Student Technology Conference 2004

Daniel Kirstenpfad

Writing Secure Code

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

10101101101101011011101011011011010110111101000101001010

Blake Blake’ drop table Daten --

Gefahren und Szenarien

1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999

0

5

10

15

20

25

30

Buffer Overruns Total Vulnerabilities

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

• Beispiel: Stack Buffer Overflow bei der Arbeit: Höhere Adressbereiche

BufferAndere

vars

EB

P

EIP Args

void oflow(char *p, int i) { int j = 0; CFlow oflow; int (*fp)(int) = &func; char b[16];}

Gefahren und Szenarien

• Beispiel: Stack Buffer Overflow bei der Arbeit:Höhere Adressbereiche

BuffersAndere

vars

EB

P

EIP Args

RücksprungAdresse

Exception handlers

Function pointersVirtual methods0wn3d!

0wn3d!

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

(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!FIXED!

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

Gefahren und Szenarien

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

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

Vorhandene Strukturen identifizieren1

Übersicht der Architektur anfertigen2

Applikation auseinandernehmen3

Bedrohungen identifizieren4

Bedrohungen dokumentieren5

Bedrohungen einstufen6

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

• Schritt 3: Applikation auseinandernehmen

Vertrauens-Grenzen erkennen

Datenfluss analysieren

Eingstiegspunkte/Eingaben

Sicherheitsprofil

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.

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

Gegenmaßnahmen - Verteidigung

• Schritt 4: Bedrohungen identifizieren– Attack-Trees

Bedrohung #1Abrechungs-Daten

1.1Netzwerk-Verkehr ist

ungeschützt

1.2Angreifer belauscht Netzwerk-Verkehr

1.2.1Netzwerk-Verkehr mithören

(Protocol-Analyzer)

1.2.2Router-Netzwerk-Verkehr

mithören

1.2.2.1Router hat nicht neuesten

Patch

1.2.2.2Router angreifen und

exploiten

1.2.2.3Router Passwort erraten

Gegenmaßnahmen - Verteidigung

• Schritt 5: Bedrohungen dokumentieren

Beschreibung SQL Injection

ZielDatenzugriff / Subsystem das für den Datenbankzugriff zuständig ist

Risiko (nächstes Slide)

TechnikenAngreifer fügt SQL Kommandos zu Eingaben hinzu welche genutzt werden um SQL Anfragen zu stellen.

GegenmassnahmeRegular Expression benutzen um Eingabe zu validieren und stored Procedure mit Parametern benutzen um auf die Datenbank zuzugreifen

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.