gibt es hier zum Download.

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
10101101101101011011
101011011011010110111101000101001010
– SQL Injection
Blake
– Arithmetik Fehler
• overflow/underflow
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
• Beispiel: Stack Buffer Overflow bei der
Höhere Adressbereiche
Arbeit:
EIP
Andere
vars
EBP
Buffer
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
Höhere Adressbereiche
Arbeit:
EIP
Andere
vars
EBP
Buffers
Args
Rücksprung
Adresse
Exception handlers
Function pointers
Virtual methods
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-- ) {
(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:
sqlString = "SELECT HasShipped FROM"
+ " OrderDetail WHERE OrderID ='"
+ ID + "'";
• Wenn die Variable ID direkt aus dem Textfeld eines Weboder 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') --
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();
}
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-BibliotheksFunktionen 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 (nonexecutable 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
• 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 #1
Abrechungs-Daten
1.1
Netzwerk-Verkehr ist
ungeschützt
1.2
Angreifer belauscht
Netzwerk-Verkehr
1.2.1
Netzwerk-Verkehr mithören
(Protocol-Analyzer)
1.2.2.1
Router hat nicht neuesten
Patch
1.2.2
Router-Netzwerk-Verkehr
mithören
1.2.2.2
Router angreifen und
exploiten
1.2.2.3
Router Passwort erraten
Gegenmaßnahmen - Verteidigung
• Schritt 5: Bedrohungen dokumentieren
Beschreibung
Ziel
Risiko
Techniken
SQL Injection
Datenzugriff / Subsystem das für den
Datenbankzugriff zuständig ist
(nächstes Slide)
Angreifer fügt SQL Kommandos zu Eingaben
hinzu welche genutzt werden um SQL Anfragen
zu stellen.
Regular Expression benutzen um Eingabe zu
Gegenmassnahme 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.