A Renaissance Security Professional

Lessons from a DFIR job search

2012-02-24T11:36:00.001-08:00

Those of you who follow my blog know that I’ve long been trying to transition into computer security for a few years now. After the US Cyber Challenge I got a QA job at an antivirus company that gave me exposure to application security issues and malware basics, but I’d really been trying for a digital forensics or incident response (DFIR) job. As of last October, I finally got a job doing infosec – including incident response - at Bay Area-based social network (not Facebook).

While I was trying to transition over, I talked to a lot of experienced DFIR people about how they got into this. Ultimately, the path that worked for me ended up being a bit different than their suggestions, so perhaps these notes about what worked and what didn’t will help other people looking for forensic work.

Transition from Operations

Several people I’d talked to started in an operations type of role and then transitioned over, supplementing their sysadmin skills with additional study to make the jump to DFIR. This path is a logical one because sysadmins know how their servers work, their configuration, how to keep them running and reliable, and networking. They will have been exposed to security issues in OS hardening, firewall configuration, and patch management. Most likely they will have responded to incidents as well, at least a DDoS if not a server breach. Ultimately, I think this is the easiest path and the one that most forensics people will continue to come from.

Law Enforcement

Quite a few forensics people got their beginning in law enforcement, particularly federal. Some local police departments are also big enough to support some cybercrime officers – particularly in the Bay Area – but entering forensics through local police is very unreliable as all new officers are treated the same. They all go to the Academy and work patrol for at least a few years before they even have a chance to try for an investigative position like cybercrime. Federal law enforcement is a more reliable route, but with the current Federal budget positions are few and far between. You also have to be hired by age 35 and positions are all over the country. I tried for the FBI, but shortly after the written test they entered a hiring freeze that’s lasted a year so far. It’s still a viable route if you’re not picky about where you live or what agency you work for, but given my age and my wife’s living preferences, it’s not going to happen. At some point in the future perhaps I could get a civilian position at a cybercrime lab, but those are still uncommon.

Consulting

A few people I talked to recommended going the consulting route, getting hired by a consulting firm and doing forensic work for them for a few years. By all accounts consulting is extremely hard work and requires a lot of travel, but the managers at the firm I talked to didn’t care about a low level of experience. As long as I had a handle on the basics, was comfortable with travelling and working very long hours, they would give me the training and mentoring. This seemed like a very likely route and would be a good one for other interested forensic people to follow, but it turned out the firm I was talking to stopped hiring for the time being and I got the job offer for my current job before I caught another firm’s interest.

Corporate

As I was talking to the consulting firm, I was also applying for corporate jobs. Despite having a forensics certification, I had a hard time getting corporate interest due to my lack of experience. Some good contacts got me a couple interviews, but no offers. Hiring managers who were looking for DFIR people could generally find someone with more experience than me. That’s when I came across a posting for my current company. It wasn’t true DFIR, it was more spam and fraud with some additional application security issues in responding to XSS attacks. Still, it was close enough to some of the things I’d done in the past to get me an interview. During the interviews, I asked about what elements of security were covered under the security team, including incident response and forensics. Despite my lack of experience in this realm, my training and study of DFIR plus my previous experience with web app security encouraged the manager to create an infosec position to start building out an incident response capability. I got the job.

Hopefully these notes about my DFIR job search will help other new and inexperienced forensic hopefuls find a position that works for them. I’d love to read anyone else’s forensic job search stories, please share them in the comments.

Status update

2011-10-20T11:14:00.000-07:00

Wow, I can't believe I haven't updated this blog since July. A lot has been going on since then, and I've been too busy to keep up the blog. While I hope to have more time and material in the near future, I'm starting a new role at a new company at the end of the month and I don't yet know their stance on personal blogging. Once I've had a chance to get settled there and get to know their stance on blogging, hopefully I'll be back here posting regularly about what's going on.

In the meantime, I've been learning more about incident response. In particular, Harlan Carvey's written some great articles on his blog, I highly recommend them. They're more pointed at high level overviews of IR rather than step by step how to do it, but that's what I need right now: basics of how to approach it. Besides, the details of IR vary dramatically based on your org's situation and needs, so that's really the only way to do it.

Also, Brian Baskin's DerbyCon talk "How to Get Fired After a Security Incident" is now available online. It's a great presentation about common mistakes made in forensics and incident response.

The short version of both Harlan's and Brian's message: prepare yourself before you discover your breach.

Sabotage, Stuxnet and the future of cyber attacks

2011-07-11T12:27:00.000-07:00

Last year, before LulzSec and Sony's epic fail, the big topic in computer security was the uniquely sophisticated and targeted malware known as Stuxnet. I blogged about it back in September. Now, Kim Zetter of Wired Magazine's Threat Level blog just posted a great overview of the effort to reverse engineer Stuxnet. If you haven't read it yet, you should now. Not only does it present a lot of great info on Stuxnet, it also gives some good insight into malware reverse engineering in general. The rest of this post will presume you've read it.

Most of the article is excellent, well researched and well written. However, I take serious issue with one of Ralph Langner's quotes towards the end of the article. Here's the excerpt:

They will likely have no second chance to unleash their weapon now. Langner has called Stuxnet a one-shot weapon. Once it was discovered, the attackers would never be able to use it or a similar ploy again without Iran growing immediately suspicious of malfunctioning equipment.

“The attackers had to bet on the assumption that the victim had no clue about cybersecurity, and that no independent third party would successfully analyze the weapon and make results public early, thereby giving the victim a chance to defuse the weapon in time,” Langner said.

In an ideal world, Langner would be completely correct, but in practical terms he's wrong. I have great respect for Langner, his expertise and his work, but it seems that almost daily I'm reading about people falling for the same attacks over and over again. As just one example, Stuxnet spread from network to network through infected USB drives. This isn't a new attack, back in 2008 the Department of Defense was hit by a major attack spread through USB. That virus was successful, but was a re-use of a virus from 2007. One would hope that the US Government takes information security seriously, but just this year DHS tested how many employees would pick up an infected USB drive and plug it into a secure system. Result: 60%. If there was a company or government logo on the drive, it was up to 90%. Old and well-known attacks work, even on high-value targets that really ought to know better. Similarly, although 0-day exploits are highly valued for malware and hacking attempts, the majority of malware out there is successful using exploits for which patches are available.

However, let's give the Iran's Atomic Energy Organization the benefit of the doubt. Let's presume since Stuxnet, they're keeping updated with every critical security patch for every piece of software they run -- an impressive feat! That can't keep them safe, new exploits are discovered daily. To get a sense of the scale of the problem, take a look at the Exploit Database and remember that those are only the exploits that are discovered by responsible security researchers, not criminals. To further complicate issues, Stuxnet has a compartmental structure. From the article: "[Stuxnet] contained multiple components, all compartmentalized into different locations to make it easy to swap out functions and modify the malware as needed." It seems apparent that the authors of Stuxnet could simply swap in new 0-day attacks and continue as before. In fact, earlier this year a security researcher discovered a serious bug in Siemens' industrial control software and wrote proof-of-concept malware to exploit it. He claims that Siemens didn't take aggressive enough action to patch the exploit.

Frankly, the recent hacking of Lockheed, Sony, Oak Ridge National Labs, Sony, InfraGard, Sony, RSA, Sony, HBGary, Sony, and assorted government contractors proves that any network can be penetrated. The only difference now is that people are more aware that attacks on the sophistication level of Stuxnet are possible. This gives incident responders a better chance to identify and react to malware and breaches. This is what Zetter referred to when she wrote "the attackers would never be able to use it or a similar ploy again without Iran growing immediately suspicious of malfunctioning equipment." The difficulty is, equipment malfunctions. Software has bugs and hardware fails, particularly when you're a country dealing with jury-rigged equipment smuggled in under trade embargoes. For any given failure, cyber attack is the least likely cause, that's why Iran's centrifuge failure rate could increase dramatically for months before a cause was found.

To further complicate the issue, I find it highly unlikely that Iran has sufficient personnel with the skills necessary for incident response and advanced malware reverse-engineering. Quite frankly, even the US government is having problems recruiting and retaining people with those skills. It's hard to imagine that Iran has an easier time with this problem.

Quite frankly, in my opinion the only limiting factor on cyber attacks against physical infrastructure is the will and resources to do it again. It's only a matter of time before another powerful and skilled group decides they want to execute a similar attack.

Reverse engineering a malicious PDF Part 3

2011-06-06T14:37:00.000-07:00

Welcome to my series in progress about reversing a malicious PDF. Last time I worked through the first exploit, geticon(), and its shellcode payload. Next, I'll be looking at printf(), which is triggered if the user is running Adobe Reader 7.1. Here's the code:

Again, the payload is the appropriate shellcode variable I found previously (shcode_printf). It's different code this time, but it follows the same pattern. Build the NOP sled, this time in the variable nop. Append the payload to create heapblock. Build a bigger, 261310 character NOP sled in block. Create an array mem and populate it with 1400 copies of the full NOP sled plus heapblock to create the heap spray. Attack the vulnerable function util.printf, overflow the buffer and Adobe Reader hits the NOP sled and executes the shellcode.

This is an older exploit, CVE-2008-2992 made public in November of 2008. A patch was available at the same time the vulnerability was published.

Now, the fun part. What does the shellcode do? Like last time, let's look at the hex and see if there's any obvious URLs.

No such luck. Back to scLog to execute the shellcode. Executing the shellcode shows it loads shell32 to get the Temp path and loads urlmon to try (but fail) to download a file to Temp. Just like before, it tries to access /forum.php?f=PDF and passes along the exploit used (printf). Again, the file would have been saved as a.exe. Simple enough.

Onward to exploit 3, collab().

First, we have a function fix_it, which takes two variables: yarsp and len. It enlarges the string to twice len, then cuts it down to half len. Once again, the shellcode is taken from shcode_collab and stored as var shellcode. Variables cc and addr are set to hex numbers, and sc_len is set to twice the length of the shellcode (338). These are used to calculate the new variable len (equal to 4093910). All of this is leading up to the good stuff, beginning with var yarsp. This variable is defined with a few NOP codes, which is then run through fix_it with len. This extends yarsp to a real NOP sled, 2096955 characters long. The variable count2 is defined and a for loop is used to generate mem_array, which is the heap spray. Next, the var overflow is created and extended to 65536 characters. Finally, overflow is passed to the vulnerable Collab.collectEmailInfo() method to trigger the exploit. This is another old exploit, discovered and patched in 2007 (CVE-2007-5659)

So far, so good. Now, onto the shellcode. I run it through scLog just like the others ... and just like the others it loads shell32 to find the temp directory, uses URLDownloadtoFile to try to access /forum.php?f=PDF (Collab)&key=... and save it to temp as a.exe.

The first three exploits all followed the same basic pattern: create a big NOP sled, attach shellcode, replicate it a few hundred times into a heap spray, overflow the buffer and let it go. All the shellcodes had essentially the same function as well, download a trojan EXE to the temp directory. As a result, I'll leave the last exploit and shellcode as an exercise to the reader. :)

Reverse engineering a malicious PDF Part 2

2011-06-02T15:46:00.000-07:00

In Part 1, I began analyzing a malicious PDF. Within the PDF, there was a fair amount of obfuscated malicious Javascript present, which I parsed through. Through many transformations and text replacement, the Javascript eventually decoded and executed the attack code, saved as the variable etppeifjeka.

The attack code was initially obfuscated with excessive exclamation marks:

but once the exclamation marks were removed, it became neat and tidy code. Unlike the malicious Javascript I analyzed last month, once the exclamation marks were removed this code even had line breaks, making it much more legible. The attack code contains several functions: nplayer, printf, geticon, and collab. The PDF contains code to read which version of Acrobat is running, and based on that chooses the exploit to launch.

Adobe has provided some documentation for the app.viewerVersion method. In this case, it's looking at the version of the EScript plugin (which provides Javascript support). The EScript plugin version number is actually the same as the version number for Acrobat itself. Thus, if Acrobat is version 9 or version 8.12 or higher, it runs geticon. If Acrobat is version 7.1, it runs printf. If Acrobat is version 6 or below version 7.11, it runs collab. The last one is oddly written, they might have been trying to write "between 9.1 and 9.2" but as it's written nplayer will be triggered if it's greater than 9.1 or less than 9.2 ... which means if it hasn't hit one of the other functions it'll hit this one.

Here's the code for the geticon function:

Back in part one, I guessed that the shcode variables were the shellcode payloads for the PDF. This function confirms my guess. First, the function grabs shcode_geticon to collect the appropriate shellcode. Then, it's appended to the end of a short NOP sled and saved as the variable garbage. The next bit of code (lines 46-53) uses a variable nopblock to extend the size of the NOP sled. By the time we get through the while loop, the variable block contains a NOP sled 262045 characters long. Since all of this is being stored in memory as the code executes, this is a heap spray. Then, an array called memory is constructed (line 54-55), containing 180 copies of block plus the shellcode. Lines 56-61 construct var buffer with 4012 copies of %0a%0a%0a%0a which are line feeds in hex. Finally, the array buffer is passed to the vulnerable geticon function. The buffer overflows, the execution hits one of the NOP sleds present and executes the shellcode.

Incidentally, this is a well known exploit. I found the exact same exploit code being shared on a security research message board two years ago. Just because all that the news talks about is the new, sophisticated malware, that doesn't mean the old stuff goes away quickly. For example, Contagio has seen samples of this from last January.

Now we've finally reached the point where the shellcode is executed. In this case, what does it do? Daniel Wesemann of the SANS Internet Storm Center provides a short Perl script to take the shellcode and dump it to hex to see if there's anything obvious, like a URL. Here's the code and the results:

In this case, it wasn't very helpful. There's no obvious URL or even anything that follows a URL pattern. The next article in Daniel Wesemann's series continues to compile and disassemble the shellcode for reversing, but I don't read assembly so it's off to another option for me. Malware Tracker has an online shellcode analysis tool, but it didn't work for the four shellcode samples in this pdf. Cruising online guides to shellcode analysis led me to a tool called libEmu. However, when I ran the code in libEmu, it hit my 10000000 step limit before execution actually completed. It looks like either I did something wrong, or I hit an infinite loop in the shellcode. Odd. The same happened with each of the four shellcodes.

Since I'm still new to malicious PDF analysis, I talked to some guys in Threat Research here and they pointed me to a tool called PDF Stream Dumper. Interestingly, I was able to execute the shellcode I copied-and-pasted into it, but it choked on the actual PDF stream that Didier Stevens' tools processed without difficulty in Part 1. This confirms the need to use multiple tools, you never know when one will fail you.

I executed the shellcode within PDF Stream Dumper. There are a couple different ways that you can do this, scDbg uses the libEmu emulation and it crashes the analysis just like libEmu does running under Linux. Running the scLog version (live, not emulated analysis) the shellcode executes. scLog notes that the shellcode loads urlmon.dll, which is an Internet Explorer library for fetching files from remote URLs. Then, the shellcode tries to access shell32.dll, but scLog kills the shellcode to prevent that. Looking at the memory dump in a hex editor, I see a call to a url: /forum.php?f=PDF (GetIcon)&key=87c1a082278ace8fdf2f63b86db29d6f&u= and a reference to a.exe.

These file references imply downloading an external file, but implication isn't proof. So, let's use scLog again and let it actually load all DLLs this time and see what happens. First, some cautionary notes: this is malware we're executing and I'm turning off some of scLog's safety functions. As a result, I'm adding some safety back in. I took a snapshot of my analysis VM first so I could revert if needed. Since this shellcode looks like a downloader, I'm running Wireshark to see if anything actually gets downloaded.

It tries to access /forum.php?f=PDF (GetIcon)&key=87c1a082278ace8fdf2f63b86db29d6f&u= and download a file as a.exe to the user's temporary directory. However, since that's a local URL, it fails and the shellcode crashes. Wireshark confirms that nothing was downloaded. Interestingly, /forum.php takes parameters including where the file request is coming from (a PDF) and even which exploit is being used (GetIcon). Interestingly, it looks like this PDF was intended to be viewed online, not downloaded (or emailed) and viewed.

In summary, the geticon() function exploits a known vulnerability in Acrobat to hook urlmon.dll to download and execute additional malware to exploit the user's system. The vulnerability is known as cve-2009-0927 and there is a patch available to prevent it from affecting your system. Moral of the story: keep your system patched and be careful where you browse.

Next, I'll get to the other exploits and shellcode.

Reverse engineering a malicious PDF Part 1

2011-05-26T12:20:00.000-07:00

One of the projects I work on is a malicious Javascript scanner. It also scans PDFs since the malicious part of PDFs is usually encoded Javascript. To test the scanner, we regularly collect malicious PDFs and run them against the scanner to see if they're detected. Of course, in order to determine if it's really malicious, sometimes you need to go in by hand and see what's going on. To this end, the Didier Stevens wrote a chapter on analyzing malicious PDFs I'll be using that as a reference as I go through a malicious PDF here. I recommend reading it alongside this article. Didier is far better at this than I am, so I won't be trying to explain structural concepts which he explains far better. The PDF I'll be looking at is named 4469.pdf. It was downloaded "in the wild" from a website listed on the Malware Domain List.

Didier provides several python scripts that are useful for analyzing PDFs, the first is pdfid.py. It examines the PDF for indicators of a possibly malicious PDF, such as the presence of Javascript, automatic actions, and document length (most malicious PDFs are only one page). Here's what the results look like for 4469.pdf.

In this case, the PDF is only one page, contains Javascript and contains code that will launch when the PDF is opened (OpenAction). This is potentially suspicious, so let's keep investigating. We know that the Javascript is where the malicious activity will happen, so let's look at that first, using Didier's pdf-parser.py

Pdf-parser.py only located Javascript is in indirect object 2 0 of the PDF. However, indirect object 2 0 references indirect object 11 0 as an OpenAction and Javascript. In a moment we'll see why pdf-parser.py didn't identify indirect object 11 0 as containing Javascript. For now, we see that the pdf is invoking Javascript when the file is opened, which we expect from a malicious PDF, and we expect that indirect object 11 contains our payload.

Using pdf-parser.py again, I can parse out indirect object 11, which is a stream object compressed with the Flate method. Interestingly, this is exactly the same situation in Didier's example script, so it seems this is a common way to obfuscate malicious code in pdfs. Since it's common, Didier provides a method to uncompress the script: pdf-parser.py --object 11 --filter --raw 4469.pdf .... and voila, we have malicious code:

(click to enlarge)

It keeps going like that for another couple pages.

Just like in the malicious Javascript I took a look at last month, the functions and variables all have random names: function hddd(fff), var fpziycpii, etc. There's also plenty of junk characters and excessive transformations to make analysis more annoying. Here's one example towards the end of the script:

for(yrauyiyqouoi=0;yrauyiyqouoi<gmgdouaeyd;yrauyiyqouoi++){var dsfsg = yrauyiyqouoi+1;xrywreom+='var oynaoyoyaia'+dsfsg+' = oynaoyoyaia'+yrauyiyqouoi+';';this[fuquoudieeel](xrywreom);}

There's even a section where every letter is interspersed with a bunch of exclamation marks. It's all messy, but nothing we can't eventually analyze. Let's start at the top.

The first code introduced is function hddd which takes the parameter fff. It takes the parameter and replaces the ** with %u. There are four separate strings processed by this function, which means each string is actually a unicode-encoded string. These are stored as variables: shcode_geticon, shcode_newplayer, shcode_printf, and shcode_collab. Based on the names, these strings are likely the shellcode payloads, but we'll see when we get there.

Next we have:

var fpziycpii = 'e';var uinsenagexo = 'l';var fuquoudieeel = fpziycpii+'va'+uinsenagexo;var ioafyyad = this[fuquoudieeel];rtaoyuupaue = "ioa!fyya!d!('!t!hi!s![!fuqu!ou!d!ie!ee!l](o!y!na!o!yoy!aia!'+!gmg!do!u!a!e!yd!+!')!;!'!)!;".replace(/[!]/g, '');

Stepping through it, the variable fuquoudieeel takes the first two variables and combines them to get "eval", so ioafyyad is this[eval]. Next, rtaoyuupaue is a string that has the replace function executed on it. In this case, the replace function just removes all the extra exclamation points that are in there, yielding:

ioafyyad('this[fuquoudieeel](oynaoyoyaia'+gmgdouaeyd+');');

If we substitute in the known variables, we get:

this[eval]('this[eval]((oynaoyoyaia'+gmgdouaeyd+');');

That's an improvement, but there's still work to do. The variable gmgdouaeyd is later defined as 1100, so we get oynaoyoyaia1100,a variable which isn't defined yet. There's a section towards the end with oynaoyoyaia0 = eiuaopyj; but obviously that's not the same variable. It may be a typo, or it may be junk code ... we'll see. For now, let's move on.

Next we have another function:

function iuoyzemuyyi(ieuohhrk)
{
var iuioathlpau = '!';
var unetoptou = '';
for(xqqauiae=0;xqqauiae<ieuohhrk.length;xqqauiae++)
{
var yaomwteez = ieuohhrk.charAt(xqqauiae);
if(yaomwteez == iuioathlpau) { } else { unetoptou+=yaomwteez;
}
}
return unetoptou;
}

This function is a longer, more complicated way of removing the exclamation marks from a string. Like the last one, this is applied another code section stored as a string and obfuscated with five exclamation marks. The string is un-obfuscated and stored as the variable etppeifjeka. That's a long section and it looks like that's part of the payload, so we'll get to that in part 2. For now, let's skip past it and see how it's used.

The last section is this:

eiuaopyj = ''+etppeifjeka+'';
var gmgdouaeyd = 1100;
var xrywreom = '';
oynaoyoyaia0 = eiuaopyj;
for(yrauyiyqouoi=0;yrauyiyqouoi<gmgdouaeyd;yrauyiyqouoi++)
{
var dsfsg = yrauyiyqouoi+1;
xrywreom+='var oynaoyoyaia'+dsfsg+' = oynaoyoyaia'+yrauyiyqouoi+';';
this[fuquoudieeel](xrywreom);
}
ioafyyad(rtaoyuupaue);

This section is odd, to say the least. The for loop constructs a string which is stored in the variable xrywreom. The loop counts from 0 to 1100 and builds a section of code that declares a series of variables oynaoyoyaiaX where X is the current number, and the variable is set to equal the previous number. The output looks like this:

var oynaoyoyaia1 = oynaoyoyaia0;var oynaoyoyaia2 = oynaoyoyaia1;var oynaoyoyaia3 = oynaoyoyaia2;var oynaoyoyaia4 = oynaoyoyaia3;var oynaoyoyaia5 = oynaoyoyaia4;

It goes up to var oynaoyoyaia1100 = oynaoyoyaia1099; Each step of the loop, the loop runs this[fuquoudieeel](xrywreom); which executes the code stored in the variable. This creates 1100 variables and sets them all equal to eiuaopyj (the variable holding the obfuscated section we haven't examined yet). Let's go back to the earlier section where we saw a reference to oynaoyoyaia. We had deobfuscated it to this point:

this[eval]('(oynaoyoyaia1100);');

which evaluates back to etppeifjeka, the probable payload.

After the for loop is the last line of Javascript in this PDF: ioafyyad(rtaoyuupaue); As we've already discovered, ioafyyad is this[eval] and rtaoyuupaue is this[eval]('(oynaoyoyaia1100);'); so that is the line of code that actually triggers the exploit.

All that's left to do is deobfuscate the exploit itself and see what it does.

Firefox 4 Browser Forensics, Part 5

2011-05-05T21:43:00.000-07:00

We're nearing the end of my series on Firefox 4 forensics (click here for the full list). Media coverage has finally started to make people aware of how much their online behavior is tracked, and the addition of "Private Browsing" modes in all major browsers is making browser anti-forensics easier than ever. This means we'll probably encounter it in our investigations.

First, I'll cover actions that prevent the creation of artifacts: turning "Remember History" off and using "Private Browsing" mode. Then I'll cover various some methods of destroying artifacts that have been created. I won't be covering third-party products.

Preventative antiforensics

To test "Private Browsing" mode, I activated private browsing, searched for Nmap and downloaded the latest version and then closed Firefox. First, I wanted to see if the page was listed in the browser history, so I opened places.sqlite and queried: "select * from moz_places where url like '%nmap%';" No result. Same with searching for 'input' in typed_urls, no cookies from the domain and nothing in the download history either. However, the google search for "nmap", many nmap images, the websites http://nmap.org, and http://nmap.org/download.html all appear in the browser cache with the appropriate timestamps and fetch count. This, plus having the creation time of the downloaded file, tells us exactly what the user did and when.

Turning off browsing history is pretty easily done, it's front-and-center on the "Privacy" tab in options. Default is "Remember history", but there are custom history settings as well as just "off". To test the artifacts, I turned off browsing history, googled "metasploit", and downloaded the latest version. As is expected, nothing is appearing in moz_places (browsing history). Nothing's showing up in the cache or the download history, so oddly enough turning off browsing history protects privacy better than "Private Browsing" mode. That means the only possibilities for detection are outside of Firefox, such as using the operating system to track who was logged in when the downloaded file was created and who executed it.

Note, this is accurate at the time of writing, for the current version of Firefox (4.0.1). Once this is made known, it's entirely possible that any of these behaviors will change. You should always run your own testing to confirm behavior before trusting it in a case.

Evidence destruction

But what if the target of our investigation didn't know in advance that he needed to cover his tracks? Firefox has several options to remove recorded data, from the selective to the blunt.

The most selective way to remove data is through the history pane. If you open the history pane and right-click on a history item, you can select "forget this site". Let's imagine this is a "violation of policy" case: browsing porn at work. I browsed to www.pornhub.com and started a video streaming to get a good cache. Opening up the history, it looks like Pornhub connected to several other porn sites, so if our suspect didn't make sure to forget all of the relevant sites there would still be evidence of their illicit browsing. In this case, however, I'm going to make sure and forget about all of them. After "forgetting" all the sites, there are no traces left in places.sqlite. There's evidence that sites were forgotten because of the gap in id numbers, but no indication of what was formerly there. Interestingly, using "forget this site" completely destroys the cache, but only removes the selected site(s) from the browsing history. This is a clear sign of evidence destruction, and the deleted cache files could likely be recovered from unallocated space or from backups (such as Volume Shadow Copy).

If any of the databases are deleted, Firefox will automatically create a new empty copy of it the next time it's run. Normally, the databases will have a modified date of the last browsing event, but a creation date of when Firefox was originally installed. The creation date is not even modified when Firefox is upgraded or the history is "forgotten" through the browser options. Therefore, if the creation date of the tables is more recent than the creation date of core Firefox files (such as firefox.exe), it's a clear indication that the table was deleted around the creation date of the existing table. It may be recoverable through standard means.

Directly modifying the databases would be somewhat more difficult to detect. The databases are modified constantly through regular browsing, so the timestamps wouldn't be a clue. However, like "forgetting this site", there will be a gap in the normally sequential ID numbers that could indicate that something was deleted, and examining the last_visit_date of the sites surrounding the gap might allow you to determine when the missing sites were visited. If backups of the databases exist, they might have the missing data. Also, the cache isn't nearly as user-friendly to edit as a sqlite database so if the cache isn't cleared it could provide a clue for what was lost. Even if the cache had been cleared, the deleted files might be recoverable through standard methods.

This isn't meant to be a complete overview of all possible methods of antiforensics with Firefox, just a quick highlight of some possibly relevant issues and how to detect and overcome them. This is the end of my Firefox 4 forensics series, I hope it'll be a useful reference for your investigations. If any of this information turns out to be incorrect or changes in future versions, please let me know and I'll edit the appropriate post.

Firefox 4 Browser Forensics, Part 4

2011-04-29T13:22:00.000-07:00

When I started this series, I had no idea it would go on this long. There are more forensic artifacts in FF4 than I thought. It seems like every time I turn around I find another database to mine for artifacts. For example, I was just about to start tearing apart cookies.sqlite when I saw there was a search.sqlite. It didn't turn out to have any significant artifacts, just the listing of search engines in the quick search box. Much more interesting are browser cookies.

Cookies
Browser cookies are a notable and well-known source of browsing history. In IE, each cookie is a separate text file, but in Firefox, they're stored in yet another sqlite database: cookies.sqlite. This database has just one table, moz_cookies, with several columns:

id: an index
name: the variable being stored
value: the value of "name"
host: the website the cookie is for
pathmain: the path the cookie is valid for.
expiry: when the cookie should be purged
lastAccessed: when the website last accessed the cookie in PRTime
isSecure: is HTTPS required to access the cookie?
isHttpOnly: Can the only be accessed by HTTP, or can other methods (Javascript) access it?
baseDomain: The site's base domain, without www or other subdomain
creationTime: when the cookie was created in PRTime

When you're drawing conclusions from cookies, remember to take into account the browser's cookie control settings as well as the cookie timestamps. Like browsing history, cookies can tell you when the user viewed a website and can be a source for usernames and passwords for insecure websites. However, if the user clears cookies regularly, the amount of data will be limited. It also doesn't mean the user visited the site directly, as many advertising cookies (such as doubleclick.net) will be downloaded for related sites.

Saved Sessions
One useful aspect of Firefox is it will automatically save the currently open browser tabs so you can reopen it the next session. The browser tabs are saved in sessionstore.js in Javascript object notation. These aren't just the raw URLs, possible fields include page title, referrer, formdata, and cookies. Any GET variables in the URL are preserved as well. As a result, if the user was logged into a website, they may still be be logged in when the saved session is restored. If sessionstore.js has been damaged or deleted, it may be recoverable in the backup, sessionstore.bak. A quick test shows that sessionstore.bak isn't always a duplicate of sessionstore.js, opening a new browser session overwrote sessionstore.js but not sessionstore.bak, so you may be able to recover two different browser sessions under some conditions.

Bookmark backups
In the profile folder there's a folder called bookmarkbackups, which contains a series of JSON files storing the last 10 backups of the user's bookmarks. The filenames are in the format of bookmarks-YYYY-MM-DD. These backup files include the bookmarks the user explicitly makes, but also Firefox's "Smart Bookmarks" which include items of forensic value like "Most Visited", "Recently Bookmarked", and "Recently Tagged". These backups also include timestamps in PRTime for when the bookmark was added and last modified. As always in forensics, backups like these can provide valuable insight into detecting antiforensics (such as deleting bookmarks) and in behavior over time.

Downloads
downloads.sqlite is where Firefox 3+ stores information relating to downloaded files. There's just one table, moz_downloads, but it has quite a few useful artifacts.

id: an index
name: the local filename of the download
source: the remote filename and path being downloaded
target: where it's being downloaded to
tempPath: if the file is complete, it will be blank. If not, it's where the incomplete file is being stored before moving to target
startTime: Time the download started, in PRTime
endTime: Time the download finished, also PRTime
state: state of download, encoded as an integer
referrer: the page containing the link to the file
entityID: a value used for resuming downloads
currBytes: Number of bytes downloaded.
maxBytes: Total file size.
mimeType: MIME file type.
preferredApplication: From the download dialogue box, if the user clicks run, this stores the program that will open the downloaded file. If the user clicks save, this will be blank.
preferredAction: Action to take when download is complete. Default is 0, just save the file.
autoResume: Can the download be resumed if broken?

extensions.ini records what Firefox extensions are installed, which may be useful if, for example, hacker tools like Hackbar or anonymizers like FoxyProxy are installed.

Form history
formhistory.sqlite is another good source for artifacts, although unfortunately it doesn't track what website the form was used on.

id: Another numeric index
fieldname: The field that contained value. This may be an HTML field in a website's form, or it may be a Firefox field, like searchbar-history.
value: What was typed into fieldname. In addition to search history, this is a good source for email addresses and usernames connected to the user.
timesUsed: How many times the user has typed value into fieldname.
firstUsed: The first time the user typed value into fieldname, in PRTime as always.
lastUsed: The last time the user typed value into fieldname, in PRTime as always.
guid: A global id for the formhistory, in case syncing is enabled.

Cache
The cache exists in two folders, for Windows 7 they are Users/[user]/AppData/Local/Mozilla/Firefox/Profiles/[profile name]/Cache and Users/[user]/AppData/Local/Mozilla/Firefox/Profiles/[profile name]/OfflineCache. The offline cache is used when Firefox is in offline mode, but it's the standard cache which will be more likely to be used for forensics. The cache can be viewed through the browser by navigating to about:cache, or it can be viewed directly on the file system. On the filesystem, the actual cache files are stored in a set of directories and subdirectories with names in hex. The files can be located by using the _CACHE_MAP_ and _CACHE_00X_ files. A full writeup on how the cache works has been done by Symantec's response team here. As far as I can tell, the cache scheme hasn't changed since then. This layout is rather inconvenient to navigate by hand, so an automated tool like Firefox's cache browser or other tool is definitely the way to proceed here. Looking at about:cache, it appears Firefox stores useful information like the full URL cached (including GET parameters), cached file size, number of times the cached file was accessed, last time the file was modified and time the cached file expires, full hex dump of the file, and the full HTTP request issued to access it. Since these are individual files on the hard drive, the standard Modified-Accessed-Created timestamps can provide additional information.

Alright, we're finally through the forensic artifacts available in Firefox 4! There'll be just one entry left, anti-forensics in Firefox 4.

Firefox 4 Browser Forensics, Part 3

2011-04-22T12:56:00.000-07:00

In Part 1, we covered typed URLs and the bookmark structure of Firefox 4. In Part 2, we started delving into the moz_places table, ending with an introduction to frecency.

As I noted, frecency is a number generated by Firefox that combines different measures of user behavior with a URL, including bookmarking it, frequency and recency of visits. The result is a single number that tries to quantify how interested the user is in the URL. This means that with a simple SQL query (select * from moz_places order by frecency desc limit 20 for example), we can get a snapshot of the user's current sites of interest. This could be particularly useful for an "acceptable use policy" investigation, where the issue may turn around how much of a user's browsing history is personal vs. work-related. If the FarmVille app is among a user's top 20 sites sorted by frecency, a violation should be pretty easy to prove. Since frecency is based on other known factors, you could go through the user's full behavior to see what exactly they did to get there (type of visit, etc). That information is stored in moz_inputhistory (which we already covered) and moz_historyvisits.

moz_historyvisits
As the names imply, moz_places records the urls that a user visits, and moz_historyvisits record the details of each visit to the url. Since it records each visit to each page in the domain, there will be a lot of records ... which makes a shorthand like frecency very useful. The columns are id (the index), from_visit (the referrer), place_id (the connection back to the URL entry in moz_places), visit_date (timestamp in PRTime again), visit_type, and session.

Let's step through what this means by actually analyzing my browsing behavior. First, I ran select * from moz_places order by frecency desc limit 20 to grab the top 20 websites from moz_places to look for something interesting. I'm arbitrarily picking http://www.wired.com as my URL of interest. moz_places.id for this url is 485, so I run select * from moz_historyvisits where place_id=485 which yields:

seven visits. Now, for these results we can ignore the first column (id). Next is from_visit, which gives the id of the page I visited before visiting the current page. For the last three visits, it's 0 indicating that I opened a new tab and went straight to Wired. For the others it refers to the immediately prior id number, which is what you would expect if I was only browsing in one tab at the moment. If the numbers were not consecutive, that would imply multiple-tabbed browsing. In the first entry, I came to Wired after visiting the entry in moz_historyvisits.id=941. Looking up that entry, I see that was a visit to place_id=484, which is http://wired.com. Incidentally, that's true for the first four entries. To explain why, see that the visit type for all four www.wired.com entries is 5, indicating a permanent redirect (HTTP 301). For the respective entries for http://wired.com, the visit type is 2, indicating I typed the URL. So, at those times I typed wired.com in the address bar. Firefox logged the visit and took me to http://wired.com, which redirected me to http://www.wired.com and logged another visit. For the last three visits to Wired, I typed www.wired.com directly. Since those were the more recent and since I logged 7 visits to www.wired.com and only 4 to wired.com, www.wired.com was the one that was on top in frecency (8800 vs. 4813) instead of the non-www version, despite the fact that a typed URL gets a frecency bonus over a redirect URL. Also note that just because I came to www.wired.com via a redirect, doesn't mean I didn't intend to go there. Seeing what site took me there is essential to determine what my intentions were.

Obviously this is a trivial example, but it should be pretty apparent how it could be applied to a more interesting investigation.

More tables
There are a set of tables called moz_annos, moz_anno_attributes and moz_items_annos, but as far as I can tell they are used by Firefox extensions and are unlikely to be useful for forensics.

That's everything of interest out of places.sqlite, but there are other tables that have useful information: tables like signons.sqlite. This is where the logins and passwords are stored. If the user hasn't specified a master password for his Firefox profile, then the usernames and passwords will be clearly available through Options > Security > Saved Passwords. If there is a master password set and you don't have it, then you won't be able to get to the list of sites and passwords directly. Nothing stops you from accessing signons.sqlite directly, though.

signons.sqlite contains two tables, moz_logins and moz_disabledHosts. moz_disabledHosts is a list of websites which the user doesn't want Firefox to ask to remember logins. moz_logins is where the sites, usernames and passwords are stored. The columns are id, hostname (the login page), httpRealm, formSubmitUrl (the actual page the username and password get sent to), usernameField (the identifier of the username field), passwordField (the identifier of the password field), encryptedUsername, encryptedPassword, guid (global ID, for login syncing), encType, timeCreated, timeLastUsed, timePasswordChanged, timesUsed.

Setting a master password in Firefox does not change any of the data here, it just blocks you from viewing the decrypted passwords IN Firefox. You can still get lots of useful browsing information from the file, everything except what their username and passwords are. Documentation on signons.sqlite is scanty, but from what I can tell all the timestamp fields are new in Firefox 4. Strangely, these timestamps aren't encoded in PRTime (microseconds since Unix epoch) like the rest of the timestamps. Instead it's miliseconds since epoch, so we get all the timestamps with:

sqlite> select hostname, datetime(timeCreated/1000,'unixepoch'),datetime(timeLastUsed/1000,'unixepoch'),datetime(timePasswordChanged/1000,'unixepoch') from moz_logins;

For my test system, the results are:

This system has credentials saved for two Facebook accounts. For the first, the login was saved on March 17 and last used on March 31. For the second, it was only used once, on April 4. Neither has changed passwords. This can be useful if you need to prove that a user actually logged into a site, rather than just visiting it. If a user clears their browsing history but not saved passwords (which is default behavior), this will still show up as well. It's also yet another way to prove that a user actually intended to go to a site repeatedly instead of it being an accidental click or redirect.

The usernames and passwords are encrypted, but the master password and decryption keys are stored in key3.db (more info here). Since you have the decryption keys, decrypting the passwords should be possible if needed. There are tools out to do that, so I'll leave that as an exercise to the reader. :)

In Part 4, I'll go into cookies and cached files.

Firefox 4 Browser Forensics, Part 2

2011-04-18T10:19:00.000-07:00

In Part 1, we covered typed URLs and the bookmark structure of Firefox 4. Now, I'm going to start digging into moz_places.

moz_places
moz_places is the main table for the browser history. It's columns are id, url, title, rev_host, visit_count, hidden, typed, favicon_id, and frecency[sic].

The first 20 entries of moz_places in my test system.

As we've mentioned before, id is a simple numerical index that connects the links in moz_places to their references in the other tables. The Mozilla Wiki has a handy graphic for reference.

After id is url which is the full URL of the visited page. As you can see from my test results above, it's the exact page visited, not just the domain. That's why we see my click train from http://www.phishtank.com/ to http://www.phishtank.com/login.php and then to http://www.phishtank.com/phish_archive.php. Next is Title which is the stored title of the page.

The Mozilla Wiki notes:

Bookmarks are basically pointers to that history entry, with a few properties to determine their placement in the bookmarks folder hierarchy. The design is such that most properties of a bookmark are derived from the moz_history entry, and not the bookmark.
This is problematic as soon as the same URI is bookmarked more than once. Eg: If you change a bookmark's title, then the title changes anywhere you've bookmarked that URI.

This is no longer the case. As we already discovered, the moz_bookmarks table has it's own title field where the bookmark title is stored. Changing the bookmark title no longer overwrites the title in moz_places.

rev_host is the fully qualified domain name backwards, ending with a period. So, "http://www.phishtank.com/phish_detail.php" gets converted to "moc.knathsihp.www." Firefox uses this so that they can index this and quickly search for subdomains of a primary domain. An investigator may want to use this field for the same purpose. See the Firefox source code. Thanks to FirefoxForensics for this.

visit_count is another field very useful for an investigation. This is an integer that increments for every time the user visits the site. Since the places.sqlite is associated with the user logged into the computer, this only reflects the number of times that particular user account visited the site. Some additional notes from FirefoxForensics:

This counter is incremented when the associated places.sqlite::moz_historyvisits::visit_type is not 0, 4 (embedded), or 7 (download).

Research by the author shows that reloading a page by clicking the 'Reload current page' button, pressing CTRL-R or following a self-referring URL does not increment visit_count.

If the start-up option to 'Show my windows and tabs from last time' is selected, the visit_count of those pages will NOT be incremented when the browser is started and they are loaded.

If the start-up option to 'Show my home page' is selected, the visit_count of the home page WILL be incremented each time the browser is started and they are loaded.

hidden
According to the Mozilla devs, "Hidden uri's are ones that the user didn't specifically navigate to. Those tend to include embedded pages and images. It might include something else, but I'm not 100% sure." At first glance one might want to exclude this from analysis because the user didn't specifically navigate to them, but since it includes images that would be a mistake. If the user navigated to the page containing the image, the images entry here would still give you valuable info like how many times the image has been loaded, etc.

typed is different than the input field in moz_inputhistory If the user started typing and then clicked the quick result, then it'll be listed under moz_inputhistory.input. If the user typed the full url, then it'll be under moz_places.typed.

To give an example, the first time I went to phishtank.com, I typed "www.phishtank.com" into the address bar and it took me to the site. That generated this entry in the database:

The next time I visited, I just typed 'phishtank' before Firefox recognized the URL and I went to the site. That got stored in moz_inputhistory.

favicon_id is an id number that connects to which image in moz_favicons is the favicon (the little graphic in the title bar) for the page.

The last field in moz_places is frecency. That's not a typo for "frequency", it's a combination of "frequency" and "recency". As you'd expect from the name, it's a value generated by both how often the user has visited a place and how recently they visited it. The full algorithm is here. 0 is the default score, and the higher the number the higher it appears on autocomplete results. As the algorithm link shows, it draws on a number of elements of user behavior to determine the frecency. This means that you can use it as a shorthand for determining if a user was interested in the URL and then investigate the underlying behaviors (how often they visited, how often they typed the address vs. redirect vs. following links, if they bookmarked it, etc) to articulate what exactly they did that shows interest in the link.

Frecency turns out to be a pretty complicated topic, so I'll save it (and signons.sqlite) for part 3. Part 4 covers cookies, cache, downloads and more.

Firefox 4 Browser Forensics, Part 1

2011-04-13T15:48:00.000-07:00

Firefox 4 was released almost a month ago now, and was in open beta for a significant time before that. However, a cursory Google search doesn't reveal much documentation of it's features of forensic interest, or it's changes since the last version.

For this analysis, I'm using Firefox 4.0 (current version as of writing) running on a Windows 7 VM. To examine the sqlite databases, I'm using the sqlite3 command line tool. Sqlite3 runs under Linux and Windows, and you can feed it SQL commands to script common actions, such as searching history for keywords or for browsing during a time range of interest.

Just like Firefox 3, Firefox 4 stores the browser history in an SQLite database. For Windows Vista/7, it's located at :\Users\\AppData\Roaming\Mozilla\Firefox\Profiles\\places.sqlite This database contains the tables moz_anno_attributes moz_annos moz_bookmarks moz_bookmarks_roots moz_favicons moz_historyvisits moz_inputhistory moz_items_annos moz_keywords and moz_places These tables seem unchanged from version 3, as documented on the MozillaZine.

moz_inputhistory
When a person begins typing into the address bar, Firefox searches through it's browser history to try and connect what the user is typing with the websites he has visited recently. It outputs the suggestions with the webpage title and full URL in the suggestions below the address bar. When the user clicks the suggestion, the text they typed to find that url is stored in the moz_inputhistory table. The moz_inputhistory table is of particular interest to forensics because it can show that the person using the user account typed something into the address bar to access the site, rather than following a link or getting forced there by a pop-up.

The column names for this table are place_id, input, use_count, and PRIMARY KEY. Here's an example of the contents of the table, taken from my test system.

Note that none of these are full links. What you see here is what you get when someone starts typing a URL or keyword into the address bar and then clicks on one of the autocomplete terms. It does not seem to record full URLs. So, we get "ars t" and "arstechn" from two of the ways I accessed Ars Technica. It does not store search terms from the search box.

place_id refers to the destination of the input. This number can be converted into the actual website visited via the moz_places table. So, for example, I see that when I typed "ars t" into my address bar, I clicked on the website with id 197. The command > select * from moz_places where id=197; returns the website URL (http://arstechnica.com/) and the website title (Ars Technica) as well as other information that we'll cover when we get to the moz_places table.

The last column, use_count is an odd one. David Koepi looked at Firefox 3.6 and suggested that use count refers to the number of times the same text was typed into the address bar. On my system in Firefox 4, that doesn't seem to be the case as most of the values in use_count are decimals (see screenshot above). Running some tests, it seems to be related to the number of times run ... for example, typing "sans.o" into the address bar the first time adds it to moz_inputhistory and sets use_count to 1. So far so good, but here's where it gets odd. Typing it in four more times changes it to 1.9, then 2.71, 3.439, and 4.0951. As you can see from the other links in my history, many of them end up with values less than 1. This is probably a bug in Firefox, so I wouldn't rely on the value of this for any reason until it's better understood.

This is why it's important to do your own testing, instead of just believing what you read on the Internet.

moz_bookmarks and moz_bookmarks_roots
Bookmarks are also valuable for an investigator to examine because like inputhistory it implies that the user took an active action with the site, in this case marking it for later re-visit. The fields here are id, type, fk, parent, position, title, keyword_id, folder_type, dateAdded, lastModified, and guid. Comparing to the documentation by David Koepi and firefoxforensics, it appears guid has been added for FF4. According to the Mozilla wiki, guid was added in order to have a unique global identifier, rather than the simple incrementing index of id. This means that gid, not id, would be the proper link between bookmarks across computers using the new Sync service in FF4. Note, I haven't tested this.

type is an integer referring to the type of the bookmark. Type 1 is a normal bookmark, 2 is a tag (folders are really just a type of tag). Type 3 is a separator, and so has no useful info. fk is a foreign key, which links to the id in moz_places (where you can find the actual url). parent refers to the id of the containing object (folder), which can tell you where the user categorized the bookmark. position refers to the listing order of the bookmarks, and is not likely to be interesting. title refers to the display name of the bookmark and keyword_id is the index number of the keyword (moz_keywords) associated with the bookmark. It may be useful to find associated bookmarks. folder_type is not likely to be useful, but dateAdded and lastModified would be. These values are exactly what they sound like, stored as PRTime

moz_bookmarks_root defines the root folders in the Firefox bookmark structure, and is not of forensic interest.

In Part 2 I'll get into moz_places and more browsing history. Part 3 has moz_historyvisits and signons.sqlite. Part 4 covers cookies, cache, downloads and more.

Reversing malicious Javascript, part 2

2011-04-08T16:50:00.000-07:00

This is part 2 in my adventures reverse-engineering a malicious Javascript I found on my computer. Last time I unraveled some annoying string manipulation that eventually ran return eval(String.fromCharCode()) on a long series of Unicode-encoded characters.

I finally unencoded that long string of Unicode and, as expected, it was more Javascript. I was surprised at how much there was ... several hundred lines of code. This is unusually large for malicious Javascript. Bigger doesn't mean more sophisticated, however!

There are two Javascript functions that are relevant here. The first is called 'zazo', which tries to exploit a vulnerability in the Java Development Kit to load a malicious Java applet that the attacker controls. The payload is gone by now, so I can't tell what it would have done. This is a known vulnerability, CVE-2010-0886, and is described in detail here.

The second function is the reason this malicious script is so long. It includes a version of PluginDetect, a script by Eric Gerds that is designed to determine what version of many common browser plugins are being used. In this case, the malware author has it probe for Java and Adobe Reader versions, although the script only uses the Adobe Reader version. Although this plugin detector is being used maliciously, it's not inherently malicious and there's no reason to think Eric has any connection to the malware author.

After determining what version of Adobe Reader is being used, the script makes a simple calculation: if Reader is older than 8.0, it serves up one malicious pdf. If Reader is between 8 and 9.3.1, it serves up an alternate malicious PDF. If you don't have Reader or if your copy of Reader is up to date, you're safe from this script. Reader version 9.3.1 was released specifically to patch the vulnerability described in CVE-2010-0188, which affected Reader versions 8 to 9.3, so we can be fairly sure that's what this PDF was exploiting.

Interestingly, in part 1 we discovered that this bit of malware knew that it was 2011 and it would need to be modified to function in a different year. Despite that, the three bugs it attempts to exploit are old. The Java bug had a patch available a year ago. With the Reader exploits, one was patched last November and the other only affected versions older than 2006! These are not anywhere close to 0-day attacks. This is exactly why it's so important to keep your software up to date.

Also, Java is very frequently exploited. If you don't absolutely need it, get rid of it. Then hackers will have one less way to attack you and you'll have one less program to keep updated.

Reverse engineering a malicious javascript part 1

2011-04-06T16:02:00.000-07:00

My antivirus program flagged a malicious javascript a few days ago. At some point in my web browsing, a webpage quietly served up a malicious script in addition to the regular content. It was saved to my browser's cache and quarantined by my antivirus. Being the curious person that I am, I thought I'd try my hand at understanding how it works. Of course, as is typical of malicious scripts it was obfuscated. Instead of looking like nice Javascript:

<script type="text/javascript">
document.write("<h1>This is a heading</h1>");
document.write("<p>This is a paragraph.</p>");
document.write("<p>This is another paragraph.</p>");
</script>

the malicious script is a mess, deliberately difficult to read (click to enlarge):

The sequence of numbers keeps going for the rest of the script.

Malware authors use tricks like this to keep people like me from understanding how the script works, and to make it more difficult for antivirus software to detect the page. If the av can't penetrate the obfuscation, then if they start detecting this page all the malware author needs to do is obfuscate it differently to generate a new signature. For more information on reverse engineering malware, take a look at this BlackHat presentation (pdf).

The curious thing about obfuscation is that it's designed to be difficult for people to understand yet simple for computers to understand. Luckily for me, that means we can use a javascript engine to translate it all back for us. Didier Stevens has modified Mozilla's Spidermonkey for exactly this purpose. All I need to to is extract the javascript from the rest of the page so I can feed it to the engine. Since this is pretty simple, though, I'm going to do this by hand.

Since the code has no line breaks or anything else useful, I fed it into Eclipse to clean it up and grab the javascript.

Cleaning it up in Eclipse makes the initial part of the script make a lot more sense. Take a look (click to enlarge):

If you know a little Javascript, you can already get an idea of what's going on. We've got a hidden textarea with some text in it. Right now it's meaningless, but this is going to be modified by the Javascript to pull the script together. The applet section makes a reference to a Java applet that would've been housed on the same webserver as this malicious webpage. Since I found this file in my cache, the applet isn't available for me to examine.

Right now it's the content in the script tags that we're going to look at. This is the part of the script that pulls together all the obfuscated components of the script and tells the browser how to execute them to infect itself with whatever piece of badness the author wants to hit me with.

Let's work through this step by step.

var date = new Date();
var f = date.getFullYear()-2009;

First, the script gets the date, pulls the year out, subtracts 2009, and saves it to the variable f. This limits the script to only this year, but the lifetime of an attack like this measures in days at the most so that's not a significant limitation. All this is a complicated way of defining f=2.

Next, we have:

zni = '2011val'.replace(date.getFullYear(),'');
var e = new Function('axlzg','return e'+zni)();

zni is another variable. Here, we take the string '2011val' and then delete the current year, so zni = val

Then, we define a function, e. e produces a string 'axlzg' and also takes the string 'return e' and appends the value of zni. This computes to return eval, which is a Javascript command to evaluate a string as if it was code.

Moving on:

xzjc=document.getElementById('textarea').value;
var content = '';

There's another uninformatively-named variable here, but it's pretty obvious what it does. xzjc grabs the content of the text area, so xzjc = 'tring.from2011har2011ode' The script also defines a variable 'content', which is a blank string. We're getting somewhere now!

var fnxes=e('S'+xzjc.split(date.getFullYear()).join('C'));

This one's a little more complicated. This one's another text-manipulation exercise that will further translate things. Like math, we need to start from inside the parentheses and work outwards.

First, we're taking xzjc from the last line. We put 'S' in front and then split it into separate strings using the current year as the split point, yielding 'String.from' 'har' 'ode'. Then we re-join the fragments using a "separator" of 'C'. Now we have 'String.fromCharCode', which is a Javascript function that takes encoded characters and decodes them to a string. This result is run through the function "e", which takes the string and converts it back to code, so it can execute.

The reason the author is bothering with all this is because String.fromCharCode() is a common function that takes a set of character codes (in this case numbers) and converts them back to letters. For example, "51*f" is 51*2 = 102, which is the Unicode character code for f. Malware authors often use to obfuscate their code (as we'll soon see) so, it's a indicator that antivirus companies will trigger on. In this script, the malware author has to obfuscate their obfuscation method in order to try and evade the antivirus signature. I found this script because it triggered my antivirus, so even all this obfuscation failed.

Let's look at the last couple lines of this script.

content = fnxes(51*f,58.5*f,55*f,49.5*f,58*f,52.5*f,55.5*f,
        55*f,16*f,50.5*f,55*f,50*f,47.5*f,57*f,50.5*f,50*f,52.5*f,
        57*f,50.5*f,49.5*f,58*f,20*f,20.5*f,61.5*f,62.5*f,29.5*f,
        50*f,........ );
     e(content);

There's actually a lot more numbers in there than I'm showing, I'm just cropping it out for simplicity's sake. The script is taking the variable "content" and actually defining it. It's taking each of these numbers and multiplying it by f, which we already learned was 2. Then, it's running fnxes (which is really String.fromCharCode) against it. Now I'm going to turn to Spidermonkey to translate all this crap into real code, it would just be too annoying to do by hand.

So, after we multiply the numbers by 2 and then turn them back into a string, we get the payload. Unfortunately the payload itself is pretty long and complicated, so that'll have to wait for part 2 so I can have time to figure out what's going on.

Digital forensics and search warrants

2011-03-24T11:54:00.000-07:00

Laws always lag far behind the pace of technology, and the laws surrounding computer security issues are no exceptions. It took several major data breaches before we began getting breach notification laws. Now, courts are trying to figure out how search warrants should work in computer crime cases. Ars Technica has a good overview of the current state of things.

NOTE: I am not a lawyer. This is not legal advice or recommendations. If you want legal advice, ask your lawyer.

It's a sticky issue because on one hand modern computers can have vast amounts of highly personal information on them: thousands of emails, journals, legal pornography, address books, etc. It can feel like an unreasonable invasion of privacy for law enforcement officers to go pawing through all of that to look for evidence of a crime, particularly if it's the victim's computer being investigated. Search warrants are supposed to specify what exactly is being looked for (stolen intellectual property, for example), and law enforcement officers are only supposed to look in places where the object of the warrant could reasonably be ... so no searching an office desk if the warrant is for a stolen car.

On the other hand, search warrants allow officers to search anything that could be hiding the object being searched for. There are plenty of videos of drug searches that show how ingeniously things can be hidden and how thorough searches can get in the physical world. The same principles apply in the digital world as well. Just as a packet of drugs can be hidden in a jar of flour, a contraband file can be hidden inside another file without too much difficulty or technical skills.

Furthermore, if evidence of illegal activity is seen on a computer, sometimes the accused will claim that either a hacker or malware is responsible, not the accused. It's perfectly possible for malware or hackers to take control of a computer and use it for illegal activity. That sort of activity can be detected, but digital evidence can be lost if not seized in time. This means that if we restrict our search to only looking for the illegal file mentioned in the search warrant, we could lose the opportunity to determine if someone other than the owner of the computer could be responsible for the illegal activity. A computer search that's too narrow in scope could result in the loss of evidence that could show the suspect's innocence.

Like many legal issues, this is a complex one with multiple legitimate concerns acting at cross purposes. Hopefully, the legislature and courts will come up with a solution that provides reasonable privacy protection, is practical, and does not place too heavy burdens on law enforcement.

Future trends in computer security

2011-03-22T12:04:00.000-07:00

These are exciting and fascinating times we live in, particularly for computer security. There's so much change going on that frequently it can be difficult to keep track of what's going on and what's coming before it hits you in the face. I rely on a wide selection of blogs (see the sidebar) to keep me informed of current trends.

Frequently I find the same "hot topic" being discussed simultaneously by a wide range of sources, rehashing the same limited information (e.g., Stuxnet or HBGary). Once in a while, though, I find a little nugget of information that startles me and really makes me wonder why no one else has noticed it.

Strategic Studies Quarterly is not normally in my reading list, but the spring issue is devoted in large part to cyberwar. As you know from my blog, normally I'm skeptical about claims of cyberwar, but this is the military's view of cyberwar instead of reporters or politicians, so I think it's worth reading. Some of the articles are more interesting than others, of course. For example, I think the article Rise of a Cybered[sic] Westphalian Age is fundamentally impractical due to the rapidly changing nature of malicious code. On the other hand, the feature article An Air Force Strategic Vision for 2020-2030 has some very interesting revelations for the computer security field.

In particular, they are very interested in integrating "cyber operations" (hacking) into their battle plans as a component of warfare. For example, this quote from page 12:

Fourth, offensive and defensive cyber capabilities must be fused into air and space platforms. By 2030 cyber capabilities may become the greatest power-projection tools in the Air Force arsenal, serving as both force multipliers and an Achilles’ heel.

Later in the article, the authors address some specific challenges for the US military in computer security, including a lack of trained personnel. However, I think the really interesting bit is here:

In the future, cyber will evolve into a weapon of preference, replacing many of the kinetic choices in today’s arsenal. The reduction in aircraft numbers and the ranges required for power projection, particularly in the Pacific, will drive cyberspace to the forefront of Air Force operations. Suppression of enemy air defenses and the ability to corrupt the software of an adversary’s aircraft will become a reality, not just science fiction.

At first glance, the idea of an Air Force aircraft that can hack targets seems like a futuristic daydream, but in actuality it's not as bizarre as one might think. Take a look at the WiFi Arial Surveillance Platform (WASP), a WiFi-hacking UAV that was built by a couple of enthusiasts in their garage. Take a look at it's capabilities:

the operator can "control the payload from anywhere in the world -- including mobile devices. It also allows for processor-intensive applications, such as WPA attacks and password cracking, to be offloaded securely in real-time to a remote computing powerhouse utilizing CUDA technology, for mind-blowing performance."

This is just a WiFi penetrator, but the possibilities of what Boeing or Lockheed could do with their gigantic budgets is mind-boggling. Fortunately, we don't have to imagine what it might look like. It's already here in the Next Generation Jammer (found via Wired.com)

For military targets, the hacker of tomorrow could be an F/A-18 Growler.

(Public domain Growler image obtained from Wikipedia)

The Aviation Week article is obviously short on details, but if air defense systems use wireless connections to launch their missiles then they would obviously be vulnerable to disruption. There's some evidence that this has actually been done in combat by Israel as early as 2007. More details on Israel's airstrike on Syria can be found here.

This doesn't mean much for civilian computer security folks yet (except for defense contractors), but military technology has a way of working its way down to other uses, such as law enforcement, corporate or criminal. We'll have to wait and see what the future brings, and in the meantime it's simply amazing to know it's possible and actually being done.

On the Internet, you're not as anonymous as you think you are

2011-03-04T10:00:00.000-08:00

One of the big issues with computer crime is the belief that because the internet is anonymous, the criminals will never be identified. A recent intellectual property case shows that's not always the case. Despite the user creating the site with a pseudonym and PO box, the government was able to track it back to the real person involved.

It's unusual for us to get this clear of a view about how a person can be tracked across the internet. The exact methods used here by the government require the cooperation of the ISPs involved, but it would theoretically be possible to accomplish the same thing by hacking or using social networking connections.

Because internet anonymity is only skin-deep I try to act as if everything I post online is under my real name. I suggest everyone do the same.

McAfee on security

2011-02-23T13:47:00.000-08:00

This past week was the RSA conference, and I was able to attend the keynotes on Thursday. McAfee's CTO, George Kurtz gave a keynote talk entitled "Driving Security Down the Stack" (preview here, full video of all keynotes here).

The "stack" that Mr. Kurtz' talk title refers to isn't one of the standard definitions of "stack" that I'm used to, his "stack" is this:

Applications
Operating system
Hypervisor
Silicon (hardware)

He was arguing that instead of running security applications on top of this stack, it should move downward. This push is in no small part due to the fact that last August, Intel purchased McAfee to build security features deeper in computing systems. After all, hackers and malware authors are attempting to do the same thing, penetrate deeply into this computing stack to hide from security applications and to have more complete control over the system. For example, rootkits install at the OS or hypervisor level.

Despite having such an ambitious talk title, Mr. Kurtz spent most of his time arguing that we should drive security deeper into the stack and very little time arguing how to accomplish it. The closest he came to addressing it was something he called "roots of trust" that would establish "trusted columns" through the stack to have areas of computing that could be malware-free. Since Mr. Kurtz said nothing about how this would work, the audience simply has to imagine how this could work.

Quite frankly, I can't figure this one out.

Modern computer software is highly complex with many millions of lines of code and the bugs that go with them. Modern malware is already highly adept at leveraging these bugs to move horizontally (from application to application or from one part of the OS to another) and vertically (from application to OS to hypervisor). Mr. Kurtz and I agree that the traditional antivirus blacklisting methods are ineffective, but without any kind of blacklist then how exactly does his "root of trust" determine that the parts of the operating system it relies on haven't been compromised? Or the application? Or the hypervisor? The only part of the stack that approaches a "known good" is the hardware, and I can't think of any way to insert security rules into the silicon that would be comprehensive enough to be effective yet flexible enough to handle the wide range of possible software over the life of the chip.

Modern chips already have some security features installed. Back in 2004 (six years ago already?) most hardware began shipping with the Trusted Computing Group's "Trusted Computing" technology, which uses hardware cryptography to allow the operating system to exert control over applications. This technology has been present in Windows since Vista, but in addition to extensive privacy and security concerns, Trusted Computing hasn't even appreciably slowed the spread of malware.

Don't get me wrong, I'm not saying that Intel/McAfee's "hardware security" efforts are doomed, but they won't be the panacea that Mr. Kurtz's talk claimed they would be. It's just another step in the computer security arms race.

Security B-sides

2011-02-15T21:09:00.000-08:00

This week is RSA, when thousands of computer security folks converge on San Francisco to talk shop. RSA has changed a lot over it's 20 year history, from a small gathering of cryptographers in a motel chatting about the latest crypto algorithms to paying up to this year paying up to $2,195 to listen to high-level presenters talking about the issues of the day. For those of us who aren't managerial types, there are "expo passes" available so we can get in the building and talk to the assorted sales reps.

Things have changed a lot from those early days, and to try and recapture some of that "small group of people chatting about their experience" feeling, groups of volunteers have started smaller "anti-cons" called B-sides. This year was my first year attending a Security B-Side conference, and I highly recommend it. There were a variety of interesting and entertaining talks about everything from low-level techie stuff like reversing Android applications to building incident management policies and "Attacking Cyber Security Marketecture". Everything was based on real personal experience at a variety of detail levels, which in my opinion was perfect. Best of all, it was free, thanks to the generosity of the sponsors.

For more opinions on B-sides, check out all the commentary on the internet and on twitter. If you're in the area or have any excuse to be in the area, I highly recommend attending next year.

How hackers can use your computer to make money

2011-02-07T13:44:00.000-08:00

When I'm talking to people outside of the computer security community, I usually find that people aren't aware of the reasons that modern hackers commit the crimes they do. Today, I found a great post on ThreatPost (a blog by the antivirus company Kaspersky) called "Inside the Business of Malware" that gives a infographic that summarizes of some of the ways that malware authors can abuse your computer for their profit (image created by graphic designer Jess Bachman.

On Piracy

2011-01-26T13:14:00.000-08:00

The government, entertainment and software industries have each put a lot of time and effort into combatting copyright infringement, including software piracy. So far, most of the public relations effort I've seen has been focused around either trying to shame people into not pirating software, or trying to scare people with the legal consequences of piracy.

So far, neither method has been effective. Shame is not effective because public opinion is that despite piracy, the victim corporations are still making tons of money. A combination of high prices, high corporate profits and the fact that corporations are faceless entities prevents people from empathising with their position. To date, fear has not been effective because the number of people sued or prosecuted for software piracy is incredibly low. People (correctly) see that they can get away with it as long as they're not major distributors. However, this viewpoint may change if law enforcement is able to exert more resources against software piracy.

Personally, I think a better approach would be to show people how they can be harmed by software piracy. Any time you place a program on your computer, you are entrusting your hardware and your data to not be abused by the program you're downloading. That's fine when it's a corporation providing you with the data because there are consequences (lawsuits, bad PR) if they provide malware in their software. However, you have no such guarantee when downloading software from warez websites or peer-to-peer applications like BitTorrent. Macs and even "jailbroken" iPhones have been virus infected by pirated software.

Pirating an OS is even worse, as a pirated OS is generally not eligable for security updates, leaving it vulnerable to hacking or virus infection. That is one likely reason that China has such a high proportion of hacked computers.

Although it's currently very unlikely that any given software pirate will be arrested, it's far more likely that their computer will be taken over and used for malicious purposes. I think if people were more aware of that fact, it might actually make a difference in the amount of software piracy.

What is computer security

2011-01-19T10:16:00.000-08:00

This morning a friend of mine tweeted about a good definition of security that he ran across. Read the article for more explanation and details, but the essential definition is that security is:

Security is the process of maintaining an acceptable level of perceived risk.

I really like this definition because it's simple and easy to comprehend, but it also accurately portrays several nuances that are frequently missed in discussions about security by both security people and non-security people.

Security is a process. Security isn't something that you set up and you're done, it's an ongoing process. You have to keep aware of current and upcoming threats, new vulnerabilities and new mitigation techniques. As bugs are found in software, you have to patch them. As employees come and go, you need to grant and remove their access diligently. These are just some examples of the process of security.
Acceptable level of risk. Security (computer or physical) isn't about eliminating risk. That's impossible. It's about managing risks to an acceptable level. Things that need to be considered are how expensive is the security device/policy? What barriers does it add to normal operations? How likely is the threat, and what amount of damage can be expected from it? How much security is worth it?
Percieved risk. We're not omnicient. Security people, managers, employees and customers have to make our best judgements about what the risks are, how dangerous they are and how likely they are. The fact that humans in general are rather poor at estimating risks is why we spend billions on airport security and very little on preventing traffic collisions. Several books have been written about this issue.

I think a better understanding of what security means would do much to improve security decision-making in general.

Forgot your password?

2011-01-17T10:48:00.000-08:00

It seems like more and more frequently, articles about email and Facebook hijackings appear in the news. Although the news frequently calls them "hacking", the actual method tends to be either guessing the password or abusing the "security questions" in the password reset feature. If you're not concerned about this, you don't understand the potential consequences of losing access to your email. George Bronk, the extortionist in this case, searched his victim's email accounts for nude pictures and videos. He sent what he found to the victim's friends and frequently attempted to extort the victim further. He also utilized his control over the victim's email accounts to gain control over their Facebook. Had he been more interested in monetary gain, he could have just as easily used the password reset feature for the victim's bank accounts to clean them out financially too.

Incidentally, this was the same method used by David Kernell to gain access to Sarah Palin's email account.

So, what can you do to prevent something like this? The article above provides some suggestions about false password reset answers ... but that poses problems of their own. If you provide false information for your password reset questions, you need to make certain you can remember the answers when you actually need to use them. If the account allows you to create your own password reset questions, that might help you make answers that are memorable to you and difficult to discover.

Another suggestion is to keep your social networking (Facebook, MySpace) privacy settings under tight control, and be careful what you share on them and who you "friend". Remember, friends can usually see more of your profile than people who aren't friends.

A fun exercise is to try thinking like a hacker ... logout of your Facebook (so you can only see the public profile) and then see if you can find out enough information on yourself to answer your own password reset questions. Pretend you don't know anything about yourself, can you break into your Facebook? Your email? Can you find out what bank you use and get into that?

Do you have any additional suggestions? If so, please comment. I'd love to hear them.

Quick update to "Cablegate"

2011-01-04T16:42:00.000-08:00

In my last post on "Cablegate", I suggested that the reason so many cables were able to be accessed by Bradley Manning was because of the desire to improve information-sharing after the attacks of September 2001. At the time that was speculation on my part, but a new article in the Washington Post shows that this is correct.

From the article:

Investigations into the attacks concluded that government agencies had failed to share critical information that could have helped uncover the Sept. 11 plot. Because of that lapse, Congress tasked the Office of the Director of National Intelligence with pressuring key government agencies - including the Pentagon, the Homeland Security Department and the State Department - to find ways to rapidly share information that could be relevant to possible terrorist plots and other threats.

The State Department, with its hundreds of diplomatic posts worldwide, was already making tens of thousands of classified cables available to intelligence and military officials with secret security clearances. But in 2005, the DNI and the Defense Department agreed to pay for a new State Department computer database that could allow the agency's cables to flow more easily to other users throughout the federal government.

"It was consistent with the concept of needing to share information after September 11th," said State Department spokesman P.J. Crowley. "We were asked to do it, and the Pentagon paid for it."

The article also describes the limited safeguards present on this system that directly allowed Manning to steal the documents.

A few State Department officials expressed early concerns about unauthorized access to the database, but these worries mostly involved threats to individual privacy, department officials said. In practice, agency officials relied on the end-users of the data - mostly military and intelligence personnel - to guard against abuse.

The department was not equipped to assign individual passwords or perform independent scrutiny over the hundreds of thousands of users authorized by the Pentagon to use the database, said Kennedy, the undersecretary of state.

"It is the responsibility of the receiving agency to ensure that the information is handled, stored and processed in accordance with U.S. government procedures," he said.

To prevent illegal intrusion, the State Department has long maintained safeguards that make it difficult for an individual to download sensitive information onto a portable device such as a flash drive or compact disc. But Kennedy acknowledged that the department had no means of overseeing practices by other agencies using its data.

U.S. investigators suspect that Bradley Manning, an Army private stationed in the Persian Gulf, downloaded the 250,000 State Department cables to compact discs from a computer terminal in Kuwait. He then allegedly provided the files to WikiLeaks, which shared them with newspapers and posted hundreds of them online.

There you have it. The rush to share information after September 2001 lead to poor logging and auditing of access to data and placed great trust in the users to not betray the government. Mr. Manning betrayed that trust.

I'll Be Pwned For Christmas

2010-12-21T15:10:00.000-08:00

I'll be pwned for Christmas
You can count on me
Please have bots and viruses
And exploits for me

When talking to people about viruses and infections, I've found that many people are confused about how virus infections happen. By now most people realize that files you download can be viruses, but hackers have found ways to circumvent people's caution. First, the virus can be disguised as something else - such as an update to Flash Player - to trick people into trusting it. Second, a malicious website can utilize a vulnerability in your browser to secretly download and execute the virus. This is called a drive-by download, and some believe these types of attacks are responsible for most virus infections. This is one of several reasons why it's important to keep your computer up to date with the latest patches. Your browser, operating system, PDF viewer (usually Acrobat), Flash player, and Java (if you have it) all need to be kept up to date because each of them can contain vulnerabilities that can be exploited to gain control (pwn) your computer.

There are several goals a hacker might have for infecting your computer, but fundamentally a computer is a resource to exploit. Modern malware, particularly botnets, are becoming very sophisticated. If Zeus (Zbot) infects your system, it can modify webpages you visit to post it's own ads, intercept website credentials (including bank accounts) and send them to the hackers, steal documents, send spam email, turn off your antivirus, install additional viruses, track your keystrokes, and grant full control over your computer ... all from a file as small as 270 kb.

With millions of dollars per year at stake, it's no wonder that virus authors will do whatever they can in order to infect you. Among other techniques, one method is by referencing current events in their spam, or building sites which are specifically designed to appear at the top of search results for key topics of the moment. This time of year, that includes using holiday greetings to infect you and using websites that appear at the top of searches for holiday terms.

What can I do about it?

Get good antivirus protection. Use an up-to-date browser. Not only are modern browsers more secure, newer versions include protection against malicious links. Use good spam protection. Keep your OS updated, and if you're still running Windows XP it's time to move up. Always, always think before you click.

Tracking cyber criminals

2010-12-13T13:14:00.000-08:00

Whenever there's a cyber attack, one of the most natural questions is "who is behind it"? That's a critical question to answer so that you can determine the reason for the attack and the damage that's done. For example, if your intellectual property is stolen by a competitor, the risks are much greater than if they were stolen by an amateur hacker just poking around. Both are dangerous, of course, but one is much more dangerous than the other.

Not all cyber attacks are equal, some are relatively straightforward to attribute, some are far more difficult and may be impossible. For example, take a standard Denial of Service (DoS) or Distributed Denial of Service (DDoS) attack, such as the ongoing attack by Wikileaks supporters against organizations that they percieve as censoring Wikileaks. They have been using a free utility called Low-Orbit Ion Cannon (LOIC), which is a tool designed for stress-testing websites (seeing how they perform under load). Since LOIC is intended as a testing - not criminal - tool, it does not have anonymization features built in. That means if the user does not take action to disguise themselves, it is trivial to track them down. A couple people associated with these attacks have already been arrested for this exact reason.

To understand how this happens, let me explain a little about how the Internet works. Over the years, there's been significant discussion about IP addresses. IP addresses are part of the internet protocol and they function to direct traffic to and from their destination. When you type a URL into your browser's address bar and hit enter, your computer contacts a Domain Name Server (DNS) to translate the human-friendly domain name into the server's IP address. It contacts that server to initiate a TCP/IP connection, and if that's successful it sends the request for the webpage. All communication from your computer to computers on local networks or the internet is sent as packets, which contain information such as the destination IP address, your IP address (so the computer knows who to send the replies to), the item (such as a webpage) requested, and other information not relevant to this discussion. If you're using your home computer your IP address is provided by your ISP and if your IP address is implicated in a crime then law enforcement can contact your ISP to get your information.

Now, for a DoS attack, there are several options that criminals can use to cover their tracks. If they use a cybercafe or open wireless access point, they can launch their attacks from there. Then, the return IP address will be the one belonging to the business they're using. However, this isn't perfect. If the business records the names of their internet users, then it's no more anonymous than using your home computer. Still, a wireless access point will record information about your computer (computer name and the MAC address of your network card) in order to successfully route the webpages back to your computer. That may allow tracking you back to your computer.

However, that just catches the ignorant criminals. Skilled criminals will build or rent a botnet to commit a DDoS attack. These attacks utilize computers that the hackers take over with viruses that the victims unintentionally downloaded. Skilled law enforcement officials can sometimes track down the hackers involved. I don't know the methods involved, but since most successful investigations I've heard about were with hackers in Western nations, I expect it relies on cooperative ISPs. Other criminals will utilize anonymization services to commit a DDoS attack, such as TOR. One interesting DoS method I've heard of involves forging your IP address. Since an attacker in a DoS attack doesn't actually need the webpage directed back to him, he can change his IP address to someone else's. For example, in a reflected DDoS attack, an attacker will send an "Echo" request to a network broadcast address. Essentially, this is asking every computer on a network to reply with an "Echo" packet, used to test connectivity. However, if you forge IP on the "Echo" request to your victim's IP address, the entire network will be sending their replies to your victim computer. This particular attack has been around for a while, so most networks have changed their configuration to prevent it. Still, it's an excellent example of how attackers will try and cover their tracks.

Botnets pose significant issues for determining the origins of an attack, as the computers that are actively attacking are under the control of assorted "Command and Control" servers, which are likely not even directly owned by the hackers. The control servers can be IRC bots, Twitter accounts, blogs, webmail accounts and/or Google groups. It can even be a rented "virtual computer" on a system like Amazon's EC2 cloud servers. Modern botnets have multiple redundant control servers, so when the primary set are taken down, secondary servers pop up. Many of these avenues can be set up anonymously, making it difficult or impossible to trace back to the original hackers. "Shadows in the Cloud" is an excellent example of a detailed analysis of a botnet. Even though the security researchers took the place of a command and control server and accessed the hacker's email addresses, they were only able to pin down the location of the servers to a particular location in China. This only provides circumstantial evidence of who is responsible for the attack. If the Chinese government and/or ISPs were to cooperate with Western law enforcement, it's possible that we might be able to prove who was responsible, but that cooperation seems exceedingly unlikely.

Determining who is responsible for an attack is a complex and thorny issue, but I've tried to briefly outline some of the complexities. If you'd like to know more about particular elements or take issue with some of my claims, post to the comments.

How "Cablegate" Happened and What It Can Teach Us About Information Security

2010-12-07T16:35:00.000-08:00

A lot of digital ink has been spilled about Bradley Manning's disclosure of Iraq War memos and now the classified diplomatic cables known as "Cablegate". Much of it has focused on Wikileaks - the site Manning chose to disclose the information to - or the content of the leaked information. However, much more interesting in my opinion, is the unusual policies that allowed this to happen.

Gary Warner, the author of the excellent blog "CyberCrime & Doing Time" recently wrote an excellent article about the flaws inherent in allowing Manning unfettered and unlogged access to virtually everything that he was cleared for. Essentially, this is one major reason that organizations should restrict access only to those who have a legitimate need for access. Not only does it limit the amount of damage that a disgruntled employee can do, but it also limits the amount of damage that can be done if an account is hijacked by a hacker or malware.

This is an inherent difficulty in information security: how do you draw the line between too restrictive and too generous permissions? Manning was an intelligence analyst in Iraq, so he needed access to a wide range of information in order to do his job. In addition to reports from Iraq itself, there might be Iraq-related discussion coming out of Afghanistan, or from diplomatic discussions between the US and Iraq, or from the US and other countries. These are just a few examples of why Manning might have had a need for access to a wide variety of data.

Despite the possible justification for access, it makes me wonder why the US Government allowed Manning to access virtually everything. I have no evidence (at the time of this writing), but I strongly suspect it's due to the events of September 11, 2001 and the recommendations of the National Commission on Terrorist Attacks Upon the United States (aka "the 9/11 Commision"). Among other issues, the Commission criticized the lack of connection between individual intelligence agents and national priorities and the lack of communication between intelligence agencies, including the military intelligence agencies. It's possible the government's response to the Commission's report included removing all significant "need to know" restrictions, while leaving in place the basic "classification" restrictions.

(UPDATE: This suspicion has now been confirmed by the Washington Post)

It's not my place to determine whether or not that decision was justified, but it's certain that allowing Manning access to everything drastically increased the damage caused by his breach. Access policies are just one aspect of information security, the other aspect is auditing (logging). Wired.com quotes Manning as writing:

“I would come in with music on a CD-RW labeled with something like ‘Lady Gaga,’ erase the music then write a compressed split file,” he wrote. “No one suspected a thing and, odds are, they never will.”

“[I] listened and lip-synced to Lady Gaga’s ‘Telephone’ while exfiltrating possibly the largest data spillage in American history,” he added later. ”Weak servers, weak logging, weak physical security, weak counter-intelligence, inattentive signal analysis … a perfect storm.”

Manning directly admits that weak (or absent) logging procedures directly contributed to his ability to remove information. Logging could have generated a digital trail of his activities (both accessing data and burning it to disk). A good SIEM software could have managed the logs and automatically alerted the appropriate manager or authority that Manning was doing something he shouldn't have been.

Just like I talked about in my blog about airport security, effective prevention, tracking and mitigation efforts all need to be combined into a coherent policy to handle damaging attacks like the US Government has recently suffered at the hands of Bradley Manning.

What computer security and airport security have in common

2010-11-29T14:55:00.000-08:00

Like many others out there, my wife and I took a plane to visit family for Thanksgiving. In fact, due to a work travel obligation I had to take four flights in the past two weeks, which is about what I usually fly in a year. That means four trips through airport security, although I managed to avoid the x-ray naked body scanners each time. My wife had to opt-out on our return from Thanksgiving (luckily, the screeners we encountered were professional), although others have not been so fortunate. You can request a private room to prevent that sort of abuse.

There are potential health risks. In particular, I want to know what safeguards there are for misconfigured backscatter machines. TSA claims that when the machines function normally there is minimal risk, but sometimes machines malfunction or are misconfigured due to poor training and TSA is already known to have poor training standards. There are the obvious privacy losses associated with naked pictures being taken of travellers. TSA assures us that the images will never be saved or made public, but that promise has been broken once already by the US Marshalls. I for one don't trust that it won't happen again.

However, these issues are specific to airport security and the naked scanners in particular. The bigger problem in my mind is that this continues to provide a static defense against a particular type of problem. Like the French Maginot line, TSA checkpoints have become an elaborate but static defense designed to prevent the types of invasions that have come in the recent past. Like the Maginot line, the attackers see that we're currently obsessed with one particular avenue of approach and are starting to switch tactics to bypass them. Bruce Schneier recently wrote a consice summary of the airport problem:

A short history of airport security: We screen for guns and bombs, so the terrorists use box cutters. We confiscate box cutters and corkscrews, so they put explosives in their sneakers. We screen footwear, so they try to use liquids. We confiscate liquids, so they put PETN bombs in their underwear. We roll out full-body scanners, even though they wouldn’t have caught the Underwear Bomber, so they put a bomb in a printer cartridge. We ban printer cartridges over 16 ounces — the level of magical thinking here is amazing — and they’re going to do something else.

This is a stupid game, and we should stop playing it.

The same problem exists in modern computer security. So much attention both on the corporate and personal level is focused on the firewall, trying to block people from entering the network. It's the same situation as on an airplane, just replace luggage searches with packet inspection and no-fly lists with port blocking. As long as airport and computer security is entirely focused on preventing intrusions at the border, it will fail. When we realize we need to also have measures in place to respond to intrusions, we can begin to detect attackers early and prevent damage from being done. This is how both Richard Reid and Umar Farouk Abdulmutallab were stopped after TSA failed. Note, no Air Marshalls were on their flights, these attackers were stopped by the random passengers that were nearby.

That's stopping people at the last minute, though. Like any crime, there's a process of deciding to attack, identifying a target, reconnaissance, positioning, attacking, and response. That link refers mostly to violent crime, but with some modifications it applies to burglary or hacking as well. Having an adaptable security procedures and a responsive law enforcement presence that is able to take proactive measures to disrupt criminal or terrorist gangs will massively improve safety, far more than naked body scanners ever could hope to.

But that brings me to the final common element between computer and airport security. Safety is not something you HAVE. It's something you WORK TOWARDS. There's no way to be perfectly safe/secure. There's no way to stop every attack. Hacker-proof, burglar-proof or terrorist-proof only exists for politicians and salespeople, in the real world there is always risk. All we can do is prevent what we can and minimize the damage from what we can't.

Agree with my post? Disagree completely? Share your thoughts, post a comment.

Facebook's most recent privacy controversy

2010-10-19T14:01:00.000-07:00

I was listening to the radio this morning and heard an interesting discussion of Facebook's most recent privacy issue (first reported by the Wall Street Journal). I follow Graham Cluley's blog so I was completely not surprised to learn that the source of this privacy leak (it's nowhere near big enough to be a "breach") was Facebook applications. However, I was surprised to learn that they weren't talking about the genuinely malicious applications out there. Instead, this is what the WSJ was concerned about:

The information being transmitted is one of Facebook's basic building blocks: the unique "Facebook ID" number assigned to every user on the site. Since a Facebook user ID is a public part of any Facebook profile, anyone can use an ID number to look up a person's name, using a standard Web browser, even if that person has set all of his or her Facebook information to be private

Ok, so what's the concern here? It's just the number that uniquely identifies your Facebook profile, plus the information you've marked Public and the information that you specifically authorize the application to collect. If you don't read that page that comes up every time you try and add an app, you should.

This is really nothing new. It's amazing to me that people look at these free apps and don't bother thinking about what what the app developer stands to gain from this. It all goes back to what our parents should have taught us back in elementary school, nothing in life is free. The best modern phrasing I've seen about this is "If you are not paying for it, you're not the customer; you're the product being sold." - Blue Beetle. Facebook (and their apps) and Google both buy our personal information with fun toys and features. They purchase our information because it's valuable to advertisers.

If you're aware of this, you can make an intelligent decision about whether or not you really want to play MafiaWars or FarmVille. Is that toy adequate payment for the information they're asking for in exchange? If so, go right ahead and play that game knowing what you're exchanging. If not, then don't.

The much bigger issue, in my opinion, are the genuinely malicious Facebook apps, the ones that post spam to your wall, or persuade you to fill out surveys for them. They're fundamentally dishonest about what they're doing, and impersonating the user to spread their spam.

Computer security is everyone's responsibility

2010-10-07T16:15:00.000-07:00

Computer security is like physical security. If any of us create a vulnerability, we're all vulnerable. It's like the college dorms, if you prop the door open or leave a window open, someone can use that vulnerability to steal from me. The same is true with computers, although the situation is massively amplified because someone can use your computer plus several thousand or million others in a botnet to attack my computer or company. As a result, we're all in the security game together. I may have better security than you, and the NSA may have much better security than me, but you can help keep us all a little safer by improving your computer's security.

There are lots of sites out there that have good advice for aspects of computer security. Many of them are targeted for techies or highly computer-savvy people. However, I've just found a site called Securing Our eCity which provides advice and presentations for both families and businesses about computer security basics and current topics like some of the recent social networking viruses and online bullying. If you have an interest in computer security (and if you're reading this blog, you probably do), take a look and see what you think. Share it with your friends to let them know how they can stay safe online. If we all help each other, we can make the internet a safer place.

Cybercrime and law enforcement priorities

2010-10-05T12:27:00.000-07:00

With all of the stories in the news these days about Stuxnet, the ZeuS botnet, spam, identity theft, cyberwar, the US Cyber Command, and hackers, it's easy to believe that cybercrime and computer security is a high priority for the US government.

However, a new analysis from Gary Warner with the CyberCrime & Doing Time blog claims that although cyber crime should be a high priority for US law enforcement, it's not. He points out that despite the fact that cyber crimes are escalating dramatically, the FBI's budget is only increasing by 4%, creating only 347 new agent positions over the 2010 fiscal year. There's only a 5.5% increase for the US Attorney's offices, which would of course be responsible for prosecuting the criminals that the FBI catches.

Officially, cyber crime is the FBI's third priority, behind terrorism and counterintelligence. However, Mr. Warner points out that 51% of the FBI's budget is for counterterrorism. Coming in at a distant second is major thefts/violent crime at 14.8% and third is "combat public and corporate corruption, fraud, economic crime, and cybercrime". Obviously, the FBI's budgetary priorities don't match their stated goals.

The 2011 FY budget (October 2010-September 2011) shows some steps in the right direction. They requested an increase of 163 positions for Computer Intrusions (63 agents and 46 analysts) and only 90 new positions for National Security Threats. This isn't to say that national security issues are unimportant ... far from it! It's that cybercrime isn't given a big enough balance of the FBI's attention, and this will work towards correcting that imbalance. After all, the FBI claims that in Fiscal Year 2008 (2009 was not complete when the report came out), out of 3,974 computer intrusion cases received, there were only 31 "priority" investigations successfully "satisfied" (the FBI's term, I don't know how they define them), resulting in 126 convictions/pre-trial diversion. Granted, some of these cases will be unable to result in convictions because many hackers reside outside the country, but this week's arrests of computer fraudsters in the US, Russia, the UK and Ukraine show that with good international cooperation these thieves can be brought to justice.

Although these arrests are excellent progress, it's sobering to note that the 2010 Verizon/Secret Service Data Breach Investigations report shows that in 2009, the Secret Service added another 84 cases from 2009, for a total of 4,058 computer intrusion cases that got the attention of federal law enforcement (although it's possible that some of the FBI's cases are also in the Secret Service's report, I'm being optimistic). Also in 2009, the Internet Crime Complaint Center reported that 336,655 internet crime complaints and only half of them were referred to law enforcement for action. Obviously, we have no way of knowing how many breaches there were total, as many are never reported or even discovered. Also, the FBI statistic refers to only computer intrusions and the Secret Service statistic refers only to data breaches, so they're not equivalent figures. Still, it seems clear that the FBI is under-equipped to deal with the vast amount of cybercrime out there today.

The FBI's cyber division and other federal cyber law enforcement agencies do excellent work fighting cybercrime, but without better support and budgets, they can't really cut down the amount of theft going on out there. Far more people are victims of cyber crime than terrorism, yet terrorism always gets the media and political attention and the budgets that go along with it. I feel we need to better support the FBI's cyber division to fight back against these hackers. What do you say, readers? What's your opinion on the topic?

Full disclosure: I have applied for the FBI and would like to work in their cyber division.

Cyberwar, revisited

2010-09-26T23:28:00.000-07:00

When I started this blog just two months ago, the news was all about "cyberwar" and the threats of it. I posted my take on the issue, which was essentially that although espionage happened, there wasn't really much that would be considered "war".

That was before the worm called Stuxnet hit the news (although after the main infection hit). Stuxnet (officially W32.Stuxnet) is a type of malware that is unique for a number of reasons, not the least in that it's the first known malware to infect SCADA systems. It's rather versatile as well, possessing the ability to exfiltrate data (send confidential info back to the hackers), hide itself in the Windows operating system, and insert new code into the systems so that the hacker can change the operations of the system. Interestingly, it injects the code in such a way that the new code is hidden from people who examine the infected system. Stuxnet exploits several different zero-day vulnerabilities, which in itself is quite unusual. A vulnerability is most effective before it's discovered and patched, so to "waste" four vulnerabilities on one virus is quite uncommon. On top of that, the hackers who wrote the virus stole two digital certificates and used them to sign the virus, so that Windows would trust that the virus came from a legitimate company. The virus contacted two command and control servers to obtain updates and instructions, but it also had a peer-to-peer (p2p) update scheme as a backup.

All of this leads several leading virus researchers to believe this was created by an organization with a large degree of technical skill, time, and money. Many believe it was created by a government intelligence agency. The fact that in the first couple days 59% of infections were in Iran further encourages the belief that it was an intelligence operation against a particular industrial facility in that country, perhaps the Bushehr nuclear reactor or perhaps the Natanz nuclear enrichment facility. The Natanz facility was built 8 meters underground and protected by reinforced concrete, likely to protect it against threatened airstrikes. Since the facility is very difficult to attack by conventional means, it's tempting to believe that this was the target of Stuxnet, and it's tempting to believe that Stuxnet may have been an Israeli intelligence operation. However, we'll likely never know for sure. Even if the perpetrators step forward and admit what they were doing (and the odds of that are nil), we'd have no way to verify it.

Either way, the fact that Stuxnet exists is proof that cyber sabotage is indeed possible. Two months after the beginning of the attack, we still no proof as to who was responsible for it, only guesses. To me, that's the more frightening part. With all conventional weapons, it's relatively easy to determine who is responsible for an attack. Even in the case of terrorism, with some investigation it's possible to prove who should be held accountable for their actions. With viruses, sometimes it's possible but much of the time it's not. Obviously, only time will tell if the creators of Stuxnet will be held accountable for their actions, but if they're never identified then I don't think there can be an effective arms control for "cyberwar"

What do you think?

On trust

2010-09-13T11:27:00.000-07:00

Computer security is a complex and continually changing field, but there are a few elements that keep cropping up. One in particular is that with increasing security measures in software, hackers and virus writers are increasingly using psychology to convince a system's user to bypass security for them. Much like an old-fashioned con-man or fraudster will persuade a user to give them access to their home or bank account, many modern viruses and hacking attempts utilize social engineering to spread viruses. By either impersonating someone you may know or stealing and using their account, hackers may try to get you to open a file or click on a link they send you. This gives them control of your computer for their nefarious ends and allows them to use your accounts (email, facebook, twitter, and others) to infect your friends. There are numerous examples of this in the wild right now, and in particular one of my friends recently fell victim to some variation of one of these. No matter where you are, always be careful of what you click, always run an up-to-date antivirus software, keep your software up to date (particularly Windows and Adobe Acrobat), and always pay attention to possible warning signs of infection (not being able to go to certain websites, antivirus being disabled).

It's not just your friends that hackers and scammers impersonate to get you to trust them. Particularly if you work on sensitive material (such as military or other government matters), there are quite a few attacks out there impersonating government officials to spread viruses or steal money. The FBI's "E-Scams and Warnings" page currently has a long list of attacks impersonating government officials.

The only way to protect yourself against these sorts of attacks is to be suspicious of any email that comes into your inbox and any page you view on the internet. Just because something claims to be from a particular source doesn't mean that's really where it comes from. Learn to identify malicious email and stay safe out there. Don't worry, if you've fallen for one of these scams, here is some advice of how to recover. Also, I strongly urge everyone to report these scams to the Internet Crime Complaint Center (http://www.ic3.gov).

The Internet is a dangerous place, but we can all do our part to keep it a bit safer.

On protectionism, security, and international politics

2010-08-30T16:03:00.000-07:00

In the news recently, there's been quite a bit of fear about hacking and data theft sponsored by foreign governments (usually China, but there's been some fear about North Korea and other nations as well). Here's an example that may or may not have been connected to a foreign intelligence agency, and here is a more recent information stealing attack on government targets. There's legitimate fear here, governments have wide resources that they can (and likely do employ) for electronic espionage. Foreign and domestic companies are also known to employ industrial espionage (electronic and old-fashioned) to steal valuable data from their competitors. As a result, governments and corporations are beginning to take foreign threats seriously and look at the ways they're vulnerable to foreign threats.

Unfortunately, the major espionage fear (corporate and government) is the same country that provides so much of our hardware and has significant government control over their corporations ... China. We don't know what they might be putting into the hardware that we buy from them, which is a serious threat.

Although that's perfectly true, China buys lots of software (security software included) from the US. Given that the US and China are global competitors, they have as much to fear from US espionage as we have to fear from theirs. As a result, it was inevitable that China would take action to prevent foreign security software from being used to secure their critical infrastructure. It's perfectly reasonable, and I think this exact concern would prevent Chinese-programmed security software from being widely used in the West.

At the same time, there are some claims of protectionism and fear that China is trying to shut foreign competition out of a major Chinese market. This is also true, favoring local companies clearly goes against "free trade" principles and certainly the Chinese computer security market would hugely benefit from forcing foreign companies out or forcing them to work alongside local Chinese companies.

There's really no easy answer to this one, but really there never seems to be. To keep free trade, you need to allow foreign companies in. To keep security, you need to keep untrusted companies out. China's trying to draw a line here by only banning foreign computer security products from critical infrastructure. They're just as afraid of the US hacking their electrical grid as we are of them hacking ours.

I'm most interested in the parallel reaction to the same threat by our countries. Information security seems to be shaping up into the great leveler of nations. It doesn't matter if your military budget is $880 billion (US), $78 billion (PRC) or the much smaller budget of any other country. To the hacker, we're all vulnerable.

But that's just my opinion, I could be wrong. What do you think, is China overreacting? Do you think the situation with China is fundamentally different than the situation in the US?

On the intersection between politics, law, and computer security

2010-08-26T14:21:00.000-07:00

One major annoyance on the internet is spam. Much of the spam that's out there are either phishing emails (attempts to get users to divulge sensitive information), viruses, or pharmaceutical advertisements. Now, the White House is calling a meeting with the top internet domain registrars (the companies that sell domain names (such as http://www.google.com) to companies. If Obama can get the major registrars to stop selling domain names to criminal organizations like these rogue pharma companies (which sell fake drugs for cheap), it would do much to cut down on their profits and thus the amount of spam they can pay people to send on their behalf. This would cut down the amount of spam sent and the amount of hacking being done in order to subvert mail servers to send out spam.

Based on the email that Brian Krebs posted, it seems that they're only talking about voluntary measures so far. Obviously, voluntary measures are only effective when everyone ignores the money that can be gained by violating them. For a current example, see how effective the voluntary safety inspections at egg farms are. These rogue pharma operations seem to be able to toss around a decent amount of money, so I doubt voluntary measures would do more than raise the price of the domain names they register for their illegal businesses.

Still, having such a high-level meeting at all and getting political attention to internet security issues like this one is a major first step. Hopefully it'll eventually lead to global regulations that are effectively enforced with significant punishments for violation. Until then, don't buy drugs advertised in misspelled emails. Seriously, why would anyone buy something advertised like that ... and then swallow it?

And yet, people do. As I'm writing this post, I stumbled across an FBI press release about a Canadian, Hazim Gaber, sentenced to 33 months in prison for selling fake drugs to cancer patients. Although he is Canadian, he was arrested in Germany. The international nature of these internet crimes makes enforcement quite difficult. Interestingly, the press release mentions specifics about his crime. Apparently he was advertising DCA, and experimental cancer drug. He was charging $45.52 for 20 grams, but actually shipping a white powder containing starch and sugars (dextrose or lactose). Absolutely medically useless, and his 65 known victims are incredibly lucky they didn't get something toxic. Good job, FBI.

On the difficulty of preventing identity theft

2010-08-24T18:55:00.000-07:00

A week ago, I was moving to a new house and helping my in-laws move their stuff too. They've run various businesses in the past, which of course creates LOTS of paperwork, including personally identifiable information (PII). Since the business in question has ended, it was time to destroy the data. In the chaos and stress of moving, it would have been easy to accidentally throw the private information out with the regular garbage/recycling. That sort of mistake happens often, and it's one way personal information gets stolen. Information security isn't just a matter of high-tech software and log files, it's also about making sure documents are destroyed properly and people can't look over your shoulder when you're accessing confidential stuff. Preventing loss of data due to dumpster-diving isn't cool, but it's important.

If you're a business (regardless of the size of the business), you're going to generate paperwork. The way you prevent this sort of problem from arising is by creating a clear document policy. Take a page from the government and assign your documents to clear, simple categories. For example, "not private", "internal use only", "secret", etc. Clearly define who can have access to what document type, and make sure anything secret isn't in a location where untrusted people like visitors, janitors or contractors can wander across it.

For any kind of PII, intellectual property or trade secrets, establish how long you need to store it and securely destroy it (shred, incinerate, etc) when it's past the expiration date. If you keep up with your document destruction duties, it won't become an overwhelming pile that you need to destroy right now! That's how mistakes happen and a file/database of bank accounts ends up in the dumpster for some opportunistic thief to steal.

Everyone should have a shredder for this sort of task, but if you're a business you may be better off using a document destruction service. Typically, they leave some sort of locking container for you to place your confidential information into, and collect it at regular intervals.

On the Security Psychology and Ethics

2010-08-03T09:22:00.000-07:00

Good security people, whether physical or cyber, share a common mindset that makes us distinct from most people. Living in society, most people follow the rules of what's considered acceptable behavior and they expect everyone else to do so as well. As a result, much of the time people don't even think about other ways even being possible. It's that blind spot that creates vulnerabilities for criminals to exploit. Good security people are able to look at the rules and assumptions people have about what other people do and say "That's how they're expecting people to act. What if I do this instead?". This allows us to find these vulnerabilities, hopefully before criminals do, and encourage people to close them. Bruce Schneier wrote an excellent article on the subject.

At the California Cyber Challenge camp this year, I was watching a discussion between security people which erupted in an interesting way. One side was arguing in favor of leniency towards criminal hackers, arguing that as long as their crime is motivated by curiosity rather than profit or malice, they can still be turned back to be a productive member of society. The other side was arguing that it's still a crime and they should be punished for their infractions. This is, of course, an old argument that crops up not just in the computer security field, but in the criminal justice system at large. Watching it play out, I realized that there's not just one security mindset, but at least two.

On one side we have the penetration testers, vulnerability researchers, cryptanalysts, and other "offensive security" types. They're good at seeing the vulnerabilities in systems and figuring out how to exploit them, so that other people can fix the vulnerabilities. The people arguing for leniency for "non-malicious" cyber criminals were from this category.

On the other side we have the system administrators, security researchers, intrusion detectors, incident response people, and other "defensive security" types. They're good at detecting and blocking attackers and implementing and enforcing security policy. Forensics people have some of both talents, able to detect and analyze attacks, but also cracking passwords and reverse engineering malware. However, in terms of mindset and ethics, they seem to be more closely aligned with the "defensive" types. The people arguing against the category of "non-malicious" cyber criminals were from this category.

My interests and talents lie on the "defensive" side of the spectrum. Although I can understand how the offensive people may have dabbled in criminal behavior in their youth, fundamentally security positions are powerful. We hold the keys to the integrity of the network. We stand between the criminals and secret data. We need to have very strong ethics and personal integrity, because organized crime is getting involved and may try to corrupt us. In my opinion, once someone starts justifying and using the darker aspects of security, it makes them vulnerable to corruption.

But that's just my opinion, and I'm interested to know what others think.

On the US Cyber Challenge and up-and-coming IT security workers

2010-07-28T13:31:00.000-07:00

Last week, I was one of the fortunate 22 winners of the California Cyber Challenge selected to attend a week-long training camp at Cal Poly Pomona. We had four days of intensive SANS training on exploit writing, Linux security, incident response/penetration testing, and digital forensics. We also had panels on ethics and education, and a job/scholarship mixer. The final day hosted a "capture the flag" event.

All in all, the event was wonderful. Events ran from 9-9, and great conversations with fellow "campers" and the instructors frequently ran until 1 or 2 am. The classes were so intense and packed with information that we frequently came out of them with headaches from the information overload, and more material on our DVDs and in our books to go over in our own time.

One of the really great things about information security in general and the camp in particular is that there are many different specialties a person can get involved in. Penetration testing (testing a company's security), vulnerability research (testing a program's security), reverse-engineering malware (taking apart a virus or other malicious software to see how it works), intrusion detection (watching a system for signs of hacking), and digital forensics (retrieving evidence from computer systems) all require different skill sets and personalities, and that's not even a complete list. I'm still new to computer security and until this camp I wasn't really sure what all the different fields were, what I would enjoy and what I was good at. A varied training camp like the USCC camps introduces the attendees to a variety of different disciplines and the methods required, which lets us discover what we're good at and what we enjoy, while also giving us a better background in the parts that aren't our preference. Learning how to write exploits is useful for determining how a virus works, or tracking down what happened on a system. For me, one of the great virtues of the camp learning for certain that I enjoy computer forensics. Now I can study it in more detail and get work experience for a career.

One aspect of events like the camp and similar security training events that is frequently underestimated is the social networking opportunities. I'm talking about the old-fashioned face-to-face kind, which can be supplemented by the Web 2.0 kind. Not only did I learn a lot from my outside-of-class discussions, but I also made connections that has resulted in me getting some volunteer experience and a team to enter the DC3 forensics challenge.

All in all, the Cyber Challenge camp is a wonderful kick-start for my career, and I'm incredibly grateful I had the opportunity to be a part of the first one.

On "Cyberwar" - Part 2: Cyberattacks and the damage they can do

2010-07-13T22:13:00.000-07:00

Although cyberespionage is a very real threat, it's not exactly the kind of nightmare that you see in Hollywood movies, news articles or defense contract applications. The real question is, what kind of physical damage can a "cyberwar" or "cyberterrorism" do?

Website defacement is a very common cyber "attack", sometimes including using the server to host viruses and malware. Denial-of-service (DoS) attacks can take a website down for a period of time. Both can cause serious damage to a victimized business, but they're not exactly militarily effective. Security expert Bruce Schneier vividly described the threat of DoS attacks like this:

A real-world comparison might be if an army invaded a country, then all got in line in front of people at the DMV so they couldn't renew their licenses. If that's what war looks like in the 21st century, we have little to fear.

In 2007, Estonia's government systems were hit by a major DoS attack. While reporters widely reported it as the first cyberwar, in retrospect this seems to have been hyperbole.

There have been a number of cases of "cyberattack" reported in the media over the past few years, but it's been difficult to tell what's really going on. Computers don't explode or fire bullets, they're just used to control other systems, so any malfunction in any system might possibly be a computer problem ... or deliberate digital sabotage.

For example, The Economist recently reported that in 1982, the CIA tampered with Soviet software to cause a gas pipeline explosion. If true, this would be an excellent example of the physical damage a computer attack could cause (although whether it would be an act of war or an act of sabotage is a matter of opinion). The question is, did that really happen? It's difficult to know for sure. In 2007, Brazil suffered a massive blackout that 60 Minutes ascribed to hackers, but it seems that it was mundane poor maintenance.

This doesn't prove or disprove the possibility of destructive hacking attacks, of course, but it does show that unlike conventional war, in the case of a cyberattack, it's difficult to even determine if you've been attacked, much less who is responsible. This spring, Howard Schmidt was in an interview with Wired Magazine and quite frankly said "There is no cyberwar." and "As for getting into the power grid, I can't see that that's realistic."

At present, the evidence seems to point against computer attacks causing physical damage. However, it seems prudent that we engineer critical systems (such as powerplants) to be resistant to hacking attacks. That way, we can keep this sort of "cyberwar" squarely in Hollywood.

Thanks to Bruce Schneier for extensive discussion of "cyberwar". His analysis and research form much of the basis of my understanding of the concept and underlies these posts.

On "Cyberwar" - Part 1: War and espionage

2010-07-07T14:42:00.000-07:00

Lately, the news has been hyped up about "cyberwar", both offensive and defensive. Many articles have been written about the concept, if it's likely (or not), and even whether or not the term "cyberwar" makes any sense at all.

I'm not a "cyberwar" expert, but all the rhetoric and essays being slung about the topic have convinced me that there really aren't any "experts" in this. Indeed, depending on whose article I read, different people have different opinions on what "cyberwar" is. When it comes to hacking and computer systems, where's the line between espionage, sabotage, and war? It certainly doesn't help that in modern politics and society, the line between the three concepts is being increasingly blurred even before you add in the complication of when it takes place on the Internet.

Traditionally speaking, "war" was considered to be declared combat operations between two (or more) countries, both fielding uniformed armies. Legally, soldiers needed to be uniformed, making it certain whose nation they were acting for (example, Geneva Conventions Articles 37-39, 46, 66 among others). Non-uniformed combatants taking part in war were typically considered spies, mercenaries or illegal combatants. Thus, traditional law establishes that in order to be acting in legal war, combatants on both sides must be positively attributable to the government they're acting for. "Cyberwar" obviously can't fit this definition, as positive attribution is very difficult if not impossible. A "war on terrorism" (or even war on a particular terrorist group) also doesn't fit this definition of war, which leads to further confusion but it beyond the scope of this blog.

Espionage, sabotage and piracy are traditionally considered to be actions taken against a government which may or may not be on behalf of another government. There's a degree of secrecy and deception that's not present in the modern legal definition of war. Espionage is typically considered to be non-violent, stealing information. Cyber-espionage is a real threat, with several clear examples of data stolen from both government and non-government ("corporate espionage") sources. Although this sort of attack would be incredibly useful for government and military uses, the fact that there's no destruction or potential loss of life makes me believe that it is more properly considered a type of espionage.

The real grey area comes when we consider sabotage, attacks that cause interference or damage to data or systems. This is a complex issue, so I'll cover that in it's own post.

Who I am, and what I mean by Renaissance security professional

2010-07-04T16:17:00.000-07:00

The "Renaissance man" is an ideal that's fallen out of favor in modern times. These days, people are expected to be specialists instead of having skill in a range of disciplines. In my opinion, the modern ideal is short-sighted. No person can be effective unless they have skill in several areas, intellectual and social. The people who achieve the most in their lives are those who have diverse skills and interests, such as Ben Franklin.

Although I've always had a diverse set of interests, it was JJ Thompson of Rook Consulting who really showed me how valuable it is to have a broad range of skill for a computer security career, and who coined the term "Renaissance security professional". Computer security needs to be more than just about technology. There is no "magic box" (hardware or software) that will make our networks impenetrable. Computer security professionals need to have an understanding of business so that we can converse with people outside our fields to show them why we're trying to make whatever change we're doing, rather than just trying to use fear, uncertainty and doubt (FUD) to make our arguments. We need to understand psychology and human behavior so that our security policies are realistic, rather than trying to demand people remember impossibly complex passwords without writing them down. An understanding of military history can inform better strategies for network defense. Besides these examples, a broad-based skill set makes one better prepared for whatever comes in life, and makes for a better person.

This is what I intend to do, and this blog will be part of that effort.