Все началось с того, что я получил тревожное сообщение на свой Email, в котором мне предложили принять участие в приватной программе поиска уязвимостей на платформе BugCrowd. Учитывая размер вознаграждений, я подумал, что было бы неплохо согласиться и принять участие в поисках багов. Время было за полночь, я немного попытался что-нибудь найти - ничего не нашел и лег спать, решив, что продолжу поиски на следующий день.
На следующий день, как и всегда, у меня было много важных дел. Но до того, как отправиться на работу, оставалось немного свободного времени и я решил продолжить вчерашние поиски.
Так как я уже был знаком с методологией работы веб-приложений, первым делом я решил провести тестированите на наличие IDOR. Оказалось, что на сайте используется зашифрованный идентификатор MongoDB, который, как вы уже догадались, расшифровать достаточно сложно. Это означает, что если бы я и нашел IDOR, то категория критичности оказалась низкой (как и вознаграждение). Это не будет стоить затраченного времени, поэтому я решил найти какие - нибудь другие лазейки, связанные с идентификатором.
Продвигаясь дальше, я нашел парочку Stored XSS. Я был уверен, что получу дубликат - зарепортил их и... получил дубликат!
Однако, после этих неудач, мне действительно улыбнулась удача и я столкнулся с уязвимостью, благодаря которой я смог бы украсть токен сброса пароля или токен подтверждения электронной почты любого другого пользователя при помощи Host-Header Injection.
Что такое Host-Header Injection?
Host-Header Injection - это уязвимость, при которой злоумышленник, изменяя в заголовке значения поля Host, может вмешаться в работу web-приложения и изменить его стандартное поведение.
Согласно Tenable: «При формировании URI-ссылок в веб-приложениях, разработчики часто обращаются к заголовку Host, получаемому в запросе со стороны клиента. Злоумышленник может воспользоваться этим, отправив поддельный заголовок с доменным именем, находящимся под его контролем».
Итак, мы имеем форму для сброса пароля. Выглядит она так:
При вводе адреса электронной почты, приходит письмо со следующим содержанием:
В запросе я подменил в заголовке хост сайта на локальный IP-адрес. При помощи инструментов разработчика, мы смотрим на ссылку и замечаем изменения, ссылка имеет вид -
Давайте теперь изменим оригинальный хост на
Посмотрим на ссылку из пришедшего сообщения. Как вы видите, теперь вместо 192.168.1.70, в качестве хоста выступает введенный нами redacted.com.
Если мы добавим существующий вредоносный хост в запрос и отправим его, в конце-концов мы сможем перехватить токен сброса пароля. Чтобы атака завершилась успешно, жертва должна кликнуть на ссылку из письма.
Так будет выглядеть обращение к нашему серверу, когда жертва перейдет по ссылке.
Я сообщил об этой уязвимости с предоставлением всех доказательств и получил 900$ в качестве bugbounty.
автор: @ Ajay Gautam
На следующий день, как и всегда, у меня было много важных дел. Но до того, как отправиться на работу, оставалось немного свободного времени и я решил продолжить вчерашние поиски.
Так как я уже был знаком с методологией работы веб-приложений, первым делом я решил провести тестированите на наличие IDOR. Оказалось, что на сайте используется зашифрованный идентификатор MongoDB, который, как вы уже догадались, расшифровать достаточно сложно. Это означает, что если бы я и нашел IDOR, то категория критичности оказалась низкой (как и вознаграждение). Это не будет стоить затраченного времени, поэтому я решил найти какие - нибудь другие лазейки, связанные с идентификатором.
Продвигаясь дальше, я нашел парочку Stored XSS. Я был уверен, что получу дубликат - зарепортил их и... получил дубликат!
Однако, после этих неудач, мне действительно улыбнулась удача и я столкнулся с уязвимостью, благодаря которой я смог бы украсть токен сброса пароля или токен подтверждения электронной почты любого другого пользователя при помощи Host-Header Injection.
Что такое Host-Header Injection?
Host-Header Injection - это уязвимость, при которой злоумышленник, изменяя в заголовке значения поля Host, может вмешаться в работу web-приложения и изменить его стандартное поведение.
Согласно Tenable: «При формировании URI-ссылок в веб-приложениях, разработчики часто обращаются к заголовку Host, получаемому в запросе со стороны клиента. Злоумышленник может воспользоваться этим, отправив поддельный заголовок с доменным именем, находящимся под его контролем».
Итак, мы имеем форму для сброса пароля. Выглядит она так:
При вводе адреса электронной почты, приходит письмо со следующим содержанием:
В запросе я подменил в заголовке хост сайта на локальный IP-адрес. При помощи инструментов разработчика, мы смотрим на ссылку и замечаем изменения, ссылка имеет вид -
http://192.168.1.70/?token={token}
Давайте теперь изменим оригинальный хост на
redacted.com и отправим запрос.
Посмотрим на ссылку из пришедшего сообщения. Как вы видите, теперь вместо 192.168.1.70, в качестве хоста выступает введенный нами redacted.com.
Если мы добавим существующий вредоносный хост в запрос и отправим его, в конце-концов мы сможем перехватить токен сброса пароля. Чтобы атака завершилась успешно, жертва должна кликнуть на ссылку из письма.
Так будет выглядеть обращение к нашему серверу, когда жертва перейдет по ссылке.
Я сообщил об этой уязвимости с предоставлением всех доказательств и получил 900$ в качестве bugbounty.
автор: @ Ajay Gautam
