Hoe hackers websites overnemen met SQL-injectie en DDoS
Zelfs als je de gebeurtenissen van de hackergroepen Anonymous en LulzSec slechts losjes hebt gevolgd, heb je waarschijnlijk gehoord van websites en services die worden gehackt, zoals de beruchte Sony-hacks. Heb je je ooit afgevraagd hoe ze het doen??
Er zijn een aantal tools en technieken die deze groepen gebruiken, en hoewel we je geen handleiding proberen te geven om dit zelf te doen, is het handig om te begrijpen wat er aan de hand is. Twee van de aanvallen die je consequent hoort, zijn "(Distributed) Denial of Service" (DDoS) en "SQL Injections" (SQLI). Dit is hoe ze werken.
Afbeelding door xkcd
Denial of Service Attack
Wat is het?
Een "denial of service" (soms een "distributed denial of service" of DDoS) -aanval genoemd doet zich voor wanneer een systeem, in dit geval een webserver, zoveel verzoeken tegelijkertijd ontvangt dat de serverbronnen overbelast raken, het systeem eenvoudigweg blokkeert en wordt afgesloten. Het doel en het resultaat van een succesvolle DDoS-aanval is dat de websites op de doelserver niet beschikbaar zijn voor legitieme verkeersaanvragen.
Hoe werkt het?
De logistiek van een DDoS-aanval kan het beste worden verklaard door een voorbeeld.
Stel je voor dat een miljoen mensen (de aanvallers) samenkomen met als doel het bedrijf van Company X te belemmeren door hun callcenter neer te halen. De aanvallers coördineren zodat ze op dinsdag om 9 uur 's ochtends allemaal het telefoonnummer van bedrijf X bellen. Hoogstwaarschijnlijk zal het telefoonsysteem van het bedrijf X niet in staat zijn om een miljoen telefoontjes tegelijkertijd af te handelen, zodat alle inkomende lijnen door de aanvallers worden vastgehouden. Het resultaat is dat legitieme klantenoproepen (dat wil zeggen die niet de aanvallers zijn) niet doorkomen omdat het telefoonsysteem vastzit aan het verwerken van de oproepen van de aanvallers. Dus in essentie verliest bedrijf X potentieel verlies door het feit dat de legitieme verzoeken niet kunnen worden verwerkt.
Een DDoS-aanval op een webserver werkt precies hetzelfde. Omdat er vrijwel geen manier is om te weten welk verkeer afkomstig is van legitieme verzoeken versus aanvallers totdat de webserver het verzoek verwerkt, is dit type aanval meestal zeer effectief.
De aanval uitvoeren
Vanwege de "brute force" aard van een DDoS-aanval, moet je veel computers hebben die allemaal gecoördineerd zijn om tegelijkertijd aan te vallen. Als we bijvoorbeeld ons voorbeeld van een callcenter opnieuw bezoeken, moeten alle aanvallers op beide weten te bellen om 9 uur 's ochtends en daadwerkelijk op dat moment bellen. Hoewel dit principe zeker werkt als het gaat om aanvallen op een webserver, wordt het aanzienlijk eenvoudiger wanneer zombiecomputers worden gebruikt in plaats van echte bemande computers..
Zoals u waarschijnlijk weet, zijn er veel varianten van malware en trojaanse paarden die, eenmaal op uw systeem, sluimeren en zo nu en dan "naar huis bellen" voor instructies. Een van deze instructies kan bijvoorbeeld zijn om herhaalde verzoeken naar de webserver van Company X te sturen om 9 uur 's ochtends. Dus met een enkele update van de thuislocatie van de betreffende malware, kan een enkele aanvaller onmiddellijk honderdduizenden besmette computers coördineren om een enorme DDoS-aanval uit te voeren.
Het mooie van het gebruik van zombiecomputers is niet alleen de effectiviteit, maar ook de anonimiteit ervan, omdat de aanvaller zijn computer helemaal niet hoeft te gebruiken om de aanval uit te voeren.
SQL Injection Attack
Wat is het?
Een "SQL-injectie" (SQLI) -aanval is een exploit die misbruik maakt van slechte webontwikkeltechnieken en, meestal gecombineerd met, gebrekkige databasebeveiliging. Het resultaat van een succesvolle aanval kan variëren van zich voordoen als een gebruikersaccount tot een volledig compromis van de betreffende database of server. In tegenstelling tot een DDoS-aanval, is een SQLI-aanval volledig en gemakkelijk te voorkomen als een webtoepassing op de juiste manier is geprogrammeerd.
De aanval uitvoeren
Wanneer u zich aanmeldt bij een website en uw gebruikersnaam en wachtwoord invoert, kan de webtoepassing een zoekopdracht uitvoeren zoals de volgende om uw referenties te testen:
SELECT UserID FROM Users WHERE UserName = "myuser" AND Password = "mypass";
Opmerking: stringwaarden in een SQL-query moeten tussen enkele aanhalingstekens worden geplaatst en daarom verschijnen ze rond de door de gebruiker ingevoerde waarden.
Dus de combinatie van de ingevoerde gebruikersnaam (myuser) en wachtwoord (mypass) moet overeenkomen met een invoer in de tabel Gebruikers om een gebruikers-ID te kunnen retourneren. Als er geen overeenkomst is, wordt geen gebruikers-ID geretourneerd, zodat de inloggegevens ongeldig zijn. Hoewel een bepaalde implementatie kan verschillen, zijn de mechanica behoorlijk standaard.
Laten we nu dus naar een sjabloonverificatievraag kijken die we kunnen vervangen door de waarden die de gebruiker op het webformulier invoert:
SELECT UserID FROM Users WHERE UserName = "[user]" AND Password = "[pass]"
Op het eerste gezicht lijkt dit een eenvoudige en logische stap om gebruikers gemakkelijk te valideren, maar als een eenvoudige vervanging van de door de gebruiker ingevoerde waarden wordt uitgevoerd op deze sjabloon, is deze vatbaar voor een SQLI-aanval.
Stel bijvoorbeeld dat "myuser'-" is ingevoerd in het veld gebruikersnaam en "wrongpass" is ingevoerd in het wachtwoord. Met behulp van eenvoudige substitutie in onze sjabloonquery, zouden we dit krijgen:
SELECT UserID FROM Users WHERE UserName = "myuser" - 'AND Password = "wrongpass"
Een sleutel tot deze verklaring is de opname van de twee streepjes (-). Dit is het begintokenkunteken voor SQL-instructies, dus alles dat na de twee streepjes (inclusief) wordt weergegeven, wordt genegeerd. In wezen wordt de bovenstaande query door de database uitgevoerd als:
SELECT UserID FROM Users WHERE UserName = "myuser"
De flagrante omissie hier is het ontbreken van de wachtwoordcontrole. Door de twee streepjes op te nemen als onderdeel van het gebruikersveld, omzeilden we volledig de wachtwoordcontrole-voorwaarde en konden we inloggen als "myuser" zonder het respectieve wachtwoord te kennen. Deze handeling van het manipuleren van de query om onbedoelde resultaten te produceren, is een SQL-injectieaanval.
Welke schade kan worden aangericht?
Een SQL-injectie-aanval wordt veroorzaakt door nalatige en onverantwoordelijke applicatiecodering en is volledig te voorkomen (wat we in een ogenblik zullen behandelen), maar de omvang van de schade die kan worden veroorzaakt, is afhankelijk van de database-instelling. Om een webtoepassing te laten communiceren met de back-enddatabase, moet de applicatie een login voor de database leveren (let op, dit is iets anders dan een gebruikersaanmelding bij de website zelf). Afhankelijk van de machtigingen die de webtoepassing vereist, kan dit respectieve databaseaccount om het even wat vragen, van lees- / schrijfrechten in bestaande tabellen tot volledige databasetoegang. Als dit nu niet duidelijk is, zouden een paar voorbeelden voor meer duidelijkheid moeten zorgen.
Op basis van het bovenstaande voorbeeld kunt u dat zien door bijvoorbeeld in te voeren, "youruser '-", "admin' -" of een andere gebruikersnaam, kunnen we onmiddellijk als die gebruiker inloggen op de site zonder het wachtwoord te kennen. Als we eenmaal in het systeem zijn, weten we niet dat we niet echt die gebruiker zijn, dus hebben we volledige toegang tot het betreffende account. Databasemachtigingen bieden hiervoor geen vangnet, omdat een website doorgaans ten minste lees- / schrijftoegang tot zijn respectieve database moet hebben.
Laten we nu aannemen dat de website volledige controle heeft over zijn respectieve database die de mogelijkheid biedt om records te verwijderen, tabellen toe te voegen / te verwijderen, nieuwe beveiligingsaccounts toe te voegen, enz. Het is belangrijk op te merken dat sommige webtoepassingen dit type toestemming nodig hebben, zodat het is niet automatisch een slechte zaak dat volledige controle wordt verleend.
Om de schade die in deze situatie kan worden gedaan te illustreren, gebruiken we het voorbeeld in de bovenstaande strip door het volgende in te voeren in het veld voor de gebruikersnaam: "Robert"; DROP TABLE Users; - ". Na een eenvoudige vervanging wordt de verificatiequery:
SELECT UserID FROM Users WHERE UserName = "Robert"; DROP TABLE Users; - 'AND Password = "wrongpass"
Opmerking: de puntkomma in een SQL-query wordt gebruikt om het einde van een bepaalde instructie aan te geven en het begin van een nieuwe instructie.
Welke wordt uitgevoerd door de database als:
SELECT UserID FROM Users WHERE UserName = "Robert"DROP TABLE Gebruikers
Dus net zo hebben we een SQLI-aanval gebruikt om de hele tabel Gebruikers te verwijderen.
Natuurlijk kan er nog veel erger aan gedaan worden, afhankelijk van de toegestane SQL-rechten, kan de aanvaller waarden veranderen, tabellen (of de hele database zelf) naar een tekstbestand dumpen, nieuwe inlogaccounts maken of zelfs de hele database-installatie kapen..
Voorkomen van een SQL-injectie-aanval
Zoals we al verschillende keren eerder hebben vermeld, is een SQL-injectie-aanval gemakkelijk te voorkomen. Een van de belangrijkste regels voor webontwikkeling is dat u nooit blind op de invoer van gebruikers vertrouwt, zoals we deden toen we eenvoudige substitutie uitvoerden in onze sjabloonquery hierboven.
Een SQLI-aanval wordt gemakkelijk gedwarsboomd door wat wordt genoemd het zuiveren (of ontsnappen) van uw invoer. Het zuiveringsproces is eigenlijk vrij triviaal, omdat het in essentie alleen maar alle inline enkele aanhalingstekens (') op de juiste manier verwerkt, zodat ze niet kunnen worden gebruikt om een tekenreeks binnen een SQL-instructie voortijdig te beëindigen..
Als u bijvoorbeeld 'O'neil' in een database wilt opzoeken, kunt u eenvoudige vervanging niet gebruiken omdat het enkele aanhalingsteken na de O ervoor zorgt dat de tekenreeks voortijdig eindigt. In plaats daarvan zuiver je het door het escape-teken van de betreffende database te gebruiken. Laten we aannemen dat het escape-teken voor een inline enkel aanhalingsteken elke quote met een \ -symbool voorafgaat. Dus "O'neal" zou worden gezuiverd als "O \ 'neil".
Deze eenvoudige sanitaire handeling voorkomt vrijwel een SQLI-aanval. Ter illustratie laten we onze vorige voorbeelden opnieuw bekijken en de resulterende query's bekijken wanneer de invoer van de gebruiker is opgeschoond.
myuser'-- / wrongpass:
SELECT UserID FROM Users WHERE UserName = "myuser \" - 'AND Password = "wrongpass"
Omdat het enkele aanhalingsteken nadat myuser is geëscaped (wat betekent dat het als een deel van de doelwaarde wordt beschouwd), de database letterlijk naar de gebruikersnaam van "Myuser '-". Omdat de streepjes zijn opgenomen in de tekenreekswaarde en niet de SQL-instructie zelf, worden ze bovendien als onderdeel van de doelwaarde beschouwd in plaats van te worden geïnterpreteerd als een SQL-opmerking.
Robert '; DROP TABLE Gebruikers;-- / wrongpass:
SELECT UserID FROM Users WHERE UserName = "Robert \"; DROP TABLE Users; - 'AND Password = "wrongpass"
Door simpelweg te ontsnappen aan het enkele citaat achter Robert, bevinden zowel de puntkomma als de streepjes zich in de zoekreeks van de gebruikersnaam, zodat de database letterlijk naar "Robert"; DROP TABLE Users; - " in plaats van de tafel te verwijderen.
Samengevat
Hoewel webaanvallen evolueren en geavanceerder worden of zich richten op een ander punt van binnenkomst, is het belangrijk om te onthouden dat u moet beschermen tegen beproefde aanvallen die de inspiratie waren van verschillende vrij beschikbare 'hacker-tools' die zijn ontworpen om ze te exploiteren.
Bepaalde typen aanvallen, zoals DDoS, kunnen niet gemakkelijk worden vermeden, terwijl andere, zoals SQLI, dit wel kunnen. De schade die kan worden toegebracht door dit soort aanvallen kan echter variëren van een ongemak tot catastrofaal, afhankelijk van de genomen voorzorgsmaatregelen..
