Fighting Hacking 2.0

For the past few weeks, I’ve been work­ing, for a project I’ll be able to shed more light on towards the end of the year, on try­ing to fig­ur­ing how com­plex algo­rithms to fight hack­ing of a cer­tain type of soft­ware. This has brought me to think more about hack­ing, its his­tory, and its poten­tial future.

Along the way, I’ve started to think about why sys­tems are hack­able, why they are hacked, and what the next gen­er­a­tion of appli­ca­tions may do (or decide not to do) to deal with the fact that soft­ware will always be hackable.

And, as the title obvi­ously says, I’ve come to the con­clu­sion that peo­ple, not algo­rithms, are the best way to fight hacking.

Here’s why.

The stack

A long time ago, as a tween and teenager, I got involved in some hack­ing activ­i­ties. The goal was to break the secu­rity on games that were, in an off them­selves, not that inter­est­ing. The chal­lenge of undo­ing the secu­rity became more of a game than the chal­lenge of com­plet­ing the game itself. Either I or a friend would buy the pro­gram tape (in those days, soft­ware came on audio tapes), and then we’d load it on top of spe­cial­ized soft­ware that would give us access to the core machine lan­guage code (granted, we’re not talk­ing very advanced tech­nol­ogy here as dig­i­tal watches prob­a­bly have proces­sors that are more com­plex than the ones we were deal­ing with.)

A favorite trick was to read through the binary code and find the place where you could make the pro­gram jump from one call before the secu­rity to one that was after. And often, it came down to find­ing an exploit in the chip’s code and using that against the piece of software.

I’m relay­ing this anec­dote because today’s world, while a lot more com­plex, has left us with hack­ers deal­ing with sim­i­lar issues. Pro­grams nowa­days rely­ing on a stack of other pro­grams that weren’t writ­ten by the same peo­ple. Just think of a web site or web ser­vice: in order for any page or ser­vice call to be served, pro­gram­mers will lever­age their own code and code writ­ten for data­bases, for web servers, for soft­ware author­ing (PHP, Java, C, .net, etc…), for net­work­ing, for oper­at­ing sys­tems, and for com­puter chips. Each of those presents mul­ti­ple poten­tial vec­tors of attack and there is no way one can patch all of them 100% (this insight came to me as I was dis­cussing pro­cess­ing speed issues with a net­work­ing expert who was rail­ing that the prob­lem in terms of opti­miza­tion often comes down to the lan­guages in which web apps are written).

In the best sce­nario, a pro­gram­mer may con­sider the poten­tial attack vec­tors and mit­i­gate for them but such deci­sion gen­er­ally come at a cost that can include impact on per­for­mance and sta­bil­ity. So the pro­gram­mer might then decide to mon­i­tor the prob­lem and be alerted if it hap­pens but not do any­thing beyond that. Another way to deal with it is to move the poten­tial hacker to some­thing that “looks” like it’s been hacked but is, in fact, an obser­va­tion area (sys­tems that imple­ment such mea­sures are called hon­ey­pots.)

Human Nature

Over time, as one reads a lot of code, one thing becomes clear: there are many ways to solve prob­lems using com­put­ing soft­ware and there is no def­i­nite right way for every­thing. Each piece of code writ­ten by peo­ple ends up reflect­ing some ele­ment of their per­son­al­ity. In the early 90s, I knew a pro­gram­mer who could almost always tell you who had writ­ten a par­tic­u­lar part of an open source project by just look­ing at the code: it was an impres­sive party trick and, the most amaz­ing part was that he was almost always right. Part of the rea­son for his suc­cess was that he had worked with a lot of the con­trib­u­tors and knew their per­son­al­ity and code-writing style (yes, there is such a thing as code-writing style, as much as there is one about writ­ing styles).

Since we can safely assume that com­puter code reflects human nature, we can eas­ily tie that to its poten­tial impact on hack­ing. For the pur­pose of this, I will posit that there are no per­fect humans: All of us make mis­takes at some point or another in our lives. So it then becomes nat­ural to under­stand that hack­ers who have a strong under­stand­ing of the per­son­al­i­ties behind cer­tain pro­grams can more eas­ily find things that make the soft­ware writ­ten by those peo­ple reveal its deep­est secrets.

On a basic level, this can take the form of social engi­neer­ing, where a hacker just asks some­one with access for the infor­ma­tion on how to access the sys­tem by pos­ing as some­one to who you ought to give the infor­ma­tion. Sur­pris­ingly, this is still one of the most preva­lent ways in which secu­rity get com­pro­mised: peo­ple leave their pass­word on post-it notes by their com­puter, or click on links they’re not sup­posed to, or give away infor­ma­tion they ought not to. The net-net is that sys­tems get com­pro­mised through sim­ple means and most of those suc­cesses are based on the fact that we, as a species, tend to be mostly nice peo­ple who want to help others.

Hack­ing 2.0

The last few years have seen the rise of a new soft­ware class called social soft­ware where the inter­ac­tions between human beings are a part of the soft­ware core. As a cat­e­gory, this has been grouped under the term web 2.0, a short­hand to explain the inter­sec­tion of peo­ple and programs.

As Fred Wil­son points out:

Every suc­cess­ful social media sys­tem I have ever been involved with has to tackle the prob­lem of spam. It is one of signs that you are suc­cess­ful. When the spam­mers start tar­get­ing you, it is a sign you have arrived.

In the last few days, we’ve also seen a report of hack­ing hap­pen­ing on Digg, where con­ser­v­a­tive peo­ple allegedly tried to cen­sor sto­ries they did not agree with.

And so I would expand Fred’s point (which I would call Wilson’s Law) to include all type of attempts to game the sys­tem. The corol­lary to this is that every startup that wants to be suc­cess­ful has to think about how to deal with the prob­lem of spam in par­tic­u­lar but also with other bad actors.

Roger Ehren­berg once reported on an inter­est­ing dis­cus­sion at CIFOO camp on the sub­ject:

The group pretty much deter­mined that the “gam­ing the sys­tem func­tion” is like a hump, with small sites and large sites less impacted by bad actors than those in between. Why? Because sheer num­bers make large sites with large amounts of com­ments like Ama­zon hard to taint, while small, niche sites aren’t often the focus of bad actors. Those in the mid­dle, how­ever, are clearly vulnerable.

So the bad actors in this case are the hack­ers and the behav­ior high­lighted in each of these cases are exam­ple of what I would call Hack­ing 2.0, a new field where hack­ers now work on find­ing exploits to make the social plat­forms act in ways other than the plat­forms’ admin­is­tra­tors intend.

Moti­va­tion

The moti­va­tions of bad actors are many: for some, as it was for me as a kid, it’s more about the thrill of fig­ur­ing out the way to the back­door. For oth­ers, the moti­va­tion may be eco­nomic or ide­o­log­i­cal. Unfor­tu­nately, legal regimes are cur­rently set up to deal with both sides as one and the same, with the goal of most leg­is­la­tion being around pun­ish­ment more than education.

Maybe more hack­ing con­vic­tion ought to end up with a pun­ish­ment that would include not just prison but also an agree­ment that the con­victed per­son would help enforce­ment offi­cials bet­ter under­stand the moti­va­tions and approaches such a per­son has (I’m think­ing here of the way the gov­ern­ment ended up get­ting Frank Abag­nale to help improve secu­rity in the finan­cial system).

Deal­ing with hack­ing 2.0

The chal­lenge in those cases is that the hack­ing is no longer the work of a lone indi­vid­ual but the work of a col­lec­tive so the ques­tion is how one can fight this.

Once again, look­ing to Roger’s note, it seems that the larger the site, the less the poten­tial for such hack­ing to hap­pen. This is because the larger the site, the larger the size of the col­lec­tive needed to have any impact.

What else can you do if your site is not sizable?

For starters, you can cre­ate auto­mated trig­gers that alert you when some­thing looks out­side of the norm (a group swarms on a story to upvote or down­vote it; a set of com­ments move in one direc­tion or another, a large amount of activ­ity is trig­gered) but that only goes so far and the num­ber of false pos­i­tives you have to deal with might not work.

Another way to han­dle this is to appeal to the com­mu­nity itself. Upvotes and down­votes can be coun­tered by com­mu­nity mem­bers, for exam­ple, forc­ing a restora­tion of equi­lib­rium. Or mem­bers can be given rights to report sus­pi­cious behavior.

Ulti­mately, if you take the long view, the only way to deal with this prob­lem is going to have to involve humans. Algo­rithms fail and hack­ers will always find a way around them but com­mu­ni­ties can find ways to hold on together and fight back.

On a final note, let me recount the story of an inter­net ser­vice provider I once was involved with. Most unix sys­tems have a set of super users often called root. Root access gen­er­ally allows who­ever has it to get a sys­tem to do their bid­ding. In the 90s, such access was given based on being an employee of the com­pany that owned the server. The ISP I dealt with at the time had a dif­fer­ent view: any­one could get root based on three conditions:

1. No one would give them access. The per­son who wanted root access to the sys­tem would have to find a secu­rity hole that hadn’t been closed yet on this system.
2. Once some­one had hacked their way in, he/she would do a check and see who else on the sys­tem had root access and send the list, along with an expla­na­tion of the way they had man­aged to get into the sys­tem and how they would fix it (close the door behind them) if they were admin­is­ter­ing the system.
3. They would fix the hole within a week of exploit­ing it and they would research holes exploited by peo­ple who were not sup­posed to be on the sys­tem in the first place (ie. they hadn’t reported how they got in) and fix those.

That ISP ended up with a few peo­ple who got through and an increas­ingly com­plex set of sys­tems to hack. It also become a mini think tank on secu­rity, and dis­cov­ered that, over time, fewer and fewer peo­ple got in, even though the num­ber of attempts kept increas­ing. Yes, the sys­tem was hacked, but the sophis­ti­ca­tion of the hack­ers who got in increased with any sub­se­quent suc­cess­ful attempt.

The secret this ISP had dis­cov­ered long before web 2.0 is that rely­ing on the good of peo­ple, and even the good of white hat hack­ers, is gen­er­ally a sound pol­icy and the best way to deal with hack­ing. And such good is some­thing that no algo­rithm will ever be able to deliver.