private key protection

[Robert J. Hansen]

On 10/19/2011 4:54 PM, Peter Lebbing wrote:
> Because in the latter case, I hardly think commonality matters.

As an example:

Three years ago I was thrown into a week-long sink-or-swim course on
malware analysis, taught by an instructor who was a principal scientist
at a company that's a big name in that field.  (Due to the subject
matter of this story, I am not allowed to give names: they don't want to
be publicly associated with this story.  You'd recognize the company
name if you heard it, though.)  The first thing we did was crack our
cases to verify that our machines had no network cards.  While we were
doing this, the instructor entertained us with a funny story about why
we were doing this.

A couple of years before that course, a new piece of malware was
reported to the company.  In turn it was sent to the malware analysis
lab, where the instructor was the guy tasked with looking at it.  He was
running a Windows VM within a Linux environment on a computer that was
physically disconnected from the internet and had the wifi card turned
off.   He fired up IDA Pro (a popular debugger) and began studying this
boring, broken piece of malware.  Within a couple of minutes the
sysadmins noticed something wrong and killed all network access in the
building.  All signs pointed to the instructor's machine being the
source of the problem.

The malware was the work of an evil genius.  As input to a PC, it was a
bunch of nonsense that crashed hard before it could do anything.  As
input to IDA Pro, it was a carefully crafted input that hijacked IDA
Pro.  It then discovered it was running inside a virtual machine, used
an exploit to get out into the Linux environment, brought up the wifi
connection and associated with the first network it could.  Wacky
hijinks ensued.

You can find some more on this subject in "The IDA Pro Book," by Chris
Eagle.  NIST also has a brief writeup on it:

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-0115