Introduction to Security – VO 05: Testing · Grundlagen des Testens ... Datenbanken,...

INSO – Industrial SoftwareInstitut fur Rechnergestutzte Automation | Fakultat fur Informatik | Technische Universitat Wien

Introduction to Security – VO 05: Testing

Stefan TaberFlorian Fankhauser

Introduction to Security WS17 | Testing

Agenda

2 / 56

Grundlagen des Testens

Einteilung von Testtechniken

Statische Codeanalyse

Penetration Testing

Fuzzing

Testen von Web Applikationen

Zusammenfassung


Aktuelle News

3 / 56

■ Android-November-Update schließt kritische WLAN-Treiber-Lucke

(07.11.2017)

■ Lochrige TLS-Verbindungen: Fortinet stopft acht Jahre alte

Project-Mogul-Lucke in FortiOS

(07.11.2017)

■ TorMoil: Luck im Tor-Browser kann Nutzer enttarnen

(04.11.2017)

■ Mobile Pwn2Own: Hacker knacken Samsung S8 mittels beachtlicher

Sicherheitslucken-Combo

(03.11.2017)

(Vergleiche https://www.heise.de)

https://www.heise.de


Grundlagen des Testens

4 / 56


Einfuhrung (i)

5 / 56

”Testing is the process of executing a program with the intent of finding

errors“ (Myers and Sandler (2004))

”Program testing can be a very effective way to show the presence of

bugs, but is hopelessly inadequate for showing their absence“ (Dijkstra

(1972))

”In essence, a web application that fails any of the tests put to it by an

application scanning tool is truly one in bad shape. On the other hand, a

web application that passes all of the tests still can’t be declared secure in

any significant sense.“ (van Wyk (2007))


Einfuhrung (ii)

6 / 56

(Vergleiche http://dilbert.com/strip/2017-10-02)

http://dilbert.com/strip/2017-10-02


Was ist Testen?

7 / 56

■ Uberprufen des aktuellen Zustands mit einem geplanten Zustand

■ Validierung: Erzeugen wir das richtige Produkt?

■ Vergleich: Wunsche des Kunden ←→ Anforderungen

■ Verifikation: Erzeugen wir das Produkt richtig?

■ Vergleich: Anforderungen ←→ Applikation

■ Test ist erfolgreich, wenn Fehler gefunden werden

■ Unterscheidung nach Testziel

■ Funktionalitat, Sicherheit, Usability, . . .


Software Fehler (i)

8 / 56

(Vergleiche Thompson (2003))


Software Fehler (ii)

9 / 56

(Vergleiche Thompson (2003))


Unterschiede zu funktionalen Tests

10 / 56

■ Funktionale Tests

■ Spezifikation als Grundlage

■ Erwarteter Output

■ Tests sind in sich abgeschlossen

■ Sicherheitstests

■ Spezifikation nicht nutzbar als Grundlage

■ Suche nach ungewollter Funktionalitat und Seiteffekte

■ Tests beeinflussen sich gegenseitig


Security Features != Secure Features

11 / 56

■ Sicherheitsrelevante Funktionalitaten

■ Anforderungen mit sicherheitskritischen Aspekten

■ Funktionale Fehler haben Auswirkung auf Sicherheit

■ Durchfuhren von funktionalen Tests

■ Beispiel: Authentifizierung, Public Key Infrastrukturen, . . .

■ Sichere Funktionen

■ Sicherheitsfehler konnen in jeder Funktionalitat auftreten

■ Testen der Robustheit gegen Angriffe

■ Beispiel: Fehlende Input Validierung

■ Wird oft verwechselt → klare Definition und Abgrenzung erforderlich

(Vergleiche Howard and LeBlanc (2002))


Sicherheitstests

12 / 56

■ Studie Carnegie-Mellon-Universitat:”tausend Zeilen Programm ca.

funf bis funfzehn Bugs – nach dem Testen“

■ Diese bleiben oft unentdeckt

■ Haben keine Auswirkung auf die restliche Funktionalitat

■ Stellen mogliche Sicherheitsfehler dar

■ Gezielte Suche nach diesen Fehlern erforderlich

■ Test ist eine Momentaufnahme und zeitlich beschrankt → Angreifer

hat beliebig Zeit

■ Testen alleine nicht ausreichend fur ein sicheres System

■ Testen ist ein Teil zur Erstellung eines sicheren Systems


Testabdeckung

13 / 56

■ Wieviele Teile eines Systems wurden getestet

■ Berechnung nach Zeilen, Anweisungen, Datenvarianten, usw.

■ Erreichung von 100% dabei nahezu unmoglich


Metriken

14 / 56


Wer kann Sicherheitstests durchfuhren? (i)

15 / 56

■ Entwickler/Tester

■ Fehlendes Wissen uber Sicherheit und aktuelle Schwachstellen →

Schwachstellen werden leicht ubersehen

■ Augenmerk auf Funktionalitat und testen dieser

■ Verwendung des Systems aus Benutzersicht → Funktionen

■ Sicherheitsexperte

■ Fehlendes Wissen uber Domane und die Implementierungsdetails

■ Wissen uber Schwachstellen und aktuelle Entwicklungen im

Sicherheitsbereich wie zum Beispiel Sicherheits-Testtools

■ Verwendung des Systems aus Angreifersicht → Schwachstellen


Wer kann Sicherheitstests durchfuhren? (ii)

16 / 56

(Vergleiche http://dilbert.com/strip/1995-11-13)

http://dilbert.com/strip/1995-11-13


Sicherheitstests im Lebenszyklus (i)

17 / 56

(Vergleiche Chess and McGraw (2004))


Sicherheitstests im Lebenszyklus (ii)

18 / 56



Einteilung von Testtechniken

19 / 56


White-Box-Tests

20 / 56

■ Wissen uber Systemdetails wird fur Tests herangezogen

■ Verwenden von Source Code, Dokumentationen,

Konfigurationsdetails, ...

■ Ableiten von Ein- und Ausgabewerten

■ Testtechniken Statische Analyse, Code Reviews, ...

■ Zugriff auf Informationen nicht immer moglich. Z.B. externe

Programmbibliotheken

(Vergleiche Dustin et al. (2001))


Black-Box-Tests

21 / 56

■ Details der Umsetzung werden fur Tests nicht herangezogen

■ Ubergeben der Eingabedaten und Betrachtung der zuruckgelieferten

Ausgabe

■ Vergleich der Ausgabe mit spezifizierten/erwarteten Ausgabe

■ Erforderlich wenn kein Zugriff auf die Implementierung vorhanden ist

■ Alle Datenvarianten nicht moglich

■ Aquivalenzklassen: z.B. Verwendung eines Vertreters aus Menge

der positiven und negativen Integer

■ Grenzwertanalyse: z.B. Vertreter aus Grenzbereichen (MAX

Integer und MIN Integer)

(Vergleiche Dustin et al. (2001))


Gray-Box-Testing

22 / 56

■ Kombination von White-Box- und Black-Box-Testing

■ Bevorzugendes Verfahren fur die Testdurchfuhrung

■ Durch Informationen konnen Tests optimiert werden

■ Ermittlung der Testabdeckung erleichtert

■ Datenvarianten anhand interner Details identifizieren

(White-Box-Tests)

■ Tests mit ermittelten Datenvarianten durchfuhren (Black-Box-Tests)


Statische Codeanalyse

23 / 56


Secure Code Review

24 / 56

■ Durchfuhrung kostenintensiv aber sehr effektiv

■ Top-Down Ansatz

■ Ausgangspunkt: Wissen uber Schwachstellen

■ Erforderliches Detailwissen uber Code gering

■ Bottom-Up Ansatz

■ Ausgangspunkt: Wissen uber Code

■ Hoherer Aufwand als beim Top-Down Ansatz

■ Walkthrough: Testfalle am Papier durchfuhren

■ Inspection: Uberprufung anhand von Checklisten/Coding Standards

■ Einfaches Design/Implementierung vereinfacht ein Review



Statische Codeanalyse (i)

25 / 56

■ Untersuchung des Codes ohne Ausfuhrung

■ Lauffahigkeit des Systems nicht erforderlich

■ Keine spezielle Testumgebung

■ Zusatzlich zur Unterstutzung von Secure Code Reviews verwendbar

■ Unterschiedliche Algorithmen vorhanden

■ Problem ist hohe false-positiv Rate

(Vergleiche Chess and West (2007))


Statische Codeanalyse (ii)

26 / 56

■ Statische Codeanalyse wird auch bei Compilern und in IDEs

verwendet

■ Typprufung (Type Check), z.B. korrekte Verwendung von Typen

■ Stilprufung (Style Check), z.B. Verwendung von Codierrichtlinien

■ Fehlersuche (Bug Finding), z.B. Ermittlung der Verwendung

nicht initialisierter Variablen


Statische Codeanalyse – Prozess

27 / 56

■ Format der Parameter und angewendete Techniken variieren

■ Durchfuhrung anhand Source Code, Byte Code oder Binary moglich

■ Sicherheitswissen beschreibt Regeln

■ Eingabequellen

■ Fehleranfallige Funktionen wie strcpy()

(Vergleiche Chess and West (2007))


Statische Codeanalyse – Varianten

28 / 56

■ Signaturbasiert

■ Suchen nach definierten Mustern wie sprintf, strcpy, ...

■ Tools: Flawfinder, RATS, ITS4

■ Kontrollfluss-Analyse

■ Kontrollfluss: Ausfuhrungsreihenfolge der einzelnen Instruktionen

■ Intra-Prozedural vs. Inter-Prozedural (Call Graph)

■ Tools: Splint, MOPS (basierend auf Modell Checking)

■ Datenfluss-Analyse

■ Zusammenhangs Erzeuger und Verbraucher von Daten

■ Vertrauenswurdigkeit der Quellen (Tainted)

■ Tools: LAPSE, Orizon


Datenfluss-Analyse – XSS Beispiel

29 / 56

p r o t e c t e d vo i d doGet ( H t t pS e r v l e tRequ e s t req ,

H t t pSe r v l e tRe spon s e r e s p )

throws IOExcept i on {

P r i n tW r i t e r w r i t e r = r e s p . g e tWr i t e r ( ) ;

S t r i n g s = req . ge tParamete r (” param ” ) ;

w r i t e r . p r i n t l n (” Value was : ”+s ) ;

}


Penetration Testing

30 / 56


Penetration Testing

31 / 56

■ Sicherheitsuberprufung

■ Schwachstellen finden

■ Ausnutzbarkeit der Schwachstellen zeigen → Beweis fur

Kunden/Management

■ Durchfuhrung im Betrieb

■ Uberprufung unterschiedlicher Ebenen des Systems

■ Uberprufung organisatorischer Sicherheit durch Social

Engineering

■ Spat im Lebenszyklus eines Systems → hohere Kosten bei der

Behebung


Penetration Testing – Einfuhrung

32 / 56

■ Berucksichtigung des gesamten Systems (Betriebssystem,

Datenbanken, Konfigurationen, . . . )

■ Teilweise automatisierbar

■ Vulnerability Scanner

■ Exploit Frameworks: z.B. Metasploit

■ Wichtig: Rechtliche Aspekte beachten!

■ Absturze oder Schaden am System unter Test

■ Gesetzliche Bedingungen → Hacker Paragraph

■ Ist Auftraggeber berechtigt?


Penetration Testing – Testabdeckung

33 / 56

■ Ermittlung der Testabdeckung schwierig

■ Laufende Teilsysteme

■ Ports, Applikationen

■ . . .

■ Einige methodische Vorgehensweisen zur Testdurchfuhrung → hohere

Abdeckung moglich

■ BSI Durchfuhrungskonzept fur Penetrationstests

■ OSSTMM – Open Source Security Methodology Manual

■ Guideline on Network Security Testing (NIST)

■ OWASP Testing Project


Penetration Testing – Informationsbasis

34 / 56

(Vergleiche Herzog and Barcelo (2010))


Penetration Testing – Prozess

35 / 56

■ Vorbereitung u. Organisation: Zielvereinbarung, Vertrag

■ Informationsbeschaffung: WWW, Foren, Stellenausschreibungen,

Netzwerkscans, ...

■ Testdurchfuhrung: Durchfuhrung von Angriffen

■ Dokumentation: Protokollierung der Testdurchfuhrung (z.B.

Netzwerkmitschnitt), Testberichte, Prasentationen

(Vergleiche National Institute of Standards and Technology (2003))


Vulnerability Scanning

36 / 56

■ Suchen nach Schwachstellen ohne weitere Ausnutzung dieser

■ Ermitteln der Versionen

■ Bekannte Schwachstellen

■ Fehlkonfigurationen

■ Bekannte Dateien und Ordner

■ Durchfuhrung fur jedes System wichtig

■ Regelmaßige Wiederholung erforderlich

■ Erster Schritt moglicher Angreifer → schnell mit wenig Aufwand

■ Automatisierbar, Tools fur die Durchfuhrung vorhanden

■ Web: z.B. Nikto

■ Systeme: z.B. Nessus, OpenVAS


Schwachstellendatenbanken

37 / 56

■ SecurityFocus (http://www.securityfocus.com/vulnerabilities)

■ BugTraq (http://www.securityfocus.com/archive/1)

■ CERT (http://www.cert.org/advisories/)

■ US-CERT Vulnerability Notes (http://www.kb.cert.org/vuls/)

■ OSVDB (http://osvdb.org/)

■ CVE (http://cve.mitre.org/)

■ NIST – National Vulnerability Database (http://nvd.nist.gov/)

■ Exploit DB (https://www.exploit-db.com/)

■ CVC Details (http://www.cvedetails.com/)

http://www.securityfocus.com/vulnerabilities

http://www.securityfocus.com/archive/1

http://www.cert.org/advisories/

http://www.kb.cert.org/vuls/

http://osvdb.org/

http://cve.mitre.org/

http://nvd.nist.gov/

https://www.exploit-db.com/

http://www.cvedetails.com/


Fuzzing

38 / 56


Fuzzing

39 / 56

■ Random Testing

■ Automatisiertes Ausfuhren mit zufallig generierten oder vordefinierten

Werten

■ Testen der Datenfelder, Struktur und Ablauf

■ Fuzzer fur unterschiedliche Eingabeformat/Protokolle vorhanden

■ Dateien: Bilder, HTML, XML, DOC, SWF, . . .

■ Netzwerkprotokolle: TCP/IP, SIP, RTP, . . .

■ . . .

■ Beispiel:”This problem occurs when the file size of the PNG file is

4,097 bytes or 4,098 bytes“ (http://support.microsoft.com/kb/

822071/en-us)(Vergleiche Sutton et al. (2007))

http://support.microsoft.com/kb/822071/en-us

http://support.microsoft.com/kb/822071/en-us


Fuzzing – Arten

40 / 56

■ Template/Block Fuzzer

■ Fur einfache Protokoll geeignet

■ Berucksichtigen der Prufmechanismen eines Protokolls, z.B.

Checksummen, Schemavalides XML, usw.

■ Mutation Based Fuzzer

■ Verwendung bestehender Daten und Abwandlung dieser Daten

■ Generation Based Fuzzer

■ Spezielle Implementierung pro Format/Protokoll

■ Aufwendiger bei der Erstellung

■ Model Based Fuzzer

■ Umsetzung eines komplexeren Ablaufs, z.B. Handshake


Fuzzing – Eingabedatengenerierung

41 / 56

■ Zufallig generierte Daten

■ Kein Wissen uber das spezielle Format erforderlich

■ Optimierung vs. Vollstandigkeit (256 unterschiedliche Varianten

fur ein Byte)

■ Ableitung der Werte von typischen Angriffswerten → Fuzz-Vektor

■ XSS, SQL Injection, Buffer Overflow, . . .


Fuzzing

42 / 56

(Vergleiche http://www.google.com/googlebooks/chrome/)

http://www.google.com/googlebooks/chrome/


Fuzzing – XSS Beispielvektor

43 / 56

<IMG SRC=” j a v a s c r i p t : a l e r t ( ’XSS’) ;”>

<IMG SRC=j a v a s c r i p t : a l e r t ( ’XSS’)>

<IMG SRC=JaVaScRiPt : a l e r t ( ’XSS’)>

<IMG SRC=&#x6A&#x61&#x76&#x61&#x73&#x63

&#x72&#x69&#x70&#x74&#x3A&#x61&#x6C&#x65

&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29>

(Vergleiche www.owasp.org)


Fuzzing – Ausfuhrung

44 / 56

■ Erzeugung und Ausfuhrung automatisierbar

■ Große Anzahl von Datenvarianten moglich/erforderlich. Microsoft

SDL verlangt 100.000 Test-Dateien bei Datei-Fuzzer

■ Fehlererkennung

■ Veranderungen eines Systems: Prozessorleistung, Fehlereintrage

in Log-Dateien, . . .

■ Uberwachen des Prozesses durch Debugger z.B. gdb oder

OllyDbg

■ Fehler der Applikation beobachten → segfault

■ Fehlerlokalisierung

■ Welcher Testfall hat Fehler verursacht?



45 / 56


Beispiele zum Testen von Web Applikationen

46 / 56

■ Uberprufung der Implementierung und Konfiguration des Web Servers

■ Bekannte Schwachstellen der verwendeten Komponenten prufen

■ HTTP ist Stateless

■ Sessions ermoglichen Zustandsspeicherung

■ Testen auf Muster in Session ID

■ Backup Dateien am Server: *.php.bak

■ Nicht interpretierte Dateien: *.inc

■ Standard Verzeichnisnamen: admin, include, . . .



47 / 56

■ Implementierung der Web Applikation, z.B. OWASP Top Ten

■ Unterschiedliche Encodings fur Eingaben

■ < (ASCII)

■ %3c (URL Encoded)

■ < (HTML Entity)

■ < (Hex Encoding)

■ . . .


OWASP Top Ten (2017) – (i)

48 / 56

■ A1 – Injection

SQL Injection, Command Injection, LDAP Injection

■ A2 – Broken Authentication and Session Management

Session Management Funktionalitat

■ A3 – Cross Site Scripting (XSS)

■ A4 – Broken Access Control

Unzureichende Prufung der Benutzerrechte

■ A5 – Security Misconfiguration

Aktualitat der Software, Logging, Standardwerte

(Vergleiche https://www.owasp.org/index.php/Top_10_2017-Top_10)

https://www.owasp.org/index.php/Top_10_2017-Top_10


OWASP Top Ten (2017) – (ii)

49 / 56

■ A6 – Sensitive Data Exposure

Unzureichender Schutz empfindlicher Daten

■ A7 – Insufficent Attack Protection

■ A8 – Cross Site Request Forgery (CSRF)

■ A9 – Using Components with Known Vulnerabilities

■ A10 – Underprotected APIs

Rich Client Apps

(Vergleiche https://www.owasp.org/index.php/Top_10_2017-Top_10)

https://www.owasp.org/index.php/Top_10_2017-Top_10


Zusammenfassung

50 / 56


Tools

51 / 56

■ Statische Codeanalyse

■ C/C++: Flawfinder, RATS

■ Java: LAPSE, CodeAssure Solo

■ PHP: Pixy

■ Vulnerability Scanning

■ Web: Nikto

■ Systeme: Nessus, OpenVAS

■ Penetration Testing

■ Metasploit, Penetration Testing Framework (PTF)


Literatur 1/3

52 / 56

■ Brian Chess und Gary McGraw. Static analysis for security. IEEE

Security & Privacy, 2(6):76–79, November/Dezember 2004. ISSN

1540-7993. doi: 10.1109/MSP.2004.111

■ Brian Chess und Jacob West. Secure Programming with Static

Analysis. Addison-Wesley, 2007. ISBN TODO

■ Edsger W. Dijkstra. The humble programmer. Commun. ACM, 15

(10):859–866, 1972. ISSN 0001-0782. doi:

http://doi.acm.org/10.1145/355604.361591

■ Elfriede Dustin, Jeff Rashka, und John Paul. Software automatisch

testen. Springer, 2001. ISBN 3-540-67639-2


Literatur 2/3

53 / 56

■ Michael Howard und David LeBlanc. Writing Secure Code. Microsoft

Press, 2002

■ Glenford J. Myers und Corey Sandler. The Art of Software Testing.

John Wiley & Sons, 2004. ISBN 0471469122

■ National Institute of Standards and Technology. Guideline on

Network Security Testing. Recommendations of the National Institute

of Standards and Technology, Oktober 2003. http://csrc.nist.

gov/publications/nistpubs/800-42/NIST-SP800-42.pdf

■ Pete Herzog und Marta Barcelo. The Open Source Security Testing

Methodology Manual, 2010

http://csrc.nist.gov/publications/nistpubs/800-42/NIST-SP800-42.pdf

http://csrc.nist.gov/publications/nistpubs/800-42/NIST-SP800-42.pdf


Literatur 3/3

54 / 56

■ Michael Sutton, Adam Greene, und Pedram Amini. Fuzzing.

Addison-Wesley, 2007. ISBN 0-321-44611-9

■ Herbert H. Thompson. Why security testing is hard. IEEE Security &

Privacy Magazine, 1(4):83–86, 2003. ISSN 1540-7993. doi:

10.1109/MSECP.2003.1219078

■ Kenneth R. van Wyk. Adapting Penetration Testing for Software

Development Purposes, Januar 2007. https://buildsecurityin.

us-cert.gov/daisy/bsi/articles/best-practices/

penetration/655.html?branch=1&language=1

https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/penetration/655.html?branch=1&language=1




Zusammenfassung

55 / 56

■ Sicherheit wird von den beteiligten Personen oft nicht verstanden

■ Testen alleine reicht nicht aus → Sicherheit ist ein Prozess

■ Priorisierung bei der Testdurchfuhrung anhand Risk-Based

Sicherheitstests

■ Sicherheitstests im gesamten Lebenszyklus integrieren

■ Viele Moglichkeiten fur einen Angreifer

■ Weiterentwicklung der Angriffstechniken → Anpassen der Testtools

und regelmaßige Re-Test Durchfuhrung

■”Sicherhheit kann nicht in ein System hineingetestet werden“

(Howard and LeBlanc (2002))

INSO – Industrial Software

Institut fur Rechnergestutzte Automation | Fakultat fur Informatik | Technische Universitat Wien

Vielen Dank!

https://security.inso.tuwien.ac.at/

https://security.inso.tuwien.ac.at/

Introduction to Security – VO 05: Testing · Grundlagen des Testens ... Datenbanken,...

Documents

Transcript of Introduction to Security – VO 05: Testing · Grundlagen des Testens ... Datenbanken,...