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.
The #badBIOS malware that Dragos Ruiu is currently analyzing allegedly modifies TrueType font files on compromised systems. Obviously the “evil thumb drives” that infect the machines use some kind of exploit that allows low level access. This likely occurs during USB device enumeration. Once on the system TTF files are modified (amongst many other things). No doubt this is one way that the malware can execute their payload which likely ensures that any future thumb drives that are inserted into the machine from that point on have their firmware reflashed to continue spreading itself.
Microsoft released a security bulletin (MS13-081) on October 8 that mentioned a vulnerability in TTF handling that may allow arbitrary code to be executed, stating that:
The security update addresses these vulnerabilities by correcting the way that Windows handles specially crafted OpenType Font files and specially crafted TrueType Font (TTF) files, and by correcting the way that Windows handles objects in memory.
No doubt that until further information is released by Ruiu I cannot conclusively verify any of the information presented.
UPDATE: Mircea over at Trilema seems to believe that this is all bunk. At this point it is difficult to conclusive say but as they say extraordinary claims require extraordinary evidence.
Hackaday has an article on Cracking GSM with a DVB-T tuner using its SDR. Given my posts on “#badBIOS” having the alleged ability to use your sound card (they said audio but I am thinking tuner card would be more suitable) as a software defined radio in order to jump an airgap in the scenario where one computer gets the evil USB stick inserted into it but is airgapped and the other computer has full network access, is nearby and has also had the evil USB stick work its magic on it. The rtlsdr driver works with those ubiquitous (and often embedded into media PCs) DVB-T tuner cards that use a RTL2832U chip. They often interface over USB and generally sell for <$30 USD. I would think that cracking GSM isn’t as fun as it once was – with only the legacy devices still using it and even services discontinuing in many areas to free up some more spectrum for LTE. This is often unfortunate news for travellers who find that pentaband GSM phones were great to travel with as they invariably worked in every non-CDMA country.
Security researcher Dragos Ruiu has revealed that he has encountered malware which purportedly can infect PCs running different operating systems. One of his statements says that it infected a BSD system without even mounting the infected media. If this is true and the malware is somehow bypassing the OS and using the hardware itself (e.g. directly infecting the BIOS, by mechanisms as yet undetermined) then we will quite possibly have an incredible new emerging threat to all x86 users. Granted this could be a hoax but as the number of people in the community who report this is genuine grow so does my fear that this is genuine.
We have postulated for years that malware could directly target the underlying hardware or device firmware but there hasn’t been many examples of such malware seen in the wild. This is different to firmware that reflashes the BIOS to either render the computer unbootable (CIH/Chernobyl), create a persistent infection by using a module that replaces a file that is executed on boot with itself which in turn chainloads the real executable (ala Computrace’s computer theft solution that was on many Dell laptops) or creates a virtualized environment (the much talked about “Blue Pill”) with the malware acting as a hypervisor. All of these previous scenarios are not nearly as scary because the vectors they use are traditional. One needed to execute compromised code by, say clicking on an evil attachment or inserting a disk with an evil executable set to autorun.
Dragos writes on his Facebook page:
Infected systems seem to reprogram the flash controllers on USB sticks (and cd drives, more on that later) to attack the system (bios?). There are only like ten different kinds of flash controllers used in all the different brands of memory sticks and all of them are reprogrammable, so writing a generic attack is totally feasible. Coincidentally the only sites I’ve found with flash controller reset software, are .ru sites, and seem to 404 on infected systems.
I believe that what Dragos refers to now as #badBIOS is the same malware that he spoke of about two weeks ago labelling it as BIOS SDR. He spoke of the latter as being able to use the sound card as an SDR to breach an air gap. Sounds like crazy conspiracy theorist stuff I know but the guy has credibility (pwn2own was his creation).
A post on the excellent blog kabelmast summarizes what Dragos has revealed so far. Also of interest will be Dragos’ twitter page where he has posted a sample of some mysterious files which were modified on an infected system. I have not yet had a chance to look at these files so cannot comment on their contents or the veracity of these reports.
This has also hit reddit so no doubt people will be scratching their heads. Given that this is likely using the thumb drive’s flash controller to somehow gain access to the BIOS software samples aren’t very useful as we don’t get to see the actual dropper. Someone needs to analyze the firmware of the controller and it appears that Dragos is now speaking of auctioning infected devices so it is unlikely that this particular goat is going to get his hands on a physical sample of an evil flash drive any time so.
If confirmed I don’t think the vector is all that surprising. We have seen flash controller firmware uh, reflashed before – for example by eBay bad guys who purchase tiny sticks and write firmware that falsifies the size reported. I guess if one found a way to inject code into the BIOS somehow (buffer overrun?) then this would be the natural next step.