Monthly Archives: June 2009

Security 2.0 – Fairy tales and the art of deception

Yesterday, I wrote a post about TwitPic and Twitter.

According to the blog of TwitPic, we can read this:

Yesterday we were made aware of a vulnerability with our email posting system that would allow someone to brute force someone’s Twitpic email PIN by trying every combination until one worked. A fix has been put in place to prevent this from happening.[...]
I want to make it clear that this was NOT a Twitter issue, but a Twitpic issue, and I take full responsibility for it. Once I contacted Twitter about the issue on our end, they worked with us to help remedy any unauthorized postings and they were extremely helpful. Kudos to the Twitter team.[...]
I want to apologize to anyone this has affected and I want you to know that we take security seriously.

The thing is: They still use a 4 DIGITS PIN code. So it means, both Twitter and TwitPic worked on this vulnerability to fix it and both of them are NOT shocked by the 10^4 possibilities of the 4 DIGITS PIN code. It’s getting funnier and funnier.

IMHO, if I should make a comparaison: it is like when a very big vendor fix an integer overflow but forget that the type of the integer is signed.

.. Shame.

Security 2.0 is not even a failure.. It is a nightmare.

Web vulnerabilities are lame and web developpers too. We all know this.

And here is what you can read on @britneyspears twitter.

Basically, TwitPic allows Twitter users to upload + post pictures on their Twitter status. How? You have to login on the TwitPic website with your login+password, then upload your picture and that’s it. According to their Twitter feed they have more than 2 millions users and as you can see they users who own a verified account like @britneyspears with more than 2 millions followers. For your information, a verified account can be recognize by the following icon: d and they have from 10k to 2millions followers.

There is even a feature which allows you to twitt picture from your phone if you mail the following address:

XXXX stands for the PIN code. This is obvious that 4 characters is A HUGE MISTAKE from a security point of view. But the most funny thing is…. this PIN code is 4 DIGITS code. Yes, 10^4 only… I am crying blood. Im crying tears from my eyes that i can’t deny and i am falling like a comet from the broken sky.

#1 This is a shame from a security point of view. This is not even 62^4, this is 10^4.
#2 They store both login + password (either in plaintext or using a reversible algorithm)

By the way, TwitPic is NOT even a departement of Twitter Inc.
If you look at the terms page, it looks the HQ address of TwitPic is that:

Twitpic Inc,7736 Farr St Suite 907, Charleston, SC 29492

which is different from Twitter HQ

Twitter Inc., 539 Bryant Street, Suite 402, San Francisco CA 94107.

Twitter has advanced search feature so it is not really hard to find potential victims
or you can still look what is the client used by Twitter user. You should read something like: “from TwitPic”

According to TwitPic, they are working on it. But the question is: How this kind of vulnerability is possible in 2009? Is that what people call Cloud Computing Bullshit?

We've implemented a fix for the email posting vulnerability, a full blog post explaining the issue will be released soon

We can walk on the moon, we made highspeed trains, people are working on Quantum mechanics AND WE CAN STILL FIND THIS KIND OF VULNERABILITY?

To conclude:

  • To conclude, Web 2.0 is even more than a failure. It shows you how much people can like Britney Spears, or how many of your Facebook friends are stupid enough to send you invitations to join 5 millions people in the “Join this group if you want to change the color of your name of Facebook.” facebook group.
  • People do not care about security and do not even know what does mean this word.
  • A PHP developer can buy a Ferrari writing a 2k lines website.
  • 2009 music industry is a failure.

And we are suppose to improve the way people can use a computer? To change their lifestyle and the world?

Challenge of Windows physical memory acquisition and exploitation

(Honolulu, HW) – Here is a quick post to provide ressources presented this afternoon at Shakacon 2009.
This talks aims at showing to win32dd users (forensics engineers, investigators, incident response engineers, ..) why physical memory analysis is important, and mainly covers how to rethink memory acquisition and exploitation in a more efficient way.

Slides are available here. Not rocket science but very interesting to see how efficient results can be obtained if we put different exciting and performant technologies together.

PowerShell script used to retrieve erased EPROCESS entries from PspCidTable is available here.

hidden process
Figure 1 – Screenshot of the powershell script in action
Magic command (.\FUto.ps1 | Out-GridView)

And here is win32dd v1.2.1.20090608 – If you want more information about the update go here.

PS. Do not copy win32dd in the System32 directory and run it as Administrator. I think I’ll write a HOWTO document soon.

Update: Win32dd (fixes + improvements)

This week Im going to give a talk at Shakacon entitled Challenge of Windows physical memory acquisition and exploitation — then I think it’s time to release a new version of win32dd.

Two major bugs fixed in this release are:

      System cache size was growing because the output file was mapped, then it filled the memory with a lot of junk pages. Current version of mdd and Memoryze have this problem too. Thanks to Marnix Kaart (Nederlands Forensisch Instituut) and Tomo Koida (National Police Agency of Japan) for the bug report.
      The output size for raw dump file only was wrong. Instead of using the size of the physical address space, win32dd used the size of the physical memory which is totally different. Current version of mdd also has this problem and Memoryze forget to save one page.

This version also fix a minor bug in the driver loading process, some people experienced problem to load the driver a second time when they interrupted it through Ctrl+C keyboard shortcut.

This version, as you can see on the screenshot, provides further information about memory state, memory dump, and the machine.

And now, win32dd also supports hashing (SHA1).

Your feedback is welcome if you want me to introduce new features or to improve win32dd. Feel free to share your experiences etc.


Download win32dd v1.2.2.20090608 now!

Update: Rob Lee announced (via Twitter) win32dd is “is the tool of choice in the SANS Forensic courses for obtaining memory.”
Update 2: Rob will also discuss about court-approved tools during the SANS Forensics Summit 2009. (via Twitter)

Undocumented Windows Vista and later registry secrets

In fact, this new key category appearred for the first time in Windows XP, formely called Whistler, in early 2001. Yes, almost 9 years ago. But its structure CM_BIG_DATA had been removed from Microsoft Windows XP public symbols but not from Windows Vista and later symbols.

Basicaly, this “secret” registry key had been briefly introduced in Windows XP Kernel Enhancements changelog as the following:

Windows XP improves the way the registry handles big data. In versions before Windows XP, if an inefficient application constantly increased a value with a small increment, it created a sparse and wasteful registry file. Windows XP solves this problem with a big cell implementation where cells larger than 16K are split into increments of 16K chunks. This reduces fragmentation when the data length of a value is increased within a certain threshold.

If we take a closer look to CmpGetBootValueData() or CmpGetValueData() functions which handles big data keys we can notice CMHIVE.Version must greater or equal to 4. I guess, this is the Whistler registry version.

To be validated as big data key pointer, CM_KEY_VALUE cell must respect the following conditions:
– CM_KEY_VALUE.DataLength must be greater than 0x3fd8 and smaller than 0x80000000

Then CM_BIG_DATA key first chunk is retrieved using CM_KEY_VALUE.Data as cell offset.

To be validated as big data key, the CM_BIG_DATA cell must respect the following conditions:
CM_BIG_DATA.Signature must be equal to 0x6264 (“bd”)
CM_BIG_DATA.Count must be greater than 0
CM_BIG_DATA.List must be different from 0

According to these information Windows do assinity check to avoid buffer overflow and re-compute CM_KEY_VALUE.DataLength for assinity check like the following:
ASSERT(CM_KEY_VALUE.DataLength < = (CM_BIG_DATA.Count * 0x3fd8))

Then, each CM_BIG_DATA.List entry are read CM_BIG_DATA.Count times as cell index, and 0x3fd8 bytes maximum are copied each time into the output buffer.

It means data chunk are not exactly 16K bytes (0x4000) but 0x3fd8. The difference of 0x28 bytes is in fact the cell header.

If you want to read further information about Windows Registry format, I suggest you to refer to Tim Morgan, Peter Norris documents and moyix blog.