Re: Surveillance, secrecy, and ebay
Matt Blaze wrote: Once sensitive or personal data is captured, it stays around forever, and the longer it does, the more likely it is that it will end up somewhere unexpected. Great point, and a fundamental lesson-of-the-moment for the security industry. To take it one step further: The amount of sensitive information an organization stores is roughly proportional to the number of data leaks it initiates. We already know that information wants to be free, and if you keep information around, sooner or later, it's going to leak out. (There's probably some mathematical way to describe this relationship.) Rather than expecting companies to keep data totally secure and then send apologetic letters when it gets lost, perhaps we should start taxing companies in proportion to the amount of sensitive information they store, and use that tax to assist victims of identity theft. This would have the double benefit of giving companies immediate incentive to reduce the amount of information they store, and would also provide appropriate public funding for incident recovery. Sherri -- http://philosecurity.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: cleartext SSH, Truecrypt, etc passwords in memory
Peter Gutmann wrote: So was this a case of recover data from an active app's memory image (not surprising) or recover data after the app has exited (surprising, at least for the crypto apps)? For this paper, I specifically examined the case where memory was dumped while the applications were still active. The snapshots were taken up to 45 minutes after the passwords were entered. (See Appendix A for the full testing procedure.) Given that users keep applications such as SSH, Truecrypt, email, etc open for a significant percentage of time that they use their systems, I do think it's important for applications to zero sensitive data immediately after it is used rather than waiting until the process is closed. Also, as you point out, there were passwords such as SSH and root which were retained outside of the application's memory. I also did some preliminary experiments to test whether passwords remained in memory after the applications were closed. However, I decided to wait until the Princeton/EFF/Wind River folks released their memory dumper code before analyzing this in detail. As described in the paper, there are now annoying limitations on access to /dev/mem in Linux, so I thought it would be best to approach this particular question by getting a full memory image using cold boot techniques. As a next step, it would be great to follow the same procedure, but image all of memory after the applications have been closed. Using Jake Appelbaum and co's newly released memory imaging tools would probably be an easy way to get full memory dumps from any OS: http://citp.princeton.edu/memory/code/ Based on your feedback, I've updated section 2 and the abstract to clarify: http://philosecurity.org/pubs/davidoff-clearmem-linux.pdf Thanks for your comments, Sherri -- http://philosecurity.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
cleartext SSH, Truecrypt, etc passwords in memory
Hello all. During the past few months, I've been poking around Linux memory and consistently finding cleartext login, SSH, email, IM, Truecrypt and root passwords. I've just finished a paper which includes detailed location and context information for each password. Given the recent buzz about cold boot memory dumping, it seems the risk associated with cleartext passwords in memory has increased. You can find the paper here: http://philosecurity.org/research/cleartext-passwords-linux/ There are also a couple snippets of process memory up there for folks to play with. Thought this might be of interest to folks on this list. Sherri -- http://philosecurity.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
As soon as I heard about this research I had to try it out. My laptop (Thinkpad) has an encrypted Truecrypt partition. I quickly made a modified bootable DSL usb memory dumper, powered the machine down, waited a minute, dumped memory, and found that I could recover passwords from multiple prior reboots. I was able to recover my Truecrypt password even if the volume was not mapped at the time of reboot, as well as GPG passwords, SSH passwords, etc etc. It was really easy. During physical pentests, when I grab an encrypted laptop from an office, my clients usually respond that the laptop was encrypted and the data was therefore safe. That's not necessarily true, of course, but we don't have the time during these engagements to test out the security of the encryption products/implementation, and neither do most attackers. Now attackers (or customs) just have to grab a live laptop, plug in a USB memory dumper and power cycle the system in order to obtain a dictionary of likely passwords and potentially recover encryption keys. Presumably tools to to accomplish this will soon be found in the wild and will become accessible to attackers with even low levels of technical skill. I imagine this will eventually have a big impact on the way organizations respond to stolen mobile device incidents. With the current technology, if a laptop or mobile device is on when it's stolen, companies will need to assume that the data is gone, regardless of whether or not encryption products have been deployed. Anyone familar with the laws in the arena? Are there regulations which require reporting only if data on a stolen device is not encrypted? Sherri Ali, Saqib wrote: interesting paper. but i fail to see how this could be deadly (as the author puts it) to the disk encryption products. This methods requires the computer to be recently turned-on and unlocked. So the only way it would work is that the victim unlocks the disks i.e. enter their preboot password and turn off the computer and immediately handover (conveniently) the computer to the attacker so that the attacker remove the DRAM chip and store in nitrogen. And the attacker has to do all this in less then 2 seconds :) If the attacker is standing right next to the victim, why even let the victim turn-off the unlocked computer Or am I missing something? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Death of antivirus software imminent
Anne Lynn Wheeler wrote: Virtualization still hot, death of antivirus software imminent, VC says http://www.networkworld.com/news/2007/121707-crystal-ball-virtualization.html Interesting how virtualization seems to imply safe in the public mind (and explicitly in that article) right now I'm sure with the increasing use of virtualization, we'll start to see more VMware-aware malware and virtual machine escapes in the wild. Another example of putting many, many eggs in the same basket. Here's a good article about the first public VMware escape, which Intelguardians demonstrated at SANSFIRE this summer: (Note: I'm biased, having worked on this project.) http://www.pauldotcom.com/2007/07/ What boggles my mind is that despite this, the DoD has still decided to rely on virtualization software to keep classified and unclassified info on the same physical systems: http://www.internetnews.com/storage/article.php/3696996 Sherri Anne Lynn Wheeler wrote: re: Storm, Nugache lead dangerous new botnet barrage http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1286808,00.html from above: The creators of these Trojans and bots not only have very strong software development and testing skills, but also clearly know how security vendors operate and how to outmaneuver defenses such as antivirus software, IDS and firewalls, experts say. They know that they simply need to alter their code and the messages carrying it in small ways in order to evade signature-based defenses. Dittrich and other researchers say that when they analyze the code these malware authors are putting out, what emerges is a picture of a group of skilled, professional software developers learning from their mistakes, improving their code on a weekly basis and making a lot of money in the process. ... snip ... ... and somewhat related Virtualization still hot, death of antivirus software imminent, VC says http://www.networkworld.com/news/2007/121707-crystal-ball-virtualization.html from above: Another trend Maeder predicts for 2008 is, at long last, the death of antivirus software and other security products that allow employees to install and download any programs they'd like onto their PCs, and then attempt to weed out the malicious code. Instead, products that protect endpoints by only allowing IT-approved code to be installed will become the norm. ... snip ... and post about dealing with compromised machines http://www.garlic.com/~lynn/2007u.html#771 folklore indeed mentioning sophistication in other ways: Botnet-controlled Trojan robbing online bank customers http://www.networkworld.com/news/2007/121307-zbot-trojan-robbing-banks.htm from above: If the attacker succeeds in getting the Trojan malware onto the victim's computer, he can piggyback on a session of online banking without even having to use the victim's name and password. The infected computer communicates back to the Trojan's command-and-controller exactly which bank the victim has an account with. It then automatically feeds code that tells the Trojan how to mimic actual online transactions with a particular bank to do wire transfers or bill payments ... snip ... there have been some number of online banking countermeasures for specific kinds of system compromises like keyloggers ... but they apparently didn't bother to get promises from the crooks to only limit the kinds of attacks to those exploits. some related comments on such compromised machines http://www.garlic.com/~lynn/aadsm27.htm#66 2007: year in review http://www.garlic.com/~lynn/aadsm28.htm#0 2007: year in review - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: solving the wrong problem
Reminds me of the White Knight from Alice in Wonderland, who doesn't understand his threat model, and doesn't know how to effectively use his tools: `I see you're admiring my little box,' the Knight said in a friendly tone. `It's my own invention -- to keep clothes and sandwiches in. You see I carry it upside-down, so that the rain ca'n't get in.' `But the things can get out,' Alice gently remarked. `Do you know the lid's open? `I didn't know it,' the Knight said, a shade of vexation passing over his face. `Then all the things must have fallen out! And the box is no use without them.'' ... `You see,' he went on after a pause, `it's as well to be provided for every-thing. That's the reason the horse has all those anklets round his feet.' `But what are they for?' Alice asked in a tone of great curiosity. `To guard against the bites of sharks,' the Knight replied. `It's an invention of my own.' Full text from the chapter: http://www.sabian.org/Alice/lgchap08.htm alien Perry E. Metzger writes: We already have the term snake oil for a very different type of bad security idea, and the term has proven valuable for quashing such things. We need a term for this sort of thing -- the steel tamper resistant lock added to the tissue paper door on the wrong vault entirely, at great expense, by a brilliant mind that does not understand the underlying threat model at all. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
