Thursday, April 03, 2008 10:16 PM
Never reveal too much - A tale on physical security
"Never reveal too much" - it's a motto that's applicable in many areas, including security.
Why does a failed attempt to log in into Windows result in "Invalid user name or password". Couldn't the system tell you just which field you screwed up? Yes, it could. But no, it shouldn't. Imagine an attacker trying to get into the system. First guess the logins (looping though a hypothetical series of "Invalid user name" messages) and once you got it right (e.g. Administrator, admin, TheAdmin, <name of someone who is known to be an admin>) move on to the passwords. Or better, use a tool that does the work for you.
There are lots of other examples, like disabling custom errors in web applications, resulting in revealing exception info that could contain e.g. the name (or more) of a database server you attempted to connect to. Anyhow, revealing too much is definitely harmful.
This evening I came back home after a busy day at work, walked through the front door of the apartment complex where I have to use my "radio key" to open the door. Visitors see this lovely touch screen device used to ring someone in the complex to have the door opened. It's just an embedded computer with some custom app that sometimes experiences troubles (luckily the door opening mechanism using the "radio key" isn't linked to it or I wouldn't be writing this post right now :-)). This is what I saw (click to enlarge):
I blurred a few pieces in red revealing company and product names but a few things are of interest:
- The "capture device" aka "camera" wasn't initialized - a nice hint for an attacker to start playing (assuming there are no other cameras in the proximity of course).
- Some detailed version information - always handy to search the web for known vulnerabilities in that particular piece of software (notice the version numbers seem to reflect dates, some almost 4 years ago == no patches in 4 years?).
- Information about the runtime, what gets loaded, port numbers and references to config files. We know at least what we can play with now.
But the possibly even more interesting one has been blurred in green: login and password in plain-text (you gotta believe me). The password isn't too long either (doesn't really matter, you already have it) and pretty predictable. Given the software and device are used in many apartment buildings and given the simplicity of both login and password it's not too hard to imagine it's the same everywhere. It also tells you where it lives.
- Why do you need to log everything to the console? Just write to a log file and tell something went wrong (but avoid pointing to the log file). Typically logs should go to a pseudo-well-known location (please don't make it c:\some.log - automated tools would love it). But of course protecting access to the logs is as important as this.
- What's the need to log the password to *anything* if it's already stored somewhere? It's clear that the "Resolved property" message is generic, revealing the password was just stored next to a bunch of other settings. Whether or not this particular password keeps something really secret is another question obviously.
- Hash (and salt) passwords, please! Not only to protect against usefulness after theft, but also to rule out the possibility to ever print it. I'm shocked every time a web site offers the possibility to "send my password" indicating they haven't (at least) hashed it before storing it. This means I've lost a password forever (deleting an account won't help - backups should have spread the secret). Notice the opposite (a site offering "reset password" functionality) doesn't necessarily mean hashing is applied but there's at least the conditional probability of it being so.
Everything in this section is purely based on imagination, not experience. The author is not responsible for any application whatsoever of possible acts outlined below.
A particularly nice property of touch screens is you can touch them :-). The application isn't touch-screen aware (meaning it would only enable the touch screen when initialization succeeded, and disable it when the application quits), meaning you can click anywhere, including:
Maybe there's more to find behind those other windows? Or we could browse Windows Explorer to find some other well-kept (ahum) secrets and with a little luck the thing is connected to the internet allowing us to submit data or install some piece of software to possibly allow us "to work from home". You might wonder what's there to steal? Definitely a list of resident names, possibly some telephone numbers, radio key data or more. There will likely be code that knows how to open the door since that's the intent of the device and maybe a little test-script to check the "open door" functionality is working properly (would be handy - purely for testing of course). Just make sure not to test the "Alarm Agent" :-).
You might wonder how to proceed with only a mouse cursor? On-screen keyboards maybe, depending on the edition of the OS installed? Or there might some keyboard in the unit if you want to turn it into a physical attack (or you can bring you own)... You could do that without the crash of course, but one might feel more comfortable knowing the camera is out of order. And you can always tell incoming residents you're there to fix the unit, just make sure to dress like a worker and bring a radio to set the scene. Or if it's a fancy machine hiding therein, BlueTooth might work too, hoping drivers are available and device detection is enabled.
And if you give up a simple DoS (for what it's worth - maybe the machine does more than operating the door) is at hand through Start, Shut down or "non-software based attacks".
Oh, and by the way the daylight saving time wasn't applied yet:
To be clear, I just took the picture, didn't touch the screen, made the observations outlined in this post and fired up Windows Live Writer.
Have a good (and safe) night!Del.icio.us
| Digg It
Filed under: Security