The real irony is that computer viri don't need to "register" with Windows OS's, but all legitimate programs do...
Posted on 11/26/2003 6:24:00 PM PST by Timesink
Cash dispensing ATMs belonging to two US financial institutions were shut down when the computer worm Welchia invaded their embedded Windows XP operating systems in August. Diebold, the Ohio-based company that makes the machines, revealed the security breach on Tuesday.
It is the first known case of a worm actually installing itself on individual ATM operating systems, says Peter Lind, a security expert at Spire Security in Malvern, Pennsylvania. Earlier in 2003, the Blaster worm shut down Bank of America ATMs, but only by causing a flood of traffic that clogged the network's bandwidth.
In the Welchia case, the only harm done was that the traffic generated by the worm trying to contact other machines shut down the ATMs. The worm, also known as Nochi, was not particularly malicious. But it is indicative of a worrying trend, says Lind.
"Nowadays it seems that any device that supports any kind of networking is opening the door to access and sometimes that access might be malicious," he told New Scientist.
Cellphones and utilities
David Loomstein, of Symantec's computer security response team in Santa Monica, California, agrees: "Are they running a popular operating system? Are they sitting on the internet or a network? If yes, then there is always the possibility of access."
Devices meeting Loomstein's criteria also include cell phones that connect to the internet and SCADA systems that control utilities. All are increasingly relying on popular software, such as embedded Windows XP, that virus writers target.
To infect the ATMs, Welchia exploited a vulnerability in Windows XP called RPC DCOM. Diebold adapted Microsoft's RPC DCOM patch for its ATM machines and offered it to its customers. But the two financial institutions did not apply the patch and were infected, says Diebold spokesperson Mike Jacobsen.
Diebold does not know how the worm got on to the closed financial network. But security experts suggest it could have been carried past security measure on an infected laptop computer. The laptop would have contracted Welchia while connected to the internet, and then transferred it when later connected to the financial network.
Spew out cash
However, programming an ATM to spew out cash would take more than a vulnerability in the operating system. It would require access to the private source code that controls the mechanical opening and shutting of the machine.
But someone might be able to use a worm that exploited a vulnerability to gain access to that source code, says Lind. "It doesn't strike me as outside the realm of possibility, although it is a little far-fetched," he says. "We really need to do a better job of understanding where folks have been."
Loomstein says the only solution is to make sure security patches are up to date. Diebold's response is to install all new ATMs with firewall software, starting from December.
Yup, that's why I posted this; it's making the rounds of the conspiracy-minded leftist communities.
Are there no real embedded programmers anymore?
The real irony is that computer viri don't need to "register" with Windows OS's, but all legitimate programs do...
Yes, there are, but they may be busy greeting customers at WalMart.
Well...
Who made the decision to run a cash machine off Windows XP? That person needs their head examined!
It's not that far fetched of an idea, and actually pretty slick. Problem is they screwed up on the implementation. The ATM machine should be behind a firewall (ATM -> network cable -> firewall -> financial network). If it was, Welchia would never have reached it from the "financial network".
I'm sure, given your response, you know nothing of the ATM business, nor probably much about computers. These machines run a derivitive of XP, not the kind you load on your desktop.
Of course, I know your next response already... LINUX...
And how does a machine running XP confirm that there aren't any I/O capture spybots added by a rogue owner/operator? Even if the XP subsystem weren't connected to an insecure network I'd still be worried about it having access to the unencrypted data.
Actually, I'd be more comfortable with an XP-based OS running on the network stuff and a ROM-based OS running the UI and handling all the encryption (so the XP stuff never saw anything but encrypted data that it could not itself decrypt) but I don't know why anyone would use XP in that fashion.
If they're using XP, what would prevent a rogue owner/operator from using an I/O port capture routine to capture people's card numbers and PINs? Or do you suppose they have a 'black box' to handle such things?
If there is a port capture device in place, why would the operating system matter? It would be between the keypad and the cpu and unless you encrypt the keypad, it'd be impossible to stop.
If it were my design, everything from the keyboard would be encrypted all the way to the bank. The computer part of it would simply transmit and receive the data. With a 128+bit encryption key system hardwired into the keyboard and display, the OS becomes moot.
Right, but if the keyboard, display, and card reader all include hard-programmed security, what's left for Windows XP to do that a decidated embedded OS can't do better?
No argument with me, but if you don't have embedded programmers on staff, you could make do with XP handling the data shuffling and farming out the KB/Display bits to people who specialize in it.
I am not a full time security guru. I am however a guy who spends alot of his time dealing with security issues. I know how to lockdown XP as a matter of course. I also spent years dealing with security issues on Novell 2.x to 5.x servers as well as solaris firewalls. It is possible to have a component level security system in place to protect data in an insecure hardware environment and use something that is only marginally secure(XP) to transmit the data and keep the data pretty damn secure. Obviously, Diebold blew it. And yes, there are better solutions. No doubt they figured they had it pretty well nailed...they just didn't forsee what people with unlimited time on their hands could figure out.
The issuance of receipts is meaningless. What's important is that the votes themselves be coded on a medium which (1) a voter can examine to confirm that the vote is recorded correctly, and (2) is proof against alteration or substitution. Optically-scanned ballots would seem to be the ideal vote-tallying method, especially if the ballots can contain a 'check' field, and if the ballots can be tagged with random machine-readable ID's for use in case of either recounts or sampling-based audits.
To clarify on the last point: I would have the electronic ballot box machine assign a unique-id to each race on each ballot and print the unique-id's on the ballot in machine-readable form. To balance voter privacy with practical information capacity limits, the unique-ID's would be split into two parts, one of which would be the same ballot-wide (but would not uniquely identify the ballot) and the other of which would be unique to each race.
To clarify, suppose there were five races and the number of voters to be served by the machine was to be less than 100,000. I'd start out by selecting a random permutation of numbers 000 to 999 (called primary-id's) and would take the first four or so of these and call them "current". For each of those first four, I'd select a random permutation of 00 to 99 (called sub-id's). Then voting would be ready to begin.After the election, a list would be published of all ballots cast in each race at each station, sorted by the unique-ID numbers. Because the unique ID numbers would be separate for each race and convey no information about any particular ballot, this would not compromise voter's privacy. It would, however, allow anyone to confirm that the reported number of votes a candidate received matched the number of recorded votes for that candidate.For each ballot, I'd pick at random one of the "current" primary id's and the first four not-yet-used sub-id's associated with that primary-id. If I used up the last of the sub-id's associated with the primary ID, I'd pick the next primary ID (from my permutated list of 1,000) and assign it a new random permutation of the numbers 00 to 99.
The races on a ballot would thus have numbers like 193-29, 193-91, 193-53, and 193-74. The numbers would thus yield very little information about what order the ballots were cast, or even which votes went together on the same ballot.
The next step would be to allow any interested party, for a nominal fee, to request any particular ballot--by number--for inspection. If the unique-id's are machine-readable, it should not be overly difficult to locate any particular ballot on request. It should thus be possible to inspect any particular ballot and determine if the vote cast on the ballot matches the recorded electronic copy.
The beauty of this sampling method is that it doesn't take a very big sample to weed out fraud. If the combined error/fraud rate is 2%, the act of inspecting 100 randomly-selected ballots will have an 85%+ chance of catching it (no matter how big the race!). A sampling of 1000 ballots will suffice to catch an error/fraud rate of 0.2%. The statistical sampling is much, much more powerful than recounting. Recounting, after all, doesn't say or indicate anything about whether any particular ballot counted the same way on multiple passes. Assigning and tracking ballots by ID would allow ballots which change on repeated reads to be flagged for hand-inspection.
Come on, its embedded Win XP. Our company found that the driver support for our custom Video on Demand systems was easier to maintain in Windows.
Of course, if we had contracted a device programmer or two, then our product could have saved the $45 per system we spent on embedded Win XP. Then we would have possibly had a system that was competitive to sell, and we wouldn't have closed our doors.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.