Вредоносный скрипт мутирует, прячась от антивирусов

Как сообщается на сайте SANS, в Интернете появились вредоносные Javascript нового типа, позволяющие оставаться незамеченными для антивирусов.

Новизна используемой техники заключается в том, что Javascript генерируется сервером динамически: при каждом новом обращении посетителя к странице все переменные и функции скрипта изменяются, принимая случайные значения. Подобная техника делает невозможным детектирование скрипта сканерами, алгоритмы поиска вирусов которых основаны на сопоставлении сигнатур.

Сообщается, что в проведенных экспериментах ни одна из протестированных антивирусных программ не смогла выявить вредоносный код. Сам код представляет собой набор эксплойтов, использующих известные уязвимости в различных приложениях.


_________________________________

Первоисточник:

Raising the bar: dynamic JavaScript obfuscation

Published: 2007-08-02,
Last Updated: 2007-08-02 22:26:39 UTC
by Bojan Zdrnja (Version: 2)

Couple of days ago one of our readers, Daniel Kluge, pointed us to a web page with some heavily obfuscated JavaScript code. The operation was typical and consisted of a compromised site that had an obfuscated iframe which pointed to the final web site serving various exploits.

The obfuscation of the iframe was relatively simple but the second stage was more heavily obfuscated with some things we’ve never seen before.

After downloading the JavaScript file it was obvious that all function and variable names are complete random. Further to that, the deobfuscation function used the well known arguments.callee.toString() trick in order to prevent modification of the code (so you just can’t replace the final document.write() call to something else as this will break the deobfuscation function body – attempts such as this one typically throw the function into an endless loop).

The screenshot below shows how the function looked when I first retrieved it.



Now, what makes this new is that the hosting web site generates this code dynamically! Every time you request this web page it will use completely random names for all variables and functions. As the deobfuscation function uses itself to deobfuscate the input, changing variable and function names even causes the payload information to change. Below you can see the beginning of the JavaScript file for two other subsequent retrievals:

(2nd try)



(3rd try)



The reason for doing this is obvious, such heavy obfuscation makes signature based detection much more difficult, if not impossible and it wasn’t surprising to see that 0 anti-virus programs detected this when tested on VirusTotal.

After deobfuscating the payload I found out that it contains the typical set of exploits: the ADODB vulnerability exploit (MS06-014), the QuickTime and WinZIP exploits, AOL SB.SuperBuddy.1, WebViewFolderIcon and the VML Element Integer Overflow . Finally, one new addition is the exploit for the NCTAudioFile2 ActiveX vulnerability (http://secunia.com/secunia_research/2007-2/advisory). While this is an old vulnerability dating from January 2007, a fully working exploit was publicly released in April and what’s worse is that the affected ActiveX control is delivered with dozens(!!!) of popular audio/video applications. This is shifting the patching process from the base OS to client applications which is usually much more difficult for users, especially if those applications don’t support automatic updates so it’s left up to the user to first find out that he has a vulnerable application and then manually patch it.

Browser differences

Now back to the infamous arguments.callee.toString() function. For those of you who regularly read our diaries, you probably remember that I analyzed a similar obfuscation method back July 2006 (http://isc.sans.org/diary.html?storyid=1519). The obfuscation function back there just used the length parameter to see if anything has been changed (obviously, changing the document.write() call to alert() or something similar will change the function body length as well). I found out that Internet Explorer and Mozilla treat white space differently and this caused the exploit to fail in Mozilla.

Daniel had problems deobfuscating this function initially and the reason why that happened wasn’t clear immediately because the deobfuscation function in this case does this:

var o3b522f35=arguments.callee.toString().replace(/\W/g,"").toUpperCase();

this call converts the function body to upper case and then strips all white space (\W matches all non-word characters) so the fact that Internet Explorer and Mozilla don’t calculate white space the same can’t matter here.

However, Daniel used Rhino while debugging it while I was playing with Windows debugging capabilities so we knew it had to be something related to the browser wars again.

After some investigation, Daniel found out that there are other inconsistencies between Internet Explorer and Mozilla when using the arguments.callee.toString() function. You can also test your browser with this bit of JavaScript code:

<script type="text/javascript">
<!--
function func(){
var l = arguments.callee.toString().replace(/\W/g,"").toUpperCase();
var failme = 00001;
alert(l.length.toString() + ' Func: ' +l );}
func(‘blah’);
//-->
</script>

This is a simple test – it calls the same function as the deobfuscation code and just declares one variable called failme with the value of 00001. If you want to test this, go to http://handlers.sans.org/bzdrnja/test.html.

Different browsers and different results:
Safari: 93
Firefox 2: 94
Internet Explorer 6 and 7: 98

Daniel’s observations were:
For some unknown reason Safari ignores “g” from the replace call. Why would they do that is not clear but it looks like a bug to me (“g” is definitely a word character).
All browsers but Internet Explorer strip leading zeros on integers so they treat variable “failme” as 1 when counting the number of characters; Internet Explorer actually counts 5 characters there.


This was the main reason why the deobfuscation function failed in Rhino which uses Mozilla’s JavaScript engine (so it stripped leading zeros from variables). Browsers are certainly strange beasts …

UPDATE



Couple of readers pointed that Secunia’s article about the vulnerability recommends setting the appropriate kill bit, but it doesn’t list any CLSIDs.

So, here’s the list of CLSIDs that this particular exploit uses, taken directly from the deobfuscated code:
QuickTime: 02BF25D5-8C17-4B23-BC80-D3488ABDDC6B
WinZIP: A09AE68F-B14D-43ED-B713-BA413F034904
SuperBuddy: 189504B8-50D1-4AA8-B4D6-95C8F58A6414
NCT AudioFile2: 77829F14-D911-40FF-A2F0-D11DB8D6D0BC

I’ve included only CLSIDs for third party application – in order to mitigate vulnerabilities in Internet Explorer make sure that you’re running the latest version with all patches installed (this is much easier to patch than all the third party applications).
_________________________________
Источники:
_http://news.softodrom.ru/ap/b1942.shtml И _http://isc.sans.org/diary.html?storyid=3219 соответственно

 

вот это жесть! фига себе

 

Да давно было ясно, что поиск вирус по сигнатуром - дело бесперспективное, и позволяет ловить лишь творения - клоны. Действительно серьёзно созданные вирусы не по силам сигнатурным антивирусам

 

наверно то что описано в новости , было создано очень давно....

просто шас тока спалили... может не конкретно это , а чтото другое , но по сути тоже самое.

 

Слабо представляю себе антивирус, который сможет самостоятельно анализировать такие вещи...А если и сделают такой, то он будет много косячить и жрать немерянно ресурсов. Я, например, с удовольствием пользовался бы антивирусом, который оценивал действия программы,скрипта и т.д., чётко показывая что программа при установке хочет сделать, что изменить и давал бы возможность это заблокировать. Сигнатурные базы бы тоже не помешали, но основной упор нужен на контроль действий.

 

Антивирусы типо Kav, Nod имеют анализаторы, но они не очень-то эффективны.

 

тут только мозги срабатают.

 

Интересно, почему нет такого антивируса, который бы помимо проверки по базам (чисто сопоставления), следил бы за приложениями? При активности бы какого-нить, вылезало бы окошко, мол данное приложение
1)Пытается записать что-то в реестр (возможно даже краткое описание, за что эта ветка отвечает)
2)Пытается выйти в интернет (куда именно)
3)Пытается записать/удалить файлы
4)...
и т.д.
Если там будет возможность создавать правила, то я бы за такую программу даже денег немного не пожалел. чтобы ни одно действие (кроме системных) не происходило без ведома пользователя.
хотя наверно это мечта

 

а про Outpost Firewall вы не слышали ??
улыбнуло....

 

красиво...

 

аутпост это конечно хорошо, но он не отслеживает действий внутри системы, а это важный фактор.

 

Вот так новизна.. Как всегда иностранные аналитики запаздывают с новостями.

 

Lexik, гениально, только скачай тулзу filemon и посмотри сколько обращений к разным вещам, реестру и тпБ и подумай сколько окошек нужно тебе буде закрывать.

>поиска вирусов которых основаны на сопоставлении сигнатур.
Разве ктонить щас юзает такие ав? Давно доказано что эвристика гораздо эффективнее.

 

Блин... Жизнь пролетает просто так... Немогу спакойно смотреть на эту новость...(

 

Если полностью так защищать комп, вплоть до регистрации действий внутри системы, ты задолбаешься алерты читать и закрывать, ибо комп - это не железный мозг, а алгоритмы =\ А вообще есть софт который следит и за реестром, и просто за приложениями, и за тем, что творица в системе, только нахрена оно кому надо? имхо антивирус+файрвол вполне достаточно.

 

У меня в паке сплоитов также все действует я не вижу чему тут удивляться

 

Новость не для удивления, если это имелось ввиду. Технологию нужно развивать, зделать нечто большее чем список сплойтов в папке. Меня заибала тупая облава закриптованых пинчей и подобных фичей..

п.с. за слова не отвечаю, пьян ув жопу.