- A támadók egyszerűen nem hagyják magukat, és új ötletes módokat találnak a személyes terünkbe való behatolásra.
- A biztonsági szakértők egy másik GitLab sebezhetőséget tártak fel, amelyet a vadonban aktívan kihasználnak.
- 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.
- Harmadik felek visszaélhetnek a feltöltési funkcióval, és tetszőleges operációs rendszer-parancsokat hajthatnak végre távolról.
Ú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 konzolTehá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.
