Fuzzing

Fuzzing Samsung Kies

Android fuzzing is always fun – seems that whenever we fuzz an android app it crashes within seconds.

Samsung Kies was no different. With the help of the talented Juan Yacubian (who built the Kies module in no time) we launched beSTORM against Kies… And saw it crash in record 23 seconds (just over 1,100 attack combinations).

Next on the agenda: install gdb for Android and build the proper payload.

Samsung Kies Crash

 

S. Korea Cyber Attack Crashes Navigation Devices. Time to fuzz your GPS?

South Korea suffered a major cyber attack yesterday. The origin of the attack seems to be China at the moment, but that is far from being definite.

I happened to be in one of the (several) cyber security operation centers, by pure coincidence. I had a chance to see events unravel in real time. Several banks have been hit (including the very large shinhan bank) and a few broadcasting channels.

The damage is hard to assess, since it’s now in everyone’s advantage to blame the cyber attack on anything from a system crash to the coffee machine running out of capsules. Budget and political moves will dominate most of the data that will be released in the next few days.
It’s clear, however, that the damage substantial. I reached out to a few friends in technical positions at various MSPs and most had a sleepless night. They’ve been hit hard.

The most interesting part of this incident, in my opinion, was a report on car GPS crashing while the attack was taking place. I haven’t seen a news report about that yet, and I couldn’t personally verify it (as I mentioned, I was stationary at the time, watching the frantic cyber-security team getting a handle on a difficult situation) but this is making rounds in security forums and a couple of friends confirmed to me that their car navigation system crashed and had to be restarted, at the exact time the attack was taking place.

The most likely explanation is that the broadcasting companies, who send TPEG data to the GPS devices (almost every car in Korea has a GPS device, almost all get real-time updates via TPEG), had sent malformed data which caused the devices to crash. This data could have been just a result of a domino effect from the networks crashing, or it could have been a very sophisticated proof-of-concept by the attacker to see if they can create a distruption. Traffic in Seoul is bad even on a normal day; without GPS devices it can be a nightmare.

Which brings up an interesting point about fuzzing network devices. TPEG fuzzers have been available for a while now (beSTORM has a TPEG module, and you can easily write your own TPEG fuzzer). The difficult part is getting the GPS device to communicate with the fuzzing generator; this is something the GPS developer can do (but probably won’t) but it is also possible for a government entity to do the necessary configuration to make that happen, given the proper resources or simply by forcing the vendors to cooperate.

The choice of the attacker to bring down the broadcasting networks might be deliberate: other than knocking TV and radio off the air (an obvious advantage in a pre-attack strike) the broadcasting networks control many devices who rely on their data. Forcing them to send malformed data to crash a variety of devices can have interesting implications. If I was a little more naive, I would predict that this will push governments around the world to focus more on fuzzing to discover these kind of vulnerabilities before they see their adversaries exploit them. But in the world we live in, they will instead throw around the phrase “APT” and buy more “APT detection products” (an oximoron if I’ve ever heard one). Thank god for APT, the greatest job saving invention since bloodletting.

An detailed analysis of the attack here:
http://training.nshc.net/KOR/Document/virus/20130321_320CyberTerrorIncidentResponseReportbyRedAlert(EN).pdf

Malformed input?

Came back to the computer after some time away, to find the sun shining full on the desk and part of the screen.  And, of course, the screen has blanked from lack of input during that time.

So, I pull the drapes forward to shade the screen–and the screen pops up, even though I haven’t touched the keyboard or the mouse.

Considering this, I realize that a) it’s an optical mouse, and b) it was on the part of the desk that was in the sun, and is now shaded when I pulled the drapes.

So, being a security geek, I start to wonder:

a) how the system interpretted that light?
b) how hard it would be to figure out how to get a laser to create specific “actions” on the computer?  (And if the optical sensor’s range is wide enough that you can do it with an IR laser, so the user doesn’t realize what you are doing?)

Windows Device Driver Fuzzing

We recently received a request to adapt the beSTORM  fuzzing framework to fuzz a series of Windows Device Drivers. It appears that there is little documentation and practically no commercial tools to provide proper fuzzing for Windows Drivers.

Adding support for device driver fuzzing required us to add a few function to our already existing File Utils library. This library allows you to create and read files with the intent of using the information inside these files to either fuzz something else, or provide a file to a piece of software that you intend to test.

With a device driver you basically do the same, but instead of opening an ordinary file, you open a device driver – usually in the form of “\\.\AAA”. The AAA is replaced by a string that tells the Windows operating system what device he should open. To provide this function inside beSTORM we introduced the Win32CreateFile wrapper function which receives the device driver’s name. This function returns a HANDLE that is then fed to the Win32CloseHandle wrapper function to close the opened handle.

The next step in fuzzing a Windows Device Driver is to send it information and in some cases read from it information. This is done through our Win32DeviceIoControl wrapper function, which receives the HANDLE from Win32CreateFile, and is passed an InBuffer as well as a IoControlCode value. Most commonly this value will be generated through the CTL_CODE macro under Visual Studio, and since it is usually very difficult to calculate this value by “hand” we provide a wrapper function called Win32CtlCode to allow you to do this inside the module you create.

Here is a complete “block” that utilizes all these wrapper functions and exploits a vulnerability in DVWDDriver – which was built with vulnerabilities inside it as an educational tool.

<SC Name="Sequence">
<SP Name="Win32CreateFile" Procedure="Win32CreateFile" Library="File Utils.dll">
<S Name="Filename">
<EV Name="Filename value" ASCIIValue="\\.\DVWD" Description="CreateFile Filename" />
</S>
<S Name="DesiredAccess">
<C Name="DesiredAccess value" Value="C0 00 00 00" />
</S>
<S Name="ShareMode">
<C Name="ShareMode value" Value="00 00 00 07" />
</S>
<S Name="CreationDisposition">
<C Name="CreationDisposition value" Value="00 00 00 03" />
</S>
</SP>
<SP Name="Win32DeviceIoControl" Procedure="Win32DeviceIoControl" Library="File Utils.dll">
<S Name="HANDLE">
<PC Name="HANDLE" ConditionedName="Win32CreateFile" Parameter="HANDLE"/>
</S>
<S Name="InBuffer">
<B Name="InBuffer value" />
</S>
<SP Name="IoControlCode" Procedure="Win32CtlCode" Library="File Utils.dll">
<S Name="DeviceType">
<C Name="DeviceType value" Value="00000022" Comment="FILE_DEVICE_UNKNOWN" />
</S>
<S Name="Function">
<C Name="Function value" Value="00 00 08 01" />
</S>
<S Name="Method">
<C Name="Method value" Value="00 00 00 03" Comment="METHOD_NEITHER" />
</S>
<S Name="Access">
<C Name="Access value" Value="00 00 00 03" Comment="FILE_READ_DATA | FILE_WRITE_DATA" />
</S>
</SP>
</SP>
<SP Name="Win32CloseHandle" Procedure="Win32CloseHandle" Library="File Utils.dll">
<S Name="HANDLE">
<PC Name="HANDLE" ConditionedName="Win32CreateFile" Parameter="HANDLE"/>
</S>
</SP>
</SC>

About the reported beSTORM “Vulnerability”

A few people asked me about the advisory posted on exploit db (Now also on SecurityFocus) that talks about a security vulnerability in beSTORM, which would be ironic since it’s a fairly simple vulnerability to find by fuzzing, and beSTORM is, after all, a fuzzer.

I always thought security holes in security products were especially funny. You expect security companies to know better, right? Well, as usual, it’s much less funny when it happens to you. Seeing reports about a vulnerability in beSTORM wasn’t amusing.

The thing is, the vulnerability is not in beSTORM, it is not remote, and on top of all – the exploit PoC does not work as advertised. Now comes the second irony: I’ve been on the management team of a security database for the past 14 years, and I’m sure more than one vendor cursed me to walk a mile in their shoes. Well, vendors: I am! Trying to explain to vulnerability databases that just because someone posted something doesn’t mean it’s true, is not easy. But you knew that already.

Now for the details:

The vulnerability described is a problem in WizGraphviz.dll, a graphic library that has been abandoned by its developer. It is not a part of beSTORM, and never was. You could, in early versions of beSTORM, install that DLL in order to view SVG files. beSTORM would have downloaded it on request. But it hasn’t been the case in a while now.

The vulnerability is also not remote. This ActiveX is marked not safe for scripting, which means you have to manually enable it to get the exploit code to run.

In other words, you need to download an ActiveX from the Internet, go into the settings to mark it safe for scripting (and ignore the huge warnings) and then you will be vulnerable to an ActiveX attack when visiting a rogue site. And all this is only true for an old version of beSTORM which is no longer available for download.

Life is full of ironies: This attack is simple enough that we could (should?) have found it by fuzzing this DLL ourselves. Hell, there’s a good chance the good guys that published this advisory did exactly that. For being lazy, we deserve the public flogging. But just to set the record straight, a security vulnerability it ain’t.

 

 

 

Who’s behind Stuxnet?

Stuxnet is a worm that focuses on attacking SCADA devices. This is interesting on several levels.

First, we get to see all of those so-called isolated networks get infected, and wonder how that happened (here’s a clue: in 2010, isolated means in a concrete box buried underground with no person having access to it).

Then, we get to see how weak SCADA devices really are. No surprise to anyone who has ever fuzzed one.

After that, we get to theorize on who’s behind it and who is the target. What’s your guess?

Apple iPhone/iPod Touch/iPad Security Update

Yesterday Apple released a security update that patches the Jailbreakme vulnerabilities to stop people Jailbreaking their Apple devices.

Okay, so maybe I’m looking at this the wrong way around, but it seems that when a vulnerability gets a lot of media attention, Apple work the backsides off to get this one patched. I understand that we are talking serious vulnerabilities here, but still. I’ve personally been in contact with Apple for a couple of months now in regards to a DoS vulnerability that I discovered, and still have no time line on when a patch for this will be released, so maybe all that’s needed is to turn this into some media hype, hmmm.

So the vulnerabilities that this patches are the following:

  • FreeTypeCVE-ID: CVE-2010-1797

    Available for: iOS 2.0 through 4.0.1 for iPhone 3G and later, iOS 2.1 through 4.0 for iPod touch (2nd generation) and later

    Impact: Viewing a PDF document with maliciously crafted embedded fonts may allow arbitrary code execution

    Description: A stack buffer overflow exists in FreeType’s handling of CFF opcodes. Viewing a PDF document with maliciously crafted embedded fonts may allow arbitrary code execution. This issue is addressed through improved bounds checking.

  • IOSurfaceCVE-ID: CVE-2010-2973

    Available for: iOS 2.0 through 4.0.1 for iPhone 3G and later, iOS 2.1 through 4.0 for iPod touch (2nd generation) and later

    Impact: Malicious code running as the user may gain system privileges

    Description: An integer overflow exists in the handling of IOSurface properties, which may allow malicious code running as the user to gain system privileges. This issue is addressed through improved bounds checking.

Where To Sell Software Vulnerabilities/Exploits?

So the last post that I wrote, and Aviram’s follow on post really got me thinking, unless you know where to sell software vulnerabilities or exploits, finding places isn’t really that easy at all. I knew about ZDI and VPC, but that was it really, and it took me ages to remember VPC.

So I spent some time Googling, and well that didn’t help me much to me honest. So I’ve decided to compile a list on here, with a subject that’s easy enough to search for.

So what I’m asking all our readers is that if you know of anywhere that buys software vulnerabilities legitimately, please let me know by leaving a comment and I’ll update the list here accordingly.

So without any further ado, here’s the definitive list of where you can sell those exploits and vulnerabilities that you worked so hard on discovering and writing.

Beyond Security

Zero Day Initiative (Tippingpoint)

Vulnerability Contributor Program (iDefense)

Global Vulnerability Partnership