One of the classic security attacks is called the "salami technique." The phrase derives from an attack that takes down its target -- one thin, imperceptible slice at a time. One example is the theft of all of those leftover fractions of pennies that result from standard bank interest calculations (a computer program that redirects these into a personal account would probably go unnoticed for a long period of time).
Although we've tried during the past few months to call attention to the phenomenon, hacking the client side of the Internet apparently isn't worrying anyone at large commerce sites.
Perhaps it's because of the salami factor: Does anyone really miss all those fractions of a penny? Who cares if a few users have their accounts compromised in the grand scheme of dizzying stock market valuations and easy venture capital funding? Well, ask leading online brokerage Etrade Group Inc., which recently had an experience that illustrates just how important the Internet client can be in maintaining (or compromising) network security.
On Friday, Sept. 22, Jeffrey Baker posted to the Bugtraq mailing list that he had discovered several security flaws in Etrade's site. Citing the potential risk of monetary damages due to the exposure, he did not post exploitation details, which is the raison d'etre of the "full-disclosure" Bugtraq list. However, programmer Marc Slemko soon determined independently just what Baker was talking about, and posted Perl exploit code to Bugtraq during the weekend. Baker then followed up with his own, more detailed post.
'Minor' security breach
Etrade initially presented a disjointed front, with one security functionary claiming the problem was "minor." For you CIOs reading this, downplaying any potential security issue is a big no-no from a PR perspective, whether or not it's real. Etrade quietly fixed one part of the problem during the next two days. As we went to press, however, some issues remained.
A subsequent post to Bugtraq dubbed this "half-full disclosure," which Baker likened to giving out flyers about a robbery instead of the combination to the safe. Implicit in his statements was the notion that financial institutions deserve special treatment because their customers can suffer direct financial harm as a result of such vulnerabilities. Whatever your feelings on the merits of special protection for financial institutions, this is just another illustration of how hard it is to alert the community to a security hole in an informative way without simultaneously identifying a way to attack it.
On a technical level, the problem for Etrade lay in cross-site scripting. Cross-site scripting is at least as old as a similar trick played on eBay some time ago. It involves the injection of code into an HTML page that solicits input from users. Baker's proof-of-concept code injected JavaScript into Etrade's log-in input box. When rendered in the client browser, the injected JavaScript is executed. Although the media hypes this as a direct attack on user passwords, it is rather indirect, requiring a user to click on a fraudulent hyperlink either on a malicious Web site, e-mail message, newsgroup posting, or similar hidden trap.
By leveraging allegedly rampant cross-site scripting vulnerabilities in Etrade's site, Baker postulated that credentials could be obtained from unsuspecting users. Baker and Slemko both reverse-engineered Etrade's somewhat crude obfuscation algorithm, which scrambled user log-ins and passwords and sent them back in a cookie to the user's browser. The weak cookie protection made the cross-site issues a grave problem. Of course, the cross-site scripting issue could feasibly be used by itself to fool a user into making unauthorized trades or taking other action before even touching the cookie jar, but hijacking the cookies is probably the most direct way to cause damage.
The solution
Have we learned anything yet? On the server, it's essential to validate all user input and then to assume it's malicious anyway. No one should be able to enter HTML tags using form-based input, and set cookies using a random session key that is expired by the server.
On the client, cookie paranoia and prudent browser configuration can help. Anyone who sets the "save my password" button on a Web site is asking for this kind of trouble. ("Save my password" is a euphemism for "store my password in a persistent cookie on my hard disk.") Disabling scripting in the browser could prevent many variations on this attack, but this will disable much of a site's rich functionality. (It certainly does in Etrade's case.) CERT (www.cert.org), in its February 2000 advisory on cross-site scripting, also advocated abstinence from "promiscuous" browsing. Try to resist the alluring beauty of hyperlinks from now on, OK? Are we motivating a response or just raining on the Web's parade? Let us know at security_watch@infoworld.com.
Stuart McClure is president and CTO and Joel Scambray is managing principal at security consultant Foundstone (www.foundstone.com).