Photo Kiosks Infecting Customers' USB Devices 288
The Risky Biz blog brings news that Big W, a subsidiary of Woolworths, has Windows-based Fuji photo kiosks in at least some of its stores that don't run antivirus software, and are therefore spreading infections, such as Trojan-Poison-36, via customers' USB storage devices. Here is the account of the original reporter. "It's not just the lack of AV that's the problem... it appears there's been zero thought put into the problem of malware spreading via these kiosks. Why not just treat customers' USB devices as read-only? Why allow the kiosks to write to them at all? It would be interesting to find out which company — Fuji, Big W, or even some other third party — is responsible for the maintenance of the machines. It would also be interesting to find out if there are any liability issues here for Big W in light of its boneheaded lack of security planning."
Read-only switch for USB sticks? (Score:3, Interesting)
Responsibility (Score:5, Interesting)
I would guess Fuji is responsible for these machines. I work for Target, and ALL equipment, kiosks included, in our Kodak labs are serviced by Kodak field techs.
Incidentally, we are allowed to connect guests' media to the kiosks ONLY, never directly to any other lab workstation, because the kiosks are (or at least are supposed to be) far better locked down, including treating all media as read-only.
Surely the title of this article should be... (Score:5, Interesting)
Re:Use file permissions. (Score:5, Interesting)
And what makes you think that the Kiosk software can read a NTFS USB drive ?
While I cannot speak for the specific types of machines mentioned in the article, I DO know that a lot of the local machines over here are using some funky Linux flavor (presumably to keep costs down), running off flash ROM. And they generally expect you to deliver the data in a FAT32 partition if you provide a USB drive.
Then again, if the software is Linux, Then there usually isn't that much of a problem with viruses hopping from one device to the next, I'd wager.
Yeah, so? (Score:5, Interesting)
They ran a hardened win2k, no network services, autorun disabled, afair execution for all drives but C: disabled.
So how the f* would they get infected in the first place?
Lazy techs, at least that was the #1 cause for troubles for back then, everything from re-enabling services to installing 3rd party RA software with no/weak passwords...
I also want to know if they copy my pics! (Score:5, Interesting)
The kiosk situation is generally lousy.
Do they keep a copy of all my pics?
They make a copy (they have to, to display thumbnails), but is it temporary or permanent ("To improve the quality of our service...").
There should be a law prohibiting the keeping of copies without express permission, and they shouldn't be allowed to make unrelated functionality dependent on the user agreeing to let them keep a copy.
Copyright law might work here, but I imagine the kiosk companies have found a way around that. Maybe there's a "Terms of user" stick on the back of the machine mentioning that they keep copies, etc.
Have you seen an infected ATM? (Score:3, Interesting)
A couple times I have seen an ATM that has crashed, BSOD or shows a windows logon screen -- And we're supposed to trust our money with these tin can openers? WTF?!
Poor design.. (Score:5, Interesting)
Why run windows on these kiosks? An embedded OS would be more suitable and cheaper...
Why execute anything thats stored on the usb sticks? That's just colossally stupid, i could understand if some malware was getting onto the devices by exploiting a bug in the jpeg parser or similar, but executing any code on an inserted device is just ridiculous.
Why is the inserted media not mounted read only? These kiosks only need to print photos, they don't need to write to the media.
Why is the system drive writable?
Why is the kiosk software running as a privileged user?
The idea of installing antivirus on them is a stupid one, it will increase the cost, require the kiosks to be updated somehow (either necessitating frequent engineer visits or require a network connection), and no antivirus detects everything (i often do incident response when a customer system has been compromised, in every single case there has been some kind of av product installed and it failed to detect the compromise even tho in most cases the malware installed is well known to other av products).
Also an av product may detect a false positive on a customer's media device and delete their data which could open the kiosk vendor up to potential liability.
Instead, run an embedded linux on these systems...
the frontend software is custom written anyway so could just be written for linux instead without too much difficulty..
less to go wrong since such an os could be stripped to its bare minimum
less cost - there would be no per unit licensing costs..
mount any customer supplied media readonly and noexec.
boot the os from readonly flash so the os cannot be tampered with and any problems a reboot will restore it to default/clean settings
use ram for temporary storage (or a small disk which is reformatted at boot if more storage is required) so after a power cycle, anything left on there is gone
if any persistent storage is required (eg for logs) use a remote syslog server, a receipt printer, or a small disk mounted noexec
use something like an internal readonly compact flash card for the os, when an engineer has to upgrade all he needs to is swap the card out.
Re:Use file permissions. (Score:5, Interesting)
Blame Microsoft...
There are plenty of open royalty free filesystems out there, but MS refuse to implement them and want you to pay royalties to use their own filesystems instead, so people use fat32 because its the least patented of the few filesystems MS do bother to support.
Re:Every input is bad... (Score:4, Interesting)
In addition to that - disable the autorun feature in the kiosks - that's probably the most likely reason why they are infected.
U3 is also a culprit here.
Re:I also want to know if they copy my pics! (Score:5, Interesting)
I know BigW keep them for up to a week - stuck disk in all the thumbnails up and I asked - how long do you keep them? Up to a week as customers often come back. Can you delete them for me now? No.
I haven't been back there to have photo's printed. and any shop - i grab just the pics I want printed and put them on an sd card and put that in.
Why feed the Beast more than it needs to? If we don't make the data available, the Beast can't eat it.
Re:Every input is bad... (Score:5, Interesting)
No, they don't teach that any longer. I was up on my soap box on the issue and the general response was "but that just introduces bloat!" and was modded troll. I seriously couldn't believe what I was seeing. The fundamentals have been forgotten or ignored lately. It explains a lot. These same people were telling me that "regex" is better than the primitive methods I described for input validation -- the primitive methods I described were to be simple, compact and likely in assembler. I was like "what do you think a "regex" does? Magic? It does the very same thing I described but in a higher-level language. These people all believe in the magical black box.
Re:Use file permissions. (Score:4, Interesting)
The word "pointless" comes to mind. First, any decent virus that *wants* to can just disable your protection immediately. Literally one line of code. I would be shocked if the virus-libraries that are out there don't already have a set of routines where you just pass it a filename that you *want* to write and it does all the fancy trickery to try to write to that file no matter what (e.g. mount the media, relax permissions, make the current user owner, overwrite the file entry entirely etc.) and then possibly even clean up any "changes" after it's done its job (e.g. restore permissions). Relying on the fact that you haven't seen a virus that knows how to change permissions on a file that stands between you and infection is *stupid*. Viruses, almost by definition, act with full administrator privileges by extremely cleverly executed buffer overruns and other attacks. You really think that a non-permissioned (but permissionable) file can't be accessed/changed automatically by something *TRYING* to write that file by an administrator privilege program written by the same person?
Your "solution" is a temporary, ineffective workaround to stop a single USB device from having its autorun information changed if the "attacker" puts zero effort into it and doesn't use quite obvious and simple code to take account of *any* possible situation that one of it's victims may have (i.e. don't expect everyone to write-protect their autorun.inf, but do expect *every* write access to fail and keep trying different ways to get them to work). Saying that you're then "immune" to all autorun viruses is stretching it a bit. It's only as secure as the fact that the virus respects the disk as an NTFS structure, uses the standard NTFS routines to access it, is running as a user that can't modify the permissions (unlikely by that point) and doesn't bother to just blindly wipe permissions on any file it wants to write to. Also, NTFS USB sticks? Yeah, right. About as popular and readable in random machines as ext4 ones. And to be honest, just making it an ext2-disk with the ext2fs driver probably renders it MORE immune to autorun.inf creation/execution.
The "solution" to this is to not have autorun enabled on your USB drives at all. WHY? What is the purpose? To save you a double-click. That's it. And it opens up arbitrary execution to any device that poses as a USB stick (even my 3G modem has writable USB storage, so I'd have to apply the same principle to this and every other device that I autorun - my phone, my 3g modem, my external hard drive, even ordinary USB devices are coming with "driver" partitions that install the drivers from an autorun partition on the device on first use). Or I could just switch autorun off. If the USB stick is compromised, then it's compromised. No amount of fancy permission-fixing will fix that and it's just as likely that a virus hunts down my JPG's and inserts some payload that crashes certain JPG-reading applications. Or just modifies the MBR so that if I leave it in it will autoboot and silently infect my PC. Or infect anything else executable / readable on the stick. It overwriting my autorun.inf is the LEAST of my worries and much more easily and permanently fixed by a built-in Windows option on a per-PC instead of per-stick basis.
Don't let things automatically do stupid shit like auto-update and/or auto-run without you knowing what they're doing.
The problem with viruses these days is not the viruses - it's the *stupid* and *ridiculous* attitude to an unknown third-party running arbitrary code on the machine that holds your banking details, etc. "Oh, I got a virus the other day but I think I cleaned it off", people running with viruses without realising for months, if not years, and people thinking that anti-virus does *anything*. Don't half-arse it. If you're smart enough to disable autorun, do that. If you think your USB sticks stand a risk of being infected, wipe them before you put them anywhere else (by inserting into an autorun-disabled or, better, Linux m
Re:Read-only switch for USB sticks? (Score:3, Interesting)
Re:Poor design.. (Score:1, Interesting)
Why run windows on these kiosks? An embedded OS would be more suitable and cheaper...
No it won't be. Developers that can do development on an embedded OS are few (and very expensive), while Windows UI developers are a dime a dozen. That goes for testing, system integration and support staff as well. These kiosks are sold at a much lower volume than mass consumer electronic products so I wouldn't be surprised if the cost of the machine + OS is dwarfed by the personnel costs in developing and supporting the system.
No, not so much (Score:3, Interesting)
MS does nothing to stop you from implementing any file system you like in Windows. In fact, they've got documentation on how to do it. It's called the Installable Filesystem Kit, which is part of their driver development kit. You can easily write your own file system drivers for Windows.
As an example have a look at http://www.fs-driver.org/ [fs-driver.org]. They've got an ext2 driver for Windows. Install it, and ext2 is a file system Windows understands and works with, just like any other. There are others too, there is a commercial HFS (Mac) IFS if you need it.
The problem is not that MS won't allow people to implement other file systems on Windows, they allow it easily. The problem is people are not at all interested in doing so. MS themselves are not that interested because they have a good file system. If you read the info on BTRFS it's goals read like an NTFS feature list. NTFS does what tehy want for a modern filesystem for their computers. For simpler devices, there is exFAT and FAT32. They need nothing else.
Also FAT is so widely supported because it is old (lots of things support it, so more things continue to support it, etc, positive feed back) and simple. For embedded devices, simplicity of a file system can be very important. You do not want the overhead associated with more complex file systems. As a simple example the exfat.sys driver in Windows 7, which supports all FAT systems (including 32, 16, and 12) is 200k. The ntfs.sys driver that supports NTFS is 1.6MB. Now please note that the size difference isn't the issue, it is just indicative of the complexity. NTFS requires a lot of processing, as do most good modern desktop file systems. FAT is just a linked list more or less. It is extremely simple to implement.
For that matter the original FAT is also the ISO/IEC 9293 standard.
But please, don't let the facts get in the way of your two minutes of hate.
Speak Up. (Score:3, Interesting)
Speak Up. Somewhere along the chain, there will be a competent IT manager who knows what this means, and why it is important. If your organisation is good, that'll be from the CTO down, but worst-case you'll get to a "sergeant" kind of level where the manager still deals with the coalface.
If that manager hasn't been notified already by this blog or by someone else reading slashdot, your speaking up will be appreciated. If it's been raised before, you can rest easier knowing there's someone competent around, and you know who to go to next time.
Seriously, what would the harm be in speaking up?
They are taught that input validation is wasteful! (Score:1, Interesting)
I recently had to work with a programmer who was trained in India. Like most Indian-trained developers, he had his bachelors degree, two masters degrees, and almost every Microsoft, Cisco and Oracle certification possible.
We were to develop a relatively simple desktop application that our company would use internally. Like most business apps, it included a few forms where the app users would input certain data.
I ended up doing much of the back-end work, while he focused on the front-end. As the project progressed, I kept seeing that he didn't do any sort of input validation. None at all. So I asked him about this, and he told me that input validation was "wasteful" (his words)! I couldn't believe it, and asked him where he heard that from. He told me that was what his professors had taught him. Not only that, but he showed me some "citations" to back up his claims. Yes, he showed me papers by Indian professors with graphs and timing tables and all sorts of shit like that indicating that basic input validation was too intensive.
This was completely unacceptable, so I had to go to our manager and demand something be done. Thankfully, our manager understands the need for reliable software that includes user input validation, so this Indian fellow was transferred to another project. We hired a German university student, and the results were much better. Our application now has input validation.