Website Hacken Demo – XSS

In deze eerste korte demo “Website Hacken” laat ik zien hoe gemakkelijk het soms kan zijn om een website te hacken. Deze demo is gedaan op een echte / bestaande website met toestemming van de website eigenaar. Wel laten we uit veiligheidsoverwegingen en andere belangen de domeinnaam / merknaam weg uit deze demo.

Onderstaande lek is gevonden tijdens een routine website PEN Test (penetration test). Deze lek was dus aanwezig maar niet gevonden door automatische scripts / bots.

Voorwerk:

Tijdens het voorwerk van de PEN Test worden alle website gegevens in beeld gebracht. Alle veilige en vooral alle onveilige gebieden worden op de kaart gezet. Zodra deze op de kaart staan wordt de (on)veiligheid later verder onderzocht. Op deze website betreft 1 van de zwakke delen de zoekmachine. De zoekmachine genereerd na een zoekopdracht de volgende URL:

http://www.vulnerablewebsite.nl/search?search_keyword=

Een zoekopdracht als deze kan gemakkelijk geïndexeerd en gegoogled worden. We spreken hier dus van een Google Dork.

Dit maakt de zoekmachine al potentieel gevaarlijk. Als de zoekmachine echter zijn zoekopdrachten netjes afhandelt dan is er geen probleem. Om dit te testen voeren we standaard HTML code is.

<h1>

Dit resulteert in de volgende broncode na het uitvoeren van de zoekopdracht:

Dit ziet er nog goed uit. Nu controleren we de output met de volgende code:

"><h1>

Dit resulteert in de volgende broncode:

Nu wordt het gevaarlijk. Bovenstaande zoekcode sluit de huidige zoekopdracht (value waarde) af middels de quote en de record separator. Hierna wordt de alternatieve HTML code geladen in de pagina.

De zoekmachine / website sanitized (valideert) de ingevoerde data niet goed. Als de website dit wel goed had gedaan dan was de value waarde niet afgesloten en had het er als volgt uitgezien:

value="<h1>"

Vatbaarheid testen:

Omdat de zoekmogelijkheid een XSS potentie bevat is het zaak dat we deze verder uitzoeken.

XSS staat voor Cross Site Scripting. De juiste afkorting zou CSS zijn maar deze was al bezet. Met wat fantasie staat de X voor een kruisje (cross). Met Cross Site Scripting is een hacker zelf in staat om zijn eigen malafide scripts te draaien. Hoe dit werkt zien we hieronder als we de lek verder gaan uittesten.

Eerst testen we de volgende code:

http://www.vulnerablewebsite.nl/search?search_keyword= "><h1>Deze website is XSS vatbaar</h1>

Dit geeft de volgende output:

De website laat dus specifieke HTML output zien. Zo kunnen we dus ook een afbeelding in de webpagina laden.

Om dat te doen gebruiken we:

http://www.vulnerablewebsite.nl/search?search_keyword=">
<img src=//www.jarnobaselier.nl/wp-content/themes/wp-creativix/images/logos/q5-logo-security.png />

De output is dan als volgt:

HTML kan gevaarlijk zijn maar Javascript is een stuk gevaarlijker. Om dat te testen vullen we op dezelfde manier javascript code in (onderstaande code moet een popup met tekst tonen):

"><script>alert("test")</script>

Dit resulteert niet in de gewenste output. De broncode ziet er dan als volgt uit:

Het probleem hier is dat de quotes “escaped” (verwijderd) worden (waarschijnlijk door de PHP.ini “magic quotes” setting). Deze setting kunnen we gemakkelijk omzeilen door de JavaScript “String.formCharCode” te gebruiken. Met deze string kunnen we decimalen gebruiken. Bovenstaande code komt er nu uit te zien als:

"><script>alert(String.fromCharCode(116, 101, 115, 116));</script>

Het resultaat is als volgt:

Op bovenstaande manier kunnen we iframes en redirects implementeren die naar malafide websites verwijzen. Dit doen we als volgt (in dit voorbeeld redirecten we naar Google.nl maar dat had gemakkelijk een andere website kunnen zijn:

"><script>document.location.href=(String.fromCharCode(104, 116, 116, 
112, 58, 47, 47, 119, 119, 119, 46, 103, 111, 111, 103, 108, 101, 46, 110, 108));</script>

Bovenstaande scenario’s kunnen we uitwerken tot heel gevaarlijke scenario’s. En als wij het kunnen doen hackers het zeker.

De gevaren van XSS

Een website die vatbaar is voor HTML of script injectie kan heel gevaarlijk zijn voor bezoekers. Bovenstaande voorbeelden noemen we “non-persistent XSS” omdat deze URL’s gemaakt kunnen worden maar nergens opgeslagen worden.

Er bestaan ook “persistent XSS” aanvallen. Dit zijn XSS code’s die worden opgeslagen in b.v. de database. Dit principe zien we vaak op forums terug. Als de handtekening van de berichten vatbaar is voor XSS kan geheime XSS code geladen worden tijdens het laden van het forum. Persistent XSS wordt dus geladen op het moment dat een webpagina laad. Hier hoeft geen handmatige actie voor ondernomen te worden. Om “non-persistent” XSS te laden moet men altijd een handmatige actie uitvoeren (b.v. op een speciaal ontwikkelde URL klikken).

Met XSS kunnen hackers hele gevaarlijke dingen doen. Denk hierbij aan:

• Malware / virus infectie verspreiden
• Sessie cookies stelen (en zo inloggen met jou gegevens)
• Verkrijgen van administrator toegang tot de website
• Valse pagina’s maken om zo gebruikersgegevens of persoonlijke gegevens te stelen
• Choquerende / aanstootgevende afbeeldingen laten zien
• DOS aanvallen lanceren
• Etc…

Als je website succesvol misbruikt is door een XSS aanval dan zal het vertrouwen van de bezoekers dalen en kan Google je website registreren als “gevaarlijke website”. Dit komt de SEO ranking niet ten goede en kan resulteren in een tijdelijke of permanente ban.

Encrypted XSS

Bovenstaande codes bevatten leesbare code. Meestal wordt code omgezet naar hexadecimale code zodat deze niet meer leesbaar is. Sommige mensen zullen dus minder snel vermoeden dat deze code een gevaarlijk script bevat. Ook zal hexadecimale code veel sneller scanners en filters omzeilen dan de standaard code.

Deze XSS code:

"><script>alert(String.fromCharCode(116, 101, 115, 116));</script>

ziet er omgezet uit als:

%22%3E%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%53%74%72%69%
6E%67%2E%66%72%6F%6D%43%68%61%72%43%6F%64%65%28%31%31%36%2C%
20%31%30%31%2C%20%31%31%35%2C%20%31%31%36%29%29%3B%3C%2F%73%63%72%69%70%74%3E

Beveiligen tegen XSS:

Het beveiligen tegen XSS is lastig. Dit is compleet afhankelijk van het gebruikte systeem, code en vatbaarheid. Gebruikers kunnen scripting uitschakelen in de browser maar dan werken de meeste websites niet meer goed. Websites die wel scripting mogen toepassen kunnen worden toegevoegd aan de “vertrouwde websites” maar dit is erg omslachtig. Gebruikers gaan er gewoon vanuit dat de website veilig is tegen XSS aanvallen.

Het vatbare gedeelte voor XSS moet zo ingesteld worden dat deze gebruikersdata netjes valideert en speciale karakters en HTML of script tags verwijderd. Om dit te doen kunnen 2 library’s gebruikt worden:

• Microsoft AntiXSS
• OWASP Enterprise Security API

Een workaround / verbetering is door gebruik te maken van de PHP “htmlspecialchars” of “htmlentities” string om speciale HTML karakters om te zetten naar veilige HTML Char tekens.

De string:

Deze tekst is <b>vet</b> gedrukt.

wordt dan omgezet naar:

Deze tekst is <b>vet</b> gedrukt.

Bovenstaande code is niet uitvoerbaar en dus onschadelijk.
In het geval van een zoekmachine zou je de code kunnen veranderen van:

value="<?php $zoekwoord; ?>">

naar:

value="<?php htmlspecialchars($zoekwoord); ?>">

Conclusie:

Bovenstaande voorbeeld is een voorbeeld uit de praktijk en betreft een XSS lek dat om meerdere manieren misbruikt had kunnen worden. Bovenstaande voorbeeld is een van de mogelijkheden om het XSS lek te misbruiken. Meer voorbeelden volgens in latere posts. Wanneer een XSS lek aangetroffen wordt is het zaak om deze zo spoedig mogelijk op te lossen. Het oplossen hiervan kan erg lastig zijn. Uit kostenoverweging hebben wij het lek uit bovenstaande systeem opgelost door een compleet nieuwe zoekmachine te implementeren die ook beter aan de wensen van de klant voldeed en voorzien was van een veel betere validatie. Ben en blijf alert op dit soort XSS lekken. Hackers kunnen je website ernstig misbruiken en het is gebeurt voordat het te laat is. Test je eigen website regelmatig of laat deze voor u testen.