Nieuws
image

Miljoenen sites kwetsbaar voor nieuwe DoS-aanval

donderdag 29 december 2011, 10:55 door Redactie, 5 reacties

Onderzoekers hebben tijdens het Chaos Communication Congres in Berlijn een nieuwe manier gedemonstreerd om websites plat te leggen, waardoor miljoenen sites risico lopen. De kwetsbaarheid bevindt zich in PHP 4 en 5, Java, Apache Tomcat, Apache Geronimo, Jetty, Oracle, Glassfish, ASP.NET, Python, Plone, CRuby 1.8, JRuby en Rubinius. Allemaal talen waar websites op grote schaal gebruik van maken.

Het soort hashing dat deze talen gebruiken is geen cryptografische hash, maar een wiskundige hash om gegevens op websites op te slaan en op te halen. De talen houden er rekening mee dat "collisions" tussen deze hashes kunnen plaatsvinden. De Duitse onderzoekers hebben een manier gedemonstreerd, zodat een aanvaller via een aantal vooraf berekende waarden, ervoor kan zorgen dat alle hashes hetzelfde zijn. Het vergelijken van al deze hashes veroorzaakt een dusdanig zware belasting op de webserver, dat die vervolgens onbereikbaar wordt.

Oplossing
Vanwege de ernst van het probleem besloot Microsoft een noodpatch uit te brengen en kunnen gebruikers van Ruby naar versie 1.9 upgraden, aldus het Amerikaanse US-CERT. Toch is het probleem niet nieuw. Programmeertaal Perl loste het probleem namelijk al in september 2003 op, zo blijkt uit de release notes, waar "hash randomisation" wordt besproken. Hieronder een overzicht van de gebruikte programmeertalen op het web.

Reacties (5)
29-12-2011, 13:38 door Anoniem
Als ik het verhaal goed begrepen heb, moet je als aanvaller er dus voor kunnen zorgen dat er zo'n hash uitgerekend wordt.
Als je dus een service hebt waarbij "externen" hashes mogen uitrekenen, heb je een probleem. Een ander voorbeeld zou kunnen zijn dat een aanvaller zelf een script op je server kan draaien waar deze hashes worden uitgerekend. Maar volgens mij is je probleem dan vooral dat je aanvaller uberhaupt scripts mag uitvoeren.

Het klinkt me daarom als een vrij academisch probleem.

Kan zijn dat ik iets over het hoofd zie. Please let me know :)
29-12-2011, 14:47 door lucb1e
Hmmm dus als ik een pagina post met een veldnaam van 500KB, zou PHP er 30 seconden ofzo op moeten hangen omdat het die data allemaal naar één hash in de $_POST array parsed. Ik heb het net geprobeerd, maar met 512038 bytes kwam ik toch echt niet verder dan dik een seconde (en dat is op een Intel Atom). Zometeen eens proberen met de post_max_size op mijn server van ~50MB.

Edit: Het heeft totaal geen effect, waarschijnlijk begrijp ik het probleem dan verkeerd (al kan ik natuurlijk lastig vragen of iemand een werkende exploit hier wil posten zodat het duidelijk is, lol).

Edit2: Oh nu snap ik hoe het werkt! Nee eerdere pogingen hadden inderdaad geen effect op deze manier ^^.
29-12-2011, 14:58 door Anoniem
In theorie zou je met een SQL injection in sommige situaties een command injection in het gebruikte script te weeg kunnen brengen.
Maar goed, als je al zo ver bent :P
Andere mogelijkheid is een directe command injection in het gebruikte script.
29-12-2011, 15:35 door Anoniem
13:38 door Anoniem: Ok, ik ben er al uit. Ik zag inderdaad wat over het hoofd. Een goed opgebouwde request is inderdaad voldoende :)
30-12-2011, 10:27 door [Account Verwijderd]
[Verwijderd]
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.

Zoeken
search