16 comments

[ 3.4 ms ] story [ 47.8 ms ] thread
I saw this on /r/netsec a few days ago. One of the comments there mentioned that some POS devices are still vulnerable to the VNC authentication bypass exploit from 2006. The "we lose money if we patch"/"don't have time to patch, got this stuff to do" mentality is strong with this one.
That doesn't surprise me. I've seen these things (Aloha terminals) still running Windows 98. BOH was on Windows XP at least. From my experience, it's less about not having time, and more about being completely unaware of the requirement to patch the things.
The management of OS updates also falls between resposibilities. Probably, the shop/chain owners will be responsible for OS and virus scanner updates, and because of lack of knowledge on their part, have been cause of critical disruptions in the past.

I have some hands-on experience with POS-systems from the vendor side of things, and it has happened multiple times that a customer led security patch carnival has led to major issues (windows needing to reboot 3 times before it became stable enough to make a print again, seriously?).

I did some work with PoS systems in the early 90s and I shit you not the VNC password on the customer deployed machines was 'godmode'. These machines were still used, with the same password most likely, in 2010. Scary shit.
The fact that the writer could even get a used system that had not been wiped by the previous owner is a huge attack vector. This coupled with the fact that employee SSN's were stored in plain text makes a huge incentive for anyone interested in buying these things up on Ebay. Even if 1/10 wasn't wiped I bet it would still be worth it.
I legitimately don't understand why a machine like this would ever need to know an employee's SSN. I can understand why the employer might need to know it for tax reasons or similar, but why does the POS terminal?
I'd guess that they'd want to give each employee a unique id, and they used the SSN because it's something that every employee has to have, so they didn't have to generate a new id number and sync it up with their accounting software. This has obvious security issues, as we see here, of course.

They'd need it integrated per-employee with accounting, since it'd be tracking tips via credit cards which have to make it into payrolls and taxes etc.

I've worked with aloha in the past. These are usually installed in their own physical switch by the server. They think that makes them secure... It's a joke. Squirrel POS is just as bad. I try to push these kinds of folks onto cloud based systems these days.
What cloud based systems do you typically recommend?
Lightspeed POS is a solid choice. It depends on the customers needs.
Cloud based POS sounds like a nightmare if you had downtime...
Most Cloud based POS have an offline mode, which still allows you to process transactions. Vend (vendhq.com) stores a local copy of the information needed to process sales (products, taxes, payment types) and allows you to continue processing sales, although it restricts you to selling and you can't manage inventory etc
Thought I could contribute my 5c here. I have been working in retail for around 4 years now, and dealt with PoS systems extensively: searched for the right software (protip: there is none), developed a master DB for synchronizing the product catalog across several locations, gathered reports and maintained the infrastructure. After all, I find the lack of good PoS software frustrating (at least here in Norway). The more or less affordable solutions are decades old, running VB macros on top of MS Access databases, they are often incompatible with versions of Windows above XP. Everything seems stitched together over the course of many years by various WYSIWYG Studio dilettantes. Extending such software with new functionality is often hard or even impossible, which their developers admitted on several occasions. For instance, I've once got an estimate of $5000 for integrating an old DIGI scale, with a condition that I'd manage to find a datasheet for that protocol. I ended up writing a small COM port emulator and used it as a proxy between PoS and the real port.

Fun thing about PoS is the huge assortment of various hardware, and all of it could be abstracted in business logic. Almost every country has it's own ways of collecting taxes, own currency, own central company registers and different ways of reporting -- all of it should be considered when designing, a dream of every architecture astronaut. In addition come these necessary things like stock control, handheld scanners, BI, printing, Unicode (never seen it supported by any PoS; imagine running an international foods store with ISO Latin-1) and last, but not the least, user-friendliness.

I guess the PoS software market is much larger in the States, but what about the average software quality? PoS systems are not going anywhere soon, and I feel that a startup dealing with these issues could definitely see success. If anyone else feels like doing it, I'd be more than glad to contribute.

I'm the CEO of startup tackling this space. Hit me up hello at touchpoint dot io. You're right that this market is rife with garbage technology which represents a large opportunity, but the MVP to run someone's business is complex. Still, we're just starting to ship and have the attention of major chains. And not just because of our Unicode support, distributed dbs, or PCI-exempt security.
Just because Automatic Updates is turned off doesnt mean they haven't been applied. If they are running a custom build of XP-SP2 they could easily deploy and install updates on their own, no? Id be interested to look at what's installed.
I worked technical support for a POS company that was in a very large chain of fast food pizza joints, which was owned by a company that did POSes for a lot of customers.

Their security was abysmal. My SSH key had to be manually added to 75% of systems because the automated system didn't work. All of the systems were running on an EOL version of a desktop version of Linux.

On the topic of this video, on the machines were all employees SSNs in a Postgres database, along with loads of other personally identifiable information.