Student Technology Conference 2004 Daniel Kirstenpfad Writing Secure Code.

Präsentation zum Thema: "Student Technology Conference 2004 Daniel Kirstenpfad Writing Secure Code."—  Präsentation transkript:

1 Student Technology Conference 2004 Daniel Kirstenpfad Writing Secure Code

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

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

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

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

6 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

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

8 Gefahren und Szenarien Beispiel: Stack Buffer Overflow bei der Arbeit: Höhere Adressbereiche Buffers Andere vars EBPEIP Args Rücksprung Adresse Exception handlers Function pointers Virtual methods 0wn3d!

9 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

10 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)

11 Gefahren und Szenarien Beispiel-Quelltext für einen Buffer Overflow (aus der Index Server ISAPI) // 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!

12 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

13 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 = "SELECT HasShipped FROM" + " OrderDetail WHERE OrderID ='" + ID + "'";

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

15 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

16 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

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

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

19 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

20 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

21 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

22 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

23 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

24 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

25 Gegenmaßnahmen - Verteidigung WICHTIG KNOW YOUR WEAK SPOTS

26 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

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

28 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

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

30 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

31 Gegenmaßnahmen - Verteidigung Schritt 3: Applikation auseinandernehmen Vertrauens-Grenzen erkennenDatenfluss analysierenEingstiegspunkte/EingabenSicherheitsprofil

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

33 Gegenmaßnahmen - Verteidigung Schritt 4: Bedrohungen identifizieren –S.T.R.I.D.E. Bedrohungsarten Beispiele Spoofing fälschen von eMails Authentifizierungen mithören Tampering Daten wärend der Übermittlung verändern (Man in the Middle) Daten auf Festplatte verändern Repudiation User gibt vor bestimmte Aktionen nicht ausgeführt zu haben Gegenteil kann nicht bewiesen werden Information disclosure zuviele Informationen in Fehlermeldungen Quellcode auf Webseiten Denial of Service Flooding: überfluten des Netzwerkes mit Packeten Elevation of privilege System/Administrator Rechte durch Exploit erlangen

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

35 Gegenmaßnahmen - Verteidigung Schritt 5: Bedrohungen dokumentieren BeschreibungSQL Injection Ziel Datenzugriff / Subsystem das für den Datenbankzugriff zuständig ist Risiko(nächstes Slide) Techniken Angreifer fügt SQL Kommandos zu Eingaben hinzu welche genutzt werden um SQL Anfragen zu stellen. Gegenmassnahme Regular Expression benutzen um Eingabe zu validieren und stored Procedure mit Parametern benutzen um auf die Datenbank zuzugreifen

36 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

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

38 Gegenmaßnahmen - Verteidigung Vielen Dank.