Авторы
Сегодня мы нашли интересный зараженный сайт. В HTML текст оригинальной страницы был встроен вредоносный код. Он представлял собой отдельную HTML страницу. Т.е. авторы этого кода, нарушая стандарт HTML, вставили дополнительный контейнер <html> </html>.
Удивительно, но браузер (проверено в Internet Explorer, Firefox и Opera) с удовольствием принимает и обрабатывает такую некорректную веб-страницу. С другой стороны, разве можно требовать от злоумышленников соблюдения стандартов?Но речь, собственно, не об этом. Интерес представляет скрипт, который злоумышленники встроили во вредоносную веб-страницу. Естественно, он был обработан так, чтобы максимально усложнить анализ функционала скрипта. В нем применяется популярная среди разработчиков вредоносных скриптов техника обфускации JavaScript.
Сам скрипт выглядит примерно так:
Ну что же, стандартная ситуация. Большинство таких скриптов можно дешифровать без анализа всех манипуляций над данными. Для этого нужно лишь найти соответствующую часть кода скрипта, где производится вывод результатов на исходную веб-страницу с целью запуска полезной нагрузки. В нашем случае это функция document.write(…):
Изменим ее так, чтобы увидеть результат дешифрования кода полезной нагрузки: заменим document.write(P7E87DE2) на textarea1.innerHTML=P7E87DE2, где textarea1 — HTML-контейнер textarea на зараженной веб-странице, который мы сознательно внесли сами. Это позволит нам увидеть результат работы скрипта в текстовом поле контейнера textarea. Итак, проделав все это мы видим следующий результат:
Выходит, что этот скрипт ничего не выводит? Именно такая мысль может прийти в голову, однако при чуть более детальном изучении скрипта можно обнаружить вот такую строчку:
Что это значит? Очень просто, здесь функция получает свой собственный код и преобразует его в «кодовую» текстовую строку, состоящую только из букв и цифр. Далее внутри тела функции эта строка используется при генерации полезной нагрузки. Это значит, что результат, выводимый в textarea, зависит от тела самой функции!
Т.е. при малейшеей модификации функции, даже если это пустая инструкция, сгенерированный результат будет совершенно иным и скорее всего бессмысленным, что и произошло в случае нашей первой попытки. Это своеобразная защита от модификации кода тела JavaScript функции. Подобных решений в Javascript еще не встречалось — довольно хитроумно, не так ли?
Однако это ограничение можно обойти путем получения такой же строки извне (т.е. за границами функции) и последующим явным присвоением результата переменной q2854da60, которая должна содержать эту кодовую строку.
Проделав это, человек, пытающийся разобраться, что же все-таки скрыто внутри зашифрованного кода, может внезапно обнаружить, что при открытии правильно сформированной им страницы для получения скрытого содержимого скрипта его браузер повисает. Забегу вперед и скажу, что в этот момент компьютер исследователя подвергается заражению!
Конструкция, которую исследователь записывает внутрь <textarea></textarea> предназначена не только для заражения обычного пользователя, но и для заражения компьютера исследователя, пытающегося получить исходный код полезной нагрузки путем вывода его в textarea! Выглядит эта конструкция так:
Итак, при вставке этого кода внутрь контейнера textarea, код закрывает тег textarea и вставляет контейнер iframe, с помощью которого в браузер подгружается внешний скрипт, в котором, в свою очередь, находится троянец с эксплойтом, заражающий систему.
На этом примере очень наглядно видно, как происходит противостояние разработчиков вредоносного кода и специалистов, пытающихся защитить обычных пользователей. Это постоянная борьба темной и светлой стороны, и стоит светлой стороне допустить небольшую оплошность, как она тотчас же будет заражена сама. Именно поэтому я и люблю свою работу — она учит нас не совершать ошибок!
Авторы
От тех же авторов
В той же категории
Анти-реверс технологии в JavaScript