Atakujący mogą zdalnie wykonywać polecenia systemu operacyjnego, wykorzystując tę ​​lukę w GitLab

Wygląda na to, że bez względu na to, jak długo firmy chcą się posunąć, aby zabezpieczyć swoje produkty, osoby atakujące są zawsze o krok do przodu i znajdują pomysłowe sposoby na ominięcie wszelkich zabezpieczeń.

W tym stale zmieniającym się świecie online ochrona poufnych danych staje się coraz bardziej trudne i jesteśmy tutaj, aby poinformować Cię o innej luce, która jest aktywnie wykorzystywana w dziki.

Kolejna luka w GitLabie aktywnie wykorzystywana na wolności

Według HN Security, na ujawnionym w Internecie serwerze GitLab CE znaleziono dwa podejrzane konta użytkowników z uprawnieniami administratora.

Najwyraźniej ci dwaj użytkownicy zostali zarejestrowani między czerwcem a lipcem 2021 r. Z losowo wyglądającymi nazwami użytkowników. Było to możliwe, ponieważ ta wersja GitLab CE domyślnie umożliwia rejestrację użytkownika.

Ponadto adres e-mail podany podczas rejestracji nie jest domyślnie weryfikowany. Oznacza to, że nowo utworzony użytkownik jest automatycznie logowany bez dalszych kroków.

Aby sprawy były bardziej skomplikowane, do administratorów nie są wysyłane żadne powiadomienia.

Jeden z przesłanych załączników zwrócił uwagę ekspertów, więc utworzyli własny serwer GitLab i faktycznie próbowali odtworzyć to, co zaobserwowali na wolności.

Niedawno wydany exploit dla CVE-2021-22205 nadużywa funkcji przesyłania w celu zdalnego wykonywania dowolnych poleceń systemu operacyjnego.

Wspomniana powyżej luka znajduje się w ExifTool, narzędziu typu open source służącym do usuwania metadanych z obrazów, które nie analizuje niektórych metadanych osadzonych w przesłanym obrazie.

GitLab składa się z wielu elementów, takich jak Redis i Nginx. Ten, który obsługuje przesyłanie, nazywa się gitlab-workhorse, który z kolei wywołuje ExifTool przed przekazaniem końcowego załącznika do Rails.

Zagłębiając się w dzienniki, odkryłem trochę dowodów na dwa nieudane przesyłanie w dziennikach Workhorse.

Ten ładunek używany przez publiczny exploit może wykonać odwrotną powłokę, podczas gdy ta użyta przeciwko naszemu klientowi po prostu eskalowała prawa dwóch wcześniej zarejestrowanych użytkowników do administratora.

echo 'user = User.find_by (nazwa użytkownika: "czxvcxbxcvbnvcxvbxv");user.admin="true";user.save!' | konsola gitlab-rails /usr/bin/echo dXNlciA9IFVzZXIuZmluZF9ieSh1c2VybmFtZTogImN6eHZjeGJ4Y3ZibnZjeHZieHYiKTt1c2VyLmFkbWluPSJ0cnVlIjt1c2VyLnNhdmUh | base64-d | Konsola /usr/bin/gitlab-rails

Tak więc w zasadzie to, co wydawało się luką w eskalacji uprawnień, w rzeczywistości okazało się luką RCE.

Jak wyjaśnili eksperci ds. bezpieczeństwa, cały proces wykorzystywania sprowadza się do zaledwie dwóch żądań.

Przy domyślnej instalacji GitLab (do wersji 13.10.2) nie ma potrzeby nadużywania API, aby znaleźć prawidłowy projekt, nie ma potrzeby otwierania zgłoszenia, a co najważniejsze nie ma potrzeby uwierzytelniania.

Wszystkie opisane w artykule podatności (ExifTool, nadużycia API, rejestracja użytkownika itp.) nie są obecne w najnowszej wersji GitLab CE w momencie pisania tego tekstu.

Jednak zdecydowanie zalecamy ostrożność podczas zajmowania się wszystkim, co wiąże się z byciem online, aby nie mieć żadnych niefortunnych doświadczeń.

Jakie jest twoje zdanie na temat tej sytuacji? Podziel się z nami swoją opinią w sekcji komentarzy poniżej.