flere dager siden i GitLab ble avduket via et blogginnlegg at forskere avslørte detaljer om en sårbarhet sikkerhet nå lappet i GitLab, en åpen kildekode DevOps-programvare, som kan tillate en uautentisert ekstern angriper å hente brukerrelatert informasjon.
Den største sårbarheten, som allerede er registrert som CVE-2021-4191, det tilskrives feilen med middels alvorlighetsgrad som påvirker alle versjoner av GitLab Community Edition og Enterprise Edition siden 13.0 og alle versjoner fra 14.4 og tidligere enn 14.8.
Det var Jake Baines, en senior sikkerhetsforsker ved Rapid7, som er kreditert for å oppdage og rapportere feilen, som etter ansvarlig avsløring 18. november 2021, fikk utgitt rettelser som en del av kritiske sikkerhetsutgivelser. fra GitLab 14.8.2, 14.7.4. 14.6.5 og XNUMX som kunne tillate en uautorisert bruker å gruve registreringstokener i GitLab Runner, som brukes til å organisere samtalebehandlere ved opprettelse av prosjektkode i et kontinuerlig integreringssystem.
"Sårbarheten er et resultat av en manglende autentiseringssjekk når du utfører visse GitLab GraphQL API-forespørsler," sa Baines. nevnt i en rapport offentliggjort torsdag. "En uautentisert ekstern angriper kan bruke denne sårbarheten til å samle GitLab-registrerte brukernavn, navn og e-postadresser."
I tillegg nevnes det at hvis du bruker Kubernetes-utførere, må du manuelt oppdatere Helm-diagramverdiene. med det nye registreringsbeviset.
Og at for selvstyrte forekomster som ikke er på versjon 14.6 eller nyere, har GitLab lagt ut patcher som kan brukes for å redusere avsløringen av Runner-registreringstokenet gjennom sårbarheten av raske handlinger Disse lappene bør betraktes som midlertidige. Enhver GitLab-forekomst bør oppdateres til en lappet versjon av 14.8.2, 14.7.4 eller 14.6.5 så snart som mulig.
Vellykket API-lekkasjeutnyttelse kunne tillate ondsinnede aktører å oppregne og kompilere lister over legitime brukernavn som tilhører et mål som deretter kan brukes som et springbrett for å utføre brute-force-angrep, inkludert passordgjetting, passordspraying og legitimasjonsfylling.
"Informasjonslekkasjen lar potensielt også en angriper lage en ny brukerordliste basert på GitLab-installasjoner, ikke bare fra gitlab.com, men også fra de 50,000 XNUMX andre Internett-tilgjengelige GitLab-forekomstene."
Det anbefales til brukere som vedlikeholder sine egne GitLab-installasjoner for å installere en oppdatering eller installere en oppdatering så snart som mulig. Dette problemet ble løst ved å gi tilgang til hurtighandlingskommandoer kun til brukere med skrivetillatelse.
Etter å ha installert en oppdatering eller individuelle "token-prefiks"-patcher, vil tidligere opprettede registreringstokener for grupper og prosjekter i Runner tilbakestilles og regenereres.
I tillegg til den kritiske sårbarheten, de nye versjonene som ble utgitt inkluderer også rettelser til 6 mindre farlige sårbarheter:
- Et DoS-angrep via tilbakemeldingssystemet: et problem i GitLab CE/EE som påvirker alle versjoner som starter med 8.15. Det var mulig å aktivere en DOS ved å bruke matematikkfunksjonen med en spesifikk formel i oppgavekommentarene.
- Legge til andre brukere i grupper av en ikke-privilegert bruker: som påvirker alle versjoner før 14.3.6, alle versjoner fra 14.4 før 14.4.4, alle versjoner fra 14.5 før 14.5.2. Under visse forhold kan GitLab REST API tillate ikke-privilegerte brukere å legge til andre brukere i grupper, selv om det ikke er mulig gjennom nettgrensesnittet.
- Feilinformasjon om brukere gjennom manipulering av innholdet i Snippets: lar en uautorisert skuespiller lage utdrag med villedende innhold, som kan lure intetanende brukere til å utføre vilkårlige kommandoer
- Lekkasje av miljøvariabler via "sendmail"-leveringsmetoden: Feil inndatavalidering på alle versjoner av GitLab CE/EE ved å bruke sendmail for å sende e-poster tillot en uautorisert aktør å stjele miljøvariabler via spesiallagde e-postadresser.
- Bestemme brukertilstedeværelse via GraphQL API: Private GitLab-forekomster med begrensede registre kan være sårbare for brukeroppregning av uautentiserte brukere via GraphQL API
- passordlekkasjer ved speiling av repositories via SSH i pull-modus
Endelig hvis du er interessert i å vite mer om det, kan du sjekke detaljene i følgende lenke.