RIP RC4

Der RFC 7465 verbietet die Verwndung von RC4 in TLS, was eine längst überfällige Entscheidung ist. Ich bin aber wirklich gespannt, wie schnell dieser RFC umgesetzt wird und RC4 aus dem Internet verschwindet. Vor allem wenn man bedenkt, dass selbst Firmen wie Google immer noch RC4 verwenden (und sogar auch SSLv3).

Für ASA-Admins ist (spätestens) jetzt der Zeitpunkt, die SSL-Einstellungen anzupassen. Die könnten so aussehen:

ssl server-version tlsv1-only
ssl encryption dhe-aes128-sha1 dhe-aes256-sha1 aes128-sha1 aes256-sha1

Und für alle anderen Crypto-Einstellungen sind natürlich immernoch die Empfehlungen von bettercrypto.org zu empfehlen.

Als nächstes könnte jetzt bitte PPTP sterben!

RIP RC4

pfSense, OPNsense

pfSense ist neben der Cisco ASA meine zweite bevorzugte Firewall. Sie funktioniert einfach problemlos, ist open Source und unterstützt in der neuesten Version (endlich) auch IKEv2.
Eine manchmal zu hörende Kritik an pfSense ist, dass die Software auch von einer amerikanischen Firma kommt.
Als zahlender Nutzer hat man noch ein paar „Premium“-Feature bekommen. Z.B. ein Cloud-Konfiguratiuons-Backup. Das hat mir dann hauptsächlich nicht gefallen. (Und bevor sich jemand wundert; Ja, Meraki gegenüber bin ich auch noch etwas voreingenommen, wenngleich ich die Geräte selbst klasse finde).

Seit kurzem gibt es OPNsense, ein Fork von pfSense. Dieses System wird unter der Leitung einer niederländischen Firma entwickelt und wirkt auf den ersten Blick wie pfSense mit einer moderneren GUI. OPNsense soll einen festen Release-Cycle mit zwei neuen Versionen pro Jahr bekommen. Auch wenn mir die Weiterentwicklung von pfSense teilweise doch zu langsam war, bin ich mir trotzdem nicht sicher ob feste Release-Zyklen wirklich sinnvoll für ein Security-Device sind. 

Aber insgesamt ist OPNsense sehr interessant und ich werde mir das System mal genauer anschauen, vielleicht ist es ja (jetzt schon oder später) eine pfSense-Alternative.

pfSense, OPNsense

Safer Internet Day (SID)

Heute ist Safer Internet Day. Dabei geht es hauptsächlich darum, Kinder und Jugendliche den verantwortungsbewussten und sicheren Umgang mit Online-Technologien näherzubringen. Dazu passt auch gut der Heise-Beitrag „Datenschutzbeauftragter: Schülern fehlt Medienkompetenz“ von vorgestern.

Aber Safer Internet kann so viel mehr sein. Ein paar Anregungen:

  • Überzeuge jemanden endlich sein Windows XP auf eine supportete Windows-Version upzudaten.
  • Aktiviere auf einer Webseite HTTPS.
  • Nutze Threema als Messenger. (Ja, auch mit closed-source kann man die Sicherheit erhöhen).
  • Verschlüssele E-Mail. Wie das geht kann man gerade in einem Online-Kurs des HPI lernen.
  • Deinstalliere Adobe Flash wenigstens im Haupt-Browser.

Und dann gäbe es da bestimmt nch vieles, vieles mehr …
Ein Vorschlag noch für die IT-Admins in den Firmen:

  • Sorge dafür, dass auch die Firewalls ab und an mal upgedated werden und die Configs überprüft werden. Denn was ich da typischerweise sehe ist immer wieder abenteuerlich.

Safer Internet Day (SID)

TLS kränkelt

Dass TLS (Transport-Layer-Security) diverse Schwächen hat, ist lange bekannt. Die meisten davon sind in dem Standard TLSv1.2 ausgeräumt, leider wird diese Version noch nicht überall unterstützt.
Der RFC 7457 fasst die wichtigsten bekanten Angriffe auf TLS zusammen:
Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)
Interessant zu lesen sind in dem Zusammenhang auch der Draft 
Recommendations for Secure Use of TLS and DTLS – draft-ietf-uta-tls-bcp-08
und natürlich das Applied Crypto Hardening PDF von bettercrypto.org.

TLS kränkelt

Wickr hat “Military Grade Encryption”

Heise berichtet heute von dem neuen Messenger Wickr. Und auf dem Screenshot springt einem gleich ein “Military Grade Encryption” in die Augen. Da muss ich immer an einen Satz von Andrew Fernandes denken (ähnliche Aussagen kommen auch von anderen Security-Leuten):

It’s sort of like saying the phrase “military grade encryption.” Whenever you´re dealing with a security product and somebody says it´s military grade encryption your bullshit detector should really go off.

Wickr hat “Military Grade Encryption”

SSH-Client-Konfiguration unter MacOS

Beim letzten Beitrag zur SSH-Konfiguration unter Cisco IOS und Cisco ASA fiel mir noch ein, dass man über sinnvolle Anpassungen der Client-Konfiguration auch mal schreiben sollte. Zumindest unter MacOS (und mindestens auch unter Debian und älterem Ubuntu Linux) wird standardmäßig nicht immer die optimale Kryptographie verwendet.
Die SSH-Parameter können an zwei Stellen konfiguriert werden:

  • systemweit unter /etc/ssh_config
  • per User unter ~/.ssh/config

In der systemweiten SSH-Config befinden sich z.B. die folgenden drei Zeilen, die weite Teile der verwendeten Kryptographie bestimmen (genauer gesagt zeigen sie die Defaults):

#Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour
#KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
#MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-sha1-96,hmac-md5-96,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96

Was kann/sollte man ändern:

Ciphers

Wer keine legacy Systeme zu pflegen hat, der könnte alle nicht-AES ciphers entfernen. Aber Geräte wie 2950 Switche sind halt auch noch ab und an anzutreffen. Daher muss man in so einem Fall 3des-cbc auch konfiguriert haben. Die Cipher-Zeile könnte dann folgendermaßen aussehen:

Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc,3des-cbc

Laut Manpage (und basierend auf der sowohl unter Mavericks und Yosemite verwendeten OpenSSH-Version 6.2p2) sollten auch die moderneren GCM-Typen unterstützt sein. Wenn die konfiguriert sind, meldet der SSH-Client aber „Bad SSH2 cipher spec“.
Beim Zugriff auf Cisco Router und Switche kommen typischerweise die CBC-Versionen zum Einsatz, da CTR erst ab IOS 15.4 unterstützt ist.

KexAlgorithms
Hier wird der Key-Exchange gesteuert. Meine Konfig-Zeile auf dem Mac ist die folgende:

KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

Die ElipticCurve Algorithmen habe ich entfernt, da diese im Verdacht stehen Backdoors zu beinhalten. Die vermutlich vertrauenswürdige curve25519 von D.J. Bernstein ist erst in OpenSSH 6.6p1 enthalten. Diese werde ich bei Verfügbarkeit mit aufnehmen. Als letztes in der Zeile ist weiterhin ein Group1-Exchange (768 Bit), der für Legacy-Geräte benötigt wird.

MACs
Am meisten stört mich, dass eine MD5-Methode die höchste Priorität hat, gefolgt von einer SHA1-Methode. Da sollte die Reihenfolge angepasst werden:

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1

Interessant sind die etm-MACs. Dazu ein kleiner Ausflug in Message Authentication Codes. Die Protokolle SSL, IPsec und SSH verwenden standardmäßig verschiedene Methoden um die Daten zu verschlüsseln und die Integrität zu sichern:

  • SSL: mac-then encrypt. Dabei wird erst der MAC gebildet, dann werden Daten und MAC verschlüsselt.
  • IPsec: encrypt-then-mac. Dabei werden die Daten erst verschlüsselt und dann darüber der MAC gebildet.
  • SSH: encyrpt-and-mac. Die Daten werden verschlüsselt, die MAC wird aber über die Klartextdaten gebildet.

Es hat sich herausgestellt, dass von diesen drei Optionen die von IPsec verwendete Methode die sicherste ist. Diese encrypt-then-mac (etm) Verfahren können auch bei SSH verwendet werden.

Update: In RFC 7366 wird eine TLS-Erweiterung definiert, die auch die Verwendung von “encrypt then mac” benutzt.

Was hat sich jetzt beim Zugriff auf ein IOS-Gerät geändert? Ohne diese Anpassungen sieht die SSH-Session so aus (auf einem Cisco 3560 mit IOS 15.0(2)SE5):

c3560#sh ssh
Connection Version Mode Encryption  Hmac	 State	            Username
1          2.0     IN   aes128-cbc  hmac-md5     Session started   ki
1          2.0     OUT  aes128-cbc  hmac-md5     Session started   ki

Es wird aes-128-cbc mit einem MD5-HMAC verwendet. Nach den Änderungen ist die Krypto etwas besser (im Rahmen der Möglichkeiten des IOS):

c3560#sh ssh
Connection Version Mode Encryption  Hmac	 State	           Username
0          2.0     IN   aes256-cbc  hmac-sha1    Session started   ki
0          2.0     OUT  aes256-cbc  hmac-sha1    Session started   ki

Hier noch einmal die resultierende ~/.ssh/config:

Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc,3des-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1

Update:
Nach einigem Nachdenken kam ich zu dem Ergebnis, dass mir die Aufnahme der Legacy-Verfahren in die Config-Datei irgendwie nicht gefällt. Daher habe ich diese wieder rausgeschmissen und gebe bei der Verbindung zu älteren Geräten die benötigte Crypto direkt an. Hier ein Beispiel für den Zugriff auf einen 2950:

ssh -l ki 10.10.10.200 -o Ciphers="3des-cbc" -o KexAlgorithms="diffie-hellman-group1-sha1"

Und hier die angepasste ~/.ssh/config:

Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1

Weitergehende Verbesserungsvorschläge werden gerne angenommen.

SSH-Client-Konfiguration unter MacOS

Geld für GnuPG

logo-draft-1Zur Zeit bin ich dabei einen weiteren Teil meiner “alles verschlüsseln”-Strategie umzusetzen. Das wird demnächst auch noch ein eigener Beitrag werden.
Dazu passend berichtet heute heise.de, dass GnuPG per Crowdfunding Geld einsammeln möchte. Als jemand, der unter anderem auch OpenPGP einsetzt, ist das natürlich eine Sache die ich auch unterstützte. Das Ziel ist zwar schon fast erreicht, aber noch kann man natürlich mitmachen!

Geld für GnuPG

Apple und die Security

Apple LogoFrüher war die Security von Apple Computern so einfach. Vor der Auslieferung hat Steve Jobs einfach eine Hand voll Feenstaub auf die Macs gestreut und sie wurden quasi unverwundbar. Leider geht das heute nicht mehr. Apple muss für die Sicherheit seiner Systeme mit “normalen” Sicherheitsmechanismen sorgen. Um so ärgerlicher, wenn Security Bugs auch nach mehreren Updates immer noch in der Software enthalten sind:

Im Juni/Juli (ok, es war schon 2013) hatte ich einen regen E-Mail-Verkehr mit dem Apple Product Security Team über ein Problem mit verschlüsselten Volumes das sich folgendermaßen zeigt:

  1. Auf einer externen Festplatte (in meinem Fall war es eine USB-Platte) wird eine verschlüsselte Partition angelegt (das macht man im Festplattendienstprogramm).
  2. Wenn man diese externe Platte anschließt, wird man nach dem Password gefragt und der vormals verschlüsselte Inhalt ist zugänglich.
  3. Wenn man nicht mehr mit dem Inhalt der Platte arbeiten muss, kann man diese über das Kontextmenü der Partition auswerfen.
  4. Jetzt sollte man annehmen, dass der Inhalt nicht mehr erreichbar ist und das Betriebssystem auch den Schlüssel nicht mehr im Speicher behält. Aber:
  5. Man loggt sich aus und wieder ein (gerne auch mit einem anderen Benutzerkonto).
  6. Die verschlüsselte Partition ist sofort wieder gemountet, ohne dass man erneut ein Password eingeben muss (und das Kennwort war natürlich nicht im Schlüsselbund gesichert).

Leider ist dieser Fehler immer noch enthalten. Sowohl im danach erschienenen Update 10.8.5, als auch in der neuen Version 10.9 “Mavericks”.

Apple und die Security

Hacker Halted 2013

hacker-haltedDieses Jahr war ich wieder auf der Hacker-Halted Konferenz, die im September in Atlanta stattfand. Vor drei Jahren war ich zumindest von dem EC-Council-Training alles andere als begeistert, aber eine zweite Chance wollte ich der Veranstaltung dennoch geben. Das galt insbesondere für das Angebot, den Hotelaufenthalt zum Training und der Konferenz kostenlos zu bekommen. Mein erster Gedanke war zwar “na, kriegen die ihre Veranstaltung nicht voll”, aber die Gelegenheit habe ich doch genutzt.
Als Training habe ich mir den 3-Tages-Kurs “CAST-615: Cryptography Deep Dive” bzw. “Hacking Encryption and Countermesures” ausgesucht, da mich das Thema sehr interessiert. Die Einleitung zum Kurs klang auf jeden Fall gut:

Perhaps you already know SSL/TLS in depth, you can setup a VPN in your sleep, and you have been using TruCrypt for years. Maybe your middle name is AES (John AES Smith), but do you know enough? This course will teach you the major algorithms in depth, allowing you to understand proper implementation and exploitation. For example can you crack hard drive encryption? How likely is it to be able to break a given RSA implementation? This course does not assume you have a strong math background, it will teach you enough number theory to understand cryptography.

Auch wollte ich nach den Erfahrungen von 2010 keinen Kurs besuchen, der zu einer Zertifizierung führt. Aber manchmal kommt es doch anders …

Unter den Voraussetzungen zum Kurs wurde extra erwähnt, dass keine besonderen mathematischen Vorkenntnisse vorhanden sein müssen. Die Mathematik ist der Bereich, bei dem ich selbst in exzellenten Büchern wie z.B. Practical Cryptography aussteige.

Der Kurs bestand aus verschiedenen Blöcken: Mathematische Grundlagen, historische Mechanismen, moderne Kryptographie, Steganographie und Cryptoanalyse.

Gleich zu Anfang des ersten Tages hatte der Trainer Chuck Easttom auch herausgestellt, für wie schlecht er alle bekannten mathematischen Erklärungen hält und dass er eine eigene Methode hat, die notwendige Mathematik verständlich zu erklären. Nun, das war dann auch nur eine zusammenhanglose Aneinanderreihung mathematischer Begriffe; zu einem Verständnis dieser hat das allerdings auch nicht geführt. Das war, nun ja …
Die historischen Verfahren haben in meinen Augen viel zu viel Platz eingenommen, Steganographie halte ich für überbewertet und muss sich in so einem Kurs sicher nicht über einen halben Tag erstrecken. Kryptoanalyse war das, worauf ich am meisten gespannt war. Dort habe ich dann doch erwartet, aktuelles zu lernen, z. B., wie kryptografische Verfahren gebrochen werden. Effektiv war das eine Übersicht von Methoden, wie known-plaintext-attacks, choosen-plaintext-attacks oder die Wichtigkeit, Kryptografie mit Cipher-Block-Chaining anstelle Electronic-Code-Book zu implementieren. Irgendwie habe ich mich um zehn Jahre zurückversetzt gefühlt, als ich den (damals sehr guten) Cisco-Kurs VPBAV (IPSec) gegeben habe. Dort bestand der erste Tag ungefähr aus dem Stoff, den wir in diesen drei Tagen durchgenommen haben (ok, ohne die Mathematik und ohne Erklärung von AES, der Standard war zu der Zeit als der Kurs entwickelt wurde noch nicht vorhanden. Auch Steganographie kam natürlich nicht drin vor). Zusammengestrichen ist der Kurs dann auch das, was ich in meinem IPSec-Workshop am ersten Vormittag mache. Als Anregung nehme ich aber dann doch mit, die Arbeitsweise von AES in meinen Workshop zu integrieren.

Eine schlimme Vorahnung überkam mich, als angekündigt wurde, dass es einen anderen EC-Council-Kurs gäbe, der zur Zertifizierung zum E|CES (EC-Council Certified Encryption Specialist) führt und mit diesem Kurs fast deckungsgleich sei. Und da sowohl unser, als auch das Zertifizierungstraining und die Prüfung vom selben Trainer entwickelt wurde, war auf einmal auch dieses Training ein reines Zertifizierungs-Training. In diesem ging es dann auch hauptsächlich darum, das zu lernen, was man für die Prüfung benötigt, anstatt tiefergehendes Wissen zu vermitteln. Dieses Training war leider kein Deep-Dive und auch um “Hacking Encryption” oder Countermeasures ging es eher nicht. Es war das, was ich als minimale Grundlagen der Kryptographie für jeden Security-Professional bezeichnen würde. Zudem waren es Grundlagen ohne praktische Anwendung, auf die man dann hätte aufbauen können.

Die Kursunterlagen sollte man natürlich auch nicht vergessen (Kostprobe unter https://www.eccouncil.org/Certification/ec-council-certified-encryption-specialist). Die gedruckten Slides wirkten so, als hätte ein Kind zum ersten Mal die Powerpoint Cliparts entdeckt und diese mussten jetzt unbedingt allesamt in den Slides dargestellt werden. Ein Resultat daraus war, dass die Schrift so klein wurde, dass man sie fast nicht mehr lesen konnte.

ecesIm Nebenraum lief auch wieder eine CEH-Schulung (Certified Ethical Hacker). In den Pausen habe ich häufiger kurz durch die geöffnete Tür geschaut. Was wurde dort meistens gemacht? Lediglich das sture Lernen von Prüfungsfragen. Das bestätigt meine Meinung, die ich schon in meinem ersten Hacker-Halted-Beitrag geschrieben habe, dass der CEH noch weniger wert als wertlos ist … Ach ja, E|CES (EC-Council Certified Encryption Specialist) bin ich jetzt auch. Und auch diese Zertifizierung ist mehr als wertlos. Als Kursteilnehmer bei EC-Council kann man quasi nicht durchfallen und vom Anspruch ist sie auch eher rudimentär.
Apropos Prüfung … Die Exam-Seite, auf der man sich einloggt, seine Prüfungen verwaltet und auch die Prüfung ablegt, arbeitet mit HTTP anstelle HTTPS (bzw. es gibt ein Zertifikat, aber das ist für einen anderen FQDN). Und nach der Registrierung bekommt man seinen Usernamen und das Password im Klartext zugesendet. Zumindest wenn die E-Mail ankommt, das ist sie bei mir nämlich nicht direkt:

MTA helo: zeus.atlas.eccouncil.org, MTA hostname: 67.221.176.34.static.nyinternet.net[67.221.176.34]

Die darauf folgenden knapp drei Konferenztage waren dann aber doch sehr gut. Es gab etliche sehr gute Vorträge, die neue Informationen lieferten oder aber zum Nachdenken anregten. U.a. berichtete Charlie Miller über den Stand der Mobile Security. Es ging weiterhin um Unicode und Security, bei dem ich mich häufiger gefragt habe, ob der Normalizer in den Cisco IPS-Appliances das auch erkennen kann oder um den Security-Zustand der Industrial Control Systems (ICS). Bei letzterem wird einem dann doch sehr mulmig. Die Security in diesen Systemen ist irgendwie vergleichbar mit dem frühen Internet. Es gibt einfach keine Security …

DragonDaySlider2Am Abend des ersten Tages gab es dann die Preview von Dragon Day, einem Independent Hacker Film, bei dem die USA durch einen Cyber-Angriff in die elektronische Steinzeit zurückgeworfen werden. Das war zwar kein großes Kino, aber trotzdem gut gemacht und gelungene Unterhaltung. Und Popcorn gab es auch!

Am zweiten Tag waren diverse kurze Sessions à 40 Minuten vorgesehen. Z.B. Angriffe auf SSL-Implementierungen. Sowas hätte ich mir auch in dem “Encryption Deep-Dive” gewünscht. Auch die weiteren Sessions waren fast alle sehr interessant. Am dritten Tag gab es dann nur vier Sessions am Vormittag. Bis auf eine waren auch die gut. Aber die letzte hatte es wirklich in sich. Durch komplette Ignoranz wie IT-Systeme und Netzwerke funktionieren, wurde unter abenteuerlichen Annahmen ein theoretischer Angriff präsentiert, der dann hypothetisch mit Mechanismen abgewehrt wurde, die bekanntermaßen nicht wirklich funktionieren (nämlich Security by Obscurity). Oh, war das schlecht …

Und damit ist es mal wieder Zeit für eine Zusammenfassung: Die EC-Council-Zertifizierungs-Trainings sind in meinen Augen die wohl schlechtesten Trainings am Markt (und ich besuche viele Trainings). Wenn man in einem Kurs-Thema schon Grundlagen hat, dann sollte man das entsprechende ec-council-Training eher nicht besuchen, es sei denn, man ist nur an der Zertifizierung interessiert. Etwas neues lernen wird man vermutlich nicht. Wenn man ein Thema noch nicht kennt, kann es durchaus lohnen, dümmer wird man sicher auch nicht. Und da der Konferenz-Teil durchweg gut war, kann ich mir bei einem ähnlich guten Angebot durchaus vorstellen, im nächsten Jahr wieder bei der Hacker-Halted dabei zu sein und dann z.B. das “Digital Forensic” Training zu besuchen. Oder noch besser das Training zum Thema “Securing Windows”. Dazu gibt es keine Prüfung und Teilnehmer dieses Trainings haben mir gesagt, dass es richtig gut gewesen sein soll.

Hacker Halted 2013