Feature: Attack of the Killer Zombies |
Article Rating: Excellent
(# of votes: 1) |
|
| Author:
| 1746
|
|
| Submitted: |
01-Jan-1970 01:00:00 |
| Imported From: |
zZine (original author: 1746)
|
| After celebrating her 14th birthday with her family, Stephanie couldn't wait to get online and go to her regular IRC channel to see who was there.
|
|
Stephanie wasn't just your average fourteen year-old; Stephanie has a secret... sitting in front of the computer, with only the light of the monitor to illuminate the darkness, she typed the following command:
!r
Within moments, several hundred users had joined the channel. She then typed the following two commands:
!p4 000.000.000.000
!udp 000.000.000.000 9999999 0
She then shut down her computer and went back to her party.
Almost instantly, 421 security-compromised Windows PCs containing remote controlled bots were attacking a server belonging to a large e-commerce firm that had sent Stephanie the wrong CD; she felt they had given her a "hassle" when she tried to return it. So what happened?
The !p4 command, followed by the target IP address (in this case I have inserted a fictitious address) causes each bot to execute the standard Windows "ping" command to send ten thousand very large ping packets to the machine at the specified IP. This doesn't generate a high-speed stream because the ping command waits for a reply before trying again, but if hundreds of machines are all pinging at once, the result is cumulative and the slowdown can be significant. Since the ping command is being executed by a separate program (ping.exe), the bot is free to execute more commands.
The !udp command does far more damage. It specifies the target IP, the number of (huge) UDP packets to send, and the inter-packet delay (zero in this case). The bots each send 9,999,999 maximum size UDP packets to the target server as fast as the compromised machine's outbound bandwidth will allow.
In response to receiving the !udp command, each of the attacking machines replied;
:FuXoRing: 000.000.000.000, HitPoints: 9999999, Delay: 0
and then began "FuXoRing" the target server with a blizzard of UDP and ICMP packets, consuming its bandwidth several times over and denying services to the Internet. If these attackers are broadband connected home PC's, known as Cable Bots, and were pumping out maximum-size UDP packets at their maximum upstream bandwidth, a hundred would have been sufficient to completely shut down access to the server. This is a classic Distributed Denial of Service (DDoS) attack and works by consuming the victim's bandwidth. When this attack is performed slowly, a site owner is forced to pay for additional bandwidth, because no clear DDos attack pattern can be discerned.
Stephanie's little army is known as a botnet. The computer press calls them "zombies", but they are known as bots or IRC bots. These armies of compromised PCs can be used for a variety of purposes by the person who controls them: spamming, DDoS attacks, extortion, money laundering and fraud are among the many things botnets are used for. A zombie PC can record and send keystrokes to its controller to allow access to passwords and financial information, all the while concealing its activities from the unknowing user.
Stephanie's next attack several days later was far worse. She happened to be running Windows 2000 and had resisted Microsoft's offer to patch it, therefore she had full raw sockets capability and knew how to use it. She knew anyone with access to a raw socket capable machine can generate any packet addresses they desire and turn on whatever TCP flag bits they like. She was well aware that any general purpose TCP connection-accepting Internet server could be used as a packet reflection server, and she had collected quite a number of fairly well known servers like these by using TraceRoute and search sites she had visited (like Yahoo! and Google), including several belonging to large Internet Service Providers and therefore possessing copious amounts of bandwidth. Stephanie spent the next few minutes setting up a program on her computer to issue orders to a small squad of cable bots, and then left for school.
DRDoS - The Distributed Reflection Denial of Service Attack
To explain exactly what happens during one of these attacks, it is first necessary to explain a little about how network connections work. To be able to address and send packets of data to each other, two machines negotiate a connection agreement. The result of their successful negotiation is a TCP connection, and over that connection, TCP packets are sent. Individual TCP packets contain flag bits which specify the contents and purpose of each packet. For example, a packet with the SYN flag bit set ((for synchronize) initiates a connection from the sender to the recipient. A packet with the "ACK" flag bit set (for acknowledge) acknowledges the receipt of information from the sender. A packet with the FIN bit set (for finish) terminates the connection from the sender to the recipient. A TCP connection typically requires the exchange of these three types of packets between two machines in an interchange known as the TCP "Three-Way Handshake".
Halfway around the world, another e-commerce site appeared to be under attack by several hundred of the Internet's core infrastructure routers and shut down as a result. Packet analysis revealed that they were being flooded by SYN/ACK packets. This in itself isn't a big deal; a SYN/ACK packet is just a SYN packet with its ACK flag bit turned on. What was unusual was the number of them.
They appeared to be completely legitimate SYN/ACK connection response packets showing a TCP source port of 179. In other words, just as a web server's packets will return from the HTTP port 80, these packets were returning from the BGP port 179 (Border Gateway Protocol, supported by intermediate routers). Routers use BGP to communicate with their immediate neighbors in order to exchange their routing tables. The routing tables tell other routers which IP ranges the router can forward. Virtually all of the Internet's high bandwidth intermediate routers will accept TCP connections on port 179. Thus, a SYN packet arriving at port 179 of an Internet router will elicit a SYN/ACK packet in response.
Now, the important thing to note is that these were not compromised routers infected by any sort of zombie, bot, or what-have-you. They were just ordinary TCP servers doing their jobs. They were sending SYN/ACK packets in the (mistaken) belief that the target wanted to open a TCP connection with their built-in BGP servers.
While Stephanie was hurrying to class, her program was instructing her squad of raw sockets capable cable bots to flood the routers with TCP connection-requesting SYN packets. Those SYN packets carried the spoofed IP belonging to the target. The routers believed that the SYN packets were coming from the target and thus were replying with the appropriate SYN/ACK packets as the second phase of the three-way handshake. These SYN packets were being reflected to innocent servers. Those servers' SYN/ACK responses were then being used to flood and attack the target. Due to TCP's automatic lost packet resending, up to four SYN/ACK packets will generally be sent because the target's aggregation router will be discarding the majority of the inbound flooding traffic. A reflection server that receives no reply to its SYN/ACK packet response will believe that its packet was lost in transit and will resend the "lost" SYN/ACK packet several times (typically three retries) before giving up and discarding the attempted connection. This means four SYN/ACK packets are generated for every SYN packet received.
The besieged engineers quickly blocked port 179. With that part of the router's traffic blocked, they realized they were also being flooded by SYN/ACK packets pouring in from from several other ports, including 80, which handles HTTP connections. This overwhelmed any legitimate browser traffic to the site.
Using its list of innocent TCP packet reflection servers, each SYN spoofing bot "sprays" its SYN packets to every reflection server on its list. A fraudulent SYN packet will bounce off each server's open TCP ports, with the resulting SYN/ACK packets aimed at the intended target's network. Since the SYN flooding machine is "spraying" its packets across a huge number of intermediate reflection servers, none of the servers participating in the attack will be inconvenienced by their participation in the attack. Each reflection server will experience a low-level "flux" rather than a high-level flood. A pattern of heavy packet flow will no longer be discernible because it will have diffused into neighboring routers rather than following a single set path. These servers are located throughout the entire Internet, just a few router hops away from the attacker, such that the target is now under a SYN/ACK flood from potentially thousands of servers.
The target network is now in serious trouble.
As long as there are vulnerable computers online it will be easy to recruit zombie botnets. An inventory of bots and reflection servers can be obtained and managed by anyone with sufficient knowledge. Backtracking an attack of this nature is almost impossible.
Don't let your computer become part of the problem. You have probably heard this too many times, but never open an untrusted Email attachment. If you are using PtoP software to share files or downloading from dubious sites, remember that these are a big source of infectious ware.
Research software applications to remove existing trojans.
A quick self-exam
The majority of IRC bots open and maintain connections to IRC servers whenever the host PC is connected to the Internet. Although it is possible for an IRC server to be configured to run on a port other than "6667", it is the IRC default port.
An active connection to an IRC server can be detected by doing the following;
* Close any IRC client you may have running.
* Open an MS-DOS window and type the following command:
netstat -an | find ":6667"
then press the "Enter" key.
If you see something like:
TCP 192.168.1.101:1026 70.13.215.89:6667 ESTABLISHED
then you may have a problem!
A second test can also be performed. Since IRC servers generally require an ident server on the client machine, IRC clients almost always include a local ident server. The detection of an ident server running on your machine would therefore be another good cause for alarm. To quickly check for an ident server, type the following command at an MS-DOS Prompt:
[i]* netstat -an | find ":113
As before, a blank line indicates that there is no ident server running on the default ident port of "113 ". (Note the "space" after the 113 and before the closing double-quote.) If, however, you see something like this:
* TCP 0.0.0.0:113 0.0.0.0:0 LISTENING
then it's probably time to pull the plug on your cable modem!
Note that a Windows IRC client running on the PC will generate false-positive reports (since these are tests for IRC client programs), so be sure to completely exit from any known IRC clients BEFORE performing the tests above.
The Present Situation
Convinced that the recent upswing in virus and trojan attacks is directly linked to the creation of botnets, a number of people are fighting back, vigilante-style. One method they use is to try to locate and disable the C&C (command-and-control) infrastructure that sends instructions to the hijacked machines. The use of "Honeypot" machines can allow the controller's IRC channel to be traced. If the controller's IRC channel gets taken down, the bots can no longer connect and report in, so until the controller contacts each bot or another controller captures them, the network is down and the bots are inactive.
Another method of defense is to trace a bot's controller and learn the commands used to control the botnets, in order to make the zombie PCs download and run a cleaning tool to rid themselves of the trojan. Those machines will probably get reinfected within a short time, but in the meantime the controller would have to create or obtain a new botnet.
It is a bit ironic that because of the competition betweeen bot creators and bot cleaners, controllers have to constantly update their bots (in much the same way Microsoft updates Windows software, albeit with more success).
A number of recent attacks have shown sites to be very vulnerable. In one recent case [1], an Australian anti-racist site was flooded with an estimated magnitude of 2 gigabits per second for twenty four hours. The hosting agent, also in Australia, had contracted with a U.S.firm to provide servers. The U.S.firm cancelled the contract after the attack and only offered to send the hard drive back. The hosting agent complained that he was more concerned with the loss of "name" and the site owner was left to find another host. If this was a reflected attack, tracing is next to impossible even with the logs as they will show the packets involved to have originated from the target and quite a number of reputable servers. If this was more of a classic attack, any sort of prosecution is next to impossible due to the jurisdictional differences and the seeming unwillingness of law enforcement to get involved unless there is substantial financial loss. They simply lack the manpower.
The Future
I believe we are involved in a war with criminals and other interests that will stop at nothing to compromise or steal our personal and financial information, and they are rapidly gaining the ability to bring e-commerce to a halt. Their methods will evolve as technology evolves, so it is up to us to stay informed and take active measures to protect ourselves. Although most bots are IRC-based now, I do not expect that they will remain so, since any piece of hardware or software can be used for the same purpose.
I believe that supporting open source development is the way to go to protect ourselves and our datain the future. I believe that open source is subjected to review by the best and brightest in IT, with security in mind.
And remember: The more you know, the safer you are.
1746
Footnotes:
[1]: Anti-racist website attacked
Varghese, Sam. September 2, 2005.
smh.com http://www.smh.com.au/articles/2005/09/02/1125302722125.html
Accessed September 2, 2005
This article was originally published by CyberArmy.net in the CyberArmy Library.
|
|
You must be logged in to vote on an article
|
About Us | Privacy Policy | Mission Statement | Help
|