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.
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.
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 firstname.lastname@example.org.
Stuart McClure is president and CTO and Joel Scambray is managing principal at security consultant Foundstone (www.foundstone.com).