Pen Testing Payment Terminals: A Step-by-Step How-To Guide

[Editor’s Note: Here is a super useful how-to guide for penetration testing payment terminals by Miika Turkia.  Given recent breach news headlines, payment terminals are getting much more security scrutiny.  Bad guys are exploiting and undermining them, so we as penetration testers need skills to be able to properly evaluate the security stance of these payment devices.  Miika delivers by providing step-by-step instructions for evaluating the security of payment terminals.  And, furthermore, his suggestions and insights go beyond payment terminals as well, revealing some strategies and tactics we can use in all kinds of penetration testing.  Well done, Miika!  –Ed.]

By: Miika Turkia

There is plentitude of payment terminals out there and the design  principles vary quite a bit. The ones I have run into in Finland appear  to be tightly secured with no attack surface. At first glance, that  is. These generally open only outbound connections and use SSL encryption to protect the traffic. Here, I explain why testing a simple,  tightly secured payment terminal is not as simple as one might  think.

Background

The payment terminals we are talking about are tamper proof.  They  usually have Ethernet connectivity, and a serial line. The interface  open to normal user is the card slot and PIN pad, and in some occasions  contactless reader. The actual configuration does vary between models  and vendors, but the basic idea is that the terminal initiates all   the  connections and doesn’t listen to anything incoming.

Don’t forget the basics

When starting a pen test against this kind of a mute payment terminal, I  do the basic port and vulnerability scanning first. Even when the vendor  states that there is no services listening, I have discovered production  terminals with telnet open, and free login as root. This obviously means  pretty much the end of the game, or actually gives me more options to  play with the terminal, for example, the possibility to MITM properly validated SSL  connections. We have also had etherleak on some terminals leaking  interesting information. One should remember that when dealing with  credit card numbers, a tiny bit of data might be enough to leak a whole  card number to anyone listening.

Serial line

Serial line is occasionally used by cash registers to talk to the  payment terminal, mainly to instruct it the amount of the payment.  Fuzzing the used protocol over the serial line is somewhat lucrative. It  usually causes quite a few crashes. The trouble with pen testing production terminals is that one has no information about the  internals or what actually occurs inside the payment terminal on crashes. The only thing I know is that the terminal either reboots or goes to an otherwise inoperable state. Whether the vulnerability is actually exploitable usually remains a mystery.

I have used Perl or Python to talk to the terminals over the serial link  or the other interfaces. Since the protocol is usually “compressed”, it  is pretty much giving the hex codes for the commands and the values in  binary form. Also, a CRC check sum is calculated (you need to know,  guess, or brute the initial value). Nonetheless, unknown commands, strange command combinations, and unexpected values do cause enough    problems on the terminals. Be creative with your Sulley scripts.

To detect malfunctions, one should implement instrumentation. What I do  is run a NOP command every other instruction that I am sending to the payment  terminal. The NOP could be e.g. status query, or heartbeat, or whatever  the terminal implements. This method does sometimes give you the exact  input that caused the problem, but often not. You might get the crash  with a delay, or the terminal might go to some sort of error state and respond to ping properly, even though you cannot do any transactions  with it. This will naturally invalidate all the further testing before  the terminal is reset. One should also do visual inspection on the  terminal as there might be something interesting on the screen, or you  can get a better idea on the instruction that caused the trouble if you  spot the terminal booting before instrumentation notices it.

There are also reportedly badly implemented terminals that leak error  information or even contents of the memory on the terminal’s small screen . One should probably install a camera with motion detection  to grab a “screenshot” when something changes on the terminal screen.

Acting as a controller

Since payment terminals usually support control from a cash register or  a slot machine, one can use the protocol to e.g. instruct the terminal  to return money to the card. A simple serial protocol usually means that  you can just send simple commands to the terminal such as messages to  display on the screen, or how much to charge. More complex protocols e.g. (usually over Ethernet) typically require one to write a server side  emulator to act as a cash register or a slot machine. The handshakes  must be right, along with all the standard pings and other queries.

My approach has been to implement a multi-threaded application that  performs the keep-alive functionality and answers to any standard  queries automatically. My server also listens on a master socket for any  incoming commands that I might want to inject into the stream. This  allows me to test different states, and also with modifying the server side, I can fuzz any of the automated states of the protocol.

As you can imagine, it is quite time consuming to test these more  complex protocols especially when they don’t recover well from  unexpected input. Power cycling the payment terminal is often needed.  Even with its limitations, this approach has allowed me to return the  paid amount to the card, or even a considerably larger sum. And  naturally the fuzzing has caused countless reboots and error states.  With some customers, the fraud detection should catch the incorrect  returns to the card, but I highly doubt that all merchants have such  processes implemented.

Pretending to be the payment mediation server

If one assumes that SSL protected traffic from payment terminal to the  payment mediation server is secure, once again you might be quite wrong.  It is surprising how often a MITM attack succeeds as the server  certificate is not validated at all, or is poorly validated. A long  certificate trust chain just might fool the payment terminal. Also, the client side ciphers supported often include very poor choices, starting  from NULL cipher to anonymous Diffie-Hellman. Getting to this MITM  position gets you the credit card numbers from the terminal  immediately  with no additional effort. On some occasions, it is enough to just listen  on a port that gets the payment terminals requests and log the card numbers, no need to talk back.  If you are less lucky with the SSL  configurations, then downgrade attacks might fit the case.

Physical

This is something where I have no experience. So far I have trusted when  I was told the payment terminals were tamper proof. I know this is  misplaced trust as experience has shown that one has to test  everything, since the implementations often have flaws in them. At least on software side, there have been so many mistakes even in rather simple   implementations. But if the engagement does not allow me to physically  tamper with the device, all the bets are off.

PIN pad

The only interfaces a normal end user has to payment terminals is usually the PIN pad and card interface. Surprisingly often, you can find  a maintenance menu when being creative with the keyboard, or resetting  the terminal. When protections are missing, you might be able to  reconfigure the payment terminal any way you can imagine, however, I have not seen this flaw in a few years.

Card interfaces

The card interfaces include magnetic stripe, contact and contactless  readers. Magnetic stripes are quite easy to “forge” with cheap hardware  that easily writes you new magnetic stripes. Then the testing process is  to write a card and swipe it. And repeat after repeat always inspecting  the results manually/visually.

EMV contact interface is more interesting since it is much more complex  protocol. The payment terminal actually discusses with the card instead  of just reading the data out. A programmable smart card is the way to go in this area. Or you might be able to grab a development board that you  can hook up to your computer and control the contact interfaces more  easily. It takes quite a bit of learning to write a fuzzer on a smart card, and especially quite a bit of time.

The contactless interface can also be tested with these programmable  smart cards. However, a Proxmark or Chameleon might be better suited for  contactless testing than the programmable smart card. Since  programming these devices is easier than re-flashing the smart card, the fuzzer implementation should be easier and faster, especially when testing.

This is an area where we are lacking the options for testing. I am not  aware of any fuzzer that would be publicly available and so far, I have  not had time to implement this myself. This is a real shame as I am  quite confident that the contactless interface fuzzing will bring a lot  of new vulnerabilities into light from the payment terminals. This is  also an interface that can readily be used to attack the payment terminals on any store. The contactless interface even allows longer  term attacks to be performed from afar utilizing a directional antenna.

Update features

The payment terminals I have been testing check for updates once in a while, e.g. every 5 boots. This tends to be totally insecure, allowing me to replace the firmware on payment terminals, or receive quite a bit  of internal information by just eavesdropping the traffic. Even when the firmware installation validates the package properly, I have been able to force the installation of an older version of the firmware  with some weaknesses in it (e.g. open telnet service). If the terminal  cannot be downgraded, it might still be possible to install another  customer’s newer firmware on it. (Sadly, this route has bricked the  terminals for me so far, as they start to communicate to different  mediation and payment servers that are not reachable from the network that I  have been testing on.)

Gaining access to the internal interfaces

Obviously, I have done most of my gigs so that access to the payment  terminal has been arranged. However, if you are doing it over the  network, the serial line might still be reachable. Almost all the master  PCs, cash registers or gas pumps I have tested so far have been easy to  compromise. Unpatched Windows XP is not uncommon to be talking to the payment terminal over a serial connection or some application level  protocol over an Ethernet interface. Once you compromise the machine  that is instructing the payment terminal to charge customers, you do  most likely gain access to these interfaces as well.

One should also remember that some of the payment terminals talk over a  WiFi connection and might thus be susceptible to standard WiFi attacks  or eavesdropping. Even if you cannot hack yourself into joining the WiFi  you can still do fuzzing on the WiFi protocol stack of the payment terminals.

What’s missing from the picture

Proper ways to debug and see what is going on inside the payment  terminals has so far been out of my reach. Even if some of the crashes  caused by fuzzing would be exploitable, I do not know, and cannot even do, proper analysis being blind to the internal operations.

Good tools to test the EMV protocol along with contactless (NFC) interface are not generally available, or are extremely difficult to  setup. Charlie Miller’s paper “Exploring the NFC Attack Surface”  describes the NFC fuzzing part and should be a good base to start fuzzing the EMV layer. But any input and tools to help in this area are  appreciated.

I hope this write-up is a good starting point with new ideas about how  to improve the testing of payment terminals and provides a  comprehensive list of things to check when testing payment terminals  or similar embedded devices (and the tools and methods to accomplish  that).

Conclusions

Even though a payment terminal is locked down pretty well on the  surface, there is still a lot of work to be done to properly test  different attack vectors. Plenty of different attacks have worked before  and new methods must be developed or discovered as the holes are being  plugged. Currently this means custom code for all the different  environments and terminals – quite a time consuming effort.

When everything else is tight and secure, the master PC, cash register  or gas pump PC are probably still an easy targets to give you more  leverage and the possibility to talk legitimately to the payment  terminal.

–Miika Turkia

Five Things Every Pen Tester Should Know About Working with Lawyers

[Editor’s Note: Here is a great article by John Strand about a topic that is sometimes difficult for pen testers: interacting with lawyers.  But, John engages the topic in his signature fun, quirky, and highly informative way that provides practical insights into how to keep yourself safe and legal when dealing with some sticky issues in penetration testing.  Nice work, John!  –Ed.]

By: John Strand

Ed absolutely loves sharing the various challenges of professional penetration testers.  We have had a couple of instances here at BHIS where we have had to walk away from contracts because lawyers have gotten far too involved in some of our contracts.  So, just a small bit of background before we delve into the insane antics of various wielders of legal might.

We have had a couple of contracts at BHIS where we had to move to a no bid position, effectively walking away.  It is a tough place to find your company.  But, as professional penetration testers, we need to be ready to move to this position if necessary.

Just remember, the single greatest negotiation tactic you can employ is being willing to walk away.

Oh, just for the record up front, I for one, welcome our legal overlords.  :)

1.  You can always be sued.

First and foremost, you need to understand one simple rule: you can always be sued.  Please, say this to yourself before you go to bed or tattoo it on the forehead of your first born. Our legal overlords tend to like that sort of thing so do whatever it takes to engrain it into everything you do.

You can always be sued. There is nothing you can ever put into a contract to prevent this from happening.

Who has thumbs and loves lawsuits? This guy!

We recently started re-reviewing our indemnification clause.  This was necessary because over the last few years we have tweaked it based on requests from various attorneys of our customers.  This sounds awesome, right?  Having multiple lawyers review your documents is like free legal advice. Yea!

But here is the deal. Have you ever had multiple English majors review a paper?  They all have different gripes.  They all find different things. And they are all convinced they are absolutely correct.  Lawyers are almost exactly like this.  They will find little words to change here and there based on whatever instructor they had in law school.  And, over time, it will reduce your indemnification clause to tatters.

I often hear students of SEC504 and SEC560 ask how they can keep from being sued.  It is almost as if as a society, we somehow think we can put in a magic clause to stop all lawsuits and there is ample evidence that this may be the case.  Read through any end-user license from any large company and there are tons of examples of insane clauses that reduce a consumer’s rights.  But, these companies have something you do not…a harem of attorneys.

Not a single comment I could come up with was
family friendly…so here is a picture of a cat thinking. –John Strand

However, you can reduce the risk of being sued successfully.  This is paramount.  Most lawyers will not push to litigate unless there is a good reason for them to believe they will win.  Remember, in civil courts, the party with the preponderance of the evidence wins.  Having a good indemnification clause and being very careful in your testing activities will help.  What does it mean to be careful in your testing?

Glad you asked.  First, it is staying in scope.  Second, testing your exploits on a lab system before launching an attack. And third, recording the fact you tested your attack.

2. How Lawyers Think About Pen Tests

Let’s set the mindset for many attorneys we may be dealing with.  First, they tend to be highly critical and detail-oriented.  This is generally a very good trait for attorneys.  Unfortunately, it is a horrible trait if an attorney has no idea what it is you are doing.  This is going to be the case for a high percentage of your contracts.

As we teach in the SANS Security 560 class, there are four documents that make up a solid basis for doing a penetration test.  First is the Proposal itself. Second, is the Scope.  The Scope details what is going to be tested, what is not to be tested, and, finally, which system/users/services need to be treated with extra special care and love.  The Rules of Engagement establish how you are to test.  This document will cover points of contact, times, and notification trees for critical findings. The last one, the Permission to Test document, we will cover in a moment.

Why do we break out the Proposal/Contract, Scope and Rules of Engagement? Can’t we just put them all in one doc?  First, it is possible to do so, but things might get muddy. If you put everything in the contract, it has the possibility of diluting the full impact of each of these documents.  Here is the problem. Many attorneys will try to ask questions like the following in the proposal:

What are you testing?
What are you not testing?
What are you doing to protect our systems?
How will you notify us of critical findings?

See, the above questions are highly important, but not all that necessary in the Proposal.  To address this issue up front, put a line in your Proposal that the issues above will be addressed in the Scope and Rules of Engagement and will be handled in separate documents.

We want to clearly point out that these issues are covered in separate documents for two reasons.  First, they are addressed in separate documents to bring the focus and clarity to these important issues. Second, many of the items in the Scope and Rules of Engagement are sensitive and should only be shared in the event the contract and NDA is signed.   It is far easier to get a contract, sign an NDA, then address the Scope and Rules of Engagement for specific projects.  Plus, the overall contract and NDA might apply to multiple different projects, each with their own scope and rules of engagement.

We have found this works with 99% of the lawyers we work with.

The other 1% got their degrees from Harvard

3. There will be contract revisions

This is a reality of any contract negations you enter into.  It is almost as if people demonstrate their value by marking up other people’s documents.  We have discovered this need is far stronger in lawyers.

They have to justify their existence in some fashion, just as every other human on the planet.  If they simply say every contract is “OK”, they will be fired quickly.  Understanding this is key.  Do not get angry.  Do not threaten them.  Simply smile, acknowledge their issues and address them.  I have seen many consultants complain for hours about some small issues lawyers found in a contract.  It is wise to point out to people who get into this type of pity party that if they spent the time complaining about some small requested changes as actually making the changes, the document would be done.

In short… treat them like Happy Fun Ball

Providing affirmation to the lawyer and their contributions will also help you with not just your current contract negotiations, but also on future contract negotiations.  Over the years, we have noticed that giving lawyers warm fuzzies for their changes helps bring them on your side. If you approach the contract negotiation as me vs. the attorney, it will be you vs. the attorney.  You will fight. Life will be miserable. There is an old saying my grandpa said about situations like this:

“Sure, you can wrestle with a pig in the mud… but remember, the pig actually enjoys it.”

Don’t ask me why my grandfather was wrestling pigs in the mud.

What lawyers wrestling with pigs might look like

Anyway, find a way to get the lawyer on your side.  A great approach is calling the attorney, one on one, before any meetings to address their corrections.  Do this before you get into a meeting.  We have discovered if you give a lawyer a stage in front of others, they will use it.  If you can enter the meeting with most issues addressed beforehand, they are on your side.  If they attack you, they would be attacking the work they did with you prior to the meeting.

4. They will want to cut your indemnification clause

This is the big one. We recently had a contract where the lawyer wanted to strike our indemnification clause and replace it with one that stated we would be liable for all damages.

Yea-ouch!!!  That should never happen.  Ever.

In fact, this contract is the reason for this article.  I called Ed about it to complain.  And he asked if I could do a write up on it.  See, this article is therapy.  It is part of my path towards acceptance.

Why would an attorney want to strike an indemnification clause?  Because they are doing their job. Their job is protecting their customer. And having a contract where a company is doing potentially damaging things is completely anathema to how things normally work.  It is going to take some time and effort on your part to train them on what you do.  This does not mean you should be condescending and talk down to them.  It means you should do your absolute best to let the lawyer, and sometimes the customer know what a penetration test actually is.

Ed has a great quote on this:  “If a penetration tester promises they will not crash a system, it means they are lying to you, or they are not planning on sending any packets to your network.”

However, there are times where a lawyer will not budge on the indemnification clause in the Permission to Test which brings us to…

5.  Know when to walk away  

Look, lawyers are awesome.  We love ours at BHIS.  However, they do not run our company.  We have found some companies are effectively run by their lawyers.  After all, a lawyer can wield a tremendous amount of power because so few people know what they are doing.

If you find yourself at odds with an attorney, and there is no one else to talk to, you have run into a company that is run by their lawyers. Lawyers are there to advise. They should never be making final decisions. If they want you to strike the indemnification clause in the Permission to Test, it is time to walk away.

There may also be some very broad language you may run into which is unrelated to indemnification, but can be equally dangerous to your company.  A contract I am working on tonight has the following gem in it.

“Company also reserves to rights to all intellectual property created by consultant related and unrelated to this contract in perpetuity.”

Yea, like you are going to hand over any and all intellectual property to your customer till the end of time.  We have found clauses like the one above lurking in more contracts than we care to remember.

We are becoming an industry that is growing more and more restricted by laws and regulation.  There is not a whole lot we can do, other than become more versed and familiar with how to interact with lawyers.

–John Strand
//

 

Upcoming Training Opportunity:

Learn more about the latest attacks and techniques used against organizations at the SANS Pen Test HackFest Training & Summit. This year’s HackFest Summit features two days of leading talks from top experts and then six days of hands-on, immersion-style pen test training in one of our seven courses to choose from! Learn and develop your offensive techniques as you strive to better defend your environment. Whether you are a penetration tester, red team member, a forensics specialist, or cyber defender, the techniques covered at HackFest represent the latest and most powerful attacks every organization needs to thwart. You NEED to be there! http://www.sans.org/u/kqa

For more free educational resources, follow:
//