5 методов обхода аутентификации
Этичный Хакер
Уязвимости обхода аутентификации являются довольно распространенными недостатками в современных веб-приложениях, но их не всегда легко найти.
Новые методы аутентификации творят чудеса, повышая кибербезопасность во многих организациях. И хоть такие инструменты, как single sign-on (SSO) зачастую являются лучше, чем старые способы входа пользователей в систему, эти технологии все еще могут содержать критические уязвимости. Будь то ошибки бизнес-логики или какой-то другой недостаток программного обеспечения, требуется острый глаз, чтобы как следует в этом разобраться.
Пример №1 – Неправильная конфигурация конечной точки для обновления токена
В этом случае, как только пользователь вошел в приложение с действительными учетными данными, он создал Bearer Authentication токен, используемый в приложении. Этот токен авторизации истекает через некоторое время. Непосредственно перед истечением срока действия приложение отправляет на /refresh/tokenlogin запрос, содержащий действительный токен аутентификации в заголовках и параметре username в теле HTTP запроса.
Дальнейшее тестирование показало, что удаление заголовка Authorization в запросе и изменение параметра username создали новый валидный токен для предоставленного имени пользователя. Используя этот эксплойт, злоумышленник с анонимным профилем может сгенерировать токен аутентификации для любого пользователя, просто указав его имя пользователя.
Пример №2 – Неправильная конфигурация SSO
Большинство приложений используют системы SSO, поскольку ими проще безопасно управлять, чем манипулировать множеством порталов аутентификации. Но простое использование SSO не обеспечивает автоматическую защиту системы: конфигурации SSO также должны быть защищены.
Здесь одно приложение использовало Microsoft SSO для аутентификации. При посещении internal.redacted.com , веб-браузер сделал перенаправление на SSO:
На первый взгляд это казалось безопасным, но анализ внутренних запросов показал, что приложение вернуло необычно большую длину содержимого (более 40000 байт!) в ответе с перенаправлением.
Зачем приложению делать это? Ну, оно было неправильно сконфигурировано. Приложение сливало свои внутренние ответы на каждый запрос, отправляя пользователя на перенаправление в SSO. Таким образом, можно было подделать ответ и изменить заголовок 302 Found на 200 OK, а также удалить весь заголовок Location, предоставив доступ ко всему приложению.
Кроме того, можно было сделать этот процесс автоматическим, добавив правила Match & Replace в Burp Suite для непосредственного удаления заголовка и автоматического изменения значений.
Пример №3 – Проблемы с доступом в CMS
Системы управления контентом (CMS), такие как WordPress, Drupal и Hubspot, также должны быть надежно настроены, чтобы они не создавали уязвимостей в вашей организации.
В одном из исследуемом мной случае использовалась платформа, под названием Liferay. Приложение имело только одну страницу входа, доступную без аутентификации, а все остальные страницы были ограничены в пользовательском интерфейсе приложения.
Для тех, кто не знаком с Liferay, данная CMS использует портлеты, которые имеют параметр типа p_p_id с числовым значением. Для этого приложения можно было получить доступ к портлету входа в систему, изменив параметр на значение 58. На обычной странице входа в систему была доступна только форма входа в систему. Однако, получив прямой доступ к портлету, можно было получить доступ к функциям создания учетной записи, которые затем позволяли самостоятельно регистрироваться для доступа к внутренним приложениям без надлежащей авторизации.
Обратите внимание, что, хотя Liferay и использовал этот рабочий процесс ранее, в его последней версии вместо числовых идентификаторов используются имена портлетов. Тем не менее, можно получить доступ к другим портлетам, также изменив имена.
Пример №4 – Использование JWT токенов из примеров
Токены JWT, или JSON web tokens, популярны в новых веб-приложениях. И хотя по умолчанию у них есть защищенный механизм, конфигурация внутреннего сервера также должна быть защищена.
Я работал над заданием, в котором аутентификация SSO использовалась для их внутренних приложений. При непосредственном посещении приложение перенаправляет пользователя на веб-страницу Microsoft SSO. Пока всё идет так, всё хорошо.
Однако некоторые JS-файлы были доступны без проверки подлинности. Тестирование показало, что приложение использовало токены JWT, которые были отправлены через систему Microsoft SSO после безопасного входа в систему. В серверном механизме произошла неправильная настройка безопасности, которая не проверяла, был ли сгенерирован токен JWT для этого конкретного приложения – вместо этого он принимал любой токен JWT, который имел действительную подпись. Итак, используя пример токена JWT с веб-сайта Microsoft:
С общими значениями:
Стало возможным получить доступ к внутренним конечным точкам, сливающим данные компании.
Пример №5 – Изменение типа аутентификации на ноль
В этом случае приложение отправляло все запросы методом POST через XML-запросы в кодировке base64. В механизме входа в систему оно отправляло имя пользователя в параметре alias и пароль в параметре scode. Значение внутри параметра scode было хэшировано. Быстрый анализ показал, что приложение использовало md5 для указанного значения пароля. В запросе был еще один интересный момент: scode имел атрибут type со значением 2.
Я попытался присвоить значение 1, которое принимало бы открытый текстовый пароль. И это сработало! Таким образом, перебор в пределах значений открытого текста был возможен. Ничего особенного, но это был знак того, что я на правильном пути. Как насчет присвоения ему нулевых значений? Или других значений, таких как -1, 0 или 9999999999? Большинство из них вернули код ошибки, кроме значения 0. Я попробовал несколько действий с атрибутом 0, но безуспешно, пока не отправил значение пароля как пустое значение.
Я обнаружил, что можно получить доступ к любой учетной записи, просто указав имена пользователей и пустые пароли. Это оказалось довольно серьезной ошибкой.
Заключение
Сложные механизмы аутентификации могут стать жертвой нераскрытых векторов атак, особенно в приложениях, подверженных ошибкам бизнес-логики. Поскольку автоматические сканеры в большинстве случаев не могут распознать такого рода уязвимости, для их обнаружения по-прежнему необходимы человеческие силы. Учитывая сложность современных программных сред, ни один отдельный исследователь безопасности не может выявить все возможные уязвимости или векторы атак. Тестирование безопасности с привлечением проверенного сообщества исследователей - лучший способ объединить уникальные знания каждого для поиска важных уязвимостей.