User input saniteren + Hearthbleed in simpel Nederlands

Soon to be blog 1:


Waarom ik een blogpost schrijf terwijl mijn blog nog "under construction" is?
Omdat ik veels te vaak een van de volgende vragen krijg:
- "Is het saniteren van user input nu echt zo belangrijk"
- "Welke inputs moet ik saniteren?"
- "Waarom kan ik niet gelijk uit de $_GET lezen"?
maar vooral omdat iedereen het heeft over de openssl bug "heartbleed"

Hoe kwam ik erop om vandaag de blog te schrijven?
Eerder vandaag heeft een of andere "handige Joris" geprobeerd op Mi-Soft.nl misbruik te maken van het e-mail formulier.
Dit door te proberen code te injecteren in de website. Dit is hem / haar echter niet gelukt omdat ik de
user input afvang en controleer op narigheid (sanitize).
Had ik dit niet gedaan dan had deze "handige Joris" zijn testscript met succes kunnen uitvoeren.

Een voorbeeld van een "injectie" is als volgt:

- 1' or '1'='1'
   Deze injectie wordt gebruikt om in te loggen op een pagina waar de "hacker" geen toegang toe zou moeten hebben. Deze injectie werkt op niet gesaniteerde inlogvelden vrijwel altijd. Dit omdat de gehele query als volgt wordt:

-- Select * from members where name = 'username' and password = '1' or 1=1

Deze query geeft ALTIJD een positieve reactie.
De naam en het wachtwoord doen er niet toe want we zeggen tegen de database:
selecteer alles waar de naam "username" is en het wachtwoord "1" of als 1 gelijk is aan 1. Zoals u ziet is dat laatste stukje cruciaal! 1 is altijd gelijk aan 1!
De "hacker" zal dan ook in kunnen loggen op andermans account.

====== Hearthbeat bug (heartbleed)
Dan komen we bij de grote openssl bug heartbleed (ja dit hele verhaal lijd nog tot iets productiefs!), zelfs een groot project zoals openSSL heeft nog wel eens last van een niet gesaniteerde user input!

Ok ok.... ik overdrijf misschien een (klein) beetje.
Ik zal in normaal Nederlands even uitleggen hoe heartbeat(de echte naam van de functie) werkt.

Heartbeat is eigenlijk een super simpel ding. Iemand stuurt een pakketje, een server ontvangt en leest dat pakketje, en vervolgens stuurt de server een reactie. Normaliter stuurt een applicatie of website dit pakketje. En in dat geval wordt het pakketje keurig opgemaakt en verstuurd.

Het probleem zit hem echter in de opbouw (en afvang) van zo'n pakketje.
Het pakketje is namelijk opgebouwd uit een aantal stukjes. Voor het gemak zeggen we even dat het pakketje bestaat uit 2 stukjes(dat is niet zo):
- Een nummer
- Het bericht

Als we een normaal pakketje sturen met een bericht (payload) van 2 woorden dan zouden we het pakketje als volgt opmaken:
2|woord woord
In dit geval stelt de | de scheiding tussen het nummer en het bericht voor.
De server ontvangt dit dan en voert de volgende stappen uit:

* ontvang pakketje
* lees hoeveel woorden (2)
* lees woorden
* maak antwoord op
    * kopieer nummer voor aantal woorden uit het geheugen
    * kopieer [insert nummer](2) woorden uit het geheugen

Niks mis mee, de applicatie krijg netjes weer een pakketje terug met de volgende inhoud:
2|woord woord

Maar nu ga ik, als de superhacker die ik ben, zo'n heartbeat pakketje maken.
Echter ben ik een "bad guy" en ga ik me dus niet aan de regels houden.
Ik vul als nummer namelijk "256" in en stuur lekker maar 1 woord mee.
Het pakketje ziet er dus als volgt uit:
256|woord

Nu doet de server de volgende stappen weer:
* ontvang pakketje
* lees hoeveel woorden (256)
* lees woorden
* maak antwoord op
    * kopieer nummer voor aantal woorden uit het geheugen (nog steeds 256)
    * kopieer [insert nummer](256) woorden uit het geheugen

Ik had echter maar 1 woord meegestuurd dus de server kan onmogelijk MIJN 256 woorden uit het geheugen halen. Echter hebben we tegen de server wel gezecht dat deze 256 woorden moet halen uit het geheugen. En dat doet het beestje dan ook braaf.

Maar waar komen de 255 andere woorden dan vandaan?? De 255 woorden zijn dus andere dingen die nog in het geheugen stonden! En dat kan vanalles zijn, ook inlognamen en wachtwoorden!

Nu stuurt de server mij dus een pakketje terug met mijn woord, en 255 andere woorden.
Als ik dit vaak genoeg doe dan krijg ik uiteindelijk vanzelf een keer een wachtwoord van een andere gebruiker (want in de pc wereld gaat alle data ooit het geheugen in).
Een zeer gevaarlijke bug dus!

Hoe is deze bug opgelost??
Simpel! Door niet uit te gaan van het nummer dat het pakketje meegeeft, maar door de woorden echt te tellen.
Als ik dus een pakketje stuur met de inhoud:
256| woord
Dan telt de server nu het aantal woorden achter de streep (1) en retourneerd dat aantal (1) woorden ook weer terug.


Een van de grootste bugs dit jaar was dus een user input fout!

Ik hoop dat iedereen na dit artikel nog eens gaat nadenken over het belang van het saniteren van de user input.
En om daar nog een handje bij te helpen wil ik jullie verwijzen naar: http://bobby-tables.com/
Een website waar stukjes code staan om SQL injections te voorkomen.


Disclaimer: Ik heb de werking van openSSL (voornamelijk de heartbeat functie) hier heel simpel weergegeven, als u wilt weten hoe het precies werkt kunt u de sourcecode van openSSL downloaden op: http://www.openssl.org/source/