Memcached Remote Denial of Service PoC

A long time ago, in 2011, a rather serious vulnerability was reported in Memcached. It is now 2013, and the vulnerability still exists in the latest version on the memcached Google Code page.

The report is here: https://code.google.com/p/memcached/issues/detail?id=192

Now, as you can see, by sending a specially crafted packet, we can cause Memcached to segfault, and essentially die. Memcached is used by a lot of high profile sites to speed up page load times, and killing it would impact a bit on site performance, so I was rather curious as to why this bug had not yet been killed.

As you can see from the report, the vulnerability is trivial to exploit. Just send the magic packet of death and it kills the memcached service. I tried to get remote code execution from it, but had no luck at all. Perhaps one of you might have more luck!

memcached dead

memcached ded

Exploit code available to download here: killthebox.py

As always, responsible use is encouraged. Killing $(big website) memcached might get you in trouble, so don’t do it.

As for the memcached devs: You have known about this for two bloody years and never fixed it. This is terribly irresponsible of you. Fix it.

Bitcoin “Brainwallets” and why they are a bad idea

// Decided to publish this after some misgivings about disclosure. After telling Asher about it earlier, it was decided to disclose it to make people aware of the issue.

A week or two ago, I stumbled across an article about how these “Brainwallet” things were making your bitcoins “Deniable”, as no “wallet” exists except in your head.

How they work is quite simple: you take a passphrase, and that is to be the super secret key for your “wallet”. So long as you remember that passphrase, you can access the wallet.

This passphrase is hashed with SHA256 to form the private key for your wallet, so you can generate your privkey at will. The privkey is turned into a bitcoin address using the standard algorithm.

Now, so long as you know the private key, you own that wallet. So if you know the passphrase, you know the private key. This is essentially basing the private key on insecure (user supplied as opposed to random) data, normally a word or string of words (everyone sucks at passphrases).

Now, how do we go about attacking this. Well, think of it as the same as cracking peoples passwords.

You take a dictionary of likely looking passphrases, and hash ‘em with SHA-256 to make a bunch of private keys. You then convert them to wallet-import format using the Base58 encoding that Bitcoin uses, and pass the WIF string to bitcoind to import the wallet. If anyone was using that private key/passphrase, all their bitcoin now belongs to you.

Being a lovely person, I wrote up a proof of concept based on brainwallet.py (a brainwallet generator) that automatically does all this. My code is terrible, but it proves the point I was trying to make. A better written piece of code could import thousands of keys incredibly quickly, exhausting entire blocks of passphrase-keyspace.

Proof of Concept

The brainwallet.py implementation I hacked into the above can be gotten here: Brainwallet.py

The terrifying thing about this is, you are not only stealing “current” bitcoins, but also future ones. If anyone ever uses any of the passphrases you have “pwned”, you own their bitcoins.

So, tell your friends: Brainwallets are dumb.

-infodox

p.s.: we now accept bitcoin if you ever feel like buying us a beer. 1MJ6KnLdXm82UjdDuvgjxDhngLjBMJfamV

NOTE: We do not encourage or approve of stealing peoples money. It is a bad idea.

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 :)
~infodox

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

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…

Refs/Links:
The Aircrack Project
Reaver WPS Cracker
Eircom WEP Key vulnerability
nmap
Nessus

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

Migration to WordPress: not as easy as it looked…

So, search when I thought “Lets move to stage two, migrate the site to a WordPress CMS”, I figured it would be fairly simple.

LOL, NO! Nothing is ever that simple. The host would not update PHP/MySQL because the ability to run WordPress was a “paid extra”. OK, fine.

Challenge Accepted Motherfuckers!

I mean seriously. Bitch, please. You tell me, a fucking hacker, that I cannot run WordPress on my own account because you want me to PAY for updates?

“So, how long did it take to make WordPress run?”

2 minutes. I basically patched wp-content/version.php to accept MY versions of PHP/MySQL instead of the hard coded minimums. It then worked.

Then came the challenge of lrn2wordpress. Themes, etc. Or rather, remembering why the fuck I installed it in the first place…

Anyways, gotta migrate content…