Что такое атака перечислением и чем она опасна

Недавно наши эксперты из Kaspersky Blockchain Security проверяли блокчейн-платформу на наличие уязвимостей.  В процессе они обнаружили, что механизм восстановления забытого пароля их веб-приложения уязвим к атаке перечислением пользовательских имен. Мы решили, что это неплохой повод рассказать в нашем блоге, что это за атака и чем она опасна.

Что значит атака перечислением

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

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

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

Чем опасна атака перечислением имени пользователя

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

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

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

Как защититься от атаки перечислением?

Вы когда-нибудь обращали внимание, как современные сервисы реагируют на форму сброса пароля? Они не говорят: «Ссылка на сброс пароля выслана на почту» или «Введенной почты нет в базе», как это происходило раньше. Вместо этого они пишут: «Если ваш адрес есть в базе, то на него будет выслано письмо со ссылкой…». То есть прямо не подтверждают и не опровергают наличие такого имени пользователя. Это делается именно для того, чтобы защититься от атаки перечислением.

Точно так же и в окне логина никогда не нужно детально объяснять «неверный пароль» или «нет такого имени пользователя». Просто — пара логин/пароль не найдена. Да, с точки зрения UX-специалиста такие ответы не оптимальны. Они могут вызывать недовольство пользователя (меня, например, ужасно бесит, когда я забываю, при помощи какого адреса регистрировался, а сервис мне не подсказывает). Но безопасность практически всегда достигается в ущерб удобству. И в случае с сервисами авторизации небольшой перекос баланса в сторону безопасности оправдан.

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