Грешката беше елементарна: входът в системата позволяваше сами да изберете къде да бъде изпратен кодът за вход. Доказването ѝ на работещ уебсайт в реално време обаче беше трудната част.

TL;DR

  • По време на оторизиран одит AI агент за пентестинг откри напълно самостоятелно критична уязвимост, позволяваща заобикаляне на автентикацията в продукционния уебсайт на голям застраховател.
  • Една-единствена заявка за вход позволяваше на потребителя да посочи къде да бъде изпратен еднократният код за сигурност.
  • Самата атака беше лесната част. Доказването ѝ в реална среда изискваше уеб контекст, граден повече от десетилетие.

Входът сработи. След това агентът спря.

AI агентът за пентестинг на Reflectiz картографираше процеса по вход в реалния уебсайт на голяма застрахователна компания с милиони потребители.

Агентът поиска код за вход и го насочи към контролирана от него имейл пощенска кутия. Кодът пристигна. Входът премина успешно. Заложените защитни ограничения спряха теста веднага след успешния вход.

Агентът бе открил напълно самостоятелно уязвимост за заобикаляне на автентикацията от критично ниво. Reflectiz докладва за проблема на застрахователната компания.

Дефектът: заявката определяше къде да бъде изпратен кодът

Еднократната парола (OTP) доказва самоличността ви само ако се изпраща до дестинация, която вече е обвързана с профила. В този случай тази връзка беше прекъсната.

Заявката за вход съдържаше две полета, определящи доставката: канал и адрес. Обикновено кодът се изпращаше чрез SMS до телефонния номер, регистриран към профила. Заявката обаче можеше да промени канала. При превключване към имейл, сървърът изпращаше кода до посочения в самата заявка адрес, а не до този, който е записан в клиентския профил.

В опростен вид заявката изглеждаше по следния начин:

Сървърът изобщо не проверяваше дали адресът принадлежи на съответния профил.

Обвързването на кода с неговия акаунт е една от най-базовите проверки при автентикация. Ръководството за тестване на OWASP поставя този въпрос съвсем недвусмислено: „Свързани ли са еднократните пароли (OTP) с правилния потребителски профил...?“

Атакуващ с нужните клиентски идентификатори би могъл потенциално да експлоатира уязвимостта, за да получи пълен достъп до профила на съответния клиент.

От подозрително поле до доказан пробив

Агентът започна с разузнаване, анализирайки JavaScript кода на сайта и API повикванията зад неговите страници. Този анализ изведе на преден план заявката за OTP и две стойности, които изглежда управляваха начина и мястото на изпращане на кода. Подобни параметри могат да породят хипотеза, но сами по себе си не представляват потвърдена констатация, тъй като сървърът би могъл да отхвърли промените или да ги блокира на по-късен етап от входа. Затова агентът изгради целенасочен тест около двете стойности и го изпълни в реалния процес на вход, което потвърди пробива.

Илюстрация на автентифицираното състояние, до което агентът е достигнал преди да спре. Пресъздадено и анонимизирано.

Искате да видите как работи този процес на тестване? Заявете техническа демонстрация, за да разгледате как Reflectiz изследва работните процеси на уебсайтове, валидира констатации и контролира изпълнението.

Уеб контекстът е трудната част

Множество системи за автоматизирано тестване спират пред бариерата на входа, но голяма част от критичните процеси се намират зад нея. Система за тестване, която няма достъп до даден работен процес, не може да оцени случващото се вътре в него.

Reflectiz реши този проблем много преди появата на агента. Компанията е прекарала над десетилетие в сканиране на хиляди реални уебсайтове, което включва влизане в профили, получаване на кодове за потвърждение и навигиране през многоетапни процеси. Поради това, в сайтове, които компанията вече наблюдава, агентът стартира с натрупан контекст, а не от празен URL адрес.

Агентният пентестинг на Reflectiz въвежда този уеб контекст в действие. Той управлява реален браузър през същите стъпки, през които преминава клиентът, включително еднократни кодове и двуфакторна автентикация (2FA).

Техническият директор и съосновател на Reflectiz Исраел Гурт, дългогодишен етичен хакер, изгради агента именно върху тази основа.

Една констатация не е отчет за пълно покритие

Потвърдената уязвимост показва къде има проблем, но не разкрива каква част от приложението е била изследвана.

Тестът на OTP се изпълняваше паралелно с други сценарии за атака върху същия сайт. Агентният пентестинг на Reflectiz съчетава отвореното проучване със структуриран план: тестване на всяка открита крайна точка срещу всяка приложима категория атаки. Отделен валидиращ агент възпроизвежда всяка предполагаема констатация със същия инжектиран код и контекст, преди тя да бъде докладвана.

Резултатът е детайлен отчет за покритието, съдържащ проведените тестове, техните регистрирани резултати и всички изключения.

Преминал през пентест не означава защитен

Застрахователят заяви, че е извършил пентест на сайта около шест месеца по-рано. Настоящата оценка обаче откри уязвимост във входа, позволяваща компрометиране, въпреки че остава неясно кога точно е бил въведен този дефект.

Това не е упрек към тестващите експерти, тъй като опитен специалист също би могъл да открие такъв недостатък. По-скоро става въпрос за естеството на моментните проверки. Те имат своето място, но колко често дадена организация може да си позволи да ги провежда?

Уебсайтовете се променят с всяка нова версия, но графиците за пентестинг остават статични. Тяхната тромавост не предлага надеждна защита срещу атакуващи, които вече използват изкуствен интелект за бързо откриване на уязвимости и няма да чакат следващия предвиден прозорец за одит.

Агентното тестване поддържа темпото. То може да повтаря насочени проверки толкова често, колкото се променя сайтът – при условие че агентът разполага с правилния достъп, ясни граници и създава доказателства, които проверяващият може да верифицира.

От Reflectiz отчитат до 10 пъти по-голям капацитет на тестване при същите оперативни разходи спрямо традиционния ръчен пентестинг. Сравнението се отнася за обема на тестването, а не представлява гаранция за откриване на 10 пъти повече уязвимости. При демонстрация попитайте как обхватът, дълбочината на тестване и честотата влияят върху капацитета и разходите за вашите приложения.