For the past few weeks, I’ve been working, for a project I’ll be able to shed more light on towards the end of the year, on trying to figuring how complex algorithms to fight hacking of a certain type of software. This has brought me to think more about hacking, its history, and its potential future.
Along the way, I’ve started to think about why systems are hackable, why they are hacked, and what the next generation of applications may do (or decide not to do) to deal with the fact that software will always be hackable.
And, as the title obviously says, I’ve come to the conclusion that people, not algorithms, are the best way to fight hacking.
A long time ago, as a tween and teenager, I got involved in some hacking activities. The goal was to break the security on games that were, in an off themselves, not that interesting. The challenge of undoing the security became more of a game than the challenge of completing the game itself. Either I or a friend would buy the program tape (in those days, software came on audio tapes), and then we’d load it on top of specialized software that would give us access to the core machine language code (granted, we’re not talking very advanced technology here as digital watches probably have processors that are more complex than the ones we were dealing with.)
A favorite trick was to read through the binary code and find the place where you could make the program jump from one call before the security to one that was after. And often, it came down to finding an exploit in the chip’s code and using that against the piece of software.
I’m relaying this anecdote because today’s world, while a lot more complex, has left us with hackers dealing with similar issues. Programs nowadays relying on a stack of other programs that weren’t written by the same people. Just think of a web site or web service: in order for any page or service call to be served, programmers will leverage their own code and code written for databases, for web servers, for software authoring (PHP, Java, C, .net, etc…), for networking, for operating systems, and for computer chips. Each of those presents multiple potential vectors of attack and there is no way one can patch all of them 100% (this insight came to me as I was discussing processing speed issues with a networking expert who was railing that the problem in terms of optimization often comes down to the languages in which web apps are written).
In the best scenario, a programmer may consider the potential attack vectors and mitigate for them but such decision generally come at a cost that can include impact on performance and stability. So the programmer might then decide to monitor the problem and be alerted if it happens but not do anything beyond that. Another way to deal with it is to move the potential hacker to something that “looks” like it’s been hacked but is, in fact, an observation area (systems that implement such measures are called honeypots.)
Over time, as one reads a lot of code, one thing becomes clear: there are many ways to solve problems using computing software and there is no definite right way for everything. Each piece of code written by people ends up reflecting some element of their personality. In the early 90s, I knew a programmer who could almost always tell you who had written a particular part of an open source project by just looking at the code: it was an impressive party trick and, the most amazing part was that he was almost always right. Part of the reason for his success was that he had worked with a lot of the contributors and knew their personality and code-writing style (yes, there is such a thing as code-writing style, as much as there is one about writing styles).
Since we can safely assume that computer code reflects human nature, we can easily tie that to its potential impact on hacking. For the purpose of this, I will posit that there are no perfect humans: All of us make mistakes at some point or another in our lives. So it then becomes natural to understand that hackers who have a strong understanding of the personalities behind certain programs can more easily find things that make the software written by those people reveal its deepest secrets.
On a basic level, this can take the form of social engineering, where a hacker just asks someone with access for the information on how to access the system by posing as someone to who you ought to give the information. Surprisingly, this is still one of the most prevalent ways in which security get compromised: people leave their password on post-it notes by their computer, or click on links they’re not supposed to, or give away information they ought not to. The net-net is that systems get compromised through simple means and most of those successes are based on the fact that we, as a species, tend to be mostly nice people who want to help others.
The last few years have seen the rise of a new software class called social software where the interactions between human beings are a part of the software core. As a category, this has been grouped under the term web 2.0, a shorthand to explain the intersection of people and programs.
Every successful social media system I have ever been involved with has to tackle the problem of spam. It is one of signs that you are successful. When the spammers start targeting you, it is a sign you have arrived.
In the last few days, we’ve also seen a report of hacking happening on Digg, where conservative people allegedly tried to censor stories 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 system. The corollary to this is that every startup that wants to be successful has to think about how to deal with the problem of spam in particular but also with other bad actors.
Roger Ehrenberg once reported on an interesting discussion at CIFOO camp on the subject:
The group pretty much determined that the “gaming the system function” is like a hump, with small sites and large sites less impacted by bad actors than those in between. Why? Because sheer numbers make large sites with large amounts of comments like Amazon hard to taint, while small, niche sites aren’t often the focus of bad actors. Those in the middle, however, are clearly vulnerable.
So the bad actors in this case are the hackers and the behavior highlighted in each of these cases are example of what I would call Hacking 2.0, a new field where hackers now work on finding exploits to make the social platforms act in ways other than the platforms’ administrators intend.
The motivations of bad actors are many: for some, as it was for me as a kid, it’s more about the thrill of figuring out the way to the backdoor. For others, the motivation may be economic or ideological. Unfortunately, legal regimes are currently set up to deal with both sides as one and the same, with the goal of most legislation being around punishment more than education.
Maybe more hacking conviction ought to end up with a punishment that would include not just prison but also an agreement that the convicted person would help enforcement officials better understand the motivations and approaches such a person has (I’m thinking here of the way the government ended up getting Frank Abagnale to help improve security in the financial system).
The challenge in those cases is that the hacking is no longer the work of a lone individual but the work of a collective so the question is how one can fight this.
Once again, looking to Roger’s note, it seems that the larger the site, the less the potential for such hacking to happen. This is because the larger the site, the larger the size of the collective needed to have any impact.
What else can you do if your site is not sizable?
For starters, you can create automated triggers that alert you when something looks outside of the norm (a group swarms on a story to upvote or downvote it; a set of comments move in one direction or another, a large amount of activity is triggered) but that only goes so far and the number of false positives you have to deal with might not work.
Another way to handle this is to appeal to the community itself. Upvotes and downvotes can be countered by community members, for example, forcing a restoration of equilibrium. Or members can be given rights to report suspicious behavior.
Ultimately, if you take the long view, the only way to deal with this problem is going to have to involve humans. Algorithms fail and hackers will always find a way around them but communities can find ways to hold on together and fight back.
On a final note, let me recount the story of an internet service provider I once was involved with. Most unix systems have a set of super users often called root. Root access generally allows whoever has it to get a system to do their bidding. In the 90s, such access was given based on being an employee of the company that owned the server. The ISP I dealt with at the time had a different view: anyone could get root based on three conditions:
That ISP ended up with a few people who got through and an increasingly complex set of systems to hack. It also become a mini think tank on security, and discovered that, over time, fewer and fewer people got in, even though the number of attempts kept increasing. Yes, the system was hacked, but the sophistication of the hackers who got in increased with any subsequent successful attempt.
The secret this ISP had discovered long before web 2.0 is that relying on the good of people, and even the good of white hat hackers, is generally a sound policy and the best way to deal with hacking. And such good is something that no algorithm will ever be able to deliver.
© Tristan Louis 1994-present Some rights reserved.