A Simple Recipe for Internet Domination
Rick Hellewell, digitalchoke.com, July 2004

Last Updated May 23, 2011 07:59 PMPDT

A Short Study of the "Download.Ject"/"Brebar" Attack

Before we get to the 'recipe for Internet domination', let's take a look at the probable techniques used in the Download.Ject/Brebar attack. This is the one where your computer, if you allow the execution of 'script commands' (most do), got infected with a keystroke logging program when all you did was visit a web site. The purpose of the attack is to harvest financial information, such as credit card numbers, bank web site logins, etc. This information would be gathered by the keystroke logger installed on your computer, and sent to a centralized point. In this case, it appeared to be a Russian web site controlled by a group called "HangUp", which appears to be part of the Russian criminal group.

I've gathered this information from many different sources: news reports, computer incident response organizations, seminars, etc. I don't have any connection to any 'underground' areas, nor do I have the expertise to write damaging code. And this will not be a technical analysis of the attack, but a discussion of the techniques that were probably used by the attacking group.

There were two vulnerabilities used by this attack. The first is a vulnerability of 'secure' web sites (those "https" sites used by banks and e-commerce). This was one of the vulnerability announced by Microsoft in April 2004. Many think it is the "LSASS" problem, but it is more likely the SSL-PCT vulnerability that was exploited by the attacking group. This vulnerability lets you 'own' the infected web server via a back door that you place on that server. Once the back door is in place, you can do whatever you want to that server.

So, even though the patch was released on April 13, 2004, it only took a day or two for an exploit to be published. And within a week, the exploit was widespread. Microsoft indicates that if you didn't apply the MS04-011 patch before April 24, 2004 (and rebooted), then your site could be vulnerable to this attack. (See their KB 871277 article for details on how to determine if your server was attacked, and how to detect the presence of the 'download.ject' attack.) (Note that all links on this page will open a new window.)

The second vulnerability is how web browsers work with 'script' commands. These are very common on many sites. In fact, we use a simple counter script to keep track of visits to a particular page. Scripts can be benign (non-destructive), or they can be destructive, such as loading programs on your computer without your knowledge. The vulnerability is how your browser reacts to possibly destructive scripts. For instance, will it allow a script to install a program on your computer. The script used by the attacking group was used to install a backdoor/key logging program on your computer.

The components for the attack are in place. The first step in any computer attack is to gather information about potential targets. The attackers used commonly available tools to scan for computers that were vulnerable to the SSL-PCT exploit. They probably did this 'quietly', only identifying possible targets. It is probable that they did not send out the infection right away.

During this phase, the attackers built their script file that would be placed on the web servers, along with the backdoor/key logging program that would be placed on the user's computers.

At the completion of their information gathering phase, the attackers had a list of sites that were vulnerable. They apparently concentrated their efforts (initially) on high-profile sites, those sites that were more likely to be visited by their ultimate targets. With these sites identified, they installed the exploit on those sites.

This was done by modifying the site's configuration of the 'footer document' setting. This setting allows the web designer to include a common HTML file on all web pages visited. It is similar to how you might set up an automatic signature on your email as it is sent out. But in this case, the footer document contained a simple script command to download and install the backdoor/key logging program.

With the quick infection of the web servers, the attackers just needed to sit back and wait for people to go to those web sites. Just the action of displaying any page on the site would cause the script file to install the worm program on your computer. The user didn't have to do anything other than display a page.

It worked quite well.

There aren't any 'hard' numbers of how many web servers that were infected with the document footer file. Estimates range from about 1000 to 10,000. We know from various news reports that many high-profile/high-traffic sites were infected. We don't know the actual site names -- this is closely guarded information.

We do know that the key logger program was built to send information back to a specific site that appeared to be in Russia. We also know that that web site was shut down. We know that the infected web sites are probably patched by now (although there is the theory that once you are infected with one attack, there may be other backdoors that you may not find, so the advice is to rebuild/reinstall, not try to remove the known infection). And it would seem that there was minimal disclosure of data.

What we don't know is what web sites were infected (those that do know aren't telling). We don't know what other information on those web sites might have been disclosed. And we don't know what happened to the perpetrators, even though some reports indicate that they may have been caught. (I don't think they were caught; there would have been much press coverage if they were.)

A Possible Recipe for Internet Domination

Let's build on this attack with some 'summer afternoon' conjecture about a more damaging attack. Let’s assume that, for whatever reason, we need or want to control a bunch of computers. In the past, individual worms and viruses have tried to do that, with some success. For instance, note that some reports have much of email spam coming from computers whose owners do not know they are compromised. These controlling efforts seem to come in waves and cycles. And they do not seem to have a coordinated purpose.

So, just as an intellectual exercise, let’s discuss a more comprehensive and coordinated way to control computers. This is all conjecture. The information posited here is nothing new; these techniques have been discussed in many places: security conferences, books (see sidebar), vendor sites, discussion groups, etc. A bit of time spend with your favorite search engine would get you similar information.

It would seem that some aspects of this plan would be quite complex to develop and distribute. It may be that the degree of difficulty might be too high. But there are some pretty smart people out there with the capabilities needed. And there are some steadily improving tools that can make creating exploits much easier.

This exercise came about because of the download.ject attack of last month (late June, 2004). It's not entirely clear how the attack worked. It looks like it got to the web servers that didn't have an MS patch released back in April 2004. And the attack vector into user systems was through a technique that is usually benign -- the use of JavaScript code.

Since the download.ject attack, I've been thinking about how it might have worked. In fact, I've thought about a similar attack technique for quite a while. The technique is similar to the one in my "Digital Choke" story that I wrote in 2001-2002. The attack in that story had some wide-ranging consequences. (You can read it at http://www.digitalchoke.com . )

So, let's explore how we would try to gain control of a vast network of computers with a 'super-worm'. Our purpose might be just to use those computers as mail spammers. Or, we might use them to artificially inflate advertising 'clicks' to make money. We might use our control for more nefarious 'information warfare' purposes.

Just remember that this is all conjecture. I don't have the programming skills to actually do this, nor do I have the lack of morals that would allow me to do this. I just found it sort of interesting to think about on a summer afternoon.

Design, Send, and Deliver

Let’s start by determining our delivery method. We need a way to get a program to run on many computers. We need to get it there fast, with a fast ramp-up of the attack. (A “zero-day” attack.)  And we need to evade detection, perhaps by changing our profile while “inside” the computer.

So, we’ll use a technique to infect web servers in some manner. Then we will use that web server to compromise user computers, which is our ultimate target.

Some preparatory work is in order. First, we need to write a simple worm program that will run on the user’s computer, no matter what operating system it has. We’ll want this first program to be a “checker”. Let’s call it “Chuck the Checker”’. It contains code that goes to a specific site (or perhaps a list of sites) to see if any instructions are waiting. The sequence of events might be:

• Infect the host computer, while making sure that the computer is not already infected.
• Periodically (not too often, perhaps every several hours), phone home (calls “Mom”, who we will discuss a bit later). Keep the frequency of calls spread out so that the program keeps a very low profile.
• Mom verifies your identity (caller id), if OK, continue, otherwise break the connection
• Ask for instructions. Instructions choices are:
  • Don’t do anything, call back later (Mom might tell you when to call back, or it can be a random value).
  • Don’t do anything, but update your list of Mom phone numbers. This ensures that the checker will always have a place to phone home.
  • Download a program as specified by Mom. Mom may optionally tell you what to do with the program. Options could include: Store it somewhere, but don’t run it now. Run it now, and then wait for further instructions. Terminate and exit (this could be a temporary exit, until the next startup, perhaps), or a timed ‘go to sleep and wake up later’ instruction. Or, it could be a permanent exit, never to start up again (removing all traces of yourself before exiting).
• Chuck will then follow the instructions from Mom. (He's a good obedient son.)

The result is that Chuck will be able to update itself, download, run other programs, or perform any instructions as requested by Mom.

The next main task is to create “Mom”. We already know what we want Mom to do, just look at what Chuck asks from Mom. But Mom needs a bit of the ‘checker’ embedded in her functions. We want Mom to call her home occasionally for updates or further instructions. So Mom contains the same type of functions that used by “Chuck”. Mom also is smart enough not to infect a system that is already infected.

In order to reduce the chance of detection, we need to have several versions of Chuck and Mom. The different versions might be seeded with an initial set of IP addresses of systems we had previously controlled. And we'll use some readily available programs that will allow us to slightly 'mutate' the programs so that signature-based detection will not work. Once the original programs are created and debugged, we can easily create many mutated versions of the programs. The mutated versions have the same function as the original, but they 'look' slightly different to signature-based detection programs. We might even build in a polymorphic code into both programs so that no two programs are exactly alike. This will help us keep a low profile, and make it harder to detect.

Now that Chuck and his mother (along with their almost-clones) are ready to go, we need a way to deliver Chuck to our target systems. To do that, let’s try to get someone else to do all the work. Let’s find a way to let a web server to be our delivery person.

All we need is a way to get inside the web server. We want it to run a little infection program when a user displays its web pages. So we’ll use some techniques that will look for web servers that have a known (or not-quite-yet-known) vulnerability that allows us to infect that web server with a worm. So we will start scanning systems for our new vulnerability. We won't infect any vulnerable system that we have found. We want to find many systems that we can use later. About 100,000 systems will be enough for our massive attack. So we'll slowly scan for systems, again keeping a low profile.

While scanning, we'll fine-tune our procedure to get Mom into the web servers. It needs to be fast and quick, so we will perform extensive testing on our isolated test systems to help optimize our infection routines.

One way that Mom can infect user computers through a web page would be to add some script code to the bottom of each page that is displayed. There’s a way to do this, with the ‘document footer’ capability of a web site. All we need to do is to modify the web system to insert our little script code on their pages. And if they don’t use page footers, we’ll helpfully add one. This looks to be the way that the download.ject infection was spread, through the use of document footer pages.

As we find vulnerable systems, we’ll not modify anything yet. We really need to have an almost coordinated attack, rather than a one or two at a time attack. So, initially, we’ll just carefully probe systems, looking for vulnerable systems. When we find one, we’ll add them to our list for later use.

We could do it another way. We could put in our attack code (the code that we get into the page footer, for example), a command that will phone home to a central point. Or code that would listen for a command from our attack point, and then do something when they get the message. Sort of like the coded radio messages of World War II. We’ll broadcast innocuous-sounding messages like “The grass is green on my side of the fence”. That might mean to not do anything now, but keep listening. When we’re ready to start the attack, we’ll send out a message to our silently-infected systems like “Row your boat down the stream”. That might be our activation code.

So we have the pieces in place. We’ve got web servers all over the place that are waiting for our secret activation code. We’ve got a series of compromised servers that have got our “Chuck” code ready to send out.

Note that these 'web servers' do not necessarily have to be the high-traffic sites, although that would be better. They could be systems whose owners don't even realize that they are running a web server. For instance, have you ever gone to a site that was 'under construction'? You could assume that many of those 'pending' web sites are not patched, and are therefore more vulnerable.

In fact, during our 'information gathering' phase (one of the classic first steps of a penetration attempt), we might just employ a web search spider to wander around the internet looking at the index pages of any site we find. We'll look at the content of those pages to see if we can find an 'under construction' message. Perhaps we will also attack those web sites. They might not be high-traffic sites, but maybe they will help with a low-level background infections.

Full Speed Ahead

Once we have all our attacking program ready, we can easily proxy through some several layers of controlled sites to send out our “Row our boat” message to activate the web server’s full infection. We do this to hide our actual location, so we can't be easily shut down. One of the reasons that the 'download.ject' worm didn't cause too much problems was that it contacted only one web server (a Russian one, it would seem). It's not hard to pass our message so that it appears to come from another place; a very useful program such as 'NetCat' does this quite easily. And remember that we have pre-seeded many different infection sources, and those infection sources are constantly updated throughout our many infection points.

Each web server we infect has our ‘send out Chuck” code, along with the actual “Chuck” code. We'll send out the different (mutated) copies of our program to different locations. And the Chuck code has a list of places it will contact for instructions. Note that we’ll have multiple sites for Chuck to contact. We don’t want a ‘single point of failure’ to limit our ability to send out instructions or gather information.

Now that Mom is active on the web servers, we just have to wait for user computers to get to those web sites. If we have been clever, we’ll have infected some high-traffic sites, so that we can get Chuck into those user computers more quickly.

When the user gets to our infected web sites, it gets the infected web page. The web page is processed by the user computer, which includes the commands to allow Chuck to “worm” its way into the user’s computer.  With any luck, Chuck will get into lots of computers.

The actual work done by Chuck is variable, according to our needs. We could have Chuck harvest passwords and financial data. For instance, a checking account program will probably be located in it’s default location. So Chuck might be able to grab the particular file that contains credit card information. Or Chuck could install a keystroke logger on the computer. The logger might just send out a couple of days of keystrokes to Mom. Remember that Mom could be any number of locations. The “Moms” are continually updated with new locations to send the data. It’s easy to create new server homes for Mom, places where we are collecting and consolidating the information that Chuck is sending.

Perhaps Chuck has a bit of a “dark side”. Perhaps Chuck is instructed, maybe randomly, to delete information on a computer. Or maybe it will just randomly change information in a spreadsheet. There are lots of possibilities, depending on the needs of the instigator of Mom and Chuck. It may be that the instigator is taking a more long-term view of things, so the destructive nature of Chuck’s action might not be activated. But Chuck could be programmed to do anything, including massive data destruction of all of the places where Chuck lives.

If we are clever enough, we will ensure that the death or detections of a few Chucks and Moms does not affect the entire family. Just like a master agent will compartmentalize his agents, so that each agent operates independently of the other agents, and doesn’t even know the identity of the other agents. Since Chuck and Mom are constantly being updates with new instructions, or new places to call when phoning home, standard detection methods (known as “signatures”) will not work. The worm code will be constantly changing, morphing with new attack vectors and data transfer targets.

Back to the "Real World"

Now, this is all just theory and the exercise of a bored information security dude on a nice balmy afternoon. (It may have been influenced by watching too many Westerns where the bad guys are trying to take over and control the town.) And this security dude has no intent (and some would say code-writing skills) to create and distribute Mom and Chuck. But some of the techniques in here do seem to mirror those of existing viral/worm attempts. Virus/worm writers are pretty clever, and I’d suspect that they are actively working towards a similar goal. There are many tools out there that make parts of the job a bit easier.

How fast could we infect systems? With our careful gathering of potential hosts for Mom, we can quickly 'seed' a base number of systems, using Mom on those systems to infect the other host systems we have previously identified. Remember that we only need to find 100,000 vulnerable systems. Once they are identified, we can quickly blast out our infections into those 100K systems.

There are research papers from 2001 that indicate that a 'blast attack' such as this can infect all computers on the Internet in about 15 minutes. A very knowledgeable information security consultant thinks it won't happen that fast. It may take about an hour.

I’m not sure how to protect oneself from a well-designed Chuck or Mom 'package'. More secure systems, much better ways to detect similar ‘bad’ behavior (not just signature-based detection, but behavior-based detection), much better ways to prevent the spread of similar attacks. It won’t be as easy as just adopting an open-source operating system or applications.

But it would seem that we need to be very careful out there. There could be some major consequences of a well-written Chuck/Mom worms. The world seems very dependent on interconnection of computers. If those dependencies are broken, we could have major problems. Some think that it would be equivalent to a big three day snowstorm. The Internet would be down for several days, there would be some impact, but it wouldn't be major.

I'm not so sure.

Rick Hellewell -- July 5^th to 14^th, 2004

http://www.digitalchoke.com

More comments available on our "Daynote" site: http://www.digitalchoke.com/daynotes. Your are invited to send your comments here.

Copyright © 2004 by Rick Hellewell, All Rights Reserved. Permission granted to reproduce in whole without editing, while providing attribution to the source document and the author. Limited excepts can also be referenced, with links to the original source document and the author.

You are not allowed to write code that will perform these functions. That would be naughty and evil.

The link to this document is below.