Skræmmende simpel teknik får NTP-servere til at gå DDoS-amok

Illustration: Virrage Images/Bigstock
Adskillige NTP-servere befinder sig i en tilstand, hvor de kan bruges til at forstærke pakkepresset fra et DDoS-angreb med mere end faktor 500. Situationen er alvorlig, vurderer eksperter.

Selv it-kriminelle med adgang til lille båndbredde kan nu forvolde stor skade som følge af svaghed i servere, der bruges til at fortælle eksempelvis operativsystemer, hvad klokken er. Ingen har det præcise tal, men nettet vrimler formentlig med de sårbare NTP-servere (Network Time Protocol), som de kaldes. Ikke mindst fordi serverne også er indbygget i flere typer hardware, herunder firewalls.

En funktionalitet i serverne, der i mange tilfælde er aktiveret som standard, bruges til at forstærke datamængderne i et DDoS-angreb med mere end 500 gange, hvilket vil kunne få selv velpolstrede hjemmesider og andre webservices til at gå i knæ. Det vil altså sige, at en datastrøm sendt fra en angriber på 10 Mbit/s bliver til omkring 5 Gbit/s, når det har været forbi en sårbar NTP-server.

Dermed er det altså ikke nødvendigt at kommandere et botnet på mange hundrede tusinde maskiner for at kunne forvolde stor skade, påpeger Version2-blogger og netværksekspert ved Solido Networks Henrik Kramshøj, som beskriver angrebet som skræmmende let at udføre.

»Det, der gør det rigtigt alvorligt, er, at man skal bruge få maskiner,« siger han.

De it-kriminelle har for længst fået øje på potentialet i denne form for angreb, der forleden blev rettet mod flere europæiske servere, som blandt andet Version2 kunne berette om.

Uden at sætte et eksakt tal på, hvor mange sårbare NTP-servere, der er derude, vurderer Henrik Kramshøj, at sårbare NTP-servere er udbredte, baseret på de scanninger og kundehenvendelser, Solido Networks selv har foretaget.

»Hvis kunden har haft en NTP-server, så er den blevet misbrugt. Så hvis man sætter en NTP-server ubeskyttet på nettet, vil den blive misbrugt. Det kan jeg godt garantere,« siger han.

Også hardware

Udfordringen er blandt andet, at den berørte NTP-software også er installeret i flere hardwareprodukter, som dermed også bliver sårbare.

»Det er mange forskellige typer udstyr, der bliver ramt af denne her type sårbarhed,« siger han.

Solido Networks har inden for de seneste par måneder fået flere kundehenvendelser, hvor netop NTP-servere er blevet misbrugt til DDoS-angreb. I et af tilfældene var det en NTP-server i en firewall, som blev misbrugt, og kunden opdagede, at der var noget galt, da firewall'en kollapsede under trafikmængderne, som den altså sendte videre mod et offer.

»Det er vi selvfølgeligt kede af, men vi sendte kortvarigt 600 Mbit/s ud i verden fra vores kunde,« siger Henrik Kramshøj.

Den statslige amerikanske it-sikkerhedsvarslingstjeneste US-CERT har for nylig også beskrevet angrebsformen som værende på vej frem. Den amerikanske myndighed forklarer i en bulletin, at sårbarheden skyldes en debug-funktionalitet, der er slået til per default i ældre, men udbredt NTP-software.

NTP understøtter en monitoreringstjeneste, der gør det muligt for administratorer at forespørge serveren om antallet af forbundne klienter. Ved at sende en kommando, som får en åben NTP-server til at returnere den såkaldte monlist, svarer serveren tilbage med en liste over de seneste 600 ip-adresser, der har været forbundet til den. Problemet er, at det er muligt at få serveren til at sende til listen til målet for et DDoS-angreb i stedet for til afsenderen af kommandoen. Og resultatet kan altså blive en forstærkning af datatrafikken fra angriberen til målet på mere end 500 gange. Og derfor bør alle med berørt software slå debug-funktionen fra.

»Denne her feature er meget, meget farlig,« siger Henrik Kramshøj.

DRDoS

Typen af angreb kalder US-CERT for Distributed Reflective Denial of Service, eller DRDoS, modsat gængse (Distributed) Denial of Service. Det reflekterende element består, som flere nok har gættet, i, at angrebet reflekterer på en anden tjeneste, i dette tilfælde en NTP-server, hvor det samtidigt bliver forstærket sammenlignet med inputtet. Og det distribuerede element kommer ind i forhold til, at der jo godt kan anvendes mere end en NTP-server til at udføre angrebet, som Henrik Kramshøj påpeger.

DRDoS-angrebene forudsætter, at de udnyttede tjenester bruger UDP-protokollen. Her er der i udgangspunktet ingen validering af source - altså afsender - ip-adressen, og derfor kan pakkerne relativt let manipuleres, så de fremstår med en falsk-source-ip - i dette tilfælde offerets.

Og det er altså denne manipulation, der bevirker, at en forespørgsel sendt til en NTP-server efter monitoreringslisten kan resultere i en sværm af data rettet mod et vilkårligt offer.

It-profil med indsigt i NTP-protokollen Poul-Henning Kamp mener grundlæggende, at protokollen er dårligt designet, og så burde internetudbyderne slet ikke tillade, at der kan sendes UDP-pakker med en falsk afsenderadresse.

»Det burde ikke være muligt at sende IP-pakker med afsender-IP-nummer forskelligt fra ens eget IP-nummer, men ISP'er har ikke implementeret disse filtre for at spare penge. Dernæst burde denne tudsegamle debug-/forskningsfacilitet være fjernet fra NTPD-softwaren for 20 år siden,« skriver han i en e-mail.

Når misbruget af NTP-servere til DRDoS-angreb lader til at tage til netop nu, mener Henrik Kramshøj, at det skyldes, at andre tjenester, der tidligere muliggjorde såkaldte amplifikationangreb - sidste år var det DNS - efterhånden er blevet lukkede, så de ikke kan misbruges. Men til forskel fra tidligere DRDoS-sårbarheder, så lader ingen, jf. en opgørelse, som US-CERT har lavet, til at kunne slå NTP's mere end faktor 500. Nærmere bestemt faktor 556.9 målt på forskellen i mængden af UDP-data sendt til serveren og UDP-data returneret fra serveren.

Det er uvist, hvor mange berørte NTP-servere, der er tale om, men teknisk direktør i sikkerhedsvirksomheden CSIS Jan Kaastrup påpeger, at det er nemt at scanne sig frem til, om en åben NTP-server kan misbruges som led i et DRDoS-angreb.

»Jeg kan tilslutte mig, at det er en alvorlig situation. Man kan sidde ene mand og lave et angreb på stort set hvad som helst,« siger han.

Svært at forhindre

Og det er svært at beskytte sig mod den form for angreb, påpeger Henrik Kramshøj. For selvom der i firewall'en er blokeret for alt andet end port 80 og TCP-trafik til eksempelvis en webserver, så forslår det som en skrædder et sted, hvor sneen angiveligt aldrig bliver liggende, hvis firewall'en, der håndterer trafikken, går i knæ.

»Forbindelsen hen til serveren kan blive fyldt op. Og det kan være et problem, at firewall'en ikke kan håndtere pakkerne,« siger Henrik Kramshøj.

Anbefalingen fra ham og fra US-Cert er at tjekke sit netværk for åbne NTP-servere med debug-funktionaliteten aktiveret.

Det kan netscanningsværktøjet nmap eksempelvis bruges til med scriptet ntp-monlist.

Derudover anbefaler US-Cert, hvis muligt, at opdatere NTP-software til mindst version 4.2.7, hvor debug-funktionaliteten ikke er aktiveret som default.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Erik Cederstrand

Har et par servere, som blev misbrugt sidste weekend. Pludselig pumpede de 300Mb/s ud på nettet. Hver.

Der har været patches til FreeBSD siden 14. januar, men hvad hjælper det at patche, når man glemmer at genstarte ntpd ...

  • 7
  • 0
#3 Brian Hansen

Og selvom du har rettet problemet, så kan du roligt regne med at blive "angrebet" af servere der forsøger at gøre brug af din tidligere åbne ntp service. Der sidder folk på TOR sites der skovler penge ind på at sælge lister med ntp servere lige pt. Der er sågar garanti for så og så høj hit ratio, eller pengene retur. Skræmmende.

  • 0
  • 0
#4 Henrik Kramselund Jereminsen Blogger

Man kan checke sine netværk med kommandoen Nmap, eksempelvis med: sudo nmap -sU -pU:123 -Pn -n --script=ntp-monlist 192.168.1.0/24

Det virker ret godt det script der. Faktisk er der jævnligt et lille script som med Nmap nemt kan bruges til at checke selv meget store netværk for sårbarheder, så lær Nmap at kende NU! Start med Zenmap - hvor du kan paste kommandoerne ind :-D

  • 3
  • 0
#5 Leif Neland

sudo nmap -sU -pU:123 -Pn -n --script=ntp-monlist 192.168.1.0/24

Hvordan skelner man mellem en farlig og en ufarlig ntp?

123/udp open ntp | ntp-monlist: | Target is synchronised with 88.83.68.3 | Alternative Target Interfaces: | 192.168.5.10 192.168.5.11 | Public Servers (3) | 87.104.211.8 88.83.68.3 217.116.227.3 | Other Associations (8) | 192.168.1.50 (You?) seen 7 times. last tx was unicast v2 mode 7 | 192.168.5.11 seen 4 times. last tx was unicast v2 mode 7 | 192.168.5.10 seen 4 times. last tx was unicast v2 mode 7 | 80.82.65.57 seen 1 time. last tx was unicast v2 mode 7 | 107.150.32.130 seen 1 time. last tx was unicast v2 mode 7 | 180.149.95.174 seen 4 times. last tx was unicast v2 mode 7 | 108.61.61.163 seen 1 time. last tx was unicast v2 mode 7 |_ 178.217.187.38 seen 1 time. last tx was unicast v2 mode 7

  • 0
  • 0
#10 Baldur Norddahl

Udtrykket reverse path forwarding dækker over filtre, som forhindrer pakker med falsk afsender IP at blive videresendt. Hvis en router kender IP-adresserne på en kunde på en bestemt port, så bør routeren nægte at tage imod adresser der ligger udenfor kundens adresseområde.

Dette gøres nemmest i accessnetværket så tæt på kunderne som muligt. Desværre er der for mange ISP'er rundt omkring der ikke har implementeret dette ganske simple filter.

Der foregår i øjeblikket en debat omkring hvorfor stopper man det så ikke længere inde i netværket? Hvorfor stopper de store transitudbydere det ikke?

Jeg har en lille internetudbyder. Vi er kunde hos et par selskaber der sælger transit til resten af internet. De ved udmærket hvilket IP adresser vi har, og ligesom det forventes at vi blokkere vores kunder fra at sende med falsk IP adresse, så kunne mine transitudbydere gøre det samme for mig. Da der er langt færre transitudbydere end ISP'ere, så er det mere sandsynligt at dette vil føre til en reel blokkering af falske adresser.

Der er nogle tekniske udfordringer for transitleverandørerne. Men onde tunger påstår at sagen er at de er et en del af problemet. De tjener penge på trafik, og et DDoS angreb er trafik. Vi er alle tvunget til at købe ekstra store linjer, for at kunne håndtere angrebene. Og transitselskaberne tjener kassen på det.

Uden mulighed for at forfalske IP-adresser vil angreb som NTP og DNS applification/reflection simpelthen ikke virke.

  • 1
  • 0
#11 Leif Neland

Udtrykket reverse path forwarding dækker over filtre, som forhindrer pakker med falsk afsender IP at blive videresendt. Hvis en router kender IP-adresserne på en kunde på en bestemt port, så bør routeren nægte at tage imod adresser der ligger udenfor kundens adresseområde.

Hvorfor gør softwaren i routeren ikke det automatisk?

Når man konfigurerer at 123.456.789.0/26 skal routes til port 7, er der så nogen tilfælde, hvor andet, der kommer fra port 7 end 123.456.789.0/26 skal smides væk?

Eller overser jeg noget indlysende på dette sene tidspunkt?

  • 0
  • 0
#12 Baldur Norddahl

Hvis der er tale om en slutkunde (privat eller virksomhed) så er det enkelt. Mange routere har mulighed for reverse path forwarding som du bare skal slå til. Derfor er det enklest hvis man klarer det i kunde-routerne.

Længere inde i netværket bliver det mere kompliceret. Det vil hjælpe lidt med en tegning, men jeg forsøger at beskrive problemet:

Lad os sige at ISP1 har en aftale med TRANSIT1 foruden flere andre transitudbydere TRANSIT2 .. TRANSITn. Vi har også ISP2 som har en kontrakt med både ISP1 og TRANSIT1.

Når ISP2 sender trafik kan han altså gøre det både ved at sende via ISP1 eller han kan vælge at sende det direkte via TRANSIT1.

TRANSIT1 kan altså forvente at modtage trafik med IP-adresser tilhørende ISP2 via ISP1, også selvom TRANSIT1 selv sender trafik til ISP2 en anden vej. Det kender man som asymmetrisk routing og det er meget almindeligt.

Problemet for TRANSIT1 er at hans routing tabel vil enten pege på ISP1 eller direkte på ISP2. Typisk det sidste, for det er den mest direkte route. En routing tabel indeholder kun én vej man sender pakkerne.

Kun i det tilfælde at et link går ned, f.eks. hvis det direkte link mellem TRANSIT1 og ISP2 bryder sammen, så vil routing tabellen ændres, så at TRANSIT1 begynder at route pakker til ISP2 via ISP1.

Hvis TRANSIT1 benytter reverse path forwarding, så er der stor risiko for at de dropper legitim trafik.

Dermed ikke sagt at det er umuligt. Det kræver bare lidt mere fodarbejde at beregne hvilke IP ranges der lovligt kan komme ind på de forskellige links. RIPE har for eksempel et IRR (Internet Routing Registry) som kan bruges.

Transitudbyderne klager over at et sådant system vil kræve mere hukommelse i deres kant-routere. Dertil kommer som sagt, at de egentlig ikke har nogen interesse i at løse problemet.

  • 1
  • 0
Log ind eller Opret konto for at kommentere