I have often wondered how hackers gain control of your system when you are just browsing the web. It's actually an interesting process, and knowing about it can help you be aware of the threats.
Through the rabbit hole
In order to understand what's happening when you get infected by a virus or another sort of malware, it seems a bit like going through the rabbit hole. This is because computer programming can be a bit of a dark corridor to the average person. Perhaps it's a place they don't usually go.
Have you heard of compromised websites? Well, I was surprised to know that almost any website can be compromised through a number of techniques. The main thing needed is for the website to contain a link that directs you to another website. This can easily be done, for instance in an ad. But HTML code often contains SQL code in it, when a database access is done. This kind of code is susceptible to SQL injection exploits. Perhaps the hacker gains access to the website's administration via a cracked password or some other mistake in configuration.
When you visit a compromised website, you don't really notice the intrusion. Actually it's supposed to be that way. They want to catch you unaware. So you will probably just see the website's normal content. But somewhere in the HTML stream, a malicious URL is included. This is what directs you to another website.
Wait: if it directs you to another website, then you should see your browser loading another page, right? No. Pointing you off to that website does not necessarily mean loading a page from that website. So you may not even notice anything at all. It can mean merely accessing a file at a specific URL in that website. But even accessing a single file can call for HTML code to be executed. Yes, before the file is loaded, special HTML code that verifies which kind of computer you are running and which OS version you are running gets executed first. This makes sure you are an intended victim: one with the vulnerability in question that is being exploited. And then a file is accessed, and loaded.
And Flash files are the most common kind of file that are chosen.
Flash: what's happning there?
The file being loaded is specially crafted to make use of a buffer overrun or another specific security hole in Flash Player. This is the kind of fault that seems to get patched nearly every month by Adobe. A recent update is a priority 1 (critical) security flaw, initially reported by MITRE. Apparently it's quite a problem. When logging into yahoo a while ago, I was prevented from doing so until I installed the most recent version of Flash Player.
However it happens, once you load this Flash file, the inevitable process of being infected with a virus has begun.
Eventually, an unsuspecting Windows XP user ends up downloading an EXE file which gets run and the virus is now installed.
When examining the SWF Flash files, it becomes clear that hackers like to obfuscate their code internally, usually by XORing parts of it with an 8-bit key. This renders plaintext unreadable to the casual observer. Or to anti-virus code that scans for dangerous items.
Steve Jobs, in April of 2010, noted that Adobe Flash Player was the number one reason for Macs crashing. Why is this?
One reason is that Flash allows code to be embedded into an animation file that gets run locally in your Flash cache folder. So just loading an animation file can cause actual code to be run! This code can be malware, of course. It can even be encrypted so it can't be detected by virus scanning software. And that presumes that the virus-scanning software even gets a look at that file.
Ah, but is this still true? Not exactly. Adobe has implemented a Protected View sandbox that prevents malware from being executed. But, as the recent security patch indicates, the wrinkles in this approach are still being ironed out. Still, it represents some progress.
It is well-documented that, in 2010, security experts denounced Flash.
And nearly every computer has it installed. So Adobe has had a lot to lose.
Adobe has updated Flash once again a few days ago, plugging memory leaks that get exploited so malware can insert their own code.
Building secure software
But, treating security flaws like a perception problem is really at the flawed center of a public relations way of dealing with security. Sandboxing approaches, internal file fuzzing, and white-box texting are the proper ways of dealing with such issues. Also, it is possible to hire a tiger team of professionals whose job it is to break the software in question and use it to compromise test websites. In other words, be the hacker. A regimen of code review is useful as well. Some would say absolutely necessary, particularly close to a release, when it is impossible for QA people to properly assess the security of the software. It is also necessary to have the latest in compilers as well. This means having a compiler that rigorously and continuously performs deep semantic analysis: tests for logical flaws that can lead to insecurities such as buffer overruns, enumerates and discovers cases that weren't handled, spots unlikely code scenarios, and so forth. People who program make mistakes all the time. It is unconscionable (and just plain stupid) to use a compiler that does not perform as many checks as possible.
When management doesn't embrace the methods of building secure software, then the users are the ones that lose. This is because the software's insecurities cause the users to be compromised. And then the software manufacturer loses as well. Because users won't buy it. These days, word spreads pretty fast about insecurity. It's all over the news. So, even in the case of Flash, where it is a significant part of the workflow of the web, this problem can lead to market share slippage and eventual replacement by transparent standard technologies, like HTML5.
For many years, Adobe treated the problem like a public relations problem. I speculate that is because they were concerned merely with getting releases out and reaping the revenue. In other words managers were concerned with making the quarterly revenue. Not with the future viability of their product.
Those who use secure software methodologies can see the forest for the trees. They know that sustainability is important. Perhaps the page has turned at Adobe.
Back to public relations. How should public relations work when dealing with perceptions of security failures? It's hopeless unless the company they are representing takes a proactive stance in preventing attacks to their security. When the hackers laugh at your security, you are going to be a big target, because the word will spread through the hacker community that you are a low-hanging fruit. Ripe for the picking. You get it.
Mark Zimmer: Creativity + Technology = Future
Please enter your email address and click submit to follow this blog
Showing posts with label exploits. Show all posts
Showing posts with label exploits. Show all posts
Tuesday, May 21, 2013
Saturday, October 13, 2012
How Old Is Your Software?

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.
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.

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.

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.
Subscribe to:
Posts (Atom)