This story says that things on your computer that make it look like you are hiding stuff is itself incriminating. For example, if you have an encrypted file on your disk, it is evidence that you have something to hide, and therefore means you must be guilty of something.
As somebody who loves freedom, this really bugs me. I do a lot of strange things, and I don't like the idea that they might come back to frame me for crimes because no normal person would do them.
For example, I like foreign movies (here is the latest movie in French that I bought). I was in a Blockbuster video rental store. Since foreign movies are not popular, they had them back behind a corner. While I was back there looking at the movies, a kid comes wandering by and asks "What's back here?". After answering "Foreign films", the kid looks up at me like I'm a perrvert, runs back to his mother, and starts babbling something while pointing to me. I don't know what the kid said, but I felt guilty and embarrassed nonetheless.
On a more serious note, I like to shoot guns, but don't want to get arrested for a local convenience store robbery because shooting guns isn't "normal".
Encryption is one of these perversions. More and more laws are being passed to restrict encryption. Many years ago, the United Kingdom passed a law requiring people to give up their encryption keys to law enforcement. Having encrypted files that law enforcement cannot decrypt is a crime. While being interviewed on this (I think for The Register) I suggested that what virus writers should do is, among other things, drop encrypted files on people's systems. This creates a sort of "inverse steganography", where the existence of encrypted data does not itself prove that the user is trying to encrypt anything.
Even if virus writers don't include this sort of code in their viruses, you can certainly add such files to your system. I've included code below that can create pseudo-encrypted files on Windows (and of course you can use /dev/urand on other systems). This software works because, in theory, "random" data is indistinguishable with "encrypted" data.
Even though virus writers haven't littered our systems with random files, you can still take advantage of inverse steganography. First, create a DVD image of some files that you want to encrypt. Then run a raw AES encryption with a strong key over that DVD image. This gives you a 4-gig file that outsiders know is either (1) random data or (2) encrypted data, but they can't be sure which. Next, create another disk image full of porn. Now XOR (in One-Time-Pad fashion) the two disk images together. Now write two DVD's to disk, one containing the AES encrypted data, and the other containing the XORed porn. When law enforcement finds you with both disks, you claim that the AES disk is actually just a One-Time-Pad, that it contains random data and NOT encrypted data. Thus, law enforcement can't prove that you the One-Time-Pad is actually encrypted data or not.
As an activist, you should do this even if you don't want to hide any data of your own. If you are like me and believe that humans should have the Right to Encrypt their private data, then you should have such random files on your computer and randomized disks among your backups. The more individuals do this, the less power law enforcement will have to prosecute those who encrypt data. It's not a loud protest, but it's still an important silent protest.
The code below is for Windows using Microsoft's Crytographic services. I'm using RC4 here in a naïve manner, so there is a chance that a determined adversary can prove the resulting file is, or is not, produced by this program, but I doubt your local cops would have the resources to do so.
#include <stdio.h>
#include <windows.h>
#include <wincrypt.h>
void main(int argc, char *argv[])
{
HCRYPTPROV hCryptProv;
unsigned size;
FILE *fp;
if (argc < 3) {
printf("usage:\n polyrand <size> <file>\n");
return;
}
size = strtoul(argv[1],0,0);
fp = fopen(argv[2],"wb");
CryptAcquireContext(&hCryptProv,NULL,NULL,PROV_RSA_FULL,0);
while (size) {
char buf[1024];
unsigned len = sizeof(buf);
if (len > size) len = size;
CryptGenRandom(hCryptProv,len,buf);
if (fwrite(buf,1,len,fp) != len)
printf("write err\n");
size -= len;
}
}
Friday, July 27, 2007
Thursday, July 19, 2007
I am not LMH...
I am sorry to disappoint but I am not LMH. The email that was sent out to all the various security mailing lists claiming to be from me is faked by a desperate person who doesn’t want their identity discovered or reported to their employer.
Lets put aside the fact the email makes almost no sense, there are several glaring errors in the post such as Sherrod never worked for GaTech. I never call Rob by the name Robert, my manager at Secureworks wasn’t Jon Rammsey it was Allen Wilson, and Chris Rouland wasn’t part of the X-Force Advanced Research team, he was the CTO of ISS.
The glaring errors are not the most damning to the validity of this claim, the method it was carried out is. I wanted to “reveal” myself, I have this blog as a pulpit to do it from. No need to fake an email to a lot of different lists, most of which I don’t read or even subscribe to.
Also the unmask.py program shows a low likelihood I am the author of the email.
Comparing two stores located at store/post.pkl and store/lmh.pkl
Compared to store/post.pkl with match value of: 31.0
So to all the reporters, readers, and other people that were duped by this email, in the future if the email is not signed by a verified PGP key, don’t fall for it.
Lets put aside the fact the email makes almost no sense, there are several glaring errors in the post such as Sherrod never worked for GaTech. I never call Rob by the name Robert, my manager at Secureworks wasn’t Jon Rammsey it was Allen Wilson, and Chris Rouland wasn’t part of the X-Force Advanced Research team, he was the CTO of ISS.
The glaring errors are not the most damning to the validity of this claim, the method it was carried out is. I wanted to “reveal” myself, I have this blog as a pulpit to do it from. No need to fake an email to a lot of different lists, most of which I don’t read or even subscribe to.
Also the unmask.py program shows a low likelihood I am the author of the email.
Comparing two stores located at store/post.pkl and store/lmh.pkl
Compared to store/post.pkl with match value of: 31.0
So to all the reporters, readers, and other people that were duped by this email, in the future if the email is not signed by a verified PGP key, don’t fall for it.
Sunday, July 15, 2007
Corps of Engineers Security
This was an interesting story: "Military files left unprotected online". One of the sites described was an FTP server run by the Army Corps of Engineers. Google quickly finds such a server, ftp://ftp.usace.army.mil, and the public directory is indeed full of the sorts of documents the article describes. For example, the /pub/aed (Afghan Engineer Destrict) contains the following subdirectories:
This looks like the sort of stuff that companies might include on internal file servers. Using my digital voodoo (such as tracking IP sequence numbers), I can tell that this is a heavily used server. According to the greeting information, this server is used to transfer files to the world outside the Corps. Outsiders can upload files to one directory for Corps employees to read, and employees can post files in another directory for outsiders to read.
The Army Corps of Engineers has an annual budget of $12-billion and 35,000 employees, but hundreds of thousands of outsiders work on Corps projects.
People have criticized this as "Security Through Obscurity". Search engines do not catalogue FTP servers, and thus, these documents will not come up in a Google search. However, this obscurity does not secure the server because anonymous FTP servers are easily found and accessed. I could easily write a program that would scan all 4-billion addresses looking for FTP servers that give helpful banners like "220-THIS IS A DOD COMPUTER SYSTEM.", then take directory listings of the files.
However, the Associated Press article hypes the importance of these files. Sure, you might dream of ways terrorists might could use these drawings of barracks to help them plan an attack, but really such information isn't really as helpful as paranoids imagine. Not everything needs the highest level of security. Obscurity is actually an appropriate level of security for trivial information.
It's like how when I stay in a hotel room and I come out of the shower and forget to close the curtains. I'd be unhappy if somebody were to spy through the window and post pictures of me changing my clothes on the Internet. However, such information isn't necessarily all that important to protect with the strictest security measures either. Ultimately, I've made the decision to secure such information with obscurity. I don't double-check the curtains before taking a shower, nor do I verify that there are no cracks that somebody could peek through.
It's easy for us security people to point out when things go wrong, it's hard for us to tell people what's right. The advice they give in such situations is to make things far more secure then they need to be, and far more costly than is practical. The point of the Corps' FTP server is to "publish" documents to the limited community of contractors. I'm guessing that any solution that would "secure" this would also make it far more costly than the benefits the Corps receives from the server. In other words, if you demanded high security, the Corps would just shut it down.
My advice to the management would be that this server is not nearly as obscure as they believe. This is an "anonymous FTP server" which is far more open to the world than they think. At the same time, they are relying upon 35,000 internal users to always make the right judgment call about whether a file can, or cannot, be published on that server. There are some extremely simple steps that would make this more obscure. The easiest is simply to put a password on the "anonymous" account, such as "corps123". This password will, of course, be the worst kept secret ever, but it would make the server dramatically more obscure.
A slightly harder change would be to have a separate account for each other top level directories you have under public. I don't know the structure of the Corps, but I assume that people working for one department in the corps do not need access to the files of another department. Thus, create an "aed-anonymous" account (with a password) that only has access to the /pub/aed subdirectory. Thus, if an employee posts an overly sensitive document, the damage will be a lot less.
Finally, being outted like that in the press is a good opportunity to have a risk assessment done. It looks to me like a bit of mission creep is going on - what might have been appropriate obscurity for documents related to such public works projects as post-Katrina reconstruction might not be the same level of obscurity/security needed for military structures in Afghanistan. That auditor should be independent -- you just know that this is a typical internal politics where the people wanting the public FTP site have influenced the risk assessment to get what they want.
ABP Info (Paktia, Paktika, Ghazni)
AED Cmdr's Brief 05 2007
AED Projects
AED Yearbook 2007
CID Materials
DrChecks
Engineering Conference
Existing Hospital AsBuilt
GIS
Gardez Hospital Addition
New Folder
PRB 7-8-07
QAR_training
RFP W917PM-07-R-0074 Bagram USACE Office & Billeting
RFP W917PM-07-R-0081 ANA Brigade Buildings-Heating & Cooling Upgrades
Standards
Toor-Ghuundi Border Crossing 99% design
UP HQ Info (Paktia, Paktika, Ghazni)
W917PM-07-R-0076 Wadi Imporements-Pol-E-Charki
W917PM-07-R-0082-ANA Cooling & Heating Upgrades-Kandahar
W917PM-07-R-0084-ANA Cooling Upgrades-Laskargah
W917PM-07-R-0086-Drawings
W917PM-07-R-0086-Kunduz
W917PM-07-R-0088 Drawings
W917PM-07-R-0088-Farah
W917PM-07-R-0089 Khair Kot
W917PM-07-T-0051 - Site Assessment
This looks like the sort of stuff that companies might include on internal file servers. Using my digital voodoo (such as tracking IP sequence numbers), I can tell that this is a heavily used server. According to the greeting information, this server is used to transfer files to the world outside the Corps. Outsiders can upload files to one directory for Corps employees to read, and employees can post files in another directory for outsiders to read.
The Army Corps of Engineers has an annual budget of $12-billion and 35,000 employees, but hundreds of thousands of outsiders work on Corps projects.
People have criticized this as "Security Through Obscurity". Search engines do not catalogue FTP servers, and thus, these documents will not come up in a Google search. However, this obscurity does not secure the server because anonymous FTP servers are easily found and accessed. I could easily write a program that would scan all 4-billion addresses looking for FTP servers that give helpful banners like "220-THIS IS A DOD COMPUTER SYSTEM.", then take directory listings of the files.
However, the Associated Press article hypes the importance of these files. Sure, you might dream of ways terrorists might could use these drawings of barracks to help them plan an attack, but really such information isn't really as helpful as paranoids imagine. Not everything needs the highest level of security. Obscurity is actually an appropriate level of security for trivial information.
It's like how when I stay in a hotel room and I come out of the shower and forget to close the curtains. I'd be unhappy if somebody were to spy through the window and post pictures of me changing my clothes on the Internet. However, such information isn't necessarily all that important to protect with the strictest security measures either. Ultimately, I've made the decision to secure such information with obscurity. I don't double-check the curtains before taking a shower, nor do I verify that there are no cracks that somebody could peek through.
It's easy for us security people to point out when things go wrong, it's hard for us to tell people what's right. The advice they give in such situations is to make things far more secure then they need to be, and far more costly than is practical. The point of the Corps' FTP server is to "publish" documents to the limited community of contractors. I'm guessing that any solution that would "secure" this would also make it far more costly than the benefits the Corps receives from the server. In other words, if you demanded high security, the Corps would just shut it down.
My advice to the management would be that this server is not nearly as obscure as they believe. This is an "anonymous FTP server" which is far more open to the world than they think. At the same time, they are relying upon 35,000 internal users to always make the right judgment call about whether a file can, or cannot, be published on that server. There are some extremely simple steps that would make this more obscure. The easiest is simply to put a password on the "anonymous" account, such as "corps123". This password will, of course, be the worst kept secret ever, but it would make the server dramatically more obscure.
A slightly harder change would be to have a separate account for each other top level directories you have under public. I don't know the structure of the Corps, but I assume that people working for one department in the corps do not need access to the files of another department. Thus, create an "aed-anonymous" account (with a password) that only has access to the /pub/aed subdirectory. Thus, if an employee posts an overly sensitive document, the damage will be a lot less.
Finally, being outted like that in the press is a good opportunity to have a risk assessment done. It looks to me like a bit of mission creep is going on - what might have been appropriate obscurity for documents related to such public works projects as post-Katrina reconstruction might not be the same level of obscurity/security needed for military structures in Afghanistan. That auditor should be independent -- you just know that this is a typical internal politics where the people wanting the public FTP site have influenced the risk assessment to get what they want.
Tuesday, July 10, 2007
Super Tuesday!!
Today is the Microsoft drop day and it was pretty light. The most dangerous bug is the Active Directory vulnerability. Its a bit hard to weaponize but its doable but I doubt there will be much of a worm. If someone manages to get it working it will more likely be used in directed attacks. Once again this proves how bad ass Neel Mehta is.
Since Errata finished up early today covering these vulns and we know super Tuesday is all any security blog will discuss today, I know present you with videos of Dillon miniguns!
And...
Since Errata finished up early today covering these vulns and we know super Tuesday is all any security blog will discuss today, I know present you with videos of Dillon miniguns!
And...
Sunday, July 01, 2007
Our first iPhone bugs
Yup. After waiting a day to get the darn thing activated, we found a bug within a few minutes. We are cheating, of course, it's just the same bug we found earlier on Safari. Also, our Bluetooth fuzzer locks up the device, so that's an interesting sign. (As we've said in the past, we'll disclose all our bugs to Apple when they publish acceptable vuln handling guidelines).
The thing that interests us most, though, is that we think the iPhone is inherently more secure than competing smartphones (such as those based on Windows Mobile or Symbian). While Apple is slightly behind Windows on the desktop/server (that Samba bug still appears to be unfixed), it's still light years ahead of the mobile vendors. The mobile market is completely screwed up right now: while carriers know about the widespread vulnerabilities in their phones, the carriers are unwilling to patch them.
Apple is taking a chance. Rather than allowing carriers like at&t/Cingular to control the mobile experience, Apple is controlling the experience through iTunes. Financial analysts on Wall Street are waiting to see whether this strategy will work. Security is an are that can prove Apple right if they respond to security threats better than the carriers.
We think Apple will win that battle. When we activated the phone, iTunes told us it was going to look for updates on July 5, 2007. That's a good sign. We've reported a vuln in a another smartphone 6 months ago that still hasn't gotten patched, mostly because that carrier doesn't want to. If Apple can push a fix for one of our bugs before this carrier fixes their bug, that might convince Wall Street that their strategy is better.
At the same time, Apple is going to have the same problem that Windows has. While they may have better theoretical security, they are going to be a bigger target. Hackers know a lot more about breaking into Mac OS X than they do competing platforms like Windows Mobile or Symbian. Thus, even though Apple will patch sooner, they'll also have more bugs to patch because of increased hacker interest.
We still have more research to do. There are a bunch of questions we'd like to figure out. These are:
- what ports are listening on the device
- what services will it automatically connect to (looks like it automatically connects to known access points)
- what processor are they are running? Samsung? XScale?
- are they running with an MMU?
- is everything running as root?
- how hard is it going to be to get a jtag interface running on that thing?
- can we get a hack going that gives us good access without much knowledge (e.g. a Java for QuickTime bug that would allow us to dump memory contents to the screen)?
- ...and who do we have to sleep with to get our other iPhone activated??
The thing that interests us most, though, is that we think the iPhone is inherently more secure than competing smartphones (such as those based on Windows Mobile or Symbian). While Apple is slightly behind Windows on the desktop/server (that Samba bug still appears to be unfixed), it's still light years ahead of the mobile vendors. The mobile market is completely screwed up right now: while carriers know about the widespread vulnerabilities in their phones, the carriers are unwilling to patch them.
Apple is taking a chance. Rather than allowing carriers like at&t/Cingular to control the mobile experience, Apple is controlling the experience through iTunes. Financial analysts on Wall Street are waiting to see whether this strategy will work. Security is an are that can prove Apple right if they respond to security threats better than the carriers.
We think Apple will win that battle. When we activated the phone, iTunes told us it was going to look for updates on July 5, 2007. That's a good sign. We've reported a vuln in a another smartphone 6 months ago that still hasn't gotten patched, mostly because that carrier doesn't want to. If Apple can push a fix for one of our bugs before this carrier fixes their bug, that might convince Wall Street that their strategy is better.
At the same time, Apple is going to have the same problem that Windows has. While they may have better theoretical security, they are going to be a bigger target. Hackers know a lot more about breaking into Mac OS X than they do competing platforms like Windows Mobile or Symbian. Thus, even though Apple will patch sooner, they'll also have more bugs to patch because of increased hacker interest.
We still have more research to do. There are a bunch of questions we'd like to figure out. These are:
- what ports are listening on the device
- what services will it automatically connect to (looks like it automatically connects to known access points)
- what processor are they are running? Samsung? XScale?
- are they running with an MMU?
- is everything running as root?
- how hard is it going to be to get a jtag interface running on that thing?
- can we get a hack going that gives us good access without much knowledge (e.g. a Java for QuickTime bug that would allow us to dump memory contents to the screen)?
- ...and who do we have to sleep with to get our other iPhone activated??
Subscribe to:
Posts (Atom)
