En PC & Nätverksteknikers tankar

Det har rapporterat om en sårbarhet i "Newsletter 2.x Plugin" för WordPress, vilket kan utnyttjas av illasinnade personer för att utföra "SQL-injection"-attacker.

Indata till parametern "newsletter" i stnl_iframe.php är inte sanerad innan de används i SQL-frågor. Detta kan utnyttjas för att manipulera SQL-frågor genom att injicera godtycklig SQL-kod.

Vid en framgångsrik exploatering kan t.ex. hämta administratören användarnamn, lösenord hashes, och e-postadresser, men det krävs kunskaper om databasens tabell prefix.

Källa: Milw0rm

Säkerhetsföretaget Sophos varnar för att delar av BusinessWeek är preparerad med skadlig kod. Angripare har utnyttjat sig av en SQL-injektion och hundratals sidor på deras rekryteringsportal har infekterats. När man besöker siten, så körs ett skadligt script från en rysk site, vilket gör att datorn riskerar att infekteras.

- BusinessWeek, och många andra företag som drabbats av SQL-injektioner, måste snabbt inte bara ta bort de skadliga scripten, men också försäkra sig om att de inte infekteras igen. Företag vars webbsiter blivit utsatta för en sådan attack rensar ofta bara bort det från databasen, för att bara några timmar senare infekteras igen, säger Graham Cluley på Sophos.

Enligt Sophos så infekteras uppemot 16 000 sidor varje dag, varav de allra flesta är att betrakta som legitima siter, där angriparna fått in den skadliga koden exempelvis genom att utnyttja en sårbarhet.

Källa: Techworld.

Googles Bloggspot.com är också en bidragande resurs för virusmakare och beräknas stå för ca 2% av alla infekterade sidor under juni 2008. Bloggsidorna används för att sprida skadlig kod och för att sprida länkar till skadliga webbsidor genom blogg kommentarer.

Samtidigt som SQL-injektioner är på frammarsch, har antalet infekterade e-postmeddelanden minskat under samma period. Under början av 2007 var 1 av 332 brev infekterade. Under samma period detta år har andelen minskat till 1 av 2500.

En webbapplikation är sårbar för SQL-injektion då icke-validerad indata används för att bygga upp en SQL-sats. Antag att parametrarna "username" och "password" inte valideras i metoden "loginUser" (se kodexempel nedan). En användare kan då ange "' or '1'='1" i lösenordsfältet vilket ger följande SQL-sats (indata från lösenordsfältet är markerat i fet stil): select * from user_login where user='hubba' and pwd='' or '1'='1';

Denna SQL-sats returnerar aldrig ett tomt "result set" varför "loginUser" alltid returnerar "true". Angriparen har således kommit förbi autentiseringen. Eftersom SQL är uttrycksfullt är denna typ av sårbarhet allvarlig. Exempelvis kan angriparen utföra CRUD-operationer (Create, Read, Update, Delete), läsa meta-data eller anropa "stored procedures" vilka kan ha kopplingar till operativsystemet. För att skapa en applikationsanvändare i vårt exempel kan följande anges (";" terminerar en SQL-sats och "--" inleder kommentar):

• select * from user_login where user='hubba' and pwd=''; insert into user_login values ('99', 'lucifer', 'dfgGSba71X_'); --';

// -- Sårbar Java-kod --
public boolean loginUser(Connection dbConn, String username, String password) throws SqlException {
String sql = "select * from user_login where user='" + username + "' and pwd='" + password + "'";
Statement stmt = dbConn.createStatement();
try {
return stmt.executeQuery(sql).next();
} finally {
stmt.close();
}
}

Lösningen på problemet är att aldrig konkatenera ihop en SQL-sats utan parametrisera den. Det går att göra i de flesta programmeringsspråk. Så här ser det ut i Java:

// -- Säker Java-kod --
public boolean loginUser(Connection dbConn, String username, String password) throws SqlException {
String sql = "select * from user_login where username=? and password=?";
PreparedStatement stmt = dbConn.prepareStatement(sql);
stmt.setString(1, username);
stmt.setString(2, password);
try {
return stmt.executeQuery().next();
} finally {
stmt.close();
}
}

Webbplatser baserade på ASP har varit mest drabbade av automatiserade attacker. Här att ett exempel i ASP:

' -- Sårbar ASP-kod --
' Assume that objConn holds connection to db.
strCmd = "select user_id, user_name from users where user_name='" + strUserName + "' AND password='" + strPassword + "'"
Set objCommand.ActiveConnection = objConn
objCommand.CommandText = strCmd
objCommand.CommandType = adCmdText
Set objRS = objCommand.Execute()
' Process the resultset

Problemet är att SQL-satsen konkateneras ihop med indata, precis som i Java-exemplet. Lösningen är densamma, nämligen att parametrisera SQL-satsen genom att använda "CreateParameter" och "Parameters.Append".

' -- Säker ASP-kod --
' Assume that objConn holds connection to db.
strCmd = "select user_id, user_name from users where user_name=? AND password=?"
Set objCommand.ActiveConnection = objConn
objCommand.CommandText = strCmd
objCommand.CommandType = adCmdText
Set param1 = objCommand.CreateParameter ("user", adWChar, adParamInput, 20)
param1.value = strUserName
objCommand.Parameters.Append param1
Set param2 = objCommand.CreateParameter ("password", adWChar, adParamInput, 50)
param1.value = strPassword
objCommand.Parameters.Append param2
Set objRS = objCommand.Execute()
' Process the resultset

Skydd mot SQL-injektion

Följande kan göras för att skydda sig då applikationen utvecklas:

• Använd parametrisera SQL-satser. Bygg aldrig ihop en SQL-sats med indata. Se ovan för kodexempel.
• Sanitetskontrollera och validera indata. All indata ska behandlas som ond! Använd ett klassbibliotek för validering av strängfält, datum, heltal, e-postadresser med mera. Viktigt är att valideringen inte sprids ut i koden, utan samlas på ett ställe. JavaScript-validering i klienten kan förhöja användbarheten men går inte att förlita sig på ur ett säkerhetsperspektiv. All indata måste valideras igen på servern eftersom en angripare lätt kan manipulera ett HTTP-anrop. Var restriktiv där det går, undvik exempelvis [<, >, ", #, --, ;, %, ?, @] i ett förnamnsfält. I vissa fall måste "farliga" tecken tillåtas, exempelvis kan citationstecken och "enkelfnutt" förekomma i kommentarsfält.
• Anropa enbart "Stored Procedures" (SP). För att öka skiktningen kan alla SQL-satser i applikationen innehålla anrop till en SP istället för exempelvis en "select"-sats. Fördelen är att applikationen arbetar mot ett väl definierat gränssnitt, och det underliggande databasschemat kan ändras utan att gränssnittet och därmed applikationen påverkas. Lösningen ger även säkerhetsmässiga fördelar då det är mer naturlig att parametrisera SP-kod. Observera dock att det ingen garanti, eftersom det även i en SP går att konkatenera ihop SQL-satser. En annan fördel med skiktningen är att all SQL-kod samlas på ett och samma ställe, vilket underlättar kodgranskning.
• Kodgranskning. Det finns två typer av kodgranskning:
• Manuell: En utvecklare går igenom någon annans kod för att hitta buggar och säkerhetshål. Nyttigt och lärorikt om det görs kontinuerligt i utvecklingsteamet. För att leta efter SQL-injektionshål kan koden genomsökas efter förekomster av exempelvis "executeQuery()" (Java), "Execute()" i "ADODB.Command"-klassen (ASP) eller "Open()" i "ADODB.RecordSet"-klassen (ASP). En modern IDE underlättar arbetet, där det går att söka på exempelvis "alla anrop till denna metod" istället för rena textsökningar.
• Automatiserad: En applikation går igenom källkoden och utför en statisk analys av den. MSCASI (Microsoft Source Code Analyzer for SQL Injection) är ett gratisverktyg som letar efter SQL-injektionsproblem i ASP-kod. För Java finns liknande verktyg, exempelvis Findbugs som är mycket användbar för generell analys. Findbugs är öppen källkod och är även integrerad i en kommersiell produkt som är mer inriktad på att hitta säkerhetsrelaterade buggar.
• Automatiserade testverktyg. Denna typ av verktyg letar efter säkerhetshål genom att "spindla" applikationen för att ta reda på potentiellt sårbara sidor, och skickar sedan specialkonstruerade HTTP-anrop till dessa sidor. Microsoft har tillsammans med HP tagit fram verktyget Scrawlr som finns i en nerbantad gratisversion. Sqlmap är ett annat alternativ baserat på öppen källkod. Denna typ av verktyg är inte språkspecifika, exempelvis kan Sqlmap användas för att testa både Java- och ASP-applikationer. Samtidigt är vissa typer av sårbarheter knutna till plattformen, varför vissa testverktyg lämpar sig bättre än andra till en specifik applikation. Verktygen är också olika duktiga på olika typer av SQL-injektion. Att använda flera verktyg kan därför vara en bra lösning.
• Logga. Vettig loggning i applikationen kan vara till stor hjälp vid en incident. Loggning förhindrar inte en SQL-injektion, men loggarna kan avslöja vilken del av koden som är sårbar.
  

Följande kan göras för att skydda en befintlig applikation:

• Databasanvändare med begränsade privilegier. Webbapplikationen ska använda en egen användare i databasen med så få privilegier som möjligt. Använd aldrig "sa"-användaren eller motsvarande.
• Applikationsbrandvägg. En applikationsbrandvägg fungerar som ett filter. Om URL:en innehåller en misstänkt SQL-injektion omdirigeras besökaren till en felsida. För Apache finns mod_security. Microsoft erbjuder gratis programmet UrlScan. Tyvärr är UrlScan 2.5 för primitiv för att skydda effektivt mot SQL-injektionsattacker eftersom det inte går att filtrera på "query"-delen av URL:en (dvs. allt efter "?"). Den nya versionen, UrlScan v3.0 Beta, är mer kraftfull och tillåter filtrering på "query strings". Tänk på att testa filtret ordentligt innan det tas i produktion. Blockas de URL:er som ska blockas? Håll koll på loggarna eftersom det finns risk att legitim trafik filtreras bort. De finns en rad kommersiella alternativ till UrlScan som ofta innehåller fler funktioner.
• Övervaka webbserverns loggarna. Använd ett övervakningsprogram, exempelvis OSSEC, för att upptäcka möjliga attacker. Liksom applikationsloggar är webbserverns loggar vara värdefulla vid en incident.
• En IDS (Intrusion Detection System), till exempel Snort, som lyssnar på trafiken till webbservern på paketnivå och varnar vid potentiella attacker är också ett värdefullt skydd. En IDS upptäcker endast angrepp medan en IPS (Intrusion Prevention System) även kan förhinda angrepp då den blockerar otillåten trafik.
  

Gunnar Sträng använde både hängslen och livrem, och satte dessutom fast sin plånbok i fickan med en säkerhetsnål. Han visste att god säkerhet bygger på många lager. Förlita dig inte på en metod eller ett verktyg, utan använd alltid flera.

Avslutningsvis vill vi tipsa om WebGoat, vilket är en applikation full av säkerhetshål gjorda med flit. Genom att exprimentera runt i applikationen fås en bra förståelse för hur en SQL-injektion fungerar.

Det går inte längre att vara säker på att det inte finns hot även på siter som man normalt litar på. Den slutsatsen kan man dra av en rapport som säkerhetsföretaget Scansafe gjort.

Istället för att försöka sig på direkta attacker genom att leta efter säkerhetshål i olika system eller få någon att lämna ut sitt lösenord så sker många attacker nu genom att man använder SQL-Injection och liknande metoder för att sprida spyware och annat. Koden läggs då in på en site som tillhör ett respektabelt företag som aldrig skulle sprida skadlig kod.

68% av den skadliga kod som Scansafes system stoppade maj 2008 kom från "hederliga" siter. Det är en ökning med 220% på ett år. Tittar man specifikt på spyware som stjäl lösenord eller installerar bakdörrar ligger ökningen under samma period på hela 855%.

Mambo är ett CMS-system (Content Manager System) implementerat i PHP. Två sårbarheter har upptäckts:

• SQL injection: Parametrarna articleid samt mcname i index.php valideras otillräckligt och används i en SQL-sats. Detta kan leda till exekvering av valfri SQL. För att utnyttja sårbaren krävs dock att inställningen magic_quotes_gpc är avslagen, vilket inte är rekommenderat i en standardinstallation.


• HTTP-response-splitting: Indata från HTTP-anropet valideras inkorrekt, vilket gör det möjlig att lägga till rader i sidans HTTP header.
  

Mambo 4.6.4 innehåller rättningar till ovanstående problem.

Botnätet Asprox har tidigare mest användts för phishing. De senaste dagarna har det byggts om för att infektera webbsidor och därifrån smitta besökare.

Ett botnät som tidigare mest använts för phishing har börjat infektera webbsidor. Den nya versionen av de små program som utgör klienterna i botnätet Asprox har utrustats med funktionen att leta efter sårbara webbsidor skrivna i Active Server Pages, ASP. När det skadliga programmet hittar en sån sårbar ASP-installation lägger det in en attack-kod i ASP-sidan som försöker smitta webbsidans besökare genom en SQL-injektion.

Den senaste månaden har en liknande attack med trojaner som stjäl lösenord till online-spel infekterat cirka en halv miljon Windowsdatorer. Den attacken ska enligt en talesman för IT-säkerhetsföretaget Secure Works ha kommit från hackare i Kina. Samma talesman, Joe Stewart, säger att den attack som nu sker via botnätet Asprox ser ut som ett sätt att härma attacken som infekterat en halv miljon datorer. Det är dock första gången han sett ett botnät användas för att sprida en SQL-baserad attack. Han tror också att den kommer från Östeuropa.

Själva attacken på webbplatsen sker genom att lägga in en iFrame i sidans kod coh sen smitta besökare med ett skadligt Javascript från domänen "direct84.com". I går hade Asprox infekterat över tusen webbplatser på det sättet, enligt nyhetstjänsten Dark Reading.

Asprox använder också attacken för att rekrytera nya botar till nätverket. Idagsläget består det av cirka 15 000 smittade datorer. Det skickar också ut "scare ware" det vill säga att det varnar för att datorn är smittad och uppmanar användaren att köpa ett program som tar bort smittan. Enligt Stewart är det inte klart vad det är i programmet som användaren köper, det hanteras av ett partner-företag till Asprox. Däremot ger det Asprox-ägaren lite extra pengar och kreditikortsnumret till folk som går att lura på det sättet.

Enligt Virus Total är det idag bara ett fåtal antivirusprogram som upptäcker den typ av attack som Asprox använder.

Ibland är världen rätt ironisk. Vad sägs om en webbplats om en utbildning i informationssäkerhet - som blir hackad och innehöll skadlig kod.

VHS sajt om lediga studieplatser infekterades genom en SQL-injektion. På webbplatsen låg sen ett javascript som pekade på domänen www.nihaoel3.com. En uppmärksam läsare tipsade IDG om detta. De ringde runt lite och kunde konstatera att alla delar av högskoleväsendet inte går helt i takt. Efter ett par timmar stod det dock klart att det faktiskt var en äkta sajt och inte en bluff-sajt som satts upp av bedragare för att lura studenter.

Per Zettervall är IT-chef på Verket för Högskoleservice,VHS. Han bekräftar att VHS hackats genom en brist i SQL-hanteringen.
- Det ska vara till täppt nu och är rapporterat till incidenthanteringen hos Umdac som kör sajten, säger han.
Den sida som javascriptet pekade på är registrerad i Kina.
- Hela databasen var korrupt men det fanns en frisk kopia från 15 maj som vi rullade tillbaka till.

Internet Storm Center går nu ut med en varning om en ny mask som smittar webbsajter innehållandes SQL-databaser. Genom att utföra en enkel sökning på t.ex. Google kan du kontrollera om din sajt har drabbats.

Internet Storm Center arbetar med att spåra webbhot, och har nu hittat en ny mask som har siktat in sig på sajter med SQL-databaser. Ännu så länge har den endast infekterat ca 4 000 sajter, inte så allvarligt för att vara en web-attack, men detta är bara början.

Om du vill kontrollera om din sajt har smittats kan du göra en enkel sökning med Google. I sökrutan skriver du då "site:www.dindomän.se winzipices.cn". Får du då en eller flera träffar på denna sökning så bör du informera den som är ansvarig för sajten.

Källa: Computerworld

En hackad sajt ger i bästa fall dålig PR, i värsta fall kommer kundregistret på drift tillsammans med användarnas inloggningsuppgifter och kreditkortsnummer. En sådan attack kommer att leda till kundflykt och kan sänka ett helt företag.

Vi har blivit vana med att stora kända företag som Aftonbladet och Tv3 hackas av hackergrupper som Vuxna Förbannade Hackare. När Bilddagboken hackades kom alla deras användares inloggningsuppgifter på drift. En katastrof med tanke på att användare ofta har samma inloggningsuppgifter på andra populära sajter som exempelvis Facebook och Gmail.

Hackerattacker kan även drabba mindre profilerade företag. I höstas angrep hackare i Turkiet och Kanada nästan 4000 svenska sajter i protest på Lars Vilks rondellhund. Dessa mindre professionella hackare ger sig främst på sajter med sämre säkerhet. Därför kan aldrig mindre sajtägare ignorera säkerhetsfrågor.

Ett ganska vanligt säkerhetshot är DoS-attacker, Denial of Service, där angriparna genom att samordna ett stort antal internetuppkopplade hackade datorer kan göra det omöjligt, eller mycket segt, för dina vanliga besökare att komma in på sajten.

Attacken behöver inte ens vara riktad mot din sajt för att drabba dig. Det räcker att du ligger på samma server som en utsatt sajt för att sajten ska gå ner. Om sajten känns som sirap ska du kontakta ditt webbhotell omgående så får deras supporttekniker filtrera bort trafiken från angripande datorer.
Den som använder sig av egna servrar, vilket hamnar utanför denna artikel, måste ha hög säkerhetskompetens. Allt annat är att be om problem.

Men även om de som har ett väl fungerande webbhotell kan ni inte helt överlåta säkerhetstänkandet till webbhotellet.

Dålig säkerhet kan leda till att:
> Alla filer på webbservern raderas
> Uppgifter på sajten kan ändras
> Hemliga kunduppgifter kan säljas till konkurrenter
> Kunders kreditkort kan länsas
> Din sajt kan fungera som bas för andra hackerattacker
> Din sajt kan infektera besökare med skadlig kod

Åtta metoder att säkra din sajt

1. Lösenord

Vad man kan lära sig av Aftonbladets säkerhetskollaps, hackarna knäckte deras mejlserver och fick den vägen tillgång till information om hur andra säkerhetsfilter fungerade, är att alltid ha riktiga säkra lösenord till e-post, webbsajtens administrationsgränssnitt, ftp-konton och så vidare. Det funkar inget bra med 855593, olof, pontus, eller lovesexy för att nämna några av Aftonbladschefernas lösenord.

Lösenord till e-post, webbsajtens administrationsgränssnitt, ftp-konton och så vidare måste ha hög säkerhet. Det innebär att lösenordet ska ha minst åtta tecken där gemener och versaler, specialtecken och siffror blandas. Att använda ditt eget namn, barnens eller hundens namn är ingen bra idé. Password är också Pett vanligt lösenord som naturligtvis är helt värdelöst.

Kravet på säkra lösenord gäller alla användare som har tillgång till webbservern då inget är hållbarare än den svagaste länken. Ge bara dem som verkligen behöver tillgång till webbservern inloggningsuppgifter och ta bort användare när de byter arbetsuppgifter.

Förvara sedan lösenordet på en säker plats. Säkrast är ett papper i en pärm. Det finns exempel på sajtägare som laddat upp en fil med lösenorden i en publik html-map hos sitt webbhotell – det är inte en bra lösning!

Hur jobbigt det än låter bör man inte heller använda samma lösenord till flera olika konton och webbtjänster. Vuxna Förbannade Hackare loggade in på Facebook med Aftonbladsanställdas e-post inloggningsuppgifter.
Post- och telestyrelsen har tagit fram en tjänst där du kan undersöka hur säkert ett lösenord är, www.testalosenord.se.

2. Backup

Även om ditt webbhotell gör backuper på allt innehåll så bör du regelbundet göra backuper av din webbsajt och tillhörande databaser. Det behöver faktiskt inte handla elaka hackers som raderar dina filer – det händer att mindre erfarna webbredaktörer raderar sina egna filer av misstag.

3. Val av webbhotell

Välj ett välkänt och väletablerat webbhotell framför mer hobbybetonade företag. Företaget bör ha funnits några år och ha flera anställda. Webbhotellet ska kunna svara på hur de arbetar för att skydda din säkerhet. Du vill också ha svar på hur ofta de gör backuper på sina kunders konton. Du kan läsa mer i Internetworlds senaste webbhotellstest.

4. Uppdatera

Uppdatera alltid ditt publiceringsverktyg när nya versioner släpps. Hackare utnyttjar ofta gamla säkerhetshål i verktyg som PhpBB, Wordpress och Joomla. Prenumerera på nyhetsbrev från dem som utvecklar ditt publiceringsverktyg för att inte missa nya versioner och säkershetspatchar. Detta gäller all programvara du har installerad på ditt webbhotellskonto.
Det finns också en lång rad program som t.ex. Testadatorn.se, som skannar dina servrar efter säkerhetshål.

5. Rätt rättighet

Det går att ge mapparna hos ditt webbhotell olika rättigheter: läsbar, skrivbar eller exekverbar. Rättigheterna ändrar du via webbhotellets filhanteringssystem eller ditt ftp-program med kommandot chmod, change mod. Sätt så begränsade rättigheter som möjligt för mapparna hos webbhotellet som är din webbplats. Problemet är att om du sätter för låga rättigheter kommer sajten inte att fungera. Men sätt aldrig rättigheten exekverbar i en mapp där besökarna kan ladda upp filer för då kan någon otäck typ smitta ner dina besökare med skadlig kod.

6.Skaffa SSL

Om användarna lämnar ifrån sig känslig information på sajten som exempelvis kreditkortsuppgifter bör trafiken mellan besökaren och sajten vara krypterad med SSL, Secure Sockets Layer. Som besökare känner du igen en säker anslutning via s:et i https:// i webbläsarens adressruta. De flesta webbhotell erbjuder SSL som tilläggstjänst.

7. Skydda mot SQL-injection

Om du byggt egna applikationer måste du skydda dig mot det vanligt förekommande säkerhetsproblemet SQL-injection. En oskyddad databas går att radera, ändra och hackern kan få ut all information i databasen. Angreppen kan komma från inloggningsformulär, sökformulär, länkar med data.Det finns flera sätt att skydda sig på och utrymmet här tillåter inte att gå igenom de olika metoderna. Läs mer här:
www.swesecure.com
www.aspkoll.se/ArticlesRead.asp?id=92

8. Val av webbserverprogram

Olika typer av webbserverprogram är olika säkra. Ju mer komplicerat ett program är och ju fler funktioner det har desto större är risken att det innehåller säkerhetshål som kan utnyttjas av hackare eller skriptungar. Med andra ord är en hemsida byggd i ren html utan några databasanrop säkrare än mer avancerade serverprogram.

– Öppna källkodslösningar som Joomla, Wordpress och phpBB, har haft många säkerhetsproblem, säger Anders Aleborg, som är vd på Binero och som själv har lång erfarenhet av system- och hemsidesutveckling. Även om det är öppet, enkelt och gratis så måste man tänka på att hålla sin lösning ständigt uppdaterad.