Вступление

Credential Stuffing - это своеобразная атака на веб-приложения. Технически это очень простая и легкая для понимания атака, тесно связанная с методами грубой силы, но она пугающе эффективна. Более того, администраторы и сотрудники службы безопасности иногда не считают эту атаку нарушением безопасности! И даже хуже, потому что эта атака нацелена на отдельных пользователей, а не на приложение или основной бизнес, по крайней мере, не напрямую. Вывод прост: когда атака с заполнением учетных данных относительно небольшая, у организации может не быть достаточной мотивации, чтобы действовать соответствующим образом.

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

Как это сделано?

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

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

  • Учетные данные
    Злоумышленник должен иметь доступ к списку утечек учетных данных (это основное различие между заполнением учетных данных и их взломом). Списки просочившихся учетных данных содержат пары имя пользователя-пароль или адрес электронной почты-пароль. Эти списки называются в сообществах взлома «комбинированными списками» или «комбо». Самыми ценными являются только что просочившиеся комбо. Некоторые из комбинаций легко найти, но обычно ценные из них продаются или предлагаются в закрытых сообществах взломщиков. Довольно распространенная схема: база учетных данных украдена и расшифрована опытным злоумышленником. Затем учетные данные продаются или выдаются в зависимости от мотивации менее опытным злоумышленникам, которые выполняют заполнение учетных данных в веб-приложениях по своему выбору.
  • Автоматизация
    Проверка огромных комбинированных списков требует автоматизации, вам нужна программа, которая будет проверять все учетные данные на соответствие приложению и определять правильные. Иногда программному обеспечению требуется возможность обхода защиты с помощью капчи или других механизмов безопасности. Нередко «желающим взломать» не хватает знаний о том, как писать собственное программное обеспечение или даже о том, как расширить существующие инструменты взлома. Таким образом, такие расширения, предназначенные для конкретного веб-приложения, также предлагаются на «черном рынке» более опытными взломщиками, одни бесплатно, а другие можно легко купить. Подробнее о рынке взлома я опишу позже.
  • Распараллеливание и анонимность
    Когда вы выполняете попытки входа в систему или просто отправляете большое количество запросов с одного компьютера на сервер, легко привлечь внимание. Взломщики используют списки прокси и зомби-компьютеров для выполнения попыток входа с этих машин. Во-первых, это позволяет им распараллеливать процесс проверки учетных записей, а также скрывает их IP-адрес, обеспечивая некоторую анонимность. Часто использование прокси-серверов является требованием для достижения автоматизации - многие веб-приложения отслеживают IP-адреса и обнаруживают многочисленные попытки входа в систему с одного компьютера.

Как рождаются крекеры?

Многие из техник и руководств по взлому доступны в обычном Интернете. Twitter и Youtube полны руководств и советов по вводу учетных данных. Будем надеяться, что эффективные и те, которые показывают успешный взлом, довольно быстро удаляются с YouTube. Чтобы дать вам представление о сообществах и методах взлома учетных данных, давайте взглянем на несколько видеоуроков. Необязательно смотреть их в деталях, просто беглый взгляд может дать вам хорошее представление о сообществе и методах, подобных сценариям.

На момент написания статьи у нее было 31 тысяча просмотров и 27 комментариев. В этом руководстве описывается установка SentryMBA, знакомство с «конфигами», которые представляют собой расширения / конфигурации, позволяющие атаковать конкретный веб-сайт. Затем они рассказывают, как использовать прокси, и рекламируют свои предложения в платных конфигурациях и списках прокси. После этого в руководстве показано, как загрузить эти файлы в SentryMBA. Для атаки они использовали 156 прокси с примерным количеством ботов 50. Видео показывает атаку и заканчивается без «попаданий», что означает, что действительные учетные данные не были найдены. Это видео не слишком техническое и пытается продвигать платные товары, предлагаемые сообществом.

с 58 тысячами просмотров и 87 комментариями - еще одна презентация SentryMBA. В нем показано, как использовать функцию «Волшебная палочка» для создания базовой конфигурации входа. Он также показывает функцию «анализа страницы входа в систему», которая пытается автоматически исследовать механизм входа в систему и в идеальном сценарии создает готовую к использованию конфигурацию. В этом случае инструмент создал HTTP POST с необходимыми полями данных. Кроме того, в руководстве кратко показано использование функции обновления файлов cookie, которая также требуется для попытки входа в систему (она захватывает идентификатор текущего сеанса). Затем определяются ключи неудачи и успеха. Ключи - это просто слова или регулярные выражения, которые SentryMBA использует для проверки ответа от приложения. Когда в ответе найден ключ, SentryMBA помечает комбинацию как успешную (попадание) или неудачную. Затем программа настраивается на выполнение перенаправлений HTTP, которые, по-видимому, также необходимы для автоматизации процесса входа в систему в этом случае. Затем злоумышленник проверяет, как работает взлом, без использования прокси! Программа выполнила более 1000 попыток входа в систему с одного IP-адреса, и веб-приложение по-прежнему не блокировало адрес. Злоумышленник пришел к выводу, что можно продолжить работу без использования прокси. На следующих этапах целью взломщика было проверить после успешного входа в систему, есть ли у взломанной учетной записи положительный баланс на счете. Видео заканчивается запуском процедуры взлома с использованием 50 ботов и без прокси. В этом видео показаны еще несколько интересных опций SentryMBA (которые все еще очень просты, если смотреть с точки зрения уровня HTTP и виртуального браузера).

аналогичного видео, где злоумышленник пытается войти в сеть PlayStation Network, набрав 16 тысяч просмотров и 70 комментариев. Я не буду описывать это видео, поскольку оно очень похоже на предыдущие видео.

Есть по крайней мере сотни других видеороликов о SentryMBA и других инструментах для взлома. SentryMBA устарел, но кажется, что он по-прежнему остается самым популярным инструментом. Хотя есть и более новые программы, которые делают очень похожие вещи. Они предлагают лучшую стабильность и более интуитивно понятный текстовый интерфейс конфигурации. Самым популярным в настоящее время является SNIPR, учебник от одного сообщества также доступен на YouTube.

STORM - еще один популярный инструмент с доступными учебными пособиями.

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

Как вы, наверное, заметили, эти видеоуроки низкого качества. Большинство из них созданы именно так - подростком, на компьютере с Windows, с некоторыми значками игр на рабочем столе и т. Д. Некоторые из них действительно сложно смотреть. Популярные направления атак, которые я наблюдал, похоже, каким-то образом отражают широкое сообщество взломщиков сценариев: игровые платформы (Steam, Minecraft, PSN и т. Spotify), доставка еды (Dominos Pizza), а также Skype и Paypal. Хотя я должен упомянуть, что все на их радарах, одни векторы кажутся более популярными, чем другие.

Каталог инструментов

Спектр доступных инструментов невелик, ограничены те, которые продвигаются на форумах и популярные:

  • SentryMBA
  • ГРОЗА
  • Снайпер

Я наткнулся на еще несколько имен, но не так много. В дистрибутив Backtrack Linux входит программное обеспечение Hydra / Medusa, но это программное обеспечение довольно старое и настолько примитивное, что анализировать его не имеет смысла. Возможно, есть некоторые другие инструменты, которые не используются или неизвестны в основных сообществах взломщиков, и их трудно достать. Но, в конце концов, взломщик с хорошими навыками программирования в любом случае напишет свой собственный инструмент ... Итак, это каталог инструментов, который я расскажу.

SentryMBA

Несмотря на то, что он довольно старый, SentryMBA по-прежнему остается самым популярным инструментом для ввода учетных данных. Если вы смотрели видео, которые я включил, вы уже имеете представление о программном обеспечении. Багги, плохо написанные, но со всеми необходимыми функциями. Я не буду описывать это подробно, поскольку существует множество описаний, подготовленных исследователями кибербезопасности. Хотя вы можете просто продолжить и установить программное обеспечение в безопасной среде. Однако, если вы ищете отчет, мне понравился Danna Thee report from cyberint, он охватывает все основы.

ГРОЗА

Как я уже упоминал, программное обеспечение для заполнения учетных данных состоит из самого программного обеспечения и конфигурации. Программное обеспечение представляет собой основу для отправки запросов к веб-приложению, но для настройки таргетинга на конкретный веб-сайт требуется конфигурация или расширения. Но это разделение неплохо - иначе для каждого веб-сайта должна была бы быть одна программа. Storm разделил эти функции и поставляется с двумя программами. Один из них - создатель конфигурации, где вы можете создавать конфигурации в пользовательском интерфейсе. Конфигурация представляет собой просто текстовый файл, в котором вы можете определять шаблоны для запросов, определять переменные и поведение. Он логично разделен на этапы. Мне было трудно найти документацию к этому инструменту, а может быть, она вообще недоступна. Чтобы понять некоторые функции, мне пришлось провести небольшой реверс-инжиниринг. По этой причине я не хочу включать подробное описание, но вы можете легко найти конфигурации Storm и изучить синтаксис, прочитав их. Другая часть программного обеспечения - это программа для заполнения учетных данных STORM. Он позволяет вам определять количество потоков, загружать комбинированные списки и списки прокси, что очень похоже на SentryMBA. Из-за наличия полностью текстовых файлов конфигурации я считаю эту программу более зрелой и простой в использовании. Хотя у SentryMBA есть некоторые функции, которые, похоже, отсутствуют в Storm.

Снайпер

Snipr - последнее дополнение к сообществу. Он обеспечивает большую интеграцию с сообществом (аналогично проектам с открытым исходным кодом) и поставляется со встроенными конфигурациями, скребками прокси и т. Д. Стабильность и производительность, похоже, значительно улучшены по сравнению с SentryMBA. Похоже, что Snipr обеспечивает все функции STORM и SentryMBA. Хакеры могут писать плагины, а затем распространять и продавать их на этой платформе. Обычно скрипач должен искать комбо-списки, затем очищать некоторые прокси-списки, а затем находить или покупать «конфигурацию» для определенного веб-сайта. Здесь все эти шаги красиво интегрированы в одну платформу, и оплата осуществляется легко. Инструмент также предлагает бесплатные плагины для некоторых веб-приложений, но имеет интегрированный платный рынок. Это очень опасно, поскольку создает общий рынок для обмена знаниями. Это означает меньше работы для скрипачей и побуждает более опытных хакеров создавать и продавать «конфигурации» - умнее. К счастью, в 2019 году получить этот инструмент бесплатно будет сложно, по крайней мере, для меня.

Почему это до сих пор происходит?

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

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

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

Вы хотите, чтобы он был надежным, поэтому вы создаете прочную входную дверь. Представим себе, что на дверях есть множество различных умных замков, защищающих от различных воровских техник (SQLInjection, CSRF, XSS и перехват sessionId).

Также каждому человеку присваивается специальный, индивидуально присваиваемый ПИН-код. Вы тратите много усилий, обучая своих строителей строить правильные двери, чтобы защитить свои квартиры. Вы нанимаете профессиональных слесарей (пентестеров) для проверки ваших дверей и выявления слабых мест.

Затем вы раздаете ключи всем локаторам и предоставляете средства для распространения ключей новым локаторам. И вы наблюдаете, как люди пользуются дверьми. Большинство из них открывают двери с первой попытки, у некоторых возникают проблемы с правильной вставкой ключа, поэтому они входят со второй или третьей попытки. Время от времени кто-то терял ключи, поэтому вы дарите им новые. Ничего особенного.

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

Вот что происходит при заполнении учетных данных. И такая сетевая активность иногда игнорируется, особенно если она небольшая. Это почему?

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

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

Обнаружение

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

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

Следы инструментов

Давайте начнем с возврата к инструментам взлома, описанным ранее. Конфигурации были исправлены. Как это переводится в HTTP-запрос? Ну, запрос постоянный, меняются только специально настроенные поля типа username, password, sessionid. Распознаются ли HTTP-запросы, генерируемые инструментами? Смотря как. SentryMBA поставляется с конфигурацией по умолчанию, которая редко меняется, и след легко распознать по строкам пользовательского агента (UAS). Мы можем просто искать шаблоны в строках входящих запросов и помечать запросы на основе этого. При таком подходе мы угрожаем нашим шаблонам, как антивирусная база данных.

Это очень простой прием, который рекомендуется в некоторых статьях - занесение определенных шаблонов в черный список. Но этот подход примитивен и его очень легко обойти злоумышленникам - им достаточно будет немного изменить запрос. Кроме того, такие инструменты, как Snipr и STORM, не имеют предопределенной конфигурации. Итак, допустим, мы можем взглянуть на существующие конфигурации, доступные на рынке. Их анализ даст нам хорошую библиотеку используемых UAS и других характерных паттернов. С централизованным рынком Snipr мы могли бы довольно легко получить доступ к конфигурациям, используя биткойны. В итоге мы получим список HTTP-запросов, используемых инструментами, и их конфигураций. Такой список необходимо обновлять и поддерживать. Не очень удобно. Кроме того, злоумышленники всегда могут изменить предварительно настроенные строки на что-то по своему выбору, что сделает весь черный список неэффективным.

Геолокация, IP-адреса

Атака с заполнением учетных данных выполняется либо с одного IP-адреса, либо с прокси-серверов, то есть с нескольких IP-адресов. Анализ происхождения IP-адресов и шаблонов трафика на IP может дать четкое указание на то, что атака выполнена.
Если взлом осуществляется с одного IP-адреса, количество попыток входа с одного IP-адреса будет легко видно. Хотя бывают ситуации, когда за одним IP-адресом находится много пользователей. В этом случае анализ должен быть усилен отслеживанием идентификаторов сеансов или пониманием поведения пользователей / ботов. Я расскажу об этом чуть позже.
Когда взлом выполняется с нескольких IP-адресов, то есть с использованием прокси-сервисов, мы можем попробовать вычесть геолокацию IP-адресов. Эту информацию можно использовать для поиска аномалий - например, если мы знаем, что 90% нашего трафика поступает из Франции, и внезапно мы получаем огромное количество попыток входа в систему из США и нескольких стран Азии, мы можем подозревать с хорошей стороны вероятность атаки с заполнением учетных данных. Есть также сервисы, которые пытаются поддерживать актуальные списки прокси, хотя я не знаю, насколько они эффективны. Другие пытаются обнаружить использование прокси, проверяя задержки ping / traceroute и другие характеристики. Хотя важно отметить, что законный пользователь также может использовать прокси. Информация об использовании прокси сама по себе ничего не значит.
Таким образом, геолокация добавляет ценное измерение для обнаружения заполнения учетных данных, особенно для веб-приложений, работающих локально в определенном регионе.

Используемые учетные данные

Утечка учетных данных - топливо для вброса учетных данных. Взломщики могут получить их, так что защитники тоже должны их получить. Они публикуются на форумах, в чатах, продаются, открыто публикуются на некоторых сервисах. Конечно, для компании сложнее получить определенные данные, и идея платить хакерам за утечку данных… ошибочна. Кроме того, сохранение утекших учетных данных - это не то, что вы хотели бы делать из соображений безопасности, морали и законности. Но вместо этого вы можете сохранить, например, хеши имен пользователей и паролей. Как мы можем использовать такую ​​информацию? Что ж, если нам удастся собрать базу данных хэшей просочившихся учетных данных, мы сможем проверять каждую попытку входа в систему с такой базой данных. Очевидно, что поиск совпадения в базе данных не является прямым признаком того, что происходит заполнение учетных данных, вам нужно будет соотнести такие события с более широким контекстом. Наличие единственного совпадения в базе данных может просто означать, что единственный законный пользователь вошел в систему со своими учетными данными, которые были украдены. В реальных сценариях вы получите много совпадений с популярными паролями, такими как «12345», «qwerty123» и т. Д. Эта идея очень похожа на отслеживание инструментов в том смысле, что мы пытаемся собрать те же данные, что и взломщики. доступ к этим данным и их использование для пометки или занесения в черный список определенных шаблонов трафика. Такой подход сопряжен с теми же неудобствами: вам придется искать данные и поддерживать базу данных в актуальном состоянии. Обычно взломщики пытаются использовать новейшие наборы учетных данных. Кроме того, они изменяют строки имени пользователя и пароля, добавляя префиксы и суффиксы и другие преобразования. На самом деле существует несколько довольно популярных программ, которые они используют для этой цели. Поскольку вы хотите работать с хэшами, а не с полными учетными данными, обнаружение таких вариаций строк очень сложно.

Обнаружение ботов

Обнаружение ботов - это гораздо более широкая тема, чем просто набивка учетных данных. Наличие высокопроизводительного обнаружения ботов остановит большинство автоматических атак. Проблема просто в том, что обнаружить умных ботов очень сложно, а также есть много хороших ботов, которых вы не хотите блокировать. А еще у нас есть вызовы API и системы, взаимодействующие друг с другом, которые можно легко квалифицировать как ботов… Тема обширна. Но для заполнения учетных данных, когда мы рассматриваем аутентификацию человека, то есть через веб-страницу, мы можем думать о методах обнаружения ботов. С авторизацией через API становится все сложнее, поэтому я буду говорить только о входе пользователя в систему на основе пользовательского интерфейса.
В зависимости от того, где будет располагаться программное обеспечение защиты, существует множество способов. От отслеживания движения курсора (новейшие капчи «Я не робот») до подробной проверки браузера и более простых методов, таких как проверка, поддерживает ли клиентское устройство JavaScript или файлы cookie. Даже довольно простые проверки будут эффективны против большинства «конфигураций» SentryMBA. Однако проблема в том, что инструменты имеют тенденцию развиваться вместе с методами защиты. Когда взломщики начнут использовать новые расширения или развернут технологию «браузер в памяти», чтобы обойти такую ​​защиту, это будет вопрос времени. Тем не менее, использование некоторых методов создает больше трудностей для взломщиков, и многие скрипачи могут быть обескуражены.
Другой способ - взглянуть на автоматизацию, повторяемость ботов. Если посмотреть на метрики, связанные со временем, автоматические атаки могут иметь отличительную схему, отличную от той, которую создают люди. Чтобы наблюдать такой сигнал, вам необходимо сопоставить эту информацию с IP-адресами, идентификаторами сеансов, UAS или другими характеристиками запросов.

Заголовок HTTP

Заголовок HTTP содержит множество данных, которые можно использовать для поиска аномалий.
Заголовки можно проверить на соответствие стандарту. Поскольку запросы создаются взломщиками вручную, иногда они вносят несоответствия, например, они могут установить версию протокола HTTP на 1.0 и определить несуществующий заголовок If-None-Match Cache, который был добавлен в версию протокола HTTP 1.1. Это привело бы к несогласованности протокола. Или они пропустили бы некоторые популярные заголовки только потому, что они не нужны. Хотя такая реализация потребует много времени и не будет новаторской, давайте посмотрим, что еще мы можем сделать.
Строка пользовательского агента очень интересна. Как уже упоминалось в разделе об инструментах, их можно использовать для анализа. Во время автоматизированной атаки злоумышленник будет использовать постоянное количество строк пользовательского агента или сгенерировать их из шаблона (при сложной атаке большинство использует только один пользовательский агент или фиксированный список пользовательских агентов). Что вы можете попробовать сделать, так это найти аномалии в распределении пользовательских агентов. UAS можно токенизировать, а затем кластеризовать по некоторой метрике. Выполнение такой кластеризации может выявить аномальные UAS: Обнаружение вредоносных программ с использованием идентификации несоответствия пользовательского агента HTTP, Обнаружение аномалий в строках пользовательского агента. Такой анализ затем можно было бы дополнительно улучшить с помощью анализа, основанного на времени. Этот метод также используется для обнаружения вредоносных программ в сетях, хотя эта область кажется более сложной, чем заполнение учетных данных (из-за использования SSL и распределения по сетевым узлам).
Подобно UAS, анализ может выполняться на URL-адресах и других строках , хотя анализ URL-адресов был бы более целесообразным для атак со стороны парсинга данных и сканирования уязвимостей.

Анализ по времени

Хотя я уже упоминал, что в разделе об обнаружении ботов это может быть ценным индикатором. Большинство атак с заполнением учетных данных или, по крайней мере, те, которые выполняются детскими скриптами, наводняют приложение постоянным, повторяющимся потоком запросов. Сигнал очень сильный, особенно когда генерируемый трафик значительный. Существует множество методов, которые можно использовать: статистические, такие как ARIMA, стандартные методы, такие как k-means, SVM, STL или использование нейронных сетей, например, LSTM - Сети с долгосрочной краткосрочной памятью для обнаружения аномалий во временных рядах. Как всегда в науке о данных, вам нужны надежные данные для оценки вашей модели и проверки ее производительности.

Попытки входа

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

Анализ поведения пользователей

UBA считается очень эффективным при правильной реализации. В аналогии, которую я представил ранее, с людьми, ожидающими в очереди, пытающимися открыть двери - это то, что делает наш разум. Мы анализируем поведение этих людей и классифицируем их как подозрительные, основываясь на наших знаниях о поведении людей и понимании того, что такое дверь и ключ.
Хотя UBA можно делать на низком уровне, что мне особенно нравится в этом подходе , заключается в том, что UBA позволяет нам подняться с уровня HTTP и взглянуть на трафик и базовые действия с более высокой точки зрения, особенно с точки зрения бизнес-контекста приложения. Это, безусловно, ценно для атак, таких как отказ в инвентаризации, скальпирование, снайперская охота или экспедиция. UBA также может быть очень полезен для отделов маркетинга и UX, и часто такой анализ существует внутри компании, но по другим причинам, чем безопасность (автоматизация маркетинга, Hotjar и подобное программное обеспечение).
Чтобы анализ был возможен, вам понадобится возможность вычитать действия, выполняемые пользователем, просматривая журналы. Есть архитектуры, которые охватывают эту концепцию. Ярким примером может служить шаблон EventSourcing и другие архитектуры на основе сообщений. Иногда для этой цели идеально подходят простые журналы аудита. В качестве альтернативы, если система будет развернута внутри, приложение может генерировать соответствующие события более высокого уровня абстракции. Или, если мы рассматриваем отдельное приложение, система обнаружения может быть тесно интегрирована в веб-фреймворк, обеспечивая бесшовную интеграцию и минимальный объем необходимой конфигурации (для этого потребуются изменения кода и разработка на стороне приложения - ничего бесплатно). С возможностью декодирования действий в рамках пользовательского сеанса следующим шагом будет различать обычное поведение пользователя и аномальное. При выборе алгоритмов можно сделать множество предположений, одно из наиболее часто повторяемых предположений состоит в том, что злонамеренное поведение будет редкостью. Но это не обязательно относится к некоторым приложениям, особенно к веб-сайтам, выходящим в Интернет. Здесь могут быть развернуты нейронные сети, отражающие сложные шаблоны. Но возможны и более простые подходы - например, можно определить набор подозрительных и вредоносных действий и по таким шаблонам можно отслеживать активность пользователей. Что касается реализации, то на ум приходят сопоставления с образцом, деревья решений, системы на основе правил или графов.

Зная свою систему

Это не конкретный метод и не сильно связан с заполнением учетных данных, но я хотел включить эту идею, поскольку она очень эффективна. Для защиты используйте информацию, которой нет у злоумышленников. Вы знаете свой трафик, вы можете извлечь из него интересную информацию. Когда дело доходит до HTTP, у вас есть довольно много данных, которые нелегко получить злоумышленнику. Например, вы знаете, каково распределение типов браузеров, операционных систем, стран и языков в вашем трафике. Другие интересные области могут включать SQL-запросы к вашей базе данных или распределения URL-адресов и многое другое. Вы можете изучить такие особенности и создать временные тренды. Постарайтесь понять и изучить свой трафик, используйте это преимущество перед злоумышленником. Просто будьте осторожны - убедитесь, что вы учитесь, когда система здорова и «нормальна». Для некоторых систем добиться этого крайне сложно (по оценкам отчетов ~ 50% или даже больше всего трафика веб-сайтов не является человеческим).

Я надеюсь, что вы нашли представленные перспективы информативными и что они могут дать множество идей для системы обнаружения. Выбор подходящего варианта, а затем его адаптация к существующим системам и приложениям может оказаться сложной задачей. Кроме того, как и в случае со всеми проектами в области науки о данных, такую ​​систему следует проверять на основе данных: чем больше данных, тем лучше может стать система.

Случайные замечания

Если система обнаружения будет использовать подход машинного обучения, важно понимать, как можно отравить систему машинного обучения. Уже разрабатываются методы, позволяющие обмануть систему машинного обучения (Объяснение и использование состязательных примеров, Атаки на безопасность: анализ моделей машинного обучения). Об этом хорошо помнить при проектировании системы.

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

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

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

Заполнение учетных данных иногда определяется как массовая попытка входа в систему в течение определенного периода времени. Но так бывает не всегда. Злоумышленники знают, что создание большого количества запросов на вход за короткий промежуток времени может привлечь внимание. Таким образом, они проводят медленную, незаметную для глаз атаку по подбору учетных данных. Пара запросов на час, может быть, всего пару в день. Они также использовали поддельные учетные записи и входили в них со второй попытки и выполняли неожиданные действия, маскируясь под обычных пользователей. Все эти сценарии заслуживают размышления. С другой стороны, даже если у вас есть система, способная обнаруживать классическое заполнение учетных данных, это уже очень ценно. На этот раз все не очень мотивированные сценаристы отправятся куда-нибудь еще - возможность проверять 20 учетных данных ежедневно, когда у вас есть 10000 учетных данных в вашем комбинированном списке, займет больше года, вероятно, не время, когда подросток готов ждать. Но даже для профессиональных взломщиков возможность значительно замедлить ввод учетных данных дает защитникам преимущество. Год на перечисление паролей, есть более высокая вероятность, что пользователи изменят свои пароли, сделав утечку учетных данных устаревшими.

Заключительные мысли

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

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

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

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