Hvordan hackere tar over nettsteder med SQL Injection og DDoS
Selv om du bare har løst fulgt hendelsene til hackergruppene Anonymous og LulzSec, har du sikkert hørt om at nettsteder og tjenester blir hacket, som de beryktede Sony hackene. Har du noen gang lurt på hvordan de gjør det?
Det finnes en rekke verktøy og teknikker som disse gruppene bruker, og mens vi ikke prøver å gi deg en håndbok for å gjøre dette selv, er det nyttig å forstå hva som skjer. To av angrepene du konsekvent hører om dem bruker, er "(Distributed) Denial of Service" (DDoS) og "SQL Injections" (SQLI). Slik fungerer de.
Bilde av XKCD
Denial of Service Attack
Hva er det?
Et "tjenestenavn" (noen ganger kalt "distribuert denial of service" eller DDoS) angir at når et system, i dette tilfellet en webserver, mottar så mange forespørsler om gangen at serverressursene er overbelastede, låses systemet bare opp og slår seg ned. Målet og resultatet av et vellykket DDoS-angrep er at nettsidene på målserveren ikke er tilgjengelige for legitime trafikkforespørsler.
Hvordan virker det?
Logistikken til et DDoS-angrep kan best forklares med et eksempel.
Tenk deg at en million mennesker (angriperne) kommer sammen med målet om å hindre selskap Xs virksomhet ved å ta ned sitt call center. Angrepene koordinerer slik at de tirsdag kl 9 vil alle ringe til selskapets telefonnummer. Sannsynligvis vil selskapets telefonsystem ikke kunne håndtere en million samtaler samtidig, så alle innkommende linjer vil binde opp av angriperne. Resultatet er at legitime kundeanrop (det vil si de som ikke er angriperne) ikke kommer gjennom fordi telefonsystemet er bundet opp med å håndtere anropene fra angriperne. Så i utgangspunktet mister selskapet X potensielt tap på grunn av at de legitime forespørsler ikke klarer å komme igjennom.
Et DDoS-angrep på en webserver fungerer akkurat på samme måte. Fordi det er nesten ingen måte å vite hvilken trafikk som kommer fra legitime forespørsler mot angripere til webserveren behandler forespørselen, er denne typen angrep vanligvis svært effektiv.
Utfør angrepet
På grunn av den "brute force" -arten til et DDoS-angrep, må du ha mange datamaskiner som alle koordineres for å angripe på samme tid. Ved å revidere vårt call center-eksempel vil dette kreve at alle angriperne begge vet å ringe klokka 9.00 og faktisk ringe på den tiden. Mens dette prinsippet sikkert vil fungere når det gjelder å angripe en webserver, blir det betydelig lettere når zombie-datamaskiner, i stedet for faktiske bemannede datamaskiner, utnyttes..
Som du sikkert vet, er det mange varianter av skadelig programvare og trojanere som en gang på systemet ligger i hvilemodus og av og til "telefon hjemme" for instruksjoner. En av disse instruksjonene kan for eksempel være å sende gjentatte forespørsler til Company Xs webserver kl. 9.00. Så med en enkelt oppdatering til hjemstedet til respektive malware, kan en enkelt angriper øyeblikkelig koordinere hundrevisusvis av kompromitterte datamaskiner for å utføre et massivt DDoS-angrep.
Skjønnheten ved å utnytte zombie-datamaskiner er ikke bare i sin effektivitet, men også i sin anonymitet da angriperen ikke faktisk trenger å bruke datamaskinen i det hele tatt for å utføre angrepet.
SQL Injection Attack
Hva er det?
Et SQLI-angrep (SQL Injection) er en utnyttelse som utnytter dårlige webutviklingsteknikker og, vanligvis kombinert med feil databasesikkerhet. Resultatet av et vellykket angrep kan variere fra å utgjøre en brukerkonto til et komplett kompromiss av den respektive databasen eller serveren. I motsetning til et DDoS-angrep, er et SQLI-angrep helt og enkelt forhindret hvis et webprogram er riktig programmert.
Utfør angrepet
Når du logger inn på et nettsted og oppgir brukernavn og passord, kan du prøve å teste legitimasjonene dine, og det kan hende at webapplikasjonen utfører en spørring som følgende:
SELECT UserID FROM Brukere WHERE UserName = "myuser" OG Password = "mypass";
Merk: strengverdier i en SQL-spørring må være vedlagt i enkelt anførselstegn, og derfor vises de rundt de brukerverdiene som er angitt.
Så kombinasjonen av det angitte brukernavnet (myuser) og passordet (mypass) må samsvare med en oppføring i brukertabellen for at en UserID skal returneres. Hvis det ikke er noen kamp, blir ingen UserID returnert, slik at påloggingsinformasjonen er ugyldig. Mens en bestemt implementering kan variere, er mekanikken ganske standard.
Så nå, la oss se på en forespørsel om malautentisering, som vi kan erstatte verdiene brukeren kommer inn på webskjemaet:
SELECT UserID FROM Users WHERE UserName = "[bruker]" og passord = "[pass]"
Ved første øyekast kan dette virke som et enkelt og logisk trinn for å enkelt validere brukere, men hvis en enkel substitusjon av de brukerdefinerte verdiene utføres på denne malen, er den utsatt for et SQLI-angrep.
For eksempel, anta at "myuser" - "er skrevet inn i brukernavnet og" feilpass "er oppgitt i passordet. Ved å bruke enkel substitusjon i vår mal forespørsel, ville vi få dette:
SELECT UserID FROM Brukere WHERE UserName = "myuser" - 'OG Password = "wrongpass"
En nøkkel til denne setningen er inkluderingen av de to bindestrekene (-). Dette er begynnelsestoken for SQL-setninger, slik at alt som vises etter de to bindestrekene (inkluderende) vil bli ignorert. I hovedsak er ovennevnte spørring utført av databasen som:
SELECT UserID FROM Brukere WHERE UserName = "myuser"
Den skarpe utelatelsen her er mangelen på passordkontrollen. Ved å inkludere de to bindestrekene som en del av brukerfeltet, overgikk vi helt passordkontrolltilstanden og kunne logge inn som "myuser" uten å vite det respektive passordet. Denne handlingen med å manipulere spørringen for å produsere utilsiktede resultater er et SQL-injeksjonsangrep.
Hvilken skade kan gjøres?
Et SQL-injeksjonsangrep er forårsaket av uaktsom og uansvarlig applikasjonskoding og er helt forebyggbar (som vi vil dekke i et øyeblikk), men omfanget av skadene som kan gjøres avhenger av databasens oppsett. For at en webapplikasjon skal kommunisere med backenddatabasen, må søknaden gi et innloggingsregister til databasen (merknad, dette er annerledes enn en brukerinnlogging til selve websiden). Avhengig av hvilke tillatelser webapplikasjonen krever, kan denne respektive database-kontoen kreve alt fra lese / skrive-tillatelse i eksisterende tabeller bare til full databasetilgang. Hvis dette ikke er klart nå, bør noen eksempler bidra til å gi litt klarhet.
Basert på eksempelet ovenfor kan du se det ved å skrive inn, for eksempel, "youruser" - "," admin "-" eller et annet brukernavn, kan vi umiddelbart logge inn på nettstedet som den brukeren uten å vite passordet. Når vi er i systemet, vet vi ikke at vi egentlig ikke er brukeren, så vi har full tilgang til den respektive kontoen. Databasetillatelser gir ikke et sikkerhetsnett for dette fordi et nettsted vanligvis må ha lese / skrive tilgang til sin respektive database.
La oss nå anta at nettstedet har full kontroll over sin respektive database, som gir muligheten til å slette poster, legge til / fjerne tabeller, legge til nye sikkerhetskontoer, etc. Det er viktig å merke seg at enkelte webprogrammer kan trenge denne typen tillatelse, så det Det er ikke automatisk en dårlig ting at full kontroll er gitt.
For å illustrere skaden som kan gjøres i denne situasjonen, bruker vi eksemplet som er angitt i tegneserien ovenfor ved å skrive inn følgende i brukernavn-feltet: "Robert"; DROP TABLE Brukere; - ". Etter enkel substitusjon blir autentiseringsspørsmålet:
SELECT UserID FROM Users WHERE UserName = "Robert"; DROP TABLE Brukere; - 'OG Passord = "feilpass"
Merk: Semikolonet er i en SQL-spørring brukes til å indikere slutten av en bestemt setning og begynnelsen av en ny setning.
Som blir utført av databasen som:
SELECT UserID FROM Brukere WHERE UserName = "Robert"DROP TABLE Brukere
Så akkurat slik har vi brukt et SQLI-angrep for å slette hele bruker-tabellen.
Selvfølgelig kan mye verre gjøres som, avhengig av de tillatte SQL-tillatelsene, kan angriperen endre verdier, dumpe tabeller (eller hele databasen selv) til en tekstfil, opprette nye påloggningskontoer eller kapre hele databasen installasjonen.
Forhindre et SQL-injeksjonsangrep
Som vi nevnte flere ganger tidligere, er det enkelt å forhindre et injeksjonsangrep i SQL. En av de kardinale reglene for webutvikling er at du aldri stoler på brukerinngang som vi gjorde da vi utførte enkel substitusjon i vår mal forespørsel ovenfor.
Et SQLI-angrep blir enkelt forstyrret av det som kalles sanitizing (eller escaping) dine innganger. Sanitize-prosessen er faktisk ganske triviell, fordi alt det egentlig gjør, er å håndtere alle inline-enkeltnoteringer (') tegn på riktig måte slik at de ikke kan brukes til å for tidlig avslutte en streng inne i en SQL-setning.
For eksempel, hvis du ønsket å lete opp "O'neil" i en database, kan du ikke bruke enkel substitusjon fordi det enkle sitatet etter O ville føre til at strengen slutter for tidlig. I stedet skal du sanitere det ved å bruke den respektive databasens fluktegn. La oss anta at fluktegnene for et inline-tilbud er prefacing hvert sitat med et \ -symbol. Så "O'neal" ville bli sanitized som "O \ 'neil".
Denne enkle sanitetsbehandlingen forhindrer ganske mye et SQLI-angrep. For å illustrere, la oss gå tilbake til våre tidligere eksempler og se de resulterende spørringene når brukerinngangen er sanitert.
gammelbruker'-- / wrongpass:
SELECT UserID FROM Brukere WHERE UserName = "myuser \" - 'OG Password = "wrongpass"
Fordi det enkelte sitatet etter myuser er rømt (som betyr at det regnes som en del av målverdien), vil databasen bokstavelig talt søke etter Brukernavn av "Gammelbruker '-". I tillegg, fordi bindestrekene er inkludert i strengverdien og ikke selve SQL-setningen, vil de bli vurdert som en del av målverdien i stedet for å bli tolket som en SQL-kommentar.
Robert '; DROP TABLE Brukere;-- / wrongpass:
SELECT UserID FROM Users WHERE UserName = "Robert \"; DROP TABLE Brukere; - 'OG Passord = "feilpass"
Ved å bare slippe det enkle sitatet etter Robert, er både semikolonet og bindestrekene inneholdt i Brukernavn-søkestrengen, slik at databasen lettere vil søke etter "Robert"; DROP TABLE Brukere; - " i stedet for å utføre tabellen slett.
Oppsummert
Mens webangrep utvikler seg og blir mer sofistikert eller fokuserer på et annet inngangssted, er det viktig å huske å beskytte mot prøvde og sanne angrep som har vært inspirasjonen til flere fritt tilgjengelige "hackerverktøy" designet for å utnytte dem.
Visse typer angrep, for eksempel DDoS, kan ikke lett unngås mens andre, for eksempel SQLI, kan. Skaden som kan gjøres ved disse typer angrep kan imidlertid variere alt fra en ulempe til katastrofale avhengig av de forholdsregler som er truffet.
