Главная > Uncategorized > Drive-by-Download: еще один способ отличить человека от робота

Drive-by-Download: еще один способ отличить человека от робота

Напомню, что целью атак Drive-by-Download является распространение вредоносного кода, а реализуются они через привлечение жертв на вредоносный сайт с последующей эксплуатацией уязвимостей в ПО (браузер, flashplayer, pdfviewer, компоненты ActiveX и т.п.).
Для того, чтобы вредоносный сайт подольше жил, злоумышленники предпринимают целый ряд защитных мер (о них подробно написано в нашей статье «Drive-by-Download по-тихому или Маскируем вредоносные сайты от wepawet и его друзей» в сентябрьском номере Хакера), среди которых:
— отделяют уязвимых пользователей от неуязвимых (страницу с эксплойтом не хочется показывать абы кому);
— отделяют посетителей-человеков от роботов (роботы, а тем более боты всяких AV-производителей мало того, что не подвержены эксплойтам, так они еще могут заклеймить домен как вредоносный, что приведет к снижению времени его эффективной работы);
— отделяют новых посетителей от возвращающихся (вредоносному сайту не нужно повышенное внимание).
… и т.п.

Сегодня я хочу поделиться с вами одной идеей, с помощью которой можно отделить роботов от человеков. Итак, задача (упрощенно):
1. Есть страница X, на которую приходят (перенаправляются) посетители, в отношении коих будет проводиться атака Drive-by-Download.
2. Есть страница Y, на которой размещен непосредственно эксплойт.

Требуется: реализовать переход со страницы X на страницу Y таким образом, чтобы до страницы Y не дошли роботы, но дошли все или почти все человеки.

Усложним себе задачу, сделав следующие допущения:
1. Все роботы умеют интерпретировать Javascript. Иначе задача решается тривиально.
2. Все роботы построены на основе WebKit, а пользователи работают из-под браузера Google Chrome. Таким образом, методы fingerprinting’а также не применимы.

Сначала перечислим well-known варианты решения:
1. CAPTCHA. Не годится, ибо мы хотим свести к минимуму взаимодействие с пользователем. Кроме того, CAPTCHA на простой странице вызывает подозрения.
2. Можно регистрировать события от мыши и клавиатуры: мол, если есть — то человек, иначе — электронный болван. Но такие события эмулируются на раз.

Что же предлагается? Идея заключается в том, что типичные пользователи до автоматизма довели свою реакцию на раздражающие факторы: всплывающую рекламу или звук — немедленно выключить. Таким образом, делаем следующее: при переходе на нашу страницу пользователю демонстрируем всплывающую рекламу (полностью отрисованную с помощью Javascript), заслоняющую почти всю страницу. Нормальный пользователь тут же закроет такую рекламу. Бот — нет. Соответственно, зарегистрировав закрытие такого окна, перенаправляем пользователя на страницу Y, в противном случае — на сайт Диснейленда.

Обсуждая эту идею с Владимиром Воронцовым, получил справедливую критику метода: а что если с помощью WebKit мы будем делать скриншоты текущего окна (пример, как это работает — тут) и распознавать в полученных картинках крестики для закрытия рекламы, вычислять X и Y и эмулировать туда click мышью?
Можно в самой рекламе разместить много похожих крестиков. Например, показать смеющуюся японскую девочку anime-style — у них, как известно, глазки крестиком :)

Если мысль моя не нова, прошу кинуть ссылкой на первоисточник. Google мне ничего не сказал…

Реклама
  1. 10.11.2011 в 13:47

    Очевидно, что регистрация события «закрыть окошко с рекламой» может осуществляться двумя способами: Либо javascript внутри самой страницы, который делает редирект, либо сам крестик должен быть ссылкой, которая перенапрявляет на нужную страницу. В любом случае, все это осуществляется на клиенте. Значит, инфа о URL Y (цель перенаправления),содержится на странице X (которая видна и роботу).

    Дальше все зависит от того, насколько виртуозно написан робот в плане обнаружения линков с данной страницы. Думаю, если злоумышленник хочет ограничиться минимумом user interaction (скажем, одно любое событие), достаточно будет в роботе дернуть все возможные обработчики. То есть даже еще проще, чем сейчас у меня в сканнере.

    • 10.11.2011 в 14:00

      Обработчик ровно один — onclick. А в теле обработчика анализ X и Y с кучей ветвлений, каждая ветвь — свой XmlHttpRequest. Или просто XmlHttpRequest передает X и Y на сервер. Как собираешься обманывать такую систему?

      • 10.11.2011 в 14:06

        Я же не статически js анализирую! Можно для каждой картинки (или вообще каждого элемента) с onclick’ом строить сетку с достаточно мелким шагом и прокликивать ее целиком. Ну и запросы по ходу перехватывать.

    • 10.11.2011 в 14:14

      Вообще, твой изначальный посыл «В любом случае, все это осуществляется на клиенте.» — неверен. Я могу события обрабатывать на севере. Вот и все :)
      Кстати, именно так и делается _правильный_ fp.

      • 10.11.2011 в 14:21

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

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

  2. 10.11.2011 в 14:09

    goganos :

    Я же не статически js анализирую! Можно для каждой картинки (или вообще каждого элемента) с onclick’ом строить сетку с достаточно мелким шагом и прокликивать ее целиком. Ну и запросы по ходу перехватывать.

    Ну а я на сервере буду обрабатывать только первый X-Y от клиента, а остальные — в топку. Дальше что?

    • 10.11.2011 в 14:17

      А я, обладая пулом ip-адресов, каждый новый запрос буду делать с нового адреса, разумеется.

      PS. Мне кажется, спор довольно-таки бессмысленный. Если мы говорим о ненаправленном обнаружении ( то есть я пишу generic-бота), то, проанализировав реализацию, всегда можно построить конкретный метод фингерпринта, который этого бота обнаружит.
      Если же я пишу бота для известного мне способа фингерпринта, я всегда найду способ сделать так, чтобы фингерпринт пофейлился.

      • 10.11.2011 в 14:32

        Спор не бессмысленный. Задача злоумышленника — за минимальные усилия максимально увеличть ресурсоемкость обнаружения вредоносного сайта. Надо мыслить только в этой категории.

        Я лично на месте злоумышленника был бы согласен на pool адресов, т.к. во-первых — это сильно дорого, а во-вторых, pool ограничен. Т.е. пожертвовав одним доменом и проанализировав прокликивающих ботов, я составлю черный список, и на новом домене стоимость обнаружения ВПО для хороших парней увеличится еще больше.

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

        Как-то так.

  3. Razdobarov Alexandr
    28.11.2011 в 20:39

    Навеяно докладом про UI redressing:
    Схема будет такая же, с одним только изменением. Через css заменяем курсор на картинку n x n пикселов, на которой изображен курсор (таких картинок, вообще говоря, может быть несколько). Человек будет попадать на крестик курсором на картинке (т.е. «настоящий» курсор будет смещен относительно крестика), робот будет попадать на крестик «настоящим» курсором.

  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: