We have spoken about the famous Ken Thompson attack before. David Wheeler believes he has the answer and has published several papers on double compilation to counter the attack. That said you still must have access to a trusted compiler, right?
A fake proof of concept for the MS12-020 RDP vulnerability has been doing the rounds. Called rdpsmash the python script contains a block of shellcode that actually executes “rm -rf /” on *NIX or recursively deletes system32 on Windows (the former is obviously far worse).
As Michael Thumann from Insinuator said in his article, “never run any untrusted code (especially exploits) without a detailed analysis.” Well said Michael.
The massive data breach which occurred recently at Adobe has resulted in the theft of the source code of some of its proprietary products and the compromise of at least 38 million user account credentials. A tarball of the account information was uploaded to Anonymous related websites recently, meaning that if you have/had an account at Adobe then a hash of your password along with identifying information (your e-mail address) is now out in the wild.
Visitors here will know better than to reuse passwords between websites but research has proven time and time again that the average user has at most two or three passwords, perhaps slightly modifying them where password strength requirements differ (e.g. appending a zero on sites that require a mix of character types) or where password changes are enforced. This subset of Internet user is also unlikely to have selected a password that would withstand dictionary cracking meaning that their plaintext password will no doubt be obtained quickly.
So what could you do with all these credentials? Many of these email accounts will be for webmail providers. Those that are not will likely have external POP or IMAP access. Obviously this is great news for spammers especially if these organizations are running an SMTP server that allows remote relaying after authentication, but perhaps we are misunderstanding the true value of these accounts.
People increasingly manage their lives through their e-mail accounts. Even if we assume that our dear user has only partially reused passwords then it would nonetheless be trivial for our hypothetical hacker to simply use a forgotten password link on said site and reset the password. If he uses information gleaned from the account (e.g. timezone information from a recently sent item in their Sent folder) then he can time this to be at an hour where the account compromise will not be discovered for some time, buying him a few hours to perform whatever nefarious act he pleases.
Unfortunately your email address is a unique identifier. Please take a moment to consider if you have reused the same password between different domains. If you think this is too much trouble then at least ensure that you never reuse the password for your primary email account. That just makes it too easy for them.
Adobe are busy sending out millions of password reset links. If you receive such an email, please have a think about where you may have used the same password and set about implementing better policy.
I guess I should mention that password managers are no panacea. There have been vulnerabilities in the past in software such as Lastpass that have enabled remote retrieval of such information. If you choose to use such software then ensure that the software encrypts your password database with your master password before synchronizing it to the cloud and be mindful that you have consolidated risk.
The data is not in the standard hashed format you would expect but is instead encrypted with a key using 3DES which may at least somewhat dampen the consequences for those exposed. That said even if the password cannot be recovered metadata including their email address has been leaked to the world.
Bruce Schneier has published an excellent article entitled The Battle For Power On The Internet. The article first appeared in The Atlantic but is mirrored on his site. It is well worth a look.
Xavier de Carné de Carnavalet, a master’s student at Concordia University, Montreal recently demonstrated that the official binary of Truecrypt 7.1a for Windows is indeed produced from the supplied source. Proving that a compiled binary derives from the same source on many platforms is far from trivial as you must ensure that all variables (compiler flags, library versions, etc.) are identical to the original build. His report includes detailed instructions should you wish to reproduce his results.
Of course this does not mean that Truecrypt is proven to be safe. This merely validates that the source code and binaries released to the public match. A backdoor could still exist in the source – and yes, a subtle “bug” could hide in plain site for long period of time.
A concerned individual sent me an e-mail relating to claims I made in a previous article about BitLocker, Microsoft Windows’ integrated full disk encryption software. In the article I suggested that full disk encryption on Windows systems might be a waste of time against a nation state level adversary. I stand by those comments.
An article on mashable about a month ago detailed claims that the alphabet soup agencies asked for (and it is implied likely attained) a backdoor that would allow BitLocker encrypted volumes to be read. Given the closed source nature of both BitLocker and the Windows operating system it is impossible to substantiate this argument in either the affirmative or the negative.
Given Microsoft has a history of cooperation with the NSA (remember the suspicious NSAKEY that was found in the crypto DLL about ten years ago?) I feel it is reasonable to assume that the alphabet agencies have some means to subvert the software.
Most disk encryption software does not actually encrypt the entire drive with the user supplied passphrase. Such a scheme would, amongst other things make changing the passphrase a less than trivial process as the entire disk would need to be decrypted with the old passphrase and encrypted again with the new one, block by block. The typical solution to this issue is to generate a strong and long random key which is used to encrypt and decrypt the data. This key is then encrypted using the user’s passphrase (which is usually stretched using a few thousand rounds of PDKBF2) and stored on the disk. When mounting an encrypted volume the software requests the passphrase (or token) from the user and uses this to obtain the actual on disk encryption key. This system allows almost instant password changes with the caveat that the static key used to actually encrypt the data on the disk never changes and thus if it is compromised directly (through, say a cold boot attack) the user may falsely believe that changing the password will re-secure the volume. Naturally such a scheme also creates a single point of failure such that if the blocks that store the keying data are corrupted the entire volume is rendered unreadable. Sometimes this is used advantageously as a way of effectively immediately rendering the disk unusable by overwriting just those blocks. Most schemes store the data in two or more separate locations at diverse positions on the disk, for example one in the volume header and one in the footer.
A subverted full disk encryption solution could store only slightly more data in this area and allow bypass by storing not only the on disk key encrypted to the user’s passphrase but a copy that is encrypted using the NSA’s public key. This is essentially a form of key escrow with the exception that the term generally implies the user has knowledge of it occurring.
A slightly more robust (and covert) scheme involves limiting the entropy of the pseudorandom number generator used by the encryption software. This has the advantage that a reference implementation which successfully opens an encrypted volume could be released (along with full source code) to essentially prove they have nothing up their sleeve. Of course should someone use the “clean” implementation to create a new volume this volume would not be generated with the deliberate entropic weakness but you can almost guarantee that few users would have the inclination or skill to compile from source and most would use the officially distributed binaries. With a closed source operating system you could even defer random number generation to a library which is shipped with the operating system thus ensuring that even the “clean” implementation would produce the required weakness. Third party that relied upon said libraries would also be able to be compromised. The dirty PRNG could indeed produce random numbers but with a confined seed thus reducing the amount of time a brute force attack would take when such seed values are known. It could also simply be running AES in counter mode and working from a known secret which then becomes the agency’s master key.
The implementation could also deliberately leak the key perhaps stashing it elsewhere on the drive in an obfuscated manner and then using the ATA command set to tell the drive controller to mark these blocks as bad. It could then zero the logical blocks with the knowledge that they have been remapped and the key persists on the physical media. This is obviously platform dependent. The implementation could also conceivably leak the key during the initial Windows activation or during a Windows Update. If the HDD serial number is queried using SMART and transmitted along with the leaked key then a database would be held that could be queried by an agency like the NSA when they seize a computer that uses said implementation just by supplying the serial number of the disk. This would be far more persistent than storing the CPU ID, MAC address or other identifying information as the disk may be portable or could conceivably move from an old computer to a new one throughout its life. Failing this (say, if the disk has been cloned to another with a different serial) all known keys could be tried via a brute force attack. This would likely not take a lot of time on a modern cluster and would certainly be preferable to brute forcing the passphrase – which would not be feasible if a strong one of a long length is used. We will assume that the user is smart enough to avoid using natural language or a simple password that could be determined using a dictionary attack.
My point here is that I cannot definitively say that BitLocker contains a backdoor nor can I claim that it is safe. Given the source code of Windows is not available for review this will remain a topic of contention. Even if the source code was available a subtle backdoor may indeed go undetected (see the attempted Linux backdoor where using = instead of == in the code would allow a privilege escalation for an idea as to just how subtle these things can be). Assuming that the code is clean and has been audited one could not guarantee that the public binary release of Windows is identical to the one released as source without Microsoft adhering to some kind of deterministic build system to actively allow such an audit to take place.
Given the number of proprietary drivers (and other code that is bound by third party licensing and/or NDA) included in Windows it is doubtful that Microsoft could ever fully open source Windows even if they wanted to (and they clearly don’t).
My advice therefore remains unchanged. Don’t rely on BitLocker (or Windows at all for that matter) to protect your secrets, particularly if your threat model includes the government as a potential adversary.
Greenwald and Gibson recently answered questions on a reddit thread. That said there are no startling revelations.
When questioned on the need for redactions as per the specific encryption technologies subverted in one of the first documents leaked Greenwald responded that the NSA has subverted many products and to list only those two would not be representative of actual fact. I question the need for any redactions except for operational information that may endanger the lives of witnesses or embedded operatives. Clearly the concern here is not focused on welfare but on maintaining the public image on the two companies who were unfortunate enough to be mentioned.
Even if the document only identifies two of the supposed large number of companies who have been collaborating with the NSA then the two names should be released. At least those companies which are identified can be boycotted and held to account by the community for egregiously damaging the security of their paying customers. Whether these organizations complied willingly or were somehow coerced is irrelevant. We have seen with Lavabit and Cryptoseal’s actions how principled organizations respond, even at the expense of destroying their income stream to protect their customers from subversion.