Saturday, October 13, 2012

How Old Is Your Software?

Let's look at software vulnerability. What kinds of software are the most vulnerable?

Well, duh! The oldest, most crufty kinds of course! Whenever you add onto software year after year, you unwittingly create opportunities for exploitation. We say that our data are secure, yet we do not test software in anywhere near the rigorous fashion it requires!

This leaves us with highly-functional yet completely-vulnerable software. And the users don't even realize it. Business users, corporate users, individual users, you.

Which Software is the Most Vulnerable?

Means: Programmers only need to be connected to the Internet and have a computer capable of being programmed to become a hacker. This makes up basically every person on the planet in all but the seriously developing nations. So let's just say there is a large sample set of possible hackers.

Motive: To be vulnerable, you also have to be hiding something desirable, interesting, or perhaps embarrassing. In other words: valuable to someone who just needs some street cred. What holds this kind of data? Your computer, your hard disk, your database, managed by operating systems, software that routinely gets installed or updated, things like distributed database server software also that protect huge amounts of data. For more motives for hacking, see my first blog post on Hackers.

Opportunity: So, let's look at software that has enjoyed release after release year after year. These releases are generally done for the purposes of:
  • increasing their feature set
  • making them faster
  • fixing their security holes
So let's examine systems which do this. Operating systems, like Windows, Mac OS X, iOS, and Android certainly are updated quite often. System software for supporting desirable things like videos are updated often as well, like Adobe's Flash. So are things like their suite of programs the Creative Suite. In business, the Oracle SQL Server is updated quite often also, to add features and, more often, to patch vulnerabilities. Programming capabilities like Java site updated a lot also. Even GNU, the Free Software Foundation's operating system, which declares proudly that GNU's Not Unix (though it is identical to it in every way I can see) is updated quite often.

These are the most vulnerable software systems on the planet, merely because they are updated so often. And because so many people and businesses use them.

What Makes These Vulnerabilities?

The best positive marketing driver is the first one: increasing their feature set. To do this, it is often necessary to allow other developers to add to their feature set. We see this in nearly every OS platform in history. Supporting Applications. Allowing Plug-ins. Enabling programmability.

Being able to program something is highly desirable. It is also exactly what causes the vulnerabilities.

In 1984, I bought my first Macintosh. Actually it was an original 128K Mac. And the first thing I did was to take it apart, with a long Torx screwdriver and some splints to crack open the shell. My business partner in Fractal Software, Tom Hedges, was doing the exact same thing in the very same room. We both came to the conclusion that it needed a real hard drive, which was an interesting hardware task. We also came to the conclusion that we wanted to program it.

I wanted to create a new application.

We met an Apple person, Owen Densmore, at Siggraph that year and he put us in touch with a key developer, Bill Duvall, who had built the Consulair C system with a text editor. Owen gave us the external terminal debugging capability, called TermBugA, that we could use to debug our applications. He put us in touch with Steve Jasik, who authored MacNosy, and had disassembled the entire ROMs in a Mac. We built our first apps for the Mac within a couple of weeks and began our development career.

This is the old school method. The very ability to program a device has a name now: pwn. This means "owning it" but it also has a whiff of programmability to it.

If a device is a computer of any kind, then the desire to program it freely is a natural consequence of these old school ways.

But those ways must change.

How Are The Vulnerabilities Exploited?

The goal is to become a privileged user on the computer. This will enable the hacker to install their programs, get access to whatever data is available without restriction, and basically to take over the computer. Once this is done, then malware can be installed. Things that log your keystrokes. Or watch you through your webcam. Or check which web sites you use, remembering whatever passwords you use to access them.

This enables them to steal your identity or your money. Or you can be blackmailed with whatever incriminating data is present. In other words, criminal activity that exploits you, your business, or your customers.

But overwhelmingly, your computer can become something that is not under your control and can be used as a base for expansion, virus propagation, or as a machine to support DDoS attacks as well.

How do they get control of your computer? Often it is with a very small bug.

Now, software above a certain size always has bugs in it, and that's the problem in a nutshell.

The kind of bugs that hackers look for are primarily buffer overrun bugs. Because all machines are Von Neumann machines, data is stored in the same place as code. This means that all the hacker needs to do is insert their code into your system and transfer control to it.

A buffer overrun bug allows them to do this because, by definition, once a buffer (a fixed-size place in memory to store data) is overrun then the program has lost control of what is going into memory. With a little cleverness, after overrunning the buffer, the data will go someplace that is a tender spot. This can cause another bug to happen or it can be a spot where program control will end up soon enough in the future.

And voilá, the hacker is running their own native code on your computer.

Their next trick is to become a superuser. This is sometimes referred to as becoming root. These terms come from UNIX, which is the basis for many operating systems, like Mac OS X and Linux.

This can be done several ways, but the most effective way is apparently to masquerade as a routine install of familiar software. Like Photoshop, Flash, a Windows Service Pack, etc.

But the process of taking over a computer, which comprises a rootkit, is often a several-step process.

Perhaps the computer becomes a bot, simply running jobs for the hacker: sending email spam at random times, using the computer's position in the network to attack other local computers, making the computer be part of a Distributed Denial of Service (DDoS) attack.

Perhaps the hacker only wants to get the data in that computer. The easiest way is to gain superuser access, and then you have the privileges to access all the files. Maybe the hacker just wants to watch the user and gain information like bank account numbers and passwords.

Sometimes the hacker just wants to get access to databases. The databases contain information that might be sensitive, like credit card information, telephone numbers. Since these databases are generally SQL servers, a specific kind of attack is used: SQL Injection attacks.

Poorly-written SQL can have statements in it that evaluate a string and execute it. Rather than running code with pre-specified bind variables. It is these strings that make SQL vulnerable to being co-opted by a hacker, who can modify the SQL program simply by changing its parameters. When the string gets changed to SQL code of the hacker's choice, it can be executed and the hacker can, for instance, extract all of the database records, instead of the usual case where the records on certain date may be accessed. Or the hacker can change the fields that get extracted to all the fields instead of a small number of them.

How Do We Combat This?

It is easy to say there is no way to fight system vulnerabilities, but you would be wrong.

The strongest way to stop it is curation. One form of curation is the ability of a supervisor to prevent malware from becoming installed on a system. When a system allows plug-ins and applications, these must be curated and examined for malware and the backdoors and errors that allow malware to take hold. And they must be limited in their scope to prevent conscription of the operating system and applications that run them.

In the case of Apple, curation means examining every App built for its platform for malware or even the whiff of impropriety. And this is a really good thing in itself, because it means that far less malware attacks iOS than does Android.

In the case of SQL injection attacks, rewrite your SQL to not use executed strings.

But general practices need to be followed religiously. Make sure your passwords are not guessable. Use firewalls to prevent unintended connections. Beware phishing attacks.


4 comments:

  1. Good topic Mark. A related topic is "Do we really know how to develop software?". I contend we don't. We make lip service about all the great things we are going to do (design review, code review, unit tests and the like), and then we don't bother to do them because there is never enough time. I hope Apple isn't like this, but I know my company is, and it makes me sad. I think I have become a bit cynical... ok a lot cynical in my old age.

    It is really hard to develop good software, and few people understand that. And finally, the really sad part is that none of them are managers.

    Sorry to hijack your post, Tommy Z (you know who)

    ReplyDelete
    Replies
    1. No prob. Developing software is of course my specialty. And it has changed through the years quite a bit. Lately the procedure of file fuzzing is responsible for unearthing loads of buffer overrun and edge case bugs. The best offense is a good defense also, and a static analyzer is key in developing software. GNU has such a tool and it is first rate. Not like the crap I used to use when I was developing my own apps. This stuff is state-of-the-art.

      White box testing is a procedure used by QA people that uses knowledge of the code to design cases to break it. And this is even better, because a clever human is behind the cracking process.

      Another main process for verification is, believe it or not, optimization. When optimizing, code can undergo the most amazing amount of inspection and consistency checking. This may happen during the process of removing redundancy, the construction and hoisting of ghost variables, the elimination of variables to cut down on the amount of computation, or even in the algorithmic simplification process.

      Even so, once this occurs, it is still most of the code that doesn't get optimized, by the 90-10 rule, and so the rest of it has to be examined quite closely.

      In a unix world, the careless use of strcpy, sprintf, strcat, and other standard library routines becomes something that should simply be outlawed. Those calls can be replaced by strncpy, snprintf, and strncat for instance. But things like memmove and bcopy are especially dangerous.

      In an Objective C world, these can be replaced by objects that are safe, like NSArray, NSString, NSDictionary, and the like. I prefer to use these because it makes coding easier, but I wouldn't particularly prefer them in the tight loop.

      Nevertheless, I believe that there is not enough testing in general because software is inherently dangerous and insecure. This is why I believe we should use every weapon in our arsenal to make sure of its security.

      Particularly on a mobile platform!

      --Mark

      Delete
  2. And one more bad thing is that sometimes when you really want a company to send you an e-mail, it ends up in the spam filter… It's very annoying to check the spam when you expect something important. So, it's not just a question about blocking the spam, it's also a matter of how to make sure the good mails reach their destiny.

    ReplyDelete
    Replies
    1. Sorry for the lateness of my reply, but...

      You know what? I usually get notified when people comment on my blog. With your comment, it literally ended up in my Junk mail folder. I guess I don't check my junk mail folder as often as I should (!), but when I checked it today, I found your comment in it.

      I found it unbelievably ironic!

      When security is an issue, I learned (in a computer security course I took at UC Berkeley in the late 70s!) that one way security can be defeated is by preventing a message from being received.

      Apparently spam filters are insecure in a big way.

      It seems like I should check my junk mail a bit more often to prevent more headaches!

      --Mark

      Delete