It may be the next big thing in Trojan horse attacks: swapping bad code for good code in transit. Fortunately, there's a defense
When possible, obtain the PGP key for the package from a different source than the package .
These fundamental cypherpunk maxims were driven home this week when I read a Slashdot post by a Linux-geek who successfully simulated the type of system the FBI may soon to inject its "Magic Lantern" application into an unsuspecting computers.
For those of you who haven't been keeping score at home, Magic Lantern is the FBI's system, under development, for capturing keystrokes on a suspect's computer. It would theoretically be installed covertly over the Internet, and send back all of the target's keystrokes to law enforcement.
Magic Lantern differs from the 'Carnivore' project, which snoops on network traffic at ISPs. Carnivore can presumably be defeated by encrypting the traffic, which is one reason keystroke capture becomes critical: it would provide the FBI with access to the target's passphrases, allowing the Bureau to decrypt the content.
Not that the FBI necessarily needs to install keysniffers remotely. In a recent criminal case involving an alleged bookie, the FBI installed a keysniffer on the suspect's system by breaking into the person's office. In this case, it required five "surreptitious entries" in order to install the system, but it clearly can be done -- and will be done, in cases of extreme import.
The Slashdot poster, rather than orchestrating a late-night burglary, claims to have used a commonly-available transparent Web proxy to replace a Linux software package, in the experiment it was 'wu-ftp', with a version he modified to contain a secret back door.
What makes this different from typical Trojan horse attacks is that there is no unsolicited transfer of data: here, the end-user requests a file, and receives a file. Furthermore, this file will perform as expected and merely have an unnoticed additional feature, such as sending passwords to an anonymous email account at FBI.gov.
The technology to do this is present everywhere, and anyone upstream can trojan your system. The FBI, for example, could insert trojaned content at various points: an Internet Service Provider is one obvious candidate, but content caching and distribution networks would provide another possible point of entry.
While modifying data in transit is not a new technique (for example, HUNT allows snooping or modification of active telnet sessions, and people have modified live FTP transfers), we have not previously seen this technique applied on a wide scale. (In fact, we still haven't, but posting of information regarding its application is a step in that direction.)
As more people install software over the Internet, transparent proxies will provide a much greater level of danger than ever before.
The Slashdot poster, who later sent the same message to
The good news is, it is quite easy to protect yourself from this attack -- simply verify cryptographic package signatures after every download. Both Red Hat and Debian package formats have provisions for digital signatures. In both cases, however, they are optional and not checked by default. The result of this policy -- and providing a default setting is a de facto policy, make no mistake -- is that it is trivial to install a trojaned package on the average end-user's box.
For Red Hat Linux, you can verify signatures by running
rpm --checksig my-new-package.rpmand confirming that it's signed by Red Hat. Because Red Hat is a single source for all of their packages, it is simple to check the signatures on a Red Hat-provided package. When Red Hat 7.2 was released, however, some packages were unsigned. While the company has since corrected this, it was a puzzling failure that suggests vendors do not understand the full import of signing packages. Hopefully this simulated attack will remind them.
Debian requires that all packages submitted to the system be cryptographically signed, but this does not prevent a transparent proxy from replacing the file while in transit from a Debian site to the end-user's system. Only validating the package signature, and the authorization of the package signer, can guard against this variety of attack. You should somehow verify that the package is signed by the package maintainer.
Unfortunately, the appropriate Debian HOWTO does not explain how to check signatures; I am not sure how to do this, or if the Debian process uses external package signatures.
For software distributed with other cryptographic signatures, the documentation should describe how to validate the integrity of those packages. When possible, obtain the PGP key for the package from a different source than the package itself -- this makes it modestly more difficult to replace the PGP key as well. (Key signatures and the web of trust provide a much stronger solution to the key-distribution problem.) Software distributed with only MD5 checksums is substantially less secure: it is trivial to modify the descriptions of the checksum on a Web page, or in the documentation.
Of course, you don't have to be a Linux or Unix user to be at risk from this style of attack. Some critics may suggest that the availability of source code makes it simple to trojan open-source software. That's not entirely untrue. But it is fairly simple to trojan Windows-based software by replacing DLLs, an operation so central to the installation of software under Windows that users will rarely question it, if they even notice. The replacement DLL can be trojaned, and it is no more or less obvious to the casual user than a modified open-source package.
Few Windows programs distributed over the Internet are sent out with cryptographic signatures, with the notable exception of Microsoft's operating system patches. And software distributed as source code can be read and checked for holes if the user is dedicated enough.
Few users are that dedicated, of course. Even as many governments the world over are switching to Linux and other open-source packages for security reasons, it seems unlikely they'll read all of the code and rebuild all of the packages. For that matter, they seem no more likely than other users to verify package signatures.
But now that the U.S. government has admitted to developing advanced Trojan horse techniques, it may prompt more vigilance from foreign governments. That, ironically, may help secure our software. If for example the French defense ministry audits every signed Red Hat package, we might all sleep a little better at night. Especially if the Chinese agree with their assessment.
Hopefully they'll just send patches to the code's maintainer, just like everyone else ...