Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2006-09-20 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

2222/tcp Probe Increase

Published: 2006-09-20
Last Updated: 2006-09-20 22:48:41 UTC
by Scott Fendley (Version: 1)
0 comment(s)

Earlier today I detected some probes that caused me to investigate further.  My ipf logs on my handy little sparc logged hits on port 2222/tcp.  I might have glossed over it, except I have sometimes used port 2222 for secure shell daemon in the past.  This was primarily to keep people from constantly hitting my unix boxen trying to brute force passwords and giving me tons of logs to process daily.  (Yes, I know that security by obscurity doesn't work, but in this case it was more of a data reduction function for the overworked and underfunded security guy.)

Well in any case, it caught my attention a bit.  I investigated a bit further and looked at secure shell logs further to see if everyone else in the world had used the same "bright idea" which I had a few years back causing the hackers to look there as well.  Amazingly enough, no logs whatsoever in any of the systems I know are still listening on that port.

After I scratched my head a bit, I went over to the Dshield data and sure enough we are seeing the same type of probing there. 



As you can see, there has been no substational increase in sources. just records and targets.  Further investigation seems to indicate that a single IP is responsible for the majority of the records. But it doesn't clear up what were they trying to find.   Is it the old rootshell left behind by the circa 1999 linux amd exploit?  Is it something else?

So with that,  "anyone got packets?"   If you have a netcat or ssh listener and have captuered packets, or have other ideas, please contact us.

Keywords:
0 comment(s)

Yet another MSIE 0-day: VML

Published: 2006-09-20
Last Updated: 2006-09-20 14:10:28 UTC
by Swa Frantzen (Version: 8)
0 comment(s)
We got multiple readers telling us in they noticed reports about a new MSIE 0-day "actively exploited unpatched vulnerability" against VML. VML stands for Vector Markup Language and is basically a XML file delivered to your browser containing a vector drawing. It was submitted to W3C in 1998.

This 0-day apears to be different from last week's 0-day abusing daxctle.ocx (BTW: it's still unpatched).

The CVE candidate number CVE-2006-3866 initially promoted has been rejected, CVE-2006-4868 is the right one.

Detection:

Antivirus Version Update Result
AntiVir 7.2.0.16 09.19.2006 no virus found
Authentium 4.93.8 09.19.2006 no virus found
Avast 4.7.844.0 09.19.2006 no virus found
AVG 386 09.19.2006 no virus found
BitDefender 7.2 09.19.2006 no virus found
CAT-QuickHeal 8.00 09.18.2006 no virus found
ClamAV devel-20060426 09.19.2006 no virus found
DrWeb 4.33 09.19.2006 no virus found
eTrust-InoculateIT 23.72.128 09.19.2006 no virus found
eTrust-Vet 30.3.3086 09.19.2006 no virus found
Ewido 4.0 09.19.2006 no virus found
Fortinet 2.82.0.0 09.19.2006 no virus found
F-Prot 3.16f 09.19.2006 no virus found
F-Prot 44.2.1.29 09.19.2006 no virus found
Ikarus 0.2.65.0 09.19.2006 no virus found
Kaspersky 4.0.2.24 09.19.2006 no virus found
McAfee 4855 09.19.2006 no virus found
Microsoft 1.1560 09.19.2006 Exploit:HTML/Levem.C
NOD32 v21.1763 09.19.2006 no virus found
Norman 5.90.23 09.19.2006 no virus found
Panda 9.0.0.4 09.19.2006 no virus found
Sophos 4.09.0 09.19.2006 no virus found
Symantec 8.0 09.19.2006 no virus found
TheHacker 6.0.1.073 09.19.2006 no virus found
UNA 1.83 09.19.2006 no virus found
VBA 323.11.1 09.19.2006 no virus found
VirusBuster 4.3.7:9 09.19.2006 no virus found

This was for a sample on the 19th, detection will obviously improve as Virustotal shares samples with the antivirus vendors involved.

Solutions:

  • Looking into alternate browsers isn't the worst way to spend the next half hour.
    One of the easiest ways to make it work might be to use Firefox with a plugin to allow certain sites (such as windowsupdate.com) to transparently use MSIE to get back the ActiveX functionality without bothering the user over the choice and differences. If you do go that road, also add noscript, and a toolbar to block funny sites.
    See also the diary on diversity.
  • There is some posibility to lessen the impact by reducing the rights the user has but it'll only mitigate drive-by shootings at best. The targeted attacker is probably more than happy to get the rights (and access to information) the user has as part of his/her daily tasks.
    Less rights are good, even critical to have. But they are not enough to take away all danger.
  • Unregister the vgx.dll:
    regsvr32 -u "%ProgramFiles%\Common Files\Microsoft Shared\VGX\vgx.dll"
    To reverse this: run the command without the -u. Ever since the WMF issue around new year we know unregistering DLLs isn't for the faint of heart. Even if Microsoft recommends it.
  • Also: Restrictive ACL on VGX.DLL, disabling scripting in MSIE (hard to determine how effective that is against content that is basically XML)  and reading email in text only are alternate mitigations from Microsoft.

Exploits

There are a number of exploits circulating, they come from multiple domains and currently use javascript to obfuscate the code itself. However the exploit itself does not need javascript it seems.

The exploits load a truckload of other malware (for profit of course). One of the main domains involved is "insorg.org" but other more adult entertainment related sites are involved in exploiting victims as well.

Since this exploit seems to be rather easy to recreate once there is a sample, there is no end to how and where it can and will be used. We'd not be surprised to see it appear soon in more mainstream public sources of exploits.

URLs


Please note that Microsoft claims to be going to release a fix October 10th (in cycle) or earlier depending on customer need. Perhaps it's time to let them hear your need.


Thanks to all who sent in a note about this.

--
Swa Frantzen -- Section 66
0 comment(s)
Diary Archives