Атаки на механизмы авторизации и аутентификации
Классификация по типам проверки подлинности:
- Знание (пароль или ответ на вопрос безопасности, одноразовый код). Факторы знаний.
- Обладание (физический объект - мобильный телефон или маркер безопасности - магнитная карта). Фактор владения.
- Биометрия (персональные данные или модели поведения - конфиденциальная информация). Фактор согласованности.
Механизмы аутентификации уязвимы в случаях:
- Не могут адекватно защитить от атак с применением методов грубой силы.
- Логические ошибки или плохой код в реализации позволяют полностью обойти аутентификацию.
Уязвимости Password-based аутентификации
Для веб-сайтов, использующих процесс входа на основе пароля, пользователи либо сами регистрируются для получения учетной записи, либо администратор присваивает им учетную запись. Эта учетная запись связана с уникальным именем пользователя и секретным паролем, который пользователь вводит в форме входа для аутентификации.
В этом сценарии сам факт знания секретного пароля воспринимается как достаточное доказательство личности пользователя. Следовательно, безопасность сайта будет скомпрометирована, если злоумышленник сможет либо получить, либо угадать учетные данные другого пользователя.
Уязвимости в этом механизме возникают по различным причинам, одни из них:
- Возможные brute-force атаки
- Уязвимая защита от brute-force атак
- HTTP-basic аутентификация
Brute-forcing пользовательских имен
Имена пользователей легко угадать если они соответствуют узнаваемому шаблону, например, адресу электронной почты. Очень часто можно увидеть логины в формате: firstname.lastname@somecompany.com
Иногда высокопривилегированные учетные записи создаются с использованием предсказуемых имен пользователей, таких как admin или administrator.
Brute-forcing паролей
Многие сайты принимают ту или иную форму политики паролей, которая заставляет пользователей создавать пароли с высокой энтропией, которые, по крайней мере, теоритически сложнее взломать одним перебором. Обычно это включает в себя принудительное использование в паролях:
- Минимального количества символов
- Смеси строчных и заглавных букв
- Как минимум одного специального символа
Пользователи часто берут пароль, который они могут запомнить, и пытаются использовать его в соответствие с политикой паролей. Например, если не разрешено использование password, пользователи могут попробовать что-нибудь вроде P@ssw0rd или P4$$w0rd!.
Такое знание предсказуемых закономерностей означает, что атаки с применением грубой силы часто могут быть гораздо более изощренными и, следовательно, более эффективными, чем простые итерации через всевозможные комбинации символов.
Уязвимая защита от brute-force атак
Для успешной компроментации аккаунта, злоумышленнику необходимо провести множество неудачных попыток. Таким образом защита от брут-форс атак строится на замедлении скорости автоматизированных попыток перебора пароля.
Двумя наиболее распространенными способами предотвращения атак полным перебором являются следующие:
- Блокировка учетной записи, к которой удаленный пользователь пытается получить доступ, если он совершает слишком много неудачных попыток входа.
- Блокировка IP-адреса удаленного пользователя, если он делает слишком много попыток входа в систему.
Оба подхода предлагают разную степень защиты, но ни один из них не является неуязвимым, особенно если он реализуется с использованием ошибочной логики.
В некоторых реализациях счетчик количества неудачных попыток сбрасывается при успешном входе владельца IP-адреса. Это означает, что злоумышленнику просто придется входить в систему под своей учетной записью каждые несколько попыток, чтобы этот лимит никогда не был достигнут.
В этом случае достаточно просто включать свои собственные учетные данные для входа в систему через регулярные интервалы времени в течение перебора всего словаря, чтобы сделать эту защиту практически бесполезной.
Basic-аутентификация HTTP
Несмотря на старость метода, ее часто используют.
При базовой HTTP-аутентификации клиент получает от сервера маркер аутентификации, который строится путем сцепления имени пользователя и пароля, а также их кодировки в Base64. Этот токен хранится и управляется браузером, который автоматически добавляет его в заголовок авторизации каждого последующего запроса следующим образом:
Не считается безопасным в связи:
- Включает многократную отправку учетных данных при каждом запросе. Если на веб-сайте также не реализована HSTS, учетные данные пользователя могут быть перехвачены в ходе атаки типа Man-in-the-Middle (человек посередине).
- Часто не поддерживает защиту от переборов грубой силы. Поскольку токен состоит из статических значений.
- Особенно уязвима к атакам, связанным с сеансом, в частности к CSRF, от которых она сама по себе не обеспечивает никакой защиты.
В некоторых случаях использование уязвимой базовой HTTP-аутентификации может дать злоумышленнику доступ только к, казалось бы, неинтересной странице. Однако, в дополнение к обеспечению дополнительной поверхности атаки, учетные данные, раскрытые таким образом, могут быть повторно использованы в других, более конфиденциальных контекстах.
Уязвимости мультифакторной аутентификации
Проверка биометрических факторов является непрактичной для большинства веб сайтов. Чаще встречается обязательная и необязательная двухфакторная аутентификация (2FA).
Все преимущества многофакторной аутентификации достигаются только путем проверки множества различных факторов. Проверка одного и того же фактора двумя разными способами не является истинной двухфакторной аутентификацией.
Одним из таких примеров является 2FA через электронную почту. Хотя пользователь должен предоставить пароль и проверочный код, доступ к коду предполагается на основе того, что пользователь знает учетные данные для входа в свою учетную запись электронной почты. Поэтому фактор проверки подлинности знания просто проверяется дважды.
Обход двухфакторной аутентификации возможен по разным причинам:
- Иногда реализация двухфакторной аутентификации бывает настолько несовершенной, что ее можно обойти полностью.
- Иногда ошибочная логика двухфакторной аутентификации означает, что после того, как пользователь выполнил начальный шаг входа в систему, веб-сайт не может адекватно проверить, что этот же пользователь выполняет второй шаг.
- А также, как и в случае с паролями, веб-сайты должны принимать меры по предотвращению перебора проверочного кода 2FA. Это особенно важно, потому что код часто представляет собой простое 4-х или 6-значное число. Без адекватной защиты взлом такого кода тривиален.
Уязвимости механизмов смены пароля, восстановления пароля, поддержания сессии
В дополнение к базовой функциональности входа в систему, большинство сайтов предоставляют дополнительные функциональные возможности, позволяющие пользователям управлять своей учетной записью. Например, пользователи обычно могут изменить свой пароль или сбросить его, когда они его забудут. Эти механизмы также могут добавлять уязвимости, которые могут быть использованы злоумышленником.
Веб-сайты, как правило, стараются избежать известных уязвимостей на своих страницах входа. Однако легко упустить из виду тот факт, что необходимо предпринять аналогичные шаги, чтобы убедиться в том, что связанная с ними функциональность не менее надежна. Это особенно важно в тех случаях, когда злоумышленник может создать свою учетную запись и, следовательно, имеет легкий доступ к изучению этих дополнительных страниц.
Сторонние механизмы аутентификации, которые также могут быть уязвимы:
- Механизм поддержания сессии «запомнить меня»
- Механизм сброса пароля через E-mail
- Механизм сброса пароля с использованием URL и одноразового токена
- Механизм смены пароля