Even the most securely coded piece of software can be susceptible to malicious hacking and significant exploits the moment it's linked with less-secure applications or platforms. These multiproduct, multirole exploits (also known as "chained exploits") are among the most difficult security issues to prevent. In fact, though issues may be known, they can be just as challenging to avert.
Two recent security events -- one involving net/tun and a Linux compiler and the second involving Gmail, Hotmail, and Twitter -- illustrate the challenges that chained exploits create. As I wrote last week in regard to the forthcoming Google Chrome OS, most -- if not all -- software must interact with other products and features if it's going to deliver the functionality that users demand. The trade-off can be weakened security.
[ Learn why Google's Chrome OS can't be perfectly secure. | Keep abreast of IT security news and developments by subscribing to InfoWorld's free Security Central newsletter. ]
The Linux kernel vulnerability emerged in the open source net/tun program. In this case, the bug was not written in to the net/tun program. Rather, when the program's source code is run through a Linux compiler for optimization, the complier introduces a kernel exploit. In particular, the compiler finds what it thinks is an unnecessary NULL value and removes an important IF-THEN statement. The subsequent exploits work even against improved security versions of Linux, such as SeLinux (see a video of a representative exploit).
The second example of a chained exploit is even more intriguing. In this case, a malicious hacker broke in to one or more Twitter employees' e-mail accounts, then publicly posted both personal and company confidential information.
The hacker accomplished this feat after discovering that a Twitter employee used Gmail and that a request for a new password for the account would be sent to the employee's Hotmail account. However, the employee had not used the Hotmail account in a very long time, so their Hotmail address was available for anyone to adopt.
The hacker registered for the Hotmail address and had Gmail send a password reset for the Twitter employee's Gmail account to what was now the hacker's Hotmail account. With the new password, the hacker gained access to the Twitter employee's Gmail account. Using information found in the employee's e-mail, the hacker was able to acquire personal information about the employee and data to exploit Twitter's own network. TechCrunch has an excellent step-by-step account of the hack.
These actions took a lot of (successful) guessing and the reliance on default human behavior. All in all, this is one of the most interesting hacks I've read about in a long time. It makes the Sarah Palin e-mail account hack seem like child's play (which it was).
These two scenarios reveal the difficulty of planning for and combating chained exploits. In the case of net/tun, the developers of the program might need to rewrite the code such that the compiler doesn't remove the important IF-THEN statement. For sure, the developers of the compiler need to rewrite their code, lest it create security bugs in a future application.
The second exploit type generated a lot of discussion among my friends and co-workers. Specifically, we focused on how to prevent an old, now long-ignored e-mail account from being exploited by hackers. Simply preventing e-mail name reuse isn't an efficient application of available resources.
One bright friend thought of using an automated mechanism to help the first e-mail host (Gmail) to communicate with the second (Hotmail, in the example) to determine how long it has been since the second account was used. If the time period exceeded the first host's expected terms of service, the host would not send a password reset notification to the older e-mail address.
The brainstorm of solutions went on and on, and each seemingly perfect answer was found to be riddled with exploit vectors. It ultimately came down to the ongoing problem of transitive trust. One weak link in the chain means the whole chain is broken.
Further complicating the problem is that any possible solution would likely solve only one interaction between two hosts. Sure, one vendor fixes the problem, but what about the other? Or all the popular e-mail hosts, for that matter? To solve the larger issue, all e-mail and password-resetting hosts would have to agree on a course of actions -- and that is unlikely to happen. Further, once that problem is fixed, hackers will just jump to the next weak link. Longtime readers know that the only solution I like is where the entire Internet is fixed. Outside of that, we're just playing whack-a-mole with point solutions that are never going to work .
Because that type of Internet protection doesn't exist, users must be ultimately responsible for closing any potential holes opened by old e-mail accounts. For one, don't reuse passwords between e-mail accounts and Web sites. Second, when you're finished with an e-mail account, delete all the messages (sent and received), though be sure to archive and copy what you need to keep. If you're an administrator, maybe it's time to share with end-users the risks of not properly cleaning up old e-mail accounts.
These examples of computer security interconnectedness show the difficulty of the task before us. It's not impossible, but there are no easy solutions. You have to be responsible and responsive, even when it isn't your company or vendor's sole fault.
'Hacker Croll' spills details to TechCrunch, the site that published internal Twitter docs
Making the Net safe will require a global security "dream team" and a new security infrastructure service
Developing a bulletproof OS isn't possible, especially one that people will want to use