Pull to refresh

Comments 39

Статья интересная, но положите половину под habracut
оттыж, забыл ЖЖшный кат исправить на хабровский.
спасибо.
Я таже начал что-то подобное делать у себя на swc.striderlance.com/ — не не смог найти список сигнатур. Ваша идея гораздо продвинутее — мой должен был просто по сигнатурам искать. Но я не оставляю надежды доделать его и позволять им пользоваться клеинтам как бесплатным бонусом.
Статья полезная. Не тестировали на сжатых Javascript файлах? Они вроде примерно так и выглядят
Я упомянул об этом немного в конце.
Сжатые файлы (jquery.min, mootools) имеют модифицированную энтропию меньше установленного порога, поэтому на них детектор не реагирует, но пропускает вирусы, сжатые аналогичным способом. Такие вирусы идут в базу сигнатур.
Спасибо! Я обязательно возьму на вооружение!
Не совсем понял, вы измеряете меру энтропии чего? Если я правильно понял, вы измеряете показатель обфусцированности кода. Т.е. по сути, измеряете насколько круто и глубоко шифрует код некий алгоритм. Но тогда я не понимаю причем здесь опасность кода. Скорее, это сравнение алгоритмов обфускации, нет?
Ну да, показатель обфусцированности.
Но задача-то имеет контекст, описанный в первой части статьи, правда ведь?
Отсюда и опасность кода.
Суть скорее в следующем: код делится на чистый и скрытый (архивированный/нечитаемый, как хотите). Если он чистый, выявление завирусованных участков не составляет труда, т.к. достаточно найти соответятсвующий iframe, ведущий на другой сайт. Чтобы задетектить вирус, который «шифруется», автор предлагает основываться на том, что создатели его шифруют с таким усердием, что его настолько же легко распознать как чистый код. Достаточно найти ну уж слишком зашифрованный участок… -)
А исходники проекта где-нибудь глянуть можно?
А чо там глядеть?
Пройтись LWP по списку сайтов и для каждого крутануть список регулярок с сигнатурами, потом выделить JS-код и прогнать эвристику — самый сложный код я выложил в статье :)
А что будет если код заенкоджен каким то ioncub'ом, zend'ом...etc?
Вы о чем?
Я — о клиентском Javascript коде внедренном в страницы, получаемые клиентом на «той стороне», а вы? При чем тут zend!?
Втикнул — коммент не туда.
Данное решение будет работоспособным пока обфускаторы не будут регулировать «энтропию», что всегда можно сделать удлинив результирующий код и уменьшив алфавит.

Почему бы просто не парсить код JS и реагировать на определенные вызовы? Код доступен, достаточно просто его отработать в эмуляторе. Для 200 страниц это не проблема имхо.
Напрашивается аналогия с гвоздями и микроскопом, но я скажу лишь что не работал с JS-эмуляторами и пока такой необходимости не было, так как эта задача была сиюминутным решением а не глобальным проектом :)
А я бы предложил использовать менеджеры паролей, чтобы червь просто немог ничего угнать. За реализацией топаем на gnome-keyring и kde-wallet
Вариант два: запускать браузер в «песочнице»: грубо говоря у системы будет набор правил, что браузер может делать, а что нет. Ну и ежели браузер начинает себя вести очень подозрительно, запрашивать совершенно нехарактерные действия, обрубать его и выводить пользователю предупреждение. Это же гораздо проще и эффективнее, чем резидентный сканнер
А нет резидентного сканера.
Есть скрипт, запускаемый по крону пару раз в день, который получает по HTTP главные страницы сайтов из списка и анализирует их на предмет инжекций. Мне казалось это понятно из статьи…
Да я это понял, я в целом про организацию защиты, гораздо эффективнее не давать пользоваться уявзимостями, а не искать последствия, иначе это всёравно что крутится, как белка в колесе
Это-то понятно если вы специалист.
Но большая часть клиентов веб-студии такими специалистами не являются. И утечки паролей, чаще всего, от них и идут. А наша задача — вовремя локализовать эту утечку чтобы она не превратилась в проблему для нашего клиента, потому что мы его любим, холим и лелеем :)
Эх… ну вот как всегда из за просчёта в прошлом, приходится городить лес костылей ибо просчеты уже врасли в систему(((
Возможно в анализе так же следует учитывать употребление операторов javascript. Например, смотреть на соотношение количества символов к количеству известных операторов и сравнивать это со средней длинной оператора. Возможно ставить некоторым операторам веса, в зависимости от вероятности встретить их во вредоносном коде, document.write/writeln/createElement — с большей вероятностью будут использоваться во вредоносном коде чем остальные.

ps. точно таким же способом можно находить различные «счетчики» на сайтах.
Слишком сложно выработать проверяемые гипотезы, алгоритмизировать их и просчитать диапазоны допустимых значений их метрик. Можно, но требует времени.
Оно, конечно, интересно в исследовательском плане, но есть рабочие задачи за которые платятся деньги :)
WOW! Спасибо за описание, очень интересно.
Спасибо, весьма полезно.
UFO landed and left these words here
А ваш краулер, периодически опрашивающий сайты, обладает характеристиками браузера? (user agent, cookies и т.п.)? Иначе взломщики выявят его и отдадут чистую индексную страницу :)
Подход к решению проблемы выбран конечно интересный, но, как уже написали выше, можно ведь «допилить» враждебный жскрипт так, что его характеристики не отличить от обычных. Все-таки найти коллизию для хэш-функции куда сложнее.
Интересно кто будет выявлять скрипт со стороны сервера? Ведь вирус внедряет не серверный код внутрь индексных файлов, а лишь js-код который будет выполняться со стороны клиента.

Да и не думаю что вирусы будут в будущем маскировать свои энтропические характеристики — в интернете миллионы сайтов, чо париться-то? :)
Если бы я раздобыл пароль от фтп, то обязательно внедрился бы в серверный код :))
Мы сталкивались однажды с попыткой внедрения в серверный php-код, но это приводило к полной неработоспособности сайта в целом и было непонятно что там вообще происходило — глюк ли это был, или фича. Так что мы не стали пока заморачиваться на этом :)
я недавно выковыривал клиенту вирус, который внедрялся в php, причём не в сам индекс, а в одну из библеотек, которая инклюдилась. вредоносный код был запакован в base64 и распаковывался при парсинге страницы, дописывая код в конец.
вы сделали не это. вы реализовали сервис, который просто проверяет целостность index.php (это тот самый метод 1 — мониторить файлы на сервере на предмет изменений, храня их хэши в отдельной базе.).
здесь же — попытка проанализировать неизвестный скрипт на наличие малвари.
В полной версии имеется и эвристический анализ, как только мы её допишем (наверное, зимой) напишем здесь
только это статистическое детектирование, а не эвристическое.
Only those users with full accounts are able to leave comments. Log in, please.