Host to Guest Code Injection in OpenVZ

This is a paper I wrote ages back, forgot about, decided to publish after OpenSSL got popped, forgot about *again* because my site was being a bollix and not working, and then remembered when walking home today. For the /r/netsec folk who will probably bash it as lame/not a new idea, yeah, its not new. Its not even that cool. But I still found it amusing as it helps show that “Virtual Private Servers” are not exactly anything that could be called private.

This paper documents a trivial method of injecting code with superuser privileges in guest virtual machines on OpenVZ systems. The conditions are that you have access to the host machine, with either a superuser account or one which has access to the OpenVZ virtual machines process space, for example, the SolusVM account on badly configured SolusVM setups. Such setups are rather common in the wild in both enterprise settings (private clouds) and VPS/web hosting companies. While not providing a remote-root exploit, it is an interesting method of abusing shared processes in virtualization software to own boxes.

Recently I, the author, was granted access to an OpenVZ setup on a virtual server host by the owner, and permitted to use it for experimentation purposes with the view to iron out any bugs before the service was publicly launched. The setup was using SolusVM/WHMCS to “Manage” the VPS servers and customer service, on an x86_64 CentOS host. The virtualization software was the reasonably popular OpenVZ software.

Previously, the author had worked with a colleague on a Linux process-injection tool, beta testing it and locating bugs. It was realized, after reading the (terrible) OpenVZ documentation, and after an idiot administrator ran “killall apache2” on the main host, that in an OpenVZ setup the process space is shared, with the processes on guest operating systems being directly accessible from the host machine.

The natural line of investigation from this was “what will happen if we try inject code into the processes of virtual machines running on the host, from the host itself?”. This line of investigation lead to the following vulnerability being discovered, and exploitation was found to be incredibly reliable.

General Overview of Exploitation:
From the host machine, all the guest systems processes run in a shared space, and may be directly manipulated from the host operating system. For example, running “killall apache2” on the host system will send the kill signal to any Apache2 processes running on the host systems (generally leading to pissed off customers). I believe this architecture is designed so a host can legitimately terminate processes on guest systems which are consuming more than their allocated amount of resources.

Seeing as the process space of guest systems is directly accessible to the host, standard techniques for process injection may be used to execute code on any or all of the guest operating systems. Therefore, it is considered trivial to inject code into guest operating systems from the virtual machine host while using the OpenVZ virtualization solution.

Impact of Exploitation:
While some may think that “if the host is rooted, the guests are compromised anyway”, and simply ignore the content of this paper, there are several rather interesting ramifications to this technique. They are not wrong either.

Of primary interest, it demonstrates that there can be no real expectation of privacy for users of “Virtual Private Servers”, which include many web hosting firms and enterprises.

It also demonstrates the lack of protection of guest processes from the host in the OpenVZ stack, which means the guests not only have to worry about the security of their own server, but are completely at risk if the host machine is compromised. Finally, it was a really neat trick, and allowed for some interesting things to be done.

Practical Exploitation:
For this demonstration, we used the process-injection tool developed by “jtRIPper”, “parasite”. You may download it from:

The host machine was running CentOS, OpenVZ and SolusVM (management software for OpenVZ). The guest host used in this demonstration, “bastion”, was running Debian. All architectures are x86_64. The utilities used on the hosting server were the “vzlist” utility, grep, and the “ps” tool, for location of process ID’s to inject into.

Exploitation, step by step:
Step one: use “vzlist” to find the CTID of the target virtual machine. The CTID is the number, normally a three digit number, listed in the first column. In the screencap, I told it to only output the details of my target virtual machine using grep. It also will give you the IP address of the target machine, take note of this as we will use it to connect to the bind-shell later.

Step two: Once you have the CTID of your target virtual machine, simply running “ps aux | grep $(CTID)” (put your CTID in there…) will list running processes on the target virtual machine. It will also output some unrelated processes, but the owner of the processes will be the same as the CTID, making locating them easy. A cleaner way is to grep for “root/$(CTID)” which I did in the demo to make it cleaner output.

Step Three: Process ID in hand, we use the parasite utility to inject our shellcode into the process. The payload is a bindshell on port 4444. Simply do “./parasite $(PID)” to inject code.

Step Four: Use netcat to connect to the bindshell on port 4444 of the target host. You should have the privileges of the process you injected into.

Step Five: Well, thats the box rooted, so, er, have fun and play safe?



This technique can be used to gain access to virtual machines from
the host machine. This impacts the integrity and privacy of the data
on the virtual machine.

It also provides an interesting lesson in how Linux process injection
techniques can be used to do more interesting things than simply
backdooring the SSHd on the host.

This proves conclusively that under OpenVZ, the guest virtual
machines are completely vulnerable to the host VM. This has
definate ramifications for the supposed privacy of “Virtual Private
Servers” on an OpenVZ stack, as it means the percieved privacy
may be completely subverted by a rogue administrator.

There is a lack of seperation of processes in the OpenVZ
hypervisior, which can be abused by someone with access to the
host machine to execute code inside the guest virtual machines.
This can allow the host to subvert any security restrictions or similar
on running guest machines, allowing theft of potentially confidential
data from clients on the guest VM’s.

If you are using a VPS server which is on an OpenVZ stack, you
therefore have no expectation of privacy whatsoever from the host

Other hypervisiors have been shown to be similarly exploitable in
the past, for example VMware. Further research into XEN and
Virtualbox/KVM hypervisiors shall be needed to see if those also can
be exploited (they can ;) ).

Code and further information/ideas: – Process injection tool used in
demo. – Potentially useful Process
Injection tool. – VMware Host to Guest
Code Injection PoC for Windows. – Information on
processes in the OpenVZ hypervisior and ideas on making a better
process-finding tool.

OpenVZ also allows filesystem access from the host, no protection
whatsoever against a malicious superuser on the host
reading/altering your files. Apparently, a superuser on host can also
spawn processes and suchlike, but the OpenVZ documentation was
so rubbish, and I did not have the patience to find out/verify.

A guest-host jailbreak is doable on OpenVZ via kernel exploits, as
seen with Enlightenment breaking out of OpenVZ containers, which
are just a glorified chroot. As I no longer have access to
infrastructure on which to run further testing (as of Feb. 2014), I
cannot do further research until further notice. Unless, of course,
someone wishes to just give me a dedicated server and a bunch of
IP addresses to do with as I please ;)

TinySHell – Ported to SCTP

You may have seen, a while ago, my post on SCTP reverse shells.

I realized quite quickly that I should definately do some more research in this direction, and hence ported one of my favourite Unix backdoors (which uses a TCP connection) to use a SCTP connection instead. This backdoor allows for a remote PTY, file upload, and file download. It also is encrypted connection.

The backdoor in question is ‘TinySHell’ by the inestimable Christophe Devine (who left quite a legacy of code, which I may start to maintain as he appears to have vanished. Chris, if you are out there, get in touch or something! Love your work!). I spent a short while examining the code, then quickly patched it up to replace all the TCP stuff with SCTP stuff. I imagine I could easily alter it to do UDP, and might try that later.

Anyways, without further ado, here is the code. Again, all credit to Chris, all I did was modify it!

Aaaand a video of it in-use (rough cut, no editing, some freezing. Will clean up later)

Also, we have not died here. Some, er, circumstances lead to extended hiatus in publication of research material.

Happy pwning!

Local File Inclusion to RCE, abusing tempfiles and phpinfo()

“If you want to win a race condition, you best cheat”.

The following article demonstrates a fascinating method of exploiting Local File Inclusion vulnerabilities first thought up of by the guy who runs . It is further documented at Insomnia Security

To start, when you are exploiting a Local File Inclusion, in order to gain remote code execution you must “write” some PHP code somewhere on disc that you can “include”. Normally this means injecting into logfiles, or the /proc/self/environ interface.
In the event you cannot locate the logfiles, or access them, most people simply give up and claim “Yep, it is unexploitable”.
This is not true.

When you upload files via HTTP POST to a webserver running PHP, during the upload it creates a tempfile for the files data, normally in /tmp. This file is “randomly named” (I do not trust the PRNG PHP uses), and is stored for the duration of the upload.

Now, it just so happens that it will create this file irrespective of whether or not you are legitimately uploading (i.e. the webapp is accepting an upload) or not, and the file is deleted when the “upload” finishes.

Because these files are randomly named, and there are no wildcards that we can use on Linux (more on this later!), you might think “So, how does this help me at all?”.

Normally, you would be right. Unless you find a flaw in the PRNG that allows you to predict the “dummy name” of the file, this is not so useful to you. What we need is an information disclosure bug that displays the PHP variables at that particular time…

… Enter PHPinfo(). The phpinfo() call, often found in /phpinfo.php or other such files (often forgotten and not removed on webservers), displays the PHP variables as they are at that point in time… Including the “Dummy Filename” that is currently in use.

So, if we are to send a file upload, containing our evil PHP code, and then include() it (via the LFI), using the path given to us by the PHPinfo page, we gain code execution on the remote server.

Yes, but not quite.
The file exists there for mere fractions of a second, so we lengthen the duration of the upload (we upload to the phpinfo file) by padding it with trash data. The insomniasec paper (linked at bottom) explains this better than I will, so I advise reading it! This is a race condition, so to further enhance our chances, we use multiple threads and multiple attempts. One of them will succeed, normally within short order (averages at 30 seconds, see the demo video!). If you have LFI and a phpinfo() page, you WILL gain code execution on the server.

The PHP code you “upload” and execute via include() effectively acts as a “Dropper”, dropping some malicious code that is stored in /tmp with a filename you have set. You then simply include() this dropped file via the LFI bug to execute code, as per normal LFI.

The InsomniaSec guys released, along with their paper, a demo script to show how it works. imax, the mantainer of Fimap (which I also develop) released a Fimap plugin that exploits this vulnerability, and that is what I am about to demonstrate. imax’s code drops a file named “eggshell” which is essentially a stripped down version of the Fimap payload.

The Fimap module is extremely reliable, giving me shells in short order. I have never had an issue with it to date, and normally on remote boxes it takes a minute or so to pop a shell.

Demo Video

Next week I will be releasing a demo of doing this against Windows targets without the lovely PHPinfo bug. A much “truer” race condition :)

Whitepaper (InsomniaSec)

Quick Post: Initial Analysis of “LuckyCat” APT Android Malware

First off, view I have not been writing as often as I like lately. Have a bunch of nice things half written, and no time at present to finish the damn things due to college. Anyway, online on with the show!

So I was browsing the Contagio Mobile Malware Dump and came across this:

I was intrigued. The “LuckyCat” APT people had come on my radar before for their elegant use of incredibly low-tech methods (old exploits, sickness very simplistic malware).

So, I decided to dissect this thing. Using Dex2Jar, Unzip and JD-GUI, I was able to quickly reduce the .apk to its source code (Java, ugh) and poke around.

Trend Micro had previously shown it seemed to have file manager functionality, remote command execution, and possibly phonebook theft features. So I decided to go look at its C&C.

I eventually found the following code in the “” class:
private String strReIP = “”;
private String strRePort = “54321”;

Now, this lead me to think “So, it connects to that host on that port… Interesting”.

An nslookup shows this no longer seems to exist:
$ nslookup

Non-authoritative answer:
Address: is, unless I am mistaken, a dynamic DNS provider.  A whois shows it to be China based, as expected.

While going over the source, I noticed a few strings with Chinese characters in them, further giving me the opinion this is another Chinese APT type threat thingy.

I did not, unfortunately, have time for anymore screwing with this, so without further ado, here is the download link to the malware and decompiled source. Password for zip files is “infected”, where needed.


0x4641494c – Fail Patching and Symantec Remote Root Redux!

Those of you who have been reading this for a while, or who are familiar with my work, might remember this: Symantec Web Gateway Remote Root, a little PoC I knocked together based on an exploit Muts from Offensive Security wrote. His PoC, I felt, was a tad unuseable, so I made an attempt at reinventing it :)

So, naturally, Symantec patched this terrible vulnerability. And everyone breathed a sigh of relief.

Or so they thought! Muts revisited it post-patch, and simply found another way to exploit the EXACT SAME FLAW. And when he released the PoC for his “Exploit: Reloaded”, I like to think he took my advice and wrote a better ‘sploit, as his new one is very similar to my “more weaponized” PoC. A bit neater too… Is this a game of one-upmanship? ;)

Without further ado, here is the exploit: Muts Reloaded!

Anyways, I better go off and finish that demo on Cryptfuscate I promised I would write :)

Zemra DDoS Bot: Backdoors in your Backdoors!

So, ailment today I grabbed a sample of the leaked “Zemra” botnet source code, and quickly did a “10 second analysis” of the webpanels source code. I often do this to see can I locate any “GLARING SECURITY FLAWS” in the C&C. I am also working on finding a google-dork to find Zemra installations.

For information about Zemra the following links are useful :)

So. This was on sale in various places online (Russian forums apparently), here however I suspect (based on the backdoor and the fact it is written in C#) that is is German in origin. Some of the stuff in there seems to be German also, illness so I assume it is another product of the German Skid Scene. Basically “Rippers Inc”. LAME!

Anyway, I was looking at the webpanels source (I will eventually rip the bots source apart) and noticed that gate.php has some lulzy SQLi (possibly).

Far more interesting was the backdoor. Located at /Zemra/Panel/Zemra/system/command.php, it is your basic “BACKDOOR”. It takes the GET parameter “cmd” and executes it.

Example: localhost/Zemra/Panel/Zemra/system/command.php?cmd=cat /etc/passwd

I will be researching this in greater depth… Sometime in the near-ish future. But as always, there be backdoors in your backdoors!

Finally: Zemra.rar file is here: Zemra

10 simple tips to secure your (home) Wireless network.

Ok, pills I never thought I would write this, however over the coming weeks I plan to write up a few simple “checklists” for the average computer user to help them secure their networks (well, make them a BIT harder to penetrate) and their computers.

Also please note this is the raw draft written up between 4am and 5.48am, Saturday 2nd of June and published sometime later that day. All concept of time and space is gone to hell due to the immense amount of sleep deprivation my fuzzing of MiniWeb is causing me. It was written on the fly, and is all original content. It is just shit off the top of my head, so if you notice any flaws in it, alert me.
The links/references to tools I refer to are at the bottom and were/will be added just prior to publication. Seeing as spellchecker has not chewed me out yet, buy viagra there is clearly no problem :P

1. If you do not need it, turn it off!
Too many home users out there do not ACTUALLY USE their wireless networks. I have seen many cases where there is a wireless access point supplied by their ISP, enabled, with encryption either turned off, or defaulting to WEP, and the computer is actually connected via a LAN cable.
This, is opening you up to a totally pointless security risk. If you are NOT using wireless, you should NOT have it turned on. It is as simple as that. By leaving it enabled when not necessary, you pointlessly increase your attack surface to anyone within reach. And with a nice antenna… Well… Lets just say, “within reach” can mean “within a very bloody long distance”.

2. If you have not enabled encryption, do so.
This is simple. If your access point does not need authentication to connect, you should really fix this by enabling it. Which brings us to step three…

3. If you are STILL using WEP, upgrade to WPA-2 NOW!
Ok. Some simple stats/figures. If, for some reason, you, like MANY others, are still using the WEP encryption on your router/access point, you are just ASKING for someone to own you, be it a non malicious nearby kid who wants free internet, or someone who wants to, er, “explore”, your network. And all too often that freeloading kid turns out to be an explorer… Either way, using WEP is a very serious risk. You may as well be using NO encryption.
Let me explain it simply. My “fastest record”, from starting sniffing/injecting to cracking the WEP key, has been three minutes. Drunk. In a bar. Using nothing other than the freely available, open source, aircrack-ng toolkit. Three minutes. Less than the amount of time it takes to smoke a cigarette. Less than the amount of time it (normally) takes me to get a pint of Guinness at a bar.
WPA-2, on the other hand, (or even WPA, but why not opt for the more secure, better encrypted version?), can be a TOTAL pain to crack. First you have to capture a handshake, then you have to crack the key. Waiting for a handshake to appear can take hours! Even if you are deauthing people and sniffing, you could STILL be waiting hours! And then there is the chance their password is not in your wordlist… Using WPA exponentially increases (on average, in MY experience), the amount of time it takes to access your network.

4. Use a secure wireless passphrase.
First off, the default passphrase that comes with your wireless router/access point, is rubbish. Change it. It may look secure, but all too often there is a secret (i.e. well known) formula to derive the passphrase from the routers SSID or MAC address. See the Eircom WEP Key Bug for an example on this, though there have been countless other such vulnerabilities exposed.
If your passphrase is a dictionary word, or even a permutation of one, change it. A sentance is more secure, and just as easy to remember. Better yet, some random junk. Your computer will remember it FOR you, so you REALLY have no excuse. You only have to find it once, and there is NO shame in keeping “WPAKEY.txt” in your “My Documents” folder. I do it myself…

5. Disable WPS.
WPS, known as “Wireless Protected Setup”, was designed to allow devices to easily authenticate to access points in a secur fashion. Too bad the implementation has been proven to have some flaws, allowing people with freely available software such as Reaver to crack your WPS within a short period of time.
You should check does your access point allow WPS, and if it does, DISABLE IT. If, for some reason, it cannot be disabled, I would advise replacing it… Or shouting at your ISP repeatedly until they release an upgrade that allows disabling it.
This may cause SOME inconvenience, but I have never actually found a legitimate use for WPS (yet).
Just disable it.

6. MAC Address Filtering.
As a standalone security measure, MAC address filtering is a joke. It is easily bypassed. However, when combined with such things as WPA-2 and string passphrases, it actually adds an extra layer of security. This is the defence in depth principle.
Essentially, this locks your Wireless Access Point to a “whitelist” of devices that you add to it. You simply add the MAC addresses (unique identifying “addresses” on network interface cards) of all the devices you want to allow on your network to the “whitelist”, and nothing else can connect. Unless, someone hijacks the MAC address of one of your devices (trivial), however this DOES add an extra element of complexity to any attacker who wishes to breach your network.

7. Disable SSID Broadcast.
Wireless Access Points are chatty beasts, and quite enjoy telling EVERYONE within range about their existance, who they are, who made them, their signal strength, and what encryption they use.
This is similar (to steal a phrase from SOMEWHERE, I CANNOT REMEMBER WHERE) standing in the street shouting your name, address, date of birth, creditcard number, CVV2, mothers maiden name, PPS Number/SSN and whether or not you are armed. Fucking stupid.
You would not do such a thing (I hope!), so why should your wireless hotspot?
You should change the SSID to something nonstandard and unique, and then disable broadcasting. This means that (in theory) only people who already know its SSID/Name can even consider connecting to it, and everyone else sees “hidden network”.
However, this alone is also useless – it can be broken/circumvented by a skilled attacker. HOWEVER, it adds yet another layer of complexity to the attack, and again, helps us in applying the Defence in Depth principle.

8. Lock Administrative Interfaces.
This one is also quite simple. Log into your router. Think for a moment about how incredibly lame the username/password it uses is. Change them.
This stops malicious intruders from (Easily) reconfiguring your network, which could allow them to launch Pharming attacks on you by reconfiguring your DNS servers. If you lock these down, it may just help in slowing down an attacker or even make them just give up and move on to easier pickings.

9. Routinely Scan your Network.
I do this, and I advise everyone to do this. Download something like Nmap and use it every so often to scan your network for unauthorized devices connected, rogue services that should not be running, and other such nasty things. This can often help you in detecting a breach early and rectifying it, and can also assist you in locating vulnerabilities in your network. I know Microsoft Security Essentials also has an auditing tool, you should also run this, or Nessus, to detect vulnerable devices attached to the network.

10. Change Everything Regularly.
This one is the one most people fail to do: Change their passwords regularly.
In the event of a compromise, you CAN LIMIT THE DAMAGE, if you are routinely changing the passphrases on your gear. I do so every 2 weeks out of habit – every 2 weeks, I simply change ALL the passwords again. It only takes a few minutes. And you know what? It is certainly worth the time for the extra peace of mind – if someone HAD gotten in during those 2 weeks, they are now locked out. Until they get in again. This limits your exposure, and helps frustrate an attacker to the point where they give up. It is also good security policy. Also change the hidden SSID to something new, and check have any new MAC addresses been added to your whitelists. AUDIT THE WHITELISTS. This is one sure fire way of detecting intrusions – spotting the attackers MAC in your “whitelist”. This way you also have evidence of an intrusion and can report it to the authorities, or simply set up something to alert you when they try connect…

The Aircrack Project
Reaver WPS Cracker
Eircom WEP Key vulnerability

[Howto] Installing Nemesis on Ubuntu Linux

Ok. Nemesis is a very powerful Packet Crafting/Injection tool for Unix based systems. I have heard that ALLEGEDLY it can be installed/ran on Windows also, ailment but never felt like trying, as I do not use Windows nor is Windows much good for ANYTHING to do with sockets.

Nemesis is similar to tools like “hping” in that you can customize the packet you want to send, and send it. Very useful for playing with low level protocols, and incredible if you want to learn more about the network layer stuff.

For more information on Nemesis, prostate you can always check out the following links…

SO. How do I get Nemesis to work on Ubuntu and such?

Well, most distributions do not have it in their repositories it seems, and just because it is easy to do, let’s compile it from source.

Step One: Install Dependancies

First off we need to install the dependancies it has, so the following two commands should do the trick.

apt-get install libdnet-dev
apt-get install libpcap-dev

No screenshot should be needed here I hope…

Step Two: Install “libnet” to the /usr directory.

Now for convenience, I do my installation in the /usr directory. Don’t ask why, it just seemed right at the time.

The following commands should do this easily for you…

The first three are “preparing the build area”

cd /usr
mkdir nembuild
cd nembuild

The next three are “getting the sources and unpacking them”
tar -xf libnet-1.0.2a.tar.gz
cd Libnet-1.0.2a

The next commands “configure” and make + make install the Libnet libraries.
make && make install

Installing Libnet

So. Now that we have successfully installed Libnet (if you get some wierd errors, leave a comment and I can try help you) we can go on and install Nemesis!

Step Three: Installing Nemesis

So. This is the fun part – where we get to finally install Nemesis.

Assuming you are still in the directory “/usr/nembuild/Libnet-1.0.2a”, just “cd ..”.

Otherwise, “cd /usr/nembuild” so we are all on the same page!

So. Lets prepare our “Environment” for the Nemesis installation by getting and unpacking the sources! The following commands should do it…

tar -xf nemesis-1.4.tar.gz
cd nemesis-1.4
Preparing to install Nemesis

So, thats everything prepared. Now for the tricky bit – making it build properly.

Note that I used very specific paths for this – this is because we HAVE to specify THESE libnet libraries!

Now for the next commands…

./configure —with-libnet-includes=/usr/nembuild/Libnet-1.0.2a/include —with-libnet-libraries=/usr/nembuild/Libnet-1.0.2a/lib
make && make install


Installing Nemesis

There we go! Now for usage and such, “man nemesis” is a good place to start – they don’t make those man pages for nothing you know!

Finally, to wrap up, a screenshot of Nemesis!

Nemesis - Screenshot

More Decompile – Nuclear DDoSer

Seeing as it is the weekend, and I had promised this, here goes nothing… Yesterday you saw my decompile of the lame HTTP Flooder – see HERE – and today, I have decompiled Nuclear DDoSer.

I previously wrote about “Nuclear DDoSer” HERE , comparing it to the SlowLoris and Slowpost tools.

This thing, as a point of interest, operates in a similar way to how I theorize “XerXes” works, and with some modification and improvement could actually do a considerable amount of damage.

SO I will not be bothering making those improvements.

Go get it here…

MD5: c8248c60b438fe544c7dfdd847f53692
SHA1: c3757099dead3a3f7656c33a49072a8126174929

AS always, we decompile and release this stuff so you don’t have to, for purely educational purposes, and to satisfy our sense of schadenfreud toward the skidiots out there. “We do not like them very much”.

Reflected SYN Floods

Spoofed SYN Flooding – A closer look at Amplification and Reflection.

In the First Part of this series on Denial of Service attacks, I explained how Spoofed SYN Floods worked. I also briefly mentioned in the SYN flood part, how the server replies with *more* data than you sent it.

In most cases anyway, this is true. If I send ONE SYN packet to a server, it normally sends 5-7 SYN-ACK packets back at me, just in case some get lost along the way.

So, for every packet I send, I get several packets back… Bear this in mind as we continue.

The Spoofed SYN flood script shown, spoofs its SOURCE IP as that of a random host. So our victim will be sending this random host a SYN-ACK packet, that the random host never knew was coming. In fact, it will be sending it *several* SYN-ACK packets…
So what does the random-host do about this?

Well, if you receive an erroneous SYN-ACK packet that you never requested, you simply reply with an RST, or RESET packet. This is the cyber-equivalent of “Bugger off”. And you don’t just send one either… You send between five and seven of them…
Now before you start thinking you could kick off some kind of endless loop here, no. If you get a RST you do not reply. Simple as that.

So, are we getting the picture here? We can have an amplification factor of (theoretically) between 25 and 49 times the amount of packets we are flooding with. IN THEORY. Accounting for massive packet losses that tend to happen in flood conditions, we are looking at a more modest 5-6 times amplification… Which is still not bad! Not bad at all! We MAY even get a 10x amplification if we are very lucky…

So, that simple Spoofed SYN Flood script I posted… A lot more lethal now, no?

AS an aside, What if you never bother sending packets to the victim host at all? What if you spoof yourself AS the victim, and spam the entire internet? This is going to give you a 3-4 times amplification, and is the implementation most spoofed-syn-flood users use. I have NO idea why, as it is less efficient. However, it does bypass rate limiting,, so it has its place. I will post up some example code that does this next time I find it…

References/fact checking:
RFC 793
RFC 4987
CERT Advisory 1996-21
Arbor Networks