...stuff I do and things I like...

Conferences

Infiltrate has Joshua J. Drake: Researching Android Device Security with the Help of a Droid Army

IEEE Security and Privacy (academic) has a number of papers: Upgrading Your Android, Elevating My Malware: Privilege Escalation Through Mobile OS Updating; The Peril of Fragmentation: Security Hazards in Android Device Driver Customizations; From Zygote to Morula: Fortifying Weakened ASLR on Android

ReCon has The Making of the Kosher Phone by Assaf Nativ (CFP not complete yet)

Hack in the Box Amsterdam has Shellcodes for ARM: Your Pills Don't Work on Me, x86; Exploring and Exploiting iOS Web Browsers; State of the ART: Exploring the New Android KitKat Runtime; On Her Majesty's Secret Service: GRX and a Spy Agency (HITB folks fix your website, finding talks and speakers is sooo hard I almost do not bother to do it - worst conference website I know!!)

ASIA CCS (academic) has a number of papers: Timothy Vidas, Nicolas Christin: Evading Android Runtime Analysis via Sandbox Detection; Collin Mulliner, William Robertson, Engin Kirda: VirtualSwindle: An Automated Attack Against In-App Billing on Android; Min Zheng, Mingshen Sun, John C.S. Lui: DroidRay: A Security Evaluation System for Customized Android Firmwares; Wenbo Yang, Juanru Li, Yuanyuan Zhang, Yong Li, Junliang Shu, Dawu Gu: APKLancet: Tumor Payload Diagnosis and Purification for Android Applications

Heartbleed and Mobile

Heartbleed and Android [1] I couldn't find any detailed discussion of Android itself or Android apps being vulnerable to the heartbleed attack. Sure some apps are linked against vulnerable versions of OpenSSL but I couldn't find any attack description. If you know anything specific please email me!

Checkout reverseheartbleed.com a heartbleed testing service for clients software (e.g., web browsers).


SMS bulk operators vulnerable to heartbleed, leak 2FA tokens see heise.de (in German)

Links

Samsung S5 fingerprint reader hacked

An Exploration of ARM TrustZone Technology

Personal notes

I'll be speaking at Duo Tech Talks in Ann Abor, MI (this will be a IoT related talk).

I'm on a panel about Internet of Things security at The Security of Things Forum in Cambridge, MA.

Mid-End of May I'll spent some time in the Bay Area for IEEE S&P, with plenty of time afterward to hangout.

I'm also planning to go to ToorCamp, who else is going?

Update 2:

I scanned Tor starting Friday April 11th and ended Sunday April 13th. I stopped cause I got enough evidence on leaked plain text. I wasn't sure what to do with the data so I was sitting on it for a couple of days but than decided to just blog about it.

Update:

Tor doesn't have too many exitnodes, the nodes I was testing are Tor nodes in general not only exitnodes. Never the less I found a number of vulnerable exitnodes that leak plain text data.

The Tor Project has started to black list vulnerable nodes.

Tuesday April 7th I started my own investigations of the Heartbleed issue. In this blog post I want to talk about one of the things I've been looking into that is the effect heartbleed has on TOR. TOR heavily uses SSL to encrypt traffic between the various TOR nodes. TOR was obviously vulnerable as reported by the TOR project.

For my investigation I pulled a list of about 5000 TOR nodes using dan.me.uk. Using one of the many proof-of-concept exploits I scanned the TOR nodes to determine if they are vulnerable. I found 1045 of the 5000 nodes to be vulnerable to the heartbleed bug, that is about 20%.

I briefly checked the leaked memory to determine if plain text is leaked that is related to TOR user traffic. Yes, TOR exitnodes that are vulnerable to heartbleed leak plain text user traffic. You can find anything ranging from hostnames, downloaded web content, to session IDs, etc.

The majority of the vulnerable TOR nodes are located in Germany, Russia, France, Netherlands, United Kingdom, and Japan. The TOR network has more than 5000 nodes so this is not a complete picture but it provides a good overview of the possible number of vulnerable exitnodes.

The heartbleed bug basically allows any one to obtain traffic coming in and out of TOR exitnodes (given that the actual connection that is run over TOR is not encrypted itself). Of course a malicious party could run a TOR exitnode and inspect all the traffic that passes thru it, but this requires running a TOR node in the first place. Using the heartbleed bug anyone can query vulnerable exitnodes to obtain TOR exit traffic.

There are a number of possible solutions for this problem. 1) update vulnerable TOR nodes (hopefully in progress), 2) create a blacklist of vulnerable TOR nodes and avoid them, 3) stop using TOR until all nodes are updated.

Further Steps:

Scan all TOR exitnodes to create a black list of vulnerable nodes so users can avoid them.

Notes:

One interesting thing I found is the large number of requests that seem to be originating from malware due to the domain names looking like the output of a DGA.

Links:

Heartbleed
Heartbleed disclosure timeline: who knew what and when