Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Category Archives: Conference

#DEFCON Defense by numbers: Making Problems for Script Kiddies and Scanner Monkeys

dc-21-logo-smWell, I finally popped my DEF CON cherry and did a presentation at the largest hacker conference in the world… and no I’m not talking about RSA!

Despite my fears of freezing on stage and beginning to drool like a moron, I think the presentation went well. Excluding of course the point where Powerpoint decided it would die in a fire rather than show my next slide. Still, in typical DEF CON fashion there were goons on hand to deliver shots _just_ at the right time to cover the problem. This will forever be known to me now as JITAD (Just In Time Alcohol Delivery).

Hopefully the attendees took something from the presentation that they can use to make their systems a little more secure, or at least the lives of script kiddies a little harder (this is a dream for us right?).

The slides for the presentation are now online (see below), and the video will be uploaded as soon as DEF CON make the release possible.

As always, feedback on the talk, the idea and anything else is gratefully received…

Links:

  • Slideshare –> HERE

BSidesLV: Android Backup [un]packer release

bsideslvlogoAs part of my “Mobile Fail: Cracking open “secure” android containers” talk at BSidesLV I’ve released a couple of scripts I wrote to automate some of the legwork involved in backing up Android applications and automatically unpacking their data and settings. The accompanying script takes the data and settings structure and re-packs it into a working Android Backup file for restoration.

These scripts were used as part of my research to view settings used by applications and in some cases alter the configuration to deactivate secure features or allow access. In some cases it’s also possible to alter configuration files to gain elevated functionality (unpaid… but nobody would ever do that… right!).

The process isn’t new and can be done manually, however automated solutions are always easier…

packer unpacker

Requirements:

  • openssl with zlib support
  • star (apt-get install star)

Simple Python scripts to perform:

  • an adb backup of a specific application and uncompress it to a directory structure
  • recompress a directory structure back into a valid adb restore file

Example usage:

./ab_unpacker.py -p com.app.android -b app.ab

  • Creates an adb backup of com.app.android called app.ab and uncompresses it into ./com.app.android

./ab_packer.py -d ./com.app.android -b app_edit.ab -o app.ab -r

  • Repacks the contents of ./com.app.android into app_new.ab and attempts to restore it via adb

dropbox

Links:

Upcoming BSidesLV and DEF CON presentations

… well, there’s nothing like leaving things to the last-minute. So here I am, sitting at the airport waiting for the first leg of the annual pilgrimage to Vegas (aka Hacker Summer camp), writing a last-minute blogpost to pimp a couple of presentations I’m doing next week.

bsideslvlogo

Thu 18:00 -19:00 – Underground Track (Siena)

Mobile Fail: Cracking open “secure” android containers

We’ve known for some time that physical access to a device means game over. In response we’ve begun to rely more and more on “secure” container applications to keep our private and company secrets… well… secret! In this presentation I will discuss specific design flaws in the security of “secure” Applications that promise to keep your data / password and even company email safe and sound.

Although this research isn’t earth shattering by any means (in my opinion anyway… way to sell it to ya eh ;), I think it provides a few valuable insights into the lack of for-thought put into some Android application security. This research (although still at the early stages) focuses on the security of secure container applications and password databases, and how the secured implemented to secure them on the device does little if nothing to stop attackers with physical or root access to a device. Yes, physical access == game over… but in this case, secure containers have been specifically designed with this event in mind. Pity they didn’t put a little more thought into it!

Applications discussed (time permitting): Dropbox, box.com, Evernote, Spideroak, Lastpass, applock …

dc-21-logo-sm

Sun 10:00 – 10:45 – Track 4

Defense by numbers: Making Problems for Script Kiddies and Scanner Monkeys

On the surface most common browsers look the same, function the same, and deliver web content to the user in a relatively uniformed fashion. Under the shiny surface however, the way specific user agents handle traffic varies in a number of interesting and unique ways. This variation allows for defenders to play games with attackers and scripted attacks in a way that most normal users will never even see.

This talk will attempt to show that differences in how different user agents handle web server responses (specifically status codes) can be used to improve the defensive posture of modern web applications while causing headaches for the average script kiddy or scanner monkey!

Furthering the research presented earlier in the year (BSides London) I will be presenting some interesting edge case notes on how mainstream browsers interpret HTTP status / response codes. I live edge case stuff, just because it’s quirky… so expect a certain amount of off the wall weirdness. Browsers are odd at the best of times, but automated scanners and attack tools are even worse. They love it when they get what they expect… not so much when they get something weird.

This is my first time talking at DEF CON… so come along and let me know what you think. Feedback as always, is desired and well received.

Defense by Numbers: Making problems for script kiddies and scanner monkies

Since early 2012 I’ve been working on a simple theory…

The Theory:

By varying [response|status] codes, it should be possible to slow down attackers and automated scanners.

If you’ve met me at a conference any time in the last year I’ve probably talked about it at length and bored the hell out of you (sorry about that BTW).

After researching a number of aspects of this theory I put forward a presentation for BSidesLondon to talk about my findings and how it might be applied to application defense.

The topic can be a little complex due to the various ways browsers handle [response|status] codes. Even within a specific browser the handling of different content types varies. JavaScript is a prime example of that. Where as a browser will happily show you a webpage received with a 404 “Not Found” code, the same browser may not accept active script content with the same code.

During testing I also discovered a couple of interesting issues with Proxy servers that could be used by attackers to expose credentials… as well as some very interesting browser quirks that are probably only interesting to a handful of people. Still, I like edge-case stuff, it’s weird and that suits me just right ;)

BSidesLondon Abstract

On the surface most common browsers (user agents) all look the same, function the same, and deliver web content to the user in a relatively uniformed fashion. Under the surface however, the way specific user agents handle traffic varies in a number of interesting ways. This variation allows for intelligent and skilled defenders to play with attackers and scripted attacks in a way that most normal users will never even see.
This talk will attempt to show that differences in how user agents handle web server responses can be used to improve the defensive posture of a website. Further examples will be given that show specially crafted responses can disrupt common automated attack methods and cause issues for casual attackers and wide scale scanning of websites

If the topic is something that interests you (and I’m sure there’s a lot more research to be done here) feel free to take a snoop at the slides… The talk was recorded also, so keep an eye on the BSidesLondon website and twitter feed for information on the video/audio release.

 

 

Links:

  • Some thoughts on HTTP response codes –> HERE
  • Privoxy Proxy Aauthentication Credential Exposure [cve-2013-2503] –> HERE
  • mitm-proxy scripts used in testing –> HERE
Follow

Get every new post delivered to your Inbox.

Join 129 other followers