John 1.7 released
If you follow such things, John the Ripper 1.7 is out. There are some pretty big-looking performance increases over the 1.6 release, so this is probably worth looking into if you need to crack passwords.
Network Security Monitoring (NSM), general InfoSec commentary and just a hint of cinnamon.
If you follow such things, John the Ripper 1.7 is out. There are some pretty big-looking performance increases over the 1.6 release, so this is probably worth looking into if you need to crack passwords.
Posted by DavidJBianco at 8:43 AM 0 comments
I ran across this USAToday article that introduces a new idea in the fight against adware, spyware and other deceptive software distribution practices: public shaming. StopBadware.org is a clearinghouse for reports of software distributed with pernicious "extras".
The site is run as a cooperative venture between Harvard's Berkman Center for Internet & Society, The Oxford Internet Institute and Consumer Reports WebWatch. Before downloading software, users can check StopBadware.org to see what they're really getting along with that elf-bowling game. It's a community-driven effort that relies on users to submit reports for inclusion in the database, so there are no listings yet (it just opened up today).
This is a fabulous idea. Most legitimate software distributors would be loath to see themselves listed on this site, and maybe it will spur them to clean up their act. However, the best thing about this site is their set of guidelines for software publishers. It reads very much like a software downloader's "bill of rights". For example, clause #2 states:
2. Prohibited Behavior. An application must not engage in deceptive, unfair, harassing or otherwise annoying practices. For example, an application must not:
(a) use an end user's computer system for any purpose not understood and affirmatively consented to by the end user. This includes: for purposes of consuming bandwidth or computer resources, sending email messages, launching denial of service attacks, accruing toll charges through a dialer or obtaining personal information from an end user's computer such as login, password, or other account information;
(b) intentionally create or exploit any security vulnerabilities in end user computers to cause the computer to malfunction;
(c) trigger unwanted pop-ups, pop-unders, exit windows, or similar obstructive or intrusive functionality, that materially interfere with an end user's Web navigation or browsing or the use of his or her computer;
(d) repeatedly ask an end user to take, or try to deceive an end user into taking, a previously declined action (such as repeatedly asking an end user to change his or her home page or some other setting or configuration);
(e) redirect browser traffic away from valid DNS entries. (Except for applications that direct unresolved URLs to an alternative URL, provided that the destination page adequately informs the end user of the source of that page); or,
(f) interfere with the browser default search functionality. (Except that an application may permit an end user to change his or her default search engine with proper disclosure, consent and attribution).
Here's a simple list of 6 things that software should never do, yet we see examples of each behavior every day. If software publishers stuck to this list, there would be no need for StopBadware.org. Until they do, though, you know where to look before downloading.
Posted by DavidJBianco at 8:07 AM 0 comments
Our local chapters of the ISSA, Infragard and ASIS are doing something smart: they're teaming up for quarterly joint meetings. I attended their first joint meeting this evening, and was impressed.
The first order of business after dinner was a brief introductory talk by the new SAC in charge of the local (Norfolk, VA) FBI field office, SAC Cassandra Chandler. SAC Chandler only spoke for about five minutes, but she had the audience in the palm of her hand. Infragard is an FBI-sponsored organization, and she emphasized the value that the organization provides to its members and to the FBI. I was very pleased that she pledged not only to continue to support the local chapter, but also to increase the level of support over time. By the end of her pep talk, I was ready to join myself!
The second speaker was Mr. Ron Kidd from the Regional Organized Crime Information Center in Nashville, TN. The ROCIC is one of several law enforcement related agencies that are cooperating on a project called the Automated Trusted Information Exchange (ATIX). ATIX is like a community of first responders from various government and industry first responders who get together to share information related to their particular professional "community". The idea is to help these responders prepare for disasters (natural or otherwise) by helping them keep up-to-date on current happenings that affect their field. For example, there's an ATIX community for public utilities, one for fire and rescue, etc. There was even one for the agricultural sector, with the sample page showing an article on agroterrorism.
ATIX provides its members a secure forum for posting news, information, links, articles, emails and other information of interest to first responders. Think "Internet Storm Center meets Wikipedia". A good idea, though it seems onerous to get to (you need their special access software, no doubt Windows-only) and, as the comparison to Wikipedia implies, there is essentially no fact-checking done for the information submitted by users. Still, there are useful features, like the page where you type in any cargo container ID number and it tells you the contents.
The theme for the evening was that we need more information sharing among the good guys. I agree wholeheartedly, but I was left wondering "Where are the people who make it all happen?" Our local ISSA, ASIS and Infragard chapters seem to be very management heavy, but light on the technical folks who can actually understand the issues and are in positions to do something about them. That's regrettable, and makes me wonder if these groups are having as much effect as they could.
On a side note, I did score this cool medallion from a friend of mine at the Navy Network Warfare Command, in return for a tour of our facilities. He's one of the people who "make it all happen", so I'm glad he goes to these meetings. Now if we can only get a few more like him to get out there and do some of that other kind of networking, we might have a shot at keeping ahead of the Bad Guys.
Posted by DavidJBianco at 10:29 PM 2 comments
The February meeting of the Hampton Roads Snort Users' Group (HRSUG) will be held at 7:00PM, Wednesday February 8th. We're fortunate enough to have Sourcefire's Judy Novak as our guest speaker. I've included Judy's bio and presentation abstract below. She literally "wrote the book" on Intrusion Detection, so I know you won't want to miss her presentation!
Date: 8 Feb 2006
Time: 7:00PM
Place: Williamsburg Regional Library
515 Scotland Street
Williamsburg, VA
(757) 259-4040
Posted by DavidJBianco at 4:03 PM 0 comments
Labels: Snort
Having recently returned from ShmooCon 2006 (and having further spent most of yesterday resting and recovering), here's my brief writeup: "Go next year."
Ok, here's my slightly less brief writeup. I arrived around 1:00PM Friday. Giant kudos to the registration team, who checked me in without delay. In fact, they checked in nearly everyone without delay, thanks to the nifty bar codes they emailed to the registered attendees. Print it out, scan it and get a conference bag. It was great. What was even better about it was that the badges had no name tag. They were just (sharp) metal access tokens, and if you had on around your neck, you were in. Good for anonymity, though a little annoying at times when I think I should know someone's name, but don't.
I don't want to give a blow-by-blow account, because
Posted by DavidJBianco at 1:12 PM 0 comments
I'd like to remind everyone that the January meeting of the Hampton Roads Snort Users Group (HRSUG) will be held this Wednesday, January 11th at 7:00PM. This will be an important meeting, since we will open the nominations for the positions of Chair and Vice Chair. These are light-duty positions, mostly consisting of filling out the library's reservation sheets every month to get the meeting room and helping to arrange for a presentation. Please consider nominating yourself or another member for one of these positions.
As for a technical presentation, I will be demoing sguil, an open source Network Security Monitoring (NSM) tool. Sguil incorporates NIDS information (snort), network session data and packet logging into a single analyst console/research tool. I'll be showing how sguil can help you save time, save money and improve your detection program at the same time. Part of the presentation details exactly how I used sguil to investigate an attempted WMF exploit being delivered by popup ads. If the Internet connection works out, we can even do a live demo.
Location details are below. Hope to see you there!
Date: 11 Jan 2006
Time: 7:00PM
Place: Williamsburg Regional Library
515 Scotland Street
Williamsburg, VA
(757) 259-4040
Meeting room B
Posted by DavidJBianco at 10:07 PM 0 comments
Going to ShmooCon 2006 next week? So is sguil! Fellow sguil project member Richard Bejtlich will present sguil in a talk entitled Network Security Monitoring with Sguil. As part of this session, Richard has invited me to present a case study on how I used sguil to investigate my recent WMF exploit attempt. Should be a lot of fun!
Posted by DavidJBianco at 12:11 PM 1 comments
There has been a lot of discussion about the Microsoft WMF vulnerability recently, and I frankly don't feel that I have much to add. You're either already taking preventative measures, you're awaiting the patch, or both. But I came across a particular infection attempt today which, while not unusual, is a good example of how an exploit for this sort of vulnerability could get delivered to a victim's PC even without them necessarily doing anything "risky". It happens to involve a WMF file, but I've seen it in the past with other types of image-related vulnerabilities as well.
IMPORTANT SAFETY NOTE: This information is based on an actual incident. I have obscured the names of most of the systems involved in part to protect the reputations of their owners, but mostly to prevent people from trying to click on them.
The scenario begins as the user (we'll call him Fred) is browsing through a popular website, in this case MySpace.com, but really it it wasn't involved in the attack itself. I only include it here because it's the start of the "web session" the user was involved in, and so it also seemed like a logical place to pick up the narrative.
In case you don't have a teenager, MySpace is a free online community that's insanely popular <old_fart>amongst the youth of today</old_fart>. It's kind of like a cross between a free website host, a blog and IM all rolled into one. The point is that each MySpace user gets their own web page/blog/buddy list/chat board page to do with as they wish. Other registered MySpace users can post messages of their own on the page when they visit, and these are automatically tagged with the visitor's name and personalized photo or icon. Later, when someone views the comments, any of the posters who happen to also be using MySpace at the time will also have a special "online" indicator displayed beside their name.
All these messages, icons and status indicators are user-customizable, and this drives many people to learn some basic HTML. Of course, if you don't feel like learning HTML, you can go to any number of websites that will generate HTML on the fly for you to paste into your own web pages.
So Fred was viewing someone's MySpace page, and apparently one of the posters was online at the time. That caused their "online status" icon to be displayed along with their name, and apparently this was linked back to one of these HTML helper websites, from which it had originally been generated. We'll call the site HTMHelper (not the real name, but the exact site isn't important either).
Here's where it starts to get interesting.
HTMHelper has many pages and is quite extensive. To help support this service, the site owners have made deals to display ads from several ad distribution companies. The HTMHelper page contained a small bit of JavaScript code to generate "pop under" ads (like popups, but they appear under your browser window so you don't see them until later). The ad provider, let's call them cash4popupads.com, is part of a whole
chain of (often sleazy) ad brokers, and it's quite common for ad brokers to get ads from other ad brokers, who got them from other ad brokers, who get them from... you get the idea. Ultimately, there is an individual who registers with one of these ad distribution services, but there are usually several levels between the person
placing the ads and the service that eventually places it on a web page where you'll see it.
In this case, cash4popupads displayed a popunder window that contained nothing but a redirection to the real ad, hosted on a server operated by a site we'll call spf99.biz. Technically, it was an invisible 1 pixel square IFRAME, but you get the idea. cash4popupads was just the conduit, while spf99 served the ad itself.
Spf99 is registered in Herndon, VA, by the way. It doesn't make any difference to this story, but it's an interesting fact. There are a lot of government and government contractors in that area, since it's basically part of the whole Washington DC/Northern VA megalopolis, but that could just be a geographical coincidence. I have no way of knowing, but it did make me wonder.
Spf99 served up the actual infected file, "/tape/XXXXX101.wmf". Their internal tracking number indicates that this file was supplied by customer number 101 ("affiliate=101" was part of the URL). I don't know who affiliate 101 is, and it could very well be another ad distribution company.
In case you missed the implication, ad services don't work for free. Everyone along the way has to take a cut from every ad delivery and/or clickthrough. This means that whoever supplied the file had enough money to pay for it to be widely distributed through the various levels of the ad networks.
If you've followed the security news through 2005, you'll know that the lone hacker is on the way out, and nation states and organized crime are where the serious hacking is going on now. This is a good example of that trend. In the past, someone would get a website with a free hosting provider and then try to get people to visit their site by sending spam, posting to discussion forums or using some similar technique. That's inefficient, so now they just pay ad networks to distribute their exploits for them. They don't do this unless they're expecting a healthy return on their investment, of course.
Anyway, I thought this might be an interesting peek into the seamy side of exploit distribution, and quite timely too, since we've recently been discussing this particular exploit. Hope you enjoyed it.
Update 2006-01-05 06:49:00
I should have mentioned this before, but all this analysis was made possible by sguil. A Snort alert tipped me off to the exploit attempt itself, and I generated an ASCII session transcript from the packet logs to verify it. I was then able to search through all network sessions involving the target machine around that time, and used additional transcripts of those sessions to establish the chain of events leading up to the exploit attempt itself. I even recovered the WMF file from the packet logs and was able to search network sessions for the download server listed within, which was a great way to verify that the exploit had not been successful. Network Security Monitoring to the rescue!
Posted by DavidJBianco at 7:35 PM 0 comments
Judging by their latest entry, the Internet Storm Center is experiencing just a little frustration over the whole Microsoft WMF thing. I can't say that I blame them at all, I just think it's amusing, and Microsoft's response to the whole thing has been a farce.
Posted by DavidJBianco at 1:51 PM 0 comments
While catching up on the mailing list traffic I skipped over the holidays, I read this post on DailyDave. The email deals with SIM technology, specifically the feasibility of a good Open Source SIM. The section below (by Anton Chuvakin) caught my eye:
IMHO, Sguil follows a wrong model, since it requires a smart analyst in front of the console, something that most companies likely won't afford.
I don't want to start a fight, but I've been seeing a lot of recent references implying that sguil is a SIM, or that it competes with/replaces SIMs. That could not be further from the truth. Here's the reply I sent to the mailing list:
Don't confuse sguil with a SIM. SIM implies a level of aggregation and automation that is not appropriate for this type of Network Security Monitoring (NSM) tool. Although there are superficial similarities, they're not intended for the same purpose.
Sguil is simply a research tool for a number of specialized databases (starting with NIDS, session and pcap data). It relies on a trained analyst simply because it's not possible to do otherwise. The Bad Guys are smart, and their capacity for underhandedness far exceeds the ability of software to detect or respond. Trained security personnel are indispensable not only for their ability to detect misuse, but also for their reasoning skills and their investigatory capacity. These are the sorts of operations sguil is designed to support.
If you want to talk about following the wrong model, trying to replace trained security personnel with a software solution is pretty high up on the list.
My fellow #snort-gui channel monkey jofny also had this to say:
A SIM's job is to present analysts with event combinations of interest which are unusual or otherwise show additional evidence of being worth investigating beyond what is presented by individual sensors/events
This is entirely correct, and it really points to the difference between NSM and SIM. Although a SIM might tip you off about a possible problem, you need an dedicated NSM solution (like sguil) to support a more detailed analysis. This implies that it's quite possible, and maybe even desirable, to run both SIM and NSM solutions in a complementary fashion.
I hope this clears things up a bit.
Update 2006-01-03 13:13: TaoSecurity has picked this up, too. I especially like the detailed comment someone left.
Posted by DavidJBianco at 10:14 AM 2 comments