Сегодня я хочу поделиться уникальным случаем, с которым я столкнулся при проверке безопасности приложения в рамках одной программы. Эта уязвимость позволила мне обойти проверку электронной почты и завладеть учетной записью любого пользователя благодаря ошибке в регистрации.
В этой статье мы пошагово разберем процесс, который привел к этому открытию, исследую работу сайта и выясню, как каждая упущенная из виду деталь способствовала возникновению серьёзной уязвимости в системе безопасности. Мы рассмотрим методы, использованные для обхода проверки электронной почты, захвата учетных записей и, в конечном счете, раскроем возможные риски.
Эта компания предоставляет организациям инструменты для создания онлайн-сообществ и управления ими.
Глубокое погружение в процесс регистрации:
Прежде всего я хотел изучить процесс регистрации и понять, как его реализовали разработчики. Поэтому я подписался на 14-дневную бесплатную пробную версию приложения для создания сообщества.
В процессе я обнаружил, что для завершения настройки учетной записи и создания сообщества мне необходимо ввести OTP, отправленный на мою электронную почту.
У меня было несколько рабочих трюков, как обойти проверку электронной почты при создании сообщества. Я решил начать с регистрации с поддельным адресом электронной почты, используя домен компании, например moraa3@company.com.
И я успешно миновал проверку, система перенаправила меня на завершение настройки сообщества.
Там прятался маленький симпатичный баг, и теперь настало время для серьезных раскопок!
Когда я успешно зарегистрировался на своем первом почтовом ящике attabombo5@gmail.com, пришло время посмотреть, смогу ли я его захватить. :))
Сначала я попытался перезаписать эту почту, используя moraa3@company.com, с небольшими вариациями, например attabombo5@gmail.coM. Но, как я и ожидал, эта попытка не удалась.
Однако есть и другой простой способ перезаписи учетки - зарегистрироваться с тем же самым электронным адресом жертвы, attabombo5@gmail.com, но с небольшими изменениями, например attabombo5@gmail.coM. Давайте посмотрим, что из этого выйдет!
Итак, давайте зарегистрируемся с attabombo5@gmail.coM.
ЛОЛ... оно даже не сказало мне «Этот e-mail уже существует». Вместо этого оно просто предложило мне ввести OTP!
Далее давайте попробуем использовать мой фальшивый электронный адрес сотрудника, moraa3@company.coM, с небольшими изменениями, чтобы проверить, удастся ли обойти запрос OTP, как в первый раз.
Они попросили ввести OTP и здесь.
Поэтому я решил посмотреть, можно ли как-то обойти эту страницу.
Через несколько минут я понял, что никакого ограничения запросов не существует.
И вот еще один сюрприз: когда я проверил OTP, отправленный на мой тестовый аккаунт attabombo5@gmail.com, я обнаружил, что срок действия OTP также не истек.
После обхода OTP я мог без проблем завладеть учетной записью любого пользователя или сотрудника.
Заключение:
В заключение хочу сказать, что эта уязвимость показала, как простой недостаток в процессе регистрации может привести к легкому захвату учетной записи. Обходя проверку электронной почты и используя такую уязвимость, как отсутствие истечения срока действия OTP, я смог легко взять под контроль любую учетную запись пользователя или сотрудника. Я также обнаружил, что, слегка изменив адрес электронной почты, например используя такие варианты, как attabombo5@gmail.coM или moraa3@company.coM, я могу переписать существующую учетную запись и полностью обойти процесс верификации. Это позволило мне успешно завладеть учетной записью, не столкнувшись с какими-либо серьезными препятствиями. Это подчеркивает, что даже незначительные ошибки в процессе регистрации могут привести к серьезным рискам безопасности.
Комментарии (28)
KennyGin
15.12.2024 14:55Так как в итоге было абьюзнуто "отсутствие истечения срока действия OTP" ? Не могу понять из статьи
luboshenko
15.12.2024 14:55Если нет ограничений на количество попыток и OTP не протухает, то элементарно методом подбора.
unreal_undead2
15.12.2024 14:55То есть в статье опущен перебор миллиона вариантов OTP (видимо скриптом)?
Pitt_Mitchell
15.12.2024 14:55Столько усилий ради сайта, с уровнем безопасности времен 95 винды... Тогда уж брутфорс запускай и кури, если ограничений нет на попытки авторизации.
Ratenti
15.12.2024 14:55Думаешь таких сайтов мало, при создании которых не участвовали специалисты AppSec?
mydigitalhabb
15.12.2024 14:55Даже не пойму, кто здесь больше даун, создатели сайта, английский кулхацкерт автор оригинальной статьи, или школьник переводчик, или AI-переводчик, либо все вместе сразу.
Но дерьмовее перевода я ещё не видел.
vityo
15.12.2024 14:55... или хабр, на котором такая статья пропускается или гугл предложки, что подсунули мне эту хрень и теперь я здесь с вами читаю это.
CorruptotronicPervulator
15.12.2024 14:55Какой ещё обход запроса? Ну ввёл ты уже существующий в системе email (системе резонно плевать на mixed-case) и она сразу спросила тебя OTP.
Вот то, что нет митигации частоты запросов к форме ввода OTP и/или инвалидации OTP после первой же неправильной попытки его ввода — печально. А вот время жизни OTP может быть и достаточно большим (более трёх минут, как на скриншоте).
IceGerda
15.12.2024 14:55Круто! Ты настоящий хакер от Бога! Я читаю и восхищаюсь твоими умениями и находчивостью! А эти распиаренные айтишники зря миллионы получают, когда настоящие таланты пропадают
Dixtox
Описание какого то коня в вакууме, непонятно что за сайт и накой там вообще кому либо регистрироваться. Это не какой то уникальный способ взлома любого ресурса а баг никому неизвестного (кроме автора) сайта, который вероятно автор и создал для пиара своих способностей, а ля - смотрите какой я молодец. Ну и возьми с полки пирожок. Толку от статьи ноль.
eledev
Судя потому что автор "забыл" замазать URI это circle.so.
eximus
Может, это такой пиар-ход, чтобы тупо перенаправить туда поток любопытных с хабра?
))
пс: м-м-м, бесплатненькая (для хабра заработок от рекламы этого сайта - ноль копеек) реклама ресурса!
Ratenti
На других сайтах email менять нельзя что ли?
askharitonov
Мне кажется, что это как раз достаточно типовой способ, основанный на том, что не везде переводят email в нижний регистр. При этом, если правильно понимаю, в одной части движка сайта email рассматривался как регистрозависимый, а в другой - как регистронезависимый, иначе просто было бы создано два аккаунта на один email в разном регистре. Ну и возможность перебора кодов подтверждения - это тоже выглядит как типовая уязвимость.
unreal_undead2
Не понимаю, в чём тут уязвимость - письма с OTP всё равно уходят на один адрес. Возможность спокойно перебрать миллион кодов - да, явная дыра.
askharitonov
В принципе, ему можно наверное было просто перебирать коды доступа, запрашивая их для одного адреса, и не использовать смену регистра, тогда часть операций просто лишняя, и всё сводится к тому, что сервер дал возможность проверить код множество раз.
Но тут ещё такой момент возникает: может в некоторых случаях возможно создать похожий адрес, отличающийся только регистром? Это наверное почти везде не сработает, но если найдётся сервис электронной почты, для которого user@example.com и USER@example.com будут разными адресами, то это уже может быть проблемой. Если адрес с этого сервиса будет использован для регистрации на сайте, то возможен, например, такой сценарий: при запросе кода для восстановления пароля указывается похожий адрес (USER@example.com вместо user@example.com), сайт ищет аккаунт в базе по адресу email, при этом поиск регистронезависимый, то есть, находится существующий аккаунт user@example.com, далее сайт отправляет ссылку для восстановления пароля на тот адрес, который был получен от пользователя (он вроде же правильный, зачем брать тот же самый email из базы?), и, в результате, ссылка отправляется на адрес злоумышленника.
При этом вряд ли существуют почтовые сервисы, где имена аккаунтов регистрозависимвые. Хотя вроде в стандартах такая возможность предусмотрена: https://datatracker.ietf.org/doc/html/rfc5321#section-2.4 Может быть разница между user и USER возможна в конфигурациях, где почта доставляется не на сервер IMAP, а кладётся в файл(ы) на диске (файл пользователя в каталоге /var/mail/ или Maildir)? Но вряд ли такой вариант используется в современных почтовых сервисах.
ahdenchik
Вообще-то, abc@domain.com и ABC@domain.com - это разные адреса
А вот abc@domain.com и abc@DOMAIN.COM - одинаковые