Student Technology Conference 2004 Daniel Kirstenpfad

Writing Secure Code Student Technology Conference 2004 Daniel Kirstenpfad

Agenda • Gefahren und Szenarien • Gegenmaßnahmen - Verteidigung • Threat Modelling

Gefahren und Szenarien • Gefahren ergeben sich aus: • Eingaben allgemein • allem anderen • Gefahren lauern nahezu überall  Sicherheit entsteht nicht von alleine

Gefahren und Szenarien • Beispiele für solche Probleme: • Buffer Overflow • SQL Injection • Arithmetik Fehler • overflow/underflow 10101101101101011011 101011011011010110111101000101001010 Blake Blake’ drop table Daten --

Gefahren und Szenarien Buffer Overruns Total Vulnerabilities 30 25 20 15 10 5 0 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 Quelle: CERT

Gefahren und Szenarien • Was sind Buffer Overflows ? • treten auf, wenn Daten die erwartete Größe überschreiten und andere Werte überschreiben • Tritt überall dort auf wo direkt auf den Speicher zugegriffen werden kann • 4 Typen • Stack Overflow • Heap Overflow • V-Table/Function Pointer Overflows • Exception Handling Overflows

Gefahren und Szenarien Buffer Andere vars Args EBP EIP Höhere Adressbereiche • Beispiel: Stack Buffer Overflow bei der Arbeit: void oflow(char *p, int i) { int j = 0; CFlow oflow; int (*fp)(int) = &func; char b[16];}

Gefahren und Szenarien RücksprungAdresse Höhere Adressbereiche 0wn3d! Exception handlers Function pointers Virtual methods • Beispiel: Stack Buffer Overflow bei der Arbeit: Buffers Andere vars Args EBP EIP

Gefahren und Szenarien • Ergebniss eines Buffer Overflows • Mit viel Glück erhält man einen Speicherzugriffs Fehler  Denial Of Service (DoS) • Mit weniger Glück wird das Programm instabil • Mit ausgesprochenem Pech kann der Angreifer seinen Code in dein Prozess einfügen und ausführen

Gefahren und Szenarien • Beispiel-Quelltext für einen Buffer Overflow // cchAttribute enthält die Anzahl der vom User eingegebenen // Zeichen WCHAR wcsAttribute[200]; if ( cchAttribute >= sizeof wcsAttribute) THROW( CException( DB_E_ERRORSINCOMMAND ) ); DecodeURLEscapes( (BYTE *) pszAttribute, cchAttribute, wcsAttribute,webServer.CodePage()); ... void DecodeURLEscapes( BYTE * pIn, ULONG & l, WCHAR * pOut, ULONG ulCodePage ) { WCHAR * p2 = pOut; ULONG l2 = l; ... for( ; l2; l2-- ) { (aus der Index Server ISAPI)

Gefahren und Szenarien • Beispiel-Quelltext für einen Buffer Overflow // cchAttribute enthält die Anzahl der vom User eingegebenen // Zeichen WCHAR wcsAttribute[200]; if ( cchAttribute >= sizeof wcsAttribute / sizeof WCHAR) THROW( CException( DB_E_ERRORSINCOMMAND ) ); DecodeURLEscapes( (BYTE *) pszAttribute, cchAttribute, wcsAttribute,webServer.CodePage()); ... void DecodeURLEscapes( BYTE * pIn, ULONG & l, WCHAR * pOut, ULONG ulCodePage ) { WCHAR * p2 = pOut; ULONG l2 = l; ... for( ; l2; l2-- ) { FIXED! (aus der Index Server ISAPI)

Gefahren und Szenarien • Was ist eine SQL Injection ? • SQL Anweisungen werden über Benutzereingaben eingeschleust • Wird dazu benutzt um: • Spionage von Daten in Datenbanken zu betreiben • Authorisierungen zu umgehen • stored Procedures auszuführen

Gefahren und Szenarien • Beispiel für eine SQL Injection: • Wenn die Variable ID direkt aus dem Textfeld eines Web- oder Windows-Formulars gelesen wird, können die Benutzer folgenden Code eingeben: • username • username' or 1=1 -- • username' DROP TABLE Bestellungen -- • username' exec xp_cmdshell('fdisk.exe') -- sqlString="SELECTHasShippedFROM" + " OrderDetail WHERE OrderID ='" + ID + "'";

Gefahren und Szenarien 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(); } • Beispiel Quelltext für eine SQL Injection

Gefahren und Szenarien • Managed Code • Code Access Security != Secure Code • überprüfbaren Code verwenden (verified) • hilft der CLR dabei Sicherheit zu schaffen • reduziert Möglichkeiten von Buffer Overruns • Ob überprüfbarer Code verwendet werden kann/wird hängt von der verwendeten Sprache ab

Gefahren und Szenarien • Managed Code • VisualBasic.NET  generell überprüfbar • C# überprüfbar, ausgenommen ist „unsafe“ • C++ ist generell nicht überprüfbar • Geplant für zukünftige Versionen

Gefahren und Szenarien • Managed Code • Vorsicht vor „AllowPartialTrust“ Aufrufen • Vorsicht vor Abhängigkeiten und Verkettungen • FxCop: nützliches Tool um Probleme vorab zu finden

Gefahren und Szenarien • FxCop - http://www.gotdotnet.com/team/fxcop/

Gegenmaßnahmen - Verteidigung • Vorbeugen ist die beste Verteidigung • Sprachen/Technologien ohne direkten Speicherzugriff bzw. mit Speicherschutz verwenden (z.B. .NET / C#) • Keine als anfällig bekannte Funktionen verwenden, z.B. bei C/C++: • Strcpy, strncpy, CopyMemory, MultiByteToWideChar • Es gibt Werkzeuge die vom Compiler zur Verfügung gestellt werden (Static Checks) • Bei Visual C++ mit Compiler-Option /GS

Gegenmaßnahmen - Verteidigung • Es gibt Werkzeuge die vom Compiler zur Verfügung gestellt werden (Static Checks) • Bei Visual C++ mit Compiler-Option /GS • schützt bspw. vor Slammer,Blaster,CodeRed • In-Memory Cookies verwenden • Auch Heap-Cookies genannt • Einige Buffer-Overruns können so erkannt werden • Heap-basierte Attacken werden zuverlässig erkannt

Gegenmaßnahmen - Verteidigung • Wenn Sprachen mit direkten Speicherzugriff bzw. Sprachen die als anfällig bekannt sind verwendet werden müssen: • „checked“ Speicherzugriffs-Bibliotheks-Funktionen benutzen • Bspw. strsafe.h bei C • Erkennen wenn Speicherbereiche überschrieben worden sind  Exception

Gegenmaßnahmen - Verteidigung • Geschützten Speicher verwenden (Windows 2003, neue Prozessoren (Itanium,K8), in Win XP SP2 enthalten) • Trennung von Code und Datenspeicher (non-executable Memory) • Wenn der Angreifer seinen Code in den Speicher des angegriffenen Rechners schreiben kann kann er ihn wenigstens nicht ausführen

Gegenmaßnahmen - Verteidigung • Daten und Code an zufälligen Speicheradressen ablegen • Macht die Ausführung weniger vorhersagbar • Es werden wahrscheinlich nur 5% aller Maschinen erfolgreich attackiert, statt 100% • Besonders bei Buffer Overflows ist es wichtig möglichst viel über Speicheradressen zu wissen • Beispiel: Xbox Dashboard Exploit

Gegenmaßnahmen - Verteidigung • Überprüfung der Daten • JEDE Eingabe ist böse, solange nicht das Gegenteil bewiesen ist • authentifizierte Verbindungen benutzen • Jede Eingabe prüfen: • nach gültigen Eingaben suchen, alles andere verwerfen • keine Annahmen über Eingaben machen • niemals direkt Eingaben wieder ausgeben, erst prüfen

Gegenmaßnahmen - Verteidigung • WICHTIG KNOW YOUR WEAK SPOTS

Gegenmaßnahmen - Verteidigung • Threat Modelling • Methodik um Sicherheitsaspekte zu analysieren • Hilft zu verstehen wo Angriffspunkte bestehen oder entstehen • Lücken und Probleme aufzeigen • Ziel ist die Reduzierung der Sicherheits-Risiken

Gegenmaßnahmen - Verteidigung Threat Modelling Prozess 1 Vorhandene Strukturen identifizieren 2 Übersicht der Architektur anfertigen 3 Applikation auseinandernehmen 4 Bedrohungen identifizieren 5 Bedrohungen dokumentieren 6 Bedrohungen einstufen

Gegenmaßnahmen - Verteidigung • Schritt 1: Vorhandene Strukturen identifizieren • Eine Liste anfertigen welche Teile überhaupt geschützt werden müssen: • Sicherheitsrelevante Daten (z.B. Kundendaten) • Web-Seiten • Teile die die Verfügbarkeit beeinflussen • Alles andere, das, wenn es kompromittiert würde den korrekten Programm-Ablauf beeinflusst

Gegenmaßnahmen - Verteidigung • Schritt 2: Übersicht der Architektur anfertigen • Was tut die Applikation • Architektur-Diagramm:

Gegenmaßnahmen - Verteidigung • Schritt 3: Applikation auseinandernehmen • Die Applikation komplett zerlegen • Sicherheits-Profil basierend auf den „traditionellen“ Bereichen von Angriffen anfertigen • Abläufe zwischen Subsystemen untersuchen • Bspw. UML Diagramme nutzen

Gegenmaßnahmen - Verteidigung Vertrauens-Grenzen erkennen Datenfluss analysieren Eingstiegspunkte/Eingaben Sicherheitsprofil • Schritt 3: Applikation auseinandernehmen

Gegenmaßnahmen - Verteidigung • Schritt 4: Bedrohungen identifizieren • Netzwerk-Bedrohungen • eventuell benutzte Protokolle • Lokale Bedrohungen • Trojaner usw. • Applikations-spezifische Bedrohungen • Kundendaten in eigener Datenbank bspw.

Gegenmaßnahmen - Verteidigung • Schritt 4: Bedrohungen identifizieren • S.T.R.I.D.E.

Gegenmaßnahmen - Verteidigung • Schritt 4: Bedrohungen identifizieren • Attack-Trees

Gegenmaßnahmen - Verteidigung • Schritt 5: Bedrohungen dokumentieren

Gegenmaßnahmen - Verteidigung • Schritt 6: Bedrohungen einstufen • Formel: Risiko = Wahrscheinlichkeit * Zerstörungspotential • D.R.E.A.D. Schema benutzen: • Damage potential • Reproducibility • Exploitability • Affected Users • Discoverability

Gegenmaßnahmen - Verteidigung • Thread Modelling • Hilft dabei die gefährdetsten Teile der Applikation zu finden • Prioritäten erkennen

Gegenmaßnahmen - Verteidigung • Vielen Dank.

Student Technology Conference 2004 Daniel Kirstenpfad