Reading RFID tags - Adam Laurie's RFIDIOt and the CardMan 5321 USB reader

As I noted in my last post, Improvised RFID Blocking Wallets: Preventing PayPass Skimming, I have recently been working with an OmniKey Cardman 5321 USB RFID reader in Windows. The reader is compatible with a broad range of RFID cards (From Omnikey's website):

• Philips/NXP: MIFARE®, DESFire®, MIFARE ProX®, and i.code
• HID: iCLASS®
• Texas Instruments: TagIT®
• ST Micro: x-ident, SR 176, SR 1X 4K
• Infineon: My-d (in secure mode UID only)
• Atmel: AT088RF020
• KSW MicroTech: KSW TempSens
• JavaCard: JCOP / SMART-MX in RSA mode with 2048 bit keys

Omnikey provides drivers, as well as a simple diagnostic tool which can read tag IDs and can provide basic information about the contents of the tag. If you want to do more with RFID, you need a more full featured software package, and Adam Laurie's RFIDIOt handily answers that call. RFIDIOt reads ICAO 9303 encoded Machine Readable Travel Documents, and both Data Group 61 (MRZ) and DataGroup 75 (Encoded Information Features - FACE), as well as many other data types.

To make RFIDIOt work, I installed Python 2.5.2, as some of the packages it relies on work with 2.5, but not with 2.6. You'll need the following software packages to make it all work:

• pySerial (2.4 Win32)
• pyscard (1.6.7 Win32-py2.5)
• pycrypto (pycrypto-2.0.1.win32-py.25)
• the Python Imaging Library (PIL-1.1.6.win32.py2.5)
• pywin32-212 (pywin32-212.win32-py2.5)

You can ignore the need for PCSCLite for the purposes of this install.

You will also need to modify RFIDIOtconfig.py to use the USB device. Simply modify the section that reads:

# serial port (can be overridden with -l for Windows)
line= "SERIAL”

With the following:

# serial port (can be overridden with -l for Windows)
line= "USB”

A simple re-compile of RFIDIOtconfig.py results in an updated RFIDIOtconfig.pyc, and you're ready to go.
Once you have done this, you should be able to test your reader by executing multiselect.pyc, which is a simple looping tag ID reader. If you see the tag IDs when the green LED on your CardMan turns red, you've succeeded.

RFIDIOt presumes that you will have a directory in your system root called /tmp - if you want to capture any data for testing, you'll need to manually create the directory on Windows systems.

Improvised RFID Blocking Wallets: Preventing PayPass Skimming

Many credit card users do not realize that they have PayPass enabled RFID credit cards in addition to the new RFID enabled US Passports. These RFID enabled devices are easily read at distances compatible with casual contact in a crowded environment such as a subway or an airport, and various data can be gathered from them (US passports require key data to decrypt the data stream). More and more people carry fob based RFID PayPass tokens, or have PayPass cards, making the wireless exposure of their card data far more likely.

How can we combat this? The good news is that commercial RFID blocking wallets are available, and various people have created their own versions such as the duct tape and tin foil wallet. The resourceful traveler can easily replicate their functionality on an ad-hoc basis too. We have tested with a number of common objects, such as the cookie bag and tinfoil above, which worked quite nicely for our 13.56 Mhz test tags.


As you would expect, common food packaging is a very easy to obtain improvised RFID blocking material. We have not tested 125 kHz tags, so your mileage may vary if you are attempting to block RFID tags using that frequency.

Our testing was conducted using a commercially available Omnikey Cardman 5321, a USB connected RFID reader, and using Adam Laurie's RFIDIOt package. Longer ranges are possible using custom antennas and readers, with some testing on these passive tags being done at up to 30 feet by NIST - a result that worries the ACLU.

Check your wallet - you may have a PayPass enabled card without realizing that you do. To check, simply check the back of your wallet for the PayPass logo. In addition, many cards have a chip logo on the front, making them easily identifiable.

PayPal Scams and Evolutionary Pressure

We've discussed the anatomy of a typical PayPal scam email in the past, and we've analyzed other scams such as credit union member phishing. With that in mind, a recent PayPal scam email has a few little tweaks that are worth noticing.

The first thing to note is that it tells the recipient that the investigation process will take at least 12 hours, and that they recommend that you verify your account then. This means that most users won't try to log in for at least 12 hours, giving the scammer a chance to loot the account.

Second, it was interesting to see that the scammer did not use a very well concealed clickable Paypal URL - a simple mouseover points it to a site easily identified as a non-PayPal site. The most interesting part here for me was that the help link redirects to an alternate site as well - although, again a poorly concealed one.

Finally, the email spends almost a third of its length discussing what PayPal does to address scams and to prosecute fraud. This appears to be an attempt to tap into what Bruce Schneier discussed recently regarding the science of cons.

These incremental improvements - and the lack of sophistication in the links show that PayPal scam email continues to evolve and adapt, and that some of the most common tricks aren't universally used. As users become more savvy, successful scams must become more realistic, and must appear more trustworthy.

The email is reproduced below as a clickable image - click to expand:

Digital Forensics: Data Carving With Foremost

If you're doing forensic work, or if you need to do data recovery, you'll likely run into deleted files that you need to match up with actual file types. This is where data carving, or file carving comes into play. Data carving involves searching an input (in this case, a dd image) for content, rather than metadata like filenames.

One of the easiest ways to do this is with an open source tool called foremost. Foremost recovers files using headers, footers, and standard data structures, allowing you to match files on a disk image. Usage is simple:

foremost -v -T -t (type) -i (file)

This enables verbose mode (-v), timestamps the output directory (-T), selects the type of files you want to search for (jpeg, gif, etc), and feeds in your dd'ed input image file (-i).

You can find previous DA posts about digital forensics here:

• An Inexpensive Forensic Toolkit
• Digital Forensics: When Users Put The Mass In Mass Storage
• Digital Forensics: A Few More Tips

How Does Your ATM Uplink? Or "Physical Security Humor As An Installation Art Form"

A recent trip to the ATM resulted in an interesting receipt as the ATM crashed. Note the debugging information providing connectivity details for the ATM. In and of itself, this wasn't a real issue, but it was interesting to see, as the ATM appeared to be working properly.

Once this three foot long error receipt printed however, we noticed something more interesting about the ATM.


That deep dark space to the left of the ATM contained networking devices, including the network uplink. Since this is a third party ATM on private property, it was not connected to the building's network.


The devices appear to include some form of serial or parallel device, an ethernet to PCMCIA bridge with an AT&T wireless cell card, and an antenna with a magnet to provide reception from the top of the ATM. Sadly, the strongest physical security control here is the sheer amount of dirt present. Nothing would prevent a malicious (or curious) person from placing a hub between the bridge device and the ATM's link to capture traffic. The cell network card could even be taken and used quite easily. Best of all, the ATM has no coverage with a camera system, and is in an area that is open at all hours of the day.

A number of very simple actions could be taken to greatly improve the security of this ATM and its operations.

• Secure the connectivity devices and network connections.
• Install a security camera, either in the ATM or, better, with a vantage point to watch the ATM itself.
• Prevent the device from providing debugging or error messages without entry of an administrative code or key.
  

The Security Mentality: Scary Security Guy?

I act as a stand-in instructor for an undergraduate security class a couple of times a year. Typically, I teach an hour or so about physical security, and lecture in coordination with the campus data center manager about data center security and operational security at the university. I tell a number of stories, and offer examples of how security design is done on campuses, as well as in the students' every day lives.

Each time I lecture, I ask the instructor about the feedback from the class. Typically, there is positive feedback, and often there is something interesting that the students will pick up on. The most recent class, however, had something new to say:

"Your friend is scary".

I'm used to scaring our datacenter manager - the security analyst's approach to systems is something I've talked about before. He knows that I analyze based on risk, and that while I may enumerate a wide variety of risks, that I'll work with him on the most plausible, and dangerous risks. The students, however, aren't used to assessing risk in the same manner, and don't think like analysts would.

This points out a problem: people rarely react well to things that are scary, and we don't want to be seen as paranoids. How can we avoid being the scary security analyst?

In general, we need to do three things:

1. Choose our battles wisely, and avoid being Chicken Little.
2. Be helpful, even when describing risk: cast the risk as an opportunity, or offer useful assistance and guidance.
3. Teach security mentality when possible.