Грешка в персонализирана система за сесийни бисквитки (session cookies) позволи на неавтентикиран атакуващ да се представя за служители и администратори в платформа за управление на дворове (yard management platform).
Проблемът не компрометира самия Microsoft Entra ID. Вместо това той позволи на слаб сесиен слой от страна на приложението да приеме фалшифицирана самоличност, след като стандартните контроли за вход вече са били заобиколени.
Засегнатата платформа използва единичен вход (SSO) и многофакторна автентификация (MFA) чрез Entra ID, но също така разчита на подписана бисквитка за поддържане на сесиите в приложението.
Този дизайн създава същия риск, наблюдаван при атаките за прехващане на акаунти чрез бисквитки (cookie-based account takeover), при които контролът върху доверена сесия може да има по-голямо значение от паролата.
От Resecurity заявяват в доклад, споделен с Cyber Security News (CSN), че тяхната оторизирана оценка е разкрила уязвимостта по време на преглед на система за управление на дворове в веригата за доставки.
Изследователите отбелязват, че не са тествани производствени системи, тестовите записи са били възстановени, а самоличностите, цитирани в концептуално доказателство (proof of concept), са анонимизирани.
Успешно са имитирани 95 профила на служители от 241 тествани потребителски идентификатора, включително акаунти с разширени права. Фалшифицирана администраторска сесия е успяла да изпълни API заявка за промяна на състоянието, което означава, че уязвимостта е могла да разкрие оперативни данни и да позволи на злонамерен субект да действа от името на легитимен служител.
Уязвимост в сесийните бисквитки
Заобикалянето на защитата произтича от две свързани дизайнерски грешки. Приложението подписва бисквитка с твърдо кодирана тайна (hard-coded secret), която съвпада с името на бисквитката, докато подписаната стойност е публично разкритият база данни идентификатор на потребителя. Нито една от двете стойности не трябва да бъде достатъчна за установяване на автентикирана сесия.
Подписаната бисквитка обикновено открива промени чрез прилагане на криптографска тайна, съхранявана на сървъра, към случайна референция за сесия. В този случай целевият CUID е могъл да бъде получена от API отговори, включително от крайни точки за автентикирани потребители и директорийни отговори.
С предвидима тайна атакуващият би могъл да генерира бисквитка, която сървърът третира като принадлежаща на друг потребител. Тази разлика е от решаващо значение, тъй като получената заявка никога не изисква паролата на жертвата, ново MFA потвърждение или Entra ID токен за достъп.
Това е срив в модела на доверие на приложението, а не доказателство, че криптографията на Entra ID е компрометирана. Неотдавнашни доклади за кражба на Entra refresh токени по подобен начин показват защо защитата на самоличността трябва да предпазва артефактите, издадени след влизане в системата.
По-широкообхватните контроли на платформата са изглеждали стабилни по време на тестването: използвани са RS256-подписани токени за достъп, валидация на схеми и параметризиран достъп до базата данни.
Въпреки това отделната сесийна бисквитка се превръща в алтернативен маршрут към приложението. Изследователите откриват и неавтентикиран Swagger интерфейс, който разкрива целия API обхват от 251 маршрута, осигурявайки допълнителна видимост при оценката.
Ограничаване на риска на сесийния слой
Приоритетът е да се подмени (ротира) компрометираната тайна за подписване на сесии и да се анулират съществуващите сесии. Това прекъсва достъпа на бисквитките, произведени с този ключ.
Екипите трябва да прегледат логовете за автентификация и приложения за необичайно създаване на сесии, промени в профили, административни действия или активност, която не съответства на очаквания потребител или устройство.
Разработчиците трябва да заменят сесийните стойности, носещи самоличност и контролирани от клиента, със случайно генерирани идентификатори на сесии, съхранявани и проверявани на сървъра.
Отделни тайни с висока ентропия трябва да се съхраняват сигурно за средите за разработка, тестове и производство, като никога не се използват повторно между различни среди. Сам по себе си флагът за сигурна бисквитка (secure cookie flag) не може да защити сесиен дизайн, който се доверява на предвидима стойност.
Организациите трябва също така да оценят всеки персонализиран слой, добавен около облачния доставчик на самоличност. Силният SSO и MFA на по-горно ниво не могат да компенсират случай, в който приложението приема отделни данни за автентификация като решаващо доказателство за самоличност.
Защитниците могат да приложат поуките от техниката за прехващане на сесии Cookie-Bite, включително наблюдение за съмнителни влизания, ограничаване на неодобрени разширения на браузъра, налагане на достъп само от съвместими устройства и прилагане на защиты на токени.
Ако токените без запазване на състоянието (stateless tokens) остават необходими, Resecurity препоръчва силни криптографски ключове, ограничения на изтичането и защити срещу повторно използване (replay protections). Екипите трябва да се уверят, че отмяната на сесията обхваща всеки хост, който приема бисквитката.
Същата фалшифицирана бисквитка в този случай е работила както в API, така и в хостовете на административното приложение. Докладите за кражба на сесии в Microsoft 365 също подчертават, че само нулирането на паролата може да не прекрати автентикираните сесии.
Случаят е напомняне, че MFA потвърждава събитието на влизане, докато управлението на сесията решава какво се случва след това. Случайна референция за сесия от страна на сървъра, подменени тайни ключове и смислено наблюдение намаляват шанса атакуващ да превърне разкрит идентификатор в кражба на самоличност и акаунт.