Parameter Tampering

Vandaag gaan we het onderwerp “Parameter Tampering” bespreken. Sounds like a lot of fun right?

Parameter Tampering is een technische term die letterlijk vertaald “Parameter Sabotage” betekend. Parameter Tampering is een techniek die door hackers gebruikt wordt om je website of webapplicatie te misbruiken voor hun eigen gewin. Deze aanval is gebaseerd op de manipulatie van parameters die uitgewisseld worden tussen cliënt en server.

Stel jezelf het volgende voor:

Een webshop gebruikt verschillende velden om de hoeveelheid en maat van een product te selecteren. Deze velden worden doorgegeven aan de server tijdens een bestelling. Als een gebruiker deze gegeven kan onderscheppen en door kan zenden (met een MiTM – Man in the Middle attack) dan kan deze ervoor zorgen dat je 10 i.p.v. 1 product besteld of dat je een hele andere maat besteld dan dat je aanvankelijk had geselecteerd.

Bovenstaande voorbeeld is een simpel voorbeeld van Parameter Tampering (het aanpassen van parameters). Maar Parameter Tampering kan veel ergere gevolgen hebben. Denk hierbij aan het aanpassen van prijzen (op je webshop) of het belasten van een creditkaart van een klant met een veel hoger bedrag dan bedoeld.

Waar worden parameters gebruikt?

Parameters worden op veel plaatsen gebruikt. Denk hierbij aan:

• De URL (route of query string)
• POST commando (ingevuld formulier)
• Cookies
• HTTP Request Headers
• Database (commando’s)
• Externe scripts en services
• Etc.

De URL en HTTP Request Header bevatten vaak POST en GET gegevens (in geval van query string) welke parameters bevatten die eventueel misbruikt kunnen worden. De HTTP Request Header is een tekst string die de browser naar de server verzend om data op te vragen. Zie hieronder een voorbeeld van de parameters in een HTTP Request Header die misbruikt zouden kunnen worden:

Onveilige data:

Zonder dat er op direct merkbaar is gebeurt er op de achtergrond dus best veel met de data. Zodra data onveilig behandeld of onveilige data toegelaten wordt maken we “Parameter Tampering” mogelijk. Wanneer een hacker bijvoorbeeld de SQL querystring aan kan passen in een URL wordt de SQL query ineens onveilige data.

Onveilige data is data waarvan we de integriteit niet kunnen verifiëren of data waarvan het doel niet bijdraagt in de noodzaak van de gebruiker (data waar de gebruiker niet om vraagt).

Een goed systeem met afdoende beveiliging en controle zal onveilige data weigeren en tegenhouden. Dit gebeurt met behulp van access controls, server-side validatie, model binding en cliënt-side validatie. Het is overigens aan te raden om die laatste zo min mogelijk te gebruiken omdat deze redelijk simpel te omzeilen (of misbruiken) is. Stel je voor dat Javascript gebruikt wordt om een formulier te valideren dan heeft dit als voordeel dat de server niet met validatie belast wordt en dat er data van en naar de server gezonden moet worden. Maar als een hacker de controle over de cliënt heeft kan deze er ook voor kiezen om Javascript uit te schakelen en om het formulier dus toch te verzenden als niet alle velden (correct) zijn ingevuld. Met cliënt-side validatie is niets mis maar het is aan te raden om deze samen met server-side validatie te gebruiken.

Voorbeeld:

Hoe gaat Parameter Tampering in zijn werk. Ok, een simpel voorbeeld. In dit voorbeeld maken we gebruik van de Fiddler tool. Fiddler is een web debug proxy die veel gebruikt wordt door internet hackers.

Op onze voorbeeldwebsite hebben we een kleine enquête staan die vraagt naar de tevredenheid van product X. Om mijn stem te kunnen geven moet ik inloggen met een unieke ID die ik via de e-mail heb ontvangen.

Nog voor ik in ga loggen start ik Fiddler. Met Fiddler pak ik alle data die van en naar mijn PC verzonden worden. Ne het inloggen stem ik een 8 op product X. In de ruwe data van Fiddler zie ik het volgende:

userID=9&productID=390&voteID=8

Vervolgens kan ik de request in de composter tab van Fiddler opnieuw samenstellen met andere parameters.

Ik kan het volgende veranderen:

userID=9&productID=380&voteID=8

Ik heb nu het productID veranderd waardoor ik op product Y een 8 stem. Maar dat alleen is nog geen Parameter Tampering. Ik stem nu namelijk op een ander product maar dat had ik ook gewoon via de website kunnen doen. De website applicatie gedraagt zich nu nog normaal (mits een ingelogde gebruiker maar 1 keer had mogen stemmen op 1 product).

Nu verander ik het volgende:

userID=15&productID=390&voteID=2

Nu stemt gebruiker 15 nogmaals op product X en deze gebruiker stemt een 2. Dit is iets wat natuurlijk nooit had gemogen.

Dit voorbeeld is simpel maar er zijn heel veel websites zo geprogrammeerd dat deze simpele truck gewoon werkt. Een veilige site met goede access control zou gebruik maken van een veilige authenticatie cookie die het userID verifieert.

Bovenstaande truck kan natuurlijk vele ergere gevolgen hebben. Zo zou een hacker ook het bedrag van een bestelling aan kunnen passen zodat hij iets t.w.v. 100 euro koopt voor slechts 10 euro.

Mass Assignment Risk

Een Mass Assignment Rist ontstaat wanneer een data model misbruikt kan worden. Een model is een geautomatiseerd proces dat data afhandeling op een gestructureerde manier verwerkt. Er bestaan diverse modellen (per Framework). Voor een ontwikkelaar is een model fantastisch. Zolang een ontwikkelaar de juiste attributen gebruikt zal het model deze weten te koppelen aan de juiste waardes in de database. Het nadeel van een model is dat deze ook misbruikt kunnen worden.

Stel voor u heeft een simpel formulier met 2 velden, een voornaam en een achternaam. Wanneer deze verzonden worden naar de server kan een hacker het model achterhalen. Als een model meerdere velden ondersteund zou de hacker de header aan kunnen passen en deze extra velden toe kunnen voegen (ook al staan deze dus niet in het formulier). Het model zal de velden netjes verwerken en de hacker slaagt erin om meer waardes te manipuleren dan door de ontwikkelaar bedoeld is. Het gebrek aan controle op inkomende parameters is een Mass Assignment Risk. Een controle die toegepast zou kunnen worden is een “Attribute Whitelist” waarop de attributen vermeld staan die het framework automatisch mag binden (verwerken).

HTTP Verb Tampering

Een HTTP Request kan diverse “verbs” (commando’s) bevatten. De meest bekende zijn wellicht de POST en GET verbs maar er zijn ook hele andere verbs zoals PUT, TRACE, OPTIONS, HEAD, CONNECT en DELETE. De meeste web applicaties zullen zo gemaakt zijn dat ze alleen reageren op POST en GET commando’s. Andere methodes moeten buiten de HTML aangeroepen worden maar Javascript en AJAX mogen wel andere methodes aanroepen.

Zo zou bijvoorbeeld “input sanitizing” en zelfs “output encoding” omzeild kunnen worden wanneer we een formulier posten met het POST i.p.v. het GET commando omdat de applicatie anders reageert op een POST commando. Het lijkt wat vreemd maar dit scenario komt soms voor. Het aanpassen van de HTTP Verb kan hele interessante gevolgen hebben waarmee een hacker XST (Cross Site Tracing), XSS (Cross Site Scripting), SQLi (SQL Injection) aanvallen kan uitvoeren.

Om jezelf te beschermen tegen HTTP Verb aanvallen moet je ervoor zorgen dat alleen HTTP Verb gegevens geaccepteerd worden die worden verwacht (query string of POST-gegevens). Zorg dat gegevens gecontroleerd (sanitized) worden en dat alleen de parameters geaccepteerd worden die in de frontend verwerkt kunnen worden.

Fuzz Testing

Fuzz Testing is een testmethode die vaak (semi-)geautomatiseerd wordt uitgevoerd. Gedurende een Fuzz test wordt het computerprogramma voorzien van verschillende soorten data. De Fuzz Tester (of hacker) bekijkt alle reacties die op deze data retour komen. Zo wordt het computerprogramma getest met willekeurige, onjuiste of onverwachte data. Vervolgens wordt er gekeken wat er gebeurt. Crashed het programma, wordt er een (waardevolle) foutmelding geretourneerd of ontstaat er een memory leak.

Fuzz testing is een aanvulling op het manueel testen van een applicatie. Omdat manueel testen veel tijd en kennis kost is Fuzz testing altijd een mooi startpunt. XSS, SQLi, Directory Traversal en veel andere aanvallen volgen vaak eenzelfde patroon. Een Fuzz Testing applicatie kent deze ook en test de applicatie automatisch op de meest voorkomende gevaren.

Een paar bekende Fuzz Testing Tools zijn:

• OWASP WSFuzzer
• SPIKE Proxy
• WebScarab
• Intruder21 (integreerd met Fiddler)
• FuzzDB (Google)

Fuzz Testing is en geweldige methode voor ontwikkelaars maar wordt natuurlijk door hackers op dezelfde manier gebruikt om zwakheden te ontdekken. Het is dus zaak om jezelf eerst te hacken en om de hackers voor te zijn.

Conclusie:

Dit hoofdstuk was een korte introductie in “Parameter Tampering”. Hopelijk heb je een idee van onveilige data en op welke lokaties zich parameters bevinden die misbruikt kunnen worden. Ga er altijd vanuit dat een hacker HTTP requests zal onderzoeken en elke parameter zal proberen te misbruiken wat kan resulteren in een XSS, SQLi of andere aanval. Probeer ook niet teveel uit te gaan van cliënt-side validatie maar probeer waar mogelijk ook altijd server-side validatie te gebruiken. Weet welke HTTP Verbs er zijn en hoe deze misbruikt kunnen worden en voorkom “Mass Assignment Risks”. Tenslotte is het altijd belangrijk om zelf de risico’s te ontdekken alvorens een hacker dat doet. Hack jezelf daarom en beveilig de risico’s die hiermee gevonden worden. Met een goede Fuzz Test worden vaak al veel problemen gevonden.