Angribere kan eksternt udføre OS-kommandoer ved at udnytte denne GitLab-sårbarhed

Det lader til, at uanset hvor langt virksomheder er villige til at gå for at sikre deres produkter, er angribere altid et skridt foran og finder geniale måder at omgå al beskyttelse.

I denne evigt skiftende onlineverden bliver det i stigende grad at holde dine følsomme data sikret svært, og vi er her for at fortælle dig om en anden sårbarhed, der aktivt bliver udnyttet i det vilde.

En anden GitLab-sårbarhed, der aktivt udnyttes i naturen

Ifølge HN Security, blev der fundet to mistænkelige brugerkonti med administratorrettigheder på den internet-eksponerede GitLab CE-server.

Tilsyneladende blev disse to brugere registreret mellem juni og juli 2021 med tilfældigt udseende brugernavne. Dette var muligt, fordi denne version af GitLab CE tillader brugerregistrering som standard.

Desuden er den e-mailadresse, der blev angivet under registreringen, ikke bekræftet som standard. Det betyder, at den nyoprettede bruger automatisk logges på uden yderligere trin.

For at gøre tingene mere komplicerede sendes der absolut ingen meddelelser til administratorerne.

En af de uploadede vedhæftede filer fangede eksperternes opmærksomhed, så de oprettede deres egen GitLab-server og forsøgte faktisk at replikere, hvad de observerede i naturen.

En nyligt udgivet udnyttelse til CVE-2021-22205 misbruger uploadfunktionaliteten for at fjernudføre vilkårlige OS-kommandoer.

Ovennævnte sårbarhed findes i ExifTool, et open source-værktøj, der bruges til at fjerne metadata fra billeder, som fejler i at parse visse metadata, der er indlejret i det uploadede billede.

GitLab er sammensat af flere elementer, såsom Redis og Nginx. Den, der håndterer uploads, kaldes gitlab-workhorse, som igen kalder ExifTool, før den videregiver den endelige vedhæftning til Rails.

At grave dybere ned i logfilerne afslørede lidt beviser for to mislykkede uploads i Workhorse-loggene.

Denne nyttelast, der bruges af den offentlige udnyttelse, kan udføre en omvendt shell, hvorimod den, der blev brugt mod vores kunde, blot eskalerede de to tidligere registrerede brugeres rettigheder til admin.

echo 'user = User.find_by (brugernavn: "czxvcxbxcvbnvcxvbxv");user.admin="true";user.save!' | gitlab-rails konsol /usr/bin/echo dXNlciA9IFVzZXIuZmluZF9ieSh1c2VybmFtZTogImN6eHZjeGJ4Y3ZibnZjeHZieHYiKTt1c2VyLmFkbWluPSJ0cnVlIjt1c2VyLnNhdmUh | base64 -d | /usr/bin/gitlab-rails konsol

Så dybest set viste det, der så ud til at være en privilegie-eskaleringssårbarhed, sig faktisk at være en RCE-sårbarhed.

Som sikkerhedseksperter forklarede, koger hele udnyttelsesprocessen ned til kun to anmodninger.

På en standard GitLab-installation (op til version 13.10.2) er der ingen grund til at misbruge API'en for at finde et gyldigt projekt, ingen grund til at åbne et problem, og vigtigst af alt ingen grund til at autentificere.

Alle de sårbarheder, der er beskrevet i artiklen (ExifTool, API-misbrug, brugerregistrering osv.) er ikke til stede i den seneste GitLab CE-version i skrivende stund.

Vi anbefaler dog kraftigt at være forsigtig, når du beskæftiger dig med noget, der involverer dig online, så du ikke har nogen uheldige oplevelser.

Hvad er din holdning til denne situation? Del din mening med os i kommentarfeltet nedenfor.