Philosophically Secure

Let’s not forget that CHM files can be dangerous. They can contain embedded executables that get launched automatically when you open them. This post on SANS ISC details a particular malicious CHM file that was sent out via email. After some investigation, it was determined that the program it ran specifically targeted PGP keyrings.

The code searched for these files (.pkr and .skr) and copied them off to the attacker’s system. To really make use of a PGP keyring, you need the passphrase. Well, this is why the malware came bundled with a keylogger, just in case you happened to be using PGP while it was running. The ISC post also notes that it collected .doc files, which could be an attempt to harvest documents that users created to help them keep track of their passphrases.

I’m not sure if I see enough evidence to agree with the conclusion that the attacker was simply trying to map relationships between PGP users, but I guess that is a possibility. Do recent versions of PGP even use these same keyring files?

This is a great lesson in why not to blindly trust random software that you find on the Internet. G-Archiver, a program created to help users locally save their Gmail messages, has a piece of code in it that sends your Gmail login and password to the author. You can see a scary screen shot of his inbox, since the guy had his own Gmail credentials hard coded right into the program, which was obviously discovered.

The details are at SANS ISC (source code) and Coding Horror (screen shot).

This article by SecureWorks, titled “The Packer 2.0 Threat”, is a good introduction to and overview of some of the most popular JavaScript packers. It discusses both the legitimate (although possibly misguided) uses of packers, as well as their role in obfuscating malware. The packers mentioned in the article include: Dojo ShrinkSafe, MOOtools, YUI Compressor, JSMin, and the Dean Edwards Packer.

Basically, the author argues that packing JavaScript leads to several unintended consequences that are bad for security. The most obvious problem is that it becomes much more difficult for network traffic inspection tools, including IDS, to tell the difference between friendly and malicious code. Other techniques, such as gzip compression, are probably good enough to improve bandwidth efficiency.

This is pretty cool. It’s the new Collaborative RCE Tool Library, a nearly comprehensive directory of reverse engineering tools. Not only does it list the tools and provide links to download them, the directory also has pretty good descriptions and resources to learn more about each topic. The tools are conveniently sorted by target type (e.g., Java, Flash, Linux) as well as tool type (e.g., debuggers, PE editors, unpackers) and the whole thing is searchable, which makes it pretty easy to find what you need. (Although, right now the search seems to be broken.)

Perhaps the best feature of the RCE Tool Library is that it’s collaborative, meaning users can improve upon entires, add new ones as new tools are created, and generally keep everything up to date. That will definitely help keep the directory from becoming stale.