MySQL, CANVAS, and you

The latest MySQL vulnerability is a bit of a weird one - it's a bug in the underlying LibC which means that memcmp is broken in many cases. This is only the case on modern x64 machines, in certain configurations.

Actually exploiting this remotely over the Internet is probably a rare thing. Not only is MySQL rarely exposed, but if you are crazy enough to expose MySQL to the public, then it's more than likely you can't afford a x64 machine or virtual host. We expect our CANVAS customers will largely use this module for internal testing.

So without further ado, here's a movie of Immunity's implementation of it, with some penetration testing ideas for your perusal. You can view it in high quality here, or below in blurry blogger-view.

Features versus Exploits

The new version of SILICA is out and it contains some things that at BlackHat or another industry conference, you'd possibly consider an "exploit". But as Mark explains it "all we're doing is using the protocol exactly as intended!"

In this case, the "exploit" is injecting into WPA user sessions (given that you know the pre-shared key).  Now, to those of us who are not familiar with WPA in detail, or wireless security, you might think "of course if you have the pre-shared-key, you can inject into user sessions!" and we'd be exactly right. But if you're a wireless security expert, you'd probably have come to the opposite conclusion, ironically.

http://steve.grc.com/2010/10/28/instant-hotspot-protection-from-firesheep/
http://codebutler.com/firesheep (check the comments)


Adding to the links above there's "Hole 196" (named after the page of the spec it's listed on):

http://www.airtightnetworks.com/wpa2-hole196

As far as I can tell, Hole 196 (which was released to much fanfare) is a simple statement that if you have the group key (which you do), then you can send broadcast packets out. Well, of course you can!

Similarly, the "instant protection from firesheep" is to use a pre-shared-key with WPA. Or at least, that's what people think. SILICA and your common sense says otherwise.

While it's true that WPA encrypts user sessions to themselves, without a public/private exchange or a shared secret of some kind, there's nothing in the spec that will magically prevent an attacker from going through the work to decrypt and encrypt as any user on the wireless network. It is a heck of a lot of work to read the spec and then do all the work to make the packets accepted by the various network stacks (all of which are different).

But look, if there's people who can watch every West Wing and compile all of Josh and Donna's moments into one little YouTube, then there's people who are going to write the Python code that follows the WPA spec so they can inject into your sessions and steal your Facebook tokens.

To be fair, SILICA can both decrypt and re-encrypt into user sessions. And it does the decryption seemlessly, so you can look at your wireshark and it's like you're on an unencrypted network. Injecting, of course, is how you get the "saved browser passwords" attack to work, which is still my favorate new thing in SILICA.

In any case, if you're a SILICA customer, please give it a shot and let us know how it works for you!

And if you're not, then admin@immunityinc.com can help you out with that. :>