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."
Every input is bad... (Score:5, Insightful)
The first thing I learned (fortunately not the hard way) was, that, nevermind the specs, input is allways malformed, user input doubly so...
System Administration 101
Windows autorun viruses are like vuvuzelas. (Score:5, Insightful)
Vuvuzelas: Annoying if you watch soccer, easy to ignore if you don't.
Re:Read-only switch for USB sticks? (Score:5, Insightful)
I've seen them, but that's not the point - the point is that the kiosk itself should be mounting the stick as read-only regardless of how the stick itself is configured. There should be absolutely no way for the kiosk to write to the stick; otherwise you risk an error (or something malicious, as in this case) wiping out the customer's data or (again, as in this case) potentially infecting their machine.
Re:Windows Read-only mode. (Score:4, Insightful)
Can you click faster than that Trojan, before it can infect your writable device? I doubt that, Speedy Gonzales. To mount read-only is divine.
Re:Read-only switch for USB sticks? (Score:2, Insightful)
From infected USB drives?
Re:Read-only switch for USB sticks? (Score:4, Insightful)
Mounting the stick readonly is to protect yourself against liability more than anything else (what if your kiosk corrupts the customers filesystem or deletes their files?)
On the other hand, you could use a hardware reader which is designed to be read only so the software cannot write to it regardless... If the customer inserts a CDROM there is no chance of it being written to if the kiosk doesn't have a writer device.
Preventing anything malicious from executing in the first place is another matter entirely, and also needs fixing.
Re:Poor design.. (Score:2, Insightful)
"Why run windows on these kiosks? An embedded OS would be more suitable and cheaper..."
Because, while the embedded OS would be less expensive, the development costs would be far higher. Windows devs are a dime-a-dozen, not so much with true embedded developers-especially ones that have experience and know what they are doing
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."
This is all may be true, but you have to remember that these machines are in world-wide use. They were developed maybe 10 years ago, embedded linux was not ready for prime-time back then. Your comments show a complete lack of basic knowledge of how software is developed and used to make money for a business. Things don't bode well for you. There are such things as ROI, project schedules, manufacturing schedules and technology that affect the decisions. It's NOT just about whatever technology is available right now. Get a clue.
Re:Every input is bad... (Score:5, Insightful)
a) Anyone in management have a clue what this means.
b) Anyone be able to track down someone who can actually DO something about it.
c) (sadly) whether anyone will actually care enough to make a change for the better.
Tomorrow morning's agenda...
Re:Every input is bad... (Score:2, Insightful)
Re:Every input is bad... (Score:5, Insightful)
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.
Let me guess: (1) the software in question was a blogging program much like wordpress (in other words, you must feel that the context of the situation wasn't relevant to your thesis and didn't even need to be shared with us), (2) the kids you were talking may have known about "premature optimization" but were far too young to explain that concept adequately to you, and (3) those same kids didn't know what an assembler was either, that's why they didn't make fun of you for pretending to know how to program in "assembler" instead of ***assembly***.
Re:Every input is bad... (Score:1, Insightful)
... These people all believe in the magical black box.
This is the problem with almost EVERYONE now, in all fields. The magical black box thinking is disasterous. People have no care or mind for trying to learn the 'why' on what is going on around them. I don't beleive that there is a device, pill, gadget or anything else that I use in my daily life that I don't have atleast some inclination as to how it works or what it's basic parts are. I can't imagine going through life not caring whats inside the black box. This is the dumbing down of society.
Re:No, not so much (Score:3, Insightful)
It's not hate.
Microsoft supporting a modern royalty free file system out of the box would make life easier for a _lot_ of people (even if most of those people have no idea that this is the case). Unfortunately Microsoft is not interested in being interoperable here, it's just not in their best interest.
Stating the above is not hate, rather a rational conclusion. On the other hand, talking about how third parties can implement file systems on Windows is a red herring if the subject is real interoperability.