Two Words: Code Quality

Dr. Brian Chess, Chief Scientist at Fortify and static analysis guru, has a couple very interesting posts on the company blog: one on the U.S. court system paying attention to source code quality of breathalyzers, and one on the quality of source code in closed systems (Nintendo Wii and Apple's iPhone).

It appears that a custom crafted Zelda saved game file can exploit a buffer overflow in Zelda allowing the execution of any code you want to throw at the console-- step one of software piracy on the Wii. It just further illustrates that you should NEVER trust user input-- no matter how unlikely you think the input will be untrustworthy (ahem, saved games in a closed video game system).

About 1.5 Million iPhones are unaccounted for, suggesting they've been hijacked to be set free of AT&T contracts. And this further illustrates that controlling a system at a distance is impossible.

Dr. Chess' comments about the Breathalyzers are choice as well:

"One of the teams used Fortify to analyze the code, and lo-and-behold, they found a buffer overflow vulnerability! This raises the possibility that if you mix just the right cocktail at just the right time, you could craft an exploit. (Dream on.) The real lesson here is that our legal system is waking up to the importance of code. If the code isn’t trustworthy, the outcome isn’t trustworthy either. (Electronic voting machine vendors, you might want to read that last line again.)"

F-Secure's Academic Malware Analysis Course

I would like to see more like this from security vendors/service providers in industry: F-Secure has created a malware analysis course at the Helsinki University of Technology. Here's a link to the course details, they're using Peter Szor's (of Symantec) book: The Art of Computer Virus Research and Defense.

Targeted Bank Malware

There have been a lot of interesting things going on with malware these days, but this is on the top of the list (for the next few hours anyway ;). Symantec has a blog write-up on a specific trojan that targets over 400 of the most popular banks in the U.S. and abroad. From the post:

This Trojan downloads a configuration file that contains the domain names of over 400 banks. Not only are the usual large American banks targeted but banks in many other countries are also targeted, including France, Spain, Ireland, the UK, Finland, Turkey—the list goes on.

Targeted malware has some interesting economic ramifications. With signature based anti-malware, the defenses only work if a signature exists (duh!). But the problem is this: will your very large (think yellow) anti-malware vendor really publish a signature to catch malware targeted at only your organization, especially considering that each signature has the possibility of falsely identifying some other binary executable and causing a problem for another of their customers? No doubt anti-malware vendors have seen targeted malware and then specifically not published a signature for all of their customers. They may have released a specific signature for an individual organization, but the support risks are significant. It's better for everyone to NOT publish a signature unless it's widespread. Signatures add overhead, even if it's minimal. It's at least one more signature to search through when comparing each signature. At best, that's logarithmic complexity, and even that minimal complexity across a half-million signatures is expensive.

But that's not all that is interesting about "Trojan.Silentbanker" ...

Targeting over 400 banks ... and having the ability to circumvent two-factor authentication are just two of the features that push Trojan.Silentbanker into the limelight...

The ability of this Trojan to perform man-in-the-middle attacks on valid transactions is what is most worrying. The Trojan can intercept transactions that require two-factor authentication. It can then silently change the user-entered destination bank account details to the attacker's account details instead. Of course the Trojan ensures that the user does not notice this change by presenting the user with the details they expect to see, while all the time sending the bank the attacker's details instead. Since the user doesn’t notice anything wrong with the transaction, they will enter the second authentication password, in effect handing over their money to the attackers. The Trojan intercepts all of this traffic before it is encrypted, so even if the transaction takes place over SSL the attack is still valid. Unfortunately, we were unable to reproduce exactly such a transaction in the lab. However, through analysis of the Trojan's code it can be seen that this feature is available to the attackers.

The Trojan does not use this attack vector for all banks, however. It only uses this route when an easier route is not available. If a transaction can occur at the targeted bank using just a username and password then the Trojan will take that information, if a certificate is also required the Trojan can steal that too, if cookies are required the Trojan will steal those. In fact, even if the attacker is missing a piece of information to conduct a transaction, extra HTML can be added to the page to ask the user for that extra information.

If you understand how Two Factor Authentication really works (at least how banks are implementing it) then you already understand that it cannot stop fraud by an adversary in the middle (a less chauvinistic way to say "man in the middle"). Bruce Schneier has been preaching "the failures of two factor authentication" for a long time. What's monumental about this piece of malware is that it is the first to do well that which pundits have been saying for a long time. Two factor authentication, including PayPal's Security Key (courtesy of Verisign, a company not on my good list), is broken. SiteKey is broken (for the same reasons). What Schneier said in 2005 took until 2008 to materialize (at least publicly). This will not go down in history as an anomaly; this will go down as the first run at creating a sophisticated "engine" to handle MITM on any web application that has financial transactions.

Here's the real question to answer: How many fund transfer transactions must be hijacked to bank accounts in foreign nations that don't extradite their criminals to the U.S. before we finally realize just how bad malware in the "Web 2.0" world (sorry that's O'Reilly's name, I really mean "XMLHTTPRequest" world) can get?

It's about the transactions, folks. It's time to authenticate the transactions, not the users. (Schneier's been saying that, too.) Bank of America is closer-- yet farther away at the same time-- to getting this multi-factor authentication problem solved by implementing out-of-band multi-factor authentication in their "SafePass" service ... BUT, it's still completely vulnerable to this malware (I cannot state that this specimen does in fact implement a MITM on this BoA service since I have not reversed a sample, but if not in version 1.0, it will eventually). I wanted to write a rebuttal to the entry on Professor Mich Kabay's column on Network World, but the authors of this trojan did a better job!

The downfalls of SafePass, which uses SMS text messages to send one-time-use 6 digit passcodes (think RSA SecurID tokens without the hardware) to a customer's mobile phone. It's nice to see authentication out-of-band (not in the same communication channel as the HTTPS session), however, once the session is authenticated, the trojan can still create fraudulent transactions. SafePass could be improved by: 1) not using a non-confidential communication channel (SMS text messages are sent through the service provider's network in plaintext) and 2) requiring the customer to input the authentication code to validate transaction details that are sent with the out-of-band authentication token. Obviously you don't want to skip on #1 or else you'll have a privacy issue when the details of the transaction are broadcast through the provider's network and over the air.

Suppose Eve can modify Alice's payment to Bob the merchant (the transaction's destination) via a MITM trojan like this one. Eve modifies the payment to go to Charlie (an account in the Cayman Islands). Suppose Alice is presented with a "Please validate the transaction details we have sent to your mobile phone and enter the validation code below" message. Alice receives the message and notices the payment is to be sent to Charlie. Since she doesn't intend to pay Charlie, she calls her bank to report the fraud (as directed in the transaction validation method). Of course, that pipe dream would only work if SMS was a confidential channel [and if we could deliver a trustworthy confidential channel to a mobile phone, we will ALREADY solved the trustworthy transaction problem-- they're the same problem] AND if we could find a way to make customers actually PAY ATTENTION to the validation message details.

And of course, incoming SMS messages in the U.S. are charged to the recipient (what a stupid idea-- what happens when people start spamming over SMS like they do over SMTP?).


...

[Side commentary] Oh. And then there's the problem of telling your family members not to click on any random e-cards (or anything else that your family members were not expecting) because it just got a little scarier out there. Imagine your retired parent just clicked on some pretty animated something-or-other that launched some client-side script, installed the Trojan.Silentbanker (or similar) and then the next time they went to check their retirement savings, their life's solvency was sent to a Cayman Islands' account and liquidated faster than you can say "fraud". Does dear old Grandma or Grandpa have to go back to work? They just might, or become a liability on their children and grandchildren. If that won't scare the older generation away from the unsafe web, what will?

Trust is a Simple Equation

[Begin rant]

OK. If security vendors don't get this simple equation, then we might as well all give up and give in...


If you don't know if a computer has been rooted or botted (apologies to the English grammar people-- computer security words are being invented at an ever-increasing rate), then you cannot use that same computer to find out if it has been rooted or botted. Let me say this slightly differently: If you don't know if a computer is worthy of trust (trustworthy), then you cannot trust it to answer correctly if you ask it if it is trustworthy.

It doesn't work in real life. It's stupid to think that a person you just met on the street is trustworthy enough to hold your life savings just because that person says "you can trust me" (or even something of less value than that, probably of any value). My father used to say "never trust a salesman who says the words 'trust me'" because of his life experiences that suggest they're lying most often when they say that (although that may not be statistically relevant, it's relevant as an anecdote).

So why in the world would we EVER trust a piece of software to run on a computer whose state is unknown-- whose TRUSTWORTHINESS is unknown-- to determine if it (or any other system for that matter) is trustworthy???

That's why many NAC implementations fail. It's opt-in security. They send some little java (platform independent) program to run and determine trustworthiness, like presence of patches, AV, etc. Of course, all it takes is a rootkit to say "nothing to see here, move along" to the NAC code. We've seen implementations of that.

So why in the world is Trend Micro-- a company who should KNOW BETTER-- creating code that does just that? RUBotted is the DUMBEST, STUPIDIST, MOST [insert belittling adjective here] idea I have ever seen. It works by running code inside the same CPU controlled by the same OS that is believed already to be botted-- why else would you run the tool unless you already suspected the trustworthiness to be low?!?

This had to have been either designed by a marketing person or a complete security amateur. It attempts to defy (or more realistically: ignore) the laws of trust! How long is it going to be before bot code has the staple feature: "hide command and control traffic from the likes of RUBotted"?


And then eWeek is suggesting that this will be a paid-for-use service or application?!? People, please don't pay money for snake oil, or in this case perpetual motion machines.


This just defies nature. If you wouldn't do it in the "real world", don't do it the "cyber world".



Now, if you could use systems you already know to be trustworthy (i.e. computers that you control and know that an adversary does not control) to monitor systems about which you are not sure, then you may be able to make a valid assertion about the trustworthiness of some other system, but you MUST have an external/third-party trusted system FIRST.


And don't forget that "trust" and "trustworthiness" are not the same.

[End Rant]

MBR Rootkits

There is a new flurry of malware floating around in the wild: boot record rootkits (a.k.a. "bootkits"). Yes, for those of you old enough to remember, infecting a Master Boot Record (MBR) is an ancient practice, but it's back.

There are several key details in these events that should be of interest.

As Michael Howard (of Microsoft Security Development Lifecycle fame) points out and Robert Hensing confirms, Windows Vista with Bitlocker Drive Encryption installed (most specifically the use of the Trusted Platform Modules (TPMs), as I have discussed here many times) is immune to these types of attacks. It's not because the drive is encrypted; it's because the TPM validates the chain of trust, starting with the building blocks-- including the MBR.



But that's not the only interesting thing in this story. What's interesting is best found in Symantec's coverage on the latest MBR rootkit (Trojan.Mebroot) that has been recently found in the wild:

"Analysis of Trojan.Mebroot shows that its current code is at least partially copied from the original eEye BootRoot code. The kernel loader section, however, has been modified to load a custom designed stealth back door Trojan 467 KB in size, stored in the last sectors of the disk."

That's right. Our friends at eEye who have been busy hacking the products we use to run our businesses in order to show us the emperor hath no clothes created the first Proof of Concept "bootkit":

"As we have seen, malicious code that modifies a system's MBR is not a new idea – notable research in the area of MBR-based rootkits was undertaken by Derek Soeder of eEye Digital Security in 2005. Soeder created “BootRoot”, a PoC (Proof-of-Concept) rootkit that targets the MBR."

Windows Vista Phones Home

OK. Perhaps not "phone home" in the sense that these people think, but it does in fact do it, at least on a minor scale.

A Windows Vista "feature" called Network Connectivity Status Indicator (NCSI) goes and fetches a file hosted on a Microsoft web server (a farm of servers, no doubt, once a widespread adoption is realized). It's a simple HTTP GET.

In fact, you can see for yourself. Fire up wireshark (or similar) while watching the traffic of a vista client. You'll notice a DNS query for www.msftncsi.com (Microsoft Network Connectivity Status Indicator) and you'll see the GET request for a file named ncsi.txt. Basically, if a client can fetch that file, Vista thinks the network interface has Internet access. Sounds simple, right? And of course, in true Microsoft style, disabling the feature will have negative effects on every application that calls the API that exposes whether or not that file could be fetched (think timeouts and bad coding habits).

What's interesting is the basic traffic analysis that can be performed just by watching clients fetch that file. In that HTTP GET request, the Vista client will pass the user agent string, not to mention it will initiate the TCP session from a randomly chosen high port. And of course, there's the source IP Address (which is likely behind a NAT in an enterprise). Without a degree of certainty, but with a degree of at least entertainment, one could see, say, how many Windows Vista installs existed behind a specific public IP Address. That might be interesting. Especially to somebody having a vested interest in, say, licensing compliance.

But that's not the biggest or most obvious problem. It's not necessarily the most preferred method of checking Internet "connectedness" for an enterprise. And since turning it off supposedly has negative effects (do your own Googling for that), there has to be a better way to configure this service.

And in fact there is ... Here is one option and some implementation choices: configure the service to connect to a different URL, perhaps one controlled by the enterprise in question, or perhaps just to another service. For complete irony, I'm choosing in this example to use the service of an organization that we all know (wink) to do no evil: Google.

Obviously there are going to be a few requirements about the URL you choose:
1) It has to small and lightweight, for performance reasons. You don't want 5000 machines checking for the existing of, say, an ISO CD image file every time the network interface's state changes.
2) It has to be mostly static, otherwise if the URL goes away then your clients (and apps) will think "the Internet needs rebooting".
3) It has to be a URL that is accessible from both inside of an Enterprise Network and outside at the local Starbucks. Remember, if you're an enterprise that authenticates every HTTP object request, this particular feature will run in the "LOCAL SYSTEM" security context inside of Windows, meaning that unless you grant "Domain Computers" or "Vista Computers" (the latter being a group you'd have to create) in your Active Directory forest to have Internet access, this process will fail. Yes ... it checks the NCSI even when a user has yet to log on.

Note that instead of a "ncsi.txt" file (a surprisingly small 34 bytes), I have chosen the ubiquitous "favicon.ico" URL, because it's static, it's prevalent, and because Google (a highly available service world wide) makes use of it, too, although it's a couple orders of magnitude higher at 1002 bytes (but it's ripe for caching). So, the astute readers will notice it meets the above three requirements.

Also note that the NCSI config requires a DNS server name and IP address. I'm choosing OpenDNS, since I've been so impressed with them recently (especially, in this case, their use of Anycast). It should work well for you as well.


Registry tweak.
A quick tweak to the registry is easy if it's just a handful of machines.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet]"EnableActiveProbing"=dword:00000001
"ActiveWebProbeHost"="www.google.com"
"ActiveWebProbePath"="favicon.ico"
"ActiveWebProbeContent"="OpenDNS"
"ActiveDnsProbeHost"="resolver1.opendns.com"
"ActiveDnsProbeContent"="208.67.222.222"

Group Policy ADM template.
A custom GPO that you can configure inside the Group Policy object editor to point to a URL of your own choosing. Oh, and you'll want to go through the View > Filtering options and uncheck the last box, as shown below, so that you can actually see the ADM template's setting options.



CLASS MACHINE
CATEGORY "Custom NCSI"
KEYNAME "SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet"

POLICY "EnableActiveProbing"
VALUENAME "EnableActiveProbing"
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END POLICY

POLICY "ActiveWebProbeHost"
PART "ActiveWebProbeHost" EDITTEXT
DEFAULT "www.google.com"
VALUENAME "ActiveWebProbeHost"
END PART
END POLICY

POLICY "ActiveWebProbePath"
PART "ActiveWebProbePath" EDITTEXT
VALUENAME "ActiveWebProbePath"
DEFAULT "favicon.ico"
END PART
END POLICY

POLICY "ActiveWebProbeContent"
PART "ActiveWebProbeContent" EDITTEXT
VALUENAME "ActiveWebProbeContent"
DEFAULT "OpenDNS"
END PART
END POLICY

POLICY "ActiveDnsProbeHost"
PART "ActiveDnsProbeHost" EDITTEXT
VALUENAME "ActiveDnsProbeHost"
DEFAULT "resolver1.opendns.com"
END PART
END POLICY

POLICY "ActiveDnsProbeContent"
PART "ActiveDnsProbeContent" EDITTEXT
VALUENAME "ActiveDnsProbeContent"
DEFAULT "208.67.222.222"
END PART
END POLICY

END CATEGORY



...
And of course, all of this is free for your use but without support or warranty of any kind. I am posting it here because I could not find these answers when I went looking for them.