Mega Sekurak Hacking Party w Krakowie! 20.10.2025 r. Bilety -30%

Jak dodatkowa funkcja Microsoft Copilota otworzyła furtkę dla hakerów

30 lipca 2025, 05:52 | W biegu | 0 komentarzy

Niedawno pisaliśmy o różnych aspektach bezpieczeństwa rozwiązania MCP. Jednak to nie wszystkie zagrożenia, z którymi muszą mierzyć się inżynierowie wdrażający rozwiązania oparte o AI. W przypadku dużych dostawców oczekiwania rozbudowy funkcjonalności są spore. Brak odpowiedniego modelowania zagrożeń, może okazać się krytyczny z punktu widzenia bezpieczeństwa.

Badacze z Eye Research opisali trywialną wpadkę, za którą stało dodanie do Copilota Enterprise piaskownicy (ang. sandbox) języka Python, w którym działał Jupyter Notebook – popularne rozwiązanie do obsługi i współdzielenia “notatników programistycznych” w przeglądarce. 

Rysunek 1. Kapryśny Copilot nie zawsze potrafił wskazać poprawną odpowiedź (źródło)

Wykorzystując Jupyterowy prefix “%”, badacze pokazali, że mogą wykonywać polecenia systemowe wewnątrz ograniczonego środowiska. Dzięki temu udało im się dokonać rekonesansu piaskownic, które były wykorzystywane do uruchamiania kodu użytkowników. 

Rysunek 2. Listing struktury uruchomionych procesów (źródło)

Po dłuższej interakcji z modelem, udało się skłonić LLM do przygotowania plików, a nawet całych katalogów do pobrania. Dane przenoszone były do roboczego katalogu /mnt/data, skąd można je było pobrać, korzystając ze specjalnego URL: blob:https[:]//outlook.office.com/<guid>.

Dalsza “rozmowa” z modelem pozwoliła określić, że interfejsem do kontenera jest aplikacja goclientapp, która wystawiała specjalne API, przyjmujące zapytania POST pod adresem /execute. Proste listowanie zmiennych środowiskowych wymagało więc jedynie przesłania poniższego JSONa w ciele zapytania POST:

{"code":"%env"}

Prawda, że piękne? Ale jest jeszcze ciekawiej, na bazie analizy entrypoint.sh, okazało się, że proces Jupytera działa w kontekście użytkownika root. Wykorzystując zapisywalną ścieżkę, udało się wgrać prosty skrypt, który pozwolił na wywoływanie poleceń (przydała się tutaj analiza kolejności przeszukiwania $PATH w celu wykonania skryptu).

Skrypt wyglądał w następujący sposób:

#!/home/ubuntu/snenv/bin/python
import os
with open('/mnt/data/in','r') as fin:
  with open('/mnt/data/out','a') as fout:
    fout.write(os.popen(fin.read()).read())
print('1')

Listing 1. Proste RCE opakowane skrypcie pgrep.py (źródło)

Wykorzystanie powyższego eksploitu jest trywialne, wystarczy poprosić model aby wykonał operację wpisania polecenia do pliku, wywołał określony kod a następnie zwrócił wartość zapisaną ze standardowego wyjścia. 

Rysunek 3. LLM wykonujący całą “ciężką” pracę za atakującego (źródło)

Jest to czysto akademickie rozważanie, które w idealny (chociaż bliski naszym hakerskim sercom) podsumowują autorzy:

Now what have we gained with root access to the container?

Absolutely nothing!

Powyższy “gadżet” umożliwił atakującym lepsze poznanie środowiska wykonania, jednak przygotowana piaskownica, była skonfigurowana w taki sposób, że ewentualne próby wyskoczenia z niej i przejęcie kontroli nad zarządzającym systemem operacyjnym nie powiodły się. Mimo wszystko jest to bardzo ciekawy przykład na to, jak z pozoru niewielkie i przydatne nowe funkcjonalności, mogą otworzyć zupełnie nowe ścieżki do nadużyć. Luka została naprawiona po niespełna trzech miesiącach. Jednak biorąc pod uwagę jej krytyczność, rozumiemy, że nie znajdowała się na priorytetowej liście MSRC. 

~Black Hat Logan

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

Odpowiedz