Badacze „potwierdzają” ścieżkę ataku na developerów za pomocą instalacji fałszywej skórki do Visual Studio Code

Wybór edytora kodu to niezwykle ważny element kultury programistów. W Internecie znaleźć można setki dyskusji czy nawet tzw. flame warów dotyczących tego kluczowego narzędzia pracy. Z biegiem lat do prostego notatnika dołożono wiele funkcji, które ułatwiają pisanie kodu i pozwalają stosunkowo mały program rozbudować do zintegrowanego środowiska developerskiego. 

Stosunkowo dużą sympatią i popularnością wśród programistów cieszy się Microsoft Visual Studio Code. Personalizację edytora ułatwia, znany też z konkurencyjnych rozwiązań, Marketplace, czyli miejsce, w którym autorzy różnych dodatków umieszczają rozszerzenia dodające nowe funkcje, integrujące zewnętrzne oprogramowanie czy dostosowujące wygląd do personalnych wymagań użytkownika. 
Izraelscy badacze bezpieczeństwa skopiowali bardzo popularną skórkę edytora, o nazwie Dracula Theme opracowanego pierwotnie przez Zeno Rocha. Po dodaniu złośliwego kodu, który miał za zadanie wykradać zawartość otwieranych plików, zmodyfikowany dodatek został umieszczony w Marketplace VSCode pod zmienioną nazwą. Wykorzystano tutaj znaną sztuczkę tzw. typosquatting, tworząc literówkę w słowie „Dracula”, poprzez zamianę kolejności liter. „Darcula”, bo tak nazwany został ich projekt, otrzymał odpowiednią domenę, łudząco przypominającą oryginał. Kolejnym zabiegiem, mającym na celu poprawienie wiarygodności, było podlinkowanie oryginalnego repozytorium. Po weryfikacji domeny, strona spreparowanego projektu w Marketplace wyglądała naprawdę dobrze.

Zmiany kodu obejmowały dopisanie funkcjonalności wysyłającej otwierane pliki oraz zapisywanie na zdalnym serwerze dodatkowych metadanych jak nazwa domenowa czy liczba zainstalowanych dodatków.

Simply put, each time a victim opens a document on the editor, we read the code and send it to our Retool server and additionally send a beacon to our sever with information on the host machine, such as the hostname, domain, platform, number of extensions, etc.

Wysyłanie kodu, nawet w przypadku prowadzenia researchu nie jest najsensowniejszym pomysłem i może spowodować poważne konsekwencje, nawet bez angażowania wysoce zmobilizowanych działów prawnych. Co ciekawe, autorzy dodali też informację, że nie opublikowali kodu, aby nie powodować problemów:

Disclaimer: Actual source code was not leaked in order to not harm anyone.

Disclaimer ten można rozumieć na kilka sposobów i nie rozwiewa to wątpliwości dotyczących etyki postępowania. Biorąc pod uwagę, że cały artykuł nie jest napisany zbyt profesjonalnie, a badacze prawdopodobnie na co dzień nie posługują się językiem angielskim, to dopytaliśmy autorów co dokładnie mieli na myśli.

Wyniki mogą zaskakiwać, ale po kilkudziesięciu godzinach, w zakładce „trending”, opisującej zyskujące na popularności dodatki, pojawiła się również zainfekowana skórka.

Badacze otrzymali odpowiedzi zwrotne nie tylko z prywatnych maszyn hobbystycznych developerów, ale także te pochodzące z maszyn zarządzanych przez usługi katalogowe ActiveDirectory dużych korporacji.

A few days later, something big happened. We noticed we had a victim which was identified as a Windows machine inside a domain and network of a publicly listed company with a $483 billion dollar market cap, and later we confirmed to be inside tens of multi-billion dollar companies all of which are widely known, inside one of the biggest security companies in the world, and in a certain country’s justice court network (Keeping the company names to ourselves for their sake), proving to us the immense danger of this attack vector.

Autorzy postanowili się pochwalić kapitalizacją zaatakowanych spółek. Zastanawia nas, czy te informacje nie wystarczą do wyłonienia prawdopodobnych kandydatów i deanonimizacji ofiar? 

W drugiej części opublikowanych wyników badań, przedstawione zostały statystyki dotyczące zebranych informacji o rozszerzeniach już dostępnych w Marketplace. Badacze zidentyfikowali:

• 1283 rozszerzenia ze złośliwymi zależnościami
• 87 dodatków próbujących odczytać plik /etc/passwd (może parsowały ten plik w celu uzyskania listy użytkowników?)
• 8161 rozszerzeń, które komunikowały się z ustawionymi w kodzie, zewnętrznymi adresami IP
• 1452 dodatków, które uruchamiały niezaufany kod w postaci plików exe lub DLL
• 267 rozszerzeń z sekretami w kodzie

Dodatkowo odkryto, że 145 projektów rozszerzających funkcje VSCode jest bezpośrednio rozpoznawanych jako złośliwe przez portal VirusTotal. Na dokładkę 2304 rozszerzenia korzystały z cudzego kodu, a 783 korzysta z zewnętrznych modeli AI. Badanie pokazuje więc nie tylko teoretyczne zagrożenie, ale też praktyczne implikacje braku jakiejkolwiek weryfikacji umieszczonych w “sklepie” rozszerzeń. 

Należy jeszcze pamiętać, że jest to ujęcie w danym przedziale czasu i te wartości mogą się zmieniać. Jedną z możliwych (i sugerowanych przez autorów zmian), jest fakt wykupienia/przejęcia zaufanych projektów przez atakujących i następnie czasowe wstrzyknięcie złośliwych zmian do określonych wersji dodatku. Konfiguracja VSCode pozwala na ich automatyczną aktualizację, więc może się okazać, że z pozoru bezpieczna konfiguracja edytora jest tak naprawdę skutecznym wektorem ataku. 

Niezależnie jak bardzo clickbaitowo i złowrogo może zostać przedstawiony ten problem, to badanie nie jest w żaden sposób innowacyjne czy odkrywcze. Do bardzo podobnych wniosków doszli badacze z aquasec już ponad rok temu. Udało im się namierzyć złośliwe rozszerzenia, które wykonywały podobne do opisanych tutaj operacje. 
Typosquatting oraz inne techniki służące do skłonienia developerów, czyli ludzi, którzy posiadają wartościowe zasoby, takie jak kod źródłowy rozwijanego projektu, nie są nowością wśród ataków. Nie jest to w żadnym wypadku problem jednego rozwiązania, jednego oprogramowania. Optymizmem nie napawa fakt, że w szybko rozwijającym się świecie bibliotek i rozszerzeń brakuje rozwiązań mających na celu weryfikację uploadowanego kodu, aby upewnić się, że pochodzi on z zaufanego źródła i nie wyrządzi krzywdy, gdy zostanie zainstalowany na stacji roboczej. Ten problem nie ma jednego uniwersalnego rozwiązania, a na ten moment jedno jest pewne: „ptaszek” wskazujący, że dany projekt jest zweryfikowany (nie przypomina to rozwiązań niektórych social mediów?), nie oznacza za wiele w kontekście bezpieczeństwa. Okazuje się, że nawet ręczna weryfikacja źródeł może być niewystarczająca, jeśli pluginy będą aktualizowane automatycznie w tle. Dla dużych organizacji jedynym rozwiązaniem może być ręczna weryfikacja podzbioru “akceptowanych” rozszerzeń oraz korzystanie tylko z własnego, wewnętrznego repozytorium. W modelu ryzyka trzeba ująć fakt, że każde z rozszerzeń to tak naprawdę oddzielna aplikacja, uruchamiana bez sandboksów. Ponieważ VSCode ze swojej natury często realizuje dostępy do plików oraz uruchamia procesy potomne – należy być ostrożnym z poleganiem na rozwiązaniach klasy EDR jako jedynej warstwie zabezpieczeń. Z uwagi na naturę VSCode, otwierającego i uruchamiającego wiele plików, będzie ona prawdopodobnie niewystarczająca.

~fc