Diaries

Published: 2006-05-31

Snort bypass vulnerability

Demarc just released a vulnerability alert on Snort. The vulnerability leads to evasion of URI content rules. When a carriage return is added to the end of a URL (before HTTP protocol declaration), Snort detection can be evaded. According to the alert, this vulnerability will affect thousands of detection rules in the standard rule base. No need to panic at the moment though, as the folks at Sourcefire have fixed this in version 2.6.0 and we haven't seen this kind of traffic in the wild yet. Thanks to Ben McDougall for reporting this to us and our friends at Sourcefire for info on the extent of the problem.

Please refer to the vulnerability alert for more details,
http://www.demarc.com/support/downloads/patch_20060531

0 Comments

Published: 2006-05-31

More on Symantec vulnerabilities

The latest patches from Symantec are causing quite a bit of confusion. To reiterate again what Kevin wrote in his diary (http://isc.sans.org/diary.php?storyid=1368):

*ALL* versions of 10.0.x and 10.1.x of Symantec Antivirus Corporate Edition and 3.0.x and 3.1.x of Symantec Client Security seem to be vulnerable.
Symantec Antivirus Corporate Edition version 8.x and 9.x seem to be ok.

Symantec released 4 patches for each product (http://www.symantec.com/avcenter/security/Content/2006.05.25.html):

Symantec Antivirus Corporate Edition
10.1.0.394 -> 10.1.0.396 (there's a typo here on their web, it's not version 3)
10.1.0.400 -> 10.1.0.401
10.0.2.2010 -> 10.0.2.2011
10.0.2.2020 -> 10.0.2.2021

Symantec Client Security
3.1.0.394 -> 3.1.0.396
3.1.0.400 -> 3.1.0.401
3.0.2.2010 -> 3.0.2.2011
3.0.2.2020 -> 3.0.2.2021

Now, if you are running *ANY* other version that is affected, you will have to first upgrade to one of the versions that have the patch out and then install the patch. I hope this will clear the confusion.

There seem to be some mitigations to the problem though. As eEye stated, this is a remotely exploitable vulnerability. Symantec Antivirus Corporate Edition, when in managed mode, will have the service Rtvscan.exe listening on TCP port 2967. In case that your host based firewall is configured to block access to this port (effectively meaning that you can't manage the client from the centralized server, at least not until the client connects to it) you should be ok.
On our test machine, the unmanaged installation of Symantec Antivirus Corporate Edition didn't have any listeners so it looks like it's safe, at least from a remote exploit over the network (patch in any case!).

If we get more information we'll update the diary. Thanks to Gary for help with this.

0 Comments

Published: 2006-05-31

Multiple security vulnerabilities in Secure Elements Class 5 AVR (EVM)

US-CERT published 19 (!!!) advisories about vulnerabilities in Secure Element's Class 5 AVR (Automated Vulnerability Remediation). The product is also known as C5 EVM (Enterprise Vulnerability Management). It allows auditing, evaluation and compliance with various policies. You can find more information about the product at http://www.secure-elements.com/products/index.htm.

There are too many vulnerabilities to list them here, but they look very bad – starting from hard-coded user IDs and passwords, over same encryption settings for every message session to typical input validation vulnerabilities.

You can find the complete list at US-CERT's web site; http://www.kb.cert.org/vuls/bypublished.

The vulnerability is reportedly patched in the latest version of the product, C5 EVM 2.8.1.

Thanks to Juha-Matti for reporting this.

0 Comments

Published: 2006-05-30

Link to 'a new Microsoft patch' being spammed

We've received samples of an e-mail which is being actively spammed at the moment. The e-mail purports to be from Microsoft and it is notifying the recipient of "a new vulnerability [that] has been discovered in the Microsoft WinLogon Service". It further states that the vulnerability can allow an attacker access to the unpatched system.

Of course, the user is advised to install the patch which can be downloaded from the included link.

As the e-mail body is an HTML message, the displayed link (http://www.microsoft.com/patches-win-logon-critical/winlogon_patchV1.12.exe) is not where the user will really be sent:

http:// www.redcallao.com/ [REMOVED] / winlogon_patchV1.12.exe

At the time when this diary was written, the site was still up and serving malware. AV detection although a better then first time when we tried it, is still pretty bad. Only 8 products from VirusTotal detected this:

AntiVir     6.34.1.34   05.29.2006    Heuristic/Crypted.Modified
BitDefender 7.2         05.30.2006    Trojan.BeastPWS.C
Kaspersky   4.0.2.24    05.30.2006    Trojan-Spy.Win32.Delf.jq
NOD32v2     1.1566      05.30.2006    Win32/Spy.Delf.NBR
Panda       9.0.0.4     05.29.2006    Suspicious file
Sophos      4.05.0      05.30.2006    Troj/BeastPWS-C
Symantec    8.0         05.30.2006    Infostealer

Does all this sound familiar? Sure, it's (almost) the same story that the Swen worm (or Gibe.F) tried to "sell" to the users. Hopefully this one will not come close to doing what Swen did.

0 Comments

Published: 2006-05-29

The Intelligence Cycle for a Vulnerability Intelligence program on-the-cheap

A Vulnerability Intelligence program should be a key component of any sound network security strategy.  It should dovetail with a Vulnerability Assessment process and a patching/remediation process.  While a Vulnerability Assessment process will tell you what needs to be patched, Vulnerability Intelligence should tell you what needs to be patched first and what new patches need to be evaluated.

Like any intelligence process, be it on the battlefield in the form of Military Intelligence, or in the marketplace under the guise of Competitive Intelligence, Vulnerability Intelligence follows the same cycle:

Planning and Direction
Collection
Analysis
Dissemination

The start of the cycle is Planning and Direction.  This is when management and other stakeholders define the goals of the Vulnerability Intelligence.  If not enough time is spent defining these goals success of the program is at-risk.  The goals should be defined as the questions that management and other consumers want to have answered.  For example, "Is our environment unnecessarily vulnerable?" or "What attacks are we currently vulnerable to?" are somewhat broad, especially for an intelligence program "on-the-cheap."  Target questions such as: "what patches should we be focusing on today?"  or "How vulnerable are our mailservers?" are a bit easier to deal with on a budget.  Without such focus, a team runs the risk of dealing with what is currently getting the most media attention.  Which may not exactly meet your organization's goals.  Another decision that needs to made is the timeframe for the process.  If your organization requires a long head-start or advance-warning, then on-the-cheap may not provide you with the results that you need.

The Collection phase is often the phase that gets the most attention.  This is where all of the cool toys are, and where likely spends most of their budget.  Since this is all on-the-cheap, I am going to skip subscription based services and share a couple of my secret-weapons of collection.  First, never underestimate a good RSS feed.  There are numerous free sources of vulnerability intelligence to get you started.  Many offer RSS feeds that you can consult on a daily basis.  A program that I use to maximize my collection potential is Website Watcher (although I don't like to endorse products on this forum, this tool should be considered to save you a lot of daily websurfing www.aignes.com/).  Some good initial sources to monitor are the Bugtraq database at http://www.securityfocus.com/vulnerabilities (which has an associated RSS feed) and Secunia (http://secunia.com/) which offers you the advantage of monitoring a single technology.  Other sources that you will want to monitor are the security advisories of the vendors of products that are in your environment.  Getting the information directly from the vendor is a sound counter-FUD strategy.

Analysis is where collected information become intelligence.  The two most-common Vulnerability Intelligence analysis process are: "Does this impact our environment?" and "If so, how badly?"  A good inventory of deployed technologies or access to the discovery scan results of the latest vulnerability assessment sweep is helpful.  Should that not be available, a "better-safe-than-sorry" approach could be exercised where, when in doubt, the intelligence team assumes that the product is within the firm; this approach can be wasteful of resources.  When addressing the potential impact of a vulnerability, it can be more efficient for the intelligence group to assess the vulnerability's threat to a hypothetical system, and allow the engineers in the field to apply additional tweaking of the threat posed.  I'm a fan of the Common Vulnerability Scoring System because it offers such flexibility.  The intelligence group can monitor and tune the Temporal Metrics, and the individual engineering groups can modify their Environmental Metrics.  I've also seen a two-stage approach used in some environments, where the intelligence group assesses an initial threat rating based on the potential Confidentiality/Integrity/Availability impact against a theoretical machine, and the probability of a successful impact based upon ease of exploit and level of reported exploitation in the wild.  Then the different areas within the firm, such as the DMZ, or the desktops, further evaluate the vulnerability.  It's important that the intelligence group have some feedback on these ratings to ensure that there is a consensus on the rating, and not simply a case of a single department lowering the threat-ratings to save some effort.

Every phase is critical-- Dissemination is no exception.  This is where the message is sent to your consumers.  The message will have to be tailored to your audience.  Upper management will have different concerns than your engineers, a one-size-fits-all report will likely result in disappointment.  This is where your goals come into play, take the guiding questions and use those to tailor your reports.

Which takes us back into Planning and Development; don't pass up the opportunity for feedback from your consumers.  Set benchmarks for your process' performance, and re-tune.  It's often very attractive to simply add more sources for collection, just remember that every new source is more work to be done when you do your sweep, so set criteria for purging your sources.  Revisit your intelligence goals, add new questions, and re-focus existing questions.  Some questions are going to be long-term strategic issues, others will have a more tactical focus and short lifetime, such as "Does Google Desktop present a threat to the firm?" or "Are we exposed to the Symantec Antivirus Vulnerability?"

Vulnerability Intelligence is a process, much like many other processes used to secure your environment.  Much like those processes, there are expensive solutions, and solutions available on-the-cheap.

--
Kevin Liston

kliston at isc dot sans dot org

0 Comments

Published: 2006-05-29

Symantec AV Vulnerability Latest

Symantec has updated their advisory (http://www.symantec.com/avcenter/security/Content/2006.05.25.html)

They confirm that the following versions are affected and patches are available:
Symantec Client Security-
   3.0 Builds 3.0.2.2010 and 3.0.2.2020
   3.1 Builds
3.1.0.394 and 3.1.0.400

Symantec Antivirus Corporate Edition-
   10.0 Builds
10.0.2.2010 and 10.0.2.2020
   10.1 Builds
10.1.0.394 and 10.1.0.400

Some have reported that the patching process is not trivial, and can be difficult to roll out in some environments.

At this time, there have been no reports of proof-of-concept-code or exploit code other than that held privately by eEye.

We have not received any reports of exploitation in the wild.

0 Comments

Published: 2006-05-27

Symantec Patch Posted

Symantec has just posted patches for the Security Advisory SYM06-010.  It appears at this time that the patches are manual download and install.  We don't know at this point if a product live update will be posted for these patches but for the meantime it is there for manual load. 

So for those of you enjoying the long weekend, look at what you get to look forward to on Tuesday. If you are running Symantec Corporate Edition 10.1 you get to spend Tuesday patching.

Symantec Patch Update

0 Comments

Published: 2006-05-27

Hacker Activity

It appears that there is a little hacker contest going on this weekend.  We have received reports of several sites being hacked by different groups. One of the web sites that posts counts of hacker activity shows several known hacker groups that are having lots of fun.

Now is it because of the long weekend or are the kiddies out of school for summer vacation and they are bored already.  Hard to tell, all we can do is keep our eyes open.  Hopefully all of our readers have taken the necessary steps to harden and protect their web pages and can sit back and enjoy the long weekend. If you haven't, you can sit back and enjoy the long weekend but come Tuesday morning you will be busy fixing the mess that the kiddies leave behind.

In case you want some information about how to harden and protect your webservers take a look at the information available in the SANS Reading Room.  We have some of the best and brightest contributors that give us some great ideas.

SANS Reading Room Web Servers

0 Comments

Published: 2006-05-27

Cisco Vulnerability in the VPN Client Software

The Cisco VPN Client for Windows software is affected by a local privilege escalation vulnerability that allows non-privileged users to gain administrative privileges. Cisco has made free software available to address the vulnerability.

Cisco Advisory - VPN Client

0 Comments

Published: 2006-05-27

Update on Symantec Elevation of Privilege Vulnerability

 It appears that Symantec has issued an update to the vulnerability that was identified yesterday.
It has been confirmed that the products affected are Symantec Client Security version 3.1 and Symantec Antivirus Corporate Edition version 10.1.  This is a stack overflow vulnerability and can cause a system crash. 

See the information on Symantec's Website for their recommendations for mitigation.

Symantec Advisory


0 Comments

Published: 2006-05-26

Sourcefire VRT MS-WORD 0DAY recommendations, Rules and tool Advisory

Ureleet reports that the Sourcefire VRT has an Advisory that contains MS-WORD 0DAY recommendations, Rules, and the "SOURCEFIRE MS-WORD 0DAY, checker v0.1 DocCheck tool download.

Thanks Ureleet!

0 Comments

Published: 2006-05-26

MS tool to help ensure that your application does not have administrator access as a dependency

From their site;

Microsoft Standard User Analyzer

Overview
The Standard User Analyzer helps developers and IT professionals diagnose issues that would prevent a program from running properly without administrator privileges. On Windows Vista, even administrators run most programs with standard user privileges by default, so it is important to ensure that your application does not have administrator access as a dependency.

Using the Standard User Analyzer to test your application can identify the following administrator dependencies and return the results in a graphical interface:

• File access
• Registry access
• INI files
• Token issues
• Security privileges
• Name space issues
• Other issues

Quick Details
File Name: SUAnalyzer.x86.msi
Version: 1.0
Date Published: 5/23/2006

Supported Operating Systems: Windows Server 2003; Windows Vista; Windows XP
Microsoft Application Verifier

0 Comments

Published: 2006-05-26

MailBag Response info about yhoo32-explr, IM malware

We had an inquiry requesting additional information about a SANS NewsBites story (SANS Computer Security Newsletters and Digests) about yhoo32-explr, IM malware. Following up on the NewsBites item for the ISC contributor lead to the following information that might be of interest.

In discussing the actions of yhoo32-explr, FaceTime Security Labs researcher Chris Boyd says (at the spywareguide.com blog) "That's not all - a file is placed on the PC which contacts a URL firing off continually modified commands for the infection. They can change the infection message and the method of infection on the fly. Tailor made messages designed for Yahoo IM, Internet-based chat and IRC? You got it. It even randomly overtypes some of your IM messages as you hit the send button.".

Source information at Facetime.com here.

NewsBites item here Worm Spreads Through Yahoo Messenger (22 May 2006)

0 Comments

Published: 2006-05-26

eEye Upcoming Advisory - both uses and abuses Symantec security applications

Some ISC participants have pointed us to an "Upcoming Advisory" posted at eEye that describes a remotely exploitable vulnerability in Symantec Antivirus 10.x and Symantec Client Security 3.x. Other ISC participants have pointed us to the new security website darkreading article where an eEye team member discusses issues, and the article also states that eEye "also tested Symantec's consumer security suite, Norton Internet Security 2006, which eEye uses, and found that it was not vulnerable."

Thanks folks!

Update - Symantec issued SYM06-010, Symantec AntiVirus Reported Vulnerability.

0 Comments

Published: 2006-05-26

Important RH kernel security advisory

Over at the NISCC they posted information about RHSA-2006:0493-6 Important: kernel security update.

The RH Advisory includes fixes for a number of issues in addition to the ones I copied next;

* a flaw in the SCTP-netfilter implementation that allowed a remote user to cause a denial of service (infinite loop) (CVE-2006-1527, important)

* a directory traversal vulnerability in smbfs that allowed a local user to escape chroot restrictions for an SMB-mounted filesystem via "..\\" sequences (CVE-2006-1864, moderate)

* a flaw in the ECNE chunk handling of SCTP that allowed a remote user to cause a denial of service (panic) (CVE-2006-2271, moderate)

* a flaw in the handling of COOKIE_ECHO and HEARTBEAT control chunks of SCTP that allowed a remote user to cause a denial of service (panic) (CVE-2006-2272, moderate)

* a flaw in the handling of DATA fragments of SCTP that allowed a remote user to cause a denial of service (infinite recursion and crash) (CVE-2006-2274, moderate)

0 Comments

Published: 2006-05-25

MS SMB zero-day?

Quite a few people have written in to give us a heads-up on
http://www.frsirt.com/english/advisories/2006/1976 ,
which references an email on the DailyDave list:
http://lists.immunitysec.com/pipermail/dailydave/2006-May/003226.html

At this time, it is unclear what, if anything, is the issue.
This may be as simple as the GREENAPPLE tool, which exploited
the vulnerability found in MS05-011, being released in next
month's CANVAS update. Or, this may be a new variant of the
same. Or, this might be something entirely different.
Or, this may be nothing at all.

Personally, I don't think there's anything to this other than
what the message on DailyDave says: "Sinan Eren wrote a
working version of GREENAPPLE,
a remote kernel overflow in SMB
for Windows 2000. It's available now to Immunity
Partners, but
it will be in the June Immunity CANVAS release, which

will be interesting."


0 Comments

Published: 2006-05-24

New PostgreSQL versions released (SQL injection issue with multi-byte encodings)

Would be a good idea to check any PostgreSQL installations (full, embedded, and drivers).

The following new versions are available:
7.3.15, 7.4.13, 8.0.8, 8.1.4

Updated drivers for ODBC, Ruby, Perl, .Net, and C++ will be released shortly.

I'll update the diary with info on any good tools to test installations for this issue.

References:
http://www.newsforge.com/article.pl?sid=06/05/23/2141246
http://www.postgresql.org/docs/techdocs.52
http://shiflett.org/archive/184

0 Comments

Published: 2006-05-24

Widespread Routing Outages

There appear to be widespread routing outages across several ISPs world wide. At this point we don't have any details. But several sites are not reachable. Cogent and Savvis appear to be harder hit then others, so if you are connecting to us via either NSP, you may not be able to see this diary :-(. The problems started about 5am EDT (9am UTC)

http://scoreboard.keynote.com/scoreboard/Main.aspx?Login=Y&Username=public&Password=public

BGP routing table delta shows some 'blip' which may indicate attempts to route past it.

http://www.cymru.com/BGP/deltapref.html

More details as we find out about them.

(Note: Cogent's website is cogentco.com, NOT cogent.com)

0 Comments

Published: 2006-05-23

Possible GNU Strings Denial Of Service Vulnerability

SecurityFocus has a vulnerability advisory about an issue with the GNU strings command and a potential Denial of Service attack.  If a file contains certain character strings, the string command will crash due to a failure to properly handle unexpected user-supplied input.

The bugzilla entry 2584 authored by Jesus Olmos Gonzales, who discovered the issue, contains more information. It indicates the the issue actually lies within the bfd_hack_lookup() routine in the BFD library.

The results of initial testing done by several ISC Handlers made it appear that this was only affecting some Linux/Unix distributions and not others.  Further testing indicated that the "exploit" seems sensitive to the content of the triggering file.

If the file contained only the following line:

        %253Cc%253Cc%253Cc%253Cc%253Cc%253Cc%253Cc

then running strings on the file would result in a segmentation fault.

If the file contained additional content, such as:

        This file will not crash
        %253Cc%253Cc%253Cc%253Cc%253Cc%253Cc%253Cc

then running strings on the file did not result in a segmentation fault.

The potential security impact of this is an attacker might be able to include this character sequence in their executable thereby making it harder to do binary analysis with the strings command.

To test if you system is vulnerable to this issue, you can run the following commands:

       echo "%253Cc%253Cc%253Cc%253Cc%253Cc%253Cc%253Cc" > evil-file
       strings evil-file

If you get a segmentation fault, you are vulnerable.

Results for some tested operating systems [1]:

        CentOS 4.3 - vulnerable
        Fedora Core 4 - vulnerable
        Mac OS X 10.4.5 - NOT vulnerable
        OpenBSD 3.5 - vulnerable
        OpenBSD 3.9 - vulnerable

       Cygwin - vulnerable

[1] - "vulnerable" meaning that the included version of the "strings" command will segment fault.

0 Comments

Published: 2006-05-23

Metasploit Framework 2.6 Released

Version 2.6 of the Metasploit Framework was released today.  The Metasploit Framework is an open-source penetration-testing / vuln-assessment tool, similar to the commercial tools CANVAS and CORE IMPACT.  The latest version now has 3 user interfaces, 143 exploits and 75 payloads.

If you already have an older version of the Framework installed (version 2.2 or newer), you can simply run "msfupdate" to update to the latest and greatest parts and pieces.

0 Comments

Published: 2006-05-23

Update on Word 0-Day Issue

Microsoft and eEye have each released advisories related to the issue this evening.

Microsoft's security advisory can be found here.

eEye's advisory can be found here.

The information about vulnerable exploits differs a little between the two advisories.

Microsoft says the vulnerability only affects Word 2002/XP and Word 2003 and that Word 2000 is not vulnerable. The Microsoft advisory contains information on workarounds including not using Word as the default mail editor in Outlook and running Word in 'Safe Mode' to disable the functionality that is affected by the vulnerability and exploit.

eEye says that the vulnerability affects Word 2000 as well.  The eEye advisory mentions that they believe there are two variants of this exploit.  Thus, it may be that the first variant only affects Word 2002/XP and 2003 and the second variant affects all three versions.

Update 25-May-2006:  eEye has removed Word 2000 from their list of vulnerable products.

0 Comments

Published: 2006-05-21

Invision Power Board Vulnerability

For those using the Invision Power Board product, there are a couple of flaws that were addressed recently.  Not sure how wide spread this product is used, but worth noting for those of you who use it.  More information on this can be found at http://forums.invisionpower.com/index.php?showtopic=215527 ,





0 Comments

Published: 2006-05-21

Solaris 9 in.ftpd security flaw

Good afternoon all,

In the midst of the Microsoft Word 0-day vulnerability (and the start of the summer vacation season), a few security issues managed to be overlooked by me this past week. 

Sun Microsystems released an advisory concerning a security flaw in the ftp daemon installed by default in Solaris 9.  This vulnerability may allow local or remote unprivileged users to access directories outside of their home directory or to log in with their $HOME directory set to the root directory of  "/" (slash) if certain options are in use.

Sun is working on an appropriate fix so keep an eye on your log files, or disable the ftp service under Solaris if it is not necessary. For more information, please see the Sunsolve document located at http://sunsolve.sun.com/search/document.do?assetkey=1-26-102356-1


---
Scott Fendley
Handler on Duty

0 Comments

Published: 2006-05-20

Microsoft Word Vulnerability

Most anti-virus vendors have already come out with signatures to detect the malware exploiting MS Word vulnerability. By now, I hope you have got all your AV signatures updated. Although relying on virus scanner is not totally full proof (especially on new variants), but it is better than none (remember defense-in-depth).

At your firewall and IDS, you may want to monitor outbound traffic going to these domains, as this may be an indication of compromised hosts:

3322.org
scfzf.xicp.net

If you are filtering Word attachment at your gateway, it should be based on Word file type and not just on file extension alone.

US CERT has released an security alert on Microsoft Word Vulnerability

Below are stories from ISC on this topic. We will update as we have more detailed information.

Word 0-day, recommended defenses

Targeted attack: Word exploit
- More AV vendor links have been added.

Targeted attack: experience from the trenches

(Update)
Miscrosoft has put up a new article on A quick check-in on the Word vulnerability (Thanks Juha-Matti). Part of the article is extracted below:

First off on the vulnerability itself: I want to reiterate we're hard at work on an update.  The attack vector here is Word documents attached to an email or otherwise delivered to a user's computer.  The user would have to open it first for anything to happen.  That information isn't meant to say the issue isn't serious, it's just meant to clearly denote the scope of the threat.

Now, we've received singular reports of attacks and have been working directly with the couple of customers thus far affected.  In analyzing the malware we've added detection to the Windows Live Safety Center, and we've passed all that information over to our antivirus partners.  But in breaking down the current malware we discovered some commonality to the current attack.  The attack we've seen is email based.  The emails tend to arrive in groups, they often have fake domains that are similar to real domains of the targets, but the targets are valid email addresses. 

Currently two of the subject lines we have seen are: 

Notice
RE Plan for final agreement

The attack we have seen so far requires admin rights, so limitations on user accounts can help here.  I want to repeat that customers who believe they are affected can contact Product Support Services.  You can contact Product Support Services in North America for help with security update issues or viruses at no charge using the PC Safety line (1866-PCSAFETY) and international customers by using any method found at this location:

http://support.microsoft.com/security.

So far, this is a *very* limited attack, and most of our antivirus partners are rating this as "low".  But we're working to investigate any variants we might see to make sure detection is out there, as well as working on the update to address the vulnerability.


0 Comments

Published: 2006-05-19

Word 0-day, recommended defenses.

The diary about the targeted attacks using a zero-day exploit against Word triggered a lot of questions about how to defend against such an attack. We understand that many organizations can not do without Word documents, so here a few ideas on how to defend against these attacks.

Note that this is not a temporary situation that will blow over soon. Microsoft will release a patch against this problem in June, but even after that there are likely to be other attacks using other exploits. So let's think a bit beyond the next couple of days on how to defend your network.

  • User education is of course key, but likely insufficient. Attacks like that will use very plausible messages. Create some examples to re-emphasize this fact. "What if you receive a message from a customer you know, referencing a project you are working on, that includes a Word document". Teach users to double check out of band. "Do not open the document before calling the customer".
  • Do not trust Antivirus alone. Defending against 0-day is all about defense in depth. Antivirus is likely going to fail you for an exploit like that. Consider a system that quarantines attachments for at least 6-12 hours to allow anti virus signatures to catch up. This may not be acceptable for a lot of organizations, but in particular right now, with a known exploit, it may be a reasonable step.
  • Limit users' privileges. The particular sample we received will not run as a non-administrator user. It will be MUCH easier to clean up after an exploit like that if the user had no administrator rights.
  • Monitor outbound traffic. Your IDS and your firewall are as valuable to protect your network from malicious traffic entering as they are in protecting you against your corporate secrets leaving your network. Consider deploying "honey tokens", files with interesting names that contain a particular signature your IDS will detect.
  • Block outbound traffic. Try to limit sites accessible to users and use techniques like proxy servers to isolate your clients further. Proxy filter logs will also work great as an IDS to detect suspect traffic.
  • Limit data on desktops. Try to teach users to limit data they store "in reach". This is a difficult balance. But a file on a remote system, which would require additional authentication, will likely not be accessible by a bot as in this case. Locally encrypted files will work too (as long as they stay encrypted until used). Encrypted file systems will not help as they will be accessible to the user opening the word document.
Again. None of these techniques are perfect. Each one can be circumvented. But the more layers you can wrap your users in the better. Think what will work well in your organization. Personal firewalls on desktop? Traffic control with flowtools or ntop? What are the tools you already have that can be used for this purpose.

There are also some rather more radical "solutions" possible if you absolutely need to be sure that you can continue working independently of this 0-day (and the inevitable variants to follow soon):
  • consider additional filtering, for example using software which converts Word DOC format to something which cannot carry the virus, e.g. RTF.  Consider using the free wvWare library. You will lose formatting but that might be an acceptable bargain for e-mail incoming from outside your organisation.
  • consider the possibility of disabling Word and replacing it with OpenOffice until Microsoft releases patches.
Contributors: Johannes, Marc, Arrigo.

Update:

Another option might be to use the Microsoft Office viewer applications instead as your default, such as Word Viewer.  You can get more information about and download the viewer programs from Microsoft. The Word Viewer application is not vulnerable to this specific exploit.

0 Comments

Published: 2006-05-19

Targeted attack: Word exploit - Update

In yesterday's diary, Swa reported on a targeted attack that appears to use a previously undiscovered Microsoft Word exploit.

What we know so far is that when the exploit is launched, early on in the process, it drops a bot, possibly Rbot or some variant.

Once the bot is in place, it begins an extensive recon of the system; installed patches, installed AV, contents of My Documents, startup file contents, IE config ..

Thanks again to Michael for reporting the incident to us and all the handlers who have helped in the ongoing analysis.

Vendor information:

McAfee

McAfee detects the Word document with the 4766 definition file as Exploit-OleData.gen and also associates Backdoor-CKB!cfaae1eg with this exploit. (Thanks James!)
File size: 233472 bytes
MD5: c1bb026ec2b42adc17d0efb7bb31f4dc
SHA1: 02b9a9530e0f4edb3bc512707c16390ea5b394d1

Symantec

Thanks to juha-matti for finding a few more references:

F-secure

This one from an anonymous reader

Microsoft

From the Microsoft Security Response Center we understood that they are developing a patch and expect it to be for inclusion in the next 2nd tuesday update. Their full recommendation:

Microsoft is investigating new public reports of a "zero-day" attack using a vulnerability in Microsoft Word XP and Microsoft Word 2003. In order for this attack to be carried out, a user most first open a malicious Word document attached to an e-mail or otherwise provided to them by an attacker.  Microsoft will continue to investigate the public reports to help provide additional guidance for customers as necessary.

As a best practice, users should always exercise extreme caution when opening unsolicited attachments from both known and unknown sources. Microsoft is adding detection to the Windows Live Safety Center today for up-to-date removal of malicious software that attempts to exploit this vulnerability.  The Windows Live Safety Center is located at the following website: http://safety.live.com [NOTE: link might not work for gecko based browsers such as FireFox]

Microsoft is completing development of a security update for Microsoft Word that addresses this vulnerability.  The security update is now being finalized through testing to ensure quality and application compatibility and is on schedule to be released as part of the June security updates on June 13, 2006, or sooner as warranted.

Customers who believe they are affected can contact Product Support Services.  Contact Product Support Services in North America for help with security update issues or viruses at no charge using the PC Safety line (1866-PCSAFETY) and international customers by using any method found at this location: http://www.microsoft.com/security.

As always, Microsoft encourages customers to follow its "Protect Your PC" guidance of enabling a firewall, applying all security updates and installing anti-virus software. Customers can learn more about these steps at http://www.microsoft.com/protect.

Trendmicro

Ivan from Trendmicro sent us where their updates can be found. Thanks Ivan!

Trojanized Word document files:

Dropped malcodes:

0 Comments

Published: 2006-05-18

Targeted attack: experience from the trenches

Learning lessons from incidents is a very important part of incident handling. Yet with targeted attacks it is very hard as you need to have a case before you can learn. So learning from others is even more important in this case.

Michael reported on an unnamed organization being hit by a limited, targeted attack.

Detection is mostly the very hard part in these attacks. This case seems to have been detected by a very alert user detecting a domainname that wasn't completely right.

That user detected an email coming in that came from a domain that looked like their own, but wasn't their own (actually only had an MX record in it. The email was written as to look like an internal email, including signature. It was addressed by name to the intended victim and not detected by the anti-virus software.
 
To say it in Michael's words:

"Emails were sent to specific individuals within the organization that contained a Microsoft Word attachment. This attachment, when opened, exploited a previously-unknown vulnerability in Microsoft Word (verified against a fully-patched system).  The exploit functioned as a dropper, extracting a trojan byte-for-byte from the host file when executed.  After extracting and launching the trojan, the exploit then overwrote the original Word document with a "clean" (not infected) copy from payload in the original infected document.  As a result of the exploit, Word crashes, informs the user of a problem, and offers to attempt to re-open the file.  If the user agrees, the new "clean" file is opened without incident." They are working with Microsoft on this.

"We are still analyzing the trojan dropped by the exploit.  What we do know is that it communicates back to localhosts[dot]3322[dot]org via HTTP.  It is proxy-aware, and "pings" this server using HTTP POSTs of 0 bytes (no data actually POSTed) with a periodicity of approximately one minute.  It has rootkit-like functionality, hiding binary files associated with the exploit (all files on the system named winguis.dll will not be shown in Explorer, etc.), and invokes itself automatically by including the trojan binary in "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows".  Note that, as of this morning, no anti-virus signatures detected this file as problematic according to virustotal.com.

We have traced nearly this attack to the far east; specifically, China and Taiwan.  IP's seen are registered there, domains seen are registered there, and the emails received originated from a server in that region.  The attackers appear to be aware that they have been "outed", and have been routinely changing the IP address associated with the URL above.

Due to the aggravating circumstances (0-day, no AV detection), we wanted to make sure the community is aware that this problem exists as soon as possible."

We're having a look at the word document ourselves. So far we found it has aparently embedded excel and powerpoint components and we found a string in Chinese that translates to: "report test file structure information write into stack"

Many thanks to all handlers active on this: Johannes, Chris, William, Adrien.

--
Swa Frantzen - Section 66

0 Comments

Published: 2006-05-18

FireFox DoS exploit public

An exploit is being made publicly available that creates a DoS situation in up to date FireFox versions.

Now as far as exploits that require javascript to be enabled go, I can't help but feel that a DoS is somewhat lame... If the attacker can already execute scripts, how much worse is getting the cpu load up to 100% ? Moreover the user will soon enough figure it out.

Your best option to mitigate this is to install something like NoScript.

--
Swa Frantzen -- Section66


0 Comments

Published: 2006-05-18

Swiss security day

We all know Swiss neutrality, army knifes, cheese, banks, but even inhabitants of Switserland might be surprised that today was the Swiss Security Day. If you speak French, German or Italian, check out http://www.swisssecurityday.ch/.

Some intersting stuff I found was (all my very liberal translation)

  • Security4kids:
    • Targeting kids in groups aged 7-10 and 11-15.
  • A short list of 5 action points for home users:
    • Make backups
    • Get anti-virus protection
    • Use a firewall
    • Keep software up to date
    • Adopt the right attitude
  • A list of 10 action points aiming at small and medium sized enterprises:
    • Get security responsabilites in writing
    • Make backups
    • Anti-virus protection
    • Firewall
    • Keep software up to date
    • Strong passwords
    • Protection of mobile devices
    • Create guidelines for IT usage
    • Create a physical perimeter
    • Classify data
  • They have a 44 page document addressing teachers and parents. It explains security wonderfully (SchoolNetGuide [FR] [DE] [IT]). This document says some things that are just not true in e.g. the US: All banks use 2 factor authentication using either a printed page of one time passwords or either a hardware token.

I'm sure other countries have similar days, but I was most impressed by their schoolnetguide, a pity it's not available in English.

--
Swa Frantzen -- Section 66

0 Comments

Published: 2006-05-18

Phishers use urlencoding to obfuscate hostnames

Update: Well, things are a bit more complex. Looks like RFC3986 actually endorses the use of URL encoded host names. Earlier RFCs (see references in RFC3986) did not.

One of our handlers (Bojan) found a hostname like this in his DNS cache:
www.paypal.com%20cgi-bin%20...(more )...example.com

This method appears to be used for a while, but I guess we missed it among all the phishing going on these days. Upon further investigation, we found that some browsers allow URL encoded host names. The impact is similar to the old (no longer working) method of using the "username:password@url" notation. So the impact is not "huge", but its yet another trick in the phishing arsenal.

Theoretically, a host name should only contain letters A-Z, numbers 0-9 and dashes (-). In order to support foreign character sets, "IDN" is used with uses that same set of characters to encode. For domain names, this is enforced by the registrars, but host names for existing domains are up to the user, and DNS servers typically allow "anything" (after all, DNS can be used for other things then host names).

We found that Internet Explorer, Safari and to some extend Opera will accept URL encoded host names and redirect to the "decoded" version. Further, they will allow spaces as part of host names. This is used by phishers to obfuscate URLs.

Explorer and Opera will accept the URL encoded host name, and redirect to it. But once you arrive at the page, the URL bar will show the URL in clear text.

Safari does accept URL encoded host names as well, but will NOT decode it as you arrive at the destination page.

Firefox refuses to use URL encoded host names.

Simple sample to test (not clickable, copy&paste):

http://www.paypal.com%20cgi-bin%20webscr%64%73%68%69%65%6c%64.%63%6f%6d

or try a host name with space vs. without (less of an issue as you would have to control DNS for the domain to use it)

http://www .securewebbank.com   (vs. http://www.securewebbank.com )

URL encoding is only supposed to be used after the host name to encode the file name and the GET parameters.

Suggested defenses:
  • Inform users about this problem.
  • Audit DNS caches to see if users asked to resolve such a host name.
  • Audit proxy logs for such domains, and filter if possible.

0 Comments

Published: 2006-05-18

RealVNC exploits in the wild

Active use of RealVNC to break into systems is being reported anonymously.

If you can share more details or just can report attempts, please let us know.

If you have any RealVNC exposed, check if you are hacked, and if not take measures immediately. If you want an inherently more secure solution check how to run vnc over ssh on your specific platform.

See more of the vulnerability in the May 15th diary by Kyle Haugsness.

--
Swa Frantzen -- Section 66

0 Comments

Published: 2006-05-18

UPnP Problems

Many home routers / firewall appliances support UPnP. UPnP is intended to allow hosts on the network to auto-configure the router. For example, some network cameras will configure the router automatically to allow access to the camera from the outside. Typcially, the camera will send UPnP messages to find the router and then request it to open a port and redirect all traffic on that port to the camera's build in web server.

Standard hardening guides will recommend to turn off UPnP.

A recent post on Securityview.org outlines that even though a security model was defined for UPnP, it is not used. Any workstation on the local network will be able to configure the UPnP capable device "at will". Even worse: Port mapping does not check if you actually redirect a port to an internal host in some cases.

Short lesson: If you haven't yet, turn off UPnP. If you need UPnP, make sure you got the latest firmware as it may eliminate some of the worst issues (e.g. rerouting to an external host). You should at least log UPnP messages with an IDS (e.g. snort, or even tcpdump will do fine). The nice thing is that the UPnP messages are pretty easily readable.

Thanks to John Herron for pointing us to the Securityview site.

0 Comments

Published: 2006-05-18

IBM websphere: Last Call

IBM's WebSphere versions 4.0 and 5.0 contain a certificate that will expire in a few hours. The exact time of expiration is 18 May 2006 at 21:59:19 GMT.  So you have little time left if you need still to act on it.

For more detailed information check out the IBM support page.

This actually is a consistent problem with many solutions that use certificates: They expire, for good reason, but it makes you vulnerable should the vendor decide not to support you with a new cert or go somehow belly up. (IBM seems to be doing the right thing so far). Trying to get an escrow on it might prove to be very hard.

A good way to deal with this is to create and maintain an inventory of when what cvertificate expires. That way you can plan against these dates.

--
Swa Frantzen -- Section 66

0 Comments

Published: 2006-05-17

Do we Know our enemy?

Do We know our enemy?

I am sure that most of you already know the excellent paper series Know your Enemy , by the Honeynet Project. This serie of papers are usually "dedicated to describing the concepts and technology of the Honeynet Project and Research  Alliance and sharing the lessons we have learned." So, just to be as clear as possible, if you are
not trying to understand how the bad guys are moving, you are a step behind...because they are doing
this to us for a long time...:)

Yesterday I was checking a large bot source code repository, and found a section called papers...inside this directory I could find a paper called 'Know Your Enemy - Tracking Botnets', the paper from the 'Know your enemy series' that is dedicated to study the botnets, their tools and actions.
Doesn't it make sense?? :)

It is always the cat and mouse game, we get their tools, study them and get intelligence to fight against...in their case they are doing exaclty the same, learning how are we detecting them and trying to bypass the controls.

So, keep always in mind that they are watching us...what about you? Are you watching them as you should?

---------------------------------------------------------
Pedro Bueno ( pbueno //&&// isc. sans. org )

0 Comments

Published: 2006-05-16

Nagios vulnerability

There was a Nagios vulnerability fixed today (versions 1.x and 2.x).  Looks like code execution is possible.  http://www.nagios.org/development/changelog.php

0 Comments

Published: 2006-05-15

RealVNC Exploits

Given the details of the RealVNC vulnerability that were disclosed this morning (May 15) on Full Disclosure, exploits are now being released.  This note is to alert our readers that the exploit is trivial and very effective.  (In fact, you can modify a VNC client to exploit the vulnerability with very little code changes -- around 1 line.)

Administrators should be scanning their networks for open VNC servers (typically on TCP port 5900).  You want to upgrade any VNC servers that give you protocol above 3.3.  You can use the service detection in nmap to get the protocol number. 

We can't confirm that VNC servers from other projects like TightVNC or UltraVNC are vulnerable - I don't think they are vulnerable.  At this time, it only appears that RealVNC servers are vulnerable.  Unfortunately, there doesn't seem to determine which software the remote end is running.  You only get to see the protocol number.

Unless you like to have unauthorized folks moving your mouse around the screen, you are strongly urged to upgrade to the latest RealVNC release.  Also, you should consider binding the VNC daemon to 127.0.0.1 and tunnelling the VNC traffic through an SSH tunnel, which will provide you with stronger authentication mechanisms.  Google "vnc over ssh" for more detailed instructions on how to accomplish this on your platform of choice.

0 Comments

Published: 2006-05-15

Path-conversion weakness in major AV products reported

Juha-Matti Laurio was kind enough to put together this excellent summary of a potentially sticky vulnerability:

Reportedly "there is a design flaw in the way that NTDLL performs path conversion between DOS style path names and NT syle path names. Although many attack vectors are possible, in this paper [see later] some proof of concept cases are covered". "This issue occurs because the operating system uses multiple differing algorithms to resolve file paths. Attackers may exploit this issue to bypass security software such as antivirus and antispyware products. Other attacks may also be possible.", continues Symantec.

List about the affected products is located at
http://www.securityfocus.com/bid/17934/info

Some examples about products listed:
Norton AV, Kaspersky AV, AVG AV, Norman AV, Ad-Aware, Spybot Search&Destroy and all Windows versions from NT4.0SP1 to Windows Server 2003 SP1.

A sample .bat file demonstrating this issue was also published at
http://www.securityfocus.com/data/vulnerabilities/exploits/17934 . bat
Note: I deliberately broke this link so that this story will make it through subscribers' mail filters. Remove those spaces around the dot if you wish to retrieve this. - gb

It appears that this issue is based to the following Bugtraq posting:
http://www.securityfocus.com/archive/1/433583
More details at this 48Bits.com PDF document:
http://www.48bits.com/advisories/rtldospath.pdf

- Juha-Matti

We at the ISC have verified this behavior and strongly advise that all Windows users exercise "safe surfing" habits such as verifying attachments before opening, not executing programs unless obtained from a trusted source, etc. Also, you can hasten the update process by staying on top of your A/V vendors support group. A partial list of vulnerable products is contained in the advisory.

0 Comments

Published: 2006-05-14

CLICKbot

With pay per click programs such as Google Adsense, there is another way to earn money from advertisers by building a scam where the money flows like this:

  • The advertisers pay Google for clicks in the hope to sell something.
  • Google has a bunch of publishers that own a website and run banners for them. Google pays (a high percentage) of the revenue to the publisher.
  • Some of these publishers aren't honest, but Google (tries to) detects fraudulous clicks and suspends them, so they need to hide the additional clicks better.
  • Somebody with a botnet generates the clicks from a few hundred machines and makes sure they look as innocent as possible. Keeps it a low profile while at it. Of course the botnet owner will want a share from the publisher.

Bottom line is that the advertiser pays in exchange for a bot visiting him.

It seems some bot operator left a website with both the bot's *.exe and the web based control panels wide open. An anonymous source sent us the URL.

While some of the *.exe's were detected pretty well, this one stood out [Virustotal results]:

AntiVir 6.34.1.27/20060514          found [TR/Drop.Small.ann.1]
Avast 4.6.695.0/20060512        found nothing
AVG 386/20060512     found nothing
BitDefender 7.2/20060514    found nothing
CAT-QuickHeal 8.00/20060512   found [(Suspicious) - DNAScan]
ClamAV devel-20060426/20060512 found nothing
DrWeb 4.33/20060514   found [Adware.IEHelper]
eTrust-InoculateIT 23.72.7/20060512 found nothing
eTrust-Vet 12.4.2207/20060512       found nothing
Ewido 3.5/20060513    found [Hijacker.BHO.d]
Fortinet 2.76.0.0/20060514        found [suspicious]
F-Prot 3.16c/20060512  found nothing
Ikarus 0.2.65.0/20060512        found nothing
Kaspersky 4.0.2.24/20060514        found [Trojan-Dropper.Win32.Small.ann]
McAfee 4761/20060512   found nothing
Microsoft 1.1372/20060513 found nothing
NOD32v2 1.1536/20060513 found nothing
Norman 5.90.17/20060512          found nothing
Panda 9.0.0.4/20060513           found [Suspicious file]
Sophos 4.05.0/20060513 found nothing
Symantec 8.0/20060514    found nothing
TheHacker 5.9.7.142/20060512       found nothing
UNA 1.83/20060512    found nothing
VBA32 3.11.0/20060513 found nothing

It is interesting to note that the botnet was 115 bots in size at the early time of the day I was looking at it and most were under 15 clicks each.

It's been reported to Google in order to make sure nobody gets paid.

--
Swa Frantzen - Section 66

0 Comments

Published: 2006-05-12

Apple OSX Patches, 2006-003

Yesterday, apple released a new set of security patches for OS X. Note that some of them fix arbitrary code execution problems in Safari and Mail.

All Apple wants you to know about the patches can be found here:
http://docs.info.apple.com/article.html?artnum=303737

Our testing hasn't shown any problems so far. Please report any issues you might have. The list of patches is long, and they can only be applied as a set, so we will skip a discussion of individual issues.




0 Comments

Published: 2006-05-12

RealVNC 4.1.1 authentication bypass vulnerability reported

The handlers have been discussing and investigating reports forwarded by many of our readers regarding the disclosure of an authentication bypass specifically affecting version 4.1.1 of the RealVNC product.  Because we have been unable confirm the vulnerability we had chosen to hold back on posting on this specifically to avoid spreading FUD (Which I personally seem to have an unfortunate penchant for doing).  Considering the fact that we are receiving the kind and welcome forwarding of this disclosure from so many avid readers and the inherent risk that this may pose due to the perceived considerable deployment base of VNC products it would be reasonable to think that many installations are exposed, unprotected and potentially vulnerable on the public internet.  We've chosen to post this here for awareness and to enable a larger audience to evaluate their own risk levels associated with this issue.

We have reached out to the disclosure point of contact at IntelliAdmin and are awaiting a response so that we can independantly confirm this vulnerabiltiy with them directly and remove the concern of this being primarily hearsay.  The IntelliAdmin website boasts a PoC to test whether your installation is vulnerable, but is conveniently unavailable due to the statement that the Slashdotting of the site was overloading the test.

The RealVNC website at http://www.realvnc.com does not yet acknowledge this vulnerability, and with version 4.1.1 being the current release, I personally offer up employing either network ACL's to prevent arbitrary access from the internet or configuring the application level ACL's to allow only specific endpoints to connect to your VNC services.

Beyond that, Keep in mind, this is reported to be a remote access authentication bypass and not to be confused with buffer overflow, associated with direct OS privileged access.  I would hope that the successful result of someone successfully abusing this flaw would result only in the remote viewing of the MS Gina login prompt.  An attacker would still have to brute force authentication credentials.  After all, your VNC instances are configured to automatically lock the screen after disconnect and allow only a single user to be connected, am I right?

The disclosure is covered in a blog available at the following URL:
http://www.intelliadmin.com/blog/2006/05/vnc-flaw-proof-of-concept.html

We'll keep you posted as this develops.

William Salusky
Handler on Duty!

0 Comments

Published: 2006-05-12

Incident Response and Malware investigations via SecCheck

Before pausing from reading email for a few hours, I'd like to take a moment to redirect your attention to a little advertised and even more infrequently used Incident Response and investigative feature hosted here on the ISC SANS portal. That feature is SecCheck, developed by MyNetWatchman, and offered to the Storm Center to assist in investigating suspicious and potentially malicious activity on hosts running the Windows family of operating systems.

The Storm Center deployment of SecCheck is hosted at http://isc.sans.org/seccheck/ and does require the use of Internet Explorer.  IE is required for this execution as our deployment is implemented in the form of an ActiveX DLL that executes in the context of your browser to analyze and deliver IR run-time reporting for the currently running workstation session.  Execution of the tool will result in the report being displayed on your workstation as well as being posted back to the Storm Center host for our review, and enables the handlers to assist you more directly.

Among the run-time details that are reported include:
  • running process list  (why am I running something called caseyvideo.exe?)       
  • running service enumeration (hmmm, that service executing from c:\winnt\lssass.exe looks interesting)
  • network connection snapshot (identify both services and established connectivity mapped to processes)
  • autostart registry hive dumps (malware has to restart itself somehow, this will show you where)
  • Installed BHO listing (Often Spyware and Hijackers jump right out)
  • Module dump (You can identify library injection techniques here)
SecCheck reporting does present much information that may take a little getting used to, but we're here to help!  Give it a try, especially if you are experiencing unusual and inexplicable computer activity.

There are additional developments available at http://www.mynetwatchman.com including standalone SecCheck binaries that offer additional features.

William Salusky
Handler on Duty!
 

0 Comments

Published: 2006-05-12

Quicktime upgrade time

Apple released a Quicktime upgrade to version 7.1 that fixes a number of vulnerabilities in the Quicktime viewer.

Normally I'd like suggest to read the release notes for details, but they are typically thin in explaining what's been fixed and/or otherwise changed.

Basically viewing crafted images:
and movies:
can lead to arbitrary code execution.

The fixed version is available for both OS X and Windows. The best about it all is that at least we don't get the implicit insults we should only visit trusted websites.

Without more information the only option is not to use quicktime or upgrade.

--
Swa Frantzen - Section 66

0 Comments

Published: 2006-05-12

Different strokes for different folks, spyware and browsers

One of our readers, Chris, sent us a URL to an interesting site. The site in question tries to install some spyware on the users' machine. This in itself is not interesting, but some "more advanced" features that we've seen deployed on this site are.

The site creators first setup a wildcard DNS entry for their domain, so anything prefixed to their domain name will go to their web server. They needed to do this so they can try to poison Google rates and enhance their page rankings when users are searching for potential keywords. In Chris' case, he was looking for information about one higher education institution (the attack is not limited to higher education institutions; we've seen a lot of other "poison" attempts from this group).

Now they have the basis for their attacks and we come to the interesting part. As a security researcher, you should always be careful when accessing unknown URLs (if you want to try it with a browser, probably the best way is to use one in a virtual machine). So, we decided to use wget to download the initial index.html web page, to see what's inside. Surprisingly, wget didn't manage to download anything:

$ wget http://[REMOVED].ascii. zstopers.com
--10:56:29--  http://[REMOVED].ascii. zstopers.com/
           => `index.html'
Resolving [REMOVED].ascii. zstopers.com... 66.246.246.215
Connecting to [REMOVED].ascii. zstopers.com|66.246.246.215|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
10:56:30 ERROR 403: Forbidden.

Hmm, forbidden. Ok, that goes with what Chris told us in his e-mail that the site seems to be down now. Being curious as we are (otherwise you won't be reading this diary) we decided to try the same site with Internet Explorer (in a virtual machine, of course).

What we got: (I've removed the domain prefix, which showed higher education institution, but the spyware domain is still visible there):



Notice the ActiveX control up there? That's what they want you to install. The popup will be shown until the user decides to install the ActiveX control. Keep in mind that other Internet Explorer versions will actually show a window asking the user to install the ActiveX component.

So, why didn't our wget work? Let's try with Mozilla:



Interesting! They detect what kind of browser is running, probably by parsing the User Agent field.
So, let's try to download the web page (just the index.html) file with wget, but this time faking the User Agent field, so the remote site will think that we are actually using Internet Explorer. If you're wondering what the User Agent field should look like, the easiest way is to check web server logs on one of the servers you have access to. Below we used Internet Explorer's User Agent field.

$ wget -U "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" http://[REMOVED].ascii. zstopers.com/

--11:04:52--  http://[REMOVED]. zstopers.com/
           => `index.html'
Resolving [REMOVED].ascii. zstopers.com... 66.246.246.215
Connecting to [REMOVED].ascii. zstopers.com|66.246.246.215|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]

    [                                                                                                                        ] 18,416        42.02K/s

11:04:53 (41.87 KB/s) - `index.html' saved [18416]

Aha! So they do use the User Agent field to detect what browser you are running and then send you to different web pages depending on it.
Further investigation of the index.html web page showed that it calls a JavaScript which then tries to install the WinAntiSpyware2006FreeInstall.cab, a well known spyware application, which some anti-virus vendors even detect as Trojans.

Those guys are definitely getting better and are actively adding new features to their malware. Remember the -U option for wget, it is very handy in cases like this.

0 Comments

Published: 2006-05-11

Firefox 1.5.0.3 Vulnerability Update

Ronald sent us a PoC DoS exploit, which uses the recently discussed Firefox 1.5.0.3 image issue.
His prove of concept exploit will use javascript to generate image tags with 'mailto:' link, which in turn will open the mail application automatically without any user interaction. As a result, many mail windows (e.g. Outlook) will be opened and the system will become unresponsive.

One possible workaround is to turn off automatic startup of your e-mai application in Firefox. To do so, enter in the URL bar: about:config . This will show a long list of configuration options. Search for 'warn-external.mailto' (e.g. use the 'Filter' option). By default, this value should be set to "false". Click on the line to toggle it to "true" (it will be bold if it is not set to the default).

Now, whenever you click on a mailto: link, you will first be asked if you would like to start your e-mail application. In the case of the exploit this will keep your system responsive, even though you may still have to click on all the dialogs.

Disabling javascript is another option, or disabling mailto: link all together. But these options are more intrusive.

For more details and a link to a PoC, see securityview.org

0 Comments

Published: 2006-05-10

Critical vulnerability in Sophos Anti-Virus products

A critical, remotely exploitable vulnerability, has been identified in various Sophos Anti-Virus products. The list of products affected is pretty big and covers everything from desktop Anti-Virus scanners over PureMessage to MailMonitor for SMTP and Exchange.

The vulnerability can be exploited by crafting a special CAB (Microsoft Cabinet) file with invalid folder count values in the header. This can result in corruption of heap memory which can further lead to execution of arbitrary code on the target machine.

This obviously requires that the inspection of CAB files is enabled, which will surely be the case at least on e-mail gateways (so a special warning for users of PureMessage and MailMonitor packages).

Sophos' advisory and details about updates are available at http://www.sophos.com/support/knowledgebase/article/4934.html.

0 Comments

Published: 2006-05-09

It's that time again!

Today is the day when Microsoft and many other vendors release their patches.  Here is a break down of Microsoft's patches and other information that hopefully will help you out.  It is a true team effort here at the ISC and I want to thank all the handlers for their help!  Good luck and happy patching (testing too of course!).

0 Comments

Published: 2006-05-09

Vulnerabilities in Macromedia Flash Player from Adobe Could Allow Remote Code Execution (913433)

MS06-020, CVE-2006-0024, CVE-2005-2628

Macromedia Flash Player Remote Code Execution
KB913433
http://support.microsoft.com/kb/913433

Adobe Security Bulletin ASPB06-03
http://www.adobe.com/devnet/security/security_zone/apsb06-03.html

Adobe Security Bulletin MPSB05-07
http://www.adobe.com/devnet/security/security_zone/mpsb05-07.html

CVE-2006-0024 and CVE-2005-2628

This bulletin addresses flaws in older versions of Adobe's flash player.
Both have been fixed for a while by Adobe. In case you haven't yet, this
is your last chance to update the Adobe Flash player.

MS06-020 patched this vulnerability as well. However, it only patched
Flash Player 7 (or 8). If a user had initially Flashplayer 6 installed,
MS06-020 was not applied. As a result, a user may have installed 7 or 8
later, and ended up vulnerable as a result. See the KB article above for
details (http://support.microsoft.com/kb/913433)

The "safe" version is 8.0.24.0 (this is currently the most recent version).

The vulnerability is exploited by viewing a crafted Flash animation.
Such an animation could be delivered via a web page, and e-mail message
or other means (P2P, Instant Messenger). If exploited, any arbitrary
command could be executed using the same privileges of the user viewing
the file.

This patch should be applied fast on all desktops. You may be able to
wait a bit on servers, or you could just uninstall the flash player on
servers (if you never use them to browse).

(Thanks Johannes for the write-up!)

0 Comments

Published: 2006-05-09

Vulnerability in Microsoft Exchange Could Allow Remote Code Execution (916803)

MS06-019, CVE-2006-0027

Exchange admins you will have your hands full, especially if you are running your own RIM/Blackberry Enterprise Server.  Please read the earlier entry by Johannes for details on the "gotcha" there.  This vulnerability allows for remote code execution and is critical that it be patched.  Here are the details as reported by Microsoft:

Maximum Severity Rating: Critical

Affected software:
  • Microsoft Exchange Server 2000 with the Exchange 2000 Post-Service Pack 3 Update Rollup of August 2004(870540)
  • Microsoft Exchange Server 2003 Service Pack 1
  • Microsoft Exchange Server 2003 Service Pack 2
Work Arounds:
Micosoft recommends two work arounds for this vulnerability.  Keep in mind that these work arounds can break other required functionality and cause you lots of pain.  Patching is the recommended solution.

1.  Require authentication for connections to a server that is running Microsoft Exchange Server for all client and message transport protocols.

2.  Block iCal/vCal on Microsoft Exchange Server to help protect against attempts to exploit this vulnerability through SMTP e-mail.

Vulnerability Details:
EXCDO and CDOEX functionality provided with Exchange server does not properly process certain iCAL and vCAL properties provided in email messages.  Collaboration Data Objects for Exchange (CDOEX) and Exchange Collaboration Data Objects (EXCDO) are interfaces that allow for certain types of information to be processed in the Exchange store. Virtual Calendar (vCAL)  and Internet Calendar (iCAL) is a MIME content type used by Microsoft Exchange Server and email clients when sending and exchanging information related to calendars and scheduling.

In short, when the exchanger server receives a message that contains specially crafted properties for vCAL and iCAL, it allows for execution of code on the exchange server.





0 Comments

Published: 2006-05-09

Vulnerability in Microsoft Distributed Transaction Coordinator Could Allow Denial of Service (913580)

MS06-018, CVE-2006-0034, CVE-2006-1184

This update patches two vulnerabilities in MSDTC
(CVE-2006-0034,CVE-2006-1184).
Both represent a denial of service in MSDTC which can be exploited locally
or remotely with malformed messages.

This vulnerability is listed as moderate for Windows 2000 versus Low for
XP and 2003 because MSDTC is enabled by default on that platform. The
severity is the same on the other platforms when the service is running.

There are three categories of mitigation available, but it is recommended
the patch be applied if possible. #1. The service can be disabled, but
this can affect a number of applications such as SQL Server, Exchange,
BizTalk, etc. #2 Network access for DTC can be disabled. This can also
affect services. Also its important to note that the vulnerability could
still be exploited locally. #3 Block network traffic with a firewall (host
or network). Traffic on ports greater than 1024 would need to be blocked
as well as any other configured RPC port.

Also note that this bulletin replaces MS05-051 on Windows 2000.

From Symantec:
"Although corrected in MS05-051, additional memory added in the allocater
for memory accounting was not accounted for. These additional 8 bytes can
be overwritten.These issues will kill the process and DoS the service."
(CVE-2006-1184)

(Thanks Robert for the write-up)



0 Comments

Published: 2006-05-09

Microsoft Patch Tuesday: Expected Exchange patch problems.

As announced by Microsoft last week, today's patches will include a patch for Microsoft Exchange. RIM (Research in Motion / Blackberry) announced that todays patch will break some functionality required by its Enterprise Server. Other third party products may be affected as well.

"this update affects user mailbox permissions by revoking the 'Send As' permission in Exchange which has an impact on third party products such as BlackBerry Enterprise Server for Microsoft Exchange. Once applied, this update will prevent users on BlackBerry Enterprise Server from sending email from a BlackBerry or BlackBerry-enabled device, however users will still receive emails on their BlackBerry device. This is due to the BlackBerry service sending emails on behalf of a user when a message is sent via the BlackBerry device."

For a workaround, see: http://support.microsoft.com/kb/912918.

Thanks to Colin and Chris for letting us know.

0 Comments

Published: 2006-05-08

Monthly Threat Update Webcast

Wednesday, from 1-2pm EDT, we will have our monthly threat update webcast. Looks like it will be a light Microsoft day, so we will discuss some techniques on how to fight (D)DoS attacks. For details, see:

https://www.sans.org/webcasts/show.php?webcastid=90621

For archives of prior webcasts, see the archive

0 Comments

Published: 2006-05-08

Typo-Squatting and Password Best Practices

Michael asked what to tell his sister, who recently visited a webmail site with a similar name to her regular webmail site, and she entered her username and password at the wrong website. This is actually a multi-layered question, and I am trying to cover the different issues related to this.

First of all, in order to avoid falling for typo-squatters, use bookmarks. Using bookmarks to reach trusted sites is probably the safest method. Never click on any e-mail link to reach a trusted site. In addition, avoid typing long and sometimes easy to misspell host names.

If you use a lot of different computers, you could use one of the personalized home page sites. At least, this leaves you with only one hostname to type, the name of the homepage. However, unless you setup your own homepage/web server, there is a problem with privacy. You trust that the site you use to store your links is safe.

A USB stick with your favorite bookmarks may work if you are able to plug a USB stick into the system you are using. Trust is again an issue, as the computer you use may modify the content of the USB stick (could even add a virus). But its probably an illusion to expect secure computing while you use a PC you don't trust. A few people tried to solve this issue, but its tricky (bootable CD is probably the best option, but not everybody will allow you to reboot a PC).

Once you know you fell for a typo-squatting site, change the password you surrendered as fast as possible. Which brings up another important point: Password security. I usually recommend a 2+n password approach:
  • use 1 password for "throwaway" registrations. This password should be used for sites that require you to register, but they don't store any sensitive information (e.g. some newspapers that require you to register).
  • use a second password for sites that you visit infrequently, and that don't store any personal information, but impersonation may be a problem. For example, think about bulletin boards. Someone may be able to post insults in your name if your password is lost. The same password may also work for e-commerce sites that do not store. your credit card number (its a bad idea to let them store it anyway). But this is a question of personal preference. How much do you care if someone can see your amazon.com orders (and addresses that go with it)?
  • The 'n' is for all other sites. These sites require specific, hard to guess passwords. Examples are online banking sites, or e-commerce sites with personal information which you want to protect very well.
For personal/home use, I do recommend stronger passwords, and write them down. Yes, you may use a Post-it and tape it below your keyboard. It all depends on what you consider a threat. In my opinion: If someone breaks into my house and steals the computer (or has access to it for some time), lost passwords are not a huge issue and can be reset.

Lastly: What is a trusted/trustworthy website? isc.sans.org is! I know. I administer it. For all other sites: Decide for yourself. I can't make that decision for you, as I don't know how well the site is maintained.
I mentioned before that the commonly used line "don't visit unsecure web sites" is nonsense.


0 Comments

Published: 2006-05-07

Port 38566, Update to Firefox weakness, Packetfoo site launched!

 Lots of scanning on port 38566

http://isc.sans.org/port_details.php?port=38566

Shows a very large number of records and sources, and a small set of targets.  

Its is currently #1 in the Dshield Ports list:

http://www.dshield.org/topports.php


Update to Firefox vulnerability posted  earlier

http://secunia.com/advisories/19698/

This particular vulnerability could be exploited by a malicious web site, enabling the remote site to open and view content of local files.  This is enabled by the site tricking the user into right-clicking (alt-clicking) and choosing the "view image" on a broken image link.  The malicious site links to a file on your machine, which then exposes the file.


Packetfoo launched

Many of us have been wanting packet capture file archives for a while.  Richard Beijtlich started a project called OpenPacket.org and I startedPacketfoo.  I have talked to Richard briefly about collaborating, and Im sure we will further that as the projects grow.  Ill be setting up the charter, and putting up files as the days go by.  Any support would be  appreciated.

domo arigato gozaimas,

Mike Poor
Handler on Duty
Intelguardians

0 Comments

Published: 2006-05-07

New Firefox Vulnerability(?)

Today on Bugtraq a message was posted that listed a possible vulnerability in Firefox 1.5.0.3.  Several attempts by various Handlers were unable to determine that a new vulnerability actually exists.  The link posted to Bugtraq took us to a web page that was purported to run the exploit, which did not appear to work.  Stay tuned for further details.

The "exploit" appears to be a simple link to an audio file (claims to be an image). If you, as instructed by the exploit page, open the "image", you will launch your media player and load a local .wav file. Nothing actually "bad" about that as far as we can tell, so this is probably just a joke to point out some of the social engineering aspects of hyperlinked media.


0 Comments

Published: 2006-05-06

Significant increase on 38566

On this quiet Handler day I received an email from a reader questioning recent activity on 38566.  This port is used, according to TrendMicro as BKDR_TRODOR.A, which is a password-stealing backdoor.   The strange thing about this as compared to others we see is the number of sources versus the number of targets.  If anybody could submit some packet captures we'd love to take a look.

0 Comments

Published: 2006-05-05

Talented and Creative Group We Are

Ok - We all know what a talented and creative group our Handlers are.  Some of them may be the most intelligent and talented programmers on earth.  Ok, maybe that is an exaggeration,  however we do have 3 of the finest in our amazing group.  By that I am referring to Tom Liston, Ed Skoudis, and Mike Poor.  These 3 brilliant minds have come together and created a nifty site to test just how well your computer is protected from the perils of the Net.

These sharp chaps have developed a web site that they call Spycar.

What is Spycar?
Spycar is a suite of tools designed to mimic spyware-like behavior, but in a benign form.  Intelguardians created Spycar so anyone could test the behavior-based defenses of an anti-spyware tool.

Check it out at www.spycar.org.

There are 17 tests that can be run.  (Tom assures me that these are harmless tests). Let us know how well they have done.  Let us know what program you are using and how many reds you get.


0 Comments

Published: 2006-05-05

Google Grants for summer of code

Google is once again sponsoring grants of $4,500 for students to work on open source software. Applications are only accepted between May 1st and May 8th 5:00PM PDT. The google summer of code site http://code.google.com/summerofcode.html is returning a 502 error code right now, possibly due to that deadline and the number of people who are interested.

Projects that qualify for these grants includes one of my favorite tools NMAP.
From: http://www.insecure.org/nmap/GoogleGrants.html
"The 2005
Google Summer of Code project was a tremendous success (project results) and benefit to the Nmap Project, so we are delighted to announce that we are participate again for their 2006 program! This innovative and extraordinarily generous program provides $4,500 stipends to hundreds of university students to create or enhance open source software during their summer break!"

0 Comments

Published: 2006-05-05

Reports of Other DDos Attacks Taking Place

One of our readers emailed us saying that their website had also experienced the same type of activity earlier in the week that BlueSecurity is reporting now.  This  site also deals with  security  related issues.  The reader posed this question "Are there other security related websites that are experiencing the same type of activity?" 

So, if you have any information about other sites that have experienced a DDOS recently let us know.


Deb
Handler On Duty


0 Comments

Published: 2006-05-05

Email from Guy Rosen at Blue Security

We just received an email from Guy Rosen at BlueSecurity outlining what they have been dealing with all week.  Here is the email in it's entirety:

Hi handlers,

In the midst of us working to restore our service after the major attacks on our service, I noticed the second mention of us in the handlers' diary and thought I might give you guys an update of what's going on back here. As you can see I'm writing from my personal email since much of our access is still limited.

So, what have we seen this week?
Monday:
 - Spam-based threats and accusations
Tuesday:
 - Our website www.bluesecurity.com is cut off from outside of Israel by a mysterious routing change
 - Later on, huge DDoSes lash out at our service's servers (but NOT the www, note!), with adverse effects to several different hosting facilities in which they were located.
 - To restore access to our inaccessible www site and keep our users informed, we restore an old blog we had and point www there.
 - Within about an hour, a DDoS attacks the blog site on which that blog was located.
Wednesday:
 - A massive DDoS goes out at our domain's DNS provider, causing a service outage that affected their customers.
Thursday:
 - DDoSes continue as we relocate our service to bring it back up. One estimate was of something of the order of 10 million packets/sec coming in.
Friday:
 - Today we are slowly coming back up and hope to see the service working soon.

I have to say that the great lengths the spammers have gone to in order to bring us down are worrying, not only in the specific context in which they took place in this last week, but I think given the general idea that so much power is available to people of this nature and that they are willing to use it in order to see things go their way. Seeing us as a threat, they did not seem to care who they brought down on the way.

I'm looking forward to seeing the ideas people bring up in response to your call for anti-DDoS suggestions.

Thanks,

Guy Rosen
Blue Security


We wish Blue Security a full and successful return to the net.


Deb Hale
Handler On Duty

0 Comments

Published: 2006-05-04

More on blue security DDOS - DDOS response

On May 1st Handler Jim Clausing wrote about the Woes of Blue Security at http://isc.sans.org/diary.php?storyid=1304

A couple of readers have written in about the threat of DDOS. One reader asks:
" I always read about large company X was under attack from a DDOS and within a few [hours|days] it was brought under control. My question is, how?"

I would like to start to compile a list of steps to respond to this. So if you have any suggestions send them in I will get a list out over the weekend.

thanks Dan
www.madjic.net

Update: May 07, 2006
An initial document regarding DDOS mitigation.  http://www.madjic.net/wiki/pmwiki.php?n=Main.DDOSMitigationTechniques
Please feel free to send changes or suggestions. I will continue to research and update this document over the course of the next several months.

0 Comments

Published: 2006-05-04

Spam blocking by RBL, when is a good thing too much?

I was involved in a recent discussion that was interesting regarding a startup company that got a new (to it) ip address assignment from its ISP. As soon as they lit up their mail server emails started to get blocked by spam filters. It turned out that a previous owner of that IP block got themselves on several spam black hole lists.

It is a long standing issue with the various RBLs that it is easy to get blocklisted, and tough to get unlisted. Needless to say the company in question requested a new address assignment from the ISP and resolved the problem that way. Leaving that address to the next poor victim to deal with it.

I have seen this situation personally a few times in the last year. I have started to suggest that anyone working with an ISP to get a new address assignment check the address block with various RBLs before accepting and putting the addresses into production. I also recommend that they request the ISP perform this check prior to making the assignment, some are more cooperative than others. Sorry I will not mention any names of ISPs. They know who they are, and if you ask them you will know too.

Dan
dan /at/ MADJiC /./ net
http://www.madjic.net/


Update:
Reader Yakov Shafranovich wrote:
"A while back when I co-chaired the ASRG, we wrote up a document which addresses RBL issues:

http://www.shaftek.org/publications/drafts/draft-irtf-asrg-bcp-blocklists-00.txt

Specifically section 2.5 would be relevant here."

Thanks for the hard work and intersting read! It seems to me that temporary blocking
would best serve the community. Of course defining temporary could keep some attorneys
very busy I suppose.

Update:
Another reader Melvin suggests that the following article should be required reading for small and medium size businesses deploying mail services in limited address space. the article describes using routing mail through an ISPs smarthost so as not to be filtered by RBLs.
I agree this is a great method to bypass this problem. In my opinion the "openness" of the Internet suffers when we are forced to take these kind of measures. There is a trade off involve here obviously.

Update:
It seems that this is a sore spot for many folks. Another writer who asked to remain anonymous wrote in that "he could spend much of his day chasing stale RBL entries" that it would serve his customer base, but is a waste of time based on what his team is supposed to be doing. He also mentions that a new trend towards reputation based blocking has a whole new potential danger.
He advocates for individuals building local RBLs for local use. I would add to that that anyone using a product for spam filtering should be aware of what they are blocking with that tool and feed back to the producer if they see erroneous mesages in the filters. One more thing for admins to chase.

0 Comments

Published: 2006-05-04

Port 8443 Spike

There is a recent spike in TCP port 8443 http://isc.sans.org/port_details.php?port=8443.  Any one have any details on what this traffic might be? Packets with payload would be great!

Update:
Many readers have written in commenting on what products use this TCP port.
This is a pretty sizable spike. It ispossible that there is some new exploit or scanning tool  being used. That is what I am looking for evidence of.

Okay we have a good handle on the products using port 8443:
ePO
Some web portal software
Alternate ssl port
Web app backend products
A backup package

The question still remains: what is the cause of the spike? It is legitimate traffic or malicious?

0 Comments

Published: 2006-05-03

Firefox fix 1.5.0.3 / MySQL Patches

Firefox update 1.5.0.3 was released yesterday, fixes a denial of service condition rated "critical". If your Firefox is set to automatically update, it eventually might do so. Otherwise, you can use Help->Check For Updates.

A new MySQL release is out, and fixes among others the exploitable buffer overflow reported last week by Stefano di Paola. See also the FrSIRT advisory.

0 Comments

Published: 2006-05-02

New Version of PHP, Cisco Advisory, BurstNET DoS'd

PHP has released version 5.1.3 which has several important security fixes that will help prevent much of the abuse that PHP has gotten lately.  I'd encourage those of you using PHP to seriously consider upgrading when you can.

There is a privilege escalation in Cisco Unity Express that allows an authenticated but unprivileged user to reset the password of any expired account.  This could be used to gain a higher level of access or even administrator access.  This doesn't strike me as a very critical issue as you need to have access to the HTTP management interface to execute this attack.  Those environments that practice least privilege (i.e. not giving people access they don't need and removing access when no longer needed) shouldn't be affected by in a big way.

Earlier today, a popular hosting/colocation company was the target of a denial of service attack and was down for a little bit.  They seemed to take care of the problem pretty quickly. 

At a point where it seems overwhelming with all the new attacks, I'm glad that there are other things to worry about than gibbering packet apes kicking over networks with DoS attacks.  At least now the bad guys come with some interesting hacks and there is real stuff on the line (identity theft/fraud, for instance).  In the words of Ed Skoudis, you can think of it as "unlimited job security".

--
John Bambenek, bambenek /at/ gmail /dot/ com

0 Comments

Published: 2006-05-02

DNS cache poisoning again!

DNS cache poisoning report.
For background you may wish to review this report  http://isc.sans.org/presentations/dnspoisoning.php
and this issue about BIND 4 or 8 not being suitable as forwarders http://isc.sans.org/diary.php?date=2005-04-28

Next, a request. PLEASE review your dns servers logs and cache for 65.23.154.2 If you find it listed as authoritative for .com please send us an email with a dump of the dns cache. Directions for dumping, cleaning and protecting your cache are available in the write-up above.

Serverhome.com (65.23.154.2) is being reported for Kashpureff-style cache poisoning for the .com TLD.

This report shows there are about 16k domains hosted on this server.
http://www.ipwalk.com/webhost/total_domains/webhost_name/serverhome.com

Be careful if you look up one of those domains there is a good chance you will see extra RR records including ones that claim they are authoritative for .com.

Sample packet showing the cache poisoning in action. Note the extra .com servers.
No.     Time        Source                Destination           Protocol Info
19 12.201047   65.23.154.2           192.168.0.3           DNS      Standard query response A 65.23.154.2
Frame 19 (542 bytes on wire, 542 bytes captured)
Ethernet II, Src: Actionte_58:9d:0a (00:0f:b3:58:9d:0a), Dst: HonHaiPr_1d:cc:b4 (00:14:a4:1d:cc:b4)
Internet Protocol, Src: 65.23.154.2 (65.23.154.2), Dst: 192.168.0.3 (192.168.0.3)
User Datagram Protocol, Src Port: domain (53), Dst Port: 3918 (3918)
Domain Name System (response)
    Transaction ID: 0x0029
    Flags: 0x8580 (Standard query response, No error)
    Questions: 1
    Answer RRs: 1
    Authority RRs: 15
    Additional RRs: 10
    Queries
        www.ibm.com: type A, class IN
    Answers
        www.ibm.com: type A, class IN, addr 65.23.154.2
            Name: www.ibm.com
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 1 day
            Data length: 4
            Addr: 65.23.154.2
    Authoritative nameservers
        com: type NS, class IN, ns a.gtld-servers.net
            Name: com
            Type: NS (Authoritative name server)
            Class: IN (0x0001)
            Time to live: 1 day
            Data length: 20
            Name server: a.gtld-servers.net
<SNIP b-m gtld-server list >
com: type NS, class IN, ns ns1.serverhome.com
            Name: com
            Type: NS (Authoritative name server)
            Class: IN (0x0001)
            Time to live: 1 day
            Data length: 17
            Name server: ns1.serverhome.com
        com: type NS, class IN, ns ns2.serverhome.com
            Name: com
            Type: NS (Authoritative name server)
            Class: IN (0x0001)
            Time to live: 1 day
            Data length: 6
            Name server: ns2.serverhome.com
    Additional records
        a.gtld-servers.net: type A, class IN, addr 192.5.6.30
            Name: a.gtld-servers.net
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 1 day, 21 hours, 4 minutes, 21 seconds
            Data length: 4
            Addr: 192.5.6.30

        <SNIP b-gtld – g-gtld>

        h.gtld-servers.net: type A, class IN, addr 192.54.112.30
            Name: h.gtld-servers.net
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 1 day, 21 hours, 4 minutes, 21 seconds
            Data length: 4
            Addr: 192.54.112.30

I provided this information to the hosting provider Rackmounted.Com. They stated that
"Returning unexpected answers to queries that will never occur in the wild is not abuse"

So I did a dig for serverhome.com a domain they own.
dig @65.23.154.2 serverhome.com
; <<>> DiG 9.2.1 <<>> @65.23.154.2 serverhome.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8745
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 15,
ADDITIONAL: 2
;; QUESTION SECTION:
;serverhome.com. IN A
;; ANSWER SECTION:
serverhome.com. 86400 IN A 65.23.154.2
;; AUTHORITY SECTION:
com. 86400 IN NS i.gtld-servers.net.
com. 86400 IN NS j.gtld-servers.net.
com. 86400 IN NS k.gtld-servers.net.
com. 86400 IN NS l.gtld-servers.net.
com. 86400 IN NS m.gtld-servers.net.
com. 86400 IN NS ns1.serverhome.com.
com. 86400 IN NS ns2.serverhome.com.
com. 86400 IN NS a.gtld-servers.net.
com. 86400 IN NS b.gtld-servers.net.
com. 86400 IN NS c.gtld-servers.net.
com. 86400 IN NS d.gtld-servers.net.
com. 86400 IN NS e.gtld-servers.net.
com. 86400 IN NS f.gtld-servers.net.
com. 86400 IN NS g.gtld-servers.net.
com. 86400 IN NS h.gtld-servers.net.
;; ADDITIONAL SECTION:
ns1.serverhome.com. 86400 IN A 65.23.154.2
ns2.serverhome.com. 86400 IN A 65.23.154.2


Highlights from the original Email thread reportng a DNS cache poisoning event.

"I have been investigating a DNS problem my company experienced late
last week. Users were reporting that no matter what site they attempted to access they would receive a page indicating that the domain was for sale.

I did some basic troubleshooting and found that all requests that were resolved against our internal DNS server were answered with the same address 65.23.154.2. I began digging in the DNS logs and found that NS record for the "com." zone had been inserted at what seemed to be a higher priority then the common TLD servers in the "com." domain.


After the cache became corrupted it caused our internal name servers to query 65.23.154.2 as a name server for the "com." zone. It would reply with the 65.23.154.2 address to any request that was requested.

I was out of town at the time of the event and without understanding what it was I was
dealing with I blocked access to 65.23.154.2 at our firewall, cleared the cache on all internal DNS servers and cleared the cache on our proxy.

I then contacted the ISP and left word that I thought they may have
a misconfigured host on their network but I did not receive a response.

Today, I was able to find the time to confirm these findings in a VM environment that I placed on our external network. The server is a MS Windows 2003 with SP1 installed and the "secure cache against pollution" check box was enabled.

I contacted MY_ISP yesterday and inquired as to what version of DNS they
were running on our forwarders. They would only admit that they had
version(8.something) and seem quite defensive about the notion that they
had forwarded corrupt cache info that caused my company so much trouble
late last week. It seemed as if they were insistent on saying that
their cache was not corrupted. I tried to explain that I didn't think
that it was only that poisoned authority records had been passed to us
from them as a result of an authoritative response from a malicious
server.

I am going to recommend that my company install its own DNS cache servers in our DMZ running the latest version of BIND and to NOT allow internal DNS servers to conduct recursive lookups."

Additional DNS information.

There are a lot of other systems that are currently setup to do dns cache poisoning.
http://dns.measurement-factory.com/surveys/200603-poison.txt
Cornell did a dns survey their report is available here:
http://www.cs.cornell.edu/People/egs/beehive/dnssurvey.html
ISC.com's DNS survey results
http://www.isc.org/index.pl?/ops/ds/

0 Comments

Published: 2006-05-02

What's a super.proxy.scanner and why is it in my logs?

Disclaimers:
Visit the urls at your own risk.

One of our readers has come across an interesting phenomenon in his proxy logs that we're hoping someone can shed some light on.

Imagine reviewing your webserver or proxy logs and seeing requests for a website completely unrelated to your organization,
but an IP address in your address block appears in the hostname.

(Thanks to Jeremy for the report and the offer to share. I was able to find plenty of examples on the internet without referencing yours specifically)

So here is an example URL that might show up in your logs:

http://check.216.109.136.53.v.80.pw1.super.proxy.scanner.i.thu.cn/Provy_OK.html

running the host command on the above hostname provides:

check.216.109.136.53.v.80.pw1.super.proxy.scanner.i.thu.cn has address 61.135.170.153

Hrm. 216.109.136.53 is a an IP in Hoboken, NJ. Thats about 6800 miles away from the host in China (61.135.170.153).

If you search for the string "super.proxy.scanner" in google you get 3 pages of proxy and web logs showing requests for various URLs that follow the form:

http://check.$ip_address.v.80.(pdx8|PCN22|mt1|pw1).super.proxy.scanner.(i.thu.cn|ii.9966.org)/Provy_OK.html

All of the hostnames resolve to 61.135.170.153.  All of the logs I could find show this activity only in the March-April 2006 timeframe so relatively new.

Visiting one of these hinkey URLs always provides the following (well at least in the few I tried):

"OK0001"

The webserver is running lighttpd/1.4.11 (http://www.lighttpd.net/)

Thats about all I could find. The string "super.proxy.scanner" showed up on a few sites as the top search results so someone or some program is looking for this traffic as well.

So let us know if you have any theories (or maybe you know exactly whats going on here) See Below for new information.  Also if you have any web/proxy log entries (or even better pcaps of all traffic related to one of these IPs) feel free to send them in.  We'll post whatever we find in the diary.

One interesting tidbit, while researching this I fat-fingered a lookup and the DNS server gave me an interesting IP back:

dig any suprt.proxy.scanner.ii.9966.org
;; QUESTION SECTION:
;suprt.proxy.scanner.ii.9966.org. IN    ANY

;; ANSWER SECTION:
suprt.proxy.scanner.ii.9966.org. 300 IN A       61.135.170.153
suprt.proxy.scanner.ii.9966.org. 300 IN NS      ns1.suprt.proxy.scanner.ii.9966.org.
suprt.proxy.scanner.ii.9966.org. 300 IN NS      ns2.suprt.proxy.scanner.ii.9966.org.

;; AUTHORITY SECTION:
suprt.proxy.scanner.ii.9966.org. 300 IN NS      ns2.suprt.proxy.scanner.ii.9966.org.
suprt.proxy.scanner.ii.9966.org. 300 IN NS      ns1.suprt.proxy.scanner.ii.9966.org.

;; ADDITIONAL SECTION:
ns1.suprt.proxy.scanner.ii.9966.org. 300 IN A   61.135.170.159
ns2.suprt.proxy.scanner.ii.9966.org. 300 IN A   61.135.159.152

Here is what I would have gotten without my typo:
dig any super.proxy.scanner.ii.9966.org
;; QUESTION SECTION:
;super.proxy.scanner.ii.9966.org. IN    ANY

;; ANSWER SECTION:
super.proxy.scanner.ii.9966.org. 300 IN A       61.135.170.153

;; AUTHORITY SECTION:
ii.9966.org.            86400   IN      NS      ns2.ii.9966.org.
ii.9966.org.            86400   IN      NS      ns1.ii.9966.org.

Some results from google:
check.216.109.136.53.v.80.pdx8.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.216.109.136.53.v.80.pw1.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.216.109.136.53.v.80.PCN22.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.63.245.201.35.v.80.mt1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.66.34.248.90.v.80.pcn22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.147.251.3.78.v.80.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.147.251.3.39.v.80.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.130.71.96.35.v.80.mt1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.141.225.152.87.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.207.73.173.23.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.63.245.201.36.v.80.pw1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.207.73.173.23.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.58.188.232.10.v.80.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.63.245.201.35.v.80.PCN22.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.207.210.74.70.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.151.100.18.65.v.80.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.212.192.114.3.v.80.mt1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.128.243.107.6.v.8080.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.192.107.81.22.v.80.pw1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.192.107.81.22.v.80.PCN22.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.130.85.162.106.v.80.pw1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.130.85.162.106.v.80.pw1.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.167.196.204.113.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.212.192.114.3.v.80.mt1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.207.210.74.70.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html

Interesting entry from the web log for a webcam:

Camera 1: Security alert:
user from IP address: 61.135.170.159 is trying to read file:
check.70.60.215.15.v.8080.PCN22.super.proxy.scanner.i.thu.cn/Provy_OK.html

Update: 5/2/06:

Thanks to everyone who wrote in with theories and facts.

This activity appears to be related to a scanning tool call "proxy_scanner" which was released in Chinese hacker circles in 2004.
The site was.io8.org was used to distribute this tool and traffic related to that site was sent in to us as well.
 (Note: we don't have a copy of the toolkit yet, so if anyone has a copy we can analyze.....)

proxy_scanner details:
  • Scans for proxies by breaking the sender queries into multiple parallel processes
  • Uses libpcap to listen for responses.
  • Target selection list is randomized

Here's an excerpt from a known Chinese hacker repository:

     http://proxy-scanner.thu.cn/proxy_scanner-0.0.14.tar.gz
     It depends on libevent, and can run on Linux/FreeBSD box.
     No any document here now, all things is in source.
     It's ugly but it's power full. it can scan whole B network in
     60 seconds
     http://was.io8.org/me/project

Related Hosts Details (thanks to Team CYMRU's wicked whois server):
AS Name
AS      | IP               | BGP Prefix          | CC | Registry |

JINGXUN Beijing Jingxun Public Information Technology Co., Ltd
9803    | 211.100.33.61    | 211.100.32.0/19     | CN | apnic    |

CHINANET-BACKBONE No.31,Jin-rong Street
4134    | 61.183.15.41     | 61.183.0.0/19       | CN | apnic    |
4134    | 61.183.15.62     | 61.183.0.0/19       | CN | apnic    |

CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
4808    | 61.135.159.152   | 61.135.128.0/19     | CN | apnic    |
4808    | 61.135.170.153   | 61.135.0.0/16       | CN | apnic    |
4808    | 61.135.170.159   | 61.135.0.0/16       | CN | apnic    |

Note: If you see an IP you own in one of the above URLs you might want to check your proxy configuration.
Here is are a few resources regarding open proxies and how to secure them:
http://www.ftc.gov/secureyourserver/
http://www.us.sorbs.net/faq/proxy.shtml
http://en.wikipedia.org/wiki/Proxy_server

You can also refer to this list of open proxies and see if your site is listed:
http://www.publicproxyservers.com/page1.html

The background as to why the proxies are entered into DNS is still a little sketchy.
Several bright folks wrote in hypothesizing how this method might be capable of detecting nested proxy networks.

Robert - SANS ISC Handler



0 Comments

Published: 2006-05-01

Spamming as 'terror' tactic

We received several e-mails today from folks who had received spam claiming that a database containing customer info at Blue Security had been compromised.  The folks there claim that this is not the case and that it is a scare campaign and the spammer is using lists already at their disposal.  There official statement can be found here.

Update:  It appears that bluesecurity.com has been under a DoS and/or DNS hijacking attack since this story was posted.

----------------------------
Jim Clausing, jclausing //at// isc.sans.org

0 Comments

Published: 2006-05-01

Spaf on reexamining

With much of the world observing holidays today, the mail has been a little slow except for the P2P malware using tcp port 8.  That gives me the opportunity to mention a couple of other things that might be of interest to our readers.  Now, some consider me a neo-luddite for not embracing blogs and such, but one of these days maybe I'll join the 21st century and set up an RSS reader.  Anyway, a week or so ago, I came across this essay from Dr. Gene Spafford at Purdue.  He's one of those really smart people whose opinions carry some weight with me and always gets me thinking (Bruce Schneier is another one, I've subscribed to his Crypto-Gram newsletter, I believe, since the first issue).  It is good to periodically reexamine the roots of our "best practices" and see if the underlying assumptions still apply.

-----------------------------------
Jim Clausing, jclausing //at// isc.sans.org

0 Comments

Published: 2006-05-01

SANS Top 20 Spring Update

SANS has announced its spring 2006 update to the "Top 20" list.  The high level discussion is here and the technical details are here.  The big news (which isn't big news to our readers) is the increasing visibility of malware targetting Mac OS X.

0 Comments

Published: 2006-05-01

As the Bot Turns

The below was sent to us as well as some of the ISACs around the net tonight. As there is quite a bit of information being conveyed by the author, I am going to leave the majority of the advisory as originally written.  I will note that this started with a click happy user on AIM to the best of our knowledge.

---snip---
A bot was seen spreading via AOL Instant Messenger (AIM) earlier today that appears to be using "encrypted"[1] peer-to-peer (P2P - possibly Waste?) as the Command and Control (C&C) mechanism. The bots communicate with each other via port 8/TCP.

The bot does not use DNS to find any C&C. It also does not use any human readable strings in its client/server communication. Therefore, many IDS measures will not help you detect infected hosts on your network. Flow analysis and/or tcpdump looking for mysterious port 8/TCP traffic seems to be the best way to detect these infections on your network.

I realize that phatbot has been able to use Waste as the C&C for several years. However, I remember finding these botnets years ago, and the bots involved, and they typically were 600KB or more in size. The bot involved here is comparatively lean at 173KB.

Info about the sample I obtained:
MD5: 74600e5bc19538a3b6a0b4086f4e0053
Installation Location (when run): %WINDIR%\System32\mstc.exe
WinXP Firewall: Grants itself an exception called "null", which allows inbound 8/tcp from anywhere. This was done without the user notification pop-up (it likely edited the registry entry directly).

The file distributed via the AIM link and %WINDIR%\System32\mstc.exe are identical - no other files are dropped, etc.

I infected a test computer with the binary. It tried to connect to port 8/tcp on 22 different IP addresses. (Note that these are most likely the "seeds" of the P2P network that were coded into the version of the binary that I downloaded.) Only four of the IP addresses responded that they were listening on 8/tcp.

My lab computer tried to contact each of the 22 IP addresses many times (I left it infected for about 15 minutes with a firewall in place that blocked all incoming packets, solicited or otherwise). Since it tried to contact each of these many times, and not any other IP addresses, I feel it is fairly safe to guess it was not randomly selecting IPs to obscure "the real C&Cs".

Anyhow, after 15 minutes of firewalling off all inbound packets altogether (even SYN/ACKs) to my infected lab computer, I lifted the incoming IP restriction. The first host my lab computer connected to on 8/tcp started a relatively short connection (10-12 packets each way), and nothing was in cleartext. In the middle of the TCP conversation, that same host connected to port 8/tcp on my host (the malware holds that port open). The connection from them to me was simply a three-way handshake, immediately followed by FIN/ACKs from them  then me. It then closed my connection to it altogether, via FIN/ACKs again.

My host then tried several other IPs (still in the list of 22, with only four of them online), and this time, connected successfully to a different host. The connection lasted for a couple of minutes before I pulled the plug.

There was more communication this time around. During the connection, the remote host connected to 8/tcp on me just like the other one did (three-way handshake, then FIN/ACK, just like before). The initial connection from  my host to theirs continued afterward. One of the packets from the remote host contained a full 1460 bytes of data. (Other packets to/from 8/tcp on infected hosts thus far had contained 64 bytes of data or less.) There was no SSL/TLS negotiation evident, and again, the contents were not human readable. I haven't taken the time yet to see if it's something simple like XOR or Base64. I suspect the content was an updated list of other infected hosts.

While still connected to that host, my bot still tried connecting to others (not common for a traditional botnet, but expected for a P2P connection). It connected successfully to a third host. My host did to that host as the others above did to it - complete the three-way handshake, then ended it with FIN ACKs. It then connected to another host that was NOT on the initial seed list. (My theory is that my host learned of this one from another bot) After that, I turned it off, so that I could write this.

Moral of the story: Prepare to watch for 8/tcp flows for a while. Unless I'm wrong, this botnet should be able to stick around for a while.

[1] I am using "encrypted" in quotes because I have not identified the protocol - but it is not human-readable. I'm sorry if this sounds FUD-like, but I wanted to get the word out sometime *before* I had done hours of analysis!
-------Snip-------

Update 1:

Earlier Sunday, Symantec has posted a write-up about this particular binary.  It is located at http://www.sarc.com/avcenter/venc/data/w32.nugache.a@mm.html. Please note that they do not have any mention about the P2P traffic noted above.  There is more analysis being done on malware by the various AV companies and others in our malware analysis team.

I expect that this binary will be detected by most AV companies quickly (today I hope) and slow its spread tremendously.  However, I also expect that this is a signal that the botnet writers are entering a new generation of  development and capabilities.  Those of us that are tasked with defending our various networks will need to find a new and better game plan to spot and counter these encrypted/p2p based botnets.

Update 2:

A few hours ago, Bleeding Snort issued some rules to help people detect this botnet on their network.  The signatures are located at bleedingsnort.com.

Hope all of you have a pleasant May day in the morning.

--
Scott Fendley
Handler on Duty


0 Comments