Het is op eerste kerstdag precies dertien jaar geleden dat SQL Injection werd ‘geboren’, reden voor Security.nl om dieper op het ontstaan van deze technologie in te gaan, waardoor nog altijd talloze websites worden gehackt. Net als mensen ziek kunnen worden, hebben ook websites gebreken die vaak lange tijd onder het oppervlakte blijven zweven, totdat het gebrek zich openbaart. Als mensen door zaken als de griep en andere nare virussen worden geplaagd, is SQL Injection een plaag op het web. De afgelopen jaren zijn letterlijk honderden miljoen persoonsgegevens via deze techniek gestolen. Hoewel SQL Injection als iets klinkt dat door een dokter wordt toegediend, is het allesbehalve een kuur, maar een omvangrijk probleem waar zowel websites als internetgebruikers dagelijks mee te maken krijgen.
Waren websites in het begin van het web nog plat en statisch, al gauw draaide het om dynamiek en interactie. Gebruikers moesten zaken in een website kunnen opvragen of hun eigen opdrachten invoeren. Denk hierbij aan een webwinkel die allerlei producten aanbiedt. In plaats van alles handmatig op losse HTML pagina's te plaatsen, werden databases gebruikt die de informatie genereerden. Daardoor hoefde de eigenaar van bijvoorbeeld een webwinkel alleen de database bij te houden. De gebruiker vertelt tegen de website welk artikel hij wil zien, de website vertaalt dit aan de database, de database geeft de gevraagde informatie aan de website terug, die het weer aan de gebruiker laat zien.
Naast producten verzamelt een webwinkel ook gegevens over klanten, zoals adresgegevens, e-mailadres en wachtwoord voor het webwinkel account. Al die informatie wordt vaak in dezelfde database als de productgegevens bewaard. Voor het communiceren met en beheren van de database wordt SQL (Structured Query Language) gebruikt. Deze taal stuurt vraagstellingen naar de database, en geeft vervolgens de antwoorden terug aan de website.
Bepaalde delen van de database, zoals bijvoorbeeld e-mailadressen en wachtwoorden, zijn normaal niet toegankelijk voor bezoekers. De website biedt gebruikers daarnaast niet de mogelijkheid om de wachtwoorden van andere gebruikers op te vragen. In het geval van SQL Injection wordt de vraagstelling van de gebruiker niet goed gecontroleerd, waardoor die toch om wachtwoorden en andere informatie kan vragen en deze ook te zien krijgt.
Geschiedenis
SQL Injection werd voor het eerst genoemd in de 54ste editie van hackerblad Phrack Magazine. Het magazine verscheen op 25 december 1998 en ging onder andere over "NT Web Technology Vulnerabilities". De auteur beschrijft de mogelijkheid hoe "mensen hun SQL opdrachten aan jouw SQL opdrachten kunnen toevoegen." De oplossing volgens de auteur is niet aannemen dat de input van gebruikers voor SQL queries van de website is te gebruiken. En dat is meteen de kern van het probleem waar websites dertien jaar later nog steeds mee te maken hebben, namelijk dat de invoer van gebruikers niet goed gecontroleerd wordt. Een website moet zo zijn geprogrammeerd dat een bezoeker in zijn vraagstelling alleen om producten mag vragen, en niet om wachtwoorden en e-mailadressen.
Sinds die eerste publicatie eind 1998 maakt SQL Injection een stormachtige ontwikkeling door. Op 4 februari 1999 verschijnt een advisory over "Multiple SQL Statements in Dynamic Queries". Volgens de waarschuwing ondersteunen sommige databases de mogelijkheid om meerdere SQL opdrachten met een query mee te sturen. Daardoor is het mogelijk om kwaadaardige SQL opdrachten aan bestaande queries toe te voegen. Volgens Allaire dat de advisory uitstuurt, moeten bedrijven hun code zo schrijven, dat aan SQL opdrachten meegegeven variabelen, worden gevalideerd.
Datadiefstal
De eerste gedocumenteerde toepassing van SQL Injection, vindt begin 2000 plaats. De hacker "Rain Forest Puppy", die het SQL Injection-artikel in Phrack 54 schreef, weet via de techniek beheerderstoegang tot het forum van security website Packetstorm te krijgen en maakt daar de wachtwoorden van 800 gebruikers buit. Een bericht dat makkelijk in het nieuws van vandaag zou kunnen verschijnen, ware het niet dat dit al bijna twaalf jaar geleden plaatsvond.
De term SQL Injection verschijnt in 2000 voor het eerst op internet. Chip Andrews plaatst de "SQL Injection FAQ" online. Een dag later geeft beveiligingsonderzoeker David Litchfield een presentatie genaamd “Application Assessments on IIS”. Daarin bespreekt hij ook het aanvallen van database servers via ASP applications door het gebruik van “SQL insertion”. Volgens de onderzoeker gebruikte het SANS instituut de term SQL Injection ook in de wekelijkse nieuwsbrief, rond dezelfde tijd als Andrews. "Wie de eerste was is niet duidelijk." Het Sans nieuwsbrieven archief uit 2000 staat niet meer online.
In april van 2001 is het wederom Litchfield die een nieuw paper over SQL Injection uitbrengt. “Remote Web Application Disassembly using ODBC error messages” beschrijft verschillende nieuwe technieken hoe via SQL Injection de structuur van de database applicatie is te bepalen. De volgende grote stap in SQL Injection werd in januari 2002 gezet. Chris Anley publiceert een paper genaamd “Advanced SQL Injection in SQL Server Applications”, waar hij uitgebreid op SQL Injection ingaat. Uiteindelijk volgt Anley met een paper over het gebruik van time delays voor het vinden van informatie in de database.
Tools
In hetzelfde jaar is het Cesar Cerrudo die naast een paper over het manipuleren van Microsoft SQL Server via SQL Injection, ook een tool genaamd DataThief biedt. Via deze tool is het mogelijk om via de Openrowset functie vraagstellingen naar de server te sturen. SQL Injection houdt onderzoekers bezig, want een jaar later komen Ofer Maor en Amichai Shulman met hun onderzoek naar 'blindfolded sql injection'. Bij "blind sql injection" is de webapplicatie kwetsbaar voor SQL Injection, maar worden de resultaten van de vraagstelling niet aan de aanvaller getoond.
Deze vorm van SQL Injection is tijdsintensief, omdat de aanvaller voor elke gevonden informatie een aparte vraagstelling moet maken. Er zijn echter tools die dit proces automatiseren. De eerste blind sql injection tool wordt tijdens de Black Hat conferentie van 2004 gepresenteerd. "SQueal", tegenwoordig bekend als Absinthe, automatiseert Blind SQL Injection-aanvallen.
Verfijning
Tussen 2004 en 2008 wordt SQL Injection verder "Verfijnd" en verschijnen nieuwe papers en tools. De meeste SQL Injection-aanvallen in deze jaren hebben het voorzien op het stelen van database en andere gegevens. In 2008 wordt SQL Injection voor het eerst op geautomatiseerde en grootschalige manier ingezet om kwetsbare websites te hacken. De aanval voegt vervolgens kwaadaardige code (exploit) toe, die bezoekers van de website infecteert met malware als ze niet hun software up-to-date hebben. Soms worden honderdduizenden websites tegelijkertijd gekraakt. Net als veel websites voor SQL Injection kwetsbaar zijn, blijken veel gebruikers beveiligingsupdates niet te installeren.
Toekomst
“Het probleem van SQL Injection is eigenlijk nooit veranderd. Wel zijn de aanvallen geraffineerder geworden, door gebruik te maken van INFORMATION_SCHEMA en timing/error trucs kan nog eenvoudiger de gehele database worden uitgelezen. Deze aanvallen worden tegenwoordig zeer eenvoudig gemaakt door tools als sqlmap en Havij”, zegt Frank van Vliet, CTO van Certified Secure.
“Een goede manier om SQL Injection te voorkomen zijn de zogenaamde parametric queries”, merkt Van Vliet op. Hiermee wordt in het commando aangegeven welke gegevens gebruikersinvoer zijn, zodat deze goed en structureel kunnen worden gecontroleerd. “Ook worden steeds vaker frameworks gebruikt waardoor de ontwikkelaar zelf geen SQL commando's meer zal schrijven.”
De ontwikkeling van SQL Injection laat zien dat het voor cybercriminelen een veelzijdig wapen is, dat zowel kostbare gegevens als besmette computers kan opleveren. Ondanks de leeftijd van SQL Injection en grote impact, negeren nog altijd veel websites dit probleem, waarvan de oorzaak even oud als de oplossing is. Het ziet er dan ook niet naar uit dat dit de laatste verjaardag van SQL Injection zal zijn.
Deze posting is gelocked. Reageren is niet meer mogelijk.