На рабочем сайте крупной страховой компании с миллионами пользователей агент Reflectiz обнаружил критический обход аутентификации. Проверка была санкционированной. Название страховщика, дата оценки и идентификатор уязвимости не раскрываются.
Вход позволял указать, куда отправить одноразовый код — OTP. Обычно такой код приходит на телефон, уже привязанный к учётной записи. Здесь запрос содержал два значения: канал доставки и адрес получателя. Их можно было изменить. Сервер отправил код на адрес из запроса, не проверив, что он принадлежит владельцу аккаунта. Агент направил код в контролируемый им почтовый ящик, получил его и вошёл в систему.
OTP подтверждает личность лишь тогда, когда связан с нужной учётной записью и отправляется на заранее привязанный контакт. OWASP предлагает проверять именно это: «Привязаны ли одноразовые пароли к правильной учётной записи пользователя?» В описанном случае серверная проверка связи между аккаунтом и адресом отсутствовала. Зная необходимые идентификаторы клиента, злоумышленник мог попытаться получить доступ к его учётной записи.
Подозрение возникло не сразу. Агент изучил JavaScript сайта и API-запросы, которыми пользовались страницы, затем обнаружил запрос для отправки OTP и параметры, похожие на переключатели канала и адреса. Одного этого было мало: сервер мог отклонить изменённые значения, а следующий шаг входа — остановить попытку.
Поэтому агент проверил оба значения в настоящем процессе авторизации. После успешного входа защитные ограничения остановили тест: агент не стал изучать содержимое аккаунта и сообщил о находке страховщику. Иллюстрация достигнутого состояния авторизации была воссоздана и обезличена. Атаку запустить оказалось сравнительно просто; труднее было проверить её на рабочем сайте, не выходя за установленные границы.
Многие автоматизированные проверки останавливаются у страницы входа. Но если система не умеет пройти авторизацию, она не видит процессы, спрятанные за ней: восстановление доступа, личный кабинет или оформление заказа. Reflectiz утверждает, что накапливала веб-контекст более десяти лет, сканируя тысячи рабочих сайтов, проходя вход, получая коды подтверждения и перемещаясь по многошаговым сценариям. На ресурсах, которые компания уже мониторит, агент может опираться на этот опыт, а не начинать с одной ссылки. По словам Reflectiz, эту основу для агента создал Ysrael Gurt, технический директор и сооснователь компании, давно занимающийся этичным хакингом.
Одна подтверждённая уязвимость доказывает, что конкретная проверка выявила сбой, но сама по себе не показывает полноту тестирования. Проверку OTP проводили параллельно с другими планами атак на тот же сайт. Reflectiz описывает подход как сочетание свободного исследования и структурированного плана: каждый обнаруженный конечный адрес проверяется по применимым категориям атак. Отдельный агент-валидатор повторно воспроизводит подозрительную находку с теми же данными и контекстом. В отчёте фиксируются выполненные тесты, результаты и исключения.
По сообщению страховщика, сайт проходил пентест примерно за шесть месяцев до этой проверки. Когда именно появилась слабость, неизвестно. Reflectiz не представляет находку как доказательство некомпетентности ручных тестировщиков: опытный специалист тоже мог её обнаружить. Проблема шире: сайты меняются с каждым релизом, а график пентестов остаётся сравнительно жёстким. Атакующие с ИИ не обязаны ждать следующей проверки. Агентное тестирование можно повторять при изменениях сайта, если у агента есть нужный доступ и чёткие ограничения; его выводы при этом должны опираться на проверяемые свидетельства.
Reflectiz заявляет о тестовой мощности до десяти раз выше, чем у традиционного ручного пентеста при тех же операционных затратах. Речь идёт об объёме проверок, а не о гарантии найти в десять раз больше уязвимостей. Для конкретного приложения компания предлагает отдельно выяснить, как объём работ, глубина тестирования и частота проверок повлияют на стоимость и охват.
Reflectiz предлагает техническую демонстрацию на 30 минут со специалистом по веб-безопасности. До встречи можно выбрать процессы для обсуждения: вход, восстановление аккаунта, оформление заказа или клиентский портал. На демонстрации разбирают, как агент проходит закрытые многошаговые сценарии, какие доказательства подтверждают находку и как фиксируются границы доступа и охват тестирования. Обязательств брать на себя не нужно; проверять сайт участника во время встречи также не требуется.
Изображение носит иллюстративный характер
Вход позволял указать, куда отправить одноразовый код — OTP. Обычно такой код приходит на телефон, уже привязанный к учётной записи. Здесь запрос содержал два значения: канал доставки и адрес получателя. Их можно было изменить. Сервер отправил код на адрес из запроса, не проверив, что он принадлежит владельцу аккаунта. Агент направил код в контролируемый им почтовый ящик, получил его и вошёл в систему.
OTP подтверждает личность лишь тогда, когда связан с нужной учётной записью и отправляется на заранее привязанный контакт. OWASP предлагает проверять именно это: «Привязаны ли одноразовые пароли к правильной учётной записи пользователя?» В описанном случае серверная проверка связи между аккаунтом и адресом отсутствовала. Зная необходимые идентификаторы клиента, злоумышленник мог попытаться получить доступ к его учётной записи.
Подозрение возникло не сразу. Агент изучил JavaScript сайта и API-запросы, которыми пользовались страницы, затем обнаружил запрос для отправки OTP и параметры, похожие на переключатели канала и адреса. Одного этого было мало: сервер мог отклонить изменённые значения, а следующий шаг входа — остановить попытку.
Поэтому агент проверил оба значения в настоящем процессе авторизации. После успешного входа защитные ограничения остановили тест: агент не стал изучать содержимое аккаунта и сообщил о находке страховщику. Иллюстрация достигнутого состояния авторизации была воссоздана и обезличена. Атаку запустить оказалось сравнительно просто; труднее было проверить её на рабочем сайте, не выходя за установленные границы.
Многие автоматизированные проверки останавливаются у страницы входа. Но если система не умеет пройти авторизацию, она не видит процессы, спрятанные за ней: восстановление доступа, личный кабинет или оформление заказа. Reflectiz утверждает, что накапливала веб-контекст более десяти лет, сканируя тысячи рабочих сайтов, проходя вход, получая коды подтверждения и перемещаясь по многошаговым сценариям. На ресурсах, которые компания уже мониторит, агент может опираться на этот опыт, а не начинать с одной ссылки. По словам Reflectiz, эту основу для агента создал Ysrael Gurt, технический директор и сооснователь компании, давно занимающийся этичным хакингом.
Одна подтверждённая уязвимость доказывает, что конкретная проверка выявила сбой, но сама по себе не показывает полноту тестирования. Проверку OTP проводили параллельно с другими планами атак на тот же сайт. Reflectiz описывает подход как сочетание свободного исследования и структурированного плана: каждый обнаруженный конечный адрес проверяется по применимым категориям атак. Отдельный агент-валидатор повторно воспроизводит подозрительную находку с теми же данными и контекстом. В отчёте фиксируются выполненные тесты, результаты и исключения.
По сообщению страховщика, сайт проходил пентест примерно за шесть месяцев до этой проверки. Когда именно появилась слабость, неизвестно. Reflectiz не представляет находку как доказательство некомпетентности ручных тестировщиков: опытный специалист тоже мог её обнаружить. Проблема шире: сайты меняются с каждым релизом, а график пентестов остаётся сравнительно жёстким. Атакующие с ИИ не обязаны ждать следующей проверки. Агентное тестирование можно повторять при изменениях сайта, если у агента есть нужный доступ и чёткие ограничения; его выводы при этом должны опираться на проверяемые свидетельства.
Reflectiz заявляет о тестовой мощности до десяти раз выше, чем у традиционного ручного пентеста при тех же операционных затратах. Речь идёт об объёме проверок, а не о гарантии найти в десять раз больше уязвимостей. Для конкретного приложения компания предлагает отдельно выяснить, как объём работ, глубина тестирования и частота проверок повлияют на стоимость и охват.
Reflectiz предлагает техническую демонстрацию на 30 минут со специалистом по веб-безопасности. До встречи можно выбрать процессы для обсуждения: вход, восстановление аккаунта, оформление заказа или клиентский портал. На демонстрации разбирают, как агент проходит закрытые многошаговые сценарии, какие доказательства подтверждают находку и как фиксируются границы доступа и охват тестирования. Обязательств брать на себя не нужно; проверять сайт участника во время встречи также не требуется.
