2222/tcp Probe Increase
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.
Yet another MSIE 0-day: VML
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
- US-CERT Vulnerability Note
- Blocking VML using a GPO (use the magic incantations at own risk)
- McAfee
- Symantec
- Trendmicro
Thanks to all who sent in a note about this.
--
Swa Frantzen -- Section 66
Comments