Alvorens we van start gaan met dit artikel wil ik dit even kwijt: JA, dit is gebaseerd op een echte security audit die we uitgevoerd hebben (en toont hoe simpel het soms kan zijn) en JA, de kwetsbaarheden zijn intussen opgelost. Alle identificeerbare bedrijfsinformatie werd aangepast.
Het begon allemaal met een security audit voor een webdesign bedrijf dat een eigen CMS aanbiedt aan zijn cliënteel (denk in de richting van WordPress) waarvan ze de beveiliging wilden testen.
We voerden enkele SQL-injection aanvallen uit, maar zagen al snel dat hun zelfgemaakt IDS (Intrusion Detection System) onze pogingen had opgemerkt en ons geblokkeerd had. We hadden onze IP-adressen kunnen veranderen, maar dat zou te veel IP-adressen en tijd gekost hebben om een geldige SQL-Injection fout te ontdekken.
Dus we gingen een andere aanvalsvector opzoeken: Social Engineering
Via de portfolio van het webdesign bedrijf starten we met opzoeken van enkele klanten. Vervolgens bellen we vanaf het nummer van de klant naar de webdesigners om toegang te vragen tot hun database. Omdat onze Exchange-server “problemen had”, vroegen we hen de inloggegevens door te mailen naar werknemer.bedrijf@gmail.com
De zwakste schakel in een systeem is de menselijke.
We kregen vlot toegang tot de inloggegevens omdat ze een alleen-lezen toegang veilig achtten. (En nee, een account met alleen-lezen rechten op een database is geen excuus om login informatie op te sturen naar een willekeurig Gmail-adres)
We logden in met MySQL Workbench en kregen heel wat tabellen te zien waaronder admin_user_data. We dumpten de hele tabel naar een lokale MySQL instantie om wat onderzoek te doen.
Twee velden sprongen onmiddellijk in het oog: username en password.
We zagen een hele hoop gebruikersnamen, waaronder enkele opvallende zoals:
We bekeken de accounts even van dichterbij.
SELECT username, password FROM admin_user_data WHERE username LIKE ‘waa_’
We zagen meteen dat al deze accounts dezelfde password hash hadden: d9f588ccaefb4042a987bb140a2eb9f0
Aangezien deze hash een unsalted MD5 was, dachten we deze snel te kunnen kraken. Onze eerste dictionary-attack bracht niet veel resultaat op. De bruteforce aanval die we hierna uitvoerden, kraakte deze hash in 3 seconden (inclusief de tijd die de software nodig had om op te starten).
Ons gekraakt paswoord (dhk!28 voor de geïnteresseerden) bleek de admin account/ontwikkelaarsaccount te zijn dat het webdesign bedrijf gebruikte om aanpassingen op maat te maken voor het bedrijf in kwestie.
We probeerden de login en het paswoord op enkele websites van andere klanten en… BINGO! We zijn binnen.
Daarna hebben we een Google Dork gemaakt om login pagina’s voor hun specifieke CMS te zoeken en we keken naar de portfolio van het web agency en vonden maar liefst 73 bedrijfswebsites.
Met de gekraakte ontwikkelaarsaccounts konden we de inhoud van de databases van al deze klanten dumpen en van daaruit ook andere bedrijven hacken (wat we niet gedaan hebben omdat het niet binnen onze scope was). Dankzij de slechte encryptie konden we nu technisch gezien ook de wachtwoorden van elk van hun klanten kraken. Daarnaast konden we checken of ze deze wachtwoorden ook nog gebruikten voor andere services om die dan als nieuwe aanvalsvector te gebruiken.
Wat hebben we geleerd:
Het is opmerkelijk dat zelfs simpele aanvallen zoals deze grote schade kunnen aanrichten aan bedrijven en hun klanten. Indien je als bedrijf een op maat gemaakte security audit wenst, contacteer ons.
