Hacking POS Terminal for Fun and Non-profit

 

Point-of-Sale (POS) devices are an essential part of modern life; the blood line for merchants. As plastic payment cards have become the default payment method, the security of POS devices has become more crucial. I was interested in learning how real-world POS machines maintain security but “close examination” without the owner’s consent is a crime. I have no friends in business using POS devices, so I decided to order a used device for investigation. The Aloha POS system is known to be very popular in the hospitality sector. (Figure 1)

 

 fig01.png

Figure 1 Aloha!

 

 

With Aloha POS systems, usually there are multiple Front-of-House (FOH) terminals and a single BOH (Back-of-House) file server. The terminals act as the servers’ access point, allowing for direct interaction to input new orders, swipe credit cards and print receipts. All transactions are logged and saved to the Aloha file server, which performs End-of-Day (EOD) transactions each day.

 

 fig02.png

Figure 2 Typical architecture of POS systems with Aloha

 

The system I acquired happened to be a master terminal (terminal 1) and would not normally operate without an Aloha file server on the same network. However, there is a fallback mode available where all transactions are handled offline, allowing the terminal to continue to accept orders and process transactions. I performed a lightweight pen-test of the system using that mode.

 

Port scanning

Figure 3 shows the results from NMAP scanning. I found file sharing related services (135, 139, 445), other MSRPC services (1801, 2103, 2105, 2107), and a VNC service running on port 5900. Interestingly enough, there is also a web server running on port 8080.

 

fig03.png

Figure 3 NMAP Scan result

 

VNC security

The first step in my pen-testing was to try to guess the VNC password. Ideally, passwords should be really difficult to guess, otherwise, you defeat the whole purpose of a password system (i.e. ‘something you know that other people don’t’). The first guess I made was so obvious (‘aloha’), but guess what? The password was correct – and I got access to the system on my first try. Moreover, this connection isn’t encrypted (Figure 5) so attackers with access to the infrastructure between the VNC client and the POS may be able to sniff the traffic.

 

fig04.png

Figure 4 VNC login screen

 

 

fig05.png

Figure 5 Unencrypted VNC connection

 

When you login to the terminal through VNC you may see a screen similar to that shown in Figure 6. You can minimize the POS program, access an Explorer program and perform additional attacks.

 

fig06.png

Figure 6 Connection to the POS terminal through VNC

 

Opened shares

The other basic issue is the opened share on the machine as multiple accounts exist including ‘aloha’, and ‘manager’. Again, the passwords were the same as the account names. You can use these accounts to access the root directory of the system drive of the machine with write access. (Figure 7) This may directly lead to system compromise by allowing modification of system files.

 

fig07.png

Figure 7 An open share

 

ATDDB.exe – Aloha Durable Messaging Service

Weak passwords and open shares are basic problems, but I wanted to find additional attack vectors. I searched for other possible entry points into the system. One of the services that caught my eye was ATDDB.exe. This program runs as a service and binds on port 8080. (Figure 8) It runs as a web server serving a SOAP service.

 

 fig08.png

Figure 8 ATDDB on port 8080

 

I couldn’t find good documentation on the protocol it uses. Also, you probably need the BOH service in order to use this inter-process mechanism. I had no way to create the necessary traffic with just one machine, but after digging into the binary itself I found that I could trigger a heap overflow issue by supplying invalid input to the HTTP request. (Figure 9) Even though I didn’t create a full exploit,  I did confirm that this is a legitimate heap overflow issue. So ATDDB.exe may be another entry point for attackers. And remember that ATDDB.exe serves SOAP messages, so if you dig more into the message format itself, you might end up finding more issues.

 

fig09.png

Figure 9 Heap corruption with wrong input

 

Security update issues

It seems the owner of this POS, or its management company, was not a huge fan of updates. Updates may interrupt business operation - especially when you are crazy busy with orders for lunch or dinner. You might not have the luxury of time to update your systems when hungry customers are waiting for their food. Then at the end of the day, you may have other priorities, or are too tired to take care of updates. There can be many reasons.

Updates were completely disabled on the machine I investigated. (Figure 10) The last time any Windows system files were updated was around March 2007, but I’m sure this machine was in use until early 2014 based on the timestamps of other files. This means that for over 7 years the system was vulnerable to whatever attack vectors were disclosed during that time. On a positive note - this POS terminal runs Windows XP SP2 Embedded with a stripped down version of services, which means that many exploits that run well against Windows XP would not run successfully against this flavor of OS. However, not applying security updates is not a good practice to follow.

 

fig10.png

Figure 10 Windows update is disabled

 

Stealing information

The Aloha POS system maintains a list of employees who can access the system. The employees access the terminal using their own magnetic stripe card which has their password recorded on it. I found a file containing the names, SSNs, addresses, phone numbers and access codes for all of the employees who worked for this restaurant. (Figure 11) This is highly sensitive information and its disclosure could easily lead to identity theft.

 

fig11.png

Figure 11 Employee database

 

Even though credit card numbers are not saved anywhere, gift card numbers are. (Figure 12) This information could also be used for fraud if it fell into the wrong hands.

 

fig12.png

Figure 12 Gift card numbers in transaction logs

 

Collecting credit card numbers

One of the main objectives of intruders who try to compromise POS machines is collecting credit card numbers. In our blog post about BlackPOS, we talked about a memory scraping technique. This technique is used when the credit card information transferred from the magnetic card reader is encrypted. But with this restaurant POS machine, the magnetic card reader is attached directly to the device and no encryption is performed. An attacker could simply use a normal keylogger to capture credit card information. (Figure 13) I had no problem acquiring the credit card number from the card that I swiped. The only problem I encountered, for some unknown reason, was that the characters repeated twice. However, this is hardly a road block to utilizing this information.

 

fig13.png

Figure 13 Keylogger capture (card numbers are obscured)

 

Conclusion

We just had an attackers-eye view into the security of a POS terminal purchased through eBay. What we found was that the overall state of security of the system was very poor. This was demonstrated by several findings, including the use of the eminently guessable ‘aloha’ for the VNC password. This insecure state could be especially dangerous if you offer free Wi-Fi access to customers without separating the networks used between your POS and your customers. Remember also that VNC connections are often used by contractors who manage POS terminals remotely, so attackers might be able to connect to machines from outside the network if proper access control is not implemented.

I also discovered a proprietary service created by the vendor and found an exploitable heap overflow in less than a few hours. (I suspect that the overall code base is not written with security in mind.) The final issue was the presence of legacy personal and sensitive information on the device. While the device I investigated was a FOH one, which means there was little chance of having actual credit card numbers saved on the device, I still retrieved a large amount of personal information about employees and large transaction logs of gift cards. Attackers who gain entry into POS terminals can also steal credit card data simply by running traditional key-loggers, as the magnetic card reader is recognized as a keyboard from the system’s point of view with no encryption being used during the process.

 

Comments
Facon12(anon) | ‎07-14-2014 03:59 PM

You are potentially getting duplicates of the credit card data the way that you are because the card read is probably reading track 1 and track 2 of the credit card and you logger doesnt know to distinguish that. 

Matt_Oh | ‎07-14-2014 04:04 PM

Hi Facon12. 

 

Actually the data is not duplicating in a way that track 1 and 2 repeats. Same characters just repeat twice like for "A", it becomes "AA" for some reason. The keylogger was hooking Windows message and maybe it is related to the way how the magnetic reader device driver works.

Textbook(anon) | ‎07-14-2014 07:20 PM

I install and provide tech support for over 150 individually-owned stores using Aloha POS.  The offline mode that the POS terminal is in will only last for 3 weeks.  It's called "redundancy mode" and if the computer hasn't received network communication from the ctlsvr service running on the back of house fileserver computer (server) in 21 days, then the software will stop functioning completely.

 

Our terminals are pretty much configured the same way and we're aware of the security issues.  We do not have our POS terminals connected to the internet.  They are only connected on the local network, and everything gets routed to the back of house computer for processing.

 

We have a VNC service running on the terminal so that we can log into the terminals from the BOH to provide tech support.  The VNC password is not aloha for us, since we configure the POS terminals ourselves we can set it to whatever we want.

 

We disable Windows Updates on the terminals because we don't even have our terminals connected to the internet.  Windows Updates are enabled and kept updated on each store's BOH.

 

The credit card processing software running on the back of house computer is called Aloha EDC and it is susceptible to memory-scraping POS malware.  We had two sites last year infected with the AlinaPOS malware via targeted emails that bypassed antivirus software.  That particular malware would scrape the card numbers from memory on the BOH computer.  We have since stopped using the Aloha EDC software for any new stores and have slowly been converting existing stores to the same system.

 

Our company is currently in the process of developing a custom POS software to replace Aloha system-wide.  Until then, we will continue to use Aloha POS.

Matt_Oh | ‎07-14-2014 08:43 PM

@Textbook.

 

Thanks for the really detailed info to understand the real world working environment. :)

asdfasfsdfads(anon) | ‎07-15-2014 12:45 AM

Interesting, but you need to attack the BOH server.  Unless it's a really screwed up environment, you won't see the terminals on anything but an isolated LAN / VLAN.  

iifdjasodiJASDOIA(anon) | ‎07-15-2014 12:47 AM

also, I believe the CHD is encrypted on newer terminals, and the reader does not emulate a keyboard.  

Matt_Oh | ‎07-15-2014 01:55 AM

Honestly, acquiring BOH server for pen-testing is not so easy. FOH research can reflect how overall environment might look like. Also, I believe some components like messaging services will be same on BOH. Definitely, it will be a good research subject to check with newer terminals.

Matt_Oh | ‎07-16-2014 10:25 AM

For the curious people, here's the product version of the software. I'm pretty sure this machine was used until it was sold early this year.

 

 

iber.png

 

 

Matt_Oh | ‎07-17-2014 11:07 PM

For the record, I'm putting the link to the NCR's response blog on this blog.

 

http://blogs.ncr.com/hospitality/hospitality/hacking-pos-terminal-funand-criminal-profit/

 

Techno-functional Payment expert(anon) | ‎07-18-2014 10:23 AM

Hi Matt,

 

Thanks for very detailed analysis of AlohaPOS. I read both your blog as well as NCR.

 

Assuming layered security infrastructure exists at enterprise level, moment back door access is obtained from BOH server, it's quite easy to play around with the FOH vulnerabilities. Things like passwords and shares can not be granted.

 

If some one can access as MIM ( Man in Middle) at FOH level ( Stores outlet's network) still may get through the access to credit card and employee information.

Tony Pelliccio(anon) | ‎07-18-2014 11:20 AM

Yeah, security is an afterthought on most POS systems out there including IBM's products. 

ertertertertertert(anon) | ‎07-18-2014 12:09 PM

It may surprise people but I used to work for a company that made POS and they would share the whole drive with full privileges and no password. When I brought this to someone's attention, they couldn't understand how this was a problem. All they could say was "Well, no one else will be on the network other than our stuff".  I will not name the company but the fact that they shared the whole drive with no password meant that anything could infect the OS.

 

Oh well.

| ‎07-18-2014 01:35 PM

If  5.3 is the core version that is old. 66.4 was out in 2008 and 6.7 has been out for some time. I cant say the new bulids are inherenaly more secure but upgrading once every decade or so problably isnt a bad idea.

geirb(anon) | ‎07-19-2014 10:27 AM

You probably get each character twice in the keylogger because it logs both the WM_KEYDOWN  and WM_KEYUP messages.

Matt_Oh | ‎07-20-2014 10:40 AM

Just for your reference, this article has been featured in computerworld, itworld, etc.

 

http://www.computerworld.com/s/article/9249825/Aloha_point_of_sale_terminal_sold_on_eBay_yields_secu...

 

Thanks.

erik hutson(anon) | ‎07-20-2014 02:00 PM

You hacked version 5.3, which is no longer even supported by NCR. Should be the responsibility of the owner to properly upgrade his systems to continue to meet PCI and securtiy standards. Aloha is now up to v12.3 and higher to give you a reference to how old this system is outdated.

Matt_Oh ‎07-20-2014 10:46 PM - edited ‎07-21-2014 01:50 AM

@erik hutson

 

I think the issue is more complicated than we think. Not so sure if the owners clearly understand the security implications of using old POS terminals. Should the vendor support almost 10 years old POS terminal? Not so sure. In real world, people are using really old machines and they are setup in very vulnerable way. I don't want to take who-to-blame approach. We better know the reality first to fix any problems and this blog only focuses on revealing basic truths.

William Sze (anon) | ‎07-23-2014 04:43 AM

Hi,The most interesting part of this is that it's being done by an HP researcher and the blog is actually on an HP.com domain. A lot of companies won't touch pentest research with a ten-foot pole, much less let people actually blog about it on the company website. Anyway I am little bit confused about my POS system which is in my shop.I am using POS system from Alliance Bankcard. I will consult with Alliance Bankcard about my POS system. Thanks for a valuable information. Thanks again.

Philimanjaro(anon) | ‎09-25-2014 06:09 AM

Great article, I appreciate all of this valuable information.

While another commenter pointed out, these POS devices are usually on an isolated network unless the environment is screwed up. I am a penetration tester with many years of experience, and there are more screwed up environments than there should be. In addition, there has always seemed to be a dual-homed server on the network that allows for network pivoting into this typically unroutable network. With that said, the not-so-fun part about being a penetration tester is that we must adhere to the proposed scope of the penetration testing engagement. As in, a client may ask us to test the security and potential exposure of their POS systems, but exclude other machines as part of the scope. A real attacker may hack the in-store password protected WiFi, use that to access the corporate network, compromise a system on that network with a dual-homed connection, and pivot in the internal POS network.


With these other potential attack vectors are sometimes out of the penetration testing scope, it doesn't give the company a real-world risk assessment. Point is, just because a POS network is technically isolated, this isn't a valid excuse to keep these systems out-of-date and completely vulnerable.  There is almost always a way into the network and underlying systems. No encryption? Open VNC ports that are probably vulnerable to the VNC Bypass vulnerability due to outdated software? These are completely vulnerable as the author has outlined. 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Twitter: @ohjeongwook .
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.