Diaries

Published: 2006-11-29

New Adobe vulnerability

Frank Klein has written to let us know that there are new vulnerabilities in Adobe Acrobat and Acrobat Reader that have the potential for code execution as a result of incorrect argument handling in the ActiveX control for IE. There is no patch currently available and Adobe is offering a mitigation of deleting the control. FrSIRT has provided a kill bit option that you can set that should disable the control.

The vulnerable versions are:
Adobe Standard, Reader & Professional 7.0.0 - 7.0.8

http://www.frsirt.com/english/advisories/2006/4751
http://www.adobe.com/support/security/advisories/apsa06-02.html

0 Comments

Published: 2006-11-29

Week of Oracle bugs cancelled

Argeniss has cancelled the week of Oracle bugs due to "many problems".
http://www.argeniss.com/woodb.html
We are left to our own imaginations to figure out what those might be.

0 Comments

Published: 2006-11-29

New Vulnerability Announcement and patches from Apple

Apple has just released a new security update with a large number of vulnerabilities fixed. Full details are available at:
http://docs.info.apple.com/article.html?artnum=304829
Here are the packages updated:
  • AirPort - CVE-ID: CVE-2006-5710 *
  • ATS - CVE-ID: CVE-2006-4396
  • ATS - CVE-ID: CVE-2006-4398
  • ATS - CVE-ID: CVE-2006-4400 *
  • CFNetwork - CVE-ID: CVE-2006-4401
  • ClamAV - CVE-ID: CVE-2006-4182 *
  • Finder - CVE-ID: CVE-2006-4402 *
  • ftpd - CVE-ID: CVE-2006-4403
  • gnuzip - CVE-ID: CVE-2006-4334, CVE-2006-4335, CVE-2006-4336, CVE-2006-4337, CVE-2006-4338
  • Installer - CVE-ID: CVE-2006-4404
  • OpenSSL - CVE-ID: CVE-2006-2937, CVE-2006-2940, CVE-2006-3738, CVE-2006-4339, CVE-2006-4343
  • perl - CVE-ID: CVE-2005-3962 *
  • PHP - CVE-ID: CVE-2006-1490, CVE-2006-1990 *
  • PHP - CVE-ID: CVE-2006-5465 *
  • PPP - CVE-ID: CVE-2006-4406 *
  • Samba - CVE-ID: CVE-2006-3403
  • Security Framework - CVE-ID: CVE-2006-4407
  • Security Framework - CVE-ID: CVE-2006-4408
  • Security Framework - CVE-ID: CVE-2006-4409
  • Security Framework - CVE-ID: CVE-2006-4410
  • VPN - CVE-ID: CVE-2006-4411
  • WebKit - CVE-ID: CVE-2006-4412 *
* Potential code execution as defined & stated by Apple

0 Comments

Published: 2006-11-28

Phishing by proxy

Phixies, Phoxies, Phishoxies, Proxishing, reverse-proxy phishing, reverse-prophixing, reverse phoxy prish, ahhh PHOOEY!!! 

It is likely already old hand to security researchers that the evolution of phishing attacks are using a black velvet paint by numbers board of increasing complexity, but I personally have recently been witness to an increase in something *new to me* which is Phishing by Proxy...  and now quickly being followed closely by Money Mule recruitment by proxy.

I had been investigating reports of phishing and miscreant web sites being hosted in specific user land network IP space, only to discover they were not in fact malicious users and in fact innocent users who had somehow been duped and computers compromised, resulting in a proxybot infection that would phone home announcing the availability of anonymous proxy redirect services offering controllable port TCP port 80 and 443 redirects to an upstream mothership.  These bots/agents also offer DNS service at the phishers whim in acting as authoritative NS targets with fast flux domain resolution techniques often found used in short lived phishing attacks or by any other type of garbageware pushers.  All that functionality [in this variant] comes in an 11k footprint, and hasn't been well detected by AV vendors either.  The AV vendors that do offer detection [for this specific variant I am referring to] unfortunately offer only innocuous names like "Trojan-Downloader.Win32.Small.dho", or "W32/Malware" which does nothing to improve awareness of the threat.  I am in the process of beating on the vendors that still do not offer detection of this simple sample.

So getting back to the story.  I had received notice of various european financial services being proxied via these proxybotted agents, but by the time I had acquired malware samples the proxying for phishing sites had ceased and in it's stead came a wave of Money Mule recruitment sites being redirected via these proxies.  I suppose that upstream phishers ran out of individuals they could abuse in financial fraud, hence had to go on a recruitment/hiring binge.

What I have found that works reasonably well in my situation to identify these infection types going forward, is to search DNS cache dumps/logs for DNS A records that point into dynamically provisioned IP space for host domain records not belonging to any typical dynamic DNS provisioning services.  More often than not, an isolated and suspiciously named A record association pointing into wildly dynamic IP space [in my experience] implies that something wicked that way goes.  I looked at alerting based on discovered target ip/hostname phone home destinations, but that seems to me to be a game that only the running man can play.

It's an obviously serious issue when it comes to combatting the phish problem where a successful takedown of a reported phish site that is only proxy will just be removing one node from the farm, while the upstream mothership continues with a typically long shelf life due to the effective anonymity offered by proxybotted hosts.  Did I mention that I'm a master of the run-on sentance?

Do we have any collective experience out there with this particular threat type?  Any experiences to share?

William Salusky 
"Painting Phish Pictures"
Handler on Duty   Geotagged: nearby

0 Comments

Published: 2006-11-28

New and Improved Honeynet Tools availability

It's time to update your Honeynet technologies toolbelt!

While the Storm Center handlers make an effort in the timely reporting and dissemination of information regarding malware and distributed threats as they occur to keep our readers in tune with the beat of things, we can't *always* be at the cutting edge.  If you have the capability of deploying new tools and infrastructure you might consider extending your efforts to grow your organizations insight and visibility into the nefarious workings of the net.  Provided you choose to do so, or already have such efforts underway I suggest sharing with us any significant findings!

While this year has personally seemed a bit slow in the tools development and release arena, there has been a considerable flurry of activity in new tools and update releases in the publicly available and commonly used Honeynet tool suites.  I'm suddenly having trouble keeping up my own infrastructure with building and deploying these releases.  Here are a few of the recent significant updates.

Honeynet Project - HoneySnap tool

  • The python based honeysnap client is making a fresh debut at v1.0.1 and offers some reasonably nice post-processing and text based reporting on packet capture.  The Honeysnap tool can be used standalone outside of a Honeynet environment or blends nicely with any pre-existing Honeywall deployments.  I 'like' it.

Nepenthes update release from the MWCollect project

  • A favorite is the Nepenthes malware collector that grew up with mwcollect, and after combined efforts this year we've been bestowed with the recent point release of v.20.

Honeynet Project - Upcoming Honeywall improvements

  • While the Honeywall has not released updates lately, there has been some significant development effort exerted this year within the project.  I'm personally hoping the next generation makes a public release very soon.

Mitre Honeyclient project

  • There has not been any fanfare lately but there has been some motion in the Mitre Honeyclient project.  Honeyclient code has been made available for download and a fair amount of documentation is published in the project wiki. 
  • Of note, but with no insight into why it may have occurred, the Mitre honeyclient project has just recently migrated from away from the mitre.org domain out to new hosting. 
  • You should really consider deploying this type of technology if you'd like to 'literally' drive your browser crazy.  Go find some some new badness and make sure to report back on your findings.

And then there's your flow data

William Salusky 
"A Human Honeyclient"
Handler on Duty   Geotagged: nearby

0 Comments

Published: 2006-11-27

New Botnet?

We've received reports from .edu (Thanks!) of a massive new outbreak of bots exploiting the Symantec Client Security and Antivirus escalation of privilege vulnerability.  ("new" implying the outbreak, not the vulnerability :)

More details on the vulnerability here.

We have not seen the botnet here at the ISC, but if you are having experience with it, please write in via our "Contact Us" Button, and let us know!

Update #1:

Port traffic on the Symantec Client port (2967) has drastically increased in the past few days.




0 Comments

Published: 2006-11-27

Spam Increase

Thanks to the many readers who have written in.  We have received multiple reports of a big increase in spam traffic overnight.  (Heck, I've noticed it myself)

Mostly non-us based as I have noticed, and ranging from topics old and new such as Stocks, Microsoft Updates, and the nearly-famous 'Nigerean' emails.

As always make sure your users are educated as to the presence of these emails.   It's generally recomended to avoid html email totally. 

Good luck, and welcome back to work .us people!

Joel Esler

0 Comments

Published: 2006-11-26

Mailbag and DShield items generate a post VNC exploitation fun question

Over the last 3 months or so Handlers have responded to a number of submissions concerning the use of an "older" vulnerability in VNC to exploit systems and install what is typically identified as RBot variants. Reports generally say something along the lines of "I've seen multiple reports from admins who have seen their systems remote controlled by a new Spybot worm via RealVNC.  They actually see the start button pushed, the Run command filled....". 

One report mentioned that "This appears to be an automated attack on this version of RealVNC.". Another says "I happened to be standing near the PC with iTunes playing and noticed it minimized and restored very quickly. That got my attention.  I noticed the VNC icon was black and within a couple of seconds the hacker clicked Start, then Run and ran (an executable).".

A number of readers have also noted and reported upticks in Port 5900 (VNC) scanning, which has certainly changed character this year, it changed character right after the vulnerability was announced, and then more noticeably in July, check out the increase in the number of reported sources for destination port 5900 at DShield.

So a question someone might have an answer for is, are the reports we're receiving, combined with the nature in the change in Port 5900 scanning, indicative of some development of Metasploit post VNC exploitation payload, ala what's described in "Post-exploitation fun in Metasploit 3.0"? All responses will be appreciated.

And thanks to everyone who submitted information.

Current Vulnerability information is at;
RealVNC Password Authentication Bypass Vulnerability

Cisco Security Response: RealVNC Remote Authentication Bypass Vulnerability

0 Comments

Published: 2006-11-26

Backdoor Trojans significant and tangible threat to Windows users - MS Antimalware Team

Windows Malicious Software Removal Tool: Progress Made, Trends Observed is a paper published in early November by the Microsoft Antimalware Team giving "perspective of the malware landscape based on the data collected by the MSRT". The tool, by default, "only looks for malware that are currently running or linked to through an auto-start point, such as in the registry.".

Anyone with network security monitoring or malware IR responsibilities should consider giving it a read. Some highlights (ymmv) include;

"Backdoor Trojans" .... "are a significant and tangible threat to Windows users.".

"Out of the 5.7 million computers cleaned, the MSRT has removed a backdoor Trojan from over 3.5 million (62%) of them.". "Bots, a sub-category of backdoor Trojans" ..... "represent a majority of the removals.". Rbot, Sdbot, and Gaobot "compose three of the top five slots in terms of total number of removals.".

"The increase in Win32/Rbot removals is due to a large number of variants of that malware family being added to the MSRT each release. On average, approximately 2,000 new variants of Win32/Rbot have been added to the tool each month.".

Correlations in the paper;

"The largest correlation shown" .... "is between rootkits and backdoor Trojans. In approximately 20% of the cases in which a rootkit was found on a computer, at least one backdoor Trojan was found as well. This emphasizes the trend of a large number of rootkits being distributed or leveraged by backdoor Trojans."  (handler emphasis/bold). "The percentages are also high between P2P worms and backdoor Trojans and IM worms and backdoor Trojans. The high values here are also expected given that many P2P worms and IM worms will often drop bots on the computer when they are run."

0 Comments

Published: 2006-11-25

Report of possible Malware coming from Chinanet

A reader has reported an instance of possible malware delivered to his machine from the Chinanet network.  A number of AV products have identified the code as possible Malware, i.e. suspicious file or possible Trojan.  Initial tests haven’t shown anything conclusive.


The file was an executable called ok.exe.

Mark H

ISC Handler On Duty

0 Comments

Published: 2006-11-25

Interesting Potential Attack Vector

One of the handlers found an interesting article on the net which raises some interesting questions and describes an interesting attack vector for the delivery of malware. 

Essentially it uses frames within word documents.  When using frames in the document you can link the content of the frame to a URL, which will be downloaded and displayed (if relevant) when the document is opened.  So this is similar to the URL links in the SPAM emails we all get.  However the email links require a click, whereas this requires you to open the document.  People nowadays are wary of clicking on links in emails, but will happily open a word document when it seemingly was sent by Aunty Joan, the boss, or someone else they know.

So in a few minutes of thinking we came up with a number of interesting uses of this feature, ranging from tracking documents being opened to malware being downloaded and installed and of course the original use as described in the article.

What to do about it?  Controls on web traffic would be  one defence, for example content scanning or URL blocking.  The payload has to be delivered, so if web traffic is controlled the risk is reduced.  To prevent email delivery, block word documents.  I know a number of sites where this is the norm and it works for them.  But still one of the best defences is an informed userbase, so awareness training.

Other products may have similar issues, so be aware.

The article can be found here.

Mark Hofman
ISC Handler On Duty
shearwater.com.au


0 Comments

Published: 2006-11-25

ebay.co.uk

Sadie from the UK reported that a number of ebay groups are having issues, defacements, deletions etc. 

I've been unable to confirm this, however if any of our UK readers have any additional information please contact us
(specific links, screen shots etc).

Mark Hofman
ISC Handler On Duty
shearwater.com.au

0 Comments

Published: 2006-11-25

First Shift !

Wow first shift as the Handler of the Day. 

It started pretty ominously.  A few days ago I accidentally mentioned the q word and was promptly told that it would come back and bite me.  And bite it did.  This morning I logged on to get ready for the next 24 hrs when the power for my neighbourhood disappears.  My little UPS happily humming along and providing power, but alas my internet connection somewhere between my house and the ISP was not so lucky.

Anyway things are back, I'm ready for the day (sort of) and the cricket is on (Go Aussies).


Mark Hofman
ISC Handler On Duty
shearwater.com.au

0 Comments

Published: 2006-11-24

Time Zone Updates, Part 2

Apparently the Western Australian government just decided on November 21 to make a change to their Daylight Savings Time period as well, which oh by the way, will now start on December 3rd of this year (yup, nine days from now).

Microsoft has already released an update for the Windows operating systems under support: Windows 2003, Windows XP and Windows Vista.  To get more information about the update and to download it, go here.


0 Comments

Published: 2006-11-23

If IE Suddenly Says "Se Habla Espanol" ...

A reader wrote in with this link.  Some folks who downloaded IE 7.0 through WSUS last night got a Spanish version rather than then English version.  Microsoft is aware of the issue and is working on correcting it.  Apparently the Spanish version of IE 7.0 accidently got classified as the English version.

0 Comments

Published: 2006-11-23

Microsoft Release 2007 Time Zone Update for Windows Operating Systems

Microsoft released an update today for the change in Daylight Saving Time (DST) that goes into affect next spring in the United States due to the Energy Policy Act of 2005.  The update also addresses some changes in other timezones.

This update is not currently showing up on Microsoft Update so users will need to download it manually for the time being if they want it.  The update will be included on Microsoft Update, Automatic Update and WSUS starting December 12, 2006.

Updates were released for Windows 2003 and Windows XP.  Windows Vista will included the newer timezone data.

0 Comments

Published: 2006-11-22

MS06-071 is available via SUS 1.0

The MS06-071 patch should now be available on SUS 1.0 servers for approval. Reader Andrew reports having seen MSXML 4.0 SP2 Security Update (KB927978), 11/17/2006 and MSXML 6.0 RTM Security Update (KB927977), 11/17/2006 show up. The Microsoft Security Response Center Blog made the announcement here.
Microsoft have also announced that support for SUS 1.0 will be further extended until Patch Tuesday July 10, 2007. The announcement appears on the main SUS page. MS06-071 not being available for SUS 1.0 when it was released was also discussed on the Microsoft blog, as well as the SUS drop dead date extension.

Cheers,
Adrien de Beaupre

0 Comments

Published: 2006-11-22

Reverse Cross-Site Request (RCSR) vulnerability

A new vulnerability in Firefox has been recently disclosed. The password saving functionality of Firefox can be exploited to expose usernames and passwords to other sites, such as those used for blogs or any page requesting user input. The proof of concept page shows the username and password input in a google URL. They are calling it a Reverse Cross-Site Request (RCSR) vulnerability. The advisory appears here. This type of attack vector appears to also affect Internet Explorer.

Bugzilla link.

Mozilla has apparently been advised of the vulnerability, there currently is no vendor patch. The workaround in this particular case would be to never use Firefox to save passwords for any web site. The option is under Tools, Options, Security. Here is a link showing how to disable it.

Thanks to our reader Carsten for letting us know.

Cheers,
Adrien de Beaupre

0 Comments

Published: 2006-11-22

Mac OS X Apple UDIF Disk Image Kernel Memory Corruption

A vulnerability has been reported in the way OS X handles corrupt DMG images. This would typically be a local user exploit for privilege escalation. The exception here would be that it could also be exploited remotely via the Safari web browser. A lot of  OS X binaries can arrive as DMG files. They are complete file systems, and are automounted in a default configuration. A corrupted DMG file would then compromise the system and allow for arbitrary code execution. This new vulnerability and the PoC is brought to you by the Month of Kernel Bugs (MoKB) and the number 10.

Mitigation: There currently is no vendor patch for this vulnerability. To reduce the risk of remote compromise reconfigure Safari and be careful with DMG files from untrusted or unknown sources. For Safari disable opening "safe" files after downloading. Tutorial on how and why to do so can be found here.

Secunia advisory can be found here

Cheers,
Adrien de Beaupre

0 Comments

Published: 2006-11-21

Week of Oracle 0-Day

Cesar of Argeniss Information Security has announced they will be publishing a 0-day vulnerability each day during the first week of December. Looks like the Oracle world will soon get some excitement (Get ready to patch). It would be interesting to see if Oracle would have to deal with these using out of schedule patches.

----------------
Jason Lam,  jason /at/ networksec.org

0 Comments

Published: 2006-11-21

CA BrightStor ARCserve Backup 11.5 remote vulnerability

A new remote code execution vulnerability on ARCServe Backup version 11.5 has been released today. The vulnerability exploits the handling of RPC requests on port 6502. Proof of concept code has been released to the public at this point. If you are running ARCServe, it's about time to patch now.

-------------------
Jason Lam,  jason /at/ networksec.org

0 Comments

Published: 2006-11-21

Online backup strategy

Availability is one of the three key aspects of information security, it is also the most often neglected aspect. To safeguard against data lost due to harddisk crashes, backup is absolutely necessary. The backup idea is simple, just make a duplicate copy of the data and store it somewhere safe and ensure you can access the backup data when you need it. This simple idea is actually difficult to implement, cost of backup media and equipment, safe transport of media to the "safe" place, scheduling the backup job regularly, etc.... Things are even worst for home and small business users who have limited knowledge and resource. There are quite a few online storage companies marketing their solution as secure online backup solution. One company even offers 25GB of free storage space for anyone to store their files online.

The online backup vendors seem to all claim themselves as very secure and can protect your data properly. A lot of them simply copy your files via an SSL tunnel to their datacenter and store the file as is. Not sure how you like the idea of some other companies storing your important (sensitive) files and have access to them. I personally dislike that idea a lot and I think data should be encrypted before shipping over to the backup location.

There are some solutions that encrypt the data before shipping it over to the datacenter, making it impossible even for the online storage vendors to read your content (if the client hasn't been backdoor that is). While choosing an online backup vendor, be sure to look for encryption capability, encryption before you send them the data, that is.

Make sure you also periodically check to see if you can retrieve the data (unencrypt the data). For the encryption key, either select something that you can remember real well or have a copy of the key available somewhere. For the forgetful readers, you might want to consider copying the encryption key on a USB key drive and put that in your safety deposit box or other safe location (outside of your primary residence/office).

With the technology available today, backup is real easy and cheap. However, you must do some proper planning to ensure your backup data is safe and sound, most importantly, available when you need them.

You might also want to review our previous stories about backup:

http://isc.sans.org/diary.php?storyid=1589

http://isc.sans.org/diary.php?storyid=702

---------------------------------------
Jason Lam,  jason /at/ networksec.org

0 Comments

Published: 2006-11-20

MS06-070 Remote Exploit

For those of you that haven't patched, (shame on you! ;), I just wanted to let you know that..  Yes, there is a remote exploit out for MS06-070.

When the patch came out initially,  Handler Pedro did a write-up on it here.  Obviously, I am not going to point out to you where the exploit is.  (Nice try ;)

The vulnerability is assigned CVE number 2006-4691.

So, if you haven't patched, I suggest you go do so now.


Joel Esler
/** Handler of the Day **/

0 Comments

Published: 2006-11-19

Taking a Look at the FreeVideo Player Trojan

ISC reader Brian Eckman shared with us a comprehensive write-up about malicious activity he observed in association with the FreeVideo Player software distributed by www-dvdaccess-net. (We do not recommend visiting that URL.) According to Brian, the program's EULA grants its authors the right to install third-party software on the user's machine; however, most users would not find the activities of this program desirable.

The main purpose of the FreeVideo Player, in its current state, seems to be redirection of web search results and DNS queries for non-existent domains to ad-hosting websites. As Brian notes, the capabilities of the program could "allow it to be incredibly effective (i.e., devastating) if used for phishing. If they decided to return false DNS answers for banks, credit monitoring companies, auction sites, etc., there is almost no protection for the end user. Even if they return valid DNS responses, they can present any page they want to the Web browser."

The program includes relatively advanced features seen in malware, such as rootkit functionality to make it difficult to discover its presence or to remove it from the affected system. In addition, its distribution mechanism gives its authors the ability to create customized or fingerprinted executables for each person downloading the program. According to Brian, the website hosting this program distributes unique executables based on the IP address of the system that is downloading the program.

Some anti-virus companies recognize variants of this program as Zlob. Others may tag it Emcodec, or may not recognize it as malware at all.

Brian states, "I believe that this software clearly fits the definition of a Trojan Horse. From what I have been able to gather thus far, the apparent motive is profiting from pay-per-click advertising. ... The engineering of this Trojan and the social engineering behind its spread appear to me to be far more advanced than typical Web browser exploits and IRC bots."

The network that is making use of the FreeVideo Player trojan falls in the netblock that belongs to Inhoster. We've been recommending that companies block access to this netblock 85.255.112.0/20, as per our January 1, 2006, diary. One of the indications that systems on your network are infected with the FreeVideo Player is the regular presence of DNS queries aimed at servers on the Inhoster netblock.

We hope to make Brian's full write-up available shortly. Please stay tuned.

Lenny Zeltser
ISC Handler on Duty
www.zeltser.com

0 Comments

Published: 2006-11-19

An Overview of the FreeVideo Player Trojan

The following analysis of the "FreeVideo Player" trojan was shared with us by Brian Eckman of the University of Minnesota. We are pleased to share it with ISC readers with Brian's permission. His write-up is presented below.



For more than a month now, we have been seeing a steadily increasing amount of DNS traffic heading to a block of IP addresses assigned to a (supposedly) Ukrainian company called InHoster. This DNS traffic is coming directly from client computers - ones that should be configured to use our local DNS servers for recursion.

I traced back the actions of some computers that are exhibiting this behavior, and have found at least one example of what is causing it. What I found is a number of pornographic Web sites are hosting (purported) links to videos that, when clicked on, bring up a Web page that claims that you need to install a codec to view their videos. Clicking on the link to install the codec is simply a link to an EXE file hosted on a different Web server.

(I have not seen evidence of this being installed via browser exploits, nor evidence of it being installed via any other method without the knowledge and consent of the user.)

While the strategy of tricking people into installing a Trojan by claiming they need a codec to view the video isn't brand new, I haven't seen any information regarding this particular line of malware.

The Web server hosting the installer is http://www-dvdaccess-net/. (URL intentionally broken, replace - with .) As of Friday, November 3rd, and when checked again on November 16th and 17th, they were hosting 301 unique versions of the installer. The home page of that site offers http://www-dvdaccess-net/download/dvdaccess1000.exe to anyone who wants it. On top of that, dvdaccess[1001-1300].exe also exist, and some or all are pointed at by various pornographic sites as described above. When downloaded, all 300 of these files have a unique MD5sum value.

The dvdaccess[1000-3000].exe files use "NullSoft Install System" as the installer, and come with a somewhat professional-looking EULA. As most EULAs do, this one has a "catch" too. In fact, it's about the most blunt I've seen. It basically says they reserve the right to install third-party software. Period. No indication as to what types of software they might install, how or when it will be installed, what rights (if any) you have to remove that software while keeping the "FreeVideo Player" installed, or if removing the "FreeVideo Player" removes that software, etc.

(Interestingly, I mention that the EULA appears somewhat professional-looking. Reading it, there are a few clues that this software is at least shady, if not overtly malicious. First off, the Licensor is never defined. It claims to be a legally binding agreement, but it never claims who you are bound to. They claim that you must abide by the intellectual property laws, but never say where the origin of the software is, or what nation's law it claims to be under. Based on this, along with other observations, while I am not a lawyer, I am doubtful as to whether or not the EULA is enforceable in the US.)

Several AntiVirus (AV) companies detect at least some of these as variants of Zlob. For example, dvdaccess1000.exe was called "Zlob.UGF" by Norman Sandbox. Symantec claims to now (as of late last night) provide detection for one of the files generically as "Trojan.Emcodec".

From what I have seen, any AV company that detects this Trojan bundles detection of it in with other, related but still quite different Trojans (which is now common). Therefore, their writeups so far are mostly useless for describing how this line of Trojans works, what its capabilities are, etc. (Hopefully due to the number of variants, and the seemingly widespread infection rate, some companies will consider giving it a more appropriate name, such as Trojan.FreeVideo.)

Anyhow, the effect of this installation that caught my eye is the fact that it adds values to the "NameServer" key in several places in the registry. This overrides DNS Server values entered manually and those assigned by DHCP, taking over all DNS resolution functions for the clients. The different versions appear to use somewhat different IP addresses in that 85.255.112.0/20 netblock. From what I have seen, two IP addresses are chosen and those same two are used for the various registry entries that are created.

The DNS servers return a valid IP address as the answer for lookups that should be NXDOMAIN. If a non-existent record is accessed via a Web browser (for example, due to a typo), the wildcard entry will return a search page with links typically chosen by some porn-centric company.

Recently, I decided to install dvdaccess1094.exe on an old computer and a Virtual Machine, to perform further analysis. Here is what I found. Note that my findings are specific to the dvdaccess1094.exe file, and are possibly *slightly* different in the other 300 variants.

===================
DNS Server Settings
===================
The installation modified numerous registry settings pertaining to the DNS servers, including overwriting settings that are issued via DHCP. The settings given to my PC initially were 85.255.116.27 and 85.255.112.114. These settings were visible in the Network Connections applet within the Control Panel, as well as via `ipconfig /all`.

Modifying the settings via the Network Connections applet worked, and did survive a reboot. It does appear that it is not protecting these values.

From what I have observed, the InHoster netblocks being used for DNS are 85.255.112.0/24, 85.255.113.0/24, and 85.255.114.0/23. There are many dozen of servers in those netblocks that are involved. Cursory investigation leads me to guess that the Trojan may always pick one IP from a list inside of 85.255.112.0/24, and the other DNS server IP may always be from one of the other two subnets.

==================
Rootkit Technology
==================
The installation set a value in a typically-unused registry key that allows it to run an executable at startup. It set a value for HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon "System"="kdfle.exe"

(A subsequent install used a slightly different value "kdyda.exe", but did use the same DNS server settings. Another subsequent install used a different value AND different DNS server settings.)

That file is not visible via Windows Explorer, but it is obviously there, stored in %WINDIR%\System32. This is simple to check - if you try to create a file in %WINDIR%\System32 using whatever name is listed as the value for "System" within that Winlogon key, you are told that you cannot do this because a file with that name already exists here. If you try to open it via the command line using Notepad, you are told that Notepad cannot open it because an existing process has it open.

================================
Built-In FreeVideo "Uninstaller"
================================
Installation of the FreeVideo software visibly creates C:\Program Files\FreeVideo\uninstall.exe, as well as a shortcut to it in Start Menu>>Programs, and the necessary registry entries to remove it via Add/Remove Programs. Using this uninstall program does not change the DNS server settings back to their original settings, it does not remove the value for the System sub-key within HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, nor does it remove the executable that that key runs at startup.

===================
Symantec AV results
===================
SAVCE 10.1.4.4000 with definitions file "11/14/2006 rev. 34" did not detect dvdaccess1094.exe nor kdyda.exe, even with Heuristics turned up to the Maximum setting.

========================
Windows Defender Results
========================
Windows Defender with the most recent definitions as of November 14th did not detect anything during the installation, nor during a manual scan after installation.

========================
Rootkit Revealer Results
========================
The most recent version of Rootkit Revealer (v. 1.71) did not flag the hidden file "kdyda.exe" or anything else related to this software.

==================
Removal Challenges
==================
The registry subkey "System" within HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon cannot simply be deleted or modified. If you modify or delete it while the Trojan is running, it simply replaces the entry immediately. This also is the case when booting into Safe Mode. It may be possible to restrict access to write to the Winlogon key to only one user account, then use that account to change it, but the one time I tried it, I forgot to set permissions back for everyone else, and the machine got stuck in the Blue Screen of Death & reboot cycle, probably because SYSTEM no longer had the rights that it needed to the Winlogon key.

Obviously the technically savvy can find lots of interesting ways to remove it. Some are more dangerous than others. The most obvious ways involve booting an alternate Operating System and mount the hard disk containing the infection with read/write capabilities, and remove/rename the file.

Note that the file that was dropped in System32 contained a "modified" date that had been altered, so finding it by simply walking the System32 directory might be a challenge (although I suspect the file name will always be five letters, starting with "kd", and use the .exe extension - at least until they release the next version of it). In one test, I booted to "ntpasswd", used the registry editor functionality, and removed the registry value that started up the file. Upon booting to Windows, the file was visible to Windows Explorer (since it wasn't running), and could easily be deleted or renamed.

=================
Wicked Technology
=================
Further analysis shows that this appears to inject itself into running processes. One noticeable side effect is that it redirects certain Internet traffic within Internet Explorer. For example, I used the Search Bar in IE7 (I have Google Search as the default search provider on this Virtual Machine) to search for "BitDefender". IE brought up the Google search results. Network traffic analysis shows that I am indeed served up results from Google.

In tests where I clicked the link within the Google search results for the BitDefender Online Virus Scan, I was taken to any one of a number of Web pages. Some of them are various "search results" pages, some are trying to get me to buy AntiVirus software, etc. Network traffic analysis shows that Google takes me to BitDefender, BitDefender returns a page, but my client immediately also contacts a Web site in the InHoster IP space, which forwards me to a page, which forwards me to another page, one or two more forwards occur (all are "302 Found" messages that redirect the client to a different URL), before landing at the final destination page. It is that destination page that is rendered in my existing IE tab - not the BitDefender page!

Note that this activity occurred even though I had already changed the client's DNS servers back to our official DNS servers! My DNS query appeared in our DNS query logs, and my client did initially start to go to the BitDefender site before it went to another site (that neither I, Google nor BitDefender told it to go to), and IE showed me that page instead.

===============================
Additional Threat Possibilities
===============================
I have not observed any false DNS query responses, except for the wildcarding done for non-existent names (queries that should result in NXDOMAIN responses are instead given answers pointing to various places). Also, the instances of Web page redirection that I have observed have appeared to be revenue generating through pay-per-click services so far. However, I cannot stress enough that the capabilities of this Trojan would allow it to be incredibly effective (i.e., devastating) if used for phishing. If they decided to return false DNS answers for banks, credit monitoring companies, auction sites, etc., there is almost no protection for the end user. Even if they return valid DNS responses, they can present any page they want to the Web browser.

(Since they can install any code they want, inserting a new trusted root certificate into the Web browser (like MarketScore did) could even let them generate whatever SSL certificates they want. Heck, in that case, they wouldn't even need to return false DNS results to steal credentials to Web-based services. But I digress.)

Also, since this Trojan can apparently return whatever Web content it wants (to Internet Explorer, anyhow), there is no telling what havoc they might wreak if they decide to redirect certain program downloads. ("You want the new Acrobat Reader? Sure, I've got that right over here....")

============================
Virtually Unlimited Variants
============================
In order to better determine if the Web site was simply serving up random variants of this FreeVideo Trojan, regardless of the filename requested, I asked some colleagues for assistance. Warren Raquel (UIUC.edu), Louis Brooks (FSU.edu) and I each downloaded all 301 files from the dvdaccess-dot-net Web site, all within an hour of each other. We each ran md5sum against our local cache of the 301 files, and compared results. We wound up with 903 unique md5sums!

Afterwards, Scott Dier (UMN.edu) went one step further and downloaded all 301 files from three different IP addresses. All 903 resulting files had unique MD5sum values, and all did not match any of those that the rest of us found.

All of us verified that we could re-download any or all of the filenames from the same IP address and receive a file with the exact same md5sum that we received previously. This showed that we were not receiving random files - a single IP Address will always get the same md5sum value when requesting the same filename. (I checked a packet capture to make sure that the Web server was indeed sending the file again, and was not trying to rely on a HTTP 304 code.)

Scott went on to show that the dvdaccess[1000-1300].exe files decompressed into two different malware binaries - step1.exe and step2.exe. He discovered that all of 903 files (all 301 files, each downloaded from three different IP addresses) that he downloaded had unique MD5sum values for step1.exe, but there were only 301 unique values for the md5sum of step2.exe.

This leads me to believe that once someone requests one of the dvdaccess[1000-1300].exe files from the Web server, a process starts that:
  1. Generates a step1.exe file that will be tied to that dvdaccess[1000-1300].exe file and the IP address of the downloading host.
  2. Takes the pre-compiled step2.exe file that corresponds with the requested dvdaccess[1000-1300].exe file.
  3. Packages them together and hands them to the Web server to present to the requester.

=======
Summary
=======
I believe that this software clearly fits the definition of a Trojan Horse. From what I have been able to gather thus far, the apparent motive is profiting from pay-per-click advertising. I do not know and cannot speculate at this time if this is the only motive, the primary motive, or simply a front for more insidious tactics.

The engineering of this Trojan and the social engineering behind its spread appear to me to be far more advanced than typical Web browser exploits and IRC bots. It is clear that we are dealing with a well organized crime ring that has significant resources at hand, including lots of IP space, bandwidth, as well as talented in-house programmers, sysadmins and marketing analysts. Considering their capability to distribute 301 unique variants of the same malware on a Web server, they clearly have the ability to distribute 301 different ones once enough companies start detecting their current versions. (Not to mention that they have plenty of other "business" taking place on this IP space.)

Finally, all of this analysis was performed by observing changes made to the computer by this Trojan, as well as authorized network packet captures taken from a computer in the path of the network traffic. No reverse engineering of any of the components was performed, as that would violate the terms of the (likely not enforceable) EULA.



The above overview of the FreeVideo Player trojan, which we referenced in the November 19, 2006, diary, was written and shared with us by Brian Eckman. Thanks, Brian!

0 Comments

Published: 2006-11-19

Virtual Machine Detection in Malware via Commercial Tools

Virtual machine detection is a self-defensive property of many malware specimens. It is aimed at making it harder to examine the malicious program, because virtualization software, such as VMware, is a very popular tool among malware analysts. For instance, 3 our of 12 malware specimens recently captured in our honeypot refused to run in VMware.

There are many ways for malicious code to detect that it's running in VMware: looking at the presence of VMware-specific processes and hardware characteristics are some of the simpler ones. More reliable techniques rely on assembly-level code that behaves differently on a virtual machine than on a physical host. VMware-detecting features are sometimes built directly into the malicious program, and are sometimes added by a third-party packing utility. (A packer is a utility that modifies the original progral to conceal its strings, disable debuggers, detect VMware, and so on.)

We recently encountered a malicious program that was packed with a commercial packer called Themida. (Thanks for the heads up, Johannes!) This packer includes support for virtual machine detection, as you can see in the screen capture below:



If you're surprised that commercial packers exist, don't be. Programmers often rely on packers to protect legitimate programs from reverse-engineering. Specifically, "Themida is very popular in China, because developers use it to protect mobile applications," according to one post on the ExeTools Forum. "They want maximum security to protect their sensitive communication between software + mobiles."

Themida is probably based on an earlier packer called Xtreme-Protector; both tools seem to have been written by the same author. The Xtreme-Protector website includes a whitepaper that outlines some of the anti-reversing features built into this program.

As a malware analyst, one way you can deal with packed executables that check for the presence of VMware is to patch the malicious code, so that the offending routine never executes. Another option is to modify your VMware instance to make it more dificult for the malicious program to detect that it's running in a virtual machine. Such VMware-concealing  techniques are still relatively immature, but they were documented by Tom Liston and Ed Skoudis at a recent SANS conference. The sides for their presentation Thwarting Virtual Machine Detection are available on-line.

Lenny Zeltser
ISC Handler on Duty
www.zeltser.com

0 Comments

Published: 2006-11-18

W32/HLLP.Phillis.bq - Early release of McAfee DAT file

Reader Alan alerted us of an early release notification by McAfee for a DAT originally scheduled for Monday. The new DAT was made available earliy due to its potential for spreading quickly. More information about this can be found at http://vil.nai.com/vil/content/v_140922.htm.

This good news is that a proper patch management routine and appropriately securing file shares will most likely prevent this virus from spreading to your system from another infected host.

0 Comments

Published: 2006-11-17

Postini Spam Filter

Reader David wrote to us with this comment and request:

We use Postini for SPAM and email filtering, and they've had a weird attack today. Emails are coming through from random sources, with TORA.OB written out in number characters.  I googled TORA.OB and found a company on the stock exchange using that name.  Just wondering if anyone else has seen this? Just a little unusual I think. Nothing else in it (ie no exploits, binary data, etc)

Anybody else seeing similar spam runs getting through Postini?  Let us know via the contact form.

UPDATE #1
Many readers are telling us that they've seen these spam messages today, so we've confirmed that they exist.  No need to write in and send us more samples.  Our cup runneth over...

Reader Conrad told us this:

Postini subscribers can email spam -at- postini.com with sample spam messages. This will enable Postini to adjust their filters to keep this sort of spam out.

Thanks, Conrad!

UPDATE #2
At the risk of drawing attention to this stock, handler Deb pointed me to a stock page where you can see the pump and dump scheme as it happens.  Looks like the value is already going down, so  no need to buy anymore.

UPDATE #3
We have multiple confirmations that the spam made it through many different spam filters in addition to Postini.  This is a typical pump-n-dump stock scheme just like the image-based spam that we are all so tired of.  If it feels like you've seen a dramatic rise in this category of spam over the past few weeks you are not alone.  eWeek has a pretty good article about it, and there's a lively debate about it over on Slashdot.

A reader gave us some ideas on how this type of spam might be blocked.  We have not tried this filter but offer it to the community for your consideration.

The following procmail recipe should catch the 'thin-line' ones:

    :0
    * ^Message-Id: <............\$........\$00000000\@

And the following should catch the 'fat-line' ones:

    :0
    * < 10000
    * ^Content-type: text/plain;
    * -100^0
    *     2^0 B [ ][0-9][0-9][0-9][0-9][0-9][ ]
    *     3^0 B [ ][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]

Thanks again to everybody who sent in samples and comments!

Marcus H. Sachs
SANS Internet Storm Center

0 Comments

Published: 2006-11-17

Microsoft Patching Observations

One of our readers applied all of the Microsoft patches that came out on Tuesday, then sent us a rather detailed note about his observations in response to our request for comments.  I sanitized it a bit to remove any personal details, otherwise it is pretty close to what he sent us.  By the way, there's a nice exploit of MS06-070 available on a popular security site in case you need a reason to get your patching done before you go home tonight.


You wanted 'em, you got 'em. Toyota... as the saying goes. Mystifying.

1. 'Went to the MS Update site, which called for 6 priority updates. I added one additional: KB920342 (for P2P). The ones called for as "Priority" updates were listed in this order:
- KB927978 MSXML 4.0 SP2 Security Update
- KB920213 MSAgent (MS06-068)
- KB923980 Netware... (MS06-066) [which is NOT installed on this machine (?)]
- KB924270 Workstation svc... (MS06-070)
- KB922760 IE[6?] (MS06-067)
- IEv7...

- KB920342 P2P (...the "extra" one I choose. Duh. 'Like I wasn't going to have enough trouble already.)
-----------------------------------------------------
2. They installed themselves in this order as I watched it, as I thought the MS Update site would prioritize them in the correct order (...duh, again.):
- KB920342 P2P
- IEv7 (...which, of course, you have to help with the prompts, the "OK" for WGA, etc.)
- KB920213 MSAgent (MS06-068)
- KB923980 Netware... (MS06-066)
- KB924270 Workstation svc... (MS06-070)
- KB922760 IE[6?] (MS06-067)
- KB927978 MSXML 4.0 SP2 Security Update ...then REBOOT, of course.
-----------------------------------------------------
3. After rebooting, went back to the Admin account (1 of 2 on this XP Home PC), tweaked IE7 a bit, found that it had installed this annoying "Language Toolbar", which I disabled via its own control options. OK, 'looks fairly clean.
'Went back and let MS Update check again, just to make sure I hadn't missed anything - 'looks good; checked the PC's "Update History", which I also printed ('glad I saved that). 'Cleaned up the temp files from the installs using "Easy Cleaner". 'Seemed like it did its' usual good job. Logged off the Admin account and went to check on the LUA accounts on this PC (4 of them). Dang it! The dopey "Language Toolbar" was installed on EVERY one of the LUA accounts - disabled them via the toolbar's own control options. 'Tweaked/checked settings in IE7, just like I had in the Admin account. Ahhh, 'seems like we're ready to go; wrong.
Now, I have an "extra" service running that I didn't before - "ctfmon.exe", even in ALL the LUA accounts.
- The "ctfmon.exe" (from MSOfficeXP, supposedly) info can be found at KB326526 and KB282599, and probably others. I am NOT going to jump through all the hoops listed in those articles - and I shouldn't have to call the MS eternal wait phone to get a hotfix for this. 'Not even sure it would fix the startup of that service, which -was not- starting before I did this bunch of patches. I found out I can "kill" this service using any number of utilities available, but it returns with just a logoff/logon, and of course with a reboot. WTF?
- Ran MSCONFIG from an Admin account, and saw that I could eliminate the startup of "ctfmon.exe"; did so. rebooted, and it stuck itself back in the startups again. Dang it! Blowing away the registry item (Run) MIGHT take care of it, but it might give me a BSOD, too. WTF?
- In running MSCONFIG, I also noted there was yet another new service started called "Remote Packet Protocol Capture (Experimental v0)" added, which I disabled, and it appears to stay that way (whew!). WTF?*
-----------------------------------------------------
Chapter 4 (now part of an "MS Updates for Dummies" book coming your way any day now). Further checking in the Control Panel led to more frustration and mysery - the list of patches supposedly shown under "Add/Romove programs" does NOT list "KB927978 MSXML 4.0 SP2 Security Update" on the list. Had I not -saved- the MS Update site's "Update History", I would be babbling in my sleep, but since I did, I know it installed because I watched it do so, -and- I have that list of the updates I let it install on 11.15.2006.
So, I did a KB search @ http://support.microsoft.com/search/?adv=1 to look for KB927978; 'tried that several times today and got "...not found" and "The Knowledge Base (KB) is currently not available". ARRGGHH!
-----------------------------------------------------
"Do not forget to report such trouble back to Microsoft as well..." - why? They really don't give a hoot.

I guess I'm lucky that the machine is still running at all, but all my forensic skills went in the dumper today, it seems. 'Just one of those days, I guess. I'm going to bed now, after a few Jameson's...

Wow.  Just when you thought patching was getting easier.  Thanks again, Reader, for your comments and thoughts!

Marcus H. Sachs
SANS Internet Storm Center

*Note: Two readers have already reported in that the "Remote Packet Protocol Capture (Experimental v0)" is typically installed with WinPCap.

0 Comments

Published: 2006-11-16

Honeypot Mirroring .edu domains under .eu / Active Threat

The .eu top-level domain is relatively new and in the build-up phase and had a co-worker notice something fun.

When ssh'ing to a local server, he typo'd and finished the DNS name as .eu, it connected with an SSH handshake (it was a new server so the key warning wasn't considered a big deal) and took a password. The individual immediately recognized the problem when the password wasn't accepted and we investigated.

It appears any DNS name at ourdomain.eu would resolve to this machine.  Not only that, but the machine in question was hosting at least 7 other domains under .eu that would map to an educational institution. For instance, for "fake" educational institution at ufoo.edu you could search for ufoo.eu and get a response to this machine.

nslookup www.ufoo.edu
response: 111.222.111.222 (good)

nslookup www.ufoo.eu
response: 200.100.200.100 (bad)

nslookup XXX.ufoo.eu (XXX = anything whether or not it exists on the .edu side)
response: 200.100.200.100 (bad)

It appears that this machine will take anything from certain domains and resolve it, whether or not the dnsname actually exists on your end. (i.e. wildcard)

What is appears, for the moment, is that this machine is running a honeypot to capture passwords for people who typo .edu as .eu.  However, with a little ingenuity they could turn this enterprise into something truly evil. Right now it is only running a few token services and the webpage appears to be hosting "non-content". There are some who think this is "legit".

With this main .edu's pointing to the same place to a box with non-content, I'm not buying it. Incidents like this are a good reason to be cautious, particularly when the mitigation is as non-involved as it is.

Mitigation:

Check your .edu to see if it resolves as an .eu (i.e. nslookup www.yourdomain.eu and see what happens).

If you get 212.79.243.140, they are mirroring your .edu.

Filter that IP in both directions and pursue what other avenues your lawyers think necessary (i.e. lock down the .eu equivalent of your domain).

I'm interested in how wide-spread this is, and would like a report if your .edu is affected.

----
John Bambenek
bambenek /at/ gmail [dot] com

0 Comments

Published: 2006-11-16

Bot C&C Servers on Port 80

We do see more and more bots that use port 80 for their C&C channel. This will make these bots harder to detect. However, these are IRC servers, so its not that hard to distinguish them from HTTP traffic.

Couple tricks that may help:

  • Implement a proxy server to filter outbound port 80 traffic. This is a good idea anyway as it may help you to implement additional filtering for web traffic as well.
  • If you suspect an IRC server on port 80 in your own network, a quick scan with nmap can help:

nmap -A -p 10.0.0.0/24 (The '-A' option will look for service banners)

Interesting ports on 10.0.0.a:
PORT STATE SERVICE VERSION
80/tcp open tcpwrapped <--- expect this from devices
using web admin interfaces.

Interesting ports on 10.0.0.b:
PORT STATE SERVICE VERSION
80/tcp open http? <--- this server is running apache
with customized headers.

Interesting ports on 10.0.0.c:
PORT STATE SERVICE VERSION
80/tcp open irc ircu ircd <--- this server is running IRC!
Service Info: Host: megaserver



  • implement a snort rule to look for IRC traffic on port 80. Snorts 'chat.rules' has a number of rules to detect IRC, but they are limited to port 6666:7000 by default. You could try some of them to see if they work for you. But the way they are written could easily cause false positives. A slightly improved rule:
alert tcp any any -> any 80 (msg:"irc traffic on port 80"; 
flow: established, to_server; content: "NICK "; depth: 5;)

0 Comments

Published: 2006-11-16

Microsoft patch troubles ?

Reboot wednesday passed with just a few isolated reports of trouble with the patches.

We would like to remind our readers we are interested in problems with patches. It's one of those cases where a community sharing such information as soon as possible can really work wonders.

However:
  • Do not forget to report such trouble back to Microsoft as well, it's the best way to get them to do something about it, and that kind of support is free.
    In the US call 1-866-PCSAFETY.
    Other coutries need to look it up on the Microsoft website, but it should be free just as well. [Fill in the country and then look in the column to the right]
  • Do not wait for others to go first. We're all interested in not being the first ones to hit the bump in the road. Unfortunately this results in increasingly longer periods of just waiting and being exposed to the bad guys. Those bad guys are not waisting a second in getting their exploits out there, either actively using it, either selling the exploit itself.
--
Swa Frantzen -- Section 66

0 Comments

Published: 2006-11-15

SANS Top 20 Update

Today, the SANS Institute released an updated Top 20 Internet Security Attack Targets list.
This update reorganizes the list recognizing the new reality of operating system independent issues. Sections for cross-platform applications, network devices, policy and the overall issue of 0-day attacks where added.

The list has been released for the last 7 years. From the start, organizations like the FBI assisted in putting the list together. It is in particular useful if you have to set and defend priorities.

Comparing the different versions it is interesting that one issue from the first list (back then it was "vulnerable CGI programs") has come back as the category of "Vulnerable Web Applications". Take a look for yourself and see how your personal infosec career is reflected in the evolution of this list.

0 Comments

Published: 2006-11-15

Malware with new features

One of our readers, Jerry Askew, sent us an interesting downloader today. The malware was spammed in e-mail (of course) and it was an executable file disguised as a jpeg, inside a ZIP archive.
Various AV tools at that point in time did not detect this particular sample, so we decided to spend some time analyzing what it does.

Downloader after downloader

The sample is a downloader, which is typical for a vast majority of malware that is spammed today. The downloader connects to a web site and downloads the second stage payload, which is another downloader.

This second stage downloader downloads and installs a small zoo of malware. Besides the usual culprits, such as keyloggers and BHOs (Browser Helper Objects), what's interesting is that it downloads multiple versions of the same Trojan. Brief analysis of these files showed that they all behave absolutely the same, but look different and have different checksums. When we tested them against AV programs, they had different detection depending on the file scanned (although some AV programs detected all of them as being the same family, but different minor versions). Why the authors decided to do this is not clear, but I suspect that they were just trying to increase their chance of getting the malware onto a machine – even if your AV program detected and blocked couple of samples, there might be one which is not detected.

After this third stage executable has been downloaded, it will turn off the host based firewall that comes with Windows XP SP2. It actually completely disables the Windows Security Center Service (wscsvc).

Malware then connects to its control and command center, which is a plain web server this time (no IRC). The web server produces a nice HTML page which has three different forms: ftpstaticdata, softstaticdata and softvardata. These will instruct malware to download additional modules. Of special interest was the ftpstaticdata section. This section contained an FTP server IP address and a username/password pair that malware used to upload keylogger logs.

Google Maps at your service

Now comes the interesting part. The authors actually went a step further. Before uploading the data to the FTP server, the malware connects to detectlocation.ru, which seems to be another compromised site setup just for this, and executes a perl script on that site. The perl script takes the IP address of the infected machine as input (this is passed as a parameter in the URL) and detects the geographical location of the IP address. What's interesting is that it even passes back valid coordinates that can be used in Google Maps!
Now when uploading data captured by the keylogger malware also automatically sorts it into directories, depending on the location of the IP address.

While at this moment malware only seems to be capturing information on infected machines, it will be interesting to monitor it to see whether it is related to the latest spam increase.

Lessons learned

In any case, it looks like malware authors got a little bit creative when they decided to use Google Maps. Also, the huge number of installed Trojans and other malicious programs once again show that when you encounter an infection like this one, reinstallation is the only option.

0 Comments

Published: 2006-11-15

Critical security vulnerability in WinZip 10

WinZip Computing released a new build of WinZip 10 that fixes a critical security vulnerability in this popular ZIP program.

The vulnerability exists in an ActiveX component that is shipped with WinZip 10 only (so if you are running previous versions of WinZip you are not affected by this vulnerability). This ActiveX component is marked safe for scripting which means that a remote attacker can exploit it if you visit a web page hosting the exploit.

Build 7245 of WinZip 10 is available at http://www.winzip.com/wz7245.htm. If you, for some reason, can not upgrade, you should disable the affected ActiveX control (WZFILEVIEW.FileViewCtrl.61) – its CLSID is A09AE68F-B14D-43ED-B713-BA413F034904.

0 Comments

Published: 2006-11-14

SUS: deadline extended - XP SP1 not supported anymore

According to the Microsoft msrc blog, Microsoft has extended the lifetime of SUS till Tuesday July 10th, 2007. So those of you not having completed deploying WSUS to replace their SUS have a few more months time.

That said, please also not that this month the SUS service will be lacking the MS06-071 patch for a little while as it wasn't finished on time.

If you read this month's microsoft security bulletins, do note that Windows XP SP1 is now not supported anymore. That means you do not get security updates and will not be warned of security issues either. So if you use Windows XP, you do not have much choice avoiding the upgrade to SP2.

--
Swa Frantzen -- Section 66

0 Comments

Published: 2006-11-14

Adobe Flash update available

Adobe has relased an update for a vulnerability in their Flash player.

CVE number is CVE-2006-5330, which interesting enough isn't included in this month's MS06-069 update from Microsoft.

http://www.adobe.com/support/security/bulletins/apsb06-18.html

Yet another thing to patch in the next few days.

Affected versions include 9.x, 8.x and 7.x .

--
Swa Frantzen -- Section 66

0 Comments

Published: 2006-11-14

WinZip 10.0 build 7245 released

Winzip released a security update today.

Winzip urges their customers to upgrade but does not seem to give details about the security vulnerability. So while you reboot those machines for the Microsoft patches, mix in a winzip installer.

http://www.winzip.com/downwz.htm

--
Swa Frantzen -- Section 66

0 Comments

Published: 2006-11-14

MS06-070: Workstation service

This is a patch to fix a remote vulnerability caused by a unchecked buffer in Workstation Service, a component of Microsoft Windows                 
                                                                                
This service is the one responsible for allow connection to shared file resources or shared print resources on a network.                         
                                                                               
As said above, it will allow remote exploitation of the machine, which would give complete control to the attacker. Most personal firewalls may protect you against this vulnerability, and despite the fact that Microsoft says that there is no public exploit or disclosure of this vulnerability yet, our advice is to test and apply it as soon as possible on your systems.

--
Pedro Bueno

0 Comments

Published: 2006-11-14

Microsoft Black Tuesday Overview

Overview of the November 2006 Microsoft patches and their status.

# Affected Contra Indications Known Exploits Microsoft rating ISC rating(*)
clients servers
MS06-066 Netware client services - remote code execution & DoS

CVE-2006-4688
CVE-2006-4689
No known problems

KB 923980
No known exploits
Important Less Urgent Less Urgent
MS06-067 Internet Explorer - remote code execution

CVE-2006-4446
CVE-2006-4777
CVE-2006-4687
No known problems

KB 922760
Actively exploited according to Microsoft
Critical PATCH NOW Important
MS06-068 Microsoft Agent - remote code execution

CVE-2006-3445
No known problems

KB 920213
No known exploits
Critical Critical Less urgent
MS06-069 Adobe flash player - remote code execution

CVE-2006-3014
CVE-2006-3311
CVE-2006-3587
CVE-2006-3588
CVE-2006-4640
No known problems

KB 923789
No known exploits
Critical Critical Less urgent
MS06-070 Workstation service - remote code execution

CVE-2006-4691
No known problems

KB 924270
Vulnerability details are public ;
Exploit available in for pay program
Critical Critical Critical
MS06-071 XML Core services

CVE-2006-5745
No known problems

KB 928088
Exploits publicly available
Critical PATCH NOW Important

We will update issues on this page as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY

(*): ISC rating
  • 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 leaisure 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-caserole.
  • 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

0 Comments

Published: 2006-11-14

MS06-067: Internet Explorer DirectAnimation and HTML Rendering Vulnerability

This advisory is a wrapper for 3 different Internet Explorer vulnerabilities:

CVE-2006-4446: DirectAnimation ActiveX Control
CVE-2006-4777: DirectAnimation ActiveX Control (not clear how it is different)
CVE-2006-4687: HTML Rednering Memory Corruption Vulnerability.

First off: All of these are exploited by exposing Internet Explorer to malicious HTML code. The "must have" precaution is to not run IE as "Administrator".

IMPORTANT: An exploit is in use against the DirectAnimation ActiveX Vulnerability!

DirectAnimation is a pre-cursor to what is not DirectX. In order to exploit the vulnerability, another deprecated library, HTML+TIME 1.0, has to be available.

The HTML render vulnerability is in particular tricky as it could be triggered by HTML e-mail.

This is a "Must Patch Now" issue for clients. Servers may want to hold off on this for a bit.
Like with all Internet Explorer patches: Don't forget to test internal critical web based applications. We had it happen in the past where such applications used older ActiveX techniques which where no longer available after a patch was applied.


0 Comments

Published: 2006-11-14

MS06-071: MSXML Core Services

CVE-2006-5745

This update patches the MSXML Core Services vulnerabilities that are currently being actively exploited by a number of web sites on the internet.

This patch should be applied immediately on all user machines and should be considered important on servers.  This bulletin appears to supercede MS06-061 which was released in October and updated last week.

http://www.microsoft.com/technet/security/bulletin/ms06-071.mspx

0 Comments

Published: 2006-11-14

MS06-069: Adobe Flash Player

CVE-2006-3014, CVE-2006-3311, CVE-2006-3587, CVE-2006-3588, and CVE-2006-4640

Updates Adobe's Macromedia Flash Player which was inlcuded in XP SP2 and XP Pro x64.  This appears to be the same update that Adobe made available in September (see here).

A buffer overflow exists that could be exploited by a malformed SWF file which could be distributed via web or e-mail.

This patch should be considered critical for user machines and less urgent for servers.  Those who updated Flash Player as a result of the Adobe bulletin should not be at risk.

http://www.microsoft.com/technet/security/bulletin/ms06-069.mspx

0 Comments

Published: 2006-11-14

MS06-068: Microsoft Agent

No CVE numbers available.  This update fixes a buffer overflow in Microsoft Agent that could allow remote code execution.

Microsoft Agent is a component of the OS that allows (to quote Microsoft) "an enriched form of user interaction that can make using and learning to use a computer easier and more natural."  This includes things like the paperclip that pops up at various times while using Microsoft Office applications.  This feature can apparently be invoked via ActiveX in Internet Explorer  Microsoft states that they are not aware of active exploitation of this vulnerability at this time.

Due to the possibility of remote exploitation, this should be considered critical for user machines, less urgent for servers.

http://www.microsoft.com/technet/security/bulletin/ms06-068.mspx

0 Comments

Published: 2006-11-14

MS06-066: Netware Client Service Buffer Overflow

CVE-2006-4688 (code execution) and CVE-2006-4689 (DoS)

The Netware Client Service for Windwos (NCSW) is used to allow Windows systems to access Netware file server, directories and printers. It runs as 'system' and this exploit would allow an attacker to execute arbitrary code as 'system'.

This service is not installed by default, and you only need it to access Netware servers. So as long as you don't run Netware, check if you got it running on a system by mistake and turn it off.

If you do run Netware (or even if you don't), make sure that you have all netware related ports blocked at your permiter. This is a critical patch for Netware users, but will only affect the client, not the netware server. Windows servers may act as clients to a Netware server.




0 Comments

Published: 2006-11-14

Microsoft XP SP2 wireless hotfix

Jakob sent in a good find over at Microsoft: http://support.microsoft.com/?kbid=917021 . It's an hotfix update to the wireless system of XP SP2 that claims to do a number of useful things:
  • Allows group policy to control WPA2 settings.
  • Allows networks in the preferred network list to be set as broadcast or non-broadcast. Setting all to broadcast prevents the computers from leaking the list of preferred networks when they do not find one in their list.
  • 'parked' wireless cards are given encryption. Parking a card is according to Microsoft: "Wireless Auto Configuration may create a random wireless network name and put the wireless network adapter in infrastructure mode.  In this situation, the wireless adapter is not connected to any wireless network. However, the wireless adapter continues to scan for preferred wireless networks every 60 seconds".
    They go on with: "Some wireless network adapter drivers may interpret this parking operation as a request to connect to a wireless network. Therefore, these drivers may send probe requests in search of a network that has the random name. Because the parking operation passes no security configuration the driver, the random wireless network might be an open system-authenticated wireless network that uses no encryption. An observer could monitor these probe requests and establish a connection with a parked Windows XP wireless client".
    Now encrypting will surely help, but it does feel funny to let it sit there configured randomly while there is no use for it doing anything.
  • Stop trying to connect to ad-hoc networks in the preferred network list.
Test it well before you deploy it widely, but it does seem a worthwhile hotfix.

See also Microsoft security advisory 917021, it contains more background information.

--
Swa Frantzen -- Section 66

0 Comments

Published: 2006-11-13

A loan offer or two

Today I received two loan offers which is unusual because I have not applied for any loans in years. When I first tried to resolve the site (~8:00 MDT) it failed. It has since come on line. The site is not rendering correctly in firefox It worked in Internet Explorer. At the bottom of their page they make it clear that they will send your information to "participating lenders" and that those lenders could call you even if your on the "do not call" list.
I suspect they are building a list for telemarketers. Also at the bottom of their page is a graphic that states "we are fully compliant with the can spam act of 2003". I removed the URL from the email because I don't wish to advertise for them. I modified the email headers to remove unimportant details and obstificate my email address.

Body of the loan offer 1:
"Thank you for your loan request, which we recieved yesterday,
we'd like to inform you that we are accepting your application, bad credit ok, We are ready to give you a $236,000 loan for a low month payment.

Approval process will take only 1 minute.

Please visit the confirmation link below and fill-out our short 30 second form.

Body of load offer 2:
"Thank you for your loan request, which we recieved yesterday,
we'd like to inform you that we are accepting your application, bad credit ok, We are ready to give you a $234,000 loan for a low month payment.

Approval process will take only 1 minute.

Please visit the confirmation link below and fill-out our short 30 second form."


Header of the First email:

Received: from 105.12.117.87.donpac.ru (105.12.117.87.donpac.ru
[87.117.12.105])by mail.notmydomain (8/8) with ESMTP id
kADFeJhv023656for <NotMyEmail@notmydomain>; Mon, 13 Nov 2006 08:40:29 -0700 (MST)

Received: from 66.179.38.137 (HELO smtp3.harrisinfo.com)    by notmydomain
with esmtp (J.E5*P/Y,8@ XS,;)    id D2,237-/3J2I3-OH    for
NotMyEmail@notmydomain; Mon, 13 Nov 2006 15:34:57 -0180

From: "Meagan Howell" <akstcharrisinfomnsdgs@harrisinfo.com>
To: <NotMyEmail@notmydomain>
Subject: We accepted your loan request
<SNIP> 

Header from email 2:
Received: from ploy-433d4dd4c8 (ppp-124.121.125.171.revip2.asianet.co.th
[124.121.125.171])by mail.notmydomain (8/8) with ESMTP id
kADErFu6026071for <NotMyEmail@notmydomain>; Mon, 13 Nov 2006 07:53:19 -0700 (MST)

Received: from 194.2.3.145 (HELO smtp.oleane.net)    by notmydomain with esmt
(439O>US,1*K0 5L2V)    id ,5X4+H-IM**Y5-T'    for NotMyEmail@notmydomain;

Mon, 13 Nov 2006 14:53:18 -0420
Message-ID: <01c70733$74a1dd40$6c822ecf@akstcapcmmnsdgs>
From: "Marquita Rosenberg" <akstcapcmmnsdgs@apcm.fr>
To: <NotMyEmail@notmydomain>
Subject: Your loan request approved

<SNIP>

0 Comments

Published: 2006-11-13

Packet Challenge: Fragments and a Blast from the Past

This time around, packets from one of my own DNS servers. If you would like to follow along, you can find the full unobfuscated packet trace here.

(quick update... turns out that the router and DNS queries involved are part of www.nlnetlabs.nl, a network research labs that does experiment with DNS servers... so maybe this is all some side effect of an experiment they are running. Thanks to Don for pointing this out to me. After visiting their website, I did see a number of similar ICMP admin prohibited packets with flipped fragmentation bytes, but the embeded packet's source port was 80! ;-) )

You should find 9 packets. To abbreviate, I am using the following notation:
DNS = my DNS Server
Q = DNS Query Source
R = router sending ICMP Admin Prohibited messages.

Here the "big picture":
  Q  -> DNS: Query for NS sans.org
Q -> DNS: Query for A sans.org
DNS -> Q : Response, Server failure
DNS -> Q : Response, Server failure
Q -> DNS: Query for MX sans.org
DNS -> Q : Response, Server failure
R -> DNS: ICMP Admin prohibited
R -> DNS: ICMP Admin prohibited
R -> DNS: ICMP Admin prohibited
These are all the packets my system exchanged with these three systems at the time. Overall, this happened in about 0.13 second. The server failure was actually a temporary issue. The DNS server is authoritative for 'sans.org' and usually responds to these queries.

Lets look at the big picture first:
We got three DNS queries, three DNS responses and three "admin prohibited" packets. Kind of makes sense. A host is requesting information from our DNS server, but a (misconfigured?) router is rejecting the responses. The timing is a bit off (would have expected 'Query','Response','ICMP' ... 'Query','Response','ICMP'...). But this is not that unusual.

So lets look at the packets in detail. First the Query for 'NS sans.org':

Internet Protocol, Src: 213.154.224.17 (213.154.224.17), Dst: 70.91.145.9 (70.91.145.9)
Total Length: 65
Identification: 0x4aa5 (19109)
.0.. = Don't fragment: Not set
Time to live: 47
Protocol: UDP (0x11)
User Datagram Protocol, Src Port: 63417 (63417), Dst Port: domain (53)
Length: 45
Domain Name System (query)
Transaction ID: 0x3180
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
sans.org: type NS, class IN
Name: sans.org
Type: NS (Authoritative name server)
Class: IN (0x0001)
Additional records
: type OPT
Name:
Type: OPT (EDNS0 option)
UDP payload size: 4096
Higher bits in extended RCODE: 0x0
EDNS0 version: 0


I removed some lines from the tethereal output. The packet looks "normal" withe the one exception of EDNS0 being used. EDNS0 is used to indicate to the receiving DNS server that the querying DNS server is able to receive more then 512 bytes of the response as a UDP packet. In this case, its 4k. A bit large, and frequently large EDNS0 packets are used to increase the amplification f or denial of service attacks.

Couple other things if you compare the packets:

  • the IP ID is incrementing. So these appear to be the only packets sent by the 'Q'.
  • the source port is constant... odd...
  • the DNS query IDs appear random.
Now lets look at the responses:

Internet Protocol, Src: 70.91.145.9 (70.91.145.9), Dst: 213.154.224.17 (213.154.224.17)

Flags: 0x04 (Don't Fragment)
Fragment offset: 0
User Datagram Protocol, Src Port: domain (53), Dst Port: 63417 (63417)
Length: 45
Transaction ID: 0x3180
Flags: 0x8002 (Standard query response, Server failure)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
sans.org: type NS, class IN
Name: sans.org
Type: NS (Authoritative name server)
Class: IN (0x0001)
Additional records
: type OPT
Name:
Type: OPT (EDNS0 option)
UDP payload size: 4096
Higher bits in extended RCODE: 0x0
EDNS0 version: 0
Z: 0x8000
Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs)
Bits 1-15: 0x0 (reserved)
Data length: 0

The response from my DNS server: well, nothing unusual here. I would like to point out that no fragmentation is used (well, there is no need to). The 'DF flag is set. The IPID is set to 0, which is typically for recent Linux kernels if the DF flag is set.

Now lets look at the ICMP packets. These are the packets that caused me to look at this issue in the first place. So far, we don't actually have much out of the ordinary. I am using the last ICMP packet here:
Internet Protocol, Src: 213.136.31.102 (213.136.31.102), Dst: 70.91.145.9 (70.91.145.9)
Total Length: 56
Identification: 0x0000 (0)
Time to live: 50
Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 13 (Communication administratively filtered)

[decoded embedded packet from ICMP message]
 Internet Protocol, Src: 70.91.145.9 (70.91.145.9), Dst: 213.154.224.17 (213.154.224.17)
Total Length: 16640 (0x4100)
Identification: 0x0000 (0)
Flags: 0x00
Fragment offset: 512
Time to live: 50
Protocol: UDP (0x11)
Header checksum: 0xbb7b [incorrect, should be 0xba7c]
Good: False
Bad : True
Source: 70.91.145.9 (70.91.145.9)
Destination: 213.154.224.17 (213.154.224.17)
Data (8 bytes)

0000 00 35 f7 b9 00 2d 3b 8b .5...-;.

Now this is where the "blast from the past" shows up:

Fragment offset 512Bytes. If you look at the Flag/Fragment offset bytes: 00 40.. flip them and you end up with '40 00' or: no fragment offset and 'do not fragment' flag set. hm... interesting...

Now if we just forget for a moment that this packet claims to be fragmented, we see that the "payload" is actually a normal UDP header: Source port 53 and Destination port 63417. This is the same port we had as a source port earlier. So if you ignore the fragmentation issue, this kind of looks like the result to the DNS response we sent earlier. Even the TTLs work out right! But then again... the size of the packet is HUGE. Looks like another byte-order issue: a size of 0x41 (65 bytes) is much closer to the size of the packet we sent.

We had a case a couple years ago with a similar byte order issue. But this is odd in the sense that the spoofed packet appears to be a direct result of the real packet. The spoofed packet is very close to the real packet. Maybe its not actually spoofed but just "mangled" by some kind of in-line device?





0 Comments

Published: 2006-11-12

Quiet day for incidents, IRC channel for discussion

     The handlers list was quiet today.  There were a few reports of malware on web sites.

    One writer asked if there was an official IRC channel for the handlers.  There isn't; we couldn't protect your privacy if we discussed security issues on a public IRC server.  That said, some of the incident handlers do spend time on the "#dshield" channel of irc.freenode.net .

0 Comments

Published: 2006-11-11

Broadcom Wireless Vulnerability

The "Month of Kernel Bug" project released an advisory with details about a bug in Broadcoms Windows driver for its Wireless card. The high/low points:

  • Only effects the wireless driver, not the broadcom wired cards.
  • The resepective file is BCMWL5.SYS Version 3.50.21.10 (this is the version pointed out as vulnerable. Others may be vulnerable as well).
  • Only Linksys published an official update at this time.
  • Other vendors have later versions of this file available as patches. It is not clear if they patch the problem or not.
  • The problem is triggered by an overly long SSID
  • the MOKB project published a metasploit module to ease exploitation of this problem.
So much for now. Expect updates as we learn more.

Go ahead and patch your driver with whatever version they offer. If you get a chance, test the exploit and see if it works against some of the later versions. Of course, take care when doing so. The "known to be fixed" version from Linksys is 4.100.15.5.

Whenever you don't use your wireless network, turn off the wireless card. In particular if you are in a public space (airport, hotel).


0 Comments

Published: 2006-11-11

Predicting Microsoft

After our morning vulnerability briefings, I often receive emails from our support engineers asking: "when will Microsoft release a patch for this?"  Answers such as "it depends" and "probably next Microsoft Tuesday," although technically accurate, do not provide much value to them.  A real answer is important to them; it impacts their planned maintenance cycles and can have a real dollar impact to the firm.  How do you really answer that question?

     First, what kind of answer is required?  For this particular example, a "yes" or "no" answer to "Will it appear in the next monthly release?" is acceptable, but a level of confidence should accompany it.  "Will it be released before schedule?" is also a key follow-on question.  So a good answer would be: "This patch in 95% likely to appear in next month's release, an early release is unlikely."

     If you don't provide a level of confidence, you really can't improve your process.  Vague terms like "not likely," or "probably," are not measurable.  If you can't measure your intelligence process, you can't improve it.  This is why confidence levels and feedback are so important. 

     To develop this answer I use a conceptual model.  This process became a lot easier once Microsoft moved to their monthly release schedule.  Given the past year's release data, I stand a reasonable chance of predicting accurately.  A key element is our knowledge base, which contains known vulnerability information, patch release dates, and details of the patch.  I expect Bayesian analysis could be as accurate as I am.  Some of the key findings from the model are:

  • Microsoft will release an out-of-band patch only if a third party has released an unofficial patch, and that patch involves a change more involved than a kill-bit.
  • Microsoft will release a patch on the next release date if the fix involves only a kill-bit.

     Try this at home/work/office yourself.  There are 5 unknowns coming out next week.  Make your guesses what will be released.  The kill-bit for the XML Core Services issue has already been announced.  Be sure to keep score, shooting for that 95% confidence rating.  For issues where you're not 95% confident, list what information you need to improve that rating.  That's how you improve your process.  For bonus points, train a learning algorithm (Bayesian, neural network, automata, etc.) to play along.

0 Comments

Published: 2006-11-11

UDP/4081 Spike

A diary-reader, Ned, reports a spike in UDP/4081 activity.  The reported source is located in China.  He did not have any captured packets, just firewall logs.  I'm 95% certain that this is messenger/pop-up spam.  I'd like to task the informal network Echelon system we have (in the form of our readers) to see if anyone can confirm this guess with a captured packet.

0 Comments

Published: 2006-11-10

New Monster Phish Bait

A reader recently submitted for review a new phish attempt which asks readers to download the "new Monster Job Seeker Tool".  The email looks authentic, as the HTML source code is pulling images from monster.com, as well as having links to other monster.com pages, however the download does not come from monster.com.  The download software link pulls the download from monster-freesoftware.com.  Of course, what is downloaded is not something monster.com would approve of.

I have sent a copy of the email to abuse@monster.com for their records as well.

0 Comments

Published: 2006-11-10

A busy Black Tuesday coming up.....

Bryan submitted today that Microsoft has sent out a pre-release notification of the goodies we can expect on Tuesday.  Taking directly from Bryan's message...
---------------------------------------------------------------------------------------------
1 patch affecting "XML Core Services", rated "critical", will require a reboot

5 patches affecting Windows, maximum rating "critical", some of these will require a reboot

New "Malicious Software Removal Tool"

2 additional "non-security high-priority updates" will be released, but only on Microsoft Update and WSUS
---------------------------------------------------------------------------------------------
Microsoft has stated here that they "will continue to support Software Update Services (SUS) 1.0 until December 6, 2006. Microsoft will no longer support SUS 1.0 after this date."  That means this is the last chance to finish testing WSUS for use on the production networks.

Thank you Bryan for the great information

0 Comments

Published: 2006-11-09

Microsoft Security Bulletin Advanced Notification

Thanks Juha-Matti, Bryan and all the others for letting us know that the monthly Microsoft Security Bulletin Advanced Notification is out.

If you don't receive the e-mail from Microsoft, or you have not yet looked at it, here is a quick summary courtesy of Bryan.

  • 1 patch affecting "XML Core Services", rated "critical", will require a reboot
  • 5 patches affecting Windows, maximum rating "critical", some of these will require a reboot
  • New "Malicious Software Removal Tool"
  • 2 additional "non-security high-priority updates" will be released, but only on Microsoft Update and WSUS

0 Comments

Published: 2006-11-09

fragmented packet challenge

Before signing off for the day and handing the helm over to Chris, I got one more diary for you.
This one is a challenge. Michael sent us this packet earlier today. He is seeing a lot of these hitting his mail server, all from the same source. I got some ideas about whats going on, but nothing "definite". So let me just show you the packet and see what you can come up with. I will post my opinion (and a summary of what you submit sometime late tomorrow.

The short summary of the packet:
- its the last fragment (MF is cleared, offset is 1472
- there are 8 bytes worth of payload
- the protocol is TCP

I obfuscated pieces that would help identify the submitter.

Update

I received a couple or interesting responses to this "challenge". Couple people noted that the offset + packet length is 1480, which would be in line with a regular ethernet MTU of 1500 bytes.
Alex had a couple of interesting insights: He noted that the 8 bytes of data are consistent with Base64 encoded data. While there is not enough data here to reconstruct any content, he suggests it may be one of the many "spam images" going around these days.
Also, he menioned that 1472 is a common MTU for PPPoE DSL connections.
So a likely reason for the fragment is that the host is connected to a local ethernet network which is using a DSL uplink.

The reason the first fragment is missing is likely some kind of packet filtering device. Given that only the first fragment will include the port number, the packet filter allows the second fragment to pass.

Lessons learned:
- If you are using a DSL modem with PPPoE, take a look at what MTU it supports. Your internet experience may improve if you reduce your MTU to match the DSL modems MTU.
- Check how your border device deals with fragments. I typically like to put some kind of statefull firewall at my border that will reassemble fragments. Most of the home-devices (NAT routers) typically do a good job at that. Its a bit more challenging to find one that can deal with large loads (in particular if you have a lot of connections. The bandwidth is sometimes not as critical here as the number of connections you are trying to support.

Thanks to everyone who responded!



Frame 1 (60 bytes on wire, 60 bytes captured)
Arrival Time: Nov 8, 2006 10:46:21.288548000
Time delta from previous packet: 0.000000000 seconds
Time since reference or first frame: 0.000000000 seconds
Frame Number: 1
Packet Length: 60 bytes
Capture Length: 60 bytes
Protocols in frame: eth:ip:data
Ethernet II, Src: (xx:xx:xx:xx:xx:xx), Dst: (xx:xx:xx:xx:xx:xx)
Type: IP (0x0800)
Trailer: 000000000000000000000000000000000000
Internet Protocol, Src: xxx.yyy.171.21 Dst: aaa.bbb.181.18
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 28
Identification: 0xdf49 (57161)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 1472
Time to live: 112
Protocol: TCP (0x06)
Header checksum: 0xXXXX [correct]
Good: True
Bad : False
Source: xxx.yyy.171.21
Destination: aaa.bbb.181.18
Data (8 bytes)

0000 75 37 68 4c 52 65 2b 4d u7hLRe+M

0 Comments

Published: 2006-11-08

Windows WMIObjectBroker 0-Day Exploit

Rohit from Tippingpoint adviced us that he is seeing a large number of attacks from Russia using an un-patched vulnerability in the WMIObjectBroker ActiveX control. He is seeing it used as part of a drive-by download. Typically, the Trojan "Galopoper.A" is load.

There is no patch available at this point. Tippingpoint and the Bleedingthreats projects have signatures available to detect this attack. Rohit mentioned that there is a metasploit module for this vulnerability. 

0 Comments

Published: 2006-11-08

Form Spam: Increasing the Attacker's work function.

Quite a while ago (2 years?) we started using a contact form. Part of the reason for the contact form was to avoid having to post our e-mail address to the site. Because we all know that posting your e-mail address on any web site is a sure way to get spammed to death. However, over the last year, the amount of spam sent via our contact form has exploded, and it was time to figure out how to combat it.

For a brief time we used "captchas". The idea is simple. You add a hard to read image of a few random letters asking a submitter to identify themselves as "human" by entering the text. However, the problem is obvious: To make it hard to OCR the image, it has to be quite hard to read. I came across one perl script used by a bot, that can recognize simple captchas in a second. Good captchas need to use colors, distorted letters and such, making them hard to read for many humans even if they have good eye sight.Using such a form can be difficult if you have bad vision. Our somewhat ugly home made captcha solution caused submissions to drop by about 30%, which wasn't acceptable.

Next, we implemented a couple of simple key word filters. They worked ok, but its kind of hard for us. What about people who are trying to send us a report that they see a bot that sends "Viagra" ads?

Another approach we took (and still take to some extent) is to block spammers. We had a lot of repeat offenders. But then again, they sometimes come through proxy servers and from dynamic IPs, so we end up locking out legitimate users as well. For what its worth: We do see in some cases a couple thousand "spam attempts" from IP addresses after they get blocked.

What you are really looking for is a method that will make it harder for a machine to submit a report but will be invisible to the user. Last week I experimented with this and came up with two ways to do so. One is implemented now and works amazingly well. The other doesn't work for us but may work for you.

First the method that doesn't work for us: Encrypted forms in Javascript. This one doesn't work for us since given our audience, I don't want to use Javascript for anything that is affects usability of our site. Sure, maybe some eye candy here and there, but that's it. Essentially encrypted javascript is what a lot of malware uses to disguise itself. But why not use it to "hide" a form from bots? The work to decrypt it is done by the browser and the user will never know that the form is encrypted. A spammer could implement a javascript parser, but its extra work. And now you just made their spam-bot slower by a factor of 10 or however long it takes to decrypt the form.

The second method is simpler, and does not require javascript. Instead, one or more fake form fields are added to the form. But style sheets are used to make them "invisible". To further confuse the attacker, the fake form fields are given names like "subject" and such suggesting to the bot that these are the form fields they are looking for. However, whenever a form is submitted with content in a "hidden" field, it is discarded. I am not talking about the classic hidden form fields that are not user changeable, but form fields that are marked with "display: none" like:

Sure, in particular after I write this article, attackers may catch on. But there are many ways to mark a form field as "invisible". You can randomize the names of your form fields to further confuse them. In short: you again increased the workload on the spammer without affecting the regular user. For a sample, just take a look at our contact form. We received only about 3 or 4 pieces of spam after implementing this last week. Usually we received dozens of pieces of spam a day.

All modern browsers do support style sheets, and for those that don't you can leave a little note in the form telling them whats going on. The fact that still some spam makes it past this method suggests that there is some manual spamming going on. But its minimal... and sure, lets have them hire armies of spaminators to have them submit these forms. Either way you succeeded in making spam more expensive and shifting the economics against it.

Couple user feedback items:

- Margles suggest to use a modified form of captcha: "Why not use an image to be identified? A house, or identify the gender of a person standing in the doorway, or a cat versus a dog. Something that would lend itself to one-word identification.".
Great idea. I think that's at least easier then some of the horrible captchas.

- Ed writes: "So far I have been successful by using a session variable that is set when the form is requested via http get. If the submitted form doesn't have the session variable set, I dump the email and return a bogus error message. Also I strip any http://  or  http://www from any submission so our users aren't likely to click on any links that load malware. The domain name, path and filename remain but its not hard to reconstuct if its a legitimate url submission."
I did try the session variable, and it didn't work for me that well :-(. Maybe I didn't implement it quite right.

- Neal writes: "[on some site the] submission from .. asks you to enter ... text found in a gif. However, no matter what you enter the first time, it says you entered it wrong"
Mean and devious. I like it!
"The best solutions I found requires symantical interpretation ... For example: Complete this sentance: I ate a ____ and it was good. ...  (a) hand (b) watermellon (c) rubber band (d) tire (e) Billy"The problems with this approach: ... non-english speakers... 5 options is still 20% spam ..."
        ... rubber tires (drool...)
Neal also points to this method which somewhat implements what was suggested above: http://www.kittenauth.com/ . Pictures of cute kittens! How can one NOT use that approach ;-) ?



---------
Johannes Ullrich, SANS Institute.



0 Comments

Published: 2006-11-08

Mozilla Firefox 1.5.0.8 and Thunderbird 1.5.0.8 Released

The Mozilla Foundation released version 1.5.0.8 of both their popular Firefox web browser and Thunderbird email clients today.  These versions address some security issues covered in MFSA2006-65, MFSA2006-66 and MFSA2006-67.   

If you have not already upgraded to the new Firefox 2.0 web browser, you should be sure to update to Firefox 1.5.0.8.

You can download the new versions off their web site at http://www.mozilla.com.

0 Comments

Published: 2006-11-07

MSXML 4.0 exploit in the wild

We've received a report of the MSXML 0-day exploit being used in the wild. This is the exploit Johannes wrote a couple of days ago (http://isc.sans.org/diary.php?storyid=1825).

The exploit does not seem to be in wide use just yet, but that can, of course (and we expect it to), change very quickly.

For the exploit to work it *needs* Microsoft XML Core Services to be installed. Microsoft XML Core Services are not installed by default on Windows XP, but there seems to be a lot of packages using it, Visual Studio appears to be one common one. You can check in the Add or Remove Programs applet if you have it installed.

The exploit works in both IE6 and IE7, which makes sense since it's exploiting a vulnerability in an ActiveX object, not in the browser itself.

When executed the exploit creates an MSXML 4.0 ActiveX object (88d969c5-f192-11d4-a65f-0040963251e5). It then uses multiple setRequestHeader() method calls to execute shellcode which is included with the exploit.

Once executed the shellcode (of course) first downloads the first stage downloader. At the moment it's a file called tester.dat:

16ac9982d177a47a20c4717183493e95  tester.dat

This downloader then downloads subsequent files (yet to be analysed).

It looks like some AV vendors are beggining to detect the exploit. At this moment it is being detected by McAfee as Exploit-XMLCoreSrvcs and Symantec as Bloodhound.Exploit.96. Microsoft also detects it as Exploit:HTML/Xmlreq.A.

The best protection, is to prevent the XMLHTTP 4.0 ActiveX Control from running in Internet Explorer, as stated in Microsoft's advisory: http://www.microsoft.com/technet/security/advisory/927892.mspx.


0 Comments

Published: 2006-11-07

Sophos Reveals the "Dirty Dozen"

I came across an article today about spam and what Sophos calls the "Dirty Dozen".  This refers to the top 12 spam producing countries in the world.  What I find rather interesting and somewhat ironic is that the US leads the way with being responsible for 21.6 % of the spam that was distributed in the 3rd quarter. 

Sophos reveals "Dirty Dozen"

Sophos says that they believe the increase in spam may be attributed to the some 300 strains of Stration or Warezov worm.  What I have to wonder about is why we still have so many people clicking on attachments (especially ZIP files) in unsolicited email.  What will it take for people to get the message that if you didn't ask for it, don't open it? 

Another thing that I find interesting is this statement in the article:

"Most unsolicited emails are now sent from zombie PCs - computers infected with Trojans, worms and viruses that turn them into spam-spewing bots."

With all the programs available to help with removal of the spyware, viruses and the like why do we in the US still have so many home computers infected with various forms of parasitic programs.  I worked on a computer a few nights ago that had over 300 different viruses, spyware and trojan-esq programs on it.  After a format and reload and installing all of the appropriate software and updates, I explained to the owner of the computer exactly what it was that happened and how it happened.  I explained that virus software does expire so you do have to renew it annually or subscribe to a service such as SecureIT that takes care of all of that for you.

Eventually maybe we will get to the place where the bad guys can't do anymore damage to the Ma and Pa home and small business computer.  I guess until then we just have to live with the fact that we are as guilty as the rest of the world at not being good Netizens.


0 Comments

Published: 2006-11-07

Malicious Trojan poses as McAfee alert

It appears now that McAfee's name is now being used to spread a new trojan via email.  The email arrives presumably from McAfee with an attachment that actually spreads the trojan.  This mass mailing is unusual because it attempts to spoof the email address mcafee @ europe . com.  This trojan has been given the name Lafool.v by Kaspersky labs and is a password stealing program.

Vnunet article

0 Comments

Published: 2006-11-07

Buyers Beware

Once again we have a nasty little email circulating that is trying to scam the unsuspecting Internet users out of their hard earned dollars. The email purports to have a product that can “guarantee that all of your banking transactions are completely secure”.  In reality this scumware does anything but…

They are selling a VPN solution and would love to have you fall for it er…  purchase it. (Adding to their little bot I am sure).

As a matter of fact when I tried to go to the web site I got a warning from my filter that the site was a known spammer site.  

As always use good common sense and extreme caution.  Don’t believe everything you receive in email or everything that you read online.  You never know when the website is from “Russia with love” or some other far away place.

0 Comments

Published: 2006-11-07

Abuse handling and the misfortunes of the good Samaritan

The requirement for domain name holders to provide a working abuse@example.com email address comes not only from tradition, but also from RFC 2142. It's interesting to note that that RFC doesn't address itself to just ISPs, it goes for any entity on the Internet.

So do your postmaster, info, NOC, hostmaster, webmaster, abuse, security, ... email addresses actually work ?

Having been on both sides of the fence when it comes to abuse@isp.net let's look at some misconceptions:

  • "let's use an auto-reply": auto-replies are in my book evil. But they are also an insult to somebody trying to do their best in making the Internet a better place and reporting on such a thing. Sure submitters will appreciate a short note that their complaint has been dealth with and thanking them for their time, but do so after you processed it. Worse are auto-responders that give a whole bunch of instructions on how to submit things that just aren't relevant.
  • "filter the spam": I've seen an abuse departments demand a copy of the spam be attached to the email and running a spam filter that bounced the message due to it being detected as spam if the spam was attached. Guess how many valid spam reports they got.
  • "form letter reply": While I think form letters are in fact good for responding to abuse notifications, you need a bunch of them, not just one. E.g. I've received form letters asking for an attachment of the spam I was supposedly complaining about while submitting a defaced website hosting some malware to an ISP. The range of complaints is always wider than what your form letters can encompass and submitters have better things to do than wade trough overly long form letters anyway. So keep them short and to the point.
  • "automate it": While there are abuse reports that can be automated (e.g. the motion picture lawyers use a xml attachment that can easily be automated to trace back your peer2peer copyright abusers), trying to widen this to encompass all complaints just will not work for the same reason as your form letters don't always work.
  • "web form": The horror method for reporting entities. You write up everything they need in a neat email and get a rude auto-reply to please use http://obscure.web.example.com/silly.form instead.
  • "abuse is helping users/customers": Abuse is actually more the one wielding the whip, kicking out unwanted elements based on the AUP (Acceptable Use Policy) or ToS (Terms of Service) or other policies. Helpdesks typically are streamlined to help users to take care of customers. Mixing the two roles into one group can cause abuse to become very inefficient at kicking out the unwanted elements. Abuse helps the outsiders getting the users/customers under control.
  • "abuse kicks out our good customers": Yes, abuse will trigger processes to kick out misbehaving customers. But they aren't the nice customers and if you do not deal with those misbehaving customers your really nice customers as well as yourself will face consequences as your neighborhood is fast becoming a bad neighborhood on the Internet.
So what does work for both sides?
  • Handle the incidents, make sure the users/customers know you are strict as it leads to less abuse. Have policies that have teeth and can bite, and let them work even when external. This will result in a very short time in less incidents to handle as once you take a few harsh measures you eliminate the really bad apples and the word will spread so that the rest starts to behave a bit.
  • Have forms letters for:
    • Thanking submitters and letting them know it's been dealt with (where I live you cannot -legally- give details of what you did).
    • Asking for more details, but be specific what you need extra for the case at hand.
    • Warning users/customer they are breaching policy
    • Escalating incidents to be investigated further
  • If you get easy to automate requests: sure process them, but keep a human supervision to it to make sure it doesn't get abused itself.
  • Do not filter the abuse email with anti-spam software, people will forward spam messages originating from your users/customers, so you need to let it in. Yes, you'll have to delete the regular crop of spam.
  • Handle the queue manually. Somebody put time into writing up the compliant, you should too.
Some examples of bad replies:
  • Somebody reporting a defaced website spreading malware: "Thank you for submitting a report to the [X] Network Abuse Department. Unfortunately, your submission does not contain sufficient information to determine the nature of your issue.  Evidence to Abuse should always include at least the IP address of the offending party and a valid timestamp, which includes time, date and timezone."
    If you host the website or if your customer hosts it, they will have better timestamps then the submitter. You really need to accept incidents and work with them on a minimal basis, if you need more you can always ask for more later on, but e.g. in this case the website is defaced "now", just check it and act on it. [BTW: checking a website distributing malware: take care with that browser ...]
  • "Thank you for submitting a report to the [X] Network Abuse Department. Unfortunately, we are unable to investigate the email you forwarded because it does not appear to have originated from the [X] network." Well perhaps the automation missed the ball completely here. There was an attached email (actually an auto-reply from the organization itself). There are two problems however:
    • The assumption that any attached email is what is being complained about. What if it was (as in this case) a clarification of the failing reporting process.
    • The email did originate from the organisation itself. Interpreting email headers is not easy. If you cannot detect normal email headers reliably, don't even try to interpret spammed email headers (spoofed information).
With thanks to Chris, a very good Samaritan out there trying to make the Internet a better place and being plagued with well below par reponses from the big ISPs out there, yet still motivated enough to share his experiences.

Success!

--
Swa Frantzen -- Section 66

0 Comments

Published: 2006-11-07

Substantial Increase in Infected System Numbers (is it real?)

Starting mid October, we did see a jump in the numbers of "source IPs" recorded by DShield. "Sources" are essentially the sources of packets dropped by firewalls and reported to DShield. While there are some false positives of course (so I wouldn't go as far as to say that all of these systems are exploited), the majority of these systems is typically part of a botnet or infected with the worm of the day.

For the last few months, he number of source IPs hovered at around 1 million per day. However, as of Oct. 18th, this number all for sudden surged to about 1.6-1.8 Million.This coincides with a dramatic increase in spam. While I haven't had a chance yet to exactly correlate this with spam numbers, the time looks suspiciously similar.

Note that the number of source IPs in our database not only correlates to the number of infected systems, but it is also related to how aggressively these systems scan. We did see one trend over the last year where infected systems scan less aggressively as they used to. This is somewhat part of the shift from random worms to more intelligent bots.

See below for a graph of source IPs vs. date for the last month. Note that this is still work in progress. We did not have a chance yet to eliminate all possible errors like a skewed submitter, an error in our data interpretation or the like. But the number of sources has been very steady since June (second graph shows the longer term numbers).

Update: A bit more analysis.... it looks like not all submitters are seeing the same increase. So either this is target, or there is some skew in the data. Some of the users seeing big increases are long time submitters.However, one particular new user reported from 900k sources! So this could very well cause issues.

Update(2): even after removing the suspect submitter, we still see a significant increase. So a lot of the 900k sources reported have also been reported by others. The total without the suspect submitter is about 1.2 Million sources post Oct. 16 (900k before).



0 Comments

Published: 2006-11-06

New Windows Kernel Issue (MoKB)

Good morning/evening everyone.

Earlier today, we became aware of a new vulnerability that does not appear to have a workaround available.  On the outset, it does look like a Denial of Service style bug, but leaves room for remote execution possibilities.  From our take on it, the code must be run locally on the computer.  So depending on the delivery mechanism for the exploiting code, you may have a very nice attack. We are investigating this flaw further and hope to report something further such as workarounds, or ways to help mitigate this issue.

source: http://projects.info-pull.com/mokb/MOKB-06-11-2006.html

0 Comments

Published: 2006-11-06

Internet Explorer XML Vulnerability

Microsoft released a knowledge base article about a newly reported vulnerability in XMLHTTP 4.0 ActiveX Control. This Active-X control is required to interact with specific web sites using XML queries. We are not aware of any widely used applications of this technology. While it is similar to Ajax in scope, it does not look like it is required to use Ajax.

In line with Microsofts advisory, we recommend setting the respective kill bit to disable execution of this ActiveX control:
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\
{88d969c5-f192-11d4-a65f-0040963251e5}]
"Compatibility Flags"=dword:00000400


(we had a mention of a possible PoC from the Month-of-Kernel-bugs project. but it looks like these are two distinct issues)

0 Comments

Published: 2006-11-06

sinFP-2.03 release

Well, it has been a pretty slow weekend at the ol' Storm Center.  As someone who is always on the lookout for new and interesting tools, I did see an announcement of a tool that I am unfamiliar with, but plan to check out because it looks kind of interesting.  It is called sinFP.  It is an OS fingerprinting tool in Perl and version 2.03 was released early next week.  The papers about it are in French (which I don't read), but the web page claims that it overcomes some limitations in nmap's OS fingerprinting.  It also claims to be able to do OS fingerprinting of IPv6 traffic.  If any of our readers have any experience with the tool, I'd like to hear from you.  Also, if you know of any other interesting tools, please drop us a note at the contact page.

----------------------------------
Jim Clausing, jclausing --at-- isc dot sans dot org

0 Comments

Published: 2006-11-04

Microsoft Security Advisory (927892)

Microsoft Security Advisory (927892)

Vulnerability in Microsoft XML Core Services Could Allow Remote Code Execution

Microsoft published an advisory yesterday regarding a vulnerability in the XMLHTTP 4.0 ActiveX Control, part of Microsoft XML Core Services 4.0 on Windows. They indicate in the advisory that they are aware of limited attacks and are investigating the reports further.

According to the advisory "
Customers who are running Windows Server 2003 and Windows Server 2003 Service Pack 1 in their default configurations, with the Enhanced Security Configuration turned on, are not affected. Customers would need to visit an attacker's Web site to be at risk."

Microsoft Security Advisory


Thanks to Edwin for providing us with this information.

Update - This is now a zero day with exploits in the wild.

FRSirt Advisory

XForce Advisory

0 Comments

Published: 2006-11-03

Malware Analysis Quiz 7!

Well, it is time for another malware analysis quiz! This time, I put a more advanced one, which I hope that you like it!:) Answers should be submitted until November 30th. Check it out right now! (btw, the zip password is 'infected').

0 Comments

Published: 2006-11-03

Call for packets TCP/UDP port 48318

One of our readers wrote in to tell us that they are experiencing alot of traffic on TCP port 48318.  They even sent us a pcap of the traffic so we could take a look.  Unfortunately the pcap only contained inbound SYN packets, and outbound RST packets.  

The Source IP's were from totally different countries, and unique in makeup.  Some packets could be from Windows Machines, (judging from TTL, options..etc) and some don't appear to be.

Taking a look at our port graph here...



Clearly we have something going on.

So we need some packets.  Don?t bother sending us just SYN packets, we?re going to need at least some 3 way-handshake stuff. 

Now.  We are NOT telling you to allow this port through the firewall, lets just get that straight.  But if you were in an operational environment where you may be allowed to get us a dump of the traffic with PERMISSION, then that would be great.

Joel Esler

0 Comments

Published: 2006-11-03

kaspersky.com, are you awake?

A reader wrote in and asked us if we could get to kaspersky.com, the antivirus vendor.  We can't get there either.

We have watched their DNS lookup change from IP to IP.  So they may be doing some updating just now.  We'll keep an eye on it.

Update #1 -- Kaspersky pinged us.  They are awake... :)   They are aware of the problem and are working on it.  Thanks for getting back to us!

0 Comments

Published: 2006-11-02

New OS X PoC virus

There is again a Proof of Concept Virus for Mac OS X. To be honest the virus is no big deal in itself. But it is yet another warning for a lot of parties involved.

As we said before the ability to have viruses and all sorts of other malware is inherently available in all modern operating systems, Mac, Linux, BSD, ... included.

It is a warning to get antivirus protection for those Macs, even if the shopkeeper told you you do not need it, even if there are no viruses in the wild today, even if it's hard to buy it, and even if the antivirus vendors seem not to know what they talk about like in the image below (highlights are mine):


I'm sure it's just a template problem, but a problem nonetheless.

Yet, it is still your responsability to make sure you do not spread malware (even if you might not be vulnerable to it yourself).
And when (not if) a really bad one hits you or your company it's better to be ready and have a framework to distribute signatures ready than to have to start shopping, get a budget, get purchase to order it, roll it out, ... after you got hit. It is a lot easier to do before you get hit.

So Apple, Apple shopkeepers, antivirus vendors and Mac users, PLEASE get a decent framework in place and please be aware there is no magic shield preventing malware on a Mac (or any other modern platform).

P.S.:
- I writing this on my Mac, and I love my Macs.
- Thanks to Juha-Matti for pointing out the PoC.

--
Swa Frantzen -- Section 66

0 Comments

Published: 2006-11-02

PHP: time to upgrade!


The PHP team announced today the release to the 5.2.0 version.
This is a major release and besided the new features, what we are looking for are the
security fixes, and the over 200 bug fixes.

Please, please, please, upgrade your PHP as soon as possible! We dont need another round of those bots/worms that exploits it, right?

--------------------------------------------------------------
Handler on Duty: Pedro Bueno ( pbueno //%%// isc. sans. org )

0 Comments

Published: 2006-11-02

Bluetooth 0day hacking

Over the past few years with the high adoption of bluetooth by mobile devices, such as pda, phones and others, few advances were made in the security area, despite de fact that it is deserving more and more attention from security researchers.

Thierry Zoller wrote to us reporting a presentation that he and Kevin Finistere gave in a security conference in Luxembourg. In this presentation they show some new 0day related to Bluetooth and a live demo of getting a remote root shell over bluetooth on a Mac OSX 10.3.9 and 10.4 !

I recommend you to take a look on their presentation and on the live demos ! Ah, I also recommend you to pay attention in which of your devices has bluetooth turned on and which ones really needed to be on!:)

0 Comments

Published: 2006-11-02

Internet Explorer 7.0 High Priority Update


Just a quick update with more recent numbers. As of today (Nov. 6th), MSIE 7.0 share is still around 26% of all MSIE users who visit http://isc.sans.org. About 50% of our firefox users use Firefox version 2 (40% use 1.5 and the remaining 10% use various older version). So it looks like only a small number installed MSIE 7 after it became a high prioirty update. But then again... this is for isc.sans.org, not an average web site. If you are willing to share logs from an "average" (= consumer oriented) site, let us know.





Alex was the first reader to report that Internet Explorer 7.0 is now a high priority update on Windows Update. Unless you setup the respective blocking script, expect IE 7 to be installed on your systems if they are configured to retrieve and install high priority updates from Windows Update.

The update is still interactive. You will not just come back to your system and find IE7 all ready to go.

For isc.sans.org (which is probably not y our typical site), 50% of Firefox users already use Firefox 2.0, and 23% of Internet Explorer users use MSIE 7.0. Overall, we got about a 50/50 split between Firefox and Internet Explorer users.

I will keep the table below updated throughout the day to see if this changes the uptake of MSIE 7.0 for our users (the data comes from Google An alytics, which we use for our web stats tracking)

Last update: 7:47am EST.

   November 1st
 November 2nd
 Firefox (total)
 46.54%  45.13%
 % of Firefox users using Firefox 2.0
 46.54%  47.00%
 Internet Explorer (total)
 45.83%  45.78%
 % of Internet Explorer users Internet Explorer 7.0
 22.70%  24.11%
 Opera  2.79%  4.87%
 Safari 1.91%   1.08%

0 Comments

Published: 2006-11-01

IE unspecified remote code execution vulnerability

Bugtaq has a report of an unspecified remote code execution vulnerability for IE 6 (it doesn't say IE 7 is *not* vulnerable, it doesn't say anything). The post is complete with proof-of-concept code.  The vulnerability would allow an attacker to run code with the permissions of the user running IE. There is a 4 page paper in PDF format that discusses the bug.  At this point I haven't seen any other advisories.  More information when we have it.

UPDATE:
Cisco (??) has an advisory out on this one.  They state it is anything IE 6 SP2 and before, which I read to imply IE 7 is fine.  More specific info is included here. The problem exists with WScript.Shell which allows malicious JavaScript to do some nastiness to your machine.  Long and short, it could be ugly, it might not be.  More info is needed.  But it's another exploit that requires bringing the victim to the exploit.

UPDATE 2:
This is actually code to do the same thing as CVE 2006-4704, i.e. exploit the same bug, so it's not all the new.
--
John Bambenek
bambenek /at/ gmail (dot) com

0 Comments

Published: 2006-11-01

Visual Studio 2005 Remote Code Exploit, Actively Being Exploited

Microsoft has issued an advisory on a remote code exploit in Visual Studio 2005 (CVE 2006-4704) in the WMI Object Broker control. The vulnerability can be exploited by getting the user to view a malicious web page with the exploit and it will allow an attacker to take full control of the system. Currently users running Windows 2003 with Enhanced Security Mode in the default configuration are not affected.  Also, users running IE 7 are not affected (as long as they do not opt-in to the particular ActiveX control).

There is also a kill bit that can be set to stop this vulnerability (place the following in a .reg file and apply it):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{7F5B7F63-F06F-4331-8A26-339E03C0AE3D}]
"Compatibility Flags"=dword:00000400

This vulnerability is being **actively exploited**.  The advisory states that Microsoft is planning an update for this problem and it should go out in the next monthly patch cycle.

UPDATE: CERT has a notice up also.

--
John Bambenek
bambenek /at/ gmail (dot) com

0 Comments

Published: 2006-11-01

Remote DoS in Firefox 1.5.0.7 and Firefox 2

There is a new advisory out that indicates there is a remote denial of service exploit in Firefox 1.5.0.7 and Firefox 2.  The original post indicated that there could be a buffer overflow and remote code execution component, but as of 10/31 this has not been verified. This exploit will occur when a specifically crafted webpage tries to create a range object with "createRange". So far it will only make the browser crash.  If new information is made available, we will post updates.

---
John Bambenek
bambenek /at/ gmail (dot) com

0 Comments