Breaking Cisco VPN Policy

I am surprised how often I hear an organization operate under the belief that they can really, truly can control what a remote client does under any situation. Here is today's lesson on how you can never know what computer is on the other end of the Cisco VPN tunnel or how it is behaving, thanks to more "opt-in security".


Step 1: Break the misconception that Cisco VPN concentrators authenticate which computer is on the other end of the tunnel.

Cisco VPNs authenticate people, not computers. When the connection is initiated from a client, sure the client passes a "group password" before the user specifies her credentials, but there's nothing that really restricts that group password to your organization's computers.

Consider this: any user who runs the Cisco VPN Client has to have at least read access to the VPN profile (the .pcf files stored in the Program Files --> Cisco Systems --> VPN --> Profiles folders on Windows systems). If the user has READ access, any malware unintentionally launched as that user could easily steal the contents of the file ... and the "encrypted" copy of the group password stored within it. Or, a Cisco VPN client can be downloaded from the web and the .pcf VPN profile can be imported into it. At that point, it's no longer certain that the connection is coming from one of your computers.


Step 2: Break the misconception that the client is even running the platform you expect.

So since any user has READ access to the .pcf VPN profiles, they can open up the text config file in a text editor like notepad, peruse the name-value pairs for the "enc_GroupPwd" value, copy everything after the equal sign ("="), and paste it into a Cisco VPN client password decoder script like this one. A novice, in less than a minute, can have everything she needs to not only make VPN connections from an unexpected device, but also from an unexpected platform. Not to mention the group password is not really all that secret.

Cisco VPN encrypted group passwords, like any encrypted data that an automated system (i.e. software) needs to unlock without interrogating user for a key value that only a human knows, must be stored in such a way that is readable for the software. Even though the name/value pair for group passwords in Cisco profiles is labeled as "encrypted" group password, the software needs to be able to decrypt it to use it when establishing VPN tunnels, which means the group password is also read-accessible for any reverse engineer (hence this source code in C). So it is now trivial to decode a Cisco group password. This is not an attack on crypto, this is an attack on key management coupled with a misunderstanding on how compiled programs work.

Now that a "decrypted" copy of the group password is known, the open source "vpnc" package can pretend to be the same as the commercial Cisco version. Here's how simple Ubuntu makes configuring vpnc to emulate a Cisco client:


A Cisco VPN concentrator (or any other server in a client-server relationship) cannot know for sure what the remote client's platform really is. Any changes Cisco makes to its client to differentiate a "Cisco" client by behavior from, say, a "vpnc" client, can be circumvented by doing a little reverse engineering and coding the emulation of the new behavior into the "vpnc" package. An important thing to keep present in one's mind is that compiled applications, although obscure, are not completely obfuscated beyond recognition. A binary of a program is not like a "ciphertext" in the crypto world. It has to be "plaintext" to the OS & CPU that execute it. If it was not readable, then the instructions could not be read and loaded into the CPU for execution. So, any controls based on compiled code are fruitless. Sure, there will be a window of time from when the changes are deployed in the official client to when they are emulated by a hacked client, but reverse engineering and debugging tools (such as bindiff and OllyDbg) are getting more and more sophisticated, reducing the time barrier.


Step 3: Break the misconception that you can remotely control a client's behavior.

A "client" is just that ... it's a "client". It's remote. You cannot physically touch it. Any commands you send to it have to be accepted by it before they are executed. Case in point with the Cisco VPN client is the notion that "network security" people try to perpetuate: "split-tunneling is bad, so let's disable it." Network security people don't like split tunnels or split routes because they view it as a way of bridging a remote client's local network and the organization's internal network. However, it's futile to get all worked up about it. If you trust clients to remote in, then you cannot control how they choose to route packets (though you can pretend that what I show below doesn't really exist, I guess.)


In the same Ubuntu screen shot above, there's a quick and easy way to implement split-tunnels. It's the "Only use VPN connection for these addresses" check box. Check the box and specify the IP ranges. Voila! You've got a split tunnel. Don't want to route the Internet through your company's slow network or cumbersome filters? Check the box. Want to access a local file share while connected to an app your organization refuses to web-enable? Check the box. You get the idea. This is an excellent example of how many "network security" people believe they can control a remote client, yet as you can see, the only way to continue the misconception is to ignore distributed computing principles.

Doing what I described above is certainly not "new" information-- clearly because there are now GUIs to do it (so it's obviously very mature). However, the principles are still not well known and we have vendors like Cisco continuing the notion that you can remotely control a client by upping the ante. Many organizations' network security people are considering the deployment of NAC ("network access control") with VPN. Microsoft has had an implementation of it (they call it NAP for "network access protection") for years. The problem is, it's based on this false sense of "opt-in security" just like split tunnels. Let's look at an analogy ...

Physical Security Guard: "Do you have any weapons?"
Visitor: [shoves 9mm handgun further into pants] "No, of course not."
Guard: "Are you on drugs?"
Visitor: [double-checks the dime bag hasn't fallen out of his jacket pocket] "No, I never touch the stuff."
Guard: "Do you have any ill intent?"
Visitor: [pats the "Goodbye cruel world" letter in his front pocket] "Absolutely not!"

How is that any different from this?

Server: "Are you running a platform I expect?"
Client: "Of course" (it says from the unexpected platform)
Server: "Are you patched?"
Client: "Of course" (why does that even matter if I'm on a different platform from the patches?)Server: "Are you running AV?"
Client: "Of course" (your AV doesn't even run on my platform)

The answer: it's not any different. Both are fundamentally flawed ideas.

So, to refute implementation specific objections, there are two key ways for a project, such as the vpnc project, to choose to not "opt-in" if so desired. They both involve lying to the server (VPN concentrator):

1. Take the "inspection" program the server provides the client to prove the client is "safe" and execute the inspection program in a spoofed or virtual environment. When the inspection program looks for evidence of Microsoft Windows + latest patches + AV, spoof the evidence they exist.
2. Reverse engineer the "everything is OK, let 'em on the network" message the inspection program sends the server, then don't even bother executing the inspection program, just cut to the chase and send the all-clear message by itself.

Sure, there may be some nuances that will make this slightly more difficult, such as adding some dynamic or more involved deterministic logic into the "inspection" program, but the more sophisticated the checks are, the more likely the whole process will break and generate false positives for legit users who are following the rules. The more false positives, the less likely customers will deploy the flawed technology.


...


So to recap: you cannot control a client or truly know anything about it. It's just not possible, so security practitioners should look to setting policies that include the fact that you cannot control a remote client. For a great in-depth review of all of these principles (with tons more examples), I suggest picking up a copy of Gary McGraw's and Greg Hoglund's "Exploiting Software: How to break code" book.

PCI Silverbullet for POS?

Has Verifone created a PCI silverbullet for Point Of Sale (POS) systems with their VeriShield Protect product? It's certainly interesting. It claims to encrypt credit card data BEFORE it enters POS, passing a similarly formatted (16 digit) encrypted card number into POS that presumably only your bank can decrypt and process.


I have to admit, I like the direction it's headed in. Any organization's goal (unless you are a payment processor) should be to reduce your PCI scope as much as possible, not try to bring PCI to your entire organization. This is a perfectly viable option to addressing risk that is often overlooked: ditch the asset. If you cannot afford to properly protect an asset, and you can find a way to not have to care for the asset anymore, then ditch it.

The questions I have about this specific implementation that are certainly going to have to be answered before anyone can use this to get a PCI QSA off of their back are:

1) What cryptographers have performed cryptanalysis on this "proprietary" design? Verifone's liberty to mingle the words "Triple DES" into their own marketing buzz format, "Hidden TDES", should at least concern you, if you know anything about the history of information security and the track records of proprietary encryption schemes. Since the plaintext and the ciphertext are exactly 16 digits (base 10) long and it appears that only the middle 6 digits are encrypted (see image below), this suggests that there might exist problems with randomness and other common crypto attacks. Sprinkle in the fact that credit card numbers must comply with the "Mod 10" rule (Luhn alogirthm), and I'm willing to bet a good number theorist could really reduce the possibilities of the middle 6 digits. If only the middle 6 digits are encrypted, and they have to be numbers between 0 and 9, then the probability of guessing the correct six digit number is one in a million. But the question is (and it's up to a mathematician or number theorist to answer), how many of the other 999,999 combinations of middle 6 digits, when combined with the first 6 and last 4 digits, actually satisfy the Mod 10 rule? [Especially since the "check digit" in the mod 10 credit card number rule is digit 14, which this method apparently doesn't encrypt.] I'm no mathematician, but I'm willing to bet significantly fewer than 999,999 satisfy the mod 10 rule. It's probably a sizeable cut-down on the brute-force space. If there are any other mistakes in the "H-TDES" design or implementation, it might be even easier to fill in the middle 6 gap.

It would be great to know that Verifone's design was open and peer-reviewed, instead of proprietary. I'd be very curious for someone like Bruce Schneier or Adi Shamir to spend some time reviewing it.


2) How are the keys generated, stored, and rotated? I certainly hope that all of these devices don't get hardcoded (eeprom's flashed) with a static shared key (but I wouldn't be surprised if they are). It would be nice to see something like a TPM (secure co-processor) embedded in the device. That way, we'd know there is an element of tamper resistance. It would be very bad if a study like the one the Light Blue Touchpaper guys at Cambridge University just published would detail that all of the devices share the same key (or just as bad, if all of the devices for a given retailer or bank share the same key).

It would be great if each device had its own public keypair and generated a session key with the bank's public key. This could be possible if the hardware card-swipe device sent the cardholder data to the bank directly instead of relying on a back office system to transmit it (arguably the back-end could do the transmission, provided the card swipe had access to generate a session key with the bank directly).

3) Will the PCI Security Council endorse a solution like this? (Unfortunately, this is probably the most pressing question on most organizations' minds.) If this does not take the Point of Sale system out of PCI scope, then most retailers will not embrace the solution. If the PCI Security Council looks at this correctly with an open mind, then they will seek answers to my questions #1 and #2 before answering #3. In theory, if the retailer doesn't have knowledge or possession of the decryption keys, POS would not be in PCI scope any more than the entire Internet is in PCI scope for e-tailers who use SSL.

...

Many vendors (or more accurately "payment service providers") are using "tokenization" of credit card numbers to get the sticky numbers out of e-tailers' databases and applications, which is a similar concept for e-commerce applications. A simple explanation of tokenizing a credit card number is simply creating a surrogate identifier that means nothing to anyone but the bank (service provider) and the e-tailer. The token replaces the credit card number in the e-tailer's systems, and in best-case scenarios the e-tailer doesn't even touch the card for a millisecond. [Because even a millisecond is long enough to be rooted, intercepted, and defrauded; the PCI Security Council knows that.]

It's great to see people thinking about solutions that fit the mantra: "If you don't have to keep it, then don't keep it."

[Note: all images are likely copyrighted by Verifone and are captures from their public presentation in PowerPoint PPS format here.]

...[Updated May 23, 2008: Someone pointed out that PCI only requires the middle 6 digits (to which I refer in "question 1" above) to be obscured or protected according to requirement 3.3: "Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed)." Hmmm... I'm not sure how that compares to the very next requirement (3.4): "Render PAN [Primary Account Number], at minimum, unreadable anywhere it is stored" Looks like all 16 digits need to be protected to me.]

Why You Don't Need a Web Application Layer Firewall

Now that PCI 6.6's supporting documents are finally released, a lot people are jumping on the "Well, we're getting a Web Application Firewall" bandwagon. I've discussed the Pros and Cons of Web Application Firewalls vs Code Reviews before, but let's dissect one more objection in favor of WAFs and against code reviews (specifically static analysis) ...

This is from Trey Ford's blog post "Instant AppSec Alibi?"

Let’s evaluate this in light of what happens after a vulnerability is identified- application owners can do one of a couple things…

1. Take the website off-line
2. Revert to older code (known to be secure)
3. Leave the known vulnerable code online

The vast majority of websites often do the latter… I am personally excited that the organizations now at least have a viable new option with a Web Application Firewall in the toolbox! With virtual patching as a legitimate option, the decision to correct a vulnerability at the code level or mitigate the vuln with a WAF becomes a business decision.

There are two huge flaws in Mr Ford's justification of having WAFs as a layer of defense.

1) Web Application Firewalls only address HALF of the problems with web applications: the syntactic portion, otherwise known in Gary McGraw speak as "the bug parade". The other half of the problems are design (semantic) problems, which Gary refers to as "security flaws". If you read Gary's books, he eloquently points out that research shows actual software security problems fall about 50/50 in each category (bugs and flaws).

For example, a WAF will never detect, correct, or prevent horizontal (becoming another user) or vertical (becoming an administrator) privilege escalation. This is not an input validation issue, this is an authorization and session management issue. If a WAF vendor says their product can do this, beware. Given the ideal best case scenario, let's suppose a WAF can keep track of the source IP address of where "joe" logged in. If joe's session suddenly jumps to an IP address from some very distinctly different geographic location and the WAF thinks this is "malicious" and kills the session (or more realistically the WAF just doesn't pass the transactions from that assumed-to-be-rogue IP to the web application), then there will be false positives, such as corporate users who jump to VPN and continue their browser's session, or individuals who switch from wireless to an "AirCard" or some other ISP. Location based access policies are problematic. In 1995 it was safe to say "joe will only log on from this IP address", but today's Internet is so much more dynamic than that. And if the WAF won't allow multiple simultaneous sessions from the same IP, well forget selling your company's products or services to corporate users who are all behind the same proxy and NAT address.

Another example: suppose your org's e-commerce app is designed so horribly that a key variable affecting the total price of a shopping cart is controlled by the client/browser. If a malicious user could make a shopping cart total $0, or worse -$100 (issuing a credit to the card instead of a debit), then no WAF on today's or some future market is going to understand how to fix that. The WAF will say "OK, that's a properly formatted ASCII represented number and not some malicious script code, let it pass".

Since the PCI Security Standards Council is supporting the notion of Web Application Firewalls, that begs the question: Does the PCI Security Standards Council even understand what a WAF can and cannot do? Section 6.6 requires that WAFs or Code Reviews address the issues inspired by OWASP which are listed in section 6.5:

6.5.1 Unvalidated input
6.5.2 Broken access control (for example, malicious use of user IDs)
6.5.3 Broken authentication and session management (use of account credentials and session cookies)
6.5.4 Cross-site scripting (XSS) attacks
6.5.5 Buffer overflows
6.5.6 Injection flaws (for example, structured query language (SQL) injection)
6.5.7 Improper error handling
6.5.8 Insecure storage
6.5.9 Denial of service
6.5.10 Insecure configuration management

The following items fall into the "implementation bug" category which could be addressed by a piece of software trained to identify the problem (a WAF or a Static Code Analyzer):

6.5.1 Unvalidated input
6.5.4 Cross-site scripting (XSS) attacks
6.5.5 Buffer overflows
6.5.6 Injection flaws (for example, structured query language (SQL) injection)
6.5.7 Improper error handling

These items fall into the "design flaw" category and require human intelligence to discover, correct, or prevent:

6.5.2 Broken access control (for example, malicious use of user IDs)
6.5.3 Broken authentication and session management (use of account credentials and session cookies)
6.5.8 Insecure storage
6.5.9 Denial of service
6.5.10 Insecure configuration management

Solving "design" or "semantic" issues requires building security into the design phase of your lifecycle. It cannot be added on by a WAF and generally won't be found by a code review, at least not one that relies heavily on automated tools. A manual code review that takes into consideration the criticality of a subset of the application (say, portions dealing with a sensitive transaction) may catch this, but don't count on it.



2) If your organization has already deployed a production web application that is vulnerable to something a WAF could defend against, then you are not really doing code reviews. There's no more blunt of a way to put it. If you have a problem in production that falls into the "bug" category that I described above, then don't bother spending money on WAFs. Instead, spend your money on either a better code review tool OR hiring & training better employees to use it (since they clearly are not using it properly).



Bottom line: any problem in software that a WAF can be taught to find could have been caught at development time with a code review tool, so why bother buying both. You show me a problem a WAF can find that slipped through your development process, and I'll show you a broken development process. Web Application Firewalls are solution in search of a problem.

Sending Bobby Tables to the Moon

NASA has a program where you can send your name to the moon. Just give them your name, they'll store it electronically, and send it on the next lunar rover to be left there forever.

Now, little Bobby Tables will be immortalized forever on the moon.

Automating Exploitation Creation

Some academic security researchers at Carnegie Mellon have released a very compelling paper which introduces the idea that just monitoring a vendor's patch releases can allow for an automated exploit creation. (They call it "APEG".) They claim that automated analysis of the diffs between a pre-patched program and a patched program is possible-- and that in some cases an exploit can be created in mere minutes when some clients take hours or days to check in and install their updates! Granted there is some well established commentary from Halvar Flake about the use of the term "exploit" since the APEG paper really only describes "vulnerability triggers" (Halvar's term).

Our friends at Carnegie Mellon have proved that the emperor hath no clothes. Creating exploits from analyzing patches is certainly not new. What is novel, in this case, is how the exploit creation process is automated:

"In our evaluation, for the cases when a public proof- of-concept exploit is available, the exploits we generate are often different than those publicly described. We also demonstrate that we can automatically generate polymorphic exploit variants. Finally, we are able to automatically generate exploits for vulnerabilities which, to the best of our knowledge, have no previously published exploit."

PCI 1.1 Section 6.6

If you're one of the many practitioners waiting to see how the PCI Security Council clarifies the ambiguous 6.6 requirement, then you may wish to use this interview with Bob Russo, General Manager of the PCI Security Standards Council, as either an inkling towards an interpretation OR just more obfuscation (depending upon your point of view).

Here is the PCI requirement in question:

6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:
• Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
• Installing an application layer firewall in front of web-facing applications.
Note: This method is considered a best practice until June 30, 2008, after which it becomes a requirement.

Russo's comments on the debate of Web Application Firewalls versus Code Reviews:

"Personally, I'd love to see everyone go through on OWASP-based source-code review, but certainly, that's not going to happen," Russo said, referring to the expensive and time-consuming process of manual code reviews. "So the application firewall is probably the best thing to do, but there needs to be some clarification around what it needs to do. That clarification is coming; that's been the biggest question."

Jeremiah Grossman sounded off on the interview as well.



Even given all of the discourse I have heard and read to date, there are many unanswered questions on this one particular point alone. No doubt the PCI Security Standards Council has realized that application layer problems are going to undermine everything else we have taught security practitioners for the last decade about the idiocy of controlling security at the network layers. And no doubt the PCI Security Standards Council understands they have a mighty hand to influence organizations to handle their custom software with the appropriate level of diligence and quality that cardholders deserve. However ...

Here are my top 7 questions concerning PCI 1.1, Requirement 6.6 that are still left unanswered:

1) Please define "web-facing applications". Does that mean HTTP/S applications? Does that mean anything directly exposed to Internet traffic? Or, does it mean any application that Al Gore created? [PCI Expert, Trey Ford, attempted to define "web-facing", but we need the offical PCI Security Council interpretation.]

2) Please define "known attacks". Known by whom? Who is keeping the authoritative list? What happens when new attacks become "known" and are added to the list? Do we have to go back and perform more analysis to check for the new attacks?

3) Please define "an organization that specializes in application security". Is that a third party or can it be a team within an organization? Can it be a team of one in a smaller organization? What is meant by "specializes"? Does that mean "took a class", "has a certificate", or is that reserved for somebody who leads the industry in the subject matter? "Application Security" as a discipline (sorry, Gary McGraw--you're right, we should call it "software security") is new. Will we have a chicken and egg problem trying to establish people as specialists in application security?

4) Does a blackbox (runtime) scanning approach constitute a "review" of custom application code? Or will only a whitebox (source code at development time) cut the mustard? Can automated review tools be used, or must it be 100% manual (human) code review? To what extent can automation be involved? Are there specific products (vendors) that are preferred or required when selecting automated tools?

5) Does the "review" imply remediation? In the case of PCI Vulnerability Scanning Procedures, some lesser vulnerabilities are allowed to exist, but vulnerabilities that the PCI Security Standards Council rate at a higher criticality must absolutely be fixed. What criticality scale must we use? Is there a taxonomy of vulnerabilities that are categorized by "must fix" criticality versus a "should fix" criticality?

6) Please define "an application layer firewall". Is that a preventative tool or can it be just a detective tool (i.e. must it be active or can it be passive, like an IDS)? What "bad things" must it detect? How tight must it be tuned? Will there be a process to pre-certify vendors, or must we invest in it now and hope that auditors will accept what we choose?

7) Why is that we are (as of today) only a mere 76 days out from when requirement 6.6 becomes mandatory and we do NOT yet have clarification? Large organizations move slowly. Complicated "web-facing applications" may take a long time to properly regression test with either option implemented (remediations found in code reviews OR web application layer firewall deployments). We have little over two months to: 1) Understand the requirement, 2) Budget accordingly, and 3) Implement on time and under budget. With PCI DSS version->next right around the corner, why wasn't this requirement held off until it could be properly flushed out in the next version?

University of Washington's Computer Security Course

Tadayoshi Kohno, a Computer Science Professor at the University of Washington, is teaching an undergraduate computer security course with a unique set of intentions: Kohno is trying to teach the security mindset-- the same mindset that Bruce Schneier has been talking about for years.

The results are interesting, not to mention available to the public. Students transforming into a security mindset are writing analytical views of just about anything, from dorm rooms to high-tech. It's available here in blog format.

More Broken DRM

From Slashdot:

"In July 2007, Richard Doherty of the Envisioneering Group (BD+ Standards Board) declared: 'BD+, unlike AACS which suffered a partial hack last year, won't likely be breached for 10 years.' Only eight months have passed since that bold statement, and Slysoft has done it again. According to the press release, the latest version of their flagship product AnyDVD HD can automatically remove BD+ protection and allows you to back-up any Blu-ray title on the market."

How many more times must we endure the faulty logic of DRM (Digital Rights Management)? It's simple, that is if you understand key management. You cannot have a ciphertext (the Blu-ray movie) that you allow an end-user to convert to a plaintext (i.e. when it's playing in a hardware or software player) without also allowing plaintext access to the key that unlocks the ciphertext (which all players must have, otherwise the video is just encrypted data-- not playable).

DRM defies the laws of nature. It's just like the recent cold-boot attacks on disk encryption. The decryption keys are there. They're in the software. If you can manipulate the hardware, you can get them. And sometimes (as is the case with the BD+ hack) you don't even have to manipulate the hardware. The keys have to be stored somewhere-- usually in memory just like the whole disk encryption vendors. In fact, a possible application of the Princeton group's research could be to cold boot computers that are playing BD+ protected blu-ray discs, since they came up with new methods of finding (identifying) encryption keys stored in decaying DRAM, correcting the bit-flip decay.

Even if the Blu-ray people mandated that only hardware Blu-ray devices could be created and sold (since software players have been the primary target for DRM destruction), the keys would have to exist in every one of their customer's homes-- right there in the players! It might be a little more difficult to reverse engineer and discover since hardware tends to not be as flexible as software, but the keys would have to be there, stored in CMOS perhaps, or possibly just hard-coded into the decryption-playback circuits. And we have seen, time and time again, that the efforts of even a single person to reverse engineer the decryption key can be devastating to DRM schemes. All it takes is one person to discover it and a company like Slysoft to find a way to legally market it.


...
In summary: DRM is not possible. If you present data to a person outside of your physical reach, then you cannot control how they use the data. Anyone who claims otherwise is peddling the information security equivalent to perpetual motion. Don't buy it.

Anderson Proves PIN Entry Devices are Insecure

If there is a theme in good security research right now, it's that we cannot trust hardware.

Ross Anderson and company at the Computer Laboratory at Cambridge University have performed some interesting research demonstrating how a paperclip can be used to steal cardholder data from a bank card PIN Entry Device (PED). Machines believed to be secure because they were assessed through the weakest level of the esteemed Common Criteria are apparently ripe with flaws. The Cambridge group believes that fraudsters have been using these techniques for some time.

Jon Callas Responds to Ed Felten

It's nice to not be on the top spot of Jon Callas' "CTO Corner" anymore ... although I held that spot for four and a half months. Jon Callas, the CTO of PGP Corporation, has moved on to respond to Ed Felten's memory-freezing, whole-disk-encryption-key-stealing crew at Princeton University.

Some highlights from Jon's response ...

"The basic issue is one that we have known for years."

Well, that's not very concerting, or at least it shouldn't be. If it was so well known, then why is PGP Corp just now looking to integrate with hardware and BIOS vendors to attempt to resolve this? That line, along with Jon's general theme, is that this is no big deal ... we've known about it forever ... it's just a new spin on an old trick ...

"Those of us who consider these things have known that this was at least in theory possible for some time. This team did two impressive things: they made it actually work, and they did some math to recover partially-damaged RSA and AES keys. This latter feat they did by looking at scratch variables that the encryption systems use, and back-deducing what some of the damaged bits of the keys must have been. The process is a bit like a big Sudoku game; when you play Sudoku, you deduce what is missing based on what is present."

Again, "it's no big deal", except, wait, yep, there's that really complicated math part. I do like Jon's comparison to Sudoku; it's a good analogy.

"Despite how dramatic this attack is, there is an easy fix for it."

If there really was an easy fix for it, then the whole notion of "coldboot" would be a solved problem, but that's obviously not the case. Ripping power from a running system (which Jon later goes on to say has never been the primary threat that PGP WDE was designed to overcome) does not protect the keys. Even if BIOS vendors started shipping with features that sanitize memory at boot, a quick power off optionally followed by a cool down of DRAM and finally placing the memory into a prepared system could still read the encryption keys. Yes, that requires a dedicated and trained adversary, but there are organizations with very valuable information. Jon should not be so quick to downplay the likelihood that his customers may have such an adversary, unless of course the really security conscious organizations have been skipping his company's products altogether.

"When a computer is hibernated, the contents of its memory is written to disk, and then the computer is shut down. No residual power is supplied to the RAM, so it will fade in one to two minutes, just as if you had shut it off. It doesn't matter what software you are running; if you hibernate a machine with WDE, it will be safe in a couple of moments. (Note: the Cold Boot researchers say that hibernate mode is vulnerable, and they are wrong on this nit. A truly hibernated machine is turned off, but with a copy of RAM written to disk. These machines are safe, once memory has faded.)"

Anyone else want to hear Felten's and crew's response to the hibernate "nit"?

"If there is a hard power loss, such as pulling the battery from a laptop or yanking the power cord out from a server, there's next to nothing that software alone can do. There's next to nothing that hardware can do. We could design hardware and software to do something in this case, but you probably wouldn't pay for it. I wouldn't."

I can think of several options here, all of which cannot be so expensive that when typical economies of scale (mass production and consumer demand) are applied the price becomes unreasonable. I'm not sure what this says about what's on Jon's computer, that he wouldn't be interested something as simple as a small reserve of electrical power (like in a capacitor) that can detect when main power has diminished and employs its small reserve which is just ample to perform a basic overwrite or sanitizing operation on DRAM. Such a feature could not possibly cost more than a seat of PGP WDE.

"External authentication using smart cards, tokens, TPMs, does not solve the problem. There have been reports of some people claiming that it does. It doesn't. Remember, this is very simple; there is some RAM that has a key, and that RAM needs to be cleared. Authentication doesn't clear memory. TPMs do not clear memory. The people who claim that a USB key helps at all are displaying their ignorance."

I agree that USB keys don't clear memory. What was Dr. Eric Cole of SANS thinking when he said this in the Feb 29th issue of their Newsbites?

"(Cole): The cold boot attack has a cool factor to it, but remember that
full disk encryption will protect a system only if it has a strong
password (two factor recommended) and if the system is completely turned
off. Use of a USB token stops the attack. If you turn your system
completely off (and hold on to it for more than 5 seconds) the attack
is not successful. If you do not follow either of these rules, than
full disk encryption can potentially be broken even without this
attack.]"

But a future generation of TPMs, or more specifically secure co-processors, could potentially perform all cryptographic operations in hardware, not just integrity checking of boot procedures. Whereas today's TPMs can store keys only later to hand them off to a process that will unfortunately store them in DRAM, the next generation of secure co-processors could be passed the ciphertext blocks of data for decryption, passing the plaintext version back to a WDE-like service. There will be I/O performance concerns to overcome initially, but it is feasible that a commodity-priced chip will one day solve that problem.

"There is more reason to use WDE in conjunction with either Virtual Disk or NetShare. We have always said that the primary threat model for WDE is a machine that is shut down or hibernated. We have always pointed to the added benefits of the other forms of encryption. In his recent article on mobile data protection, Bruce Schneier touts PGP Virtual Disk. The PGP Encryption Platform gives you defense in depth. Defense in depth is good because the layers of protection give more security."

Translation: buy more of their products.



Of course, there's always the solution I have offered despite common objections: one method for securing information is to not place it on disk at all. Encryption is not always the answer.

Excellent Cold Boot Step-By-Step

News.com has an excellent step-by-step complete with pictures detailing what it takes to steal the encryption keys for Apple's File Vault using the Princeton University's Cold Boot attack on whole disk encryption. Jacob Appelbaum, one of the independent security researchers involved with Ed Felten's Princeton crew, is your guide.

Felten Destroys Whole Disk Encryption

Ed Felten and company publicized some research findings today on a form of side-channel attack against whole disk encryption keys stored in DRAM.

We show that disk encryption, the standard approach to protecting sensitive data on laptops, can be defeated by relatively simple methods. We demonstrate our methods by using them to defeat three popular disk encryption products: BitLocker, which comes with Windows Vista; FileVault, which comes with MacOS X; and dm-crypt, which is used with Linux....

Our research shows that data in DRAM actually fades out gradually over a period of seconds to minutes, enabling an attacker to read the full contents of memory by cutting power and then rebooting into a malicious operating system....
Interestingly, if you cool the DRAM chips, for example by spraying inverted cans of “canned air” dusting spray on them, the chips will retain their contents for much longer. At these temperatures (around -50 °C) you can remove the chips from the computer and let them sit on the table for ten minutes or more, without appreciable loss of data. Cool the chips in liquid nitrogen (-196 °C) and they hold their state for hours at least, without any power. Just put the chips back into a machine and you can read out their contents.
This is deadly for disk encryption products because they rely on keeping master decryption keys in DRAM. This was thought to be safe because the operating system would keep any malicious programs from accessing the keys in memory, and there was no way to get rid of the operating system without cutting power to the machine, which “everybody knew” would cause the keys to be erased.
Our results show that an attacker can cut power to the computer, then power it back up and boot a malicious operating system (from, say, a thumb drive) that copies the contents of memory. Having done that, the attacker can search through the captured memory contents, find any crypto keys that might be there, and use them to start decrypting hard disk contents. We show very effective methods for finding and extracting keys from memory, even if the contents of memory have faded somewhat (i.e., even if some bits of memory were flipped during the power-off interval). If the attacker is worried that memory will fade too quickly, he can chill the DRAM chips before cutting power.

This is a good example of academic security research. We need to see that the trust placed upon the hardware by the whole disk encryption software is a faulty decision.

There's even a video:

Websense CEO on AV Signatures

Websense CEO, Gene Hodges, on the futility of signature based antivirus, just an excerpt:

On the modern attack vector: Antivirus software worked fine when attacks were generally focused on attacking infrastructure and making headlines. But current antivirus isn’t very good at protecting Web protocols, argued Hodges. “Modern attackware is much better crafted and stealthy than viruses so developing an antivirus signature out of sample doesn’t work,” said Hodges. The issue is that antivirus signature sampling starts with a customer being attacked. Then that customer calls the antivirus vendor, creates a sample, identifies the malware and then creates the sample. The conundrum for antivirus software comes when there’s malware that’s never detected. If you don’t know you’re being attacked there’s no starting point for a defense. “Infrastructure attacks are noisy because you wanted the victim to know they have been had. You didn’t have to be a brain surgeon to know you were hit by Slammer. Today’s malware attacks are stealthy and don’t want you to know it’s there,” said Hodges.

Is antivirus software necessary? Hodges said that antivirus software in general is still necessary, but the value is decreasing. Hodges recalled discussions at a recent conference and the general feeling from CIOs that viruses and worms were a solved problem. Things will get very interesting if there’s a recession and customers become more selective about how they allocate their security budgets. For instance, Hodges said CIOs could bring in Sophos, Kaspersky and Microsoft as antivirus vendors and “kick the stuffing out of the price structure for antivirus and firewalls.” The dollars that used to be spent on antivirus software could then be deployed for more data centric attacks that require better access control, encryption and data leakage. My take: Obviously, Hodges has a motive here since these budget dollars would presumably flow in Websense’s direction. That said the argument that the value of antivirus software is declining makes a lot of sense and is gaining critical mass.

Web 2.0 as security risk. Hodges said Web 2.0–or enterprise 2.0–techniques could become a security risk in the future, but Websense “really hasn’t seen significant exploitation of business transactions of Web 2.0.” That said enterprises are likely to see these attacks in the future. For starters, enterprises generally allow employees to tap sites like YouTube, Facebook and MySpace. Those sites are big targets for attacks and connections to the enterprise can allow “bad people to sneak bad stuff into good places,” said Hodges. In other words, the honey pot isn’t lifting data from Facebook as much as it is following that Facebook user to his place of employment. Meanwhile, Web connections are already well established in the enterprise via automated XML transactions, service oriented architecture and current ERP systems. Hodges noted that Oracle Fusion and SAP Netweaver applications fall into the Web 2.0 category.

Even the security CEOs can see it (the futility of signature based anti-malware, that is).

Localhost DNS Entries & "Same Site Scripting"

I'm not a big fan of new names for variations of existing attacks, but Tavis Ormandy (of Google) has pointed out an interesting way to leverage non-fully qualified DNS entries for localhost (127.0.0.1) with XSS:

It's a common and sensible practice to install records of the form
"localhost. IN A 127.0.0.1" into nameserver configurations, bizarrely
however, administrators often mistakenly drop the trailing dot,
introducing an interesting variation of Cross-Site Scripting (XSS) I
call Same-Site Scripting. The missing dot indicates that the record is
not fully qualified, and thus queries of the form
"localhost.example.com" are resolved. While superficially this may
appear to be harmless, it does in fact allow an attacker to cheat the
RFC2109 (HTTP State Management Mechanism) same origin restrictions, and
therefore hijack state management data.

The result of this minor misconfiguration is that it is impossible to
access sites in affected domains securely from multi-user systems. The
attack is trivial, for example, from a shared UNIX system, an attacker
listens on an unprivileged port[0] and then uses a typical XSS attack
vector (e.g. in an html email) to lure a victim into
requesting http://localhost.example.com:1024/example.gif, logging the
request. The request will include the RFC2109 Cookie header, which could
then be used to steal credentials or interact with the affected service
as if they were the victim.

Tavis recommends removing localhost entries from DNS servers that do not have the trailing period (i.e. "localhost" vs. "localhost."). The trailing period assures that somebody cannot setup camp on 127.0.0.1 and steal your web applications cookies or run any other malicious dynamic content in the same domain, exploiting DNS for same origin policy attacks.

WiKID soft tokens

I promised Nick Owens at WiKID Systems a response and it is long overdue. Nick commented on my "soft tokens aren't tokens at all" post:

Greetings. I too have posted a response on my blog. It just points out that our software tokens use public key encryption and not a symmetric, seed-based system. This pushes the security to the initial validation/registration system where admins can make some choices about trade-offs.

Second, I submit that any device with malware on it that successfully connects to the network is bad. So you're better off saving money on tokens and spending it on anti-malware solutions, perhaps at the gateway, defense-in-depth and all.

Third, I point out that our PC tokens provide https mutual authentication, so if you are confident in your anti-malware systems, and are concerned about MITM attacks at the network, which are increasingly likely for a number of reasons, you should consider https mutual auth in your two-factor thinking.

Here's the whole thing:
On the security of software tokens for two-factor authentication
and thanks for stimulating some conversation!

Here is their whitepaper on their soft token authentication system.

Unfortunately, I would like to point out that WiKID is first and foremost vulnerable to the same sort of session stealing malware that Trojan.Silentbanker uses. It doesn't matter how strong your authentication system is when you have a large pile of untrustworthy software in between the user and the server-side application (e.g. browser, OS, third party applications, and all the malware that goes with it). I'll repeat the theme: it's time to start authenticating the transactions, not the user sessions. I went into a little of what that might look like.

Nick is aware of that, which is why he said point number two above. But here's the real problem: the web is designed for dynamic code to be pulled down side-by-side with general data, acquired from multiple sources and run in the same security/trust context. Since our browsers don't know which is information and which is instructions until runtime AND since the instructions are dynamic (meaning they may not be there for the next site visit), how is it NOT possible for malware to live in the browser? I submit that it is a wiser choice to NOT trust your clients' browsers, their input into your application, etc., than to trust that a one time password credential really did get input by the proper human on the other end of the software pile. I suggest that organizations should spend resources being able to detect and recover from security failures (out of band mechanisms come to mind-- a good old fashioned phone call to confirm that $5,000 transaction to a foreign national, perhaps?), rather than assuming the money they invested in some new one time password mechanism exempts them from any such problems.

Microsoft published a document titled "10 Immutable Laws of Security" (nevermind for now that they are neither laws, nor immutable, nor even concise) and point number one is entirely relevant: "Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore". How does javascript, a Turing Complete programming language, fall into that? If you completely disable script in your browser, most applications break. But if you allow it to run, behaviors you cannot control can run on your behalf. Taking Nick's advice, we should be spending all of your time and resources solving the code and data separation problem on the web, not implementing one time passwords (and I agree with him on that).



Second, I have a hard time calling WiKID a token-- not that it couldn't fit that definition-- it's just that it is a public key cryptography system. I never have referred to a PGP key pair as a token, nor have I heard anyone else. Likewise I don't really ever here anyone say "download this x509 token" ... instead they say "x509 certificate". Smart cards might be the saving grace example that allows me to stretch my mind around the vocabulary; generally speaking, a smart card is a physical "token" and smart card implementations can have a PKC key pair. So, I'll have to extend my personal schema, so to speak, but I guess I'll allow WiKID to fit into the "token" category (but just barely).

The x509 cert example is a great analogy, because under the hood that's basically how WiKID works. Just like an HTTPS session, it swaps public keys (which allows for the mutual authentication) and then a session key is created for challenge/response-- the readout of the "soft token" that the user places into the password form, for example.


There is one concerning issue with WiKID. It uses a relatively unknown public key encryption algorithm called NTRU. NTRU aims to run in low resource environments like mobile phones, which is undoubtedly why WiKID employs it. NTRU is also patented by NTRU Cryptosystems, INC (the patent may have some business/political ramifications similar to PGP's original IDEA algorithm). However, when choosing an encryption algorithm, it is best to use that which has withstood significant peer review. Otherwise, Kerckhoffs' Principle that we have come to know and love as "security by obscurity" will eat us alive when the first decent attack reduces our security to rubble. Googling for "NTRU cryptanalysis" returns around 3,000 hits. Googling for "RSA cryptanalysis" returns around 186,000-- two orders of magnitude higher. This is not the nail in WiKID's coffin, though, but it could be betting the company on Betamax. It is undoubtedly less popular than, say RSA or Eliptic Curve. In most aspects of life, supporting the underdog can result in a great time. Doing it in crypto, however, may not be a good idea.

Before somebody reads the above paragraph and goes in the extreme in either direction, please note my point: the workhorse of WiKID, the NTRU encryption algorithm, has an unknown security value. One could argue that RSA, likewise, has only a mostly known security value, but you decide: "mostly known" or "unknown"? There may not be any problems in NTRU and it may be perfectly safe and secure to use. Conversely it may be the worst decision ever to use it. That's what peer review helps us decide.


...
To sum up ... WiKID is cheap, open source, interesting, and ... still vulnerable to malware problems. And don't forget: you have to choose to use a less popular encryption algorithm.

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."