Intrepidus Group
Insight

Author Archives: mxs

Securing Mobile Hotspots, Part 1

Posted: May 7, 2013 – 1:19 pm | Author: and | Filed under: Mobile Device Management, Mobile Security, OWASP, Wireless

Mobile hotspots are awesome. They allow the user to connect any WiFi-enabled device to a high-speed 4G network. Anywhere. Maybe that’s one reason we see so many hitting the shelves. A significant number of these devices are equipped with advanced capabilities, such as media sharing or location-based services. But even without these capabilities, mobile hotspots are a tinkerer’s dream. It’s a WiFi radio, cellular (3G and 4G) radio, embedded OS, and web server, all rolled into one sweet package. So much to look at! Without pointing out particular vulnerabilities that we’ve found, we’re going to cover several weak points that we see across the board in these devices and provide some advice for testers and developers.

Weak admin controls
While a router’s webapp isn’t a fully internet-exposed attack surface, it isn’t ideal if sharing your hotspot with someone you think you can trust leads to a total compromise of your data. Most hotspots have an admin password — we like to see a different password for the admin interface and for WPA. Otherwise, what’s the point of an admin interface? <oprah>You get admin, and you get admin, and….</oprah> Once the passwords are different, it shouldn’t be easy to bypass the password prompt altogether. Here is a great example. Researcher Dustin Schultz found that an unprivileged user can access the WiFi password and administrative settings by adding a ‘/’ to the end of any URL. We’ve seen this take many forms, and allow anything from faking the admin cookie to disclosure of the actual admin password.

Common web-app vulns
The router’s web interface is private, right? Right? Unfortunately, Cross-Site Request Forgery (CSRF) attacks can originate from outside the network, and ultimately send data on your behalf. If you are logged in as the administrative user, CSRF can be used to change access point security, administrative passwords, or execute denial-of-service (DoS) attacks. CSRF attacks have been well-documented, and the OWASP site has plenty of examples and remediations, the most basic of which is to include anti-CSRF tokens with every request. This allows the webserver to verify that the request is coming from the actual page, not from a pre-crafted static request which is embedded in a website.

WiFi Protected Setup
Many modern routers STILL have Wifi-Protected Setup (WPS) enabled by default. The purpose of WPS is to allow users to connect to the Access Point using an 8-digit WPS PIN instead of a WPA(2) network key. Unfortunately, a very public design flaw in the protocol allows the PIN to be brute forced because it is sent and verified 4 digits at a time. This results in the router giving out the WPA key for the network. Lucky for us, some routers do have an option to disable WPS. Unlucky for us, some of those routers respond to WPS protocol requests even after WPS has been disabled. To mitigate the problem, OEMs should make sure that users have an option to disable WPS and that the device does not respond to requests after it’s disabled.

We’ll be publishing some more issues next week, including command injection, UPnP, and DNS rebinding!

Cheers,
Max and Rohan

Comments disabled

UltraReset – Bypassing NFC access control with your smartphone

Posted: September 21, 2012 – 8:24 pm | Author: and | Filed under: android, bugs, Conferences, Mobile Security, NFC, RFID, Tools

We were just in Amsterdam to present our research on uses of NFC for physical access control. The two main industries we focused on were transit and hotel systems. Ever since Intrepidus got us Nexus S phones with NFC early last year, we’ve been looking for real world uses of NFC on our trips. We discovered the flaw with the SF Muni Ultralight cards last year on a trip there and followed up with informing them of the issue in December. At the time, we had to take the cards home and use an NFC reader connected to a laptop to do testing. Since then, things have changed; the Android API supports reading from and writing to most Mifare NFC cards, Ultralights included.

Some of the coverage of this has confused all NFC transit systems with those using the Mifare Ultralight cards incorrectly. In our presentation, we listed several cities that we know have NFC transit systems as an example of how widespread the technology is becoming. We listed two cities using Mifare Ultralight cards incorrectly that we have 1) tested and 2) contacted with remediation details.

For those of you that missed the video, we have it posted here: https://vimeo.com/49664045

UltraReset Screenshot

UltraReset resetting an Ultralight transit card

This was a NJ Path 10 trip Ultralight card in the video. When we tap the card to the phone, our application reads all the data in pages 4 to 15 from the card and stores the data to the phone (we also store the card’s UID which we’ll write about more next week on hotel card issues). We then tap the card between two turn styles (which is why the count jumps by two). Once the 10 trips on card have been used up, touching it back to the phone causes the application to write the data back to the card. And with that, the card looks to be back in its original state when it was purchased with 10 rides remaining.

While these Ultralight cards don’t have access control features which are found in more expensive NFC cards, they do support a feature called a “One Way Counter” (which was named One Time Programmable or “OTP” in previous documents). These bits are in page 3 of the card’s data and once a bit is turned on, it can never be turned back off. This way, a card could be limited to being used only a limited number of times. These bits are left unchanged by the two transit systems we looked at which used Ultralight cards.

Ultralight Card OTP values

The one way counter (OTP) values of of the NJ Path card (top) and SF Muni (bottom). Neither system changes these bits when the card is used.

We know a number of cities are looking to roll out contactless technology and hope we can bring light to this issue so that it is implemented correctly in the future. One of the items we also raised in our talk is that full card emulation on smartphones is likely to happen soon. When this does, it could cause a number of NFC based access control  systems to be re-evaluated.

If you think your system might be vulnerable to this issue, we have put an Android application in the Play store which will read and compare the one way counter (“OTP”) on Ultralight cards. Note, the standard cards that you might get from transit systems typically are not Ultralights. Ultralights are typically only used for  “disposable” or “limited use” type tickets.

We have been reading lots of insightful comments on the articles we’ve seen. Please feel free to post questions or comments here and we will do our best to answer them (and no, we’re not planning to release the full UltraReset application). Last but not least, we would like to thank dragos and crew for having us at another one of the SecWest events — it’s always a great to catch up with folks in the industry and hear talks in the single track format. Thanks!

~Corey and Max

Comments disabled

The Cloud Comes to Your NFC Wallet

Posted: August 6, 2012 – 10:58 am | Author: | Filed under: android, NFC, RFID

This week, Google released a new “cloud” based wallet. We had some difficulty getting a device which actually *supported* this wallet, and in the end used Cyanogenmod 9 on a Nexus S 4G from Sprint and installed Google Wallet from the market.

The new wallet welcome screen

We were pretty curious what could possibly be cloud-based about a mobile wallet and how the Secure Element (SE) would be involved in all of this. It turned out that the difference between this wallet and the previous Google Wallet incarnations is that payments are made via a “virtual” credit card, and Google charges back to the original credit card. One Google credit card number (a Mastercard) is used for all of your Google wallet purchases, regardless of the “Selected Card”. For example, if you have a Visa and an Amex card in your wallet, and you want to pay for your groceries with the Visa card, you first select the Visa card via the Google Wallet UI, and it becomes the “Selected Card”. However, to the point-of-sales (PoS) terminal at the grocery store, it looks like you are paying with a Mastercard (which Google has issued to you).

The dialog displayed after making a payment using Google Wallet.

We haven’t yet tested if this MC credit card number is the same across all devices, though my initial guess is that each user will be issued a unique Mastercard credit card number from Google. If you read one of our previous posts on Google wallet, APDU commands are still sent between the wallet application and the phone’s secure element to select the active card, and they are logged to the standard logcat utility.

APDU command visible via logcat as 'desired' data when changing the selected card.

This behavior has a lot of parallels to Google Checkout (which now looks like it’s been merged with Wallet), where you link different financial institutions (credit card, bank account) to a single virtual account from which all your payments are made. This new update changes Google Wallet from a way to store and pay directly with your payment cards to a NFC Google Checkout service. Of course, this means that Google can now keep a repository of your purchases (blah blah big data blah blah). This new wallet format raises several interesting questions:

  1. Is the Mastercard credit card the same on my device and on your device? Or does each Google Wallet user get their own credit card number?
  2. What happens if this Google Mastercard credit card gets stolen?
  3. If I have multiple credit cards in my wallet, how does Google differentiate between cards? The standard “Selected Card” user interface still applies, but either Google is transferring data to its servers using the device’s internet connection (unlikely becuase I was able to make a transaction in airplane mode) or Google is transferring some piece of EMV Co. compatible data across the contactless interface at the time of the transaction.
  4. How do credit card rewards work if all transactions show up on my statement as “GOOGLE * <merchant>”
  5. How do Visa and Mastercard handle splitting the fees? Since there are now two transactions made (one between you and the merchant, and one between Google and you), we’re assuming there are twice as many fees. Is Google eating the fees and taking this as a loss leader?

We hope to find out the answers in a future post, after we get some more quality time with the magical Cloud Wallet.

Cheers,

Max

Comments disabled

USRP NFC Post Part II

Posted: June 20, 2012 – 3:02 pm | Author: | Filed under: Conferences, NFC, RFID, Wireless

This is not what you think it is, unfortunately. It has nothing to do with the USRP, but is the second in a series of posts which should really be entitled “Alice’s Adventures in NFC-land”. Since the second post in this series was supposed to be about demodulation/decoding, I’ll continue the title with the hopes of eventually porting this to the USRP.

This past week I attended training at ReCon, taught by Milosch Meriac. Milosch designed the OpenPCD2 line of RFID hardware, as well as some kick-ass firmware to go along with it. The most important thing I learned? “You know nothing, Jon Snow.” The training, entitled “Holistic NFC Hacking”, covered RFID hardware hacking, including sniffing and emulation (both of which have been a constant thorn in my side while trying to explore the world of NFC). This post will cover sniffing, and a follow-up will cover emulation.

Corey and I have been giving an Intro to NFC Security talk at various venues, in which we have a brief introduction to RFID/NFC waves and hardware. One of our slides shows a 0×52 (wakeup all tags) command that we captured on an oscilloscope followed by the tag’s response, which is the beginning of the anti-collision routine. We point out that, while all communication is propagated on a 13.56 MHz carrier wave, the PCD to PICC (reader to tag) transmits data via Modified Miller encoding and modulates the wave at 100%. The PICC to PCD communication, however, uses Manchester encoding and modulates at only 10%. On top of that, the peaks of the 10% ASK modulation are mixed with an 848 KHz sub-carrier frequency. Here I’d say a picture is worth 10,000 words:

Keep in mind, this waveform has been run through Milosch’s RFID sniffer (more on that later) and is only the envelope of the signal. The envelope is what we care about; it is the top half of the signal, without the carrier wave (the 13.56 MHz part) that is really only useful for vibrating this data through space. In fact, compared to the waveform displayed above (which looks like it could almost be an ugly sine wave), the carrier is so fast that it would look like a solid blob sitting under the blue line. That is an important characteristic of RF communication: your carrier signal must be much faster than your data symbol rate or you will not be able to differentiate one from the other at your receiving end. For reference, here is the tag response *with* the carrier wave. Notice the bottom of the picture where we measure the frequency between the two dotted lines at 13.56 MHz. That part is taken out in the first picture.

Take a close look at the peaks of the tag’s response. What looks like noise or some strange form of clipping is actually another wave: the 848 KHz subcarrier wave we mentioned before. This is a really cool RF concept. 10% ASK is about all the tag can manage with the limited power provided to it. That can very easily look like noise on the signal, so the tag modulates the peaks of its response with a wave that is much faster than the data rate so that the response can be picked out by the receiver. By design, the 848 KHz wave is 1/16 of 13.56 MHz, which allows the sniffer to use a different register on the same counter for both waves (more on that in a later post, too). Here is a close-up of that wave (again, just the envelope):

I was looking for parts of this picture to crop, but I think every part here is important. The crosshairs in the upper right (within the box titled “Zoom Overview”) shows where we are within the whole wave. We are really zoomed in, looking directly at one of the peaks that we saw on the tag response before. Again, we can use the dotted lines to measure the frequency of the wave, or 1/(t2-t1) if we are looking at just 2 peaks. The calculation, on the bottom right, shows 800 KHz. While it’s not quite 848 KHz, we are just looking at one cycle and it’s pretty close.

As per Milosch’s explanation, when the entire wave is displayed on a Fast Fourier Transform (FFT), the 848 KHz wave just looks like 2 bumps at +800 KHz and -800 KHz from the main 13.56 MHz peak. If a sniffing antenna is tightly tuned to 13.56 MHz, it can miss the subcarrier and effectively act as a filter, removing the subcarrier from the waveform. In order to capture the whole wave, he suggested increasing the resistance of the antenna to increase the bandwidth of the signal it will receive. That way, the subcarrier property of the encoding from the PICC can be used to pick out the signal.

More adventures down the NFC rabbit hole soon – the next post will cover emulation; also, a big thank you to Milosch for the in-depth training.

Cheers,

Max

1 comment

Bluetooth: Defining NAP + UAP + LAP

Posted: February 13, 2012 – 2:30 pm | Author: | Filed under: Wireless

Just a quick follow up to last week’s post, defining what NAP, UAP, and LAP actually are and where they come from. They are the 3 components of 6 byte “BD_ADDR” (Bluetooth device address):

NAP: “Non-significant Address Part”. 2 bytes. These are assigned by the IEEE and are publicly available here. Depending on who makes the Bluetooth hardware, there can be anywhere from 1 to 10′s of possible NAP portions. For example, Xerox is assigned 00-00-00 through 00-00-09 (along with 00-00-AA and 9C-93-4E). A search through the IEEE database for “Motorola” returns 250 results. Just to be clear, the first 2 bytes of these assignments are the NAP, and the last byte is the UAP. We can narrow the search space even further by filtering the list based on the assigned UAP, which we can also get by sniffing communication:

UAP: “Upper Address Part”. 1 byte. The UAP is also assigned by the IEEE and is listed on the same IEEE page as the NAP. The cool part about the UAP, which links it to both the NAP and the LAP (next section), is that it can be derived from packet data. As I mentioned in the previous post, Ubertooth provides a utility for calculating the NAP on-the-fly. This part involves some fairly complex unwhitening and brute-forcing, so we’ll leave that to Ubertooth ;)

LAP: “Lower Address Part”. 3 bytes. The LAP is easy — it’s transmitted with every packet as part of the packet header! All we have to do (which the Ubertooth does for us) is sit on one channel and wait for a packet to be transmitted. This happens frequently — to the “tune” (har har) of 1600 hops over 79 channels every second, meaning we should see just over 20 packets per second on our one channel if the two devices are communicating at full bandwidth.

So! Now we have the full BD_ADDR. What can we do with it?

Well, first of all, we can sniff Bluetooth! (Pending hardware support ;) ). Bluetooth’s special “hopping” pattern is derived from the master device’s MAC address. Using the BD_ADDR of the master, in theory we can follow that hopping pattern and start extracting useful data from the Bluetooth communication.

We can also target one device directly, or emulate that device and cause all sorts of mischief. We can tell the other device that we forgot our secret Link Key, and need to re-pair and make a new one. Or run attacks against the Bluetooth implementation.

Comments disabled

Wallet PIN Storage Best Practices

Posted: February 10, 2012 – 11:24 am | Author: | Filed under: NFC

In light of some recent issues, we thought we’d try to answer the question: “So… where *should* Google Wallet have stored the PIN to protect it on a rooted device?” The answer is… the same place all the other sensitive data is stored! On the Secure Element (SE). Instead of storing the PIN in protected space on the filesystem (which works just fine on a non-rooted device), wallet applications should store the PIN for their particular applet within the SE. Then, using ISO 7816-4, or Application Protocol Data Unit (APDU) commands, send the PIN to the SE and let the SE do the verification. This article, written by a couple guys at RIM, gives a Blackberry-specific but generally very useful overview of NFC payment/Secure Element access components.

APDU commands are exchanged with the SE to execute lots of other functionality — they are the primary means of sending and receiving information from the SE. They can be sent using any API in place for smartcard/SE communication. On the Blackberry, the APDUConnection interface implements:

byte[] exchangeAPDU(byte[] commandAPDU)

The same article mentioned above gives a code snipped for actually using this method:

 // The JSR177 connection will use the APDUConnection object
APDUConnection apduConn = null;
// The connection string for the JSR177 connection
String conStr = "apdu:0;target=41.5F.50.5F.44.5F.55.5F.41.70.71.01";
// Define the command to send to the Smart Card applet
byte[] command = { (byte) 0x00, (byte) 0x04, (byte) 0x00, (byte) 0x00 };
try
{
// Open a logical channel to the application
apduConn = (APDUConnection) Connector.open( conStr );
// Send an APDU and wait for a response
byte[] ret = apduConn.exchangeAPDU( command );
// Close the logical channel connection
apduConn.close();
}
catch( Exception e )
{
// handle the Exception
}

At this point, Blackberry seems to have the most comprehensive and well-defined SE interface, baked right in to Blackberry OS. This list of supported Java APIs includes JSR 177, which is the Security and Trust Services API (SATSA). The JSR 177 API allows a Java application to communicate with a smart-card (or SE). Blackberry OS implements JSR 177 in the APDUConnection interface. This interface has high-level methods, including one specifically for PIN verification:

“enterPin(int pinID): This is a high-level method that lets the J2ME application ask for the user PIN value for PIN verification purposes and send it to the card.”

In short, we’d love to see JSR 177 or equivalent implemented in Android. And if it already exists, please leave a link in the comments!

Comments disabled

Ubertooth: Bluetooth Address Breakdown

Posted: January 29, 2012 – 2:03 pm | Author: | Filed under: Tools, Wireless

The IG crew is just heading back from ShmooCon, which reminds me of last year’s awesome talk on the Ubertooth One. Intrepidus backed the kickstarter project and, as promised, got 2 Ubertooths. We recently started playing with it, and have a couple of tips and a supplementary script.

We originally followed the post here to get the Ubertooth set up on BackTrack 5, but then had some trouble keeping the device connected and sniffing reliably (similar to our experience with the Proxmark III — sensing a trend here ;) ) After updating the firmware and setting this up on an Ubuntu host, the device works flawlessly. I honestly don’t remember if these are my comments in the commands below or if I found it somewhere on the internetz. I apologize if I stole your commands:

cd ubertooth/trunk/host/bluetooth_rxtx/
./ubertooth-util -f #puts the device in flash mode. lights should blink prettily.
cd ../usb_dfu/
./ubertooth-dfu write /path/to/firmware/bluetooth_rxtx.bin #this is the standard firmware. there are other special ones. suit yourself.
../bluetooth_rxtx/ubertooth-util detach

The “Getting Started” section of the Ubertooth site gives a pretty good idea of what the device can do. We found that the Ubertooth sits on one Bluetooth channel (out of the 79) and sniffs the LAP out of the Bluetooth packets. A little bit on Bluetooth address breakdown (This image is from section 3.2 of this paper):

Bluetooth address breakdown

Bluetooth MAC addresses are comprised of 3 pieces: the Lower Address Part (LAP), Upper Address Part (UAP), and the Non-significant Address Part (NAP). The picture above illustrates this nicely. The Ubertooth can sniff the LAP out of the air, and use the error checking field in the Bluetooth packets to figure out the UAP (ubertooth-lap and ubertooth-nap, respectively).

The NAP (and UAP) are assigned on a per-vendor bases by the IEEE. That means the UAP is available through both the Ubertooth and the IEEE database of NAP+UAP addresses. Using both these resources (and matching up the UAP from both), we can figure out the first 2 NAP bytes pretty quickly! Of course it’s also possible to figure it out if we haven’t calculated the NAP (by appending the LAP to everything we can pull from the IEEE database and ping each one sequentially).

Automating stuff is fun. Here’s my (sloppy) script to figure out the NAP using first the short method, then the long if that one fails: https://github.com/intrepidusgroup/napfinder

– Max

Comments disabled

USRP for NFC Part 1

Posted: November 30, 2011 – 3:30 pm | Author: | Filed under: NFC, RFID, USRP

The USRP from Ettus Research is an awesome tool for radio analysis. It’s a really complex tool that is capable of doing almost anything involving radio signals (see these two previous Insight posts by Corey and myself, and Raj). That doesn’t even scratch the surface, though. This post will go into the detailed hardware setup for investigating NFC over the air communication using the USRP.

For the RFnoID project, a group of us temporarily turned into nocturnal, lab-dwelling creatures to get this set up. Full credit for this post goes to my group members: Rob Lee-Own, Scott Velivis, and Vincent Lin.

Step 1: Obtain USRP. Ettus Research has several models. For the RFnoID project, we used the plain ol’ black USRP1. At Intrepidus Group, we have the USRP N210. An enormous, frustrating, caveat to the USRP will be mentioned later, but for now, keep this in mind: The USRP1 uses USB, while the N210 uses Gigabit Ethernet to communicate with the computer. Select with care!

Step 2: Select your daughter boards. The USRP requires RFID works in three frequencies: 125 KHz, 13.56 MHz, and 900 MHz. We’re going to be focusing on ISO14443-A, which operates at 13.56 MHz. For the rest of this article, NFC refers to the 13.56 MHz band. We’ll need one daughter board for receiving, and one for transmitting. The low frequency transmit and receive daughterboards (LFTX and LFRX) should fit the bill for 13.56 MHz RF communication at DC to 30 MHz.

Step 3: Select your antennae! This part took trial and error, including some home brew (courtesy of Scott and Rob):

We ended up going with two of the DLP-RFID-ANT from Digi-Key at $40.

Here’s the tl;dr so far:

  1. USRP @ $1700 (USRP N210) or $700 (USRP 1)
  2. LFTX, LFRX @ $75 each
  3. 2x DLP-RFID-ANT @ $40 each

At this point, you should be able to hook it all up, set up GNU radio on your computer, plug in the USRP, and capture NFC goodness right out of the air. Wahoo!

In this video, we’re issuing a read command using libnfc in the left terminal, and detecting NFC energy using the USRP in the right terminal.

Still with me? Good. Here’s where we started spending long nights in the lab banging our heads against the desk. First, a little background on the software/protocol: NFC at its most basic level follows the ISO 14443-4 “Transmission protocol” specification. You can purchase that from ISO for 136 CHF. Google tells me that’s about $150 in real money. The real gem to pull out of those endless pages is that 0×52 is the WUP (wakeup) command, and it will wake up all tags in the area. 0×26 does something similar. In short, we used some hack-y Python to convert hex numbers into a wave format the USRP could understand and transmit. Code here. Feel free to use that code, but please credit RFnoID if you do find it useful. The USRP will modulate this wave at the carrier frequency. You do not need to do that part. You can set up the USRP to use that .wav file using:

from gnuradio import gr

gr.wavfile_source(“wave52.wav”, True)

We’ll get more into the software behind this in Part 2. Back to the hardware. Here’s what we were trying to get:

Notice that wave is 5.5V peak-to-peak. The NFC tag gets its energy from the RF signal the reader (or, in this case, the USRP) transmits. That’s the energy required to wake up and power an NFC tag.

When we transmitted, the tag simply wasn’t responding. Looking at our signal using the oscilloscope, we found that our signal was roughly .5V peak-to-peak. We required an amplifier to boost the signal to the 5.5V level and, luckily, found one in the lab. The amp doesn’t have to be this fancy, but needs to be SMA-in, SMA-out. We’re still searching for a cheaper amplifier that meets our criteria. Luckily Scott understands antennas much better than I do and says: “the 13.56mhz band is so narrow that even a very non-linear amp would look linear for a ~200khz bandwidth.” We’ll keep this post updated if we find something cheap that fits our criteria.

The second major issue we encountered came when we tried to do 2 things: first, detect energy in the NFC band; and second, send a blocking signal (0×52 works well for this purpose because it re-starts the tag’s initialization and anti-collision routine). We were using a USRP1. Remember we mentioned before that the USRP1 connects to the computer using USB. We were getting a large delay (~300 microseconds) we believe was coming from the USB stack (in the Linux kernel) buffering before sending a complete frame, causing a delay in detecting the RF energy. In theory, the USRP N210, which connects via Gigabit Ethernet, would not have this issue and could send frames as soon as they were received from the USRP.

More on the software (GNU radio and the scripts we used) in Part 2!

-Max

Comments disabled

BlackHat 2011 and Defcon 19 Summary: MXS9000 Style

Posted: August 8, 2011 – 12:20 pm | Author: | Filed under: Conferences, Mobile Security, NFC

We’re all getting back from BlackHat and Defcon now, despite some weather delays and red-eyes, I think everyone had a blast again this year. First off, a big thanks to the Rio for hosting DC and putting up with some shenanigans: there were rumors of rogue cell towers, some definitely unsafe wifi, and elevators mysteriously ended up in “inspection” mode (I had to walk 30 flights down one night! /me shakes his fist). The venue was great (I think everyone appreciated the change in scenery) and the tracks were pretty well organized. My only complaint: CRT TVs? Still?

I really want to thank the FNGs for their valiant effort to misinterpret my list: “re-usable bowl“, “re-usable spoon”, “tube of sunscreen”:

 

There were some really interesting talks at both BH and DC. In particular, “Reviving SmartCard Analysis”, by Karsten Nohl and Chris Tarnovsky was awesome — Nohl was one of the guys who broke the Mifare Classic by grinding down the chip and looking at the gates to figure out Mifare’s Crypto-1 algorithm. For those of you who aren’t familiar with smartcards, they are essentially a full computing system, complete with a processor, ROM, RAM, and supplementary processors, scaled down onto one chip. In this presentation, the researchers went through some of the previous attacks on smartcards. In early revisions, it was possible to use a microscope to read out memory on the chip. Once that memory was encrypted, attackers began capturing data by putting tiny pins into the wires between the decryption centers and the processor. In newer smartcards, those wires are protected by a mesh, making it far more difficult to read data from that area. Still newer smartcards will hide decryption within the CPU. Nohl and Tarnovsky revealed several design weaknesses in some modern chips — in an unnamed chip, the key was stored right next to the encrypted data in ROM; the baseband processor has unencrypted memory; substantial portions of the bootloader are unencrypted; also, everything sent to on-chip peripherals is in the clear (the wires themselves can be scrambled, but on an 8 bit chip there are only so many possible orders). My favorite part of this talk was degate, a software tool for reverse engineering gate logic from images (the researchers plugged siliconzoo.org if you’re like me and can’t tell the difference between an AND gate and an XOR etched in silicon, or any other logic circuit for that matter).

Also — thank you to Immunity and BlackHat for hosting and sponsoring another great HackCup. It was a little more popular this year with 12 teams competing. Unfortunately, the initial round was only two 15 minute games and Goal++ suffered defeat in both (5-4 and, well, we won’t mention the second game). We’ll be back next year with a leaner, meaner, and more coordinated team. Watch out, Brazil. Pics to follow, as soon as Zach gets his camera back.

That’s it from me. Hope to see you all again next year at BH/DC.

-mxs9000

 

Comments disabled

USRP 101: Unlocking Wireless PC Locks (and freeing dolphins)

Posted: July 18, 2011 – 5:39 pm | Author: and | Filed under: Cryptography, Mobile Security, RFID, software security, Tools, USRP, Wireless

Wireless PC Proximity Lock

Have you ever seen one of these “USB Proximity PC Locks” before and thought “There’s NO way that piece of junk is secure”… turns out, you were right.

We had a little office challange recently to break this system, just for fun, and along the way document our Universal Software Radio Peripheral (USRP) which I’m still just starting to get to know. By now, I figure most of our readers would be familiar with the OpenBTS Project which uses an USRP to impersonate a GSM base-station. While this is an impressive use of the hardware at a fraction of the cost of a comercial base-station, the USRP can also be used to impersonate less functional and almost worthless priceless equipment… like that USB proximity lock.

First things first, we need to get one of these locks ourselves. Surprisingly, I got one of these as a gift from ThinkGeek years ago and you can still find them on eBay and a few other sites. I was missing the drivers for mine, but you can still find a copy online. I installed it in an XP virtual machine and paired the remote with the USB dongle. Now anytime the remote was powered down or more than 30 feet away, the lock screen with these pretty dolphins was displayed.

Wireless Lock "lock" screen on XP

What I needed to know next was the approximate frequency. which the remote used to send data to the dongle and unlock the computer. My goal was to capture this transmission with the USRP, then replay the signal when the remote was turned off or out of range. Unfortunately the documentation that came with the wireless lock was pretty silent on what it used to do this. Given the device is so old, I doubted it would use BlueTooth, so I started to look through the installed application files for clues. The application is sold to be re-branded by many companies, but the string “Copyright (C) 2003 Dritek System Inc” in the HIDRead.dll seems to point to the actual manufacture. The USB dongle installed as a HID device under Windows, but the driver does not appear to say anything about the frequency which the dongle and the remote communicate. Neither does the documentation with the driver nor the PDFs I found online. However, one EBay post did contain an image of the back packaging which seems to have “FCC 434Mhz”. This matches the unlicensed spectrum that is commonly used for remote keyless car unlocking and garage doors.

This was also backed up when the remote device was taken apart. There are 2 main chips on the remote I was interested in, one labeled “NDR 550″ and the other “MDT10P55B1S”. Some surfing around leads to the NDR550 being from “Najing Electronic Devices Institute” which list this as a One Port Resonator which operates at 433.92 Mhz. Also looking at the remote’s PCB near the battery there are markings “315″ and “434″. Mine had a blue pen marks next to the “434″ text which falls within the range of the WBX board in our USRP.

Wireless PC Lock Remote

Using the GNU Radio spectrum analyzer around the 433.92Mhz frequency with our USRP N210, we do in fact receive a signal when the unlock remote is powered up and transmitting. The “uhd_fft.py” script comes with GNURadio UHD package. While the GUI was a bit unstable on my system, command line parameters worked well.

uhd_fft.py -f 433.9M -A TX/RX

USRP FFT

The next step was to capture the signal coming from the remote to the dongle. While far from stealthy, the Log Periodic antenna we had from WA5VJB works for 400-1000MHz ranges. So with a bit of gain tweaking and proper timing, we were able to snag a good complex capture of the signal out of the air. Again, GNU Radio makes this easy with the “uhd_rx_cfile.py” script.

uhd_rx_cfile.py -f 433.9M -A TX/RX -g 35 outfile.dump

Then it was time to replay the signal. To do this, we wrote a GNU Radio Companion (GRC) file. I’d recommend looking at the OZ9AEC GRC examples if you’re new to GRC and have a UHD device like our N210. However, this replay script was so easy you could basically point and click to get it working. You’ll need just one source (something that will generate a signal in this case) and one sink (something to transmit the signal). The source was the file we had just captured which we sent to the UHD: USRP Sink.  Set the sample rate to match that of the capture (default 1M), the center frequency (433.9 MHz in this case), and adjust the gain depending on your antenna and range.  We set the file sink to repeat so running the script would continuously replay the unlock command to the dongle. From there, simply execute the script and watch the PC unlock (Go free my dolphin friends!)

GRC Transmit from File

We also looked at unlocking the system using a Teensy USB development board as a fake dongle (Sid, I want my Teensy back!). We plan to have a follow up post on that, but if you start looking though the registry and configuration settings for this wireless lock, you’ll notice some data looks strange. The “SqrtyKey.Cfg” file and HKLM\SOFTWARE\KeyMark\Wireless PC Lock\Password Answer registry setting are encoded with a transposition cipher. It shouldn’t take you long to figure out the pattern, so once you have, you can use the python script below to save you some decoding time. [download id="271" format="2"] (update: link should now work) (update 2: the maddman posted an awesome clean up of the script for Python 3 here)

So there you have it. Want to defeat a $20 wireless PC lock? All you have to do is spend $2500 on USRP hardware ;-)

~Corey and Max

4 comments

image

This site is protected with Urban Giraffe's plugin 'HTML Purified' and Edward Z. Yang's Powered by HTML Purifier. 24529 items have been purified.