Webframework Django dicht denial of service-kwetsbaarheid

Django, een framework voor webapplicaties dat bovenop Python draait, heeft een kwetsbaarheid gedicht waarmee het relatief eenvoudig was om een denial of service uit te voeren. Door extreem lange wachtwoorden naar een Django-site te sturen, liep de server vast.

Django heeft zondag een tussentijdse fix voor het beveiligingsprobleem uitgebracht, nadat het bestaan van de kwetsbaarheid op een openbare mailinglijst was gemeld. Daardoor was een risico op misbruik ontstaan. Het webapplicatie-framework wordt gebruikt door veel grote sites, zoals Pinterest, Instagram en Mozilla.

De kwetsbaarheid bevond zich in het deel van de code dat het hashen van wachtwoorden afhandelt. Django had echter geen limiet op de wachtwoordlengte. Doordat de standaard-library die in Django wordt gebruikt voor het hashen van wachtwoorden, pbkdf2, intensief voor de server is, konden loginvensters op met Django gebouwde sites worden gebruikt als aanvalsmethode. Aanvallers konden herhaaldelijk extreem lange wachtwoorden verzenden, waardoor de server vastliep.

Door de kwetsbaarheid zouden wachtwoorden overigens niet buitgemaakt kunnen worden. Django slaat net als veel andere softwarepakketten de wachtwoorden van gebruikers zelf niet op, maar enkel een hash van het wachtwoord, waaruit het wachtwoord niet valt af te leiden. Om bij het inloggen het door een gebruiker ingevoerde wachtwoord te kunnen vergelijken met de opgeslagen wachtwoordhash, wordt bij elke inlogpoging het ingevoerde wachtwoord ook gehasht. Daarna kan worden bekeken of de twee hashes overeenkomen.

Om de kwetsbaarheid op te lossen, hebben de ontwikkelaars van Django een maximale wachtwoordlengte van 4096 bytes ingevoerd. Wanneer utf-8-encodering wordt gebruikt, komt dat neer op tussen de 1024 en 4096 karakters. De wijziging is doorgevoerd in recente Django-versies, waaronder de nieuwste versie, 1.5, en bètaversie 1.6.

Reacties (20)

[HollowGamer]

Is dan if (strlen($password) => [max]) voldoende geweest?
Verder goed natuurlijk dat het gedicht wordt.

Waar ik op hoop is dat PHP(5/6) eindelijk een goede functie krijgt om passwords te hashen. De nieuwe hash-functie die in PHP5.5 zit zou al bruikbaar zijn. Zou dit niet op alle frameworks kunnen worden toegepast? Zo is er een standaard die voldoet en veilig is.

[YaPP]

Is dan if (strlen($password) => [max]) voldoende geweest?

Dat is idd het idee.

Leuk om te zien dat onderaan de news pagina ook links staan naar de fix per versie (linkje naar code):
- idd length checks.
- form validatie een max_length gegeven
- unit tests toegevoegd ter controle:

Erg netjes weer

[Reactie gewijzigd door YaPP op 22 juli 2024 14:32]

[MBicknese]

De password functionaliteit van php5.5 is inderdaad veilig en is ook zo opgezet dat het makkelijk te updaten is naar veiligere methodes zonder dat de programmeur meerwerk heeft (mits goed opgezet natuurlijk).

Voor versies voor 5.5 kan je: https://github.com/ircmaxell/password_compat gebruiken. Zo heb je dezelfde functionaliteit en als je wel 5.5 gebruikt wordt het script overgeslagen. Nu dus wachten dat frameworks het oppakken en als standaard gaan implementeren.

[TECHcrime]

Django een maximale wachtwoordlengte van 4096 bytes ingevoerd. Wanneer utf-8-encodering wordt gebruikt, komt dat neer op tussen de 1024 en 4096 karakters

Dit vind ik alsnog erg extreem lang voor een wachtwoord. Als dit het crashen van de server voorkomt, hoe lang moeten de wachtwoorden dan zijn geweest om de server wel te laten crashen?

[matty___]

Hoe lang mag een String in Python zijn?

[S0cky]

Een python string, uitgaande van een 64 bit versie, zal ongeveer 63Gb kunnen zijn. Dus als er geen limiet op stond kan ik me goed voorstellen dat dit mis ging. In dit geval betekend "extreem" groot dus ook echt EXTREEM groot.

[mzziol]

A password one megabyte in size, for example, will require roughly one minute of computation to check when using the PBKDF2 hasher.

Dus zo extreem groot hoeft de string niet te worden om een effectieve aanval uit te voeren.

[Rafe]

Aldus het bronartikel:

A password one megabyte in size, for example, will require roughly one minute of computation to check when using the PBKDF2 hasher.

[biglia]

Ik heb totaal geen kennis van Django. Maar een ontwikkelaar die gebruik maakt van dit framework, zal deze limiet toch ook wel zelf kunnen instellen zeker? Het lijkt me een beetje veel afhankelijk van de servercapaciteit.

[S0cky]

Als je zelf je login page maakt wel maar de meeste django sites die ik ken gebruiken de library die django zelf aanbied omdat je hierbij ook andere dingen gratis meekrijgt (zoals SQL injectie beveiliging).

[Verwijderd]

SQL injectie vind ik echt iets van jaren geleden. Ik snap niet dat dit nog steeds een issue is (schijnbaar). Er zijn hele eenvoudige (standaard) methodes om dit af te handelen, en elke active record library of database wrapper die ik ken zit dit zowat standaard in. Dan heb je ook nog prepared statements op database niveau.

[garagaholic]

SQL injectie blijft een probleem, dat daar oplossingen voor zijn bevestigt dat alleen maar. Django is een MVC framework over Python heen, met z'n eigen ORM en ook bescherming tegen SQL injection. Het zit er dus standaard in, en daarom gebruiken mensen de user libraries van Django; eenvoudig en veilig. Wanneer je je eigen libraries zou gaan schrijven, los van dat alles, dan zou je dus zelf SQL injection moeten afvangen, wat natuurlijk meer moeite met zich meebrengt dan een al bestaande lib gebruiken.

[DeuTeRiuM]

Dat kan, maar hoeft niet. Met de zgn "custom user models" is het mogelijk.

Het is in de meeste gevallen voldoende om de standaard user models te gebruiken. Je kan hier met een OneToOne relatie een profile en meer aanvast plakken. Voor al deze standaard implementaties is de fix.

[supersnathan94]

Dus een Password dat meer dan 1000 tekens heeft word nog steeds geaccepteerd? Wow dat vind ik nog steeds behoorlijk overdreven. een brute force attack op H3lloh3lloh3lloh3lloh3llo! duurt al lang.

[DeuTeRiuM]

Hoezo overdreven? Als jij elke keer de eerste paragraaf van een word-document als wachtwoord hebt, dan is 1024 niet overdreven. Of misschien een of andere tool die enorme passwords voor je genereert. Ik bedoel: er zijn vast mensen die er een rede voor hebben om een lang password, al dan niet automatisch, te kiezen.

Andere vraag: Hoe lang mag een wachtwoord dan maximaal zijn en waarom?

[Godgeneral16]

kijk, dat is altijd fijn als je een lek kan dichten waardoor een DOS aanval moelijker kan worden uitgevoed.

[NetworkDoc]

heb ik geluk dat mijn wachtwoord 1023 tekens lang is...

[Indifstublatia]

the DOS-vulnerability is no longer unchained

[BikkelZ]

Ik gebruik voor de meeste server related dingen een dynamisch gegenereerd random password wat ik opsla in KeyPass. Dat is geen 1000 tekens lang maar ergens rond de 25 of 30 maar ik lach niemand uit die dat wel doet.

Overigens ga ik mijn Django based sites niet direct upgraden denk ik, sites zoals Pinterest, Instagram en Mozilla daar wil een lolbroek nog wel eens een DOS op uitvoeren maar gewone sites platfleggen daar behaalt niemand eer aan.

Het is trouwens een ongebruikelijke zet om zo snel te patchen maar iemand had de vulnerability gemeld op een publieke mailinglist.

Ik ben enorm enthousiast over Django, het voelt compact en klein aan en je hebt heel snel resultaten maar tegelijkertijd is het enorm flexibel.

[Reactie gewijzigd door BikkelZ op 22 juli 2024 14:32]

[Sfynx]

Ik denk dat de echt grote sites wel het e.e.a. aan resource management hebben op serverbreed niveau zodat een zich misdragend proces zoals deze in ieder geval niet de rest van de server onderuit kan halen. Dat is sowieso een goed idee.