I was working with a client recently, working through the move of a Credit Union branch.  In passing, he mentioned that they were looking at a new security camera setup, and the vendor had mentioned that it would need a SPAN or MIRROR port on the switch set up. At that point my antennae came online - SPAN or MIRROR ports set up a session where all packets from one switch ports are "mirrored" to another switch port.  Needless to say, this is not something you want to do for fun and giggles in a bank!

Anyway, I asked what the SPAN port was for, and the answer was that the camera server is set to capture the packets from the ATMs.  Apparently this has full support from the banking service providers and law enforcement, as it allows them to tie a fraudulent/suspect ATM transaction directly to the associated video clip of the person keying it in.  No tedious fast forward / reverse on the video, and hoping your timestamps all match up.

OK, but at that point it started to sound bad-bad-bad from a PCI perspective.  The question in my mind at that point was - did the banking provider give up their encryption keys to the video company, or is the ATM transaction data not as encrypted as it should be?

So, time to break out wireshark and take a look?  The answer to that question would be a resounding NO.  It was time to ask for PERMISSION to capture a test transaction.  If you've taken SANS SEC504 or SEC560 (or any of several other classes), you know that some days, the biggest difference between a successful security consultant and a potential convict is permission.

A week later, with permission in hand and my client with me, we did couple of $20 withdrawals and caught them "on film".  What we found was a 3rd possibility, and if I had thought it through I should have anticipated this result.  The transaction was all encrypted as we expected on tcp/3002, or at least obfuscated enough that the encoding wasn't obvious (I'll be digging a bit more into that, stay tuned).  But when it came time to print the receipt, the exact character-by-character text of the receipt printout is in clear 8-bit-ASCII text, all in one packet (including the required CRLFs, spaces and tabs) .  And when you opt to not print a transaction receipt, that "receipt packet" is still sent. 

If you've ever looked closely at an ATM receipt, the date, time, ATM identifier and often the street address will be printed, along with the dollar amounts and specifics of the transaction.  But the actual account identifiers are mostly represented by "*" characters, with just enough of the number exposed so that you can verify that things happened as they should.   Most of the captured packet below is blurred out (sorry, but it's against my actual account), but you can see some of the text clearly, and it's exactly as printed on the paper receipt.

As a side note, if you ever are in a position to look at a capture of this type though, you might find TCPDUMP easier to work with than Wireshark - Wireshark wants to decode this as IPA (GSM over IP), and of course that means all the decodes are messed up.  It's much easier in cases like this to just look at the hex representations of the packets.

So the stuff we really want protected is still protected, but there's enough exposed in that receipt packet that our friends in law enforcement can tie the video to the transaction, with help from the folks on the banking side.  A reasonable compromise I think, but take a look at your receipt next time you make an ATM withdrawal. 

Are you OK with the data on that slip of paper being sent in the clear?

If you are a QSA, are you still OK with it?

If I've missed anything, or if you've got an opinion (in either direction) on this, please use our comment form to post!

===============
Rob VandenBrink
Metafore