Denial of Service i light-version: 100 kilobyte overmander serverens CPU

En fejl i de fleste webservere verden over gør det muligt for hackere at skabe effektive denial-of-service-angreb med én computer. Microsoft har straks rettet fejlen i .Net, men andre teknologier er også ramt.

Det er ikke nødvendigt med store botnet, der kontrollerer millioner af computere, hvis man vil have en webside til at gå offline med et denial-of-service-angreb (DoS-angreb).

Faktisk kan en hacker nøjes med én computer, én almindelig internetforbindelse og nogle små filer, der vil sende en webserver på så meget overarbejde, at den ikke kan drive hjemmesiden.

Sådan lød det et par dage før nytår fra tyske sikkerhedseksperter, og siden da har problemet fået stor opmærksomhed. Det skriver IDG News Service.

For eksempel har Microsoft valgt - for første gang i hele 2011 - at udsende en nød-opdatering til ASP .Net uden for de faste opdateringstider. Det skulle lukke hullet for .Net-servere, men problemet gælder også andre typiske webserver-teknologier: PHP, Ruby, Java og Googles V8-Javascript-motor.

De to tyskere fandt sikkerhedshullet i webservernes måde at håndtere hash-forespørgsler på.

En hash-værdi af data er en kode, der kan bruges, når der er brug for en kortere repræsentation af dataene. Webserverne skal sørge for, at der ikke dukker ens hash-værdier op, en såkaldt hash-kollision.

Men hackere kan ved at sende en lille, særligt kodet http-forespørgsel til en webserver fremprovokere et væld af disse hash-kollisioner, som tager meget processorkraft.

En forespørgsel på 100 kilobyte kan således holde en cpu-kerne fuldt beskæftiget i halvandet minut på en ASP-server, bekræfter Microsoft. Og med Java kan selv en fil på seks kilobyte holde en processorkerne travlt optaget.

Mens Microsoft allerede har sendt en opdatering ud - hvilket understreger alvoren i problemet - er flere andre firmaer på vej med en lapning af hullet.

Faktisk blev princippet bag angrebet beskrevet allerede i 2003, men dengang var det kun Perl, der valgte at følge op med en løsning på sikkerhedshullet.

Siden har hackere dog ikke brugt denne teknik, men det kan ske nu, hvor der er kommet meget opmærksomhed om sikkerhedshullet.

Kommentarer (29)

David Askirk Fotel

Det er rettet i Ruby 1.9 og jeg ved at der er en opdatering på vej til ruby enterprise 1.8.7 som er den mange ruby on rails ting kører på.

Claus Junker

Journalisten kan finde ud af at skrive PHP med store bogstaver, men ikke ASP.NET eller bare .NET i sig selv, selvom begge dele er akronymer.

Derudover er en "ASP-server" måske bedre kendt som IIS.

Samt resten af artiklen virker noget rodet.

Bryan Østergaard

Problemet er langt mere generelt end man måske umiddelbart får indtryk af at læse artiklen.

Ved at skabe tilstrækkeligt mange hash kollisioner "konverterer" man reelt an hash liste til en kædet liste som er meget mere krævende for mange operation (som f.eks. opslag i listen). Det interessante er at tricket generelt virker for alle applikationer der gemmer bruger genereret input i en hash liste på en forudsigelig måde.

Perl har så vidt jeg ved løst det ved at tilføje noget random til hashen (generet under opstart af perl så det er unikt for hver perl session), men flere andre projekter forsøger at løse problemet ved at begrænse mængden af bruger input til mere rimelige mængder.

Som et eksempel på andet end webservere så er der formentligt nogle IRCd daemoner der er sårbare overfor angrebet i et eller andet omfang. De burde dog blive reddet af generelle begrænsninger af antalelt af forbindelser per IP adresser mv., men der er ret meget kode der bør kontrolleres for dette.

Anders Hessellund Jensen

I artiklen står der: Og med Java kan selv en fil på seks kilobyte holde en processorkerne travlt optaget.

Det er ikke korrekt. I beskrivelsen af sårbarheden ( http://www.nruns.com/_downloads/advisory28122011.pdf ) står der

A Tomcat 6.0.32 server parses a 2 MB string of colliding keys in about
44 minutes of i7 CPU time, so an attacker with about 6 kbit/s can keep one i7 core constantly
busy. If the attacker has a Gigabit connection, he can keep about 100.000 i7 cores busy.

Dvs. der skal altså POST på 2MB til for at holde én i7 core beskæftiget i 44 minutter. Det kræver altså en forbindelseshastighed på 6 k[b]bit[/b]/s. Men én request på 6 kbyte kan altså ikke gøre det.

Kasper Grubbe

Det er ikke en rigtig løsning, mere et workaround, for problemet eksisterer stadigvæk selvom du salter. Det er noget som ligger i sig implementationen af hashlister.

Ved at salte hashlisten, kan du stoppe angrebet, da angriberen forhåbentligt ikke kan gætte, eller for den sags skyld regne sig frem til din salt. Men du er stadigvæk sårbar.

Jeg ved ikke hvilken indflydelse det har på flere servere der snakker med én enkelt klient på tværs af forespørgsler, for så kan det godt være det er derfor det har taget lidt længere tid at fikse.

Poul-Henning Kamp

  1. Microsofts nødpatch handler om noget helt andet og meget alvorligere, hash-fixet blev først klistret på senere.

  2. Problemet er at folk ikke bruger stærke nok hash-funktioner. Salt'ning er kun et band-aid.

  3. I stedet for alle de der "shift+add" type hashs på kun 32 eller 64 bits, bør man bruge en hash med kryptografisk styrke på mindst 128 bits, så er problemet løst en gang for alle.

Poul-Henning Kamp

Sjovt, jeg synes nu det er den her er den mest skræmmende:

> The most severe of these vulnerabilities could allow elevation of privilege if an unauthenticated attacker sends a specially crafted web request to the target site.

Jesper Kristensen

I stedet for alle de der "shift+add" type hashs på kun 32 eller 64 bits, bør man bruge en hash med kryptografisk styrke på mindst 128 bits, så er problemet løst en gang for alle.

Hvordan vil du gemme en hashtabel med 128 bit hashes i hukommelsen på en 64-bit server? Den tabel vil da fylde en hel del mere end det tilgængelige adresserum...

Det vil nok heller ikke være det smarteste at bruge hashfunktioner med kryptografisk styrke, da de typisk er noget tungere at beregne i forhold til universelle hashfunktioner baseret på randomisering. Specielt når det nu handler om DOS.

Thomas Dybdahl Ahle

Her er 100.000 longs, der tog min laptop 76s at knække:

Set<Long> set = new HashSet<Long>();  
for (long i = 0; i < 100000; i++)  
    set.add(i<<32|i);  
set.contains(0);

Det svarer vel til ca. 768KiB. Og det er med kun én forspørgsel til tabellen.
Man kunne også bare gå over til at bruge træer med garenteret performance. Måske er de lige så hurtige som en hashmap med kryptografisk hashing.

Kræn Hansen

Interessant læsning: Her tænker jeg primært på kommentarene.
Måske burde man sende artikler i "beta-release" før de blev udsendt til den glubske forsamling af kritiske læsere :)

Poul-Henning Kamp

Man kunne også bare gå over til at bruge træer med garenteret performance. Måske er de lige så hurtige som en hashmap med kryptografisk hashing.

Det afhænger af dine nøgler. Problemet for generel software, som et programmeringssprog, er at du ikke kan lave nogen antagelser om dine nøgler.

Træer er specielt dårlige for leading-prefix nøgler og derfor valgte jeg at bruge SHA256+træ i Varnish, for at sikre god distribution.

Klaus Post

@Thomas Dybdahl Ahle: Nej - du har misforstået problemet. Læs de linkede artikler igen.

Det handler ikke om "bare" at lave en masse hash-værdier. Det handler om at generere kollisioner, der gør at du er nød til at teste hver enkelt værdi - hvilket er det som hash-træerne skal undgå til at starte med.

Thomas Dybdahl Ahle

@Klaus Post: Jeg tror du misforstår hvor nemme kollisioner kan være at generere. I java hashes en Long som (int)(value^(value>>>32)). Derfor har alle de tal på formen (i<<32|i) samme hash: 0.

At bruge et træ uden nøgler ville selvfølgelig kræve at man i steddet fandt gode og effektive måder at sammenligne de enkelte elementer. Det ville nok være svært for en hashtable over generelle blobs, men i de tilfælde hvor det er nemt, som her ved longs, kan jeg ikke se nogen grund til ikke at gøre det.

Jacob Gorm Hansen

Jesper: Hvordan er det i praksis lettere at gemme en 64-bit hashtabel i hukommelsen? Jeg tror ikke der er mange steder du kan koebe en maskine med 2**64 bytes lager. I stedet for traeer kan man med fordel kigge paa Cuckoo Hashing som faktisk er en dansk opfindelse.

Jacob Christian Munch-Andersen

Cuckoo Hashing løser i hvert fald ikke problemet i sig selv, umiddelbart er det sårbart overfor kæder som kan flytte hele stakken af objekter med en enkelt insert, og derefter flytte hele molevitten tilbage igen med den næste insert osv. Hvis man kan gennemtvinge table rebuilds kan det i mange situationer også være et ret grimt angreb. Vi er vel sådan set blot tilbage ved at hash funktionerne skal være ukendte for angriberen.

Jacob Gorm Hansen

Pointen var ikke at cuckoo hashing beskytter mod angreb, men at 128 bits ikke er vaerre end 64, da det ikke giver mening at lave hashtabeller til nogen af delene. Cuckoo hashing er bedre en traeer fordi man i visse varianter kan komme over 90% pladsudnyttelse (se fx Manasse og Erlingssons udgave). Naturligvis skal man bruge en sikker hashfunktion, og man kan trivielt seede den med et hemmeligt, tilfaeldigt tal for at forhindre angreb. Endelig boer man jo kun bruge hashtabeller hvor det giver mening, da moderne hardware slet ikke bryder sig om random access.

Jacob Christian Munch-Andersen

Det giver såmænd ganske god mening at bruge en del af en stor hash til en hashtabel, man kan så lade hvert punkt i tabellen pege på et søgetræ som anvender hele hash værdien. Man får på den måde den garanterede performance og fleksibiliteten som et søgetræ giver, men man sparer tid ved at bruge et enkelt tabelopslag i stedet for at traversere den første del af et stort søgetræ.

Anders Hessellund Jensen

Endelig boer man jo kun bruge hashtabeller hvor det giver mening, da moderne hardware slet ikke bryder sig om random access.

Det er korrekt at random access i hukommelsen er dyrt, men et binært søgetræ hvor hver knude i træet er allokeret separat på heap'en giver en random access for hvert niveau i træet. Så en hashtabel er klart bedre. En hashtabel giver kun O(1) random accesses per opslag, hvilket er optimalt.

Jacob Gorm Hansen

Nu er der jo heldigvis andet end binaere soegetraeer til, og en simpel hashtabel kan kun lave opslag i konstant tid naar der ikke er kollisioner, hvilket typisk undgaas ved at fordoble tabellens stoerrelse hver gang der er en kollision. Cuckoo hashing og varianter deraf reducerer risikoen for at maatte fordoble, og udnytter dermed pladsen bedre. Et B-trae har ofte bedre lokalitet, specielt naturligvis naar input ikke allerede er hashet, og tillader bl.a. range queries. Mht. at kombinere en hashtabel med et trae, hedder det vist officielt et Van Emde Boas-trae, og har fordele mht. lokalitet ved bl.a. range queries, men er ofte dyrere mht. pladsforbrug.

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen

TDC skifter koncernchef efter faldende mobilomsætning

Jesper Stein Sandal Mobil og tele 14. aug 2015

Nyeste job

KurserStyrk dine evner med et kursus

AUTODESK INVENTOR PRODUKTKONFIGURATION (ILOGIC)

Hvornår: 2015-12-07 Hvor: Østjylland Pris: kr. 9500.00

Implementing Microsoft Azure Infrastructure Solutions [20533]

Hvornår: 2015-10-22 Hvor: Østjylland Pris: kr. 19500.00

Den fængende fortælling

Hvornår: 2015-10-26 Hvor: Storkøbenhavn Pris: kr. 5900.00

PowerPoint kursus grundlæggende

Hvornår: 2015-09-16 Hvor: Storkøbenhavn Pris: kr. 2950.00

Chefsekretæren - sparringspartner og kommunikator

Hvornår: 2015-09-08 Hvor: Østjylland Pris: kr. 7990.00