SSRF и облачните метаданни: опасна комбинация

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

Какво е SSRF

SSRF се случва, когато приложение изтегля URL, подаден — директно или косвено — от потребителя, без да ограничава къде може да отиде. Инструменти за внос на изображения, тестери на webhook, генератори на PDF, визуализации на URL, функции „изтегли от връзка“: навсякъде, където сървърът прави изходяща заявка от ваше име, е кандидат. Целта на нападателя е да насочи тази заявка към нещо вътрешно.

Защо облакът го прави критичен

Облачните екземпляри излагат крайна точка за метаданни на локален за връзката адрес, която връща конфигурация — и, което е решаващо, временни данни за достъп за ролята, прикрепена към екземпляра. SSRF, който може да я достигне, прочита тези данни за достъп и после действа като екземпляра срещу API-тата на облачния доставчик. В зависимост от правата на ролята, това може да означава прочитане на контейнери за съхранение (buckets), бази данни или повишаване на права през целия акаунт. Едно непроверено изтегляне се превръща в пробив.

Как да се защитите

• Налагайте закалената услуга за метаданни. Изисквайте версията на метаданните, ориентирана към сесии (в стил IMDSv2), така че обикновен GET да не може да отнесе данните за достъп; изключете остарялата крайна точка.
• Роли на екземплярите с минимални необходими права. Ако данните за достъп бъдат откраднати, обхватът на пораженията е точно толкова голям, колкото ролята. Ограничавайте ролите строго.
• Списък с разрешен изходящ трафик. Приложението трябва да може да достига само местоназначенията, които законно му трябват. Блокирайте локалните за връзката и вътрешните диапазони по подразбиране.
• Валидирайте и валидирайте отново URL адресите. Разрешавайте и проверявайте местоназначението след пренасочвания; не се доверявайте на еднократна проверка, която пренасочване може да заобиколи.

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

Слепият SSRF също носи риск

Blind SSRF не връща отговора от целта пряко на нападателя. Наблюдаван DNS или HTTP callback доказва конкретното изходящо взаимодействие, а не произволен вътрешен достъп или извлечени credentials. Според метода, хедърите и страничните канали примитивът може да позволява вътрешно проучване или неразрешено действие. Самото достигане на metadata endpoint не доказва прочетени или използвани credentials. Оценявайте показаната възможност и отделяйте непотвърденото въздействие.

Отвъд облака: заявки към вътрешни услуги

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

Защо обвързването със сесия в IMDSv2 преодолява именно базовия SSRF

Първата версия на услугата за метаданни на екземпляри в AWS отговаряше на всеки процес, който можеше да достигне локалния за връзката адрес, с обикновена GET заявка. Това е точно формата на заявка, която уязвим сървър с охота ще направи от името на нападател — затова SSRF и метаданните станаха толкова мощна двойка. IMDSv2 променя модела на разговора, не адреса: преди да могат да бъдат прочетени данни за достъп, извикващият трябва първо да извърши PUT, за да получи краткотраен сесиен токен, и после да представя този токен като заглавка при всяка следваща заявка.

IMDSv2 добавя изисквания за метод, хедър и обработка на отговора, които SSRF само с GET може да не изпълни. По-способни примитиви изискват отделна оценка. HttpPutResponseHopLimit ограничава мрежовите преходи на PUT отговора с токена; той не разпознава и отхвърля заявка заради преминаване през контейнерен слой. Ниска стойност може да попречи на отговора да достигне легитимен контейнер. Изберете я според мрежовия дизайн и я съчетайте с достъп само чрез IMDSv2 и ограничени workload права.

DNS rebinding и валидация между момента на проверката и момента на употребата

Голяма част от защитата срещу SSRF е изградена върху една стъпка на валидация: разрешаване на името на хоста, потвърждаване, че адресът не е вътрешен или локален за връзката, и разрешаване на заявката. Слабостта е в разликата във времето. Между момента, в който приложението проверява адрес, и момента, в който HTTP клиентът действително се свързва, едно име може да бъде разрешено отново до различен адрес. Нападател, който контролира авторитетните отговори на един домейн, може да върне безвреден публичен адрес за проверочното запитване и чувствителен вътрешен адрес за последващата връзка. Това е класическо разминаване между момента на проверката и момента на употребата (TOCTOU) и преодолява валидатори, които се доверяват на име вместо на връзка.

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

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

Един URL се разбира от повече от един компонент, а те не винаги са съгласни. Валидаторът, HTTP клиентът и всяко прокси по-надолу могат да интерпретират авторитета, вградените данни за достъп, кодираните символи или необичайните форми на хост по различен начин. Когато компонентът, който решава, и компонентът, който се свързва, не са съгласни, адресът, преминал проверката, не е адресът, към който се установява връзка. Пренасочванията усложняват това: разрешен URL може да върне отговор 3xx, сочещ към нещо вътрешно, а клиент, който следва пренасочвания сляпо, ще го последва покрай вратата. Затова еднократната проверка спрямо списък с разрешени адреси при подаването е необходима, но никога достатъчна.

Особености при облачните доставчици и наблюдение извън канала

Услугите за метаданни се различават по начини, които имат значение за защитниците. AWS придвижи индустрията към описания по-горе модел с обвързване към сесия. Крайната точка за метаданни на екземпляри в Azure изисква наличието на конкретна заглавка в заявката, преди да отговори, което блокира наивен SSRF без заглавки. Google Cloud по подобен начин охранява отговорите си за метаданни зад изисквана заглавка. Общата нишка е, че съвременните доставчици изискват нещо, което обикновеният GET не може да предостави — така че най-безопасната позиция е да се допусне, че настройките по подразбиране на нито един доставчик не са еднакви, и всяка среда да бъде закалена до собствената ѝ най-строга настройка.