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

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

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.

Microsoft Bug Bounties – Podcast interview with Katie Moussoris

7840.BlueHat_logo

As most people have already read (unless you’re still under that rock), Microsoft made a landmark announcement yesterday regarding its new bug bounty programs. If you’ve not already read about the news I won’t try to rehash what’s already been said (detailed information is available in the links below). However in a case of “right place, right time”, Martin McKeay and myself managed to chat to Katie Moussouris (the driver behind these programs) as part of the FIRST conference podcast series.

Hopefully this open and frank discussion helps to clear up any questions people may have forming about the programs and their effect on the InfoSec community at large. Microsoft always do things in a unique way, and these bug bounty programs are unique in many ways. With more emphasis on defense and really talking about fixing the problems, the programs certainly looks interesting and another step along the path to making things more secure… hopefully

Microsoft’s announced bug bounties:

  • Mitigation Bypass Bounty
  • BlueHat Bonus for Defense
  • Internet Explorer 11 Preview Bug Bounty

The podcast can be found here –> http://media.first.org/podcasts/FIRST2013-Katie-Moussoris-Microsoft.mp3

Links:

{QuickPost} Windows 8 Digital Product Key recovery

Recently I’ve started moving over my lab systems from my old faithful Mac Book Pro to a new Lenovo system. After receiving the new Lenovo and booting into Windows 8 pro for the first time, I did what any sane person would… formatted the thing and installed a usable operating system.

After the usual tinkering period and getting everything setup just right, I turned my mind to setting up the various lab VMs I wanted, and quickly realized that my new Lenovo with Windows 8 pro had no license code. No sticker, nothing in the documentation, nothing on the box. Where the F was that little code I needed to get Windows 8 pro running in my VirtualBox lab.

Well, the answer came quickly… it’s in the BIOS. When you installed Windows 8 it checks for a Digital Product Key (DPK) and uses it. Simple, except I’m pretty sure my VirtualBox VM isn’t going to read the key from my BIOS through a thin layer of virtualized hardware (although I could be wrong on that). So, after digging about on the net and finding a whole load of “if you run Windows just do this” type solutions, I started digging around in my BIOS using a few Linux tools (dmidecode and acpidump).

Although dmidecode gives a nice decoded view of most of the data, it didn’t seem to pick out the information I was looking for (still, interesting stuff). In the end I used acpidump to dump the data and comb through it looking for the MSDM section containing my Windows 8 pro DPK.

Walkthrough

sudo acpidump -t MSDM

This will output the hex and ASCII version of the DPK from your system

DPK_blanked

Enjoy!

Links:

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 120 other followers