1 / 38

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

landry
Télécharger la présentation

Student Technology Conference 2004 Daniel Kirstenpfad

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Writing Secure Code Student Technology Conference 2004 Daniel Kirstenpfad

  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 Blake Blake’ drop table Daten --

  5. 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

  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 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];}

  8. 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

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

  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="SELECTHasShippedFROM" + " OrderDetail WHERE OrderID ='" + ID + "'";

  14. 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

  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 1 Vorhandene Strukturen identifizieren 2 Übersicht der Architektur anfertigen 3 Applikation auseinandernehmen 4 Bedrohungen identifizieren 5 Bedrohungen dokumentieren 6 Bedrohungen einstufen

  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 Vertrauens-Grenzen erkennen Datenfluss analysieren Eingstiegspunkte/Eingaben Sicherheitsprofil • Schritt 3: Applikation auseinandernehmen

  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.

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

  35. Gegenmaßnahmen - Verteidigung • Schritt 5: Bedrohungen dokumentieren

  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.

More Related