Yahoo! Messenger exploits seen in the wild
Just three days after the PoCs for 2 Yahoo! Messenger vulnerabilities have been posted (http://isc.sans.org/diary.html?storyid=2943), we’ve been informed by Roger C. from the Malware-Test Lab about a site hosting exploits for the mentioned vulnerabilities.
The exploit is referenced the standard way – an iframe points to the web site hosting the exploit (n.88tw.net). The exploit has been pretty simply obfuscated. One thing that makes it easier to identify is the object creation – for some reason attackers left it outside of the obfuscated string so it is very easy to spot:
<object classid="clsid:DCE2F8B1-A520-11D4-8FD0-00D0B7730277" id='viewme'></object>
Practically the only difference from the published PoC is the objects name – in this case it is, as you can see above, “viewme”, while the object name in the originally published PoC was “target”.
The rest is very much the same, apart from the attached shellcode. The shellcode in the sample we analyzed downloaded another dropper (of course), and this second component wasn’t detected by any AV vendor on the VirusTotal site when we tested it (!!). This dropper downloaded further components, of which one was called 5in1.exe – we haven’t analyzed this yet but judging just by the file name, it doesn’t sound good.
Mitigation
As you are probably aware, Yahoo! provided a fix practically only couple of hours after the PoCs have been posted online (kudos to Yahoo! for this). If you are using Yahoo! Messenger you should upgrade as soon as possible. Alternatively, you can set the kill bits for the affected ActiveX controls, as we’ve posted in our original diary.
One thing that might help as well is the AV detection. Although the second stage dropper wasn’t detected by any AV vendor, the JavaScript that triggers the exploit was detected by couple of programs. As the names were generic (HEUR/Exploit.HTML, JS:Feebs-D, Heuristic.Exploit.HTML), my guess is that those that detected this properly got lucky (the Javascript used standard eval(unescape("”) method). In any case, every defense layer helps.
The exploit is referenced the standard way – an iframe points to the web site hosting the exploit (n.88tw.net). The exploit has been pretty simply obfuscated. One thing that makes it easier to identify is the object creation – for some reason attackers left it outside of the obfuscated string so it is very easy to spot:
<object classid="clsid:DCE2F8B1-A520-11D4-8FD0-00D0B7730277" id='viewme'></object>
Practically the only difference from the published PoC is the objects name – in this case it is, as you can see above, “viewme”, while the object name in the originally published PoC was “target”.
The rest is very much the same, apart from the attached shellcode. The shellcode in the sample we analyzed downloaded another dropper (of course), and this second component wasn’t detected by any AV vendor on the VirusTotal site when we tested it (!!). This dropper downloaded further components, of which one was called 5in1.exe – we haven’t analyzed this yet but judging just by the file name, it doesn’t sound good.
Mitigation
As you are probably aware, Yahoo! provided a fix practically only couple of hours after the PoCs have been posted online (kudos to Yahoo! for this). If you are using Yahoo! Messenger you should upgrade as soon as possible. Alternatively, you can set the kill bits for the affected ActiveX controls, as we’ve posted in our original diary.
One thing that might help as well is the AV detection. Although the second stage dropper wasn’t detected by any AV vendor, the JavaScript that triggers the exploit was detected by couple of programs. As the names were generic (HEUR/Exploit.HTML, JS:Feebs-D, Heuristic.Exploit.HTML), my guess is that those that detected this properly got lucky (the Javascript used standard eval(unescape("”) method). In any case, every defense layer helps.
Keywords:
0 comment(s)
My next class:
Web App Penetration Testing and Ethical Hacking | Amsterdam | Mar 31st - Apr 5th 2025 |
×
Diary Archives
Comments