Chris Paget's Blog

To repeat what I said on Twitter, it’s somewhat pointless but a neat hack nonetheless – running a GSM base station from a CDMA handset. With minimal work it’s possible to get gnuradio and OpenBTS working on the ARMEL architecture used on the Droid, allowing my Droid to act as a base station to which handsets can connect; the Droid then connects calls using an on-board Asterisk server and routes them to the PSTN via SIP over Verizon’s 3G network.

The quick version: I can provide voice and SMS connectivity to local GSM handsets using nothing but a Droid and a USRP.

A quick log of what you’ll need to replicate this. This is from memory so I may have missed something; fortunately there’s an easier way that I’ll come back to.

- Root the Droid and install Sholes Mod.
- Mount your SD card in a desktop machine and create an EXT3 partition. I shrank the FAT32 partition but left it otherwise intact, this is probably a good idea if you want to still take pictures.
- debootstrap into the new ext3 partition, bearing in mind the new architecture (use the two-stage debootstrap with –foreign)
- Put the SD card back in the Droid, and mount the EXT3 partition (you’ll probably need to manually insmod the ext3 and jbd modules)
- “mount -o bind” all of the system filesystems into the mounted EXT3 environment (including /dev, /dev/pts, and /sys)
- Mount usbfs in the mounted filesystem at /proc/bus/usb (if you don’t it won’t find the USRP)
- chroot into the new Debian environment, and debootstrap –second-stage
- Go get dinner – it’ll be a while
- Install all the usual dependancies for building gnuradio (if you can’t figure this out on your own you’re in the wrong place!)
- Configure gnuradio with ./configure –disable-all-components –enable-usrp –enable-omnithread –enable-mblock –enable-pmt
- Patch for 52MHz clock (I highly doubt that Droid can handle the stock 64MHz clock)
- Patch the gnuradio makefiles for ARMEL
- Build gnuradio (again, it’ll be a while)
- Install libosip2-3.3.0 from source (the Debian package is out of date)
- Download and ./configure the openbts source, but don’t build it
- Apply the same makefile patch in Transceiver/ and Transceiver52M/ (or you’ll get the same build error)
- Build OpenBTS
- Install Asterisk (from the debian packages is fine)
- Configure as you wish, then connect the USRP (via a powered hub) in Host mode and have fun!

The easier way that I mentioned before would be for me to just zip up an image of my SD card and slap it on a fileserver somewhere public – I’ll also include some scripts to mount it and start everything up correctly. Give me a few days to clean it up and watch on Twitter for the link, it should be as simple as dropping 2 files on the SD card and then running one of them as root.

I’ll also post video of the Droid connecting a call (that sounds far less cool than it should) at some point, I’m also considering running a workshop on all of this if there’s any interest…?

I know I’m supposed to be writing up the OpenBTS thing (it’s coming) but this was a quick thought that I had to get out in the meantime.

I hear a lot of people talking about PCI, discussing whether or not it actually does anything for security, whether it was a move on the part of the card issuers to improve security or simply shift liability, about the strengths and weaknesses of the protections it provides. Almost invariably, these conversations completely miss the far larger issue in credit card security. PCI is nothing but a distraction, a shiny thing to wave in the faces of infosec’ers, execs, and politicians alike, trying to distract them from the bigger issue.

The bigger issue is this – credit cards are broken. The very concept of a “credit card” as it exists today is as fundamentally broken as anything in Infosec has ever been.

Let’s think like infosec professionals for a second here instead of like consumers. Your credit card is a token, one that is used to:
- Prove your identity to the merchant
- Confirm your intent to process a transaction
- Identify your source of funding

We have many protocols that can do all of this and more with a high level of security, it’s trivial to name half a dozen. None of them require you to give your full plaintext credentials to a third-party – although that’s exactly what happens every time you use your credit card. You have to give every merchant a complete list of every bit of information that is required to process transactions against your account – or else they can’t process the transaction. Those credentials remain static for several years, by design being given to several thousand anonymous strangers (known only by their participation in the system) over their lifetime. Multi-year credentials for financial authorization that are, by design, shared with any participant in the system. Does this sound broken yet?

Seriously, why are we still using credit card numbers? Why don’t we have smartcards containing a megabyte of pre-programmed single-use card numbers (that’s a LOT of card numbers!) that we pull up once and throw away? Or some kind of signature algorithm, put a public key on the card and sign the transaction electronically? Or secure tunnels between the card and the processor backend (hell, even between the terminal and the backend)?

Why is it so trivial to spoof our most commonplace payments system when there are such obvious examples of ways to fix it? Why, in short, do we still have credit card fraud?

PCI, no matter what its strengths and weaknesses are, is a band-aid on a festering gangrenous wound. It’s a shiny pink band-aid with a little bit of sparkle to distract us all, but it’s nothing compared to the fundamental brokenness of our credit card infrastructure. We need to stop blaming merchants and consumers for failing to protect a set of data with a process that is inevitably doomed to failure, and instead start blaming the credit card companies for failing to produce a payment vector that is compatible with the security requirements of the 21st century.

We stopped using plaintext protocols for sensitive information decades ago, for good reason. Think about that the next time you swipe your credit card.

I’ve had a few days hacking on the Droid now (with some fun results that I’ll write up in a separate post in a moment), but I wanted to get back to a few things on Host mode USB first.

Firstly, adapters: these should work (3 links) to convert the Droid’s b-only socket to the correct A socket. Be careful of devices like this which will probably not work since the Droid has a Micro-B connector and that cable requires a Micro-A socket.

Next up, I’ve had a few folks ask for a review of the Droid comparing it to my G1. I’ll keep it quick – the screen and touch-response are far better, as is the keyboard, audio jack, speakers, CPU, and standard SD card (16Gb). It bugs me that there’s no pipe character on the keyboard (it is, after all, a *nix box), I don’t like the joypad mouse replacement and it bothers me that I have no cables or chargers for Micro-USB which is now the standard – all those Mini-USB dongles you’ve accumulated will soon be worthless. Whatever I think of it though I’ll forgive its flaws just purely because it supports USB host mode, even if the drivers are buggy as hell

Speaking of bugs, some workarounds and other notes:
- A powered USB hub is very handy if you’re playing with host mode. You can add and remove devices from the hub and as long as the hub stays plugged into the socket it all continues to work. Self-powered is good because the Droid can’t supply much power, although optionally-powered will also work because the Droid can supply small peripherals such as keyboards, mice, and small hubs.
- I was talking this all over with Mike Baker and it seems that the only reason you can’t switch the port back and forth between host mode and peripheral mode is because the gadget driver locks it – this is the driver that provides such things as ADB. If you prevent that driver from loading you should be able to switch back and forth by poking the right value in /proc/. Haven’t confirmed this yet but it sounds plausible.
- There’s an odd signal coming out of the power line on the Droid’s USB port if you shut the device down in host mode. The +5v drops to about +3.3v with about 0.5v of signal modulated on top. It’s definitely a signal (it responds to button input) and this is after the device has been powered down. Mike was going to investigate further and I’m planning to write a PIC decoder for it as well, so we’ll see where it goes – ideas for the signal source would be useful (I’ll post traces soon).
- If your USB peripherals just stop working at any point check for crash logs in dmesg. The driver does crash regularly, it doesn’t cause a kernel panic but does require a reboot to get the port working again.

The big fun (at least in my eyes) is the fact that I now have a working GSM base station running on my Droid. Watch this space for a howto coming up soon…:)

Yes, it’s true – Android (at long last!) has access to USB Host mode. I had been waiting for this to happen on the Nexus 1 or N900 some time soon, but as it turns out it’s the Droid that takes the crown. It’s a neat little hack that I heard about at Shmoocon; I’d like to thank to Mike Kershaw from Kismet and Mike Baker from OpenWRT for sharing Here’s how it works.

The USB hardware on the Droid is actually capable of USB-OTG (meaning that it can act as both host and peripheral), however it only possesses a standard USB Micro-B port instead of the Micro-AB port that you would normally get from an OTG device (such as the N810). With a minimal amount of effort (and tolerance of a few bugs) it’s possible to enable the B port as a host interface (as OTG says you should be able to do), meaning it supplies power and acts as the bus controller. It’s actually pretty easy; I can easily think of about a hundred million ways to make this useful on the Droid (think: plug any USB hardware you like into your Droid, as long as it works in Linux it should work in Android).

You’ll need to make two things, a micro-dongle to enable the port (you plug it in during boot time) and a cable with the right connectors on each end (for connecting your peripheral). To do this you’ll need three cables:
- A car charging cable (off-the-shelf at the Verizon store)
- A Micro-USB cable (as above)
- A USB extender cable (the teeny ones that sometimes come free with USB keys work great)

Start with the car charging cable. Break open the micro-usb connector (it comes apart fairly easily) and look at the little PCB inside – there should be a single tiny surface-mount resistor and two wires from the charger cable. Unsolder both wires and the resistor, and then bridge the pads where the resistor used to be so that it’s completely shorted. The end result should look something like this:

This is your micro-dongle.

Next up, you need to make your connector cable. Cut the end off the USB extender cable, you want to keep the socket end and discard the plug. Cut the micro-usb cable as well, but on this one you want to keep the plug and discard the socket. You should now have a micro-usb plug that’ll fit into your droid and a usb socket that you could plug a memory stick into. Strip the wires off the ends of both cables and join them to each other, connecting like colours (and the shield) together. When it’s finished it should look something like this:

(You’ll obviously want to insulate the wires afterwards, this is just to show how the colours are connected).

You don’t even need to root your droid in order to verify it works (although I rooted mine using the instructions here anyway), just do the following:
- Turn your Droid off
- Plug the micro-dongle into the USB port
- Turn the droid on
- Unplug the micro-dongle as soon as the Motorola logo disappears (as the Droid lodo is appearing).
Once your Droid is booted, pull up a terminal and look at dmesg – after plugging in your USB peripheral using the cable you made earlier you should see the usual kernel notifications about new USB devices being connected; they’ll also turn on (or start charging) if they’re powered by USB. You’ll only be able to plug in one peripheral before the port reverts to peripheral mode; you’ll have to reboot with the micro-dongle if you want to go back into host mode. Also, if you leave the micro-dongle plugged in too long it triggers another bug, the port gets stuck supplying power to devices but not actually recognising them. Hopefully the drivers are sufficiently open-source that these are easy bugs to squash, and that dynamically switching between host mode and peripheral mode won’t be too hard to add either.

Unsurprisingly there’s not much driver support for USB peripherals in the standard Android kernel (I couldn’t mount a USB key for example), but it’s easy enough for the ROM developers to start adding drivers – I’ll be flashing Sholes shortly to see how it does. Expect to see a whole new generation of Android hackery to start soon

//edit: Andrew de Quincey has apparently also gotten Host mode working on the Hero, and pointed out that while the stock Android kernel may not support USB storage it does support USB keyboards. Plugging one into my Droid using the steps above, it Just Works. It’s kinda nice to have a proper keyboard on a cellphone…:)

I’ve decided that the start of a new decade is a good opportunity to come clean about a couple of things and to try a slightly new approach to life. Anyone who’s met me in person probably already knows about my taste in footwear (this being a great example – that’s me on-stage at CCC a few days ago, the photo really doesn’t do justice to the glitter). There’s a lot more to it than just the shoes though, and I’ve decided that it’s time to stop living to other people’s expectations / prejudices and live life on my own terms instead.

What does that mean? Well, first and foremost I completely reject the notion of binary gender. “Male” and “female” aren’t opposites, they’re extremes. There’s a whole roller-coaster of variation between them (it’s certainly more complicated than a simple spectrum!), and the idea of trying to fit myself into either stereotype really doesn’t work. Sure, I’m biologically male, but for a long time I’ve regarded myself as mentally female; I’ve come to the conclusion that it really doesn’t work for me to try to be one or the other. I value my ability to switch back and forth as my mood dictates, and that means that how I present myself to the world switches back and forth as well. Some days I want to wear a pretty dress and sparkly jewellery, other days I want to be big, male, and intimidating. Why commit to one or the other fulltime when I can have both?

So, the upshot of all of this is that I’m going to be a little more expressive with my gender identity. Whether I’m “male”, “female”, or (more likely) riding the rollercoaster between the two, I’m not going to let fear of other people’s reactions temper how I express myself, the one obvious exception being client meetings. It’s not a great idea for small startups to bite the hands that feed (or mess with their heads, as the case may be), but outside of that I’m going to just be me, whatever that entails.

Male? Female? Psshhh. It’s way more fun to make it up as you go along

Finally getting around to moving some of my web content across to a new server. It’s been smooth sailing so far but feel free to let me know if anything looks broken…

Noisebridge: www.noisebridge.net
Proxpick: www.proxpick.com

I wanted to let everyone know that we’ve finally gotten the ProxPick
into a form that we’re now prepared to share, so Karsten and I will be
hacking on it tomorrow at Noisebridge from about 2pm onwards. We’ll be
there until the wee hours most likely so feel free to join us any time
you can.

We’ll have schematics and source to share as well as enough parts to
build at least a few working prototypes; if anyone’s interested in
helping us with the final hardware tweaks and firmware development
before we get the first batch of boards made up, please come along.

Hope to see you tomorrow!

So our old friend SSL has been broken again. I’ve had a little more time to chew on this than most, and a few thoughts have occurred to me.

Firstly, let’s talk about its implications for HTTP.

Assuming all the conditions are right (and we’ll get back to that) at best it allows an attacker to inject an arbitrary request into an SSL-protected stream. It does not allow you to decrypt data, it does not allow you to read any information back, it does not allow you to inject into the returning stream of data.

Here’s the thing – I can already do that. Watch:


<html>
<body onload="document.pwned.submit()">
<form method="post" name="pwned" action="http://www.arbitrary.com/some/path/here">
<input type="hidden" name="parameter1" value="value1">
<input type="hidden" name="parameter2" value="value2">
</form> </body> </html>


(This works so well that when I first previewed this post I ended up at a 404 on /some/path/here from arbitrary.com…)

Hey look! I can make you submit an arbitrary POST request to any location on the internet! No SSL / TLS trickery needed, just click on my link. Your browser will automatically fill in the cookie (meaning that the request will be authenticated) and you’ll submit the nastiness for me. It’s called Cross-Site Request Forgery, it’s been around for a long time, and it’s well-known and well-defended against by anyone who knows about such things (the key is to use a nonce in the original form – google is your friend).

It’s not a big deal for HTTP. The only ways to even trigger it require any of:

1: A client certificate being actively used (at the choice of the user)
2: An odd per-directory configuration of SSL/TLS cipersuites (a problem for shared hosting, sure, otherwise what I would regard as broken behaviour from IIS)
3: Other uncommon but possible circumstances.

It’s not a big deal for the majority of HTTP users, and there’s probably going to be good workarounds for it all in the coming days (expect some creative solutions – I plan to follow along if only to learn more about the internals of SSL).

Here’s the problem. SSL stands for “Secure Sockets Layer”, while TLS stands for “Transport Layer Security”. These protocols are designed to offer a layer of security – a universal “comfort blanket” to anyone who cares to implement them, something they can trust to do all the security heavy-lifting so they don’t have to. It’s a reasonable approach, and SSL / TLS is a good choice for doing so if it’s properly implemented.

The problem is that it’s not always properly implemented, and neither are the protocols that it protects. We may not have too much of a problem for HTTP, sure, but what do you think about SQL? An attacker who has the ability to inject a single arbitrary-length request into a stream of SQL queries and responses would be *devastating*. How about the thousands of different software update mechanisms out there that depend on SSL being secure in order to function? This is a protocol-level breach, one that requires a modification to the way that SSL & TLS function in order to repair. In other words, your implementation of SSL can be *completely* compliant with the protocol, *completely* immune to code-level vulnerabilities, *completely* fine at managing its keys, and using ciphers that are *completely* unbroken, and you are *still* vulnerable.

This is one of those bugs that will be biting us in the ass for a long time to come. Expect to see tools that exploit this weakness across a wide variety of protocols (what could you do with IMAP/S or POP3/S?) and a wide variety of devices, a hurried fix that isn’t-quite-thought-through by a lot of folks (and will have lots of implementation problems even if the protocol itself is secure), and some huge and far-reaching implications for the security of a whole lotta systems.

Just like Null-prefix certificates.
Just like DNS flaws.
Just like BGP.

Anyone who says this isn’t a problem simply doesn’t get it. It’s not a huge problem for HTTP (although I’m prepared to be proven wrong on that one, mail me if you have a PoC) and there will no doubt be some widening of the scope of this flaw once more eyeballs see it, but there’s a whole lot more than HTTP that gets protected by SSL.

Fun.

Wow, it’s been a while since I was last here. Alienware was finally resolved (I got the drive I wanted then decided the machine was altogether too flimsy for business travel anyway and bought a superb Dell), Defcon happened (google news can give you the details), and my company is now officially launched and running. Lots going on, not enough time, yadda yadda.

Anyway, I finally got around to installing Windows 7 and decided that I finally had something worthy of blogging. I normally tweet my random thoughts but this one won’t fit 140 characters, so here I am. Here’s the thing – after 5 minutes with Windows 7 I have decided, once and for all, that I will never voluntarily use another Microsoft product.

Let me be clear first of all – I have absolutely no problem whatsoever with the security of Windows 7. I was deeply involved in the Vista security review (source code access, interviewing developers and PM’s, threat modeling, etc) and saw far behind the curtain at Microsoft – the best description I can give of the experience is the H. P. Lovecraft quote which we had printed on the back of our “Windows Vista Pentest Team” shirts: “Searchers after horror haunt strange, far places.”. There’s some real nightmares in there, but although I was not involved in the Windows 7 review I have confidence in its security. I know the team, I know the processes that were already mature after Vista, I have an idea how much further the review went for 7, and I have confidence that it’s been done very well indeed. Security is absolutely not the problem with Windows 7.

The problem with Windows 7 is that it’s 2.8Gb. That’s an awful lot of code, and a significant amount of it is for “legacy support” – the obscure little features that some random company in some random place absolutely can’t live without, but the other 99.9% of us get to carry around as well. That’s why Windows is so big – it’s carrying around the baggage of decades of legacy support.

Why is it then, if we’re all carrying around this huge pile of backwards-compatible junk, that Windows 7 doesn’t support “older” hardware right out of the box? My test victim for tonight’s installation was my old Dell Inspiron – a 3-year-old sub-notebook with completely standard Intel-everything-on-board Dell-branded hardware. I expected it to be flawless, given the size of all the companies involved – if you don’t get support from them who are you going to get it from?

Instead, the first thing I noticed was a lack of screen resolutions above 1024×768 on my “Standard VGA Graphics Adaptor”. Nothing widescreen, certainly nothing approaching the native resolution of 1280×800. Next up I tried to connect to my wireless network, only to notice that I had no wireless card – no sound either, and a couple of other things in device manager that I’ve yet to even figure out what they are. What the hell? We’re all carrying around gigabytes of “legacy support” code in Windows but we don’t actually get any “legacy support” for our hardware? Why isn’t this on the CD, let alone on the Intel or Dell websites?

I’m done playing this game. I have a ton of hardware around here with multi-gigahertz processors, plenty of drive space and RAM, and no Windows support for any of it since Windows 2000 (Windows 98, in the case of one ATI card). It’s all perfectly serviceable; any time I need a machine for something-or-other I can almost always be assured that the very latest distribution of my choice will have near-perfect support for anything _that_ old.

It’s a difference of mindset. To Microsoft, Dell, and Intel, we’re all customers – they can’t afford to let us know that the hardware they sell is actually perfectly capable well beyond the shelf-life of the software, because if they did we’d all stop buying it. Linux has a diametrically opposite viewpoint, in that if something is truly that old then there’s a very good chance that at some point in between someone has just coded up a driver and made it work – and that’s all you need. Open-source will always have support for any of the older hardware of mine that I will ever care to throw at it, whereas the lifetime of hardware in the Windows world is getting shorter with every release. It makes no sense – why keep dancing the dance for no reason at all other than to “stay current”?

So yes. I’m done with Windows and Office (I’ve been impressed with OpenOffice – it has its quirks but it’s generally pretty decent), and Exchange, and in fact any commercial software that requires me to throw away perfectly serviceable hardware. Why bother? I’ll buy new hardware when it has something to offer, and I’ll upgrade my operating systems as and when I please. When did it start being Linux and not Windows that “just worked” anyway?

I now have both an “account number” and an “order number” from Alienware. I really shouldn’t be so happy about being $150 poorer. Alienware’s “critical issues” team for the win.