Internal Denial-of-Service with Fork and Malloc Bombs

by Israel

Anyone who watches the (((Western news))) has heard of "cyber attacks."

This is usually a dumbed-down media term for Denial-of-Service attacks.  This kind of attack has become rather popular lately.

Examples include attacks from China against the U.S., Operation Payback from Anonymous, and many others.

While somewhat effective, there are other ways to bring a server down that can be more effective and harder to trace.  I hope to show how to improve on this and, as a caveat, prevent such attacks.

Remember, this information is for educational purposes only!

A Denial-of-Service attack (DoS) is accomplished by taking a client, or multiple clients (Distributed Denial-of-Service or DDoS), and using them to flood a server with packets until it can no longer handle the traffic.  The server either crashes or becomes unresponsive to the world.  The same is achieved with software called Slowloris by only sending an unfinished TCP handshake.

There are a couple of problems with flooding.

One, there is a chance you may bring down a node along the path of the target server and never complete the attack.  Two, most sophisticated firewalls are going to drop an obscene amount of packets like this.  In Linux, iptables can easily be configured to drop all SYN packets (or other packets) from a connection that generates too many per second.  Lastly, to perform a SYN flood or any classic DoS on a network is very loud!  An ISP or anyone on the line can see this coming a mile away.

While Slowloris is a lot quieter and likely to complete, it has one major pitfall that I see it shares with traditional DoS.  Beyond spoofing, there is no way to really cover your tracks.  An administrator can still view a log and see where the attack initiated from.

Let's jump ahead now and look at this code.

I will tell you before you gasp or laugh that this is not a mistake.  An infinite loop is usually considered a big no-no, even though they are used for writing processes and daemons.  The reason you're told not to use them is because they can crash a machine if not properly implemented.

However, in our case, this is not a bad thing:

bomb.c:

// bomb.c #include <stdlib.h> int main(void) { int *x; for (;;) { fork(); x = malloc(sizeof(int) * 2097152); *x = 0; } }

The code above is basically a combination of a fork() bomb and a malloc() bomb.

Like I mentioned before, this is an infinite loop.

Upon each iteration of the loop, it will call the fork() function.  This will cause the program to subdivide, creating a new instance of itself each time the loop is run.  This alone will keep demanding more and more resources until they are all gone and the system crashes.

To improve the speed of this, I added the malloc() function.

malloc() allows you to allocate dynamic memory, but normally you are strongly advised to use the free() function afterwards to prevent a memory leak.

Again, we are throwing caution to the wind.  malloc() is being called here to allocate 2 MB of RAM on each iteration of the loop.  This number could be set to anything, but remember, it takes milliseconds to run this loop many times.  The new processes/daemons started by fork() will also be running malloc(), so it won't take long to gobble everything.

While Linux has very good protection against this in the kernel, it has almost nil in userland.

When I tested this code against Debian Sid, it froze the mouse instantly and kicked on my cooling fans.

Your mileage may vary between OS, RAM, and processing power.  Similar parallels can be drawn between this and a DoS, with the bandwidth attack versus memory and processing power.

So what do we do with this?

First, one should achieve a reverse shell on the server.

I'm not going to explain this because it would be an article in itself.  Once access is gained, this code can easily be converted to run inside a userland rootkit or a Trojan.

Anything that is stealth and can start at boot would be fine.  Probably any strength of hardware would never finish booting upon running this code.  After covering your tracks and implementing this, you can send a halt to the system to reboot and freeze, or crash the system.

A lot of people may even interpret a machine not booting as a hardware problem, not even thinking the attack has taken place.  Applying this method to any system backups and mirrors may not hurt as well.

Prevention

Most Linux systems can be configured to put limits on how many daemons or threads can be used by the same program.

(Yes, there are thread bombs too...) But by setting limits in /etc/security/limits.conf, you can easily stop this from happening.

Windows should allow some configuration file of this degree for their users or at least build implementation from the kernel.  I searched but could find no documentation of this in Windows.

However, any administrator worth his salt should have a good list of hashes on the server regardless of the platform.  One could mount the server with a live Linux distribution and be able to examine their files for any injected code inside an incorrect hash.

If you have not checked your hashes, you most likely won't.

You won't have a log when the time comes and malware will look like just another file.  But, in this case, you most likely already have a Trojan, rootkit, or bot and don't know it.

Learn to store your hashes just like you do good backups, in separate locations with multiple backups, perhaps even on paper in case your backup is tampered with.

Code: bomb.c