Bootkit Bypasses TrueCrypt Encryption 192
mattOzan writes with this excerpt from H-online: "At Black Hat USA 2009, Austrian IT security specialist Peter Kleissner presented a bootkit called Stoned which is capable of bypassing the TrueCrypt partition and system encryption. The bootkit uses a 'double forward' to redirect I/O interrupt 13h, which allows it to insert itself between the Windows calls and TrueCrypt."
Uh, what? (Score:5, Interesting)
So yeah, if someone is running live software on your machine then there isn't much you can do. If there is decrypted data then it's essentially available to anything on the machine.
I mean if you're going to do this you could just modify the TrueCrypt code (bootloader in this case) itself to do what you want.
Kind of "duh" story if you ask me.
Re: (Score:3, Interesting)
Re: (Score:2)
I think you misunderstand... the entire volume is presumed to be encrypted by TrueCrypt, so the assumption is that the data on the machine is safe, even if the entire machine is stolen (such as the case with a laptop)
The thinking is that yes, you could boot to a LiveCD on the stolen laptop and try to e.g. mount the NTFS volume on the machine, but with the entire volume encrypted you wouldn't be able to get any meaningful data off the machine
This isn't a "duh" story, because if you're able to steal a laptop
Re: (Score:2)
I think you need to read the article again. This doesn't bypass TrueCrypt's security. If you steal the computer you can't use this technique to get at the encrypted data. This attack needs the person to enter their password to decrypt the volume.
I think the only presumption is that for some reason people think someone can't install anything on their computer just because the entire drive is encrypted. That logic is flawed because there is still plenty of unencrypted code that must be run to bootstrap th
Much as we hate TPM here on /. (Score:5, Interesting)
TFA has a very good point -- unless you (cryptographically) trust the components of your system all the way down to the hardware itself, you can get pwned by an attack like this. You can regularly do all-the-way-to-the-firmware scrubs of your machine as damage-control, but the only real prophylactic is some form of trusted computing.
Of course, I'm not really dying to jump on the TPM bandwagon, given the sponsors, but it sure would be nice if there was an openly-audited trusted computing module.
Re: (Score:3, Insightful)
Re:Much as we hate TPM here on /. (Score:5, Informative)
http://lwn.net/Articles/144681/ [lwn.net]
Linux has had kernel level support for TPM for a while but most F/OSS developers have an intrinsic aversion to the concept (as I said in the GP, the identity of the TPM principals doesn't exactly give me a lot of confidence) so it's not widely used as far as I can tell.
A wonderful response from the F/OSS community would be to build a version of TrueCrypt that uses TPM to authenticate the BIOS and MBR against the known good versions.
Re: (Score:2)
TPM is only good if you trust it to be secure. I think the issue a lot of F/OSS people have is that you are taking Intel's word for the security of the TPM.
Re: (Score:3, Informative)
I have seen implementations that use the TPM chip offer additional functionality so the chip can be part of the boot process. PGP allows one to use both the TPM chip and a passphrase for booting, so if the TPM chip does get compromised, it will not do an attacker much good.
BitLocker allows one to use a USB flash drive as well as a TPM, XORing the keyfile and the TPM's sealed key to obtain the final volume decryption information. This way, an attacker would have to not just be able to physically attack the
Re: (Score:2)
Which doesn't necessarily mean that you need the highest bit rate for every task, if you're just wanting to secure a connection for a OTP the amount of encryption is pretty minimal, if you're needing to use the same cert for many connections then you'd want and
Re:Much as we hate TPM here on /. (Score:5, Interesting)
The tools are there (tboot, TrouSers). What is missing is a gestalt "stack", where an admin can configure a distro to "seal" the hash of various parts of the boot process in the TPM (MBR, boot sector, BIOS, kernel, RAMdisk image), then encrypt the rest of the machine. Then, at boot, it would boot to the ramdisk filesystem, ask the TPM for the key, and if the image has not been tampered with, the TPM will hand the key over, and the boot process continues.
One thing that isn't discussed (which is important) is a facility for recovering the encrypted data should the TPM be off or erased. BitLocker handles this fairly gracefully by saving a keyfile to a USB flash drive, or allowing the user to print out a sequence of numbers with the recovery key. BitLocker also allows saving of the recovery key to Active Directory, ensuring that corporate IT has recovery access (which is required by law in a number of cases). Finally, for home users, BitLocker allows use of offsite storage for the recovery information.
Another option to implement a means of recovery is to have a recovery passphrase. PGP is a product that allows this, where one can boot from a TPM, but if that is unavailable, one can type in a previously set passphrase, or a WDRT (whole disk recovery token, which is a challenge/response system).
This functionality will have to be implemented distribution by distribution, as there isn't a standardized set of tools. Perhaps one thing that should be designed would be a standard for implementation across distros.
Re:Much as we hate TPM here on /. (Score:5, Insightful)
Unless the bios writes a kernel module that hooks into reads from /dev/sda and gives out false information for the first 512 (or whatever) bytes.
You cannot possibly defeat malware that is running on the same level of privilege as your detection code.
Re: (Score:2)
I'm not entirely sure why the malware can't just forward the boot sector. The hack intercepts the interrupt 13h then forwards it but it doesn't say that it limits it's function. Your script would probably return the same boot sector information whether whether using the bios it kernel level access.
Re: (Score:2)
Re:Much as we hate TPM here on /. (Score:5, Insightful)
Because if you have a compromised BIOS, it could "read back" whatever you wanted to hear. Asking a hacked BIOS to read itself back to you is like asking a liar whether he is a liar -- it gets you no reliable information.
Surely you jest.
As to updating the BIOS in a TPM system, I imagine that the procedure would be like this: ...
(3) On next boos, TPM raises an alert saying "BIOS has been replaced -- new bios hash XXXXXXX"
If you think this scheme works, but the one above doesn't, I have a bridge to sell you. Where do you think this data to hash is going to come from? From the BIOS, which you claim is an unreliable source. Indeed, if you rig up a BIOS to return the same signature as your current one, and you can run step 2 with no step 3 or 4.
Re: (Score:2)
Umm, no. Software that hashes the BIOS for comparison purposes will be reading the flash itself, not relying on the BIOS at all.
Re: (Score:2)
I saw a lengthy video that really went into the depth of it. And the main point was/is, that TPM in itself is a great security concept. It's just that the problem is, that it's controlled by them. And they decided, not to trust you. (As that short video we all know also explains.)
Luckily, they left a hole in it as big as an asteroid belt: You can change who controls it, and so take back your computer. From then on, you change it so that you are trusted and everything else is not, lock the hole down, and you
Re: (Score:2)
TPM will not help you in this case. At all.
If you can modify the MBR (which this guy has to), you either already have admin rights or physical access to the machine.
If you have admin rights, you can reset the TPM or do just about anything (save snapshots of RAM, where the decrypted plaintext, and master key are). If you have physical access you can do just about anything top (install a key logger, take snapshots of RAM, replace the Bitlocker bootloader with a fake one that will accept your password and fals
Re: (Score:3, Informative)
Replacing software security with hardware security only moves the attacks from software to hardware.
It's much harder to compromise a cryptographic key that is burned into a piece of silicon (think millions for a scanning electron microscopy setup and many hours) than it is to attack software.
See Nintendo's Wii, Microsoft's XBoxen (both of them), BluRay/HD-DVD and we could go on ad nauseum.
Different security situation in those, since you need the person to be able to decrypt the content in order to play the game. By contrast, a TPM-based setup needs only to confirm that the BIOS and MBR match a specific hash and then pass along control to the (now verified) boot loader or, failing that, draw a red scree
Re: (Score:2)
Oops: http://www.computerandvideogames.com/article.php?id=165699 [computeran...ogames.com]
Re: (Score:2)
Re: (Score:2)
The TPM does make things more difficult for an attacker in a way that no software is able to. Software can do a lot, but sometimes you do need hardware. For example, hardware is required for a translation layer from a physical drive to the SATA connection so an OS doesn't have to worry that a new hard disk has perpendicular recording on the sectors as opposed to MR recording.
The big advantage of having hardware is that it forces an attacker to look elsewhere for a way in, to hardware that is machine depen
man in the middle (Score:5, Informative)
it's more of a "man in the middle" sort of thing and it by itself does not "break" the encryption.
Think of it as a keylogger for your hard drive.
No matter how complex and secure an encryption method is, if you can steal the password (or key), yea...you get the idea.
In that sense, the title, summary, and the title of the article in question is misleading as it doesn't really bypass any encryption but rather daisy-chains itself into the process (so once you enter a password/key, it can capture it).
Re: (Score:2)
Exactly...
This 'attack' can only work if the person compromised the machine, waited for you to log in and then stole it or compromised it again.
For all intents and purposes your typical street level thug swiping a laptop laying around it keeps them from accessing your shit.
Not a new thing or idea (Score:5, Insightful)
I can't tell what's supposed to be interesting or spectacular about this. It's a standard rootkit with MBR support along with some special hooks for truecrypt. It won't let anybody read an encrypted truecrypt volume unless you enter the password... And if you do enter the password on an owned computer it's not like trucrypt is going to help you anywhere. If you unlock the volume any malware can grab all the data it wants through the usual calls and hooks. It doesn't seem especially advanced compared to many of the rootkits out there.
Re: (Score:3, Insightful)
Agreed; I'm more worried about tiny pinhole cameras watching my keystrokes, that RF keylogging, or a rubber hose. My crypto has always been to deter the average thief who boots once to look for personal info before selling it online and to prevent other students from pranking me. Against a resourceful attacker you're pretty much screwed anyway.
My best defense is that the kind of people who /could/ break into my computer have better things to do.
Ok I don't get it (Score:5, Insightful)
How does this, in any way shape or form, "break" Truecrypt? Now maybe I misunderstand how it works, since the information is not presented in a clear manner and the author is letting ego get in the way of good writing, but more or less it looks like he has a way to get in to the system at a low level. Ok, great, that does NOTHING to break the encryption. I see nothing in here about managing to get data out of a Truecrypt drive/volume without knowing the key. So what's the big deal?
I mean yes, you could use said malware to log the password. Well guess what? If you've physical access to the system, you don't need software for that. A hardware keylogger would achieve the same thing, or maybe a camera over the shoulder or maybe a tempest attack. The point is if you have physical access to the system, there is little someone can do to keep you from bugging said system.
What Truecrypt is intended to deal with is someone nabbing your system and getting data, and I see no break in that regard. If you encrypt your laptop's harddrive to ensure that nobody gets your data, and somebody steals you laptop, this doesn't help them. For it to help them they'd have to get your laptop, bug it, get it back to you such that you didn't notice, wait for you to use it, then steal it again so they could get the password.
I just fail to see how this is news here. If there is something I'm missing, by all means I'd be interested in knowing.
Re:Ok I don't get it (Score:5, Insightful)
How does this, in any way shape or form, "break" Truecrypt?
It breaks the unspoken (and totally unwarranted & incorrect) assumption that TrueCrypt not only encrypts but also authenticates.
This is not "breaking" TrueCrypt since they never claimed to authenticate the MBR/BIOS against this sort of attack. That's what's somewhat clever about it -- it doesn't attempt to smash the door open but rather attacks in a fashion that this particular security software was not designed to handle.
Re: (Score:3, Informative)
TrueCrypt not only encrypts but also authenticates.
As far as I know, TrueCrypt has never made any claims about authentication. They promise quality encryption, nothing more and nothing less. Everyone who knows anything about security knows that encryption and authentication are separate issues; although they may be combined in a particular system as they are in certificates and public-key cryptography.
One interesting thing to note are the recent higher quality attacks on 10 round AES, as discussed here [slashdot.org] on /. TrueCrypt defaults to 256 bit AES for the default
Re: (Score:3, Informative)
No, for two reasons.
1. truecrypt doesn't use related keys for encrypting different things, so there's no known plaintexts with which to perform that attack.
2. 10 round 256 bit AES is less secure than 128 bit AES in cases for which that attack applies. But AES-256 is defined to use 14 rounds so that attack only works against bizarre implementations that decided to be incompatible with the rest of the world and to ignore the security advice of the AES designers. There are approximately 0 such uses of AES.
Re: (Score:2)
it doesn't attempt to smash the door open but rather attacks in a fashion that this particular security software was not designed to handle.
No security software can "handle" attacks when the attacker has admin privileges or physical access to the machine (i.e. root access), which is the case here.
In case you thought TPM would help, then, no it wouldn't [slashdot.org].
This is nothing more than stupid nonsense created by a random teenager, who obviously knows nothing about security.
Re: (Score:2)
What if someone (say, a government agency) does not steal your laptop, but instead, infects it with this compromised BIOS, then just puts it back?
Then just let you run it awhile oblivious, *THEN* later on seize it? You think you're protected, but surprise, you aren't.
It is a lot easier to detect a hardware keylogger or secret camera, than an infected BIOS, unless you are super paranoid.
Re: (Score:2)
Theoretically.
Re: (Score:3, Informative)
Theoretically, in that case, you'd be protected by entrapment laws, the fifth amendment, and due process.
Uhhh....No. This is no different from a wiretap (assuming a judge authorized it, of course). It has nothing to do with entrapment or the fifth amendment, any more than an FBI bug on a phone line does. As for due process, see the part about a judge issuing a warrant. The fact that you thought it was perfectly safe don't enter into it.
Re: (Score:2)
My point was actually your point: they would have to have a warrant first, otherwise the only two ways to implant the bug would be getting you to do it for them (entrapment) or doing it themselves (due process).
Re: (Score:2)
Please point where the "get a warrant later" part is in that post.
Since all I can see in it is that instead of taking the laptop they put this bios on it and take it later. Nothing about putting the bios on it being done under different circumstances than the original taking (which once upon a time would have needed a warrant then and there).
Re: (Score:2)
Uhhhh (Score:2)
That seems extremely far fetched for one, but then even if you believe it is the case, what good would it do to fix? When you talk about a government agency, you are talking about someone with essentially unlimited resources. So they have plenty of options. Like I said, there's tempest. They monitor your computer remotely. I've no idea how well it works enough in reality, but it works well enough in theory that intelligence agencies shield against it. Or maybe they simple rewrite the Truecrypt bootloader, a
Re: (Score:2)
As usual secrets are best kept in brain case (Score:2)
As usual secrets are best kept in brain case as anyone who physically gets a hold of your truecrypt volume and machine can now insert the bootkit at their leisure and to their pleasure.
So we're back to physical control of memory to keep secrets.
Re: (Score:3, Insightful)
Tell that to the doctor in the emergency room when he needs to look up your patient records to decide if it's safe to administer a drug to you.
Re: (Score:2)
Ok, so how would having all your medical records encrypted on a key dongle memory stick help you there? The doc would be waking you up saying what's your password dude your life depends on it... the only problem is that you're incoherent from all the partying you did the night before and blerble out nonsense that didn't work anyhow. I guess your lucky since your doctor happens to read slashdot and saw the above article about breaking truecrypt volumes and he compiled the hackers bootkit and installed it and
Re: (Score:2)
Why don't you read the comment that I was responding to:
"As usual secrets are best kept in brain case"
I was asserting the falsehood of that statement., not shilling for USB key dongles.
Re: (Score:2)
That's funny, I wrote the comment you were responding to!
Your case for the falsehood of the statement was rejected since it was based upon bad logic.
Re: (Score:2)
I just come back to what my mother told me once. "If you don't want someone else to read it never write it down"
So (Score:2)
If you give your PC to someone, with the capability to modify the innermost workings of the boot sectors, and then log into the PC indiscriminately without verifying that the boot sectors, etc. haven't been modified, it's possible that the password you typed on the keyboard etc. could be captured and then used later (assuming the rogue software would also have the capability send that password to the attacker and/or for the attacker to AGAIN gain physical access to the PC after you've typed in the password
Oblig (Score:5, Funny)
Funny, but true (Score:3, Interesting)
Things like encryption are to protect against normal problem, like losing a device with important data, not to protect against a determined adversary that wants your particular stuff.
For example I have an encrypted USB stick who's function is to hold my passwords, in particular the ones I don't use a lot. It is a USB stick, since I don't want to keep something like that on my computer which is always networked. While I think I have good security, there's always a chance someone owns my computer and I don't
Re: (Score:2)
A better and easier method for storing stuff like that is to use GPG/PGP.
Create a text file for the site / server name. Copy your authentication information (be verbose...) into the clipboard and encrypt with PGP/GPG. Paste the encrypted ASCII text block into the text file.
The big advantage here is that text files are dirt simple to backup (you could even email them) and your m
Re:Oblig - $5 wrench to the shins (Score:2, Informative)
Not a break of the encryption or even TC in genera (Score:5, Insightful)
This really does not defeat TrueCrypt. All it does is read the date after its decrypted and before it gets to the OS. It also can only read the data after the real key has been presented. I think the take away here is disk encryption is not a silver bullet. You can't sit there and say "My disk is encrypted my data is safe." Its not safe while the machine is on an in the unlocked state. Any other malware running on the system can send or leak data all over the place. You have to trust the entire stack or have defenses in place at every layer.
All disk encryption can accomplish is:
1. If someone steals the system while off or locked and does not already have the key they can't get the data
2. The system cannon be modified offline with out the key
It can't really do anything more than that. TC is not broken its just not a defense against other software that can get ahold of the disk layer.
Suppose I walk into a bank during hours after the manager has opened the vault. I point a gun at him, hand him a bag and tell him to start loading it up. I then leave with the money. The vault is not broken. Its just that it only protects the money while its closed. If I showed up in the middle of the night broken and got the goods then the vault would be broken; but a day light robbery is just exploiting another weakness in the system.
Boot from CD with a "secure" BIOS (Score:3, Insightful)
Password protect the BIOS, disable post-boot BIOS flashing, and only boot from a CD that you carry with you at all times. That's a pretty effective way to get rid of software only attacks. Once the hardware is involved (which includes vulnerabilities that allow flashing the BIOS after it's booted or without a password), you're screwed.
Confirm this for me... (Score:2, Insightful)
So let me get this straight...if a program lodges itself into the bios and intercepts disk calls above an encryption layer and can intercept the data, that is in and of itself newsworthy?
Ok, I though it was like "The government can wiretap your phone by standing in your kitchen while you're talking."
Please....this is unworthy of any attention. Everyone knows that a compromised system is not secure. Was this ever in question? Take your 15 minutes of fame, and go....
Your computer is stoned... historical reference (Score:3, Informative)
One of the first MBR-infecting virused was "Stoned".
Wikipedia entry. [wikipedia.org]
Re: (Score:2)
Just following Taco's lead.
Ya know... (Score:2, Informative)
Full-disk encryption is designed to stop a thief who steals a computer from getting more than the hardware, and it's designed to keep a misplaced laptop with important data from becoming a headline. It's not designed to be the first and
Timing attacks? (Score:2)
I'm somewhat surprised that there are no published timing attacks against TrueCrypt's AES implementation. Attacks against 128-bit AES are certainly easier, but there's a public attack that breaks Linux's dm-crypt in 65ms of testing and 3s of computation, and 256-bit AES shouldn't be immune.
Those attacks shouldn't require admin privileges.
Backdoor if you forget your TrueCrypt password? (Score:2)
Re:Do I need to prepare? (Score:4, Informative)
And, is it true we are screwed?
You were always screwed if you don't have your machine physically secured. There's really nothing new here other than an interesting implementation of a concept that's been around for awhile. If you care about the privacy of your information then your PC had better be secured at least as well as you would secure your other valuables. If someone can gain physical access to your machine then it's effectively game over.
Re:Do I need to prepare? (Score:5, Informative)
If you care about the privacy of your information then your PC had better be secured at least as well as you would secure your other valuables. If someone can gain physical access to your machine then it's effectively game over.
But that's the entire point of System Encryption right there! Someone gains physical access to your machine and they still can't do squat to read the contents (short of beating you with a hose to get the password or spending serious supercomputer time). System Encryption was designed for precisely this application.
This nice little trick here gives them a third option -- install malware at the BIOS level while leaving TrueCrypt unchanged so as to give you the illusion of safety while they read your mail/keystrokes/whatever. If I were the Border Patrol, I would consider a tool that automates the installation of this tool to be a very worthy investment.
In short, he's exploiting the fact that encryption and authentication are two very different things. TrueCrypt can assure you that you data are unreadable without the key but cannot authenticate the MBR as being genuine. For that, you need some form of trusted computing, the mention of which never goes well.
Re:Do I need to prepare? (Score:5, Insightful)
Giving someone physical access to your machine is the equivalent of losing it and recovering it later, and encryption was never about this case!
Encryption is meant to prevent data release with such a loss, but does nothing much to guarantee integrity of the system after recovery. It does not provide a tamper-evident nor tamper-proof system, since tampering can occur outside the encrypted content. Also, encryption itself does not even provide tamper-proofing for the encrypted volume! It just makes it infeasible to inject known plaintext into the real filesystem, but someone can simply corrupt the ciphertext image and therefore corrupt the real filesystem. You would need additional checksums or other integrity-checks to actually detect such damage.
Re: (Score:3, Insightful)
It just makes it infeasible to inject known plaintext into the real filesystem, but someone can simply corrupt the ciphertext image and therefore corrupt the real filesystem.
If you were able to do several lunch-time attacks over time, you might also be able to do 'traffic analysis' to figure out which files were system files, correlate that with a security update, then replace the updated software with an older, vulnerable version by re-writing old ciphertext. This would be particularly easy if, for example, /home is mounted on a different encrypted volume than /usr.
Re:Do I need to prepare? (Score:5, Interesting)
This exploit really is more comparable to a software keylogger. It lies between OS and Truecrypt Bootloader, catching the disk access requests.
For infection, you need admin rights on the running machine (TFA says so).
So, with the full system encryption, you are of course safe. This is just a way of listening to Truecrypt requests.
Kudos to Peter, hope to meet him in the Metalab sometime.
Re: (Score:2)
It's not even as good as a keylogger really, as it does not capture the encryption key or password. It could be modified to, but at the moment it just reads unencrypted data (and has no way of storing it en-masse either).
This sort of attack has been known for quite a while. A similar one involves rebooting a booted system and loading a Linux distro to capture the encryption key from memory (since memory is not normally wiped during a reboot). Really, there is very little you can do against that kind of atta
Re:Do I need to prepare? (Score:5, Informative)
i'm yet to see a decent defense against keyloggers like this thats acceptable to home users.
Re: (Score:2)
hd encryption was designed to stop people stealing your hd
Yes, when my encrypted volume detects bad people it shouts "Go away, this volume is encrypted, shooo!"
Re: (Score:2, Informative)
i'm yet to see a decent defense against keyloggers like this thats acceptable to home users.
Decent defense against keyloggers etc.: Do not let anyone compromise your machine. It boils down to this; even with "authenticated" hardware there's always a step that is not authenticated. As long as you don't let anyone tamper with your machine, you're safe.
And if you do think your hardware has been compromised, there are ways to attempt an offline recovery of data so that the attacker never knows you have decrypted your system and gotten the data out. Physically destroy the machine afterwards, to be s
Re: (Score:3, Insightful)
Yes, it's a typical MITM attack [wikipedia.org].
As Trucrypt presents it's drives as block devices to the OS, this BIOS-level Trojan is equivalent to a typical OS-level Trojan.
Re: (Score:2)
Re: (Score:3, Interesting)
Re: (Score:3, Interesting)
If someone can gain physical access to your machine then it's effectively game over.
If that was the case, what would be the point of disk/partition encryption in the first place?
Re: (Score:3, Insightful)
The perp won't be able to read the data, unless he installs this rootkit, returns your PC and then steals it again to read the keylogger info.
Easy solution: Wipe the system and restore it from a backup if you suspect your machine has been physically compromised.
Re:Do I need to prepare? (Score:5, Informative)
Easy solution: Wipe the system and restore it from a backup if you suspect your machine has been physically compromised.
Sorry. Wiping the system will do nothing if the malware is installed in the BIOS. And it will do nothing to protect you from hardware keyloggers. Also, recall the story earlier today about tampering with the flash memory in keyboards.
Re: (Score:2)
The BIOS and the keyboard are part of the system. You just have to be thorough. ;)
You should be able to spot external hardware keyloggers easily.
Re: (Score:2)
Re: (Score:2)
So just re-flash your BIOS. If you are really paranoid, you could even just switch to a new PC. You can recover your data from another OS.
Re: (Score:2)
Assuming you can get to the network stack from the malicious bios, then the "steals it again" might be as simple as, waits for a network connection, to start transferring.
The only novel thing I see, is having a malicious true crypt stack means that it could then send the credentials out, then even after you remove all the malware and change your volume password unless you create a new truecrypt volume, some data will be vulnerable to the hacker long into the future.
It does make me wonder if a combination ke
Re: (Score:2)
Disk encryption is handy, for traveling with a USB device, protecting a laptop from a corporate "partner" when you connect to a network to do a presentation, or avoiding having the Chinese or US federal agencies illegally scan your laptop data without a warrant.
Re: (Score:2)
The perp won't be able to read the data, unless he installs this rootkit, returns your PC and then steals it again to read the keylogger info. Easy solution: Wipe the system and restore it from a backup if you suspect your machine has been physically compromised.
Even easier solution: I ensure my system contains nothing but totally useless crap. That'll learn 'em!
Re:Do I need to prepare? (Score:5, Interesting)
If you lose a laptop and then recover it, you can be fairly certain that your data was never leaked but you cannot be certain that someone didn't tamper with your system so they could steal the data later. At that point the best you could do would be mount the volume on a completely different system and move any data you hadn't already backed up, then wipe the drive/bios fully..though after yesterday's article about the BIOS "rootkit" that is Computrace, I'd be wary of the hardware at that point.
Re: (Score:2)
though after yesterday's article about the BIOS "rootkit" that is Computrace, I'd be wary of the hardware at that point.
So what your saying is be wary of the hardware when your kit is stolen AND be wary of the hardware before your kit's been stolen. Great! I was gonna wait until my hardware was morphing into robocop before being scared of it now I'll have to rethink . . .
Re:Do I need to prepare? (Score:5, Interesting)
You're absolutely right. Strangely, none of those links led to Peter Kleissner's web page [peterkleissner.com].
Check out the comments. Some of the visitors are flaming him pretty hard, but he's just a kid with amazing skills and (understandably) very little historical knowledge. Luckily, Christian [peterkleissner.com] politely points out that his attack serves to "... alert many people who think they made their PC secure by installing TrueCrypt and still keep working with an admin account where they should not. You prove that a security policy is indispensable, because admin privileges will give malicious software the ability to tamper with the installed security software."
Re: (Score:2)
and still keep working with an admin account
I'm in the process of virtualizing our servers and will be using encryption to further secure the data. You make a good point because the most unpleasant part of the process is gonna be telling the other admin he can't work with root anymore. Here's me diligently creating a new user with only the necessary rights, both on the System and within services (Mysql, etc.), and there's him tip-toeing around the file system like an elephant in a rage. He dropped one of our live databases by accident the other day w
Re: (Score:2)
Re: (Score:2)
That's something you were as soon as you started to earn money.
There is always someone out to get your money one way or another.
Re: (Score:3, Funny)
...
* look inside your computer once in a while
For WHAT?!?!? Gnomes transcribing your keystrokes?
Re: (Score:2)
1)Transcribe keystrokes
2)?????
3)Profit
Re: (Score:2)
One thing you can do with TrueCrypt, if a person fears compromise of a MBR:
Boot from the CD image that TrueCrypt forces one to make (unless they RTFM and explicitly run the TrueCrypt Format utility, telling it not to make the image.)
This way, a corrupted or tampered with MBR is completely bypassed, and the user has the option to overwrite it with the MBR image from the boot CD.
Another idea: (Score:2)
Re: (Score:2)
Re: (Score:3, Interesting)
Is this type of attack only limited to trucrypt or can it affect other product?
From what I understand it could potentially affect other products unless they (properly) use TPM to avoid this kind of attack by checking MBR against a checksum.
is there a way to prevent it?
Get a mac! Not trolling, from TFA: "The attack is unsuccessful when the BIOS successor the Extensible Firmware Interface (EFI) is at work on the motherboard." AFAIK Apple are the only vendor using EFI on their entire range at the moment. I guess mounting everything read-only, or using a BSD with the file immutable bit [cyberciti.biz] set on all system files would w
Re:Just when I though I was safe.... (Score:5, Interesting)
I'm not so sure a mac is the answer. With a mac, you can just install the code in the keyboard [slashdot.org] and grab the keys directly.
Re: (Score:2)
And what does the keyboard do with the data? It still needs a compromised system to relay it anywhere useful. Or you need to have repeated physical access to the keyboard.
Re: (Score:2)
Well, yea, it's the same witht he bios hack. You gain access to the system, install your malware, leave then come back and either take the system with unfettered access to the data on it or simply use it in place and hope no one detects it.
Re: (Score:2)
Re: (Score:2)
Although now that I think of it... how does setting +i on everything help?
Re: (Score:2)
Hmm, looks like another case where Linux has copied a feature and yet missed the point. On a BSD system (this feature comes from 4.4BSD, so it is a BSD feature, just one that a few SysV variants have implemented) this is tied to the concept of securelevels. The system boots in securelevel -1, and typically enters securelevel 0 at the end of the boot process. At this point, you can read and write any devices, subject to their permissions, and can use chflags to set and clear immutable attributes.
A root u
Re:LFP is doomed (Score:5, Funny)
This sure is a big hit on the Linux for Pedophiles distro.
What part of "insert itself between the Windows calls and TrueCrypt" did you miss?
Maybe that's what he calls Windows?
It's a reference to the Stoned virus of DOS days (Score:2)
The name just seems to show that Mr. Kleissner has a sense of history. One of the old MBR viruses that used to plague systems in the days of MS-DOS was known as the Stoned MBR [wikipedia.org] and from reading the article it seems that Mr. Kleissner's technique operates much the way that virus once did, by gaining . The marijuana references come from the original virus, which contained the phrase 'Your PC is now stoned! Legalise marijuana!'
This doesn't even sound like it 'bypasses' TC? (Score:2)
The article headline says this bootkit 'bypasses' TC encryption, but it doesn't appear to do that at all, as far as I can tell? Am I mis-reading the article, or is this simply describing software that runs *along side* of truecrypt, and after the user loads truecrypt and provides the password to decrypt the hard drive to truecrypt, this software simply uses truecrypt to access the hard drive like *ANY OTHER PROGRAM*? It's like saying Microsoft Word "bypasses truecrypt encryption" because Word is able to acc