A támadók távolról is végrehajthatják az operációs rendszer parancsait a GitLab biztonsági résének kihasználásával

Úgy tűnik, hogy bármennyire is hajlandók a cégek termékeik védelméért, a támadók mindig egy lépéssel előrébb járnak, és találnak zseniális módszereket minden védelem megkerülésére.

Ebben a folyamatosan változó online világban az érzékeny adatok biztonságban tartása egyre fontosabbá válik nehéz, és azért vagyunk itt, hogy beszámoljunk egy másik sebezhetőségről, amelyet aktívan kihasználnak a vad.

Egy másik GitLab sebezhetőséget aktívan kihasználtak a vadonban

A HN Security szerint, két gyanús, rendszergazdai jogokkal rendelkező felhasználói fiókot találtak az internetre kitett GitLab CE szerveren.

Úgy tűnik, ezt a két felhasználót 2021 júniusa és júliusa között regisztrálták véletlenszerű felhasználónevekkel. Ez azért volt lehetséges, mert a GitLab CE ezen verziója alapértelmezés szerint lehetővé teszi a felhasználók regisztrációját.

Ezenkívül a regisztráció során megadott e-mail cím alapértelmezés szerint nincs ellenőrizve. Ez azt jelenti, hogy az újonnan létrehozott felhasználó minden további lépés nélkül automatikusan bejelentkezik.

Bonyolítja a helyzetet, hogy a rendszergazdák egyáltalán nem kapnak értesítést.

Az egyik feltöltött melléklet felkeltette a szakértők figyelmét, ezért létrehozták saját GitLab szerverüket, és megpróbálták megismételni azt, amit a vadonban megfigyeltek.

Egy nemrég kiadott exploit for CVE-2021-22205 visszaél a feltöltési funkcióval tetszőleges operációs rendszer-parancsok távoli végrehajtása érdekében.

A fent említett sérülékenység az ExifToolban található, amely egy nyílt forráskódú eszköz a metaadatok eltávolítására a képekről, és amely nem képes a feltöltött képbe ágyazott bizonyos metaadatok elemzésére.

A GitLab több elemből áll, mint például a Redis és az Nginx. A feltöltést kezelőt gitlab-workhorse-nak hívják, amely viszont meghívja az ExifTool-t, mielőtt átadná az utolsó mellékletet a Railsnek.

Mélyebbre ásva a naplókban egy kis feltáratlan bizonyítékot két sikertelen feltöltésről a Workhorse naplóiban.

Ez a nyilvános exploit által használt hasznos terhelés fordított shellt hajthat végre, míg az ügyfelünk ellen használt terhelés egyszerűen megnövelte a két korábban regisztrált felhasználó adminisztrációs jogait.

echo 'user = User.find_by (felhasználónév: "czxvcxbxcvbnvcxvbxv");user.admin="true";user.save!' | gitlab-rails konzol /usr/bin/echo dXNlciA9IFVzZXIuZmluZF9ieSh1c2VybmFtZTogImN6eHZjeGJ4Y3ZibnZjeHZieHYiKTt1c2VyLmFkbWluPSJ0cnVlIjt1c2VyLnNhdmUh | base64 -d | /usr/bin/gitlab-rails konzol

Tehát alapvetően az, ami privilégium-kiterjesztési sebezhetőségnek tűnt, valójában RCE sebezhetőségnek bizonyult.

Amint a biztonsági szakértők elmondták, a teljes kihasználási folyamat mindössze két kérésből áll össze.

Egy alapértelmezett GitLab-telepítésen (a 13.10.2-es verzióig) nincs szükség az API-val való visszaélésre, hogy érvényes projektet találjunk, nem kell problémát nyitni, és ami a legfontosabb nem kell hitelesíteni.

A cikkben leírt összes sérülékenység (ExifTool, API visszaélés, Felhasználó regisztráció stb.) a cikk írásakor még nem található meg a GitLab CE legújabb verziójában.

Mindazonáltal határozottan azt tanácsoljuk, hogy legyen körültekintő, ha bármivel foglalkozol, amihez online kell lenni, hogy ne legyenek szerencsétlen tapasztalataid.

Mi a véleményed erről a helyzetről? Ossza meg véleményét velünk az alábbi megjegyzések részben.