Onderzoekers waarschuwen GitLab-gebruikers voor actief aangevallen oud lek

Beveiligingsonderzoekers van Rapid7 waarschuwen GitLab-gebruikers voor een kwetsbaarheid die in de praktijk wordt uitgebuit. Het gaat om een oude bug waar al een patch voor bestaat. Aanvallers kunnen door de bug code uitvoeren op een kwetsbaar systeem.

De kwetsbaarheid bestaat al langer. Het gaat om CVE-2021-22205, die al in april een patch kreeg van GitLab. De bug zit in alle versies van GitLab Community Edition CE als Enterprise Edition EE vanaf versie 7.12. De bug is gefixt in versies 13.8.8, 13.9.6 en 13.10.3 van GitLab. Desondanks zeggen onderzoekers van Rapid7 en HN Security dat ze recent meerdere aanvallen hebben gezien waarbij de kwetsbaarheid werd uitgebuit. Rapid7 voorspelt dat dat vaker gebeurt, met name omdat de bug ernstiger is geworden.

Toen de bug werd ontdekt kreeg die een kritieke CSVV-score van 9.9, maar later werd dat verhoogd naar een 10. Dat kwam omdat er voor een exploit aanvankelijk een geauthenticeerd account nodig was, maar later bleek dat niet nodig te zijn. De bug maakte het mogelijk om git-commando's uit te voeren door een geïnfecteerd DjVu-bestand te openen op de installatie.

Volgens Rapid7 zijn er op dit moment 60.000 GitLab-installaties openbaar vindbaar op internet. Daarvan heeft de helft de beschikbare patch nog niet doorgevoerd. In bijna een derde van de gevallen kon Rapid7 niet met zekerheid zeggen of de patch was doorgevoerd. Hoeveel actieve aanvallen er plaatsvinden op de servers is niet bekend, maar het lijkt vooralsnog om een klein aantal te gaan. De onderzoekers van HN Security hebben het bijvoorbeeld alleen over anekdotische gevallen waarin klanten werden geïnfecteerd.

Reacties (20)

[temp00]

Terwijl het updaten van Gitlab in de praktijk maar iets van 15min duurt. Gebruikers informeren, tijdelijk netwerkconnecties blokkeren, snapshot maken (tenminste als je die luxe hebt), sudo apt update && sudo apt upgrade, netwerkconnecties deblokkeren, klaar

[Oon]

Ik doe altijd een docker image pull en dan een service update, want mijn Gitlab draait netjes in een Docker Swarm stack met losse services

[Apache]

Ik draai het op k8s met hun officiële helm chart en dan is er geen downtime tijdens de upgrades. Die lopen verder ook netjes snachts geautomatiseerd.

[vinx77]

Helm charts is anders dan GEO, toch? Had gekeken naar Kubernetes waar de servers niet op 1 netwerk stonden, maar vond dat te ingewikkeld worden.

Heb hier alles op Docker-Compose en dat is niet meer dan `sudo docker-compose pull main && sudo docker-compose pull redis && sudo docker-compose down && sudo docker-compose up -d` voor minimale downtime (< 1 minuut). Met GEO moet je dat wel per locatie doen en is er dus een minuutje down-time per locatie.

[Dykam]

`down` is volgens mij niet eens nodig toch? `up -d` restart volgens mij services die dat nodig hebben, bijv. door nieuwe image of docker-compose.yml. tenzij het met een opstartvolgorde te maken heeft.

[Sando]

Ik gebruik watchtower voor automatische updates, maar zo'n update gaat een keer mis. Het gaat altijd een keer mis. En als je pech hebt moet je kiezen: Data kwijt of je dag kwijt.

Is er ook een commando waarmee de complete installatie (inclusief volumes en data) naar een makkelijk terug te zetten backup image te schrijven is? Het zou fijn zijn om met een druk op de knop een volledige revert te kunnen doen.

[Apache]

Dat kan, onderliggende fs zfs maken, of gitlab task executor een backup laten maken naar een s3 bucket.

Bij de helm chart is er semantic versioning waarbij we weten dat onze automatische upgrade niet moet lopen als er manuele stappen zijn. Werkt 👌

[Sando]

Je zegt twee interessante dingen. Dat eerste (gitlab backup) heb ik hier teruggevonden, maar dat tweede (gitlab helm chart) snap ik niet helemaal. Kan je een linkje of voorbeeld geven hoe we kunnen zien of er manuele stappen zijn? Is dat ook gitlab-specifiek of standaard voor alle containers?

Overigens is zfs niet zaligmakend. Ten eerste "vervuilt het je global scope" waardoor commando's als `zfs list` erg vertraagd worden en vervolgens een kilometer output geven. Elke container heeft weer een dozijn layers/mounts/snapshots.

Ten tweede lost het niet zo gek veel op als je bedenkt dat je huidige layer los staat van de locatie van de `docker-compose.yml` en eventuele relative mounts, automatic volumes en named volumes, die je afhankelijk van de eisen op een andere ssd of hdd hebt gezet. Zo kan je container verspreid zijn over 5 verschillende locaties, en ben je met het terugzetten toch weer een dagdeel kwijt.

Wat je eigenlijk zou willen is een commando waarmee je een backup maakt van een gehele container, en als je server dan kapot gaat, dat je met één commando een restore kunt doen, welke vervolgens alles repliceert: This will create the following named volumes: foo, bar, baz. Continue? (y/N)

[sonicboy]

Heb tijdje terug hier een script voor aangemaakt. Wel voor oudere versie van Gitlab (13.x) maar zal normaal gezien wel werken (best eerst es testen )

[RoestVrijStaal]

(...) sudo apt upgrade (...)

Hier wil je toch liever sudo apt-get install --only-upgrade gitlab-ce (oid) uitvoeren?

[temp00]

Ja klopt wel. Ik doe meestal het hele OS erbij. Zelfs dan duurt het nog geen 15min.

[TheVivaldi]

Maar duurt dat ook maar 15 min. bij bedrijven die het hosten dan? Want ik update mijn computer ook in een paar minuten, maar op bijv. een school gaat dat zo snel niet.

[temp00]

Yep. Hangt natuurlijk een beetje van je infrastructuur en aantal gebruikers af maar bij ons bedrijf wel.

[Reactie gewijzigd door temp00 op 23 juli 2024 08:35]

[Barracuda]

Als bandwidth een issue is, overdag refresh signatures en download only;

sudo apt update && sudo apt upgrade -d

Tijdens maintenance window daadwerkelijk patchen.

sudo apt upgrade

Of beter nog een eigen local repo zodat je deze kan bevriezen en ook je patches in OTAP volgorde kan doen.

[BobV]

Het draait hier zelfs in de unattended-upgrade 's nachts mee. Doen we al jaren en nog nooit een probleem mee gehad.

[bobdetweaker]

Bij ons ook. Automatische back-up vooraf. Slechts in een paar jaar een enkele keer voorgekomen dat we de update zelf eerder gestart hebben.

[LEiPiE]

Voor de duidelijkheid: gitlab 14 is niet affected blijkbaar.

[dcm360]

Dat is op zich ook logisch, want Gitlab 14 is pas halverwege dit jaar uitgebracht, en bevat daarmee (als het goed is tenminste) ook de beveiligingspatches van eerdere versies.

[LEiPiE]

Het was mij niet helemaal duidelijk of de patches voor 13 uitgebracht waren voor of nadat 14 uitkwam, vandaar, aangezien er nog wel eens patches willen komen voor oudere versies
Sterker nog: wij gebruikten nog 13.12.12 van september dit jaar, terwijl 14 dus zo teruglezend al in juni uit was.
Wij zaten nog op Ubuntu 16.04 en daardoor uberhaupt niet eens hadden gezien dat 14 al uit was
Toevallig vorige week onze gitlab moeten verhuizen naar een andere vps en die kans aangegrepen om naar ubuntu 20.04 en de nieuwste gitlab 14 te gaan (via een paar tussenstappen en veel gevloek en gezucht ). Dus dan is de tijdlijn wat fuzzy

[vinx77]

Tussen 22 juni 2015 en minimaal 14 april 2021 waren onze installaties kwetsbaar.