История двух ATO. Ищем уязвимости в логике обработки email

Содержание статьи

• Первый Account Takeover
• Пример пейлоада JWT
• Эксплуатация
• Рекомендации
• Второй Account Takeover
• Эксплуатация
• Рекомендации

В кон­це 2023 года я учас­тво­вал в прог­рамме баг­баун­ти одной круп­ной рос­сий­ской ком­пании. Ком­бинируя логичес­кие ошиб­ки, я смог про­экс­плу­ати­ровать баг, который поз­воля­ет зах­ватить любой акка­унт. В этой статье я рас­ска­жу, как про­ходи­ло иссле­дова­ние и какие трю­ки мне помог­ли добить­ся резуль­тата.

К сожале­нию, я не получил сог­ласие на раз­гла­шение от ком­пании, одна­ко уяз­вимость уже устра­нена. Так что опи­шу ход тес­тирова­ния, не называя заказ­чика.

Pentest Award

Этот текст получил пре­мию Pentest Award 2024 в катего­рии Hack the logic, пос­вящен­ной поис­ку логичес­ких уяз­вимос­тей. Это сорев­нование еже­год­но про­водит­ся ком­пани­ей Awillix.

warning

Статья име­ет озна­коми­тель­ный харак­тер и пред­назна­чена для спе­циалис­тов по безопас­ности, про­водя­щих тес­тирова­ние в рам­ках кон­трак­та. Автор и редак­ция не несут ответс­твен­ности за любой вред, при­чинен­ный с при­мене­нием изло­жен­ной информа­ции. Рас­простра­нение вре­донос­ных прог­рамм, наруше­ние работы сис­тем и наруше­ние тай­ны перепис­ки прес­леду­ются по закону.

Первый Account Takeover

При изу­чении сер­виса я нашел нес­коль­ко инте­рес­ных ано­малий:

• При сме­не email в нас­трой­ках про­филя дос­туп к новому адре­су не про­веря­ется.
• При регис­тра­ции поль­зовате­ля и логине в его акка­унт API при­водит передан­ный email к ниж­нему регис­тру. Но при сме­не email в нас­трой­ках про­филя он не под­верга­ется никаким изме­нени­ям и успешно про­ходит про­вер­ку уни­каль­нос­ти, даже если сущес­тву­ет близ­нец с сим­волами в ином регис­тре.
• При иссле­дова­нии JWT, который исполь­зует­ся для авто­риза­ции поль­зовате­ля, я выяс­нил, что роль иден­тифика­тора поль­зовате­ля игра­ет email (так как это единс­твен­ный иден­тифика­тор поль­зовате­ля в пей­лоаде JWT).

По­луча­ется, что если у поч­тового адре­са есть близ­нец, то вла­делец такой поч­ты потен­циаль­но смо­жет под­делать токен дру­гого поль­зовате­ля и получить сес­сию от его име­ни.

Пример пейлоада JWT

Пер­вым делом нуж­но было понять, что про­изой­дет, если будет сущес­тво­вать нес­коль­ко email-близ­нецов с сим­волами в раз­ных регис­трах и мы поп­робу­ем исполь­зовать их для логина.

Что­бы разоб­рать­ся, что про­исхо­дит на бэкен­де сер­виса, я соз­дал два акка­унта и email вто­рого поменял на email пер­вого через баг в нас­трой­ке про­филя, пред­варитель­но изме­нив регистр некото­рых букв. При этом пароли у акка­унтов были раз­ными.

При попыт­ке вой­ти с дан­ными пер­вого поль­зовате­ля (того, который был зарегис­три­рован рань­ше) мы успешно попада­ем в его акка­унт. Если же исполь­зовать дан­ные вто­рого поль­зовате­ля, получа­ем ошиб­ку Invalid Credentials.

Источник: xakep.ru