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??
Saturday, June 30, 2007
An iPhone post...
So I'm waiting for the iPhone to "activate", by which I mean get a signal from at&t that will tell the phone to start its web-browser and wifi interfaces. That doesn't appear to be happening any time soon, but I feel I have to blog something related to the iPhone.
This article from Slate.com has an interesting comment about the social norms of waiting in line. The article points out that while it's rude to jump ahead of people to buy the first iPhone, it's not illegal.
This is a good starting point to ask what sorts of social norms should be regulated by the government. Stephen Landsburg points out that our social norm may be the best way, and using economic theory, it might be better to always put the latest arrivals at the head of the line. Computer scientists who study queuing theory have their own ideas of a "fair" way to stand in line. Other cultures have different social norms. For example, the Chinese government is now worried that Western norms will clash with Chinese norms (they take cuts) during the Olympic games in a couple years. Governments attempting to regulate social norms are in danger of forcing us to follow what may turn out to be bad norms.
Despite this, a lot of people want social norms regulated. The British government is heading that direction. Lawrence Lessig, board member of the EFF, argues that the government should regulate social norms on the Internet.
In many ways, the government is already regulating the social norms of the Internet without people quite realizing it. Electronics Arts (EA) have published their Terms of Service that you must agree to in order to play their games. Among those terms are: You will not exploit any bug in the Service or in any EA product to gain unfair advantage in the game and you will not communicate the existence of any such bug (either directly or through the public posting) to any other user of the Service. This a good social norm on one hand (we don't like cheaters) and a bad one on the other (we don't like restriction in our freedom to speak). Unfortunately, the courts have ruled in the Bnetd case that such restrictions might be enforceable. Before you argue that the government should regulate social norms, you might ask yourself if you are willing to have the government side with the wrong norm (pro-speech or anti-cheating).
As we ask the government more and more to regulate and police the Internet, how much longer are we going to get away with not paying for those services? What I mean here is that the more the government gets involved in governing the Internet, the more they are going to want to tax it. If companies like EA want the government to regulate virtual money in their games, the government is going to want to tax that virtual money.
What we have here is both the right (businesses like EA) and the left (groups like the EFF) campaigning for the government to regulate and police social norms on the Internet. I predict the situation will get worse. I'm suggesting that we should resist all such attempts by the government, even if we agree with the norm they want to regulate (such talk won't make you NetNeutrality guys happy).
Grr. I've written this long diatribe and my iPhone STILL hasn't activated. Maybe I should fuzz something else this weekend. I wonder if anybody has tested Opera recnetly...
This article from Slate.com has an interesting comment about the social norms of waiting in line. The article points out that while it's rude to jump ahead of people to buy the first iPhone, it's not illegal.
This is a good starting point to ask what sorts of social norms should be regulated by the government. Stephen Landsburg points out that our social norm may be the best way, and using economic theory, it might be better to always put the latest arrivals at the head of the line. Computer scientists who study queuing theory have their own ideas of a "fair" way to stand in line. Other cultures have different social norms. For example, the Chinese government is now worried that Western norms will clash with Chinese norms (they take cuts) during the Olympic games in a couple years. Governments attempting to regulate social norms are in danger of forcing us to follow what may turn out to be bad norms.
Despite this, a lot of people want social norms regulated. The British government is heading that direction. Lawrence Lessig, board member of the EFF, argues that the government should regulate social norms on the Internet.
In many ways, the government is already regulating the social norms of the Internet without people quite realizing it. Electronics Arts (EA) have published their Terms of Service that you must agree to in order to play their games. Among those terms are: You will not exploit any bug in the Service or in any EA product to gain unfair advantage in the game and you will not communicate the existence of any such bug (either directly or through the public posting) to any other user of the Service. This a good social norm on one hand (we don't like cheaters) and a bad one on the other (we don't like restriction in our freedom to speak). Unfortunately, the courts have ruled in the Bnetd case that such restrictions might be enforceable. Before you argue that the government should regulate social norms, you might ask yourself if you are willing to have the government side with the wrong norm (pro-speech or anti-cheating).
As we ask the government more and more to regulate and police the Internet, how much longer are we going to get away with not paying for those services? What I mean here is that the more the government gets involved in governing the Internet, the more they are going to want to tax it. If companies like EA want the government to regulate virtual money in their games, the government is going to want to tax that virtual money.
What we have here is both the right (businesses like EA) and the left (groups like the EFF) campaigning for the government to regulate and police social norms on the Internet. I predict the situation will get worse. I'm suggesting that we should resist all such attempts by the government, even if we agree with the norm they want to regulate (such talk won't make you NetNeutrality guys happy).
Grr. I've written this long diatribe and my iPhone STILL hasn't activated. Maybe I should fuzz something else this weekend. I wonder if anybody has tested Opera recnetly...
Thursday, June 28, 2007
And now...something light...
http://legal.ea.com/legal/legal.jsp?language=en
"You will not exploit any bug in the Service or in any EA product to gain unfair advantage in the game and you will not communicate the existence of any such bug (either directly or through the public posting) to any other user of the Service."
Gee, I was just about to tell my online gaming clan, SecuritySucks, how to totally own in the Sims online, but after reading this I will not give anybody any exploits. I am just relieved I saw this before I started handing out code...
A nod to Mr. Stepto, for this heads up!
"You will not exploit any bug in the Service or in any EA product to gain unfair advantage in the game and you will not communicate the existence of any such bug (either directly or through the public posting) to any other user of the Service."
Gee, I was just about to tell my online gaming clan, SecuritySucks, how to totally own in the Sims online, but after reading this I will not give anybody any exploits. I am just relieved I saw this before I started handing out code...
A nod to Mr. Stepto, for this heads up!
The Purple Pill?
This story highlights one of the problems in Internet security.
Joanna Rutkowska has been talking about "hypervisor rootkits", a way of creating undetectable malware on a machine. It's pretty cool stuff, regardless how you look at it. However, she describes it as being "100% undetectable", which of course, challenges other researchers to prove that it is indeed detectable. They have challenged her to infect one of their systems at random, and that they can detect it.
However, Joanna has already admitted that her Blue Pill can be detected in a laboratory setting. What she is claiming is that vendors won't be able to ship a product that will detect it in practice.
What this is highlighting is how much that happens in our industry is done in "bad faith". One of those challenging Joanna is Nate Lawson. If you'll remember earlier this year, Lawson attacked Barnaby Jack claiming that he unjustly hyped a presentation for CanSecWest. As it turns out, Barnaby's presentation was about something new and interesting, and the press article talking about it was 100% non-hype. Banarby delivered, as promised, a "new class of attacks target[ing] embedded devices". Lawson was wrong.
In much the same fashion, Lawson is ignoring Joanna's comments that her stuff can be detected in a laboratory, and challenged her with a laboratory setting. They created rules that do not address what Joanna has already claimed. They bet her that if she installs a hypervisor rootkit on one of their machines that they can detect it in the laboratory.
What would a good-faith bet be? They should publish a hypervisor detection tool on their website, then challenge Joanna to create a hypervisor that evades it. They should challenge the rest of us to install it on our machines to prove that it is robust and doesn't cause problems (like slowing our machines down). Better yet, they should provide source for their tool with BSD licensing so that anti-virus vendors can include it with their offerings.
All of this is largely theoretical. I don't see botnets using Blue Pill technology yet (although that's because it's so easy to evade detection they don't need more advanced techniques). I likewise don't see vendors providing defense for this. The entire debate is like betting whether Batman could beat Spiderman in a fight. The only relevancy that this debate has is to the spooks at the NSA worried about Chinese hackers installing rootkits in the DoD. And for the NSA, Joanna has an easy answer: don't worry about detection, just worry about defense and install a hypervisor on all your machines that prevents another hypervisor from being loaded.
Joanna Rutkowska has been talking about "hypervisor rootkits", a way of creating undetectable malware on a machine. It's pretty cool stuff, regardless how you look at it. However, she describes it as being "100% undetectable", which of course, challenges other researchers to prove that it is indeed detectable. They have challenged her to infect one of their systems at random, and that they can detect it.
However, Joanna has already admitted that her Blue Pill can be detected in a laboratory setting. What she is claiming is that vendors won't be able to ship a product that will detect it in practice.
What this is highlighting is how much that happens in our industry is done in "bad faith". One of those challenging Joanna is Nate Lawson. If you'll remember earlier this year, Lawson attacked Barnaby Jack claiming that he unjustly hyped a presentation for CanSecWest. As it turns out, Barnaby's presentation was about something new and interesting, and the press article talking about it was 100% non-hype. Banarby delivered, as promised, a "new class of attacks target[ing] embedded devices". Lawson was wrong.
In much the same fashion, Lawson is ignoring Joanna's comments that her stuff can be detected in a laboratory, and challenged her with a laboratory setting. They created rules that do not address what Joanna has already claimed. They bet her that if she installs a hypervisor rootkit on one of their machines that they can detect it in the laboratory.
What would a good-faith bet be? They should publish a hypervisor detection tool on their website, then challenge Joanna to create a hypervisor that evades it. They should challenge the rest of us to install it on our machines to prove that it is robust and doesn't cause problems (like slowing our machines down). Better yet, they should provide source for their tool with BSD licensing so that anti-virus vendors can include it with their offerings.
All of this is largely theoretical. I don't see botnets using Blue Pill technology yet (although that's because it's so easy to evade detection they don't need more advanced techniques). I likewise don't see vendors providing defense for this. The entire debate is like betting whether Batman could beat Spiderman in a fight. The only relevancy that this debate has is to the spooks at the NSA worried about Chinese hackers installing rootkits in the DoD. And for the NSA, Joanna has an easy answer: don't worry about detection, just worry about defense and install a hypervisor on all your machines that prevents another hypervisor from being loaded.
Thursday, June 14, 2007
A really good question deserves an answer…
As a comment to our previous Safari post I got a really good question from Jeffrey Hawkins and exploit terminology. His question reads:
Weaponized basically means you have found a remote execution bug that you can successful and reliable get code execution (not just theoretical or in a lab environment) that requires little or no effort on the part of the attacker to successfully exploit. The exploit will also take application or operating system versions into account and can work on a variety. The Metasploit project is an example of high quality weaponized exploits.
“I notice you found 2 remote execution bugs, but said one of them wasFirst of all not all software bugs all vulnerabilities, sometimes a bug is just a bug and nothing useful can be done with them. One step up from useless bugs are Denial-of-Service (DoS) bugs that while MAY have some security impact in reality are mostly annoying and are often caused by things like NULL pointer dereferences. Most researchers think a DoS is lame. Then we have code execution vulnerabilities. These are software flaws that allow the flow of execution of a program to be redirected to whatever arbitrary code an attacker chooses. These are what most people search for however just because you find a bug like this doesn’t mean it’s exploitable or reliable. There are several factors that can cause a code execution bug not to be exploitable such as the process dying before execution has been achieved (remember to get execution often times you are overwriting parts of the process memory that may be relied upon later), nothing useful to overwrite, thread problems, and hardware or software based anti-exploitation technology like NX or DEP.
"weaponizable". What does that mean?Specifically, how can one remote execution
bug be weaponizable, while the other is not?”
Weaponized basically means you have found a remote execution bug that you can successful and reliable get code execution (not just theoretical or in a lab environment) that requires little or no effort on the part of the attacker to successfully exploit. The exploit will also take application or operating system versions into account and can work on a variety. The Metasploit project is an example of high quality weaponized exploits.
HD's new groove...
https://strikecenter.bpointsys.com/
Check this site in the future for fun stuff from the Breakpoint Systems research team headed up by none other that everyone’s favorite prom date, HD Moore. Expect a lot of cool stuff as some of the fun things they are working on become public.
Check this site in the future for fun stuff from the Breakpoint Systems research team headed up by none other that everyone’s favorite prom date, HD Moore. Expect a lot of cool stuff as some of the fun things they are working on become public.
Monday, June 11, 2007
Niiiice...
**PLEASE DO NOT POST A COMMENT IF ITS ABOUT SAFARI IN BETA**
These bugs have been verified in the current PRODUCTION copy on OSX (Safari 2.0.4).
Apple just released a Safari for Windows beta at http://www.apple.com/safari. Using publicly available tools we had a DoS in no time. Keeping with our disclosure policy, we do not report bugs to Apple.
UPDATE: Whoops, sorry, thats not a DoS, its memory corruption.
UPDATE 2: Per Request....WinDBG output of a new bug. These are popping out like hotcakes.
UPDATE 3:
It appears I am not the only person who had this idea today?
http://aviv.raffon.net/CommentView,guid,54A1DB79-0ECB-4F13-99AE-45BAB70C4256.aspx#a0ac5417-013d-43ae-9abc-7d265113892c
UPDATE 4: Thor Larholm has also found a bug.
http://larholm.com/2007/06/12/safari-for-windows-0day-exploit-in-2-hours/
I'd like to note that we found a total of 6 bugs in an afternoon, 4 DoS and 2 remote code execution bugs. We have weaponized one of those to be reliable and its diffrent that what Thor has found. I can't speak for anybody else but the bugs found in the beta copy of Safari on Windows work on the production copy on OSX as well (same code base for alot of stuff). The exploit is robust mostly thanks to the lack of any kind of adanced security features in OSX, I write about it here.
UPDATE 5: I've been asked what our disclosure policy is. Its pretty simple, in most cases we will give vendors as long as they need to fix problems. If the vendor is unresponsive or make threats, we will give them 30 days then release details. If a vendor answers a vulnerability disclosure with marketing and spin attempts, we no longer report vulnerabilities to that vendor but the information goes into our Hacker Eye View program for customers and will be used in pentesting. We do not sell the vulnerabilities to any 3rd party.
These bugs have been verified in the current PRODUCTION copy on OSX (Safari 2.0.4).
Apple just released a Safari for Windows beta at http://www.apple.com/safari. Using publicly available tools we had a DoS in no time. Keeping with our disclosure policy, we do not report bugs to Apple.
UPDATE: Whoops, sorry, thats not a DoS, its memory corruption.
UPDATE 2: Per Request....WinDBG output of a new bug. These are popping out like hotcakes.
UPDATE 3:
It appears I am not the only person who had this idea today?
http://aviv.raffon.net/CommentView,guid,54A1DB79-0ECB-4F13-99AE-45BAB70C4256.aspx#a0ac5417-013d-43ae-9abc-7d265113892c
UPDATE 4: Thor Larholm has also found a bug.
http://larholm.com/2007/06/12/safari-for-windows-0day-exploit-in-2-hours/
I'd like to note that we found a total of 6 bugs in an afternoon, 4 DoS and 2 remote code execution bugs. We have weaponized one of those to be reliable and its diffrent that what Thor has found. I can't speak for anybody else but the bugs found in the beta copy of Safari on Windows work on the production copy on OSX as well (same code base for alot of stuff). The exploit is robust mostly thanks to the lack of any kind of adanced security features in OSX, I write about it here.
UPDATE 5: I've been asked what our disclosure policy is. Its pretty simple, in most cases we will give vendors as long as they need to fix problems. If the vendor is unresponsive or make threats, we will give them 30 days then release details. If a vendor answers a vulnerability disclosure with marketing and spin attempts, we no longer report vulnerabilities to that vendor but the information goes into our Hacker Eye View program for customers and will be used in pentesting. We do not sell the vulnerabilities to any 3rd party.
Friday, June 08, 2007
Amero, part 2
Brian Krebs has posted an update to the Julie Amero case (the teacher convicted of harming students by letting them see porn). Krebs also links to an e-mail exchange between Nancy Willard and the prosecution's expert witness Mark Lounsbury (the guy who made the technical error).
The fun little bit is that Nancy Willard has a website and books that deal with the issue of "cyberbullying", which she defines as:
This case is a good example of why company management does not listen to technical experts. Technical experts are angry because they understand how spyware and popups can lead to porn arriving on people's machines. They believe that Mark Lounsbury was wrong about this fact.
However, the case didn't hinge on that point. What was far more important was the testimony from children saying they watched the teacher click on porn. While the corrected technical analysis shows that the porn almost certainly started with the spyware/popups in the morning, it does not disprove the children's testimony that Amero was intentionally surfing porn later in the day.
Even that isn't the most important issue in the case. The biggest issue is that Amero did not prevent children from seeing the porn throughout the day. She didn't turn the computer off, she didn't even put a piece of paper in front of the monitor, stack books in front of it, put her purse in front, or do much of anything. Children viewed porn, she could have prevented it, but she didn't. (And that was against the law).
Corporate management doesn't listen to the technical staff for precisely this reason. The technical staff believes that everything hinges on the small technical details they are experts in. They refuse to confine their advice to the areas where they are competent ("porn first arrived due to standard spyware/popups"), but instead insist on advising in areas where they are not competent ("Julie Amero is innocent").
Its good that's she's getting a second trial where the correct information about spyware/popups is presented, but chances are good that she will still be found guilty. The students testified that Amero was more interested in watching the popups than noticing that the children were also seeing the same popups. Nothing on the disk drive would ever disprove the children's assertion that she was scrolling through porn-filled webpages (and letting the children watch her do it).
The fun little bit is that Nancy Willard has a website and books that deal with the issue of "cyberbullying", which she defines as:
Cyberbullying is being cruel to others by sending orCompare that definition to the e-mail she sent to Mark Lounsbury:
posting harmful material or engaging in other forms
of social aggression using the Internet or other digital
technologies.
Mark,The thing about bullies is that they don't know that they are bullies. Nancy Willard certainly doesn't believe she is a cyberbully.
You did not present FACTS at trial. You are either totally stupid and naïve cop who should have never been given the keys to a $300,000 Internet safety van or you committed perjury.
I hope you find the strength to face the facts and to take responsibility for your words and actions, someday. I do believe that in the end you will be held accountable.
Nancy
This case is a good example of why company management does not listen to technical experts. Technical experts are angry because they understand how spyware and popups can lead to porn arriving on people's machines. They believe that Mark Lounsbury was wrong about this fact.
However, the case didn't hinge on that point. What was far more important was the testimony from children saying they watched the teacher click on porn. While the corrected technical analysis shows that the porn almost certainly started with the spyware/popups in the morning, it does not disprove the children's testimony that Amero was intentionally surfing porn later in the day.
Even that isn't the most important issue in the case. The biggest issue is that Amero did not prevent children from seeing the porn throughout the day. She didn't turn the computer off, she didn't even put a piece of paper in front of the monitor, stack books in front of it, put her purse in front, or do much of anything. Children viewed porn, she could have prevented it, but she didn't. (And that was against the law).
Corporate management doesn't listen to the technical staff for precisely this reason. The technical staff believes that everything hinges on the small technical details they are experts in. They refuse to confine their advice to the areas where they are competent ("porn first arrived due to standard spyware/popups"), but instead insist on advising in areas where they are not competent ("Julie Amero is innocent").
Its good that's she's getting a second trial where the correct information about spyware/popups is presented, but chances are good that she will still be found guilty. The students testified that Amero was more interested in watching the popups than noticing that the children were also seeing the same popups. Nothing on the disk drive would ever disprove the children's assertion that she was scrolling through porn-filled webpages (and letting the children watch her do it).
Wednesday, June 06, 2007
How to become a "security guru"
A comment on my last post claimed that every company needs a "security guru". This is a good idea, but the problem is that technical experts rarely have the "people skills" to be effective gurus.
The most important issue facing you experts is that people aren't going to listen to you most of the time. It doesn't matter if you are the summer intern or the CEO: getting people to listen is hard. It's not your job to "tell" people what the right answer is, but to "sell" your idea. If you get angry and poison your working relationships, you are not going to be an effective salesman. The reason experts get angry or frustrated is because they blame others for not listening to the "truth", rather than blaming themselves for their inability to sell their ideas.
The second most important issue is that there is no such thing as a "right" answer. Technical people fail because they always strive for the optimal solution to a problem, but as Voltaire says "perfect is the enemy of good enough". Your job as the guru isn't to steer to the organization toward the best solutions, but to steer them away from those that aren't good enough. Frankly this is because while you are often correct about what is "good enough", you are probably wrong about what is "best".
The geek's approach to selling ideas is to construct a logical proof of their idea such that nobody can disagree. This never works. Selling your ideas means you have to social engineer your co-workers. People make decisions for emotional reasons more than logical ones.
The most important social engineering technique is to shut up. The human emotion that drives most arguments is that we just want the other person to listen to us. The reason that somebody opposed your expert advice isn't so much that they don't like it, but that they wanted you to listen to their point of view. Often all it takes is win acceptance of your idea is to listen to your opponents. When you talk, you should ask pertinent questions or paraphrase what they've said in your own words. It doesn't matter whether you care about what they are saying or agree with it, what matters is that you prove them that you are listening. Objecting or arguing with them, no matter how wrong they are, puts you into the "not listening" mode, and should be avoided.
Your success often depends upon how well you deal with objections by others. Your instinct is to respond like you've been attacked, to go on the defensive, and respond with an argument. Resist that urge.
Try to figure out the reason for the objection. For example, the person may actually support your idea, but be looking for any problems before publicly endorsing you. Angrily counterattacking will, of course, be precisely the wrong thing to do in that situation. Some objections come from people who just like to hear themselves talk. When you argue with an idiot like this, most observers will assume you both are idiots. A big reason is for objections is that the person has some other agenda: your goal is to deal with that agenda, not with the individual objections that the person brings up.
Following the "shut up" principle above, the best way to deal with objections is not to argue. Your first instinct should be instead to ask questions. Good questions to ask are "Can you be more specific?", "Can you give an example?", "Is that your only objection?", "How would you fix it?", "I have no solution to that objection, does this mean that my idea has no merit?". The last one is one of the best: it social engineers the objector into feeling uncomfortable, and encourages them to overcome their own objection so that you don't have to. Remember: when you are listening to them talk, you are winning, when you are arguing, you are losing.
Don't go all emo. People pick up on your emotional state. You want to project a "calm-assertive" attitude. I get that term from "The Dog Whisperer" TV show, where the dog trainer tells owners to be calm-assertive with their pets, but the same applies to dealing with computer geeks. Showing emotion occasionally is okay, but only if you are in control of the emotion you are displaying, rather than letting the emotion control you. Remember that people pick up on subtle emotions well. You may be sitting quietly in the room, but be loudly projecting your sullen anger or agitation. When you can project an attitude that you don't seem upset by the fact that many (or all) disagree with you, then you've won half the battle. When you project the attitude that you are in control, then others will believe you.
I describe this as "social engineering", but you've probably guessed is that it really more than that. My previous company, Network ICE, had three founders. The reason we got along so well was because of instead of angry arguments, we aggressively attempted to social engineer each other. A typical "argument" would go like: "(Alice) What is your idea? (Bob) No, you tell me what your idea first! (Alice) No, I don't think you'll like my idea, so I think we should start with yours first.". Arguments where two people are trying to out-listen each other always end better than those where they talk to out-talk each other.
I could write a whole book on the topic, but these are the essentials:
- sell your idea, don't tell
- accept that there is no "best" solution
- listen, listen, listen
- don't get drawn into futile arguments
- stay calm and assertive
The most important issue facing you experts is that people aren't going to listen to you most of the time. It doesn't matter if you are the summer intern or the CEO: getting people to listen is hard. It's not your job to "tell" people what the right answer is, but to "sell" your idea. If you get angry and poison your working relationships, you are not going to be an effective salesman. The reason experts get angry or frustrated is because they blame others for not listening to the "truth", rather than blaming themselves for their inability to sell their ideas.
The second most important issue is that there is no such thing as a "right" answer. Technical people fail because they always strive for the optimal solution to a problem, but as Voltaire says "perfect is the enemy of good enough". Your job as the guru isn't to steer to the organization toward the best solutions, but to steer them away from those that aren't good enough. Frankly this is because while you are often correct about what is "good enough", you are probably wrong about what is "best".
The geek's approach to selling ideas is to construct a logical proof of their idea such that nobody can disagree. This never works. Selling your ideas means you have to social engineer your co-workers. People make decisions for emotional reasons more than logical ones.
The most important social engineering technique is to shut up. The human emotion that drives most arguments is that we just want the other person to listen to us. The reason that somebody opposed your expert advice isn't so much that they don't like it, but that they wanted you to listen to their point of view. Often all it takes is win acceptance of your idea is to listen to your opponents. When you talk, you should ask pertinent questions or paraphrase what they've said in your own words. It doesn't matter whether you care about what they are saying or agree with it, what matters is that you prove them that you are listening. Objecting or arguing with them, no matter how wrong they are, puts you into the "not listening" mode, and should be avoided.
Your success often depends upon how well you deal with objections by others. Your instinct is to respond like you've been attacked, to go on the defensive, and respond with an argument. Resist that urge.
Try to figure out the reason for the objection. For example, the person may actually support your idea, but be looking for any problems before publicly endorsing you. Angrily counterattacking will, of course, be precisely the wrong thing to do in that situation. Some objections come from people who just like to hear themselves talk. When you argue with an idiot like this, most observers will assume you both are idiots. A big reason is for objections is that the person has some other agenda: your goal is to deal with that agenda, not with the individual objections that the person brings up.
Following the "shut up" principle above, the best way to deal with objections is not to argue. Your first instinct should be instead to ask questions. Good questions to ask are "Can you be more specific?", "Can you give an example?", "Is that your only objection?", "How would you fix it?", "I have no solution to that objection, does this mean that my idea has no merit?". The last one is one of the best: it social engineers the objector into feeling uncomfortable, and encourages them to overcome their own objection so that you don't have to. Remember: when you are listening to them talk, you are winning, when you are arguing, you are losing.
Don't go all emo. People pick up on your emotional state. You want to project a "calm-assertive" attitude. I get that term from "The Dog Whisperer" TV show, where the dog trainer tells owners to be calm-assertive with their pets, but the same applies to dealing with computer geeks. Showing emotion occasionally is okay, but only if you are in control of the emotion you are displaying, rather than letting the emotion control you. Remember that people pick up on subtle emotions well. You may be sitting quietly in the room, but be loudly projecting your sullen anger or agitation. When you can project an attitude that you don't seem upset by the fact that many (or all) disagree with you, then you've won half the battle. When you project the attitude that you are in control, then others will believe you.
I describe this as "social engineering", but you've probably guessed is that it really more than that. My previous company, Network ICE, had three founders. The reason we got along so well was because of instead of angry arguments, we aggressively attempted to social engineer each other. A typical "argument" would go like: "(Alice) What is your idea? (Bob) No, you tell me what your idea first! (Alice) No, I don't think you'll like my idea, so I think we should start with yours first.". Arguments where two people are trying to out-listen each other always end better than those where they talk to out-talk each other.
I could write a whole book on the topic, but these are the essentials:
- sell your idea, don't tell
- accept that there is no "best" solution
- listen, listen, listen
- don't get drawn into futile arguments
- stay calm and assertive
Tuesday, June 05, 2007
Details matter
Bruce Schneier describes his African safari. He tells how the staff explained to him that when threatened by different animals, people needed to respond differently. You stare down some animals, you avert your gaze from others. You run from some, stand your ground with others. You can climb trees to avoid some animals, but other animals are better climbers than you are. Following the wrong strategy for an animal can get you killed, such as staring down an animal that provokes it to attack.
Schneier doesn't make what I think would be the obvious corollary with cybersecurity, namely that the details of each threat matters. In order to defend yourself, you need to pay attention to the details.
The Slammer worm resulted in a lot of sales of anti-virus product. However, anti-virus products do not protect against in-memory worms like Slammer. Anti-virus is not the correct defense against Slammer. The correct defense would include intrusion-prevention systems (IPS), better firewall rules, better patching, and better vulnerability scanning. In other words, unless you pay attention to the details of Slammer, you are unlikely to defend yourself well against it.
Corporations have a culture of ignoring the details of cyber-threats. They build their security policies at a high-level, from the top down. Of course these policies state that the details must be taken care of eventually, but much of the time, their processes never advance that far. When confronted with a cybersecurity failure due to lack of attention to the details, they will often go back and redesign their policies from scratch, again at a high-level, and again ignoring the low level details.
A good example of this is the recent fad of "secure development lifecycles", where corporations now pay attention to securing their internal software projects. The low-level details they need to solve are things like "SQL injection" and "cross-site scripting". However, when companies approach the problem from a high-level, they often never get as far as these details. Thus, the uptake in "secure development" has not resulted in solving the widespread problem of "SQL injection".
Its interesting reading documents on the Internet about the security lifecycle, such as this one. It's full of high-level platititudes but empty of any low-level details. For example, it stresses the importance of teaching software security in universities, but it's approach is largely meaningless. A better approach to the problem, one that is focused on the details, is to tell universities to stop teaching students to use "strcpy()" and to start teaching them how hackers "smash the stack".
The successful security lifecycle projects I've seen are those that start first with the details, then build upwards from there. In other words, processes that focus first on a detail like "SQL injection" is likely to both solve that problem as well as be extensible to other problems. An example of this is Microsoft: while they do describe the security lifecycle from the high-level, their processes were created from low-level details. The documents they produce show that they pay attention to low-level details.
You would think that the technical staff would be the leaders in getting their employers to focus on security details, but you'd be wrong. Technical people ignore the details of business to the same degree that business people ignore the technical details. It's a rare company that has a leader who both understands the business as well as the security details. In addition, the technical staff likes to focus on exciting problems like stopping 0day worms, but the biggest problems are the boring ones (like guessable passwords), and companies are more likely to be hacked by the boring problems than the exciting ones.
So what is the solution? My recommendation is to change the culture so that technical details matter. Any high-level document used in the process should include "use-cases" or something that points to a low-level detail. This will keep the project anchored in reality, and discourage it from drifting off course.
Schneier doesn't make what I think would be the obvious corollary with cybersecurity, namely that the details of each threat matters. In order to defend yourself, you need to pay attention to the details.
The Slammer worm resulted in a lot of sales of anti-virus product. However, anti-virus products do not protect against in-memory worms like Slammer. Anti-virus is not the correct defense against Slammer. The correct defense would include intrusion-prevention systems (IPS), better firewall rules, better patching, and better vulnerability scanning. In other words, unless you pay attention to the details of Slammer, you are unlikely to defend yourself well against it.
Corporations have a culture of ignoring the details of cyber-threats. They build their security policies at a high-level, from the top down. Of course these policies state that the details must be taken care of eventually, but much of the time, their processes never advance that far. When confronted with a cybersecurity failure due to lack of attention to the details, they will often go back and redesign their policies from scratch, again at a high-level, and again ignoring the low level details.
A good example of this is the recent fad of "secure development lifecycles", where corporations now pay attention to securing their internal software projects. The low-level details they need to solve are things like "SQL injection" and "cross-site scripting". However, when companies approach the problem from a high-level, they often never get as far as these details. Thus, the uptake in "secure development" has not resulted in solving the widespread problem of "SQL injection".
Its interesting reading documents on the Internet about the security lifecycle, such as this one. It's full of high-level platititudes but empty of any low-level details. For example, it stresses the importance of teaching software security in universities, but it's approach is largely meaningless. A better approach to the problem, one that is focused on the details, is to tell universities to stop teaching students to use "strcpy()" and to start teaching them how hackers "smash the stack".
The successful security lifecycle projects I've seen are those that start first with the details, then build upwards from there. In other words, processes that focus first on a detail like "SQL injection" is likely to both solve that problem as well as be extensible to other problems. An example of this is Microsoft: while they do describe the security lifecycle from the high-level, their processes were created from low-level details. The documents they produce show that they pay attention to low-level details.
You would think that the technical staff would be the leaders in getting their employers to focus on security details, but you'd be wrong. Technical people ignore the details of business to the same degree that business people ignore the technical details. It's a rare company that has a leader who both understands the business as well as the security details. In addition, the technical staff likes to focus on exciting problems like stopping 0day worms, but the biggest problems are the boring ones (like guessable passwords), and companies are more likely to be hacked by the boring problems than the exciting ones.
So what is the solution? My recommendation is to change the culture so that technical details matter. Any high-level document used in the process should include "use-cases" or something that points to a low-level detail. This will keep the project anchored in reality, and discourage it from drifting off course.
Tuesday, May 29, 2007
This is not cyber-warfare
Former Soviet republic Estonia has been under constant cyber-attack since it removed a Russian statue a month ago. Estonia claims that the attacks are from the Russian government. Journalists love the story and have been blindly repeating it, such as John Markoff reporting: "In Estonia, what may be the first war in cyberspace.
This is not the first such incident in cyberspace. Such incidents have been going on all the time. For example, two years ago when a Japanese prime minister offended China and South Korea by visiting a shrine containing the remains of convicted WW II war criminals. Along with street protests, there were extensive cyber-attacks against Japan sites from Korea and China. Back in 1999, while opponents to the WTO (World Trade Organization) were in the streets demonstrating against their meeting in Seattle, hacktivists were conducting a "cyber sit-in" against their website. This involved running JavaScript that would cause a user's browser to regularly refresh their homepage. Hacktivists have since used such sit-ins successfully in protests against oil companies, animal testing companies, and financial firms.
Like the attacks against Estonia, these attacks in cyberspace coincided with physical protests in the streets. Russia has an unusually large hacking underground with many people controlling large botnets. Any issue that brings Russian protests to the streets is therefore almost certain to bring with it DoS attacks. Thus, using Occam's Razor, it's unreasonable to believe that the Russian government itself had any direct influence on the cyber-attacks.
This story reflects the general paranoia of the Internet. Whenever anything happens, people seek to uncover the "plan" behind it. In reality, most bad things that happen on the Internet occur by happenstance, without any plan or conspiracy behind them.
An example of this is the Slammer worm of 2003. It hit South Korea especially hard. This is likely due to the fact that South Korea had unusually high bandwidth, and an unusually high percentage of vulnerable servers. There is absolutely no evidence that they were targeted by the worm, yet many in South Korea still believe the worm targeted them. Another example is the Witty worm of 2004. It hit the US military hard. This was due to the fact that the military controls the largest block of the world's IP address space and monitored it with vulnerable promiscuous systems. There is no evidence that they were targeted by the worm, but most people believed that the Army was the target.
Unfortunately, "happenstance" is not a legitimate story angle that reporters can report on. It's always something like "is this cyberterrorism" or "is this cyberwarfare".
EDIT: I just noticed this story on Slashdot, where the awesome guys at Arbor describe their analysis. They point out a few other examples, such as cyberattacks from Korea protesting a decision by an Olympic judge against a Korean athlete. Another example was a nationalistic cyberattacks traded between Packistan and India. Again, these incidents show evidence of popular protest rather than government directed cyberwarfare.
EDIT: Here's a link from Ars Technica that refuses to give up on the cyberwar theory.
This is not the first such incident in cyberspace. Such incidents have been going on all the time. For example, two years ago when a Japanese prime minister offended China and South Korea by visiting a shrine containing the remains of convicted WW II war criminals. Along with street protests, there were extensive cyber-attacks against Japan sites from Korea and China. Back in 1999, while opponents to the WTO (World Trade Organization) were in the streets demonstrating against their meeting in Seattle, hacktivists were conducting a "cyber sit-in" against their website. This involved running JavaScript that would cause a user's browser to regularly refresh their homepage. Hacktivists have since used such sit-ins successfully in protests against oil companies, animal testing companies, and financial firms.
Like the attacks against Estonia, these attacks in cyberspace coincided with physical protests in the streets. Russia has an unusually large hacking underground with many people controlling large botnets. Any issue that brings Russian protests to the streets is therefore almost certain to bring with it DoS attacks. Thus, using Occam's Razor, it's unreasonable to believe that the Russian government itself had any direct influence on the cyber-attacks.
This story reflects the general paranoia of the Internet. Whenever anything happens, people seek to uncover the "plan" behind it. In reality, most bad things that happen on the Internet occur by happenstance, without any plan or conspiracy behind them.
An example of this is the Slammer worm of 2003. It hit South Korea especially hard. This is likely due to the fact that South Korea had unusually high bandwidth, and an unusually high percentage of vulnerable servers. There is absolutely no evidence that they were targeted by the worm, yet many in South Korea still believe the worm targeted them. Another example is the Witty worm of 2004. It hit the US military hard. This was due to the fact that the military controls the largest block of the world's IP address space and monitored it with vulnerable promiscuous systems. There is no evidence that they were targeted by the worm, but most people believed that the Army was the target.
Unfortunately, "happenstance" is not a legitimate story angle that reporters can report on. It's always something like "is this cyberterrorism" or "is this cyberwarfare".
EDIT: I just noticed this story on Slashdot, where the awesome guys at Arbor describe their analysis. They point out a few other examples, such as cyberattacks from Korea protesting a decision by an Olympic judge against a Korean athlete. Another example was a nationalistic cyberattacks traded between Packistan and India. Again, these incidents show evidence of popular protest rather than government directed cyberwarfare.
EDIT: Here's a link from Ars Technica that refuses to give up on the cyberwar theory.
Monday, May 21, 2007
Life imitating art?
That is interesting. Not so long ago Rob and I spoke at Microsoft’s Bluehat conference about a variety of topics under the heading of “Breaking and Breaking into Microsoft Security tools”. One of the sections covered how easy it is to reverse an Anti-virus tools rule set and modify it which concluded with a live demo of a popular tool causing a Windows XP SP2 machine to crash.
I open my rss reader this morning and b00m, Whitedust has an article about something similar happening in China. It may not have been malicious but it still shows something that Rob and I have been talking about for years: security problems exist because code has gotten so complex it’s hard to get right. The solution for this is not layering more complex code on top of the already broken code and hoping the dam holds.
A leading industry analyst I know said “it’s amusing that since blaster, we've had bigger outages from bad AV signatures on most major products than the viruses themselves”. Can anybody else see the sun setting on these products?
UPDATE: Infoworld is also running a story on it.
I open my rss reader this morning and b00m, Whitedust has an article about something similar happening in China. It may not have been malicious but it still shows something that Rob and I have been talking about for years: security problems exist because code has gotten so complex it’s hard to get right. The solution for this is not layering more complex code on top of the already broken code and hoping the dam holds.
A leading industry analyst I know said “it’s amusing that since blaster, we've had bigger outages from bad AV signatures on most major products than the viruses themselves”. Can anybody else see the sun setting on these products?
UPDATE: Infoworld is also running a story on it.
Friday, May 18, 2007
Public wifi vs 3G mobile broadband
Wireless sans wifi
In my last post, I pointed out that public wifi is too dangerous to use. Web/2.0 is fundamentally insecure around eavesdroppers. It allows hackers to break into your accounts and/or your computer.
One option is "mobile broadband", or "tethering" your computer to a 3G mobile phone's Internet connection. The speeds are competitive with public access points. It's a bit of security-through-obscurity, though. It's safer because robust hacking tools to eavesdrop and interact with 3G don't exist. However, since hackers haven't been testing it, 3G is likely no more secure than wifi was in the early days with WEP. Thus, it's not really a good long term security solution.
Anyway, I signed up for a 3G phone service with a Blackjack from Cingular. It's not going to be the first thing that hackers attack when I go to conferences, and it's actually a lot more convenient. I can hook-up/tether the Blackjack mobile phone to my computer, then surf the web from my computer like I was connected to a public wifi.
Setting up tethering was a bit of a pain. Even though this feature has been around for many years, phone companies don't really support it well. While going through the support process, I found some poorly (or not all at) documented features. Typing *#1234# is the secret code to get your version on the Blackjack, *#2222# is the secret code for getting the hardware revision, and pressing the "up" button on the nav-wheel while powering on will completely reset the device (wiping out your data).
I wanted to be able to tether with Bluetooth as well as USB, which was particularly problematic. I could only do so after removing the Toshiba Bluetooth stack and replacing it with Microsoft's Bluetooth stack on WinXP SP2. Then, following the instructions found on the Internet, I was able to get it to work. Tethering via Bluetooth is a bit slower than USB, and of course, a lot less safe. However, I lose cables quiet often while traveling, so having that as an option is pretty important to me. Otherwise, I was going to buy a new computer with 3G like HSDPA or EVDO built in.
Speed is good. I suppose I should measure ping times and DSLtest reports, but I'm too lazy. All I want to know is that I can surf the web, pull up maps, read mail, and do my normal activity. It does this quiet well. It seems that the latency is a bit higher, but the bandwidth is just as good. I'll have to wait until I get into crowded areas like airports to see how well it degrades as more people are using it. EDIT: Most importantly, the phone works while surfing (most other tethered phones cannot both receive a call and surf the web at the same time).
I'm exploring other options than just changing from wifi to 3G. A lot of Web/2.0 companies support SSL for full access, they just don't advertise it because they don't have enough crypto acceleration. You can often find the SSL option if you search enough. Another option that doesn't seem to be used much on the public Internet is automatically establishing an IPsec session between two machines: this is well supported in Windows, but it's never turned on. VPNing back to home, then surfing out from there is really a desperate measure: Web/2.0 should really be secure enough such that it's not necessary.
As a side note, Cingular wanted to my SSN, and of course I didn't give it to them. I got the same reaction I usually get. It's usually an option to provide a deposit instead of an SSN, but they consider that so unreasonable they never tell me about it. They aren't hiding the option, they just assume that nobody would ever choose it. In the case of Cingular, when the sales guy told me that I had to give him my SSN, I said "ok, then I won't buy the service" and was walking out the door before I remembered to ask about the deposit. He was willing to let me go rather than suggest the option. I often wonder why customers think that paying a deposit is such an unreasonable alternative to disclosing your SSN. Does anybody know? Also: everyone in the cybersecurity community refuses to disclose their SSN, right?
In my last post, I pointed out that public wifi is too dangerous to use. Web/2.0 is fundamentally insecure around eavesdroppers. It allows hackers to break into your accounts and/or your computer.
One option is "mobile broadband", or "tethering" your computer to a 3G mobile phone's Internet connection. The speeds are competitive with public access points. It's a bit of security-through-obscurity, though. It's safer because robust hacking tools to eavesdrop and interact with 3G don't exist. However, since hackers haven't been testing it, 3G is likely no more secure than wifi was in the early days with WEP. Thus, it's not really a good long term security solution.
Anyway, I signed up for a 3G phone service with a Blackjack from Cingular. It's not going to be the first thing that hackers attack when I go to conferences, and it's actually a lot more convenient. I can hook-up/tether the Blackjack mobile phone to my computer, then surf the web from my computer like I was connected to a public wifi.
Setting up tethering was a bit of a pain. Even though this feature has been around for many years, phone companies don't really support it well. While going through the support process, I found some poorly (or not all at) documented features. Typing *#1234# is the secret code to get your version on the Blackjack, *#2222# is the secret code for getting the hardware revision, and pressing the "up" button on the nav-wheel while powering on will completely reset the device (wiping out your data).
I wanted to be able to tether with Bluetooth as well as USB, which was particularly problematic. I could only do so after removing the Toshiba Bluetooth stack and replacing it with Microsoft's Bluetooth stack on WinXP SP2. Then, following the instructions found on the Internet, I was able to get it to work. Tethering via Bluetooth is a bit slower than USB, and of course, a lot less safe. However, I lose cables quiet often while traveling, so having that as an option is pretty important to me. Otherwise, I was going to buy a new computer with 3G like HSDPA or EVDO built in.
Speed is good. I suppose I should measure ping times and DSLtest reports, but I'm too lazy. All I want to know is that I can surf the web, pull up maps, read mail, and do my normal activity. It does this quiet well. It seems that the latency is a bit higher, but the bandwidth is just as good. I'll have to wait until I get into crowded areas like airports to see how well it degrades as more people are using it. EDIT: Most importantly, the phone works while surfing (most other tethered phones cannot both receive a call and surf the web at the same time).
I'm exploring other options than just changing from wifi to 3G. A lot of Web/2.0 companies support SSL for full access, they just don't advertise it because they don't have enough crypto acceleration. You can often find the SSL option if you search enough. Another option that doesn't seem to be used much on the public Internet is automatically establishing an IPsec session between two machines: this is well supported in Windows, but it's never turned on. VPNing back to home, then surfing out from there is really a desperate measure: Web/2.0 should really be secure enough such that it's not necessary.
As a side note, Cingular wanted to my SSN, and of course I didn't give it to them. I got the same reaction I usually get. It's usually an option to provide a deposit instead of an SSN, but they consider that so unreasonable they never tell me about it. They aren't hiding the option, they just assume that nobody would ever choose it. In the case of Cingular, when the sales guy told me that I had to give him my SSN, I said "ok, then I won't buy the service" and was walking out the door before I remembered to ask about the deposit. He was willing to let me go rather than suggest the option. I often wonder why customers think that paying a deposit is such an unreasonable alternative to disclosing your SSN. Does anybody know? Also: everyone in the cybersecurity community refuses to disclose their SSN, right?
Monday, May 14, 2007
Blogging Toorcon/Seattle
The San Diego cybersecurity convention Toorcon has branched northwards with a cool concept. This year, they had a small con (150 people) on the weekend after BlueHat (Microsoft's internal cybersecurity con). It was in a small bar, talks lasted 20 minutes, and ended in with an hour of 5 minute "lightning" talks. The format rocked, hard.
I want to apologize for my talk. My talk was later in the day, so in the time leading up to the talk I was sniffing the wireless. (I wasn't alone, MANY other people were also sniffing the wireless). I started my talk by showing the sorts of things I could sniff about somebody, such as their AIM buddy list, their DNS requests, alternate e-mail addresses they use, and so forth. The person I showed was somebody that had a diverse set of information, but not somebody who was doing anything embarrassing. I specifically chose NOT to 'out' the attendee who was surfing gay porn during the talks (although I probably should have, since virtually nobody who goes to cybersecurity cons would be embarrassed by surfing gay porn). However, even if nothing embarrassing is shown, it's still embarrassing feeling a bit exposed like that (although, I should repeat: a lot of people will sniffing the traffic as well, my talk just exposed it).
The moral of the story is: DON'T USE OPEN WIFI AT CYBERSECURITY CONVENTIONS. Seriously, any wifi is dangerous. The dangers are:
1. I can sniff more interesting bits out of your traffic than you realize
2. I can hijack (or "sidejack") the web accounts you log onto
3. I can grab control of your browser (download history, cached passwords, etc.)
4. I can probably break into your machine
5. This works on Internet Explorer and Firefox on Mac, Linux, and Windows
6. …all using well-known, unpatched (and often unpatchable) techniques
I've already released my Ferret tool that sniffs interesting info (like I showed at the start of my talk). I'm going to be releasing my "sidejacking" tool that sniffs Web/2.0 session IDs, allow other people on the same wifi to gain access to your accounts even without man-in-the-middle attacks. I'm going to be releasing a "man-in-the-middle" tool that inserts JavaScript into your browser, essentially making every website you visit vulnerable to Cross Site Scripting (XSS) attacks against your browser.
There are two good alternatives to public wifi. The first is to setup a box at home and VPN to it, and harden the wifi adapter so that none of your normal system applications (e.g. NetBIOS) are bound to it.
The second alternative is mobile broadband like GPRS, EDGE, HSDPA, or EVDO. You can often access the Internet by "tethering" your mobile phone, or get one of the new notebooks with built-in adapters.
It's interesting to see that public wifi is still growing fast, with cities all across the United State creating municipal wifi networks. This means that more and more hackers will be attacking it. Now is a good time to start weaning yourself off of it.
I want to apologize for my talk. My talk was later in the day, so in the time leading up to the talk I was sniffing the wireless. (I wasn't alone, MANY other people were also sniffing the wireless). I started my talk by showing the sorts of things I could sniff about somebody, such as their AIM buddy list, their DNS requests, alternate e-mail addresses they use, and so forth. The person I showed was somebody that had a diverse set of information, but not somebody who was doing anything embarrassing. I specifically chose NOT to 'out' the attendee who was surfing gay porn during the talks (although I probably should have, since virtually nobody who goes to cybersecurity cons would be embarrassed by surfing gay porn). However, even if nothing embarrassing is shown, it's still embarrassing feeling a bit exposed like that (although, I should repeat: a lot of people will sniffing the traffic as well, my talk just exposed it).
The moral of the story is: DON'T USE OPEN WIFI AT CYBERSECURITY CONVENTIONS. Seriously, any wifi is dangerous. The dangers are:
1. I can sniff more interesting bits out of your traffic than you realize
2. I can hijack (or "sidejack") the web accounts you log onto
3. I can grab control of your browser (download history, cached passwords, etc.)
4. I can probably break into your machine
5. This works on Internet Explorer and Firefox on Mac, Linux, and Windows
6. …all using well-known, unpatched (and often unpatchable) techniques
I've already released my Ferret tool that sniffs interesting info (like I showed at the start of my talk). I'm going to be releasing my "sidejacking" tool that sniffs Web/2.0 session IDs, allow other people on the same wifi to gain access to your accounts even without man-in-the-middle attacks. I'm going to be releasing a "man-in-the-middle" tool that inserts JavaScript into your browser, essentially making every website you visit vulnerable to Cross Site Scripting (XSS) attacks against your browser.
There are two good alternatives to public wifi. The first is to setup a box at home and VPN to it, and harden the wifi adapter so that none of your normal system applications (e.g. NetBIOS) are bound to it.
The second alternative is mobile broadband like GPRS, EDGE, HSDPA, or EVDO. You can often access the Internet by "tethering" your mobile phone, or get one of the new notebooks with built-in adapters.
It's interesting to see that public wifi is still growing fast, with cities all across the United State creating municipal wifi networks. This means that more and more hackers will be attacking it. Now is a good time to start weaning yourself off of it.
Saturday, May 12, 2007
Toorcon Beta
I am sure you expect me to post about Bluehat as both Rob and I talked there. We are currently sitting in the Last Supper Club watching the Toorcon Beta.
Beetle is up now talking about Wi-Fight Club. He is a great speaker and the concept s super cool!
Beetle is up now talking about Wi-Fight Club. He is a great speaker and the concept s super cool!
UPDATE: The next talk I really dug was the Pusscat talk on automating exploitation. The lowdown on is that Pusscat (mad reverse engineer badass) and lin0xx have combined Metasploit fuzzing and Windbg debugging to do automated exploit analysis. This stuff is super cool.
Lin0xx has more information on his site, here.
Subscribe to:
Posts (Atom)