So the hack is a classic kiosk mode breakout, like you could try to do with poorly secured public computers. The wonder here is not in the hack, because it's just a set of keypresses and mouse clicks. The wonder instead lies with the the manufacturer who made a safe stupid enough to be bypassed with a mouse and keyboard.
Who put the USB port on the outside? The article made it seem like they didnt need to use the USB port for normal operations (unlocking/locking). So why didnt they face it toward the safe or disable access somehow until the safe is unlocked. I'm not going to even touch on the Windows XP issue.
I am guessing it's a failsafe in case the touch screen on the safe fails and they need to plug in a keyboard to open it / diagnose it. It's a legitimate thing to do, but you would think that the USB port would have protection.
For instance, the USB port could be on a daughter board, and requires you to enter a password on the plugged in keyboard before the daughter board would complete the connection to the main motherboard.
The really simple method would be to at least have a USB Lock that plugs into the USB port, and once locked it hooks into a USB port and if physically ripped out without unlocking, it would rip out the USB port with it. This is something they can retrofit quickly while figuring out other problems with their software problems.
Auto-enabling keyboard input at all is totally crazy; if you can type you can compromise something. my last startup (it's still around, just without me) makes kiosks with touch displays and accessible usb ports, and disabling that shit was the first obvious move.
We then allowed them to be re-enabled selectively based on a challenge-response touch screen input (didn't require connectivity, just pre-shared keys to verify the response) or via our server (if connectivity was stable and the touch screen had an issue).
Assuming you have a team competent enough to build a platform that you can at minimum reboot and ensure it'll always come back up, you'd never, ever want to automatically let someone access your system.
I see people getting upset all the time about cashier tills running windows xp - but that doesn't make any sense. If the software works fine in that situation then it could be just as well running windows 3.11 and I don't see a problem.
There are unpatched 0-days that go back years that still make WinXP dangerous to have on any sort of network. Not only that, but they will never be fixed. Nor can you fix them yourself (no source code).
And yes, cash registers will be networked because of data mining. I can get an accurate picture of store utilization solely by watching registers. And also by seeing what was purchased, I can change inventory appropriately. So yes, networking is essential. Perhaps it's not for the small business that handles flea markets and such.
Windows XP Embedded is still supported and still gets security patches. I'm also pretty sure you can get the source to it too, if you pay Microsoft and sign an NDA.
Windows XP; the security researchers favorite distro.
There are few things better than showing up to a security review gig and have them running XP. Makes my job super easy and clients love when I rain down bugs. It's even better because we can actually write exploits in a short time frame. Love XP.
Somewhat related, check this out. In the video they theorize that the power line attack is obfuscated by software techniques. An old OS may have buggy USB drivers I can imagine but they claim the OS does not matter.
"0-day" is a vulnerability that's discovered at the same time there are already exploits in the wild. It means you have zero days to get a patch deployed before the target is vulnerable to attack. Obviously a very bad situation to be in.
And yet these days it gets thrown around as if it describes the severity of the vulnerability itself. Thus the above scoffing at "0-days that go back years". What does that mean? It's like saying you have a matinee movie on blue-ray that you'll watch tonight.
I suppose one could have a patched 0-day? It would need to be be fixed by the vendor without them ever acknowledging the underlying issue existed, right?
As for the "go back years" bit, the guy just has some XP vulns that were found ages back and he's never released them, and of course they still work.
So the machine connected to your Windows XP tills has internet access and/or external storage enabled. Of course that's not safe....if I said "not connected to a network" would that be better?
Nope. You just flipped one of your caveats: no internet connectivity.
I only specified networking.
Its also how Target was attacked. Their registers are networked yet there was a hole from the internet to their corporate net. That hole was through their HVAC control system.
The Tl;Dr. Is that you design a secure system, so that if one part fails, the whole system doesn't fall like a house of cards. Security through layers.
You can say that... but I think GP's point is that there's an obvious behavioral pattern to that, which is less data mining of your sales info and customer's buying habits, compared to the sometimes unobvious but major downside of the terminals being hacked. I think we've seem what choices businesses make when presented with the obvious upside over the poorly understood downside.
Evidently it's not completely secure if you can add an external keyboard and it's in kiosk mode.
(Having worked somewhere close to the field of XP-for-POS, the answer appears to be that the customers really do not like having to do updates. They'd much rather just firewall the tills and hope they don't suffer a stuxnet. They're attacked surprisingly rarely because you can't steal money over the internet this way.)
10+ years ago I was at a public library with terminals that were in kiosk mode with IE in fullscreen, hidden start menu etc. I used a paperclip to eject the cd drive, put in a CD with autorun, and voila, visible start menu and was able to get to the internet from IE
Exactly. Often in BigCorp type places bugs are classified as deviations from requirements. If this poor design was the requirement, then any objections that may have arisen would've probably been classified as suggestions instead of bugs.
I have to think even the most myopic bureaucrats would remember to include "cannot be opened except by authorized parties" in a requirements document for a safe.
Yes, but all that will achieve is a tester writing it into their plan to check that invalid credentials don't let you in. It will not magically teach programmers to write secure code.
The bit I was replying to was a hypothetical situation where QA does, for some reason, find the flaw but management rejects it because it doesn't match a bullet point in the requirements. My point was just that if that's not in the requirements then you have even bigger problems. I never claimed or even implied (because I don't believe) that writing down that requirement would actually achieve anything.
Seriously -- this is ludicrous. I founded a hardware tech company a few years back that does a similar thing (machines in very public places) and -- knowing approximately dick about building robust hardware -- auto mounting of input devices was basically the first thing I locked down once I had the basics up and running.
