HTC launches htcdev.com

Yesterday HTC launched a new developer portal at www.htcdev.com.

HTC announced the following: "Our developer portal went live today! Currently on HTCdev.com you can check out an early access version of the OpenSense SDK for the 3D display on Evo 3D, the Tablet Pen used with HTC Flyer and also download kernel source code for HTC Android devices with even more to come. The site is also the future home of bootloader unlock process. Check it out!"

This means that the kernel sources for the HTC Evo 4G running Android 2.3.3 are now available for download and the workaround in my previous post is no longer needed.  Hopefully HTC keeps their kernel sources up-to-date with this new site.

The other intriguing part of the announcement is the HTC promises a web tool that will unlock the bootloader on HTC devices. So how will this work? "The Web tool, which will launch this month, requires that you register an account with a valid e-mail address and accept legal disclaimers that unlocking may void all or parts of your warranty. Then plug in your phone to a computer with the Android SDK loaded to retrieve a device identifier token, which you can then enter into the Web tool to receive a unique unlock key via e-mail. Finally, apply the key to your device and unlocking will be initiated on your phone."

While I applaud HTC for making it easier for anyone to unlock their bootloaders (which means trivial rooting, custom kernels, and awesomeness), I think it's pretty lame that HTC will require disclosure of personal identifiable information and a voided warranty to use the tool.  I'll be interested in seeing exactly what information HTC collects.

Compiling custom kernel modules for HTC Evo 2.3.3 Gingerbread

Some of my current research on Android forensics and security requires the loading of custom kernel modules.  In my previous post I detailed the steps required to compile and load custom modules on a rooted phone.  I recently updated my rooted Evo to Android 2.3.3 Gingerbread and was frustrated to see that HTC has yet to release the updated kernel source code.

Using an adb shell I can see that the phone is running linux kernel 2.6.35.10.

joe@zuul:~$ adb shell
# uname -a
Linux localhost 2.6.35.10-gc0a661b #1 PREEMPT Tue Jun 14 23:58:32 CST 2011 armv7l GNU/Linux

Luckily, HTC has released the Gingerbread kernel source for another phone, the Desire HD, which runs the same kernel version.  Assuming that the the kernels from the two phones would be very similar, I tried my hand at compiling the module for my Evo with the Desire HD source.  It worked!

To compile a kernel module for the Evo with the Desire HD kernel source requires a few extra steps:

• Download and unpack the Desire HD source code.
• Modify Makefile at the root of the source.  Change line 4 to read: EXTRAVERSION = .10-gc0a661b
• Follow the steps outlined in my previous post to export the config from the Evo, prepare the kernel sources, and compile the custom module

These steps worked for my phone and my module, but your mileage may vary.  It is unlikely that the kernels running on the two phones are identical, but hopefully the sources are similar enough to allow the functionality of your custom modules to work.  Of course HTC will eventually release the official kernel sources for the Evo 4G, but it's anyone's guess when that will be.

UPDATE (8/9/11):// HTC has released the EVO 2.3.3 GB Kernel sources.  See this post for details.

Phishing Web-Based Email Services with HTML5

Abstract: This paper presents a novel approach to phishing using the programmable session history stack introduced in HTML 5. The technique is implemented and tested against a sample of 100 Gmail users and 100 Yahoo Mail users. In this preliminary testing the technique has shown to be effective against approximately 9.5% of recipients.

Introduction

As the internet is becoming more ubiquitous and browsers are becoming more powerful, more and more people are moving away from traditional native applications and are doing most of their computing in the web browser.  Google recently released its CR-48 Chrome notebook, a laptop whose only operating system is the browser itself and which has no native applications.

Web-based email applications are also increasing in popularity.  Many are moving away from applications, such as Microsoft Outlook and towards web services such as Google's Gmail, Microsoft's Hotmail, and Yahoo's Mail.  Most websites utilize email as a means of identity control, allowing users to reset their passwords by clicking on a reset link that is sent to them in email.  This makes access to a user's email address desirable for hackers and identity thieves.

HTML 5 is the latest standard (in progress) for the markup language most commonly used for building content on the web.  HTML 5 introduces many powerful new features, which allows developers to build more powerful and useful web-based applications.  One of the new features in HTML 5 is the addition of a History Interface, which allows programmatic manipulation of the session navigation history.

In this paper I present a new phishing technique, which uses the HTML 5 History Interface to trick users into giving an attacker their email credentials.  Users will receive a link in their email to a harmless looking website.  When the website loads, a fake entry will be added to the session history.  If the user clicks the "Back" button in the browser they will be given a fake version of their web-based email application asking them to re-enter their password.  This attack will take advantage of the fact that, since the link was sent to a web-based email service, the attacker can guess what the previous page looks like.  It also takes advantage of the fact that users may implicitly trust a website that appears to be the page the navigated from, after clicking the back button.

The full paper can be found here.


Keywords: phishing yahoo mail, phishing gmail, html5, html 5 history interface

Linux CAP_SYS_ADMIN to root exploit 2

I've released my first Linux kernel exploit.

Guide to Compiling Custom Kernel Modules in Android

I've spent the better part of today trying to figure out how to compile and load a custom kernel modules in android to aid me in my research.  It has been in entirely frustrating experience, as there is almost no documentation on the topic that I can find.  Below you will find my attempt at a guide.  Hopefully this will help save someone else the hassle.

PREREQUISITES

Disclaimer:  This list may be incomplete, since I've not tried it on a fresh install. Please let me know if I've missed anything.

• Install the general android prereqs found here. 
• Download and un(zip|tar) the android NDK found here.
• Download and un(zip|tar) the android SDK found here.
• Download and untar the kernel source for your device.  This can usually be found on the website of your device manufacturer or by a quick Google search.
• Root your phone.  In order to run custom kernel modules, you must have a rooted phone.
• Plug your phone into your computer.

PREPARING YOUR KERNEL SOURCE

First we must retrieve and copy the kernel config from our device.

$ cd /path/to/android-sdk/tools
$ ./adk pull /proc/config.gz
$ gunzip ./config.gz
$ cp config /path/to/kernel/.config

Next we have to prepare our kernel source for our module.

$ cd /path/to/kernel
$ make ARCH=arm CROSS_COMPILE=/path/to/android-ndk/toolchains/arm-eabi-4.4.0/prebuilt/linux-x86/bin/arm-eabi- modules_prepare

PREPARING YOUR MODULE FOR COMPILATION

We need to create a Makefile to cross-compile our kernel module.  The contents of your Makefile should be similar to the following:

obj-m := modulename.o
KDIR := /path/to/kernel
PWD := $(shell pwd)
CCPATH := /path/to/android-ndk/toolchains/arm-eabi-4.4.0/prebuilt/linux-x86/bin
default:
$(MAKE) ARCH=arm CROSS_COMPILE=$(CCPATH)/arm-eabi- -C $(KDIR) M=$(PWD) modules

COMPILING AND INSTALLING YOUR MODULE

$ cd /path/to/module/src
$ make
$ cd /path/to/android-sdk/tools/
$ ./adb push /path/to/module/src/modulename.ko /sdcard/modulename.ko

RUNNING YOUR MODULE

$ cd /path/to/android-sdk/
$ ./adb shell
$ su
# insmod /sdcard/modulename.ko

CONCLUSION

Ineviditibly you'll run into some errors that you will need to sort out, as I did with both my droid 2 and evo devices.  Feel free to post in the comments if you run into any major problems, and I'll try my best to help you out.

FrozenCache Woes

There was a talk given very recently at 27c3 that I was very much looking forward to.  Juergen Pabel gave a talk about his ideas on mitigating cold boot attacks on cryptographic keys.  Since cold boot attacks are possible due to flaws properties of physical hardware they remain a largely unsolved problem.

Pabel's idea is that you can store sensitive data, such as keys, in the CPU's cache, disable cacheing, and zero the data from memory.  This should leave us with the key stored in a usable state in the CPU.  It's a good concept, but unfortunately it doesn't seem to be much more than a concept at this point.

Not surprisingly, CPUs have caches for a reason and when they are disabled, performance suffers.  In Pabel's demo, he was running what seemed like nothing more than a terminal to enable and disable his proof-of-concept and even that was painfully slow.  I realize that Pabel was not presenting a full solution, and I know how far from complete many POCs are, but I'm not sure how much optimization can actually be done.

x86 processor's simply weren't designed for this sort of cache abuse.  They don't offer enough control over the cache for this method to really be feasible.  There are no obvious ways to disable only the parts of the cache of our choosing, and no way to prevent others from flushing the cache and either destroying our sensitive data or dumping it to RAM.

What we really need is a hardware-tailored solution to this problem.  I think there is a need for a dedicated piece of hardware, either built into the CPU or with fast access to it, that could be used as forensically secure storage for sensitive data.  Similar solutions seem to work reasonably well in consoles (unless you are into epic math fails like Sony).

Overall, cold boot attacks aren't a huge problem, since they require physical access to pull off, but with an increase in government asshat-ery at airports it would be nice to have a solution.

UPDATE:// Juergen was kind enough to address my concerns in the comments.  Read on.

New Years Resolution #2: Password Policy

They say there's a syndrome in medical school where med students become temporary hypochondriacs and think they have symptoms of every disease that they study.  Graduate school may be having a similar effect on me, but hopefully in a more productive manner.  However, it's been said that "just because you're paranoid it doesn't mean they're not out to get you" so I've decided to greatly improve my password policy in 2011.

In the past I've had 3 or 4 different passwords of varying strength that I've used for pretty much everything.  That's better than most people (most people only have 1 password for everything), but it's still pretty stupid from a security standpoint.  If one or more of those passwords were ever compromised (and trust me, I'm sure they have been at one point or another), then the attacker (or ex-girlfriend) would have access to pretty much everything they'd need to own me.  Think about how much information you have out there.  Between email, IM, facebook, twitter, banking, bills, student loans.. It's pretty scary.

In 2011 I'm adopting a new policy: unique and reasonably-secure passwords for each and every service.  I'm talking about passwords like this:

,H!i43/%]I.3{X#TT"Z2/e%IL

Don't use that as your password, BTW.  Since it's posted on the internet, it's no longer secure.

Having long, random passwords that are unique for each service is really the best way to protect your data.  Not don't get me wrong,  passwords suck as a form of authentication by themselves, but it's what we're stuck with for the time being, so it's best to make them as strong as possible.  A hash of the password above would not be found in a dictionary attack.  It would take an unreasonable amount of time to crack with a rainbow table or brute force method.  It is, however, very difficult to memorize a password like that for every service used.  That's where the tools come in.

By using a combination of KeePass, KeePassX, and KeePassDroid I am able to access an encrypted database of all my passwords on all of my devices.  I use Dropbox to securely sync my password database among my devices.

KeePass allows me to generate, store, and organize secure passwords for all of my services.  It also allows me to copy my passwords to the clip board, so I can log into services without having to manually type the complected passwords.  I do try to copy something else to the clip board after logging in, however, so that my password isn't lying around in memory.

Hopefully, this new system will help better secure my data in 2011.  Are there any problems with this scheme?  What is your password policy?