Sometimes a burden is worth it.

I just read this legal opinion from Voom about a recent Supreme Court decision. http://www.prweb.com/releases/Justice_Scalia/cybercrime/prweb2620114.htm This quote sums up article fairly well.

In a U.S. Supreme Court ruling handed down last month in the case of Melendez-Diaz v. Massachusetts, the Court held that "certificates" of forensic findings were admitted in error. In a controversial 5 to 4 vote that reversed the judgment of the Massachusetts Appeals Court, the Supreme Court held that admission of notarized forensic analysts' reports violated the defendant's 6th Amendment right to confront witnesses against him under the Confrontation Clause. In the absence of live testimony by forensic analysts, such evidence was precluded.

The Voom analysis indicates that there is a likelihood that this decision will add an undue burden to forensic analysts around the country. The ruling was not limited to "conventional" forensics like what you see on CSI either, it also includes digital forensics. So it is possible that whenever a lab produces a report of its findings, an analyst may have to show up in court to defend it. I would like to go on record saying that I support this decision, and I think that in the long run it may work to REDUCE burden on forensic workers.

A while back I was commenting on whether people should sue PCI QSA's that report incorrect findings, and I said that I think that is a good thing too. The reason is because it protects the integrity of our field. If a QSA has subpar practices they would hopefully be sued out of business and the whole field would be better off. If QSAs ever gained a repution for being expensive people that you can pay to say anything then you would have a couple bad things happen. First a "race to the bottom" with other people coming in and agreeing to say anything for a little less than the last new entry in the QSA field. Followed up quickly with PCI moving away from QSAs in favor of some other group that doesn't have a bad reputation. So while it is burdensome for QSAs to face litigation over their decisions, it is less burdensome than going through a few years of declining profits followed by searching for a new job.

Some of these principles apply in the case of digital forensic work too. I don't think there is anyone in the digital forensics field that would argue with me when I say that the integrity of the profession and the public perception of that integrity is one of the top five most important things to the continued success of the field. How do you gain integrity? By withstanding scrutiny time and time again. Now as it stands today, there isn't a great deal of competition in the digital forensics field. It would be difficult to call up the FBI lab at Quantico, Virginia and pressure them to find evidence that supports your case with the threat that you'll take your business elsewhere. There aren't many other places that you can take your case, but that is quickly changing as the availability of education increases and demand continues to stay high. If we were to bless all of our forensic professionals with the ability to write a report and not have to face cross examination then you would invite less honest people into the field, and eventually for a price you could get someone to say anything. Finally we would reach a place where prosecutors and defendants each show up to court with their notarized certificates from the lab of their choice and both would be worthless. Even if the prosecutor got his certificate from an honest lab, it would be cancelled out by the dishonest report issued by some other lab. The way we deal with that now is through cross examination and if this Supreme Court decision had gone the other way we might have lost that valuable check on our field. And before we get to that place we have people that will be sent to jail because of a report from someone that doesn't have to come to court and face cross examination.

Does this decision add more work for forensics professionals? Yes it does, but probably not as much as you might think at first glance. Quantico deals with a million cases every year, but the vast majority of them do not make it to trial because of plea bargaining. Most of the time, the crime lab will submit a written report and that will be presented to the defense and they will say "let's make a deal." Sure, if even 10% of those cases go to trial you end up with 500 employees having to deal with 100,000 trials. But I think it is less burdensome than allowing the integrity of the profession to rot and then having to deal with the consequences of that. Also, by placing more work on our forensic professionals we will increase demand for more of them, which will lead to higher salaries and more job security. That is also good for the field.

So maybe I'm wrong about this, but I'm not terribly upset with the Supreme Courts decision. If you think I'm wrong, feel free to leave a comment and set me straight.

Pointsec Video Tutorial: Remote Help

Encryption as a tool to deny access to information

Yesterday I blogged about the minor break in AES and what effect this would have on encryption products like Check Point Full Disk Encryption (formerly known as Pointsec). In short, there is not practical effect and the product is still effective at protecting your data.

One of the things I talked about yesterday was that the purpose of encryption is not to protect some piece of information forever. That would likely be impossible as our computer power grows in strenth. Eventually the processes of simply trying every possible key combination will become trivial enough that an sufficiently old algorithm will no longer be effective. Instead, I said that one of the aims of encryption is to deny access to information until that information is no longer useful.

A stunning example is illustrated in this article I read today from the Wall Street Journal: http://online.wsj.com/article/SB124648494429082661.html

To summarize, a friend of Thomas Jefferson once sent him a letter with an encrypted block of text in it. I should point out that this friend was a professional in the field of cryptology as it existed in the early 1800's. The really interesting thing is that the encrypted block of text, which was encrypted without the aid of computers obviously, stoood up to professional examination for 206 years. The code was broken in 2007, but the article is from today. So even though the algorithm was successfully broken, it still served its primary purpose which was to deny access to the plaintext until that plaintext was no longer useful to the attacker.

New Attack on AES, is Pointsec broken?

Like many people in the security world, I keep a close eye on Bruce Schneier's blog. Today I was a little scared when I read about a new attack on AES that has theoretically broken the cipher. You can read Schneier's comments on it here: http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html

The reason that this freaked me out at first is because the default encryption algorithm used by Check Point Full Disk Encryption (formerly known as Pointsec). Much of my personal data is protected by Check Point FDE and I don't want to see it exposed. The good news is that while this may fit the dictionary definition of a break, it is far from the end of the world.

The freakout comes from the difference between what a cryptologist calls a broken algorithm and what broken algorithm means to a typicaly person on the street. When you tell me that AES is broken, I think that it has been made completely worthless (or nearly worthless as is the case with DES). However, cryptologists have a much different definition. For them, a break means that someone found a way to get at the plaintext data in a more efficient way than simply trying all of the possible code combinations that exist. In this case, they found a way to reduce the number of possible code combinations from 2 to 119th power down to 2 to the 110th power.

So basically, AES is still very much alive and kicking. It is very unlikely that anyone is going to be able to exhaustively search through 2 to the 110th power code combinations and still derive value from your data. This is one of the points that I try to stress in my Full Disk Encryption classes, though. No encryption algorithm is perfect and able to remain eternally unbreakable. The power of encryption is to deny access to information for such a long period of time that the information is no longer valuable. For example it is worthless for the enemy to learn about tomorrows battle plan 35 years from now. The flip side of that coin is that if someone could theoretically gather enough computing resources to break your encryption in a short amount of time (say one week for example) the cost would exceed the value of the information. In other words, I would not spend tens of billions of dollars to break your encryption so that I could get your credit card number that has a limit of $5,000.

So if Check Point Full Disk Encryption broken? Well, maybe in a theoretical sense, but absolutely not in a practical sense.

Friday Diversion: What's the deal with Jammie Thomas?

I am embarrassed to say that I live in the state where a jury decided that Jammie Thomas should pay the RIAA $1.9 million for sharing 24 songs on the Internet.

Putting that in perspective, the jury has awarded $80,000 in damages per song.

According to wikipedia, there were 5 billion songs shared on the Internet in 2006. If we accept that the jury's verdict is fair, that means that the record companies lost out on $400 trillion dollars. $400,000,000,000,000.00. The current Gross Domestic product of the United States is about $14 trillion dollars. The gross domestic product of the world is about $60 trillion dollars.

The median household income in the United States in 2007 was about $50,000. If Jammie Thomas earnes that she would have to give all of her earnings (pre-tax) to the RIAA for the next 37.8 years. This is assuming there is no interest applied to the unpaid balance. At 3% interest, her salary will never cover the interest earned in a year.

If a typical CD costs $12 then you can purchase 158,333 CDs with this award.

Based on a sample size calculator, we can be 95% certain that at least 93.37% of the residents in Hennepin County are absolutely ridiculous.

Open Source Application Layer Firewall part 5

Continuing with our discussion of setting up a home-grown application layer firewall. So far we have set up an insecure application that needs protection. Then we configured our server to act as a router. Then we set up stateful packet inspection using PF, and turned it into a proxy firewall using Apache. Now I'd like to talk about how you can really look deep into the application traffic to stop unauthorized activity at a much higher level than what is possible with a stateful inspection firewall.

Now that we have a proxy firewall, we want to set up Apache mod_security to look deep into our http requests and identify malicious traffic. We're going to use packages to install mod_security, so the first thing we should do is set up our package path. I'm going to use the main OpenBSD distribution site for this, but you should probably choose a mirror that is closer to you. First we want to set up the environment variable:

# export PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/4.4/packages/i386

You can also add this to your .profile file so that you will have that set up every time the machine boots.

PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/4.4/packages/i386
export PKG_PATH

Now we can search the package list for mod_security.

# pkg_info -Q modsecurity
modsecurity-apache-1.9.3p2 

And then install it:

# pkg_add modsecurity-apache-1.9.3p2
modsecurity-apache-1.9.3p2: complete                                   
--- modsecurity-apache-1.9.3p2 -------------------
To finish the install of modsecurity-apache-1.9.3p2, you need
to enable the module using the following command

/usr/local/sbin/mod_security-enable

The manual is found at /usr/local/share/doc/mod_security.

If you already have Apache running on your machine,
you should not use "apachectl restart" - instead,
you should fully stop and then start the server.
#
# /usr/local/sbin/mod_security-enable                                    
Enabling  module...
[activating module `security' in /var/www/conf/httpd.conf]
cp /usr/local/lib/mod_security.so /usr/lib/apache/modules/mod_security.so
chmod 755 /usr/lib/apache/modules/mod_security.so
cp /var/www/conf/httpd.conf /var/www/conf/httpd.conf.bak
cp /var/www/conf/httpd.conf.new /var/www/conf/httpd.conf
rm /var/www/conf/httpd.conf.new

Let's follow the directions and shut down the httpd server:

# apachectl stop
/usr/sbin/apachectl stop: httpd stopped

Now take a moment to examine our httpd.conf file. You will notice that one line has been added to the configuration by the mod_security-enable script

# diff httpd.conf httpd.conf.bak
274d273
LoadModule security_module    /usr/lib/apache/modules/mod_security.so # 

Now that we have mod_security set up in Apache, let's do something with it. I'm going to put together a basic set of options, and put in one single filter that will block any requests going to my server that have the word "kevin" in them. Open up /var/www/conf/httpd.conf and enter this into one of the VirtualHosts that we created earlier.

 SecFilterEngine on
   SecFilterCheckURLEncoding On
   SecFilterScanPOST On
   SecAuditEngine On
   SecAuditLog /var/www/logs/audit_security.log
   SecFilterDefaultAction "deny,log,status:500"
   SecFilter "kevin" 

The indenting is not necessary, but it makes it look good and helps to identify all of the mod_security related stuff in this virtual host. You can also put configuration directives like this in the global configuration rather than within a single VirtualHost. However, if you're going to have multiple servers behind this firewall, you may find that you need different rules for each one, so I'm going to do it this way. Restart httpd to make the changes take effect.

Now let's test it. I'm going to go to my web application and enter the following:
Firstname: Shamus
Lastname: McFinnigan
Card: some number
I hit submit and the application works as expected. Then I tried the same thing but with the first name kevin instead. Mod_security blocked the request, and gave me an http 500 error. Mod_security is working. Congratulations, you now have a firewall that is doing layer 7 inspection of your traffic before it hits the server. You have an application layer firewall.

The rule set that we've built in here doesn't really do much for us, unless we want to discriminate against the Kevin's of the world. But what if we were using this to protect some appliance and we didn't know whether or not the coders had put proper input validation into their form fields? Well one thing we could do is use our proxy server to look at the requests that go by and find out what variable names are in use, and then write filter rules. For example, I know that my crappy application should only accept First and Last names that are alphabetical characters and no more than 12 characters in length. I also know that credit card numbers should only contain digits and dashes and that there should be four digits followed by a dash. So I can take out my SecFilter Kevin line and replace it with this:

SecFilterSelective "ARG_Fname" !^([A-Z]|[a-z]){1,12}$
SecFilterSelective "ARG_Lname" !^([A-Z]|[a-z]){1,12}$
SecFilterSelective "ARG_Ccard" !^([0-9]{4}-){3}[0-9]{4}$

So from the first name variable we're going to filter anything that does not match our regular expression (!). The regular expression indicates that we want to start with the first character of the variable (^) and that it should be an uppercase or lowercase letter ([A-Z]|[a-z]). That should occur at least one time but no more than 12 times {1,12} and then there should be nothing else $.

So now, regardless of how crappy the application behind the firewall is, it is protected pretty well. Sure it's not going to be bullet proof, but adding in this kind of input validation will add a lot of strength to your application security. Try doing this with a Cisco ASA box.

Check out the rules at http://www.gotroot.com/downloads/ftp/mod_security/rules.conf for more ways to strengthen your box. I suggest adding these in one at a time and making sure that your apache process doesn't crap rather than putting in the whole wad. Also, ff making up your own rules seems difficult, try out this online rule creator! http://jcksn.com/tools/modsecurity/

What about the core rule set?
Yeah, that would be pretty cool, wouldn't it? Well it's not going to happen anytime soon, at least not the way I've set things up here. One of the things I've tried to do in this setup is leverage the work of other people that are smarter than me to make a good firewall. One of the big points is using the chrooted Apache software that comes with OpenBSD. In order to use th mod_security core rule set, you have to be running Apache2. The core rule set depends on a newer version of mod_security, and that version depends on Apache2. Installing Apache2 on OpenBSD is pretty easy, but it isn't chrooted which means you have to do all that work yourself. I'd like to start working on another version of this that uses a chrooted Apache2, but first I need to figure out how to do that and keep it secure.

Friday Diversion: here be chunks

Quick note: I had nothing to do with this.  I'm just reporting on it.

There is a reason why I love working at a University, and why I feel that the one I work for is the finest educational institution in the Midwest. The answer is the people. I want to share something odd I found today on campus.

I had just gone to the restroom and I was walking back along a different route than I had taken to get to the restroom. Along the way, I encountered a group of chairs in the library in an unusual place with a piece of paper on the floor between them. Here is a photo of the chairs:


As I leaned in to examine the piece of paper, the unmistakable smell of vomit struck me in the nose. Then I was able to read the piece of paper. Here is a photo:
The text reads: "Dar, here be chunks."  Notice the marks where some unidentified fluid has started to seep through the page.  From what I can surmise, someone vomited in the library.  Then, instead of cleaning it up, this person arranged chairs around the vomit to warn others not to step there.  Then this person took the time to color print a warning page in pirate speak complete with old english font and pirate logo to place on top of the vomit.  

Only in my work place.