FBI waarschuwt bedrijven voor opkomst van nieuwe typen ddos-aanvallen

De Amerikaanse FBI heeft bedrijven in de Verenigde Staten gewaarschuwd voor nieuwe vormen van ddos-aanvallen. Er zouden onlangs meer distributed-denial-of-serviceaanvallen hebben plaatsgevonden waarbij de criminelen netwerkprotocollen misbruiken die niet eerder zijn ingezet.

De federale politie waarschuwt in een melding aan bedrijfstakken voor de opkomst van nieuwe vormen van distributed-denial-of-serviceaanvallen tegen bedrijven. De FBI zegt sinds februari een stijging te zien van pogingen om zulke aanvallen uit te voeren. De dienst noemt specifiek een kwetsbaarheid in de opensourceprotocollen in Jenkins-servers, waarmee ddos-aanvallen kunnen worden uitgevoerd. Hoewel de FBI nog geen actieve uitbuiting heeft gezien, kan de Jenkins-kwetsbaarheid in theorie worden misbruikt om bestaande aanvallen meer dan honderd keer te versterken, waarschuwt de FBI.

Criminelen maken volgens de FBI steeds vaker gebruik van methodes die tot nu toe nog niet vaker zijn ingezet bij ddos-aanvallen. Die methodes zijn vooral uitgekozen omdat ze de aanvallen groter maken. Bij de aanvallen gebruiken de criminelen netwerkprotocollen die door bedrijven zelf vaak worden gebruikt. Dat maakt het moeilijker het aanvallende verkeer van het legitieme verkeer te onderscheiden.

Behalve voor de Jenkins-kwetsbaarheid waarschuwt de FBI specifiek voor Constrained Application Protocol- of CoAP-aanvallen, Web Services Dynamic Discovery of WS-DD, en Apples Remote Management Services of ARMS. Het gaat bij alle aanvallen om amplification attacks, waarbij een bepaalde aanval met minimale middelen wordt vermenigvuldigd en zo versterkt. Bedrijven zouden de protocollen in hun netwerken of iot-apparaten gebruiken en ze daardoor niet zo snel uitschakelen om ddos-aanvallen te voorkomen.

Volgens de FBI is de waarschuwing vooral bedoeld om bedrijven in staat te stellen zich beter op ddos-aanvallen voor te bereiden. Zo kunnen ze in gesprek gaan met hun hostingproviders of kunnen ze investeren in mitigaties via derde partijen.

Reacties (18)

[supersnathan94]

Behalve voor de Jenkins-kwetsbaarheid

Ik ben nu wel benieuwd welke kwetsbaarheid dat dan is. Jenkins heeft vaak al verregaande rechten dus lijkt mij absoluut niet handig om hier dan security issues in te hebben zitten. Daarnaast gaat het om OSS protocollen. Is er al bekend welke dat dan zijn?

edit:

In February 2020, UK security researchers identified a vulnerability in the built-in
network discovery protocols of Jenkins servers—free, open source, automation servers
used to support the software development process that cyber actors could exploit to
conduct DDoS amplification attacks — according to open source reporting. Researchers
estimated cyber actors could use vulnerable Jenkins servers to amplify DDoS attack
traffic 100 times against the online infrastructure of targeted victims across sectors.

FBI maakt het er zelf ook niet echt duidelijker van.

edit 2:

https://www.helpnetsecurity.com/2020/02/11/cve-2020-2100/
OK het lijkt dus om CVE-2020-2100 te gaan.

“An attacker can either send a UDP broadcast packet locally to 255.255.255.255:33848 or they could send a UDP multicast packet to JENKINS_REFLECTOR:33848. When a packet is received, regardless of the payload, Jenkins/Hudson will send an XML response of Jenkins metadata in a datagram to the requesting client, giving attackers the ability to abuse its UDP multicast/broadcast service to carry out DDoS attacks.”

The vulnerability was fixed in Jenkins 2.219 and LTS 2.204.2 two weeks ago by disabling Jenkins’ two network discovery services (UDP multicast/broadcast and DNS multicast) by default.

edit3:

Gaat dus helemaal niet om de OSS protocollen, maar gewoon een Amplification attack gebaseerd op standaard Multicast? Simpel vinkje uitzetten en je bent ook met oudere versies gewoon weer up en running.

edit4:

En ja hoor: The MITRE CVE dictionary describes this issue as:

Jenkins 2.218 and earlier, LTS 2.204.1 and earlier was vulnerable to a UDP amplification reflection denial of service attack on port 33848.

https://access.redhat.com/security/cve/CVE-2020-2100
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-2100

@TijsZonderH hoe kom jij aan die OSS protocollen dan? Ik kan het niet vinden namelijk.

[Reactie gewijzigd door supersnathan94 op 23 juli 2024 20:51]

[aequitas]

Gaat dus helemaal niet om de OSS protocollen, maar gewoon een Amplification attack gebaseerd op standaard Multicast?

Dat Jenkins op elk ontvangen bericht met een XML response reageert lijkt me niet een standaard multicast probleem, heeft dus wel te maken met het protocol wat Jenkins gebruikt. Net zoals de andere protocollen beschreven is dit een discovery protocol, bedoelt om een Jenkins server in je lokale netwerk te vinden[0].

Ook is het vaak dat Jenkins servers verbindingen van buitenaf accepteren. Dit om events van externe systemen (zoals b.v. Github) te ontvangen dat er een nieuwe commit is gepushed die gebouwd moet worden. Als je dit niet op de juiste manier dichttimmert in je firewall (geen whitelist, alle url's toestaan ipv alleen de push url) dan heb je een gapend gat in je netwerk. Vooral omdat dit soort servers vaak houtje touwtje in elkaar gezet zijn over de jaren heen en vaak heel veel toegang hebben binnen een netwerk (om code te pullen/pushen, applicaties te deployen).

[0] https://wiki.jenkins.io/d...ng+Jenkins+on+the+network

[Rob Coops]

Ook is het vaak dat Jenkins servers verbindingen van buitenaf accepteren. Dit om events van externe systemen (zoals b.v. Github) te ontvangen dat er een nieuwe commit is gepushed die gebouwd moet worden. Als je dit niet op de juiste manier dichttimmert in je firewall (geen whitelist, alle url's toestaan ipv alleen de push url) dan heb je een gapend gat in je netwerk. Vooral omdat dit soort servers vaak houtje touwtje in elkaar gezet zijn over de jaren heen en vaak heel veel toegang hebben binnen een netwerk (om code te pullen/pushen, applicaties te deployen).

Sorry maar dan klopt er iets niet binnen het bedrijf. Juist een server als die met vaak redelijk veel toegang tot andere systemen dient extra aandacht te krijgen als het gaat om de beveiliging van de server en wat er wel en niet is toegestaan. Zo'n ding direct aan het internet hangen ach ze bestaan vast maar dat soort bedrijven verdienen het niet te blijven bestaan.
Daarnaast moet je je heel erg af vragen waarom je een jenkins server auto discoverable zou willen maken op de interwebs. Wat voor toegevoegde waarde heeft zo iets voor ene bedrijf anders dan dat het een risico op levert omdat de buiten wereld dan veel makkelijker kan "zien" welke software er draait achter dat IP address.
Dat je verbindingen van buitenaf accepteert is niet gek maar alleen als deze met een key en of ander soort authenticatie token worden verstuurd en alleen over https om het lekken van de key te voorkomen.

Het argument dat men een houtje touwtje oplossing hebben draaien als CI/CD oplossing is in mijn ogen helemaal fout en meteen een reden om naar een andere werkgever te zoeken want een bedrijf dat dit soort infra niet op orde heeft heeft duidelijk geen kaas gegeten van ICT. De enige manier waarop ik bij zo'n soort bedrijf zou blijven werken is als ik er 100% zeker van ben dat men deze beschamende rommel op aan het lossen is en dat hier mensen aan werken die weten wat ze doen.

[aequitas]

Helaas is de praktijk vaak weerbarstiger dan de gewenste theorie. Bij grotere bedrijven komt shadow-ops vaak voor als dingen niet (snel genoeg) vanuit ops aangeleverd kunnen worden. En als aan de ene kant een manager zit te trekken voor security en aan de andere kant een manager die zorgt dat er gezonde omzet gedraaid kan worden zodat het bedrijf niet kopje onder gaat, dan worden sommige risico's wel eens genomen (of als minder risicovol bestempeld). Vaak hang je de server ook niet direct helemaal aan het internet, maar via een gaatje in de firewall op layer 7 met ip whitelists, zodat je het meeste gebruik kan voorkomen. Het beste is natuurlijk helemaal niet. Maar een huis zonder deuren of ramen wil ook niemand in wonen.

[supersnathan94]

Oke op die fiets. Maar dat is gewoon een implementatie voor auto discovery. Dat is eigenlijk hoe iedere vorm van auto discovery werkt. Alleen dan met een iets minder willekeurige payload. Dat is bijvoorbeeld ook hoe Hazelcast werkt.

Als je dit niet op de juiste manier dichttimmert in je firewall (geen whitelist, alle url's toestaan ipv alleen de push url) dan heb je een gapend gat in je netwerk.

Maar dat heb je dan toch sws? Die firewall regels moet je dus überhaupt gewoon in place hebben. Als beheerder zou ik ook standaard die autodiscovery uit hebben staan. Goeie DNS alias er aan hangen en je kunt direct verbinden. Autodisco is alleen handig als je anders op IP adres moet gaan lopen klooien met tig instances.

[fastedje]

Het is zowiezo handig om op elk systeem een lokale firewall te activeren die alleen protocollen doorlaat die je nodig hebt. UDP verkeer wil je echt wel standaard blokkeren, dit is heel vaak een attack vector.

[rjmno1]

Een ddos aanval is een aanval via internet na een server.Meestal worden meerdere ddos aanvallen gecreert
en vele malen en kort achter elkaar geprogrammeerd zodat de volledige bandbreedte van het internet bezet, men zou als men slachtoffer is geen connectiviteit meer hebben met het internet.
Of althans zo denk ik dat ook hackers te werk gaan, ze kunnen een of meerdere servers platleggen zodat er een netwerk of internet server plat leggen waar een website of andere applicaties op draaien.

[supersnathan94]

Ik snap je punt denk ik niet helemaal. Probeer je mij uit te leggen wat een DDoS is? Ik weet prima hoe die werken hoor .

De aanval die hier beschreven wordt is een UDP amplificatie aanval. Dit gaat uit van een stukje IP spoofing van "hacker" Jan. Die zegt hoi tegen Jenkins, maar doet alsof hij Pietje heet. Jenkins gaat zijn "hallo, dit is mijn berg met info *BARF* XML!!!" daardoor naar Pietje sturen, maar die zit daar helemaal niet op te wachten.

Jan zet echter zijn volledige bandbreedte van 1Gbit/s in om Jenkins instanties over de hele wereld (en dat zijn er kennelijk meer dan 12.000) te groeten en te doen alsof hij Pietje is. Pietje krijgt dus van iedere Jenkins instance de groeten terug. Het punt van amplification is echter dat Jan meer bandbreedte kan genereren door dit soort dingen te doen. Stel 1 request naar Jenkins kost hem 10Kb en de response van jenkins is 100kb dan heb je effectief je bandbreedte vertienvoudigt richting Pietje. Jan had het ook zelf kunnen doen, maar die heeft maar 1Gbit/s. Door deze Amplificatie te doen krijgt hij echter vrijwel gratis 10Gbit/s ter beschikking en Pietje heeft een enorm probleem want ga jij in dergelijke chaos maar eens 12.000 IP adressen blocklisten en bannen.

Wat echter een groter issue is, is dat je meerdere instances tegen elkaar kunt opjutten. Doordat er geen validatie is op de inhoud van het request (moet bepaalde syntax bevatten) wordt er ook gereageerd op de response van een andere instance. JE hoeft dus maar 1 keer een request te sturen waarbij je doet alsof je een andere Jenkins instance bent en je hebt een infinite loop te pakken. In een bedrijf met meerdere Instances vrij snel te regelen. Je hoeft alleen maar de DNS aliassen te achterhalen en met een beetje mazzel zit daar een fatsoenlijke logica in (zoals <team>-jenkins.blabla.nl).

ontzettend dom dus om in bedrijfsmatige toepassingen UDP auto discovery aan te laten. Je kunt vaak makkelijk DNS aliassen intern maken die makkelijk te onthouden zijn voor de gebruikers en dan heb je het helemaal niet nodig. Scheelt je een enorme attack vector binnen je netwerk (waar je vaak nog meer bandbreedte hebt dan erbuiten).

[mkools24]

Amplification attacks is toch niets nieuws? Dat begon jaaaren geleden al met DNS.

[hackerhater]

Inderdaad niks nieuws.
Als nu eens de oorzaak aangepakt zou worden ipv maar water naar de zee te dragen:

Afzender IP kunnen spoofen. Er is geen enkele reden waarom een netwerk/ISP zo'n packet zou moeten routen met een afzender IP dat niet tot zijn space behoort.
Als dit eens netjes overal geimplementeerd zou worden zou zo'n aanval nog niet eens het lokale netwerk uit komen of op zijn laatst het netwerk van de ISP.

Dat zou de kracht van botnets al enorm verminderen.

[Reactie gewijzigd door hackerhater op 23 juli 2024 20:51]

[mkools24]

Nu moet ik wel zeggen dat dat soort aanvallen wel steeds eenvoudiger zijn af te slaan. Veel bandwidth attacks heb je tegenwoordig al goede protectie voor, Cloudflare, OVH, etc.

Het zijn bij mij vooral de application layer attacks die het gevaarlijkst zijn, weinig bandbreedte soms maar een paar MB maar toch heel je service down.

[hackerhater]

Evengoed blijft dat een wedstrijdje van wie heeft de grootste.
Zelfs Cloudflare kan down gaan als er maar genoeg verkeer komt.

[mkools24]

Cloudflare hoeft niet down te gaan door een DDoS daar zorgen ze zelf wel voor

Maar om Cloudflare plat te leggen heb je wel HEEEL veel verkeer nodig, dat is toch wel heel erg lastig laat staan om het uren of dagen aan een stuk vol te houden omdat je bij iedere aanval ook een deel van je botnet verliest.

Ik gebruikte ook Cloudflare om m'n site te beschermen maar die ging down door de meest simpele bypass aanvallen. Probleem is wanneer iedereen Cloudflare gebruikt gaan daar ook de meeste bypass attacks voor worden ontwikkelt en doorverkocht.

[ACM]

Uiteraard is het principe niet nieuw. Deze 4 voorbeelden zijn blijkbaar wel voldoende nieuw (hoewel sommige al sinds 2018 worden gebruikt) voor de FBI om er nu over te waarschuwen.

[init6]

Jenkins is per definitie niet een omgeving welke ik graag aan internet heb hangen, vaak worden er builds van je hele stack er in uitgevoerd. Toegang tot dergelijke omgeving geeft gewoon je hele IP weg. Jenkins is ook best wel wat werk om goed te configureren, slecht geconfigureerd heb je toegang tot de console en kan je groovy scripts uitvoeren. Volgens mij gebruikt het UDP als je jenkins build agents hebt eraan hangen zodat het een heartbeat kan versturen.

Volgens mij zijn er wat proxy oplossingen, maar dan nog is het altijd een goed idee om te bedenken of je het niet kan oplossen met een aantal goede whitelists.

[Snow_King]

Aan het internet kan prima, maar alle poorten gewoon dicht behalve vanaf bepaalde bekende IP’s :-)

[mr94]

Voor mensen die niet weten wat Jenkins is:

Jenkins is een gratis en open source automatiseringsserver. Het helpt bij het automatiseren van de onderdelen van softwareontwikkeling met betrekking tot bouwen, testen en implementeren, wat continue integratie en continue levering mogelijk maakt.

https://en.wikipedia.org/wiki/Jenkins_(software)

[Mastofun]

Ik kan alleen maar denken aan het volgende :

https://en.wikipedia.org/wiki/Leeroy_Jenkins