Ken Thompson’s seminal paper “Reflections on Trusting Trust”, which won a Turing Award, addresses in detail why we can never be fully sure of the trust relationships in our development environment. The paper asserts that since people tend to only review the security of the source code of their programs, and not the resulting compilation, there is a built in level of trust with regard to the tools that convert human readable source code into executable binary programs. According to the paper, this trust can be abused by creating a compiler that outputs something different than originally intended by the source code. No level of source code security review is going to catch this type of malicious activity. To take it one step further, Ken also discusses a malicious compiler that when used to build a new compiler, will make that one malicious as well. Well recent discoveries have shown that the paper is spot on with regards to a new virus that is currently making the rounds.

A few days ago, a security researcher by the name of Andreas Marx submitted a sample of a new strain of virus to a number of anti-virus vendors. This strain, which has been named Win32.Induc.a, was subsequently researched by both Kaspersky Labs and F-Secure with the details being published shortly after discovery. What makes this virus interesting isn’t a devastating payload — it has none — but instead what it targets. When an infected binary is executed it attempts to locate an installation of the Delphi compiler and, if one is present, subverts that target to create a real-life version of Ken Thompson’s malicious compiler. All future programs compiled by the now infected compiler will result in a binary that also contains the virus. Regardless of the security level of the source code fed into the compiler, the output will be dangerous. Some reports have gone so far as to claim that over 200,000 infected files have already been produced by infected compilers. (Take these numbers with a grain of salt of course).

This realization of the “Trusting Trust” subverted compiler demonstrates the need to secure and test exactly what we are going to execute and not what we write. Given the existence of malware like this, it is clear that what we write may be nowhere near what we actually run.

Update: I was just handed a link to a very interesting paper written by Chris Wysopal detailing the relationship of Thompson’s compiler backdoor to binary analysis. Link HERE. This is a must read.

Veracode Security Solutions

Security Threat Guides

It turns out that the main entry point was a SQL Injection vulnerability. The indictment states that a SQL Injection vulnerability was exploited and used to install malware on the target network.

The indictment doesn’t give any details of the technique that was used to leverage the SQL Injection vuhnerability to install the malware. I have my theories. Here are some potential ideas:

• xp_cmdshell was enabled and allowed the attackers to execute the commands of their choice on the server
• web content was served from the database and it was changed to allow executable file uploads to the web server and then execution on the web server
• there was sensitive data stored in tables in the database that allowed the attackers access to machines they could execute code on.

I would be interested in other ways people know of to leverage a SQL injection vulnerability to execute code.

Once an attacker has the tiniest foothold through a perimeter it can often be leveraged to compromize an entire organization. That is why public facing web applications are critical to secure. They are on the front line perimeter of your organization and demand the same care you would put into locking down your firewall, mail server, or VPN. Thinking that attackers who find a web vulnerability will only be able to manipulate web transactions deprioritizes the risk inappropriately. Sometimes a web vulnerability gives them the whole enchilada.

“Mr. Bumgarner traced the attacks back to 10 Web sites registered in Russia and Turkey. Nine of the sites were registered using identification and credit-card information stolen from Americans; one site was registered with information stolen from a person in France.”

I have my own data point to share on this attack trend. My credit card number was used fraudulently to register 4 web sites from separate ISPs last Monday. The fraud detection was flagged at one of the ISPs, Laughing Squid Web Hosting. Thanks guys! This was because the fraudsters were sloppy and tried to register an invalid domain name as the name of their web server, arararararar.com. Laughing Squid gave me a call and I was able to get my card cancelled and the other ISPs notified within a few hours. Interesting that the other ISPs didn’t notice.

It is easier to steal credit card info from merchants and processors than it is to compromise web servers to build botnet attack and control. There is no physical shipment when you order web server hosting. ISPs need to be more rigorous in their fraud detection.

Poor security at sites processing credit cards can do more damage than hurt individuals, merchants, or banks financially. It is a risk to the internet because the purchasing power of the credit cards can be used to fund attacks.

Veracode Security Solutions

Security Alternatives

Security Threat Guides