Phrack 67 comes out today! Phrack is THE online magazine for anyone interested in security. Phrack was the original magazine to debut the infamous “Smashing The Stack For Fun And Profit” article. Its been some time since they last released an issue (2009). “Is your blood boiling?” – heck ya!
Be sure to check it out;you know it’s going to be good!
There’s a great article on Conficker variant C’s peer-to-peer update process. It allows for distributed updating abilities by scanning for Conficker peers and implements a simple update protocol
- What’s your version? Here’s my version. If your running version is higher than mine, send me yours, if not I’ll send you mine.
It’s a pretty in-depth read but very interesting. Check it out
The Zues trojan has been around for quite some time. Enough time that some people have even dedicated entire websites to tracking Zues Botnets (According to the Zues Tracker, even a host on my hosting company is, or was at one time, part of the Zues Botnet!!). It’s primary target is stealing bank account information and it has been utilized successfully to steal a lot of money!
It’s said to be one of the biggest, if not the biggest, Botnets on the Internet according to Wikipedia.
Zues is a very sophisticated piece of malware. Instead of the standard central IRC based “command & control” — it utilizes a P2P web based command center which completely eliminates centralized shutdown. It also comes equipped with sophisticated updating abilities and spreads through multiple vectors, including Facebook and LinkedIn.
Even more so interesting, the bot writers built in functionality to kill your operating system. Seems like a smart idea if you want to self destruct your botnet!
If you’re interested there’s tons of info on the Zues botnet online; just do a quick search.
Excellent post from McAfee Labs on Zeus Crimeware Toolkit showing that it even comes with a graphical interface for configuring and building the malware!
This post is mainly for my own benefit because I’ll forget this if I don’t put it down somewhere. A lot of the times I need to convert hex to dec when I’m on the command line and it’s a pain to open up the calculator so here is the command line equivalent
echo "ibase=16; FFFF" | bc
The news just keeps getting worse for Adobe. After releasing an out-of-band patch for their other 0-day PDF exploit used to jailbreak the iPhone, the people at McAfee discovered malware in the wild exploiting another 0-day PDF exploit. Apparently this exploit takes advantage of your typical buffer overflow exploit (come on Adobe!) but the way it’s exploited is very interesting; it uses return oriented programming.
Return Oriented Exploitation
This is a very clever exploitation technique that subverts all known countermeasures to mitigate exploitation of overflows such as ASLR, compiler stack protection, and non-executable memory regions. It essentially works by using the prior code on the stack as well as well known (not everything is randomized) locations of library routines as building blocks for executing code. The key is that every “building block” must end in a RET instruction, hence the name return oriented.
Suppose after scanning memory we found the following useful “building blocks” (Commented for understanding )
mov ebx,0x01 # fd = sysout leave ret
mov ecx,msg # Some msg (e.g. Hello World) mov edx,len # len of msg leave ret
mov eax,0x04 #write syscall int 0x80 leave ret
You could construct each of these “building blocks” in reverse order such that the RET address jumped from one block to the next, in essence executing the following code:
mov ebx,0x01 # fd = sysout mov ecx,msg # Some msg (e.g. Hello World) mov edx,len # len of msg mov eax,0x04 #write syscall int 0x80
You’re exploit would print “Hello World” to standard out at this point (not much of an exploit!).
These types of exploitation techniques seem very hard to defend against. I’d be interested to see what mitigation techniques they’ll come up for to defend this! For more info on Return Oriented Exploitation, check out an excellent presentation at trailofbits.com.
As of very recently the PS3′s security has been finally been compromised!
Commercially, a company is selling a USB device called PSJailBreak (for a steep $130) which takes advantage of this exploit but it was reverse engineered and released as an open source project, yesterday, called PSGroove. The open source release is targeted towards homebrew developers who want to develop their own things on the PS3.
The guys over at lan.st have a really nice wiki post about the reverse engineering they did on PSJailBreak. Be sure to check out the original article for a more in depth explanation. I’ve summarized the exploit below. I take no credit for any of these findings. All the credit goes to the awesome PS3 hackers out there (GeoHot)!
Summarizing the Exploit
The exploit takes advantage of a heap overflow by making the PS3 think the single USB device that’s plugged in is a 6 port USB hub. The single USB then tells the PS3 to allocate/unallocate large chunks of heap space (4K) (using large device descriptors) by faking that devices are being plugged and unplugged from the USB hub.
One of the fake USB devices thats plugged in manages to overwrite another USB device’s heap space when allocating it’s configuration data. The key point here is that when it overwrites this data, it overwrites malloc’s pointer to where the next free memory block is. That means when malloc gets called again, it allocates space to wherever that pointer is pointing. The exploit overwrites it with a pointer to a function that it knows the PS3 will need to call. The function has something to do with freeing memory when a USB device is unplugged. (You might see where this is going)
All PS3′s have special built in functionality that allows an authorized USB “Jig” device to be plugged into the PS3 which turns it into development/debug mode. Sony uses this for repairing PS3′s and likely distributes it to game developers.
The exploit takes advantage of this fact and tells the PS3 that a “Jig” device has been plugged in. The PS3 sends an authentication challenge to the device to verify it’s authenticity. A real device with a key from Sony would be able to compute the response, respond, and continue on it’s merry way but the exploit takes advantage of the fact that the PS3 has to call malloc to allocate space for the challenge response. Malloc’s pointer to the next free space in memory was overwritten earlier. That means malloc will allocate space in the wrong place, overwriting a function the PS3 calls when a USB device gets unplugged. That means we can send a function of our choice (the shellcode) as the challenge response and the PS3 will overwrite another function with our function!
This is where the exploit gets invoked. The exploit explicitly unplugs one of it’s fake USB devices causing the PS3 to call the function related to freeing device memory which was overwritten with our challenge response data. The PS3 happily starts executing our code. From here we can now start patching memory to tell the PS3 that it’s in debug mode!
So what can you do in debug mode? You can start writing code and developing on the PS3!
Sony is very likely to patch this ASAP. In the meantime, you better hurry and get yourself a PS3. I know I’m thinking about it!