NFC credit cards are broken by design

nfc_cc_broken.png

Short version: NFC enabled credit cards are broken by design. If your bank offers you one, you should refuse it. If you already have one be sure to drill a hole thru the card body to destroy the antenna.

Renaud Lifchitz (french security expert at BT ) gave a presentation today (friday 13th april 2012) at Hackito Ergo Sum 2012 conference on the lack of security in NFC enabled credit cards(no authentification and no encryption).

Security and convenience are diagonal opposite. What is convenient is rarely secure. What is secure is rarely convenient. For example my 63 characters long WPA2 WiFi passwords are a genuine pain in the rear end to enter on some devices (worst to date keyboardless Amazon Kindle) but I want to belive they are pretty secure.

NFC falls in the VERY convenient bin... some applications based on NFC are designed correctly some are not. For example the Navigo Pass used in the Paris public transportation is properly encrypted and authenticated. Another proper design is the electronic passport that requires reading the MRZ (machine readable zone) to unlock the access to the sensitive data.

On the other side of the spectrum lies the NFC enabled credit card. If you thought WEP encryption was broken, at least it tried to encrypt the data. NFC enabled credit cards don't require authentication to access the sensite data. This means that a bad guy in range can access your data and build a "clone". Or if he is in a good mood, kill the chip by doing 3 PIN failed access.

The sensitive data is sent unencrypted. This means that the bad guy (15 meters away) can eavesdrop a valid transaction and build a "clone" card.

The demo application ran on a computer and on an Android phone harvested the following data from the NFC enabled credit card:

  • the PAN (primary account number).
  • the holder first name, last name and gender.
  • the expiration date.
  • the transaction history.
  • the magnetic stripe data.

Eye roller snippets from the presentation:

  • But it's a shame and a big FAIL. They don't use any kind of authentication and any kind of encryption. So it's wide open. (at 10:40)
  • EMV (Europay MasterCard Visa) is simply poorly designed for NFC and needs a complete rewrite. (at 32:40)
  • EMV is not designed for contactless (at 32:50).
  • We haven't broke any security or tried to because there is none. (at 39:18)

From the email exchange with Renaud Lifchitz, no tricks were used. The card just communicates with the reader without encrypting data. As in the card was not forced to use a plain text mode. I'm not even sure it qualifies for security thru obscurity since it's pretty straight forward to buy a contactless smartcard reader. Renaud Lifchitz successfuly ran his "attack" on recent credit cards from Visa and MasterCard (latest from march 2012).

Given that I have a spare laptop and some contactless smartcard readers (ACG, SCM and Omnikey), I'll be able to give the demo code a try. The hardest part will be to find a NFC enabled credit card. I asked around me but I haven't found one yet.

The following Ustream video record is a boring static shot that doesn't allow to read the slides. The presentation slides are available in PDF form on the ReadNFCC Google Code project.

Video streaming by Ustream

Links and external references:

icon_pdf.png

Wake up call from Google cars recording wifi data

On 15.05.2010, Google admitted that their Google Street View cars recorded a lot of Wi-Fi data (access point MAC address, SSID and more). The purpose is to be able to correlate the GPS location with the visible Wi-Fi access points. The end game is to provide a quick approximate geolocation to Wi-Fi enabled devices. A company like Skyhook Wireless records similar informations and provides its services to Apple mobile products (iPod Touch, iPhone, iPad,...).

google_street_view_car.png

The SSID can be easily changed by the user so you shouldn't rely on it alone. The average Joe will probably never change their SSID. The MAC address modification is possible but far out the reach of the average Joe. It require a custom firmware which not all router support.

When the SSID is not "hidden", the Wi-Fi beacon packet advertise the SSID every 100ms. If it's "hidden" there are 4 other ways to get the SSID. For routing purposes, every Wi-Fi packet feature in the clear the MAC address of the communicating devices. Only the payload is encrypted when using WEP or WPA.

I believe that Google cars record the GPS location and whatever packet they ear on the 14 Wi-Fi channels. The Google cars change the listening channel every 200ms so in less than 3 seconds they can scan the 14 available channels. Instead of extracting the useful parts of the packet (SSID + MAC) on the fly, they keep the intercepted packets for an offline analysis.The open source Wi-Fi auditor inSSIDer builds a database of MAC address/SSID/GPS coordinates.

Google clearly stated that they didn't record encrypted packets. But the real issue for me is the following. Once you record a WPA encrypted packet you are able to do a brute force offline attack. It's time and computer consuming. The duration of the attack depends on the length of the WPA key. A tool like Elcomsoft Wireless Security Auditor is able to try 100000+ keys a second.

You should use WPA with a 63 characters random key from the GRC password generator. WEP encryption is so badly broken that it should not be used at all. Insecure wifi access points should be used only when there is no other option. If you have to use an open access point know that whatever is not encrypted is broadcasted in the clear.

Hardware DEP has a backdoor

Introduction :
Hardware DEP (Data Execution Prevention) is a feature that protects Windows XP SP2 from buffer overruns. When a compatible CPU is present, Windows XP SP2 DEP interface offers 2 options. The default one protects only the core Windows components and the ones manually added by the user (OPTIN). The most secure one protects all the programs on your systems except the ones manually added by the user (OPTOUT).
For more informations on how to activate hardware DEP, visit my DEP to keep buffer overrun at bay blog post.

Investigating hardware DEP :
I activated DEP on my 2 compatible PCs in mid 2006, it was protecting my PCs in the background so I forgot about it. Recently the security guru Steve Gibson of grc.com in it's Security Now podcasts mentioned that IrfanView refused to run in ALWAYSON DEP mode. While it would run perfectly in in OPTOUT mode. Theoretically OPTOUT with an empty exclusion list should behave exactly like ALWAYSON. The only possible explainations were either IrfanView was doing a nasty trick to evade DEP or Microsoft lied about the definition of OPTOUT.

I ran a bunch of queries on Google to find more information on the subject... nothing really impressive. Then a contributor on the GRC security newsgroup posted about packed executable disabling DEP. Back in late 2005, when the WMF exploit surfaced Kaspersky pointed out that IrfanView and XnView were running without protection even in OPTOUT mode. Leaving their users with their pants on the ankles. It clearly stated:

“However, when testing the latest builds of third party image viewers like Irfanview and XnView HW DEP didn’t prevent exploitation, even with HW DEP enabled for all programs. This is because both Irfanview and XnView are packed with ASPack and Windows disables HW DEP for ASPack packed files.”
— Roel Schouwenberg, Kaspersky

ASPack allows to compress executable files (EXE, DLL, OCX,...) so their footprint on the hard disk is smaller. The file is decompressed on the fly at runtime. The CPUs are faster than hard disk so in the end running these apps should be faster. I never used DriveSpace/DoubleSpace (back in the DOS days) or RAID0... mainly for low reliability and lack of decent performance boost. So I have a hard time believing that saving 2MB on my laptop 160GB hard disk is a useful trick. Especially when it comes at the expense of DEP protection.

So this new keyword unleashed the doors of very interesting stuff on Google (query ASPack DEP Kaspersky). I quickly found out that IrfanView was not using any trick to evade DEP... Microsoft just coded a backdoor used only in OPTOUT. Bascially Microsoft checks the executable header for a section matching one of the 3 strings. If one these strings is found, DEP will be turned OFF for this application by windows. To find these strings all you have to do is use a hex editor to open ntdll.dll found in your sytem32 directory.

The 3 backdoor strings in ntdll.dll :

By order of appearance, the strings are:

  • aspack : from ASPack. Common programs that use ASPack are the 2 image viewers IrfanView and XnView... but also the web browser Opera.
  • pcle : (source not yet identified) I put my 0.02€ on Pinnacle System for their long history of crashing apps and their NASDAQ ticker.
  • sforce : from Star-Force the highly unpopular game/app copy protection. The list of current Star-Force protected games can be found on the Boycott StarForce website.

The easiest way to identify the DEP status of an application is to run Process Explorer. In order to display the DEP status you'll need to go to the View menu, click on Select columns and then tick the "DEP status" checkbox.

Process Explorer window :

The compressed programs appear in purple. You can see that packed apps are common but only the ASPack ones disable DEP. Both IrfanView and Opera run with DEP off. In this case, I had Skype (proprietary packer???) and FastStone Capture (UPX). I also use uTorrent which uses PECompact.

From my point of view the worst case is Opera. By definition a web browser is on the front line it has to be backed up by DEP. I would barely tolerate that a local widget that displays an analog clock disables DEP... but a browser is way beyond my threshold. If the widget requires DEP to be turned off to run, I want to be in charge of doing so. Just like I want to control the opened ports in my routers and therefore turn off UPnP, I want to have the control of my hardware DEP protection.

Conclusion :
I want to believe that Microsoft will eventually release a properly named OPTOUT mode. If the current backdoored version was to stay it should be named with clear unsecured in its description. If some spin doctor wanted to pull "Hybrid" out of his sleeves he should take this PR stunt and *censored*. On the programs side, it would be a good time for the ASPack users to switch to UPX which is open source and DEP compliant. Or simply dump packed executables for good. I don't care if my web browser takes 200 extra milliseconds to launch. But I do care to have DEP blindly protecting my programs from undisclosed buffer overruns.

Some will say that ALWAYSON locks this backdoor... but in my case being able to OPTOUT one program in beta stage is priceless. Therefore I'd rather replace the strings in ntdll.dll by some random gibberish so that no other app can slip thru my fingers. Last year, for speed reasons, I switched from IrfanView to FastStone Image Viewer. I'll now use Opera only as the last resort and for testing purpose on known websites.

Edits :

    • IrfanView 4.x+ now uses UPX packer so it's fully hardware DEP compliant.
    • A bunch of PhotoShop compatible plugins require switching DEP off for the hosting app (PhotoShop, Paint Shop Pro or others).
    • These plugins don't trigger a DEP interception, they just fail to properly run and crash the host application. Here are some plugins that crash: Xero Graphics, PhotoWiz and plugins built using FilterMeister. The FilterMeister devs are aware of the issue and are working on a solution.
    • Opera from version 9.50 alpha and up is now DEP compliant (FYI: it uses UPX to pack its executable).

    Useful links :

    DEP to keep buffer overrun at bay

    Since the service pack 2 (august 2004), Windows XP supports the hardware DEP (Data Execution Prevention). This feature is hardwired in the modern CPUs, it allows to intercept and lock programs before buffer overruns lead to issues. It requires a compatible BIOS, CPU and operating system.

    By default the DEP is only applied only to the Windows core programs and services. The main reason behind this default behavior is that back in august 2004 a bunch of legit apps were locked by hardware DEP (Adobe Reader 6, Jasc Paint Shop Pro 8, Pinnacle Systems Studio 9,...). These programs were patched out of the bugs / performance tricks to be hardware DEP compliant.

    If your gear supports hardware DEP, it's highly recommended to activate it. To do so, you'll need:

    • Open the system applet in the control panel.
    • Select the advanced tab then click on parameters in the Performance section.
    • Select the Data Execution Prevention tab.
    • Select the Turn on DEP for all programs and services except those I select.
    • Click on Ok then reboot to apply the changes.

    DEP options:

    070208_dep_us.png

    From now on your PC is protected against most buffers overruns. If a program tries to execute code in a forbidden area, the following window will appear.

    DEP warning:

    070208_dep_us_crash.png

    In this example, Windows Explorer is not behaving properly... If a legit program is stopped by DEP, you still have the option to add it to the Opt-out list. But you'll have to understand that disabling DEP leaves a breach in the security wall created by DEP.
     
    In case you don't know if your PC supports hardware DEP, Steve Gibson from grc.com made a program called Securable. Securable checks your system for the following security features:

    • Hardware DEP: for Windows XP SP2 32/64 bits and up.
    • 64 bits: for the Kernel Patch Protection of Windows Vista 64 bits.
    • Virtualization: for the future HyperVisor of Windows Vista 64 bits.

    Securable ran on my laptop:

    070208_dep_securable.png

    Additional informations: for the advanced users
    The DEP mode is a parameter of the operating system in the boot.ini file.

    [boot loader]
    timeout=30
    default=multi(0)disk(0)rdisk(0)partition(1)\\WINDOWS
    operating systems]
    multi(0)disk(0)rdisk(0)partition(1)\\WINDOWS=\"Microsoft Windows XP Professionnel\" /fastdetect /NoExecute=OptOut

    The possible values for the NoExecute parameter are:

    • ALWAYSOFF turns DEP off.
    • OPTIN activates DEP only for the main Windows programs and services and those added to the list. (Windows XP SP2 default mode)
    • OPTOUT activates DEP for all the programs et services except those added to the list. (best mode available from the DEP options window)
    • ALWAYSON activates DEP for all programs and services. (only available by manually editing the boot.ini file)

    Remark: If a bug in a critical driver triggers a DEP lock in OPTOUT or ALWAYSON modes it might prevent your PC from booting. In that case you'll have to access the recovery console and edit the boot.ini file to switch to OPTIN mode.