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 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

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."

• 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.

• 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.

Vendor information:

McAfee

File size: 233472 bytes
MD5: c1bb026ec2b42adc17d0efb7bb31f4dc
SHA1: 02b9a9530e0f4edb3bc512707c16390ea5b394d1

Symantec

• Dropper component
• Backdoor component

F-secure

• F-Secure

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.

Trendmicro

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

Trojanized Word document files:

• W97M_MDROPPER.AB
• W97M_MDROPPER.AC

Dropped malcodes:

• BKDR_GINWUI.A
• BKDR_GINWUI.B
  

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.

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.

• 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.
  

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

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.

• 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)

• JPEGs [CVE-2006-1458],
• Flashpix [CVE-2006-1249],
• PICT [CVE-2006-1453, CVE-2006-1454],
• BMP [CVE-2006-2238]

• Quicktime [CVE-2006-1459, CVE-2006-1460]
• Flash [CVE-2006-1461]
• H.264 [CVE-2006-1462, CVE-2006-1463],
• MPEG-4 [CVE-2006-1464]
• AVI [CVE-2006-1465]

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.

• 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

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

Thanks to Colin and Chris for letting us know.

• 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.

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.

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.

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!"

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.

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