Статья Взлом паролей для предотвращения Credential stuffing

g00db0y

g00db0y

Red Team
11.06.2018
94
393
Статья является переводом. Оригинал вот


Мы знаем, что пароли - отстой.

Если вы этого не понимаете, вбейте в гугл "почему пароли - отстой", и я избавлю вас от нескольких страниц текста.

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

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

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


Введение в Credential stuffing

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

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

Акт кражи учетных данных с одного веб-сайта и попытки их повторного использования на других веб-сайтах в конечном итоге перерастут в так называемую " (с англ. Заполнение учетными данными )". Такие атаки становятся проблематичными, когда используют различные средства защиты, как: двухфакторная или многофакторная аутентификация (2FA / MFA), геолокационное отслеживание и т.д., но даже у них есть свои недостатки (если они вообще есть на веб-сайте).

Согласно , опубликованному издательством Akamai, только в 2018 году было зафиксировано около 30 миллиардов попыток атак типа credential stuffing. Трудно найти постоянный источник успеха атаки, но если даже 1% из этих атак окажутся успешными, мы рассматриваем возможность взлома 300 миллионов аккаунтов. В сочетании с тем, что, по словам Акамая, они , и поэтому у нас серьезная проблема.



Действия хакеров.

Процесс выполнения этих атак прост:
  1. Злоумышленник получает (или создает свой собственный) список валидных комбинаций адресов почты и паролей, полученных при утечке данных. часто распространяются в закрытых сообществах.
  2. Затем злоумышленник использует скрипт или собственное приложение, которое автоматизирует процесс входа с каждой парой учетных данных на различные популярные сайты (Gmail, Facebook, Instagram и т.д.). Иногда они даже автоматизируют процесс размещения вредоносного контента и/или смены пароля аккаунта жертвы, что затрудняет восстановление ее учетной записи.

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



Защита клиента

Хотя компания Datto уже несколько лет предлагает 2FA в качестве опции, растущая популярность атак credential stuffing даёт понять, что мы несём ответственность за соблюдение политики безопасности от имени наших клиентов и конечных пользователей. Ранее в этом году мы объявили о переходе на обязательную политику для всех аккаунтов Партнерского портала (нашей клиентской платформы). Это позволит гарантировать, что даже если пароль клиента окажется вне игры, злоумышленнику все равно придется пройти 2FA, прежде чем он сможет причинить какой-либо вред.

Что, если мы сможем предотвратить атаки credential stuffing, чтобы они стали абсолютно бессмысленными?

Мы придумали несколько идей:


  • Вариант №1: Мы могли бы использовать API (HIBP) для поиска электронной почты и/или паролей наших клиентов.
Но это было быстро исключено по нескольким причинам:

  1. Сопоставление по адресу электронной почты не обязательно означает, что пароль клиента Datto находится в чужих руках.
  2. HIBP API позволяет искать скомпрометированные пароли, если они находятся в открытом тексте, SHA1 или NTLM форме, но Datto хранит их только в виде хэшей.
  3. Нам неудобна идея передачи конфиденциальной информации о данных наших клиентов за пределы офиса.


  • Вариант #2: Мы можем запустить в попытке перебора паролей каждого клиента со списком общих и слабых паролей.
Но это неэффективно по отношению к bcrypt, но, что более важно, это несущественно по отношению к нашим специфическим усилиям по предотвращению credential stuffing. То, что кто-то использует слабый пароль, не обязательно означает, что он был замешан в нарушении данных.


  • Вариант #3: Мы можем просто сделать то, что делают хакеры, получив некоторые учетные данные для взлома данных и попробовав их на нашей собственной странице входа.
Это было бы очень медленно и генерировало бы много ненужного трафика.


Используем гибридный подход

После оценки всех инструментов, имеющихся в нашем распоряжении, мы поняли, что можем использовать как учетные данные для взлома данных, так и хэш-пароль bcrypt клиента, чтобы помочь нам:
  • Создать нашу собственную базу учетных данных на основе популярных утечек. Использовать те же самые списки, которые используют хакеры, чтобы мы могли предотвратить их использование против нас.
  • Найти в базе учетных данных адреса электронной почты клиентов. Поиск адреса электронной почты может дать нулевой или более простой текстовый пароль, связанный с этим адресом.
  • Если мы найдем простой текстовый пароль, сравнить его с хэш-паролем клиента Datto. Если они совпадают, то мы знаем, что клиент рискует быть взломанным. Каждый криптовый хэш включает свою соль, немного упрощая эту часть.
  • Как только уязвимые клиенты будут идентифицированы, уведомить их и принудительно сбросить пароль по истечении льготного периода. Убедится, что они не пытаются повторно использовать один и тот же пароль.
Получение и распаковка популярных баз

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

1576872159567.png



Списки были упакованы глубоко в рекурсивном лабиринте сжатия различными способами (tar.gz, zip, rar и т.д.). Я не хранил никаких записей во время этой фазы, но вот что я помню:

Многие имена сжатых файлов использовали пробелы, кавычки или нечетные кодировки, что усложняло работу таких инструментов, как tar/unzip/etc. У меня были некоторые трудности с поиском решения, и мне пришлось переименовать/кодировать некоторые из наиболее проблемных файлов, прежде чем я смог их извлечь.

Для безошибочной распаковки потребовался рабочий каталог объемом около 2 ТБ.

Реальные мандаты хранились в файлах различных типов, включая: txt, csv, sql, sqlite, doc, docx, pdf, xls, xlsx и т.д. Также было много других случайных ненужных файлов (exe, dll, com, jpg и т.д.). К счастью, большинство файлов были txt и csv.


Выдача реквизитов

Так как у меня было всего несколько дней, чтобы закончить этот проект, у меня не было времени проанализировать и переварить каждый отдельный список. Я выбрал подход 80/20.

Я подумал, что, так как большинство файлов были txt и csv, то они, скорее всего, будут содержать учетные данные в шаблоне: <email><delimiter><password or hash>

Скорее всего, это было бы неправильно для таких вещей, как SQL дампы, но я случайно отобрал достаточно файлов, которые придерживались этой формы, что бы не останавливаться на этом шаге.

Используя grep и немного свободного регекса, я рекурсивно извлекал все, что соответствовало вышеуказанному шаблону:

grep -arihE -o '[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,6}[,:;\s].*' ./ > list-1

-a: Обратиться с бинарными файлами как с текстом (помогает исправить несколько ошибок).​
-r: Рекурсивное чтение всех файлов под каждой директорией​
-i: Игнорировать случай​
-h: Сгруппировать имена файлов на выходе​
-E: Расширенный регекс​
-o: Выводить только совпадающие сегменты, а не всю линию​


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

<email><comma|colon|semicolon|space><any number of characters>

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


Нормализация данных

Затем я использовал sed, чтобы осуществить несколько трансформаций: Преобразуйте все двоеточия, точки с запятой и пробелы в запятые для единообразия. Это также приготовит список для импорта в базу данных SQLite.

sed -e "s/[\:\;[[:space:]]/\,/g" -e "s/\,\{2,\}/\,/g" -e "s/\"//g" -e "s/'//g" -e "s/[^[:print:]\n]//g" list-1 > list-2
  • Сложите несколько последовательных запятых в одну запятую. Множество последовательных запятых было основным артефактом первого шага. Обратите внимание, что это также может быть выполнено с помощью: tr -s ','.
  • Удалить двойные и одинарные кавычки. Не спрашивайте, почему я разделил их, я не знаю.
  • Удалите непечатаемые и символы новой строки. Это важно, потому что в противном случае будут тысячи дублирующих друг друга записей, которые различаются только на основе невидимых символов управления.

На данный момент список содержит строки в форме:

<email><comma><a string of text>

Остались две проблемы, обе из которых были решены с помощью awk:

awk -F ',' '{ split($0, a, ","); print tolower(a[1])","a[2] }' list-2 > list-3

  • Разделите строку на массив (используя запятую в качестве разделителя), и конвертируйте адрес электронной почты в нижний регистр. Это помогло свернуть дубликаты записей, предотвратив различное обращение с fake@fake.com,password123 и FAKE@fake.com,password123.
  • Сохраняйте только первый и второй элементы массива, отбрасывая остальные. Это предотвратило ошибки " too many columns " при импорте списка в базу данных SQLite.

После этого любые строки, которые не следовали формату <email><comma><password>, становились для меня искаженными и бесполезными, но, по крайней мере, не вызывали никаких проблем при импорте SQLite. Я также предположил, что письма и пароли сами по себе не содержат запятых, но обнаружил, что сайты очень редко разрешают подобное.

Далее я отсортировал и унифицировал список вывода. Я использовал параметр -T, чтобы установить пользовательскую рабочую директорию, которую я рекомендую в любое время, когда вы думаете, что у вас закончится дисковое пространство (по умолчанию это /tmp на диске операционной системы). Эта операция может занять несколько дней или недель, поэтому лучше всего выполнить ее в screen/tmux или распараллелить каким-либо другим способом:

sort -u -T ./tmp/ list-3 > credentials.csv

Общий размер до нормализации: 816 ГБ
Общий размер после нормализации: 103 ГБ
Общее количество мандатов после нормализации: 3,4 млрд.



Создание базы данных SQLite
Я хотел создать простую схему, которая бы выполнила три вещи:
  • Позволить мне запросить адреса электронных почт как можно быстрее.
  • Предотвратить вставку пустых/неудаленных email’ов или паролей.
  • Предотвращение вставки дубликатов email’ов/паролей.
В конце концов, я остановился на следующем:

SQL:
create table credentials (
    email text not null,
    password text not null,
    constraint uc_credential unique(email, password) on conflict ignore
);

create index credentials_email_index on credentials (email);
Импорт списка учетных данных был так же прост, как:

Код:
sqlite> .mode csv
sqlite> .import ./credentials.csv credentials

Хоть credentials.csv и весил всего 103 Гб, сама база данных SQLite была размером в 396 Гб. Это было в основном результатом индексирования почтового столбца.



Взлом хэшей

Все, что осталось сделать, это запросить базу учетных данных для каждого клиентского email’a и проверить, соответствует ли любой из полученных паролей клиентскому при хэшировании. Библиотека bcrypt на Python делает это тривиальным, предоставляя функцию checkpw, позволяющую проверять обычный текстовый пароль на соответствие заданному хэшу bcrypt.

Весь процесс взлома был выполнен с помощью простого скрипта на Python:

Python:
#!/usr/bin/env python3

import bcrypt
import csv
import sqlite3

db = sqlite3.connect('credentials.sqlite3')
c = db.cursor()

# Assumes csv file formatted as <email>,<hash>
with open('customer-emails-and-hashes.csv', 'r') as csv_file:
  csv_reader = csv.reader(csv_file, delimiter=',')
  next(csv_reader)  # Skip header row

  for row in csv_reader:
    customer_email = row[0].lower()

    if customer_email:
      potential_passwords = []

      for plaintext_password in c.execute('SELECT password FROM credentials WHERE email = ?', (customer_email,)):
        if plaintext_password:
          potential_passwords.append(plaintext_password[0])

      if potential_passwords:
        customer_hash = row[1]

        for plaintext_password in potential_passwords:
          if bcrypt.checkpw(plaintext_password.encode('utf-8'), customer_hash.encode('utf-8')):
            print(f'{customer_email} : {customer_hash} : {plaintext_password}')
            break

db.close()

Окончательные результаты, последующие размышления и будущие улучшения

Мы можем получить статистику наихудшего случая, используя электронные адреса @example.com. Эти адреса имеют десятки соответствующих текстовых паролей, что должно значительно снизить скорость нашего взлома.

1576872611661.png

1576872622801.png



Взлом этих хэшей на Intel i5-4460 занял около двух секунд на хэш, что теоретически составляет около 43 000 хэшей в день. На самом деле, большинство адресов электронной почты имеют только несколько паролей, связанных с ними (если таковые имеются), что означает, что процесс будет намного быстрее по сравнению с реальными данными.

Запуск этого скрипта против десятков тысяч наших клиентов занял всего около часа. Общий коэффициент успешности составил около 0.56% - несколько сотен клиентов в нашем случае. Мы предупредили уязвимых клиентов о наших исследованиях и принудительно сбросили пароль после льготного периода.

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

  • Аутентифицированный веб-интерфейс API: Позволяет внутренним службам вашей компании идентифицировать клиентов, пытающихся использовать скомпрометированный пароль. Если ваша база данных поддерживается в актуальном состоянии, это поможет вырубить проблему на корню.
  • Импорт, экспорт и удаление списка нарушений: Предоставить управление данными для различных баз данных и типов файлов. Вы можете включить метаданные и журнал изменений для каждого импорта, что позволит вам отслеживать происхождение учетных данных.
  • Поддержание распространенных типов хэшей и методов «посолки»: Позволит пользователям указывать хэш-функцию (bcrypt, md5 и т.д.), а также положение «соли» в процессе взлома.
  • Параллельное взламывание и повышение эффективности: Процесс взлома не занимает слишком много времени, но его можно улучшить с помощью GPU, многопоточности или интеграции с хэш-памятью.

Профилактика

На сегодняшний день можно утверждать, что лучшая профилактика от credential stuffing - это ее использование:
  • , с уникальным паролем для каждого сайта.
  • 2FA/MFA, для каждого сайта.
Несмотря на то, что это стратегия является высокоэффективной, она все же несет в себе риск того, что все ваши яйца окажутся в одной корзине. Прежде чем брать на себя какие-либо обязательства, было бы полезно потратить время на аудит безопасности каждого менеджера паролей.

Кроме того, я бы порекомендовал следить за своими адресами электронной почты, на функцию "Уведомить меня" (ссылка в верхней части главной страницы). Они будут высылать вам сообщения по электронной почте всякий раз, когда ваш адрес будет связан с дампом данных, и даже будут содержать подробную информацию о том, какого рода информация была раскрыта. Стоит отметить, что многие менеджеры паролей включают эту функцию и могут автоматически запрашивать API HIBP от вашего имени.

Спасибо за внимание!
 
SearcherSlava

SearcherSlava

Red Team
10.06.2017
800
1 075
Статья является переводом. Оригинал вот


Мы знаем, что пароли - отстой.

Если вы этого не понимаете, вбейте в гугл "почему пароли - отстой", и я избавлю вас от нескольких страниц текста.

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

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

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


Введение в Credential stuffing

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

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

Акт кражи учетных данных с одного веб-сайта и попытки их повторного использования на других веб-сайтах в конечном итоге перерастут в так называемую " (с англ. Заполнение учетными данными )". Такие атаки становятся проблематичными, когда используют различные средства защиты, как: двухфакторная или многофакторная аутентификация (2FA / MFA), геолокационное отслеживание и т.д., но даже у них есть свои недостатки (если они вообще есть на веб-сайте).

Согласно , опубликованному издательством Akamai, только в 2018 году было зафиксировано около 30 миллиардов попыток атак типа credential stuffing. Трудно найти постоянный источник успеха атаки, но если даже 1% из этих атак окажутся успешными, мы рассматриваем возможность взлома 300 миллионов аккаунтов. В сочетании с тем, что, по словам Акамая, они , и поэтому у нас серьезная проблема.



Действия хакеров.

Процесс выполнения этих атак прост:
  1. Злоумышленник получает (или создает свой собственный) список валидных комбинаций адресов почты и паролей, полученных при утечке данных. часто распространяются в закрытых сообществах.
  2. Затем злоумышленник использует скрипт или собственное приложение, которое автоматизирует процесс входа с каждой парой учетных данных на различные популярные сайты (Gmail, Facebook, Instagram и т.д.). Иногда они даже автоматизируют процесс размещения вредоносного контента и/или смены пароля аккаунта жертвы, что затрудняет восстановление ее учетной записи.

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



Защита клиента

Хотя компания Datto уже несколько лет предлагает 2FA в качестве опции, растущая популярность атак credential stuffing даёт понять, что мы несём ответственность за соблюдение политики безопасности от имени наших клиентов и конечных пользователей. Ранее в этом году мы объявили о переходе на обязательную политику для всех аккаунтов Партнерского портала (нашей клиентской платформы). Это позволит гарантировать, что даже если пароль клиента окажется вне игры, злоумышленнику все равно придется пройти 2FA, прежде чем он сможет причинить какой-либо вред.

Что, если мы сможем предотвратить атаки credential stuffing, чтобы они стали абсолютно бессмысленными?

Мы придумали несколько идей:

  • Вариант №1: Мы могли бы использовать API (HIBP) для поиска электронной почты и/или паролей наших клиентов.
Но это было быстро исключено по нескольким причинам:

  1. Сопоставление по адресу электронной почты не обязательно означает, что пароль клиента Datto находится в чужих руках.
  2. HIBP API позволяет искать скомпрометированные пароли, если они находятся в открытом тексте, SHA1 или NTLM форме, но Datto хранит их только в виде хэшей.
  3. Нам неудобна идея передачи конфиденциальной информации о данных наших клиентов за пределы офиса.


  • Вариант #2: Мы можем запустить в попытке перебора паролей каждого клиента со списком общих и слабых паролей.
Но это неэффективно по отношению к bcrypt, но, что более важно, это несущественно по отношению к нашим специфическим усилиям по предотвращению credential stuffing. То, что кто-то использует слабый пароль, не обязательно означает, что он был замешан в нарушении данных.


  • Вариант #3: Мы можем просто сделать то, что делают хакеры, получив некоторые учетные данные для взлома данных и попробовав их на нашей собственной странице входа.
Это было бы очень медленно и генерировало бы много ненужного трафика.


Используем гибридный подход

После оценки всех инструментов, имеющихся в нашем распоряжении, мы поняли, что можем использовать как учетные данные для взлома данных, так и хэш-пароль bcrypt клиента, чтобы помочь нам:
  • Создать нашу собственную базу учетных данных на основе популярных утечек. Использовать те же самые списки, которые используют хакеры, чтобы мы могли предотвратить их использование против нас.
  • Найти в базе учетных данных адреса электронной почты клиентов. Поиск адреса электронной почты может дать нулевой или более простой текстовый пароль, связанный с этим адресом.
  • Если мы найдем простой текстовый пароль, сравнить его с хэш-паролем клиента Datto. Если они совпадают, то мы знаем, что клиент рискует быть взломанным. Каждый криптовый хэш включает свою соль, немного упрощая эту часть.
  • Как только уязвимые клиенты будут идентифицированы, уведомить их и принудительно сбросить пароль по истечении льготного периода. Убедится, что они не пытаются повторно использовать один и тот же пароль.
Получение и распаковка популярных баз

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

Посмотреть вложение 36233


Списки были упакованы глубоко в рекурсивном лабиринте сжатия различными способами (tar.gz, zip, rar и т.д.). Я не хранил никаких записей во время этой фазы, но вот что я помню:

Многие имена сжатых файлов использовали пробелы, кавычки или нечетные кодировки, что усложняло работу таких инструментов, как tar/unzip/etc. У меня были некоторые трудности с поиском решения, и мне пришлось переименовать/кодировать некоторые из наиболее проблемных файлов, прежде чем я смог их извлечь.

Для безошибочной распаковки потребовался рабочий каталог объемом около 2 ТБ.

Реальные мандаты хранились в файлах различных типов, включая: txt, csv, sql, sqlite, doc, docx, pdf, xls, xlsx и т.д. Также было много других случайных ненужных файлов (exe, dll, com, jpg и т.д.). К счастью, большинство файлов были txt и csv.


Выдача реквизитов

Так как у меня было всего несколько дней, чтобы закончить этот проект, у меня не было времени проанализировать и переварить каждый отдельный список. Я выбрал подход 80/20.

Я подумал, что, так как большинство файлов были txt и csv, то они, скорее всего, будут содержать учетные данные в шаблоне: <email><delimiter><password or hash>

Скорее всего, это было бы неправильно для таких вещей, как SQL дампы, но я случайно отобрал достаточно файлов, которые придерживались этой формы, что бы не останавливаться на этом шаге.

Используя grep и немного свободного регекса, я рекурсивно извлекал все, что соответствовало вышеуказанному шаблону:

grep -arihE -o '[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,6}[,:;\s].*' ./ > list-1

-a: Обратиться с бинарными файлами как с текстом (помогает исправить несколько ошибок).​
-r: Рекурсивное чтение всех файлов под каждой директорией​
-i: Игнорировать случай​
-h: Сгруппировать имена файлов на выходе​
-E: Расширенный регекс​
-o: Выводить только совпадающие сегменты, а не всю линию​


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

<email><comma|colon|semicolon|space><any number of characters>

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


Нормализация данных

Затем я использовал sed, чтобы осуществить несколько трансформаций: Преобразуйте все двоеточия, точки с запятой и пробелы в запятые для единообразия. Это также приготовит список для импорта в базу данных SQLite.

sed -e "s/[\:\;[[:space:]]/\,/g" -e "s/\,\{2,\}/\,/g" -e "s/\"//g" -e "s/'//g" -e "s/[^[:print:]\n]//g" list-1 > list-2
  • Сложите несколько последовательных запятых в одну запятую. Множество последовательных запятых было основным артефактом первого шага. Обратите внимание, что это также может быть выполнено с помощью: tr -s ','.
  • Удалить двойные и одинарные кавычки. Не спрашивайте, почему я разделил их, я не знаю.
  • Удалите непечатаемые и символы новой строки. Это важно, потому что в противном случае будут тысячи дублирующих друг друга записей, которые различаются только на основе невидимых символов управления.

На данный момент список содержит строки в форме:

<email><comma><a string of text>

Остались две проблемы, обе из которых были решены с помощью awk:

awk -F ',' '{ split($0, a, ","); print tolower(a[1])","a[2] }' list-2 > list-3

  • Разделите строку на массив (используя запятую в качестве разделителя), и конвертируйте адрес электронной почты в нижний регистр. Это помогло свернуть дубликаты записей, предотвратив различное обращение с fake@fake.com,password123 и FAKE@fake.com,password123.
  • Сохраняйте только первый и второй элементы массива, отбрасывая остальные. Это предотвратило ошибки " too many columns " при импорте списка в базу данных SQLite.

После этого любые строки, которые не следовали формату <email><comma><password>, становились для меня искаженными и бесполезными, но, по крайней мере, не вызывали никаких проблем при импорте SQLite. Я также предположил, что письма и пароли сами по себе не содержат запятых, но обнаружил, что сайты очень редко разрешают подобное.

Далее я отсортировал и унифицировал список вывода. Я использовал параметр -T, чтобы установить пользовательскую рабочую директорию, которую я рекомендую в любое время, когда вы думаете, что у вас закончится дисковое пространство (по умолчанию это /tmp на диске операционной системы). Эта операция может занять несколько дней или недель, поэтому лучше всего выполнить ее в screen/tmux или распараллелить каким-либо другим способом:

sort -u -T ./tmp/ list-3 > credentials.csv

Общий размер до нормализации: 816 ГБ
Общий размер после нормализации: 103 ГБ
Общее количество мандатов после нормализации: 3,4 млрд.



Создание базы данных SQLite
Я хотел создать простую схему, которая бы выполнила три вещи:
  • Позволить мне запросить адреса электронных почт как можно быстрее.
  • Предотвратить вставку пустых/неудаленных email’ов или паролей.
  • Предотвращение вставки дубликатов email’ов/паролей.
В конце концов, я остановился на следующем:

SQL:
create table credentials (
    email text not null,
    password text not null,
    constraint uc_credential unique(email, password) on conflict ignore
);

create index credentials_email_index on credentials (email);
Импорт списка учетных данных был так же прост, как:

Код:
sqlite> .mode csv
sqlite> .import ./credentials.csv credentials

Хоть credentials.csv и весил всего 103 Гб, сама база данных SQLite была размером в 396 Гб. Это было в основном результатом индексирования почтового столбца.



Взлом хэшей

Все, что осталось сделать, это запросить базу учетных данных для каждого клиентского email’a и проверить, соответствует ли любой из полученных паролей клиентскому при хэшировании. Библиотека bcrypt на Python делает это тривиальным, предоставляя функцию checkpw, позволяющую проверять обычный текстовый пароль на соответствие заданному хэшу bcrypt.

Весь процесс взлома был выполнен с помощью простого скрипта на Python:

Python:
#!/usr/bin/env python3

import bcrypt
import csv
import sqlite3

db = sqlite3.connect('credentials.sqlite3')
c = db.cursor()

# Assumes csv file formatted as <email>,<hash>
with open('customer-emails-and-hashes.csv', 'r') as csv_file:
  csv_reader = csv.reader(csv_file, delimiter=',')
  next(csv_reader)  # Skip header row

  for row in csv_reader:
    customer_email = row[0].lower()

    if customer_email:
      potential_passwords = []

      for plaintext_password in c.execute('SELECT password FROM credentials WHERE email = ?', (customer_email,)):
        if plaintext_password:
          potential_passwords.append(plaintext_password[0])

      if potential_passwords:
        customer_hash = row[1]

        for plaintext_password in potential_passwords:
          if bcrypt.checkpw(plaintext_password.encode('utf-8'), customer_hash.encode('utf-8')):
            print(f'{customer_email} : {customer_hash} : {plaintext_password}')
            break

db.close()

Окончательные результаты, последующие размышления и будущие улучшения

Мы можем получить статистику наихудшего случая, используя электронные адреса @example.com. Эти адреса имеют десятки соответствующих текстовых паролей, что должно значительно снизить скорость нашего взлома.

Посмотреть вложение 36234
Посмотреть вложение 36235


Взлом этих хэшей на Intel i5-4460 занял около двух секунд на хэш, что теоретически составляет около 43 000 хэшей в день. На самом деле, большинство адресов электронной почты имеют только несколько паролей, связанных с ними (если таковые имеются), что означает, что процесс будет намного быстрее по сравнению с реальными данными.

Запуск этого скрипта против десятков тысяч наших клиентов занял всего около часа. Общий коэффициент успешности составил около 0.56% - несколько сотен клиентов в нашем случае. Мы предупредили уязвимых клиентов о наших исследованиях и принудительно сбросили пароль после льготного периода.

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

  • Аутентифицированный веб-интерфейс API: Позволяет внутренним службам вашей компании идентифицировать клиентов, пытающихся использовать скомпрометированный пароль. Если ваша база данных поддерживается в актуальном состоянии, это поможет вырубить проблему на корню.
  • Импорт, экспорт и удаление списка нарушений: Предоставить управление данными для различных баз данных и типов файлов. Вы можете включить метаданные и журнал изменений для каждого импорта, что позволит вам отслеживать происхождение учетных данных.
  • Поддержание распространенных типов хэшей и методов «посолки»: Позволит пользователям указывать хэш-функцию (bcrypt, md5 и т.д.), а также положение «соли» в процессе взлома.
  • Параллельное взламывание и повышение эффективности: Процесс взлома не занимает слишком много времени, но его можно улучшить с помощью GPU, многопоточности или интеграции с хэш-памятью.

Профилактика

На сегодняшний день можно утверждать, что лучшая профилактика от credential stuffing - это ее использование:
  • , с уникальным паролем для каждого сайта.
  • 2FA/MFA, для каждого сайта.
Несмотря на то, что это стратегия является высокоэффективной, она все же несет в себе риск того, что все ваши яйца окажутся в одной корзине. Прежде чем брать на себя какие-либо обязательства, было бы полезно потратить время на аудит безопасности каждого менеджера паролей.

Кроме того, я бы порекомендовал следить за своими адресами электронной почты, на функцию "Уведомить меня" (ссылка в верхней части главной страницы). Они будут высылать вам сообщения по электронной почте всякий раз, когда ваш адрес будет связан с дампом данных, и даже будут содержать подробную информацию о том, какого рода информация была раскрыта. Стоит отметить, что многие менеджеры паролей включают эту функцию и могут автоматически запрашивать API HIBP от вашего имени.

Спасибо за внимание!
Здрав будь!

Рекомендации правильные. Матрица спрятана за картинкой.

В интернетах пишут: Google хранит информацию о ваших поисках, совершенных вне аккаунта, в течение 180 дней и сохраняет в файлах cookie браузера, включая запросы и нажатые результаты. Ваша история веб-поиска хранится на серверах Google, а потому вы можете просматривать её и управлять ею с любого компьютера, войдя в свой аккаунт Google. В аккаунте хранится информация, связанная с посещенными страницами, в том числе URL-адреса, но не сохраняются снимки экрана. В любой момент временно или навсегда вы можете прекратить хранить в истории веб-поиска свои действия в Интернете или удалить сохраненные элементы.

Что же происходит в аккаунтах в любой/каждый момент времени со времени регистрации, подвергаются ли адреса электронных почт сенсорной депривации на тех самых серверах, на которых хранятся персональные (?) данные, об этом остается только догадываться.

Адрес электронной почты = набор цифр, букв и символов, включая @, это единственное "личное", что физически принадлежит, и то, весьма условно, пользователю, всё остальное принадлежит другим людям с момента регистрации и принятия пользовательского соглашения, которое разработано не в пользу пользователей. Бобра, добра, и хорошего настроения!

 
Последнее редактирование:
  • Нравится
Реакции: avan и g00db0y
Hartwell

Hartwell

Member
16.11.2016
5
3
grep -arihE -o '[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,6}[,:;\s].*' ./ > list-1
1. Пример не включает second level tld к примеру
@outlook.co.uk
cctld лист не маленький
1.1. Адрес почты в целом не может начинаться и заканчиваться на "." о чем прописано в RFC (как вариант \w добавить в начало regexp). Так-же длинна в 64 символа но в целом можно опустить.



2. с grep состарится на неделю можно, почему бы не взять к примеру rip-grep?
Сравнение на 40мб запакованных
Bash:
./ANTIPUBLIC_1:
total 40028
-rwxrwxrwx 1 root root 15169192 Feb  7 02:02 'MYR_(59).txt.zst'
-rwxrwxrwx 1 root root 12544058 Feb  7 02:02 'MYR_(60).txt.zst'
-rwxrwxrwx 1 root root 11533666 Feb  7 02:02 'MYR_(58).txt.zst'
-rwxrwxrwx 1 root root  1735574 Feb  6 19:53 'MYR_(61).txt.zst'

grep gnu 0m2.261s
Bash:
time  grep -arihE -s '[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,6}[,:;\s].*' ./

real    0m2.261s
user    0m2.219s
sys     0m0.047s
rip-grep 0m0.022s (2.261 % 0.022 = 10277.273%)
Bash:
time rg -e "[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,6}[,:;\s].*" -z -q

real    0m0.022s
user    0m0.016s
sys     0m0.031s
 
  • Нравится
Реакции: g00db0y
The Codeby

The Codeby

ООО Кодебай
30.12.2015
3 509
4 937
@Hartwell черный не виден на сером
 
Hartwell

Hartwell

Member
16.11.2016
5
3
@Hartwell черный не виден на сером
сорян, у меня light тема =)

в целом задача решается по мануалу, не превосходно, но вполне годно. + за транслейт

с rip-grep могут быть траблы с memory allocation of 1040187392 bytes failed при распаковки архивов, несмотря на гибкую конфигурацию все же не советую rip-grep с флагом -z (по архивам), запускает кучу процессов распаковки, троллит проц и после kill висят еще процессы unzip пока не завершат распаковку.
Но если все распаковано, справится с задачей минут за 40-60
 
  • Нравится
Реакции: g00db0y
Мы в соцсетях: