Hacket database

http://www.web-dev.dk/post/2008/07/14/SQL-injections-mere-end-bare-et-pling.aspx

hvis du evt kan komme med et kodeeksempel på et typisk SQL-opslag kan vi måske se om det kunne komme derfra.

Jeg har fundet 3 steder hvor der er mulighed for at lave SQL injection. Det skal i hvertfald lukkes. Men kan det være andre steder fra at man ville kunne lave sådan noget? Der er flere databaser på serveren, men det er kun den ene som har fået tilføjet den ekstra tekst. Samtidig er det rigtig mange tabeller som er ramt, men ikke alle. Det er lidt underligt. Det er selvfølgelig noget der skal laves, men jeg ville bare høre om der kunne være andre steder fra man kunne lave sådanne angreb. Men det er vel nærliggende at tro at det er igennem SQL injection de har fået indsat teksten. Jeg er så bare også lidt nysgerrig for at vide hvordan de har lavet sql sætningen. For det har været lidt af et arbejde hvis de har siddet og indsat koden i alle de tabeller og rækker der er.

i teorien ville du kunne finde de statements der er kørt i transaction-loggen - så med lidt held kan du derigennem se hvordan opdateringerne er kommet.

Hvis du ved fejl tillader server-kode at komme ud til klienten kan man på den måde også udstille fx serveroplysninger så dit password/brugernavn nu er offentligt kendt (så skift gerne det hurtigst muligt).

Som nævnt i artiklen er SQL Injection utrolig let at lave - fx ved at manipulere med adresselinjen så

page.aspx?id=2

ændres til

page.aspx?id=2;DITHACKSQL

Ja, det er jo så en anden ting. Jeg har ikke fået rettet min config fil efter at jeg lagt opdateringer ud. Så alt fejlkode er blevet sendt til klienten. Så den har været nem at gå til desværre. Heldigvis er det kun ekstra tekst der er lagt ind. Men i realiteten kunne det hele være lagt ned. Hvordan finder jeg tranaction loggen?

Jeg har ændret brugernavnet og passwordet på min database bruger. Skulle der være andre steder der skal ændres bruger/password?

Kan man ikke udelukke at det er via FTP eller igennem windows server at denne database er hacket?

Jeg fandt loggen. Men jeg synes ikke rigtig at jeg kan se at der er noget at kigge i ang. updates.

du kan aldrig udelukke noget så længe årsagen ikke er fundet - så få gennemgået sikkerheden på serveren, skiftet de passwords der kan skiftes, sørg for at fejl ikke kommer ud til klienten (specielt hvis brugernavn/password til databasen ligger kodet direkte ind) etc...

Det kan godt være at jeg har taget munden lidt for fuld ved at sige at du kunne se statements i loggen - der bliver kun gemt ændringer. Du kan måske i stedet prøve at lege lidt med denne statement på SQL serveren;

SELECT deqs.last_execution_time AS [Time], dest.TEXT AS [Query]
FROM sys.dm_exec_query_stats AS deqs
CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest
WHERE dest.TEXT LIKE '%update%'
ORDER BY deqs.last_execution_time DESC

Hm - den ser ud til kun at vise data for indeværende session. Så er jeg ikke sikker på at det kan lade sig gøre.

Nej jeg ved godt at man ikke kan udelukke andre huller. Jeg er bare hamrende frustreret over at jeg skal bruge et par dage på at genoprette databasen fordi en eller anden spade synes det er sjovt at lægge et link til en eller anden tilfældig hjemmeside ind i alle teksfelter i databasen. Så det havde været rart at man kunne sige at det var igennem SQL injection de havde fået adgang. Nu ved jeg ikke hvor hullet er. Jeg har rettet teksterne, men det kan være smadret igen i morgen hvis jeg ikke har fået lukket hullet.

Så må du trække udvikleren i løn da det, formentlig, er ham du kan takke for manglende sikkerhed i første omgang og ham du kan takke for nu at skulle spilde tid ;)

Der er masser af ting du kan gøre for, måske, at komme det lidt nærmere. Er der fx log over FTP-adgang? Log på serveren over logins? Hvad logger IIS'en af besøgs- og url-historik? Det kunne måske også give inspiration, udover korrekt programmering, til fx fremtidig audit-logging.

Der er ingen tvivl om at det selvfølgelig er irriterende men man kan også vende det om og sige at de kunne have været meget værre - data kunne have været væk eller der kunne have været udstillet følsomme data. Det lyder trods alt som om at din udfordring relativt let kunne løses med et update-script.

Ja, udvikleren er jo så desværre mig selv :-( Og det er desværre et enkelt sted hvor jeg ikke har fået sikret mig. Jeg tror det er der. Jeg mente at have lukket ale huller, men her til eftermiddag, var den gal igen. Desværre inden jeg nåede at tage en ordentlig kopi. Så det er tilbage til opdatering af hver enkelt tabel. Alle passwords til dette site er skiftet. Men jeg undrer mig over at de kan komme ind.

Fandt så lige noget gammelt kode som ikke var sikret. Så håber vi at det var der huller var.

Har du erfaringer med nogle værktøjer til at teste sikkerheden på et site? Og det skal selvfølgelig helst være gratis. Jeg har set nogle stykker, men de skal alle have penge for det. Måske kender du et som er godt.

Du kan evt sætte en Profiler op og se hvad der bliver sendt af SQL statements til databasen - det koster en smule på performance, men næppe noget der kan mærkes.

Google har et projekt der hedder skipfish - har dog aldrig selv brugt det; http://code.google.com/p/skipfish/

Jeg har sat registrering af alle querystrings og inputfelter. Så må vi se om der kommer noget ind. Jeg er jo dels nysgerrig for at se om hullerne er lukket men også hvad der er for SQL der bliver sendt.

Men hvad mener du med at sætte en profiler op?

http://www.codeproject.com/Articles/21371/SQL-Server-Profiler-Step-by-Step

Det ser ud til at jeg har fået lukket hullerne. Men jeg kan stadig se at der forsøges at indsætte SQL. Men det må jeg jo se om det holder op på et tidspunkt. Jeg læser lidt om profiler. Det ser jo ud som om det er noget af det jeg skal bruge for at se om jeg kan finde Synderen :-) Eller i det mindste finde ud af hvordan de indsætter SQL.
Tak for hjælpen.

Hvis det er lykkedes er det super - men en lille sidste kommentar; et meget meget almindeligt problem er desværre også at brugernes klienter, altså din PC, har fået uheldig software installeret og alle passwords m.m. dermed er kendt af nogle der bestemt ikke bør kende det så hvis du ikke allerede har fået det gjort så kør et virus-tjek på din maskine.

Min maskine er ren. Men derfor kunne det selvfølgelig godt være nogen af de andre brugere, har et problem.

@keysersoze
Jeg har lige et tillægsspørgsmål som jeg håber du måske kan svare på.
Jeg har sporet de forskellige requests der bliver lavet, og jeg kan se at der gentagne gange bliver lavet dette request fra den samme ip:_TSM_HiddenField_=ToolkitScriptManager1_HiddenField&_TSM_CombinedScripts_=%3b%3bAjaxControlToolkit%2c+Version%3d4.1.40412.0%2c+Culture%3dneutral%2c+PublicKeyToken%3d28f01b0e84b6d53e%3aen-US%3aacfc7575-cdee-46af-964f-5d85d9cdcf92%3a475a4ef5%3aeffe2a26%3a1d3ed089%3a5546a2b%3a497ef277%3aa43b07eb%3a751cdd15%3adfad98a5%3a3cf12cf1

Ved du om der er noget at komme efter her eller om det er et "lovligt" request??

Mit umiddelbare gæt er at det ser fint ud - det ligner at du benytter AjaxToolKit og det laver vist netop sådan et request. Du kan evt bevæge dig lidt rundt på sitet mens du følger med via Fiddler om hvad der sker af requests.

Synes bare det ser mærkeligt ud. Det er den eneste IP adresse hvor der bliver logget denne mærkelige url. Men det kunne være jeg skulle prøve fiddler.
Endnu engang tak for hjælpen

Du kan evt prøve at sætte CombineScript til false på ToolkitScriptManager og se om det gør noget forskel.