Threat Level: green Handler on Duty: Jan Kopriva

SANS ISC: ATM Traffic + TCPDump + Video = Good or Evil? SANS ISC InfoSec Forums

Participate: Learn more about our honeypot network
https://isc.sans.edu/honeypot.html

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
ATM Traffic + TCPDump + Video = Good or Evil?

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

Rob VandenBrink

521 Posts
ISC Handler
I appreciate that banks, at least my bank, give you the option of printing a receipt for you or not. I also like the option of being sent an email of the transaction if you wish. I rarely print receipts when asked to do so and when I get one from any source where sensitive data is present I will shred at home.
Jestermon

1 Posts
Quoting Jestermon:I appreciate that banks, at least my bank, give you the option of printing a receipt for you or not. I also like the option of being sent an email of the transaction if you wish. I rarely print receipts when asked to do so and when I get one from any source where sensitive data is present I will shred at home.


The problem is that you are still susceptible because even after shredding your paper receipt or declining to get a receipt altogether, the data could still be out there in the wild due to the clear-text electronic transaction.

Quote: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." ***
Alex Stanford

136 Posts
No; i'm not okay with the data on that slip of paper being transmitted in the clear; privacy concerns.

I understand the desire to correlate transactions to video, but traffic sniffing over the LAN is not a secure method of disclosure of transaction details.

I am all for the ATM sending a unique "transaction key / transaction ID number, and ATM Location/ID number" to camera systems, but not disclosing the transaction details to anyone who happens to be listening on the LAN.
Mysid

146 Posts
I always see receipt papers in the trash can next to the ATM's so sincerelly I don't know what is the big deal, what can someone do with this data ? Absolutelly nothing in my opinion. Nice article tough.
Mysid
1 Posts
Hey Rob,

I am fairly certain that the actual 16-digit card number is only obfuscated in most cases. I know for a fact that, in some cases, it's sent in Unicode plain text. I don't know if this is something specific to credit union ATM networks, to the ATM software itself, or to ATM networks in general, but from a security perspective, it's always bothered me. When I've inquired about this in the past, the excuse that I usually get is that 'the PIN is encrypted.' But as security aficionados, I know we'd like to see all of this traffic encrypted.

William
William McGlasson

1 Posts
It has been a long time since I checked on the regulations, but at one point, it was only required that the PIN be encrypted. Everything else was in plain-text.
It was also just DES encryption at the time and handled by specialized hardware.
I also know that user experience and speed are very high priorities, even higher than "unnecessary" extra encryption.
I believe you are expected to protect the traffic at the network level if it means that much to you with something like a point-to-point VPN or some other protected tunnel technology.

This really sounds like a case of regulations lagging behind the technology. We could encrypt the whole thing now without much performance impact thanks to Moore's Law. There are plenty of good reasons to update the regulations but if Law Enforcement is reaping the benefits of the weak security, I can't see there being any rush.

Of course, banks could also demand it but I imagine there is a super low priority on heaping even more legal requirements upon themselves.
Jasey

93 Posts

Sign Up for Free or Log In to start participating in the conversation!