At November's Grand Rapids ISSA meeting, Tim Crothers gave an awesome preso on malware analysis. In it, he provided a value proposition for using honeypots in corporate network security. Up until this November, I had always considered honeypots a tool for AV and IDS R&D folks, but Tim demonstrated how to work Nepenthes into network security ops. I was inspired by his talk and promptly took his idea home and set set up Nepenthes and built a VMWare image for doing malware analysis and started collecting and reversing malware being passed around in the wild. Mas alegria!
As much fun as I was having at home, when it came to operationalizing Nepenthes at work, I had a problem. Collecting malware that spread via network services might not be all that useful since all workstations have 1 client firewall, and all laptops have a second that is bundled with the VPN client. Malware that Nepenthes would collect from the network would not affect these workstations because they malware would never connect regardless of whether the workstation was vulnerable. As such, all of the malware I have chased down over the past couple of years either came in via IE/Outlook exploit, e-mail attachment, or as an infected installer/program that a user downloaded.
That got me thinking about ways to collect malware that relies on browser exploits. This is much harder to do and requires a number of things that have security implications of their own, like parsing or executing JavaScript to find the downloader URL. And then there's the issue of determining what and when to crawl looking for these. Should you look for "fertile ground" like MySpace, replicate real web traffic from proxy logs, use Google, or what? Of course, I have no working code to offer. But like most good ideas, it's hard to have an exclusive or original one. And if you said, "I bet Lance Spitzner already thought of this." you'd be totally right. Of course, honeyclient is old news as it turns out, and seems to be dead in the water anyway. But more along the lines of what I was thinking, and more similar to Nepenthes, there are Capture and HoneyC, self-described low interaction honeyclients.
Of the two, HoneyC takes the least amount of effort to get up and running. It's a web honeyclient written entirely in Ruby, and a lot more like what I had in mind. It uses the Yahoo API to search and crawl for suspicious pages. It's too early for me to say how accurate it is, but it was definitely painless to get it configured based on my own search criteria and turn it loose. It will take some more work to build some intelligence into my searches (more proxy logs!) and some effort to develop some useful (Snort-like) signatures, but this looks very promising. I'll report back by the end of March with more on how this is going.
Tuesday, February 27, 2007
Thursday, February 22, 2007
GRSec Blog Online
The GRSec Blog is now online and very much empty. I will be posting pictures from the first meetup as well as information about upcoming meetups here. I'm also looking for a volunteer or two to co-moderate/co-author this blog. It won't be much work, but you never know, I might take a vacation or something.
Wednesday, February 21, 2007
Useless Statistics, Part Deux
It's so easy to pick on some of the stuff that comes across Dark Reading. But something being easy never stopped me from doing it, especially if it involves scornful derision. :-)
nCircle published the results of a survey today that indicate that 2/3 of [83] security professionals believe that their data is less secure today than it was 24 months ago. I will forgo the rant about bad data and statistics and instead point out that what nCircle has really done is highlight an issue of perception and definition that exists across infosec today.
What these results really tell me, if anything, is that only one in three infosec pros recognized this trick question for what it is. Your data is no less secure today than it was 2 years ago because your data was in approximately as many places, transmitted and traded just as freely, protected just as poorly, and sought by organized crime and bot herders just as much. Simply because disclosure laws have forced the issue into the media, people perceive things as being worse. But they're not. In other words, relax Chicken Little, it's been raining sky for years now.
nCircle published the results of a survey today that indicate that 2/3 of [83] security professionals believe that their data is less secure today than it was 24 months ago. I will forgo the rant about bad data and statistics and instead point out that what nCircle has really done is highlight an issue of perception and definition that exists across infosec today.
What these results really tell me, if anything, is that only one in three infosec pros recognized this trick question for what it is. Your data is no less secure today than it was 2 years ago because your data was in approximately as many places, transmitted and traded just as freely, protected just as poorly, and sought by organized crime and bot herders just as much. Simply because disclosure laws have forced the issue into the media, people perceive things as being worse. But they're not. In other words, relax Chicken Little, it's been raining sky for years now.
Monday, February 19, 2007
Reminder: GRSec is Wednesday 2/21 !
If you are in West Michigan, the Inaugural GRSec meetup is this Wednesday at 5:30pm at GRBC.
Hope to see lots of people there!
Hope to see lots of people there!
Tuesday, February 13, 2007
I am SO NOT a developer
I came up in IT as a sysadmin, and though I have a few semesters of formal education in C and C++, what I know best are scripting languages - MS-DOS batch, UNIX shell, and Perl.
There is an undeniable trend toward the widespread use of Python in the infosec industry. I was finally convinced of this when I recently got a sneak peek of a commercial app that is going to offer a Python stepping interface to its scanning engine. Very cool. And we bought it... so, I better learn how to use it.
To prepare myself, I wrote my first Python program. It replaces a shell script hack that I wrote a year or two ago that basically does bulk DNS reverse-lookups on large IP ranges. To be cool, and to prepare for working with a scanning engine, I decided to use threading.
I've been working on it in small bursts over the past two weeks, and as of this morning I have something that works very well. I also have to say, it wasn't much harder than working with Perl. It took a little Googling to find the dnspython libraries, which I used instead of writing my own DNS query code. Once I had that working, the rest was pretty straightforward. Using threading was painless, and well worth the effort. Compared to the shell script it replaces, the Python program is smoking fast, as you would expect.
Mostly this post is me patting myself on the back, but what I wanted to impart to the other non-coders that might read this is that if I can muddle out 20 lines of working Python code, you can too.
There is an undeniable trend toward the widespread use of Python in the infosec industry. I was finally convinced of this when I recently got a sneak peek of a commercial app that is going to offer a Python stepping interface to its scanning engine. Very cool. And we bought it... so, I better learn how to use it.
To prepare myself, I wrote my first Python program. It replaces a shell script hack that I wrote a year or two ago that basically does bulk DNS reverse-lookups on large IP ranges. To be cool, and to prepare for working with a scanning engine, I decided to use threading.
I've been working on it in small bursts over the past two weeks, and as of this morning I have something that works very well. I also have to say, it wasn't much harder than working with Perl. It took a little Googling to find the dnspython libraries, which I used instead of writing my own DNS query code. Once I had that working, the rest was pretty straightforward. Using threading was painless, and well worth the effort. Compared to the shell script it replaces, the Python program is smoking fast, as you would expect.
Mostly this post is me patting myself on the back, but what I wanted to impart to the other non-coders that might read this is that if I can muddle out 20 lines of working Python code, you can too.
Useless Statistics
Today, Dark Reading posted a press release from web-app-sec vendor Acunetix that claims, "70% of Websites Hackable." This is based on the results of 10,000 scans of 3,200 sites with Acunetix free on-line scanner. One word: useless.
First, Acunetix uses the free scanner in its sales cycle to attract clients that might buy their full-featured scanner. So, it would be safe to say that some fraction of targets scanned were HacMe sites that are intentionally vulnerable to SQL injection and XSS.
Second, there's absolutely no way that an automated scanning tool can assess the "hackability" of a web application. I used to do lots of web-app-sec work, with and without scanners, and here's the thing: inserting '%27%2D%2D' into a URL and getting a 500 code back from the web server doesn't mean that SQL injection is possible, let alone that that SQL injection will lead to a compromise of the application. All it means is that something, somewhere, did a poor job of handling input.
Third, the tell-tale sign that this "article" is meaningless is that all of the quotes from Acunetix come from Kevin Vella, their sales veep.
But here's the bone I'm going to throw Kevin; based on my experience, 70% is a conservative estimate. Maybe things have changed for the better in the two years since I was doing live web-app-sec work, but I would put that number between 85-90% in terms of sites where privilege escalation is possible within the app.
Update: It seems that the idiocy surrounding this thing knows no bounds. Watch as Paul McNamara and Joel Snyder of NetworkWorld throw their careers away over a piece of marketing. Hope that story was online only. Thanks to Thomas Ptacek at Matasano for pointing out this fascinating turn of events.
Update II: It's a train wreck. Snyder responded to criticisms yesterday by backpedaling and changing his story to something more rational. (And it sounds an awful lot like my second point from Tuesday.) But he can't un-ring that $1,000.00 bell. I have changed my mind about Acunetix's part in all of this - I wish them all of the free press they can gain at the expense of Joel Snyder. Naturally, Tom at Matasano has a nice analysis of Joel's rambling Slashdot post.
First, Acunetix uses the free scanner in its sales cycle to attract clients that might buy their full-featured scanner. So, it would be safe to say that some fraction of targets scanned were HacMe sites that are intentionally vulnerable to SQL injection and XSS.
Second, there's absolutely no way that an automated scanning tool can assess the "hackability" of a web application. I used to do lots of web-app-sec work, with and without scanners, and here's the thing: inserting '%27%2D%2D' into a URL and getting a 500 code back from the web server doesn't mean that SQL injection is possible, let alone that that SQL injection will lead to a compromise of the application. All it means is that something, somewhere, did a poor job of handling input.
Third, the tell-tale sign that this "article" is meaningless is that all of the quotes from Acunetix come from Kevin Vella, their sales veep.
But here's the bone I'm going to throw Kevin; based on my experience, 70% is a conservative estimate. Maybe things have changed for the better in the two years since I was doing live web-app-sec work, but I would put that number between 85-90% in terms of sites where privilege escalation is possible within the app.
Update: It seems that the idiocy surrounding this thing knows no bounds. Watch as Paul McNamara and Joel Snyder of NetworkWorld throw their careers away over a piece of marketing. Hope that story was online only. Thanks to Thomas Ptacek at Matasano for pointing out this fascinating turn of events.
Update II: It's a train wreck. Snyder responded to criticisms yesterday by backpedaling and changing his story to something more rational. (And it sounds an awful lot like my second point from Tuesday.) But he can't un-ring that $1,000.00 bell. I have changed my mind about Acunetix's part in all of this - I wish them all of the free press they can gain at the expense of Joel Snyder. Naturally, Tom at Matasano has a nice analysis of Joel's rambling Slashdot post.
Not What Marty Had In Mind...
Even though it has the reputation of being the more secure browser of the two, early versions of Firefox lack a feature that IE has had for a long time - automatic updates. The end result is that there are probably some old, vulnerable versions of Firefox running on your network. So, I wrote some Snort signatures to take a quick poll for old versions of Firefox. Not what your IDS was intended for, but it works. (And it's cheaper than a software management rootkit like Unicenter or Altiris.)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version 1.5"; content:"User-Agent|3A|"; pcre:"/Firefox\/1.5.0.[0-6]/"; sid:9000040; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version 1.0"; content:"User-Agent|3A|"; content:"Firefox/1.0"; sid:9000041; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version 0.x"; content:"User-Agent|3A|"; content:"Firefox/0."; sid:9000042; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version 0.9.2"; content:"User-Agent|3A|"; content:"Firefox 0.9"; sid:9000043; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version Mozilla 7"; content:"User-Agent|3A|"; content:"Firefox 7"; sid:9000044; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version 0.9.3"; content:"User-Agent|3A|"; content:"Firefox_123"; sid:9000045; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version 1.1"; content:"User-Agent|3A|"; content:"Firefox/1.1"; sid:9000046; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version 1.2"; content:"User-Agent|3A|"; content:"Firefox/1.2"; sid:9000047; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version 1.4"; content:"User-Agent|3A|"; content:"Firefox/1.4"; sid:9000048; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version 1.5 RC"; content:"User-Agent|3A|"; content:"Firefox/1.5 RC"; sid:9000049; rev:1;)
Since these signatures look for the User-Agent client header, these will alert on every HTTP request from an old version, so these can be very, very noisy. I recommend turning them on, getting a list of machines, turning them off, getting those browsers upgraded; lather, rinse, repeat.
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version 1.5"; content:"User-Agent|3A|"; pcre:"/Firefox\/1.5.0.[0-6]/"; sid:9000040; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version 1.0"; content:"User-Agent|3A|"; content:"Firefox/1.0"; sid:9000041; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version 0.x"; content:"User-Agent|3A|"; content:"Firefox/0."; sid:9000042; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version 0.9.2"; content:"User-Agent|3A|"; content:"Firefox 0.9"; sid:9000043; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version Mozilla 7"; content:"User-Agent|3A|"; content:"Firefox 7"; sid:9000044; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version 0.9.3"; content:"User-Agent|3A|"; content:"Firefox_123"; sid:9000045; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version 1.1"; content:"User-Agent|3A|"; content:"Firefox/1.1"; sid:9000046; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version 1.2"; content:"User-Agent|3A|"; content:"Firefox/1.2"; sid:9000047; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version 1.4"; content:"User-Agent|3A|"; content:"Firefox/1.4"; sid:9000048; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Vulnerable Firefox Version 1.5 RC"; content:"User-Agent|3A|"; content:"Firefox/1.5 RC"; sid:9000049; rev:1;)
Since these signatures look for the User-Agent client header, these will alert on every HTTP request from an old version, so these can be very, very noisy. I recommend turning them on, getting a list of machines, turning them off, getting those browsers upgraded; lather, rinse, repeat.
Blocking Teredo
Teredo is Microsoft's IPv6-over-IPv4 tunneling protocol. Rather than rehash the security implications of Teredo or tunneling protocols in general, I'll just point out that you can read about it here.
Teredo has been available for awhile on XP, but as Vista clients have started popping up, I am noticing that despite Microsoft's claims to the contrary, Teredo seems to be active by default, at least on the Vista machines we've loaded from the MSDN image.
It will show up in your firewall logs as traffic to udp/3544 with a destination IP that resolves to teredo.ipv6.microsoft.com. And, of course, it defeats all of your firewall's security goodness. This is why you should restrict outbound traffic to only that traffic that is necessary for business purposes. But that's hard to do. Seriously. It's even harder to move from a default allow to a default deny. More on that later.
Teredo has been available for awhile on XP, but as Vista clients have started popping up, I am noticing that despite Microsoft's claims to the contrary, Teredo seems to be active by default, at least on the Vista machines we've loaded from the MSDN image.
It will show up in your firewall logs as traffic to udp/3544 with a destination IP that resolves to teredo.ipv6.microsoft.com. And, of course, it defeats all of your firewall's security goodness. This is why you should restrict outbound traffic to only that traffic that is necessary for business purposes. But that's hard to do. Seriously. It's even harder to move from a default allow to a default deny. More on that later.
Wednesday, February 7, 2007
Drive Encryption
Full-disk encryption products like Pointsec are a flash in the pan. A lot of time and energy is being spent right now on encrypting laptop hard drives to stem the tide of stolen data. But five years from now, we won't be talking about it. Disk encryption that is good enough to be compliant, if not effective, is commodity technology. You will be able to get it cheaply, and from a variety of vendors in the immediate future.
If you are an end user, the cheaper options probably work for you right now. If you are a large company, replacing thousands of hard drives or upgrading to Vista is a huge job with huge costs, and it's probably cheaper to buy a third-party encryption product. Unpleasant as the prospect of a big, expensive software rollout is, the alternative sucks. So, git-r-done already.
Some advice on third-party products:
If you are an end user, the cheaper options probably work for you right now. If you are a large company, replacing thousands of hard drives or upgrading to Vista is a huge job with huge costs, and it's probably cheaper to buy a third-party encryption product. Unpleasant as the prospect of a big, expensive software rollout is, the alternative sucks. So, git-r-done already.
Some advice on third-party products:
- Test. And I don't just mean functionality. At least a couple of the products in Gartner's Magic Quadrant have glaring design holes in them. The kind that make it possible to bypass the product altogether in certain configurations. Oops!
- Be thinking about your roll-out when you pick a product. Easy deployment and stable performance are worth probably $40-50/seat in terms of cost savings for the relatively short life of this project.
- Don't buy the 5-year support contract. If you plan to still have this stuff in wide deployment in 5 years, then you've also just finished deploying Windows 2000 SP4 and you've got bigger issues than laptop theft. Face it, nobody's going to steal your Celeron-366 laptops anyway.
- Think past the short-term fix. Buy and apply a bandage now. Spend more time planning and less money buying your next drive encryption solution. And if you're going to use something that requires new hardware, start buying today.
Monday, February 5, 2007
GRSec Inaugural Meetup 2/21
What: GRSec Meetup
When: 02/21/2007 5:30pm
Where: Grand Rapids Brewing Company
ToDo: RSVP by 2/19 if you can. If you don't RSVP, come anyway.
GRSec is a new social gathering for people involved in or interested in information security. Come talk shop with, rub elbows with, or buy drinks for other information security professionals. Connect with other people in your industry in your local area. There is no set topic or agenda. Just show up, ask questions, float ideas, or shoot the breeze.
GRSec is not an ISSA sponsored event. In fact, it's not sponsored at all, it's a casual meetup. However, ISSA members are invited to attend and encouraged to invite others who like information, security, beer, or cheese-stuffed pretzels. Despite the name, GRSec does not imply that you live or work in Grand Rapids, it only implies that you are willing to travel to Grand Rapids to hang out with infosec types.
If the first meetup is well-attended, we will try to make this a monthly thing, perhaps even over the summer (when there are no ISSA meetings and the patios are open!). So also bring suggestions for meeting locations and help get the word out.
When: 02/21/2007 5:30pm
Where: Grand Rapids Brewing Company
ToDo: RSVP by 2/19 if you can. If you don't RSVP, come anyway.
GRSec is a new social gathering for people involved in or interested in information security. Come talk shop with, rub elbows with, or buy drinks for other information security professionals. Connect with other people in your industry in your local area. There is no set topic or agenda. Just show up, ask questions, float ideas, or shoot the breeze.
GRSec is not an ISSA sponsored event. In fact, it's not sponsored at all, it's a casual meetup. However, ISSA members are invited to attend and encouraged to invite others who like information, security, beer, or cheese-stuffed pretzels. Despite the name, GRSec does not imply that you live or work in Grand Rapids, it only implies that you are willing to travel to Grand Rapids to hang out with infosec types.
If the first meetup is well-attended, we will try to make this a monthly thing, perhaps even over the summer (when there are no ISSA meetings and the patios are open!). So also bring suggestions for meeting locations and help get the word out.