Sicherheit

Öffentlich zugängliche SSL/TLS Dienste bilden das Rückgrat der Internet Anwendungen und haben zugleich das Problem, dass der initiale Handshake eine CPU intensive Crypto-Operation auf dem Server erfordert. Das ist deswegen problematisch, weil der Server erst nach dieser Operation feststellen kann ob der Client den Rechenaufwand ebenfalls eingegangen ist, oder einfach nur zufällige Daten beim Schlüsselaustausch geschickt hat. Dieses Ungleichgewicht kann ein Angreifer bei einem DoS (Deny of Service) Angriff ausnutzen und wiederholt (ggf. von verschiedenen bots) eine solche SSL Verbindung anfordern. Dadurch kann es dann zu Überlastungen der Server kommen, ohne dass der Angreifer viele Ressourcen investieren müsste.

Diese Form des SSL DoS lässt sich aber zum Glück einfach erkennen und dank Rate Limits in Firewalls oder SSL Accelerators auch einfach abwehren. Etwas problematischer ist es da schon, dass auch in einer bestehenden TLS Verbindung die Gegenstelle eine neue Aushandlung der Schlüsseldaten anfordern kann. Dazu sind keine von der Firewall bemerkbaren neuen Verbindungen notwendig, und auch die Handshake Records die bei SSL ausgetauscht werden sind als solche nur mit anfälliger Heuristik zu erkennen.

Wenn man das nun mit der Eigenheit von RSA kombiniert, dass das entschlüsseln auf der Serverseite mehr CPU Zeit beansprucht als die Verschlüsselunsoperation, so erhält man eine neue Klasse von Angriffen auf die die deutscheinternationale Security Research Gruppe THC 2011 aufmerksam gemacht hat. Und obwohl ein dDoS Angriff auf den initialen Handshake um ein vielfaches wirkungsvoller ist hat die Veröffentlichung des Tools einige Hersteller dazu bewegt etwas dagegen zu unternehmen (die meisten schalten die Renegotiation komplett ab). Hinweis: THC spricht von Faktor 15 mehr Rechenaufwand auf dem Server als auf dem Client, dem widersprechen allerdings die Zahlen von Vincent (s.u.).

Jedenfalls ist es für einen öffentlich angebotenen SSL Server wichtig die Renegotiation Anfragen der Clients zu erkennen und zu limitieren. Neben den häufig verwendeten nativen Libraries wie puressl oder openssl gibt es auch noch weitere Implementierungen, z.B. den SSLServerSocket bei Java (im Falle der JVM von Oracle mit der ehemals von Sun stammenden JSSE Implementierung). Für diese bleiben aktuell zwei Strategien:

a) HandshakeListener auf jedem SSLServerSocket registrieren: dieser wird bei jedem erfolgreichen Handshake aufgerufen, er kann also mitzählen und ggf. Gegenmaßnahmen einleiten. Das hat aber einen großen Nachteil: der Listener selbst wird Asynchron in einem neuen Thread aufgerufen. Und dies auch dann wenn die Funktion im Listener nicht mehr macht als einen Zähler hochzählen. Das starten des Threads ist im Vergleich dazu viel belastender für den Server. Es sollte also vermieden werden überhaupt einen Listener zu registrieren.

b) Nach dem initialen Handshake die Liste der erlaubten Ciphers auf eine leere Liste setzen. Das führt dazu, dass alle weiteren Handshake Anfragen mit einem SSL Alert abgebrochen werden. Leider gilt das allerdings auch für Handshakes die vom Server angefordert werden (z.B. wenn Client Zertifikate angefordert werden sollen) oder auch bei sehr seltenem Schlüsselaustausch (bei lange bestehenden SSL Verbindungen sinnvoll).

Ich würde mir deswegen wünschen Oracle bessert hier an zwei Stellen nach: zum einen sollte man bei SSLServersockets direkt die Renegotiation die von Clients angefordert wird mittels eines Flags ignorieren/ablehnen können. Zudem macht es Sinn wenn der SSLServerSocket diese automatisch in der Anzahl begrenzen. Zum anderen sollte es möglich sein auf die Erzeugung eines Threads pro Handshake Event zu verzichten, z.b. indem der Anwender einen eigenen Executor mitgeben kann (der einen Pool hat oder aber bei sehr leichtgewichtigen Listener einfach synchron ausführt).

Übrigens bietet die JSSE2 Implementierung von IBM eine Systemproperty (com.ibm.jsse2.renegotiate=NONE) an, mit der man die Renegotiation ausschalten kann. Im Falle von Oracle kann nur die unsichere Renegotiation (ohne RFC5746) verboten werden. Das hilft aber nicht gegen den DOS Angriff.

Zum Weiterlesen

• SSL/TLS and Computational DoS (Eric Rescorla)
• SSL computational DoS mitigation (Vincent Bernant)
• Forward Secrecy for Google HTTPS (Adam Langley)
• JSSESocketServer.java testcode (GitHub Bernd Eckenfels)

Web Anwendungen werden immer essentieller und es zeigen sich immer mehr Schwachstellen und Risiken. Als Web Application Entwickler kann man einige Technologien verwenden (die mehr oder weniger verbreitet sind) um das Risiko zu reduzieren. Hier möchte ich Funktionen sammeln die als "neue" HTTP Header bereitgestellt werden:

Content-Security-Policy: (CSP) Dieser HTML5 Header erlaubt es dem Web Server der eine HTML Seite ausliefert Beschränkungen für den html/javascript code zu definieren in Bezug auf Quellen für Code (und andere Ressourcen wie Fonts und Bilder). Sinnvoll ist dieses Verfahren insbesondere in Verbindung mit Web Seiten die keinen Inline JavaScript code enthalten (nur script tags) sowie auf eval in JavaScript verzichten. Eine gute Zusammenfassung findet sich auf html5rocks.com. Leider ist die Unterstützung in den Browsern noch eingeschränkt und die verschiedenen Engines benutzen noch nicht den offiziellen Header name. [W3C Working Draft Content Security Policy 1.0]

Strict-Transport-Security: (HSTS) Ein Problem mit https (SSL/TLS) ist, wenn es nicht oder falsch verwendet wird. Mit dem HSTS header wurde eine Möglichkeit geschaffen dass Web-Seiten dem Browser der User dazu zwingen können für bestimmte URLs nur die SSL Variante zuzulassen. Der Nutzen ist ein wenig umstritten, da es zum einen noch das Henne und Ei Problem gibt und zum Anderen der Header nicht vor man-in-the-middle (MITM) Angriffen oder Phisching Angriffen mittels alternativen URLs schützen kann. Es ist aber trotzdem eine gute Idee den Header einzusetzen, vor allem wenn die Browser Hersteller dann eigene Listen erstellen und diese fest mit der Software ausliefern (und damit das Henne und Ei Problem umgehen). Die OWASP Initiative hat weiterführende Informationen. [IETF WEBSEC Draft: HTTP Strict Transport Security]

Access-Control-Allow-Origin: (CORS) Die Access-Control-Allow Header sind genau genommen kein Mechanismus um die Möglichkeiten einer Web Seite zu beschränken, sondern um diese feingranular um Zugriffe auf fremde Server (die dem zustimmen) zu erweitern. Dies erlaubt unter anderem die Vermeidung des eher problematischen JSON-P Verfahrens (das auf JavaScript eval basiert). Eine gute Beschreibung wie das Verfahren eingesetzt werden kann findet sich bei html5rocks.com. [W3C Working Draft Cross Origin Resource Sharing]

Cache-Control: no-store Diese Einstellung bietet sich vor allem für dynamisch erstellte HTML Seiten an die sensible Daten enthaten die nicht permanent auf dem Client Rechner gespeichert werden sollen. Es sollte nicht für statische ressourcen (Bilder) gesetzt werden, da dies Geschwindigkeit der Web Anwendung durch ständiges neu-übertragen eben solcher verschlechtert. [W3C RFC2616 HTTP/1.1]

Cookies: HttpOnly secure Cookies werden in Web Anwendungen unter anderem dazu eingesetzt Einstellungen oder Details auf dem Client zu erinnern oder eine Session ID zu speichern. Damit sind Cookies eine Achillesferse jedes Authorisationssystems und bedürfen besonderem Schutz (vor Einsichtname oder Auslesen). Wenn ein Server ein Cookie mittels Header anlegt, so kann er diesen Attribute mitgeben die zum einen regeln wann das Cookie zurückgeschickt wird (secure = nur wenn https methode verwendet wird) und zum anderen ob das Cookie mittels JavaScript/DOM ausgelesen werden kann, oder einfach nur für alle weiteren Zugriffe bereitsteht. Web Anwendungen sollten zum Schutz der Session Information unbedingt dieses Verfahren erzwingen: session cookies mit HttpOnly Attribut. [IETF RFC6255 HTTP State Management Mechanism]

X-Frame-Option: Erlaubt Web Seiten die nicht in Frames eingesperrt werden dürfen. Dies hat den Vorteil dass es Angreifern etwas schwerer gemacht wird eine Webseite anzuzeigen die normale Funktionalitäten bereitstellt, der Angreifer aber Clicks und Eingaben abfangen kann. Außerdem bietet es auch Schutz Trittbrettfahrern die Ihre eigenen Vorstellungen von Betrieb eines Services haben. (IE8 Security Blog: Clickjacking Defense) [Quelle?]

Server:/X-Powered-By:/Via: Um es (automatisierten) Angreifern nicht so einfach zu machen sollten Header die eine schnelle Identifikation (Fingerprinting) der eingesetzten Software Version erlauben entfernt (im Fall von X-Powered-By: was gerne von JSP compilern erstellt wird) werden. Der Punkt ist eher umstritten: es reduziert die Gefahr dass bekannte Lücken einfach ausprobiert werden nicht, dafür erschwert es den Administrator und Partnern die Überprüfung der Konfiguration. Da aber viele Assessment Tools das Vorhandensein der Header anmerken ist es für einen Softwareersteller ratsam diese Header (und Versionsstrings in Fehlerseiten) konfigurierbar zu machen. In dem zusammenhang ist die Empfehlung einen falschen Versionsstring zurückzuliefern sehr kritisch zu betrachten, lieber einen unkonkreten generischen Header. Z.b. gibt der Apache httpd nur "Server: Apache" aus, wenn "ServerTokens ProductOnly" gesetzt wird. [W3C RFC2616 HTTP/1.1]

Übrigens haben all diese Mechanismen bekannte (und unbekannte) Bugs in verschiedenen Browser Versionen. Nicht alle Browser unterstützen die Header im gleichen Funktionsumfang oder nach der gleichen Methode. Es macht dennoch Sinn diese einzusetzen da die Sicherheit von Web Anwendungen für größere Benutzergruppen dennoch verbessert wird. Zudem achten viele (automatisierten) Audits auf das Vorhandensein, so lässt sich mit geringem Aufwand bei der Anwendungserstelllung eine bessere Compliance erreichen.

Update 2012-11-08: Server header hinzugefügt, IE8 Security Blog artikel verlinked der X-Frame-Option erklärt.

TODO 2012-11-23: Es gibt noch die /crossdomain.xml policy files die von Flash und wohl auch dem Java Plugin beachtet werden. Diese Technologie kennt den X-Permitted-Cross-Domain-Policies: header. Dieser fehlt im Artikel noch.

Mit Hilfe des TPM kann auf moderner Hardware auf sichere Art und Weise Verschlüsselungmaterial abgelegt werden oder die idendität des Gerätes nachgewiesen zu werden. Windows ab Vista und 2008 Server unterstützt dies auch für Bitlocker Festplattenverschlüsselung. Aber das TPM kann auch für andere Anwendungen genutzt werden. Verwaltet wird es mit dem Management Consolen Plugin "tpm.msc". Die meisten Funktionen wie das übernehmen des Besitzes oder das Erzeugen von Keys kann aber über die Windows Management Instrumentation (WMI) auch gespcriptet werden. Dabei bietet sich insbesondere die Powershell an:

PS> $tpm = Get-WMIObject -Class Win32_Tpm -Namespace "root/CMIv2/Security/MicrosoftTPM" PS> $tpm IsActivated_InitialValue : False IsEnabled_InitialValue : False IsOwned_InitialValue : False ManufacturerId : 1112687437 ManufacturerVersion : 7.11 ManufacturerVersionInfo : Not Supported PhysicalPresenceVersionInfo : 1.0 SpecVersion : 1.2, 2, 1
Wenn man das Owner Passwort hat, so kann man das TPM auch mit der Powershell zurücksetzen:

PS> $tpm.Clear($tpm.ConvertToOwnerAuth('PASSWORT'.OwnerValue)) ReturnValue : 0
Wenn das TPM dies nicht zulässt, oder das Owner Passwort nicht bekannt ist, so ist es auch möglich über den Nachweis einer physischen Präsenz das TPM zu initialisieren oder zurückzusetzen.

Die Methode SetPhysicalPresenceRequest kann dazu mit dem Wert 5 (zurücksetzen) aufgerufen werden. Und GetPhysicalPresenceTransition liefert dann die Aktion die der Benutzer durchführen muss. Im Fall des Wertes 2 wäre dies ein Soft-Reboot und eine Bestätigung der Aktion im BIOS.

PS> $tpm.SetPhysicalPresenceRequest(5) ReturnValue : 0 PS> $tpm.GetPhysicalPresenceTransition() ReturnValue : 0 Transition : 2
Und wie erwarten funktioniert dies auch (ohne das Owner Passwort abzufragen). Getestet habe ich dies unter Windows 7 auf einem Dell Latitude E6510 mit einem TPM von Broadcomm.

Passwörter haben eine Menge Probleme. Deswegen gibt es jede Menge best-practice um diese Probleme etwas zu reduzieren. Eine einfache Regel ist, dass man Passwörter von Benutzern so abspeichern sollte, dass diese nicht wiederhergestellt werden können. Der Grund dafür ist insbesondere dass die Passwörter die ggf. in unterschiedlichen Diensten genutzt werden nicht eventuellen Hackern (oder unehrlichen Administratoren) in die Hände fallen können.

Dazu werden die Passwörter durch eine Hash Funktion einwegverschlüsselt. Bei der Prüfung des Passwortes wird dann nicht das eingegebene Passwort mit der gespeicherten Version vergleichen, sondern die Einweg-Funktion darauf angewendet und dann verglichen. Eine Konsequenz dieses Verfahren ist es, dass das Passwort von der Anwendung nicht wieder angezeigt oder per Mail an den User gesendet werden kann.

Bei mehr oder weniger öffentlichen Diensten ist es üblich, dass es dort eine Passwort-vergessen Funktion gibt die eine Reset Mail an den Benutzer versendet. Dieses Verfahren verlässt sich auf die Sicherheit des E-Mail Verkehrs - ist somit keine sonderlich sichere Option - aber bei Diensten die mehr oder weniger öffentlich angeboten werden ist die E-Mail Adresse sowieso die einzige zusätzliche Möglichkeit den User zu erreichen.

Es gibt im wesentlichen 3 Möglichkeiten für solche Passwort-Zurücksetzungsmails:

a) aktuelles Passwort per E-Mail zusenden. Das hat den ganz großen Nachteil, dass das Passwort dazu wiederhergestellt werden muss (also nicht Einweg-verschlüsselt sein kann). Außerdem wird das aktuelle Passwort unverschlüsselt per E-Mail versendet. Was besonders problematisch ist wenn dieses wiederverwendet wurde oder weiterverwendet wird.

b) neues Passwort erzeugen und zumailen. Nachteil bei dieser Methode: jeder kann eine beliebige E-Mail Adresse eingeben um deren Besitzer mit nicht funktionierenden Passwörtern zu nerven.

c) Reset-Link erzeugen und zumailen. Wenn der Benutzer den Link benutzt, so wird er um Eingabe eines neues Passwortes gebeten. Dies bietet den Vorteil, dass das alte Passwort weiterhin gültig bleibt wenn die Funktion jemand unberechtigt benutzt. Außerdem wird kein Passwort per (unverschlüsselter) Mail versendet.

Man sieht hier schnell, dass die Methode a) nicht nur die unsicherste und unpraktische ist, sondern auch dass man daraus auch als Endanwender (ohne den Quelltext zu analysieren oder die Datenbank zu kennen) sofort ablesen kann, dass die Web Anwendung eine unsichere Passwort Speicherung verwendet.

Immer wenn ich eine Passwort Recovery Mail mit einem bestehenden Passwort bekomme regt mich das auf, deswegen muss ich jetzt mal einfach hier im Blog "Fingerpointint" betreiben:

• Intel Software Network: speichert und mailt Passwörter an Benutzer
• BMC Servicedesk Express: speichert und mailt Passörter an Benutzer. (Beispiel)
• Open Application Group (OAGi) Portal. (Beispiel)
• RosettaNet.org (Beispiel)
• kontent.de (Beispiel)
• mailman Die GNU Mailing-List-Manager-Software weist wenigstens beim Anlegen eines Kontos schon drauf hin (einfacher wäre es die Eingabe generell zu entfernen und nur zufällige Passwörter zuzusenden)

Update: OAGi und Rosettanet.org (danke Christian) hinzugefügt. kontent.de hinzugefügt (danke Robin). Added mailman.

Mit Java 7 sind in den SSL/TLS Provider von Oracle einige neue Funktionen eingezogen. Darunter der schon lange erwartete Support für TLSv1.1 und TLSv1.2, aber auch die Unterstützung der TLS Extensions u.A. für die Server Name Indication(SNI).

Letzteres wird dazu verwendet virtuelle Hosts auf einem SSL Port zu unterstützen: Bisher konnte ein SSL Server nämlich nicht wissen an welchen (der potentiell vielen) virtuellen Dienste hinter einer IP Adresse sich der SSL Client wenden will. Besonders ärgerlich ist dies im Fall von HTTP/s, dort ist es die Regel dass Hoster sehr viele Kunden-Domains hinter ein und der selben IP-Adresse betreiben. In HTTP/1.1 wird der gewünschte Servername in der Anfrage mitgegeben (Host: Header). So kann der HTTP Server entscheiden welche Webseiten er ausliefern soll.

Im Falle des SSL Server Zertifikats (welches im SSL Handshake schon vor der HTTP Anfrage ausgetauscht wird), kann dies der Webserver aber nicht. Er muss raten welches Zertifikat er dem Client präsentieren soll, und das schlägt natürlich in der Regel fehl. Mit der Extension wird der Servername auch im Handshake mitgeschickt, und der Server kann sein Zertifikat passend auswählen.

Problem bei der Geschichte ist: der Server darf auf eine solche Namensanfrage mit einem SSL Alert (Warning) reagieren. In dieser sagt er, dass er sich für den angefragten Host nicht zuständig fühlt. Das kommt bei aktuellen Webserver Installationen häufig vor, weil diese einfach nicht korrekt eingerichtet sind (und die modernen Browser die SNI unterstützen diese Warnung auch einfach ignorieren). Da das zurückgelieferte Default Zertifikat oftmals den richtigen Hostnamen (in einer der Attribute) enthält, klappt der gesicherte Handschlag im Alltag dennoch. Nicht jedoch mit Java 7 SSL Clients, JSSE macht daraus eine fatale Exception:

javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name
	at sun.security.ssl.ClientHandshaker.handshakeAlert
	at sun.security.ssl.SSLSocketImpl.recvAlert
	at sun.security.ssl.SSLSocketImpl.readRecord
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake
	at sun.security.ssl.SSLSocketImpl.startHandshake
	at sun.security.ssl.SSLSocketImpl.startHandshake
	at sun.net.www.protocol.https.HttpsClient.afterConnect
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect
	at sun.net.www.protocol.http.HttpURLConnection.getOutputStream
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream

Ich habe deswegen einen Bugreport aufgemacht, jedoch wurde dieser wieder kommentarlos geschlossen. Falls Sie nun trotz Oracle's widerstreben die Notwendigkeit haben mit einem Web Server zu kommunizieren der SNI nicht richtig eingerichtet hat, so bleiben nur 2 Möglichkeiten über:

a) TLS aus der Liste der unterstützten Protokolle entfernen - mit einem SSLv3 Handshake wird kein Extension Record übertragen, und entsprechend klappt auch der Handshake (solange der Server SNI nicht benötigt).

b) den SSL Socket so initialisieren, dass die SSLEngine den Host nicht kennt. Dieser sogenannte Host hint wird für mehrere Dinge verwendet, kann aber auch weggelassen werden. Erreichen kann man dies, indem man den Socket statt mit s=factory.createSocket(name, port); mit "s=factory.createSocket(); s.connect(name,port);" erzeugt.

Übrigens ist dies ein ziemlich unerwartetes Verhalten: SSL mit Kerberos Authentifizierung würde nur auf die erste Art und Weise funktionieren, da hierfür die Identität des Servers bekannt sein muss.

Der Punkt a) ist ein schneller Fix, kommt aber in der Praxis eigentlich nicht in Frage, da man mit Java 7 ja eher daran Interesse hat TLSv1.1 oder TLSv1.2 zu verwenden um Lücken wie z.B. den BEAST-Angriff auszuschließen. Daher bleibt es nur übrig entweder den Anwendungscode zu ändern (oder wenn man diesen nicht selbst geschrieben hat, wie im Falle einer häufig verwendeten URLConnection oder beim Apache HTTPClient) oder aber mindestens eine eigene SSLSocketFactory zu implementieren, die auf die 2-stufige Erzeugung des SSLSockets aufsetzt.

Update: Ich habe in den Sourcen grade eine System Property gefunden, mit der man abschalten kann, dass der ClientHandshaker die SNI Extention sendet. Dies lässt sich als Work around gut verwenden: System.setProperty("jsse.enableSNIExtension", "false"); (muss vor der Verwendung von SSL Klassen im Programm, oder auf der Command Line gesetzt werden).

Von den Änderungen in Java SE 6.0 Update 29 zum Schutz vor SSL BEAST Angriffen hatte ich schon berichtet. Ein Opfer dieser Kompatibilitätsänderung sind die JDBC Treiber für den Microsoft SQL Server (jTDS und Microsoft JDBC Driver for SQL Server sind betroffen).

Beim Aufbau der Verbindung (TCP) direkt mit dem jTDS Treiber kommt es zu folgendem Fehler:

java.sql.SQLException: I/O Error: Software caused connection abort: recv failed
  State  : 08S01
  Error  : 0

Und die folgende Exception wirft der Microsoft JDBC Driver for SQL Server:

com.microsoft.sqlserver.jdbc.SQLServerException: Connection reset
  State  : 08S01
  Error  : 0

Wenn die Treiber durch einen Connection Pool benutzt werden, oder innerhalb einer Datasource, so kann es sogar zum Hängen (wegen Endlosschleife) kommen.

Eine Möglichkeit ist es, beim jTDS Treiber anzugeben, dass man kein SSL machen möchte (sollte aber eigentlich auch der default sein, laut jTDS FAQ). Dies kann man mit dem JDBC URL Property ";ssl=no" erreichen. Wenn der Server allerdings auf "Force Encryption" konfiguriert ist, so wird er dann die Logins ablehnen. Beim Microsoft Treiber würde das property "encrypt=false" lauten, dies half aber in meinen Versuchen (mit MS SQL Server 2008 R2 Express) nicht.

Eine weitere Möglichkeit ist es den SSL/TLS CBC-Fix per Java System Property abzuschalten: -Djsse.enableCBCProtection=false

Dies wirkt sich aber auf alle anderen SSL Verbindungen innerhalb dieser VM ebenfalls aus. Es gibt Berichte, dass dieses Problem mit JavaSE 6.0 Update 30 behoben sei, das kann ich aber weder nachvollziehen, noch lassen die ReleaseNotes darauf schließen. Ich habe mal einen Fehlerbericht bei jTDS dazu geöffnet.

Im September 2011 haben die Sicherheitsforscher Duong und Rizzo nachgewiesen, dass eine - seit 2002 bekannte und in TLS 1.1 behobene - Schwachstelle in den SSL 3.0 und TLS 1.0 Verschlüsselungsprotokollen nicht nur theoretisch ist, sonder wirklich ausgenutzt werden können. Unter bestimmten Bedingungen erlaubt diese Schwachstelle einem Angreifer Teile aus einer SSL/TLS geschützten Übertragung zu ermitteln.

Gezeigt wurde dies am Beispiel eines abgefangenen paypal http Session Cookies, was erlaubte eine Browser Sitzung zu übernehmen. Das Problem ist unter dem Namen „BEAST“ (Browser Exploit Against SSL/TLS) bekannt, und wird unter der Common Vulnerability ID  CVE-2011-3389 geführt. Bei der Demonstration wurde ein Java Applet verwendet um die notwendigen Daten einzuschleusen, nach Duong/Rizzo es soll aber auch mit WebSockets oder JavaScript XHR Aufrufen möglich sein.

Dies zugrundeliegende kryptografische Schwäche ist ein generelles Problem vom SSL 3.0/TLS 1.0. Es wurde aber als 2002 nur als theoretischer Angriff gesehen, jetzt sind Angriffe mit Hilfe der erweiterten Funktionen des WebBrowsers bekannt geworden. Da es für einen erfolgreichen Angriff nicht nur notwendig ist, dass die verschlüsselte Verbindung abgehört werden kann, sondern auch, dass der Angreifer in den Klartext eigene Stück einfügen kann (Chosen Plaintext). Dies ist durch die Verwendung von JavaScript auf Webseiten relativ einfach möglich.

Wird bei SSL/TLS eine Blockchiffre im CBC (Cipher Block Chaining) Modus verwendet, so benutzt SSL 3.0 und TLS 1.0 einen vom Vorgängerblock abgeleiteten Initialisierungsvektor. Da sich dieser ermitteln lässt ist hier ein Problem gegeben, das durch geschicktes einfügen von Füllzeichen in den Klartext erlaubt Inhalte zeichenweise an den Blockgrenzen zu ermitteln.

Dies zu behaben bedarf es einer neuen Protokollversion: TLS  1.1. Aber in TLS 1.0 und SSL 3.0 kann es nicht so einfach verhindert werden. Somit hilft mittelfristig nur ein Update auf diese „neuen“ Protokolle, die zwar schon Jahrelang verfügbar sind, sich aber in der Praxis in den meisten WebServern und WebBrowsern noch nicht durchgesetzt haben (vor allem nicht per default aktiviert sind).

Mögliche Gegenmaßnahmen zu BEAST (und deren Probleme) sind:

1. SSL/TLS Ciphers nicht im CBC Modus verwenden. Diese können in den gängigen Browsern und Servern abgeschalten werden. Die Gefahr dass dann Gegenstellen keine gemeinsame Verschlüsselung aushandeln können ist allerdings groß. Sollte also nur bei einer kleinen Anzahl von bekannten Kommunikationsgegenstellen benutzt werden.
2. Statt die CBC Chiffren abzuschalten kann auf jedenfall die Stromchiffre RC4 (TLS_RSA_WITH_RC4_128_SHA) bevorzugt werden. Diese verwendet kein CBC und ist damit nicht betroffen. Dies macht Google z.B. schon seit einiger Zeit. RC4 ist nicht unumstritten, es gibt Angriffe gegen das Verfahren, die aber in SSL nicht auftreten.
3. Oracle Java (JSSE) ab Version 1.6.0_29 und 7.0.0_1 implementiert einen CBC Schutz (der mit dem System Property jsse.enableCBCProtection aus kompatibilitätsgründen wieder abgeschalten werden kann) bei dem der erste Block in zwei mit der Länge 1 und (n-1) gesplittet wird. Erst mit Java 7 wird TLS 1.1 und 1.2 unterstützt.
4. Der gleiche Fix wird gerade in Chrome Beta 15 getestet, es gab schon Kompatiblitätsprobleme.
5. Für Opera 10.51 war der Fix geplant, ist aktuell noch nicht vorhanden (Opera benutzt keine WebSockets).
6. Dieser Schutz wird auch in Mozilla Firefox (via NSS library) eingebaut, wartet dort aber noch auf eine Lösung der Kompatibilitätsprobleme und ist somit nicht Bestandteil von Firefox 7 (Mozilla sagt die WebSockets sind nicht verwundbar).
7. Es ist zu erwarten dass Microsoft für den Internet Explorer nachzieht, bisher empfehlen sie nur die RC4 Chiffre zu bevorzugen (Windows XP scheint dies zu tun), Vorsicht bei dem Umgang mit http Seiten walten zu lassen und ggf. TLS 1.1 auf Client und Server zu aktivieren (immerhin unterstützen Microsoft Produkte dies schon, wird nur aus Kompatibilitätsgründen nicht aktiviert).
8. Die Option TLS 1.1 (oder neuer) zu verwenden wird leider noch einige Zeit auf sich warten lassen. Besonders da SSL 3.0 und TLS 1.0 abgeschalten werden müssten, um zu verhindern das Angreifer diese erzwingen. Leider hängt openssl der TLS 1.1 Entwicklung nach, so dass auch Apache hier nur mit der RC4 Cipher gerettet werden kann (alternativ kann man mod_gnutls oder mod_nss verwenden, die sind aber beide weniger stark in der Nutzung).

Microsoft hat mit Ihrem Security Development Lifecycle für eine deutliche Steigerung der Sicherheit Ihrer Produkte gesorgt. Zudem ist die Methodik offen zugänglich und verbessert somit die Software Entwicklung auch in anderen Firmen. Ein Konzept das bei der Analyse und Modellierung von Risiken und Bedrohungen im Ramen von SDL eingesetzt wird ist die STRIDE-Klassifizierung von Bedrohungen:

Threat	Definition
Spoofing	Impersonating something or someone else.
Tampering	Modifying data or code
Repudiation	Claiming to have not performed an action.
Information Disclosure	Exposing information to someone not authorized to see it
Denial of Service	Deny or degrade service to users
Elevation of Priviledge	Gain capabilities without proper authorization

Diese Klassifizierung finde ich nicht sonderlich nützlich. Die Klassen der Bedrohungen überlappen sich. Es ist eine Mischung aus Angriffen auf primäre und sekundäre Schutzziele. Viel besser finde ich es daher, bei der Betrachtung von Bedrohungen deren Auswirkungen auf die Primären Schutzziele der Informationssicherheit (CIA) zu betrachten:

Confidentiality (Vertraulichkeit)

Integrity (Integrität)

Availability (Verfügbarkeit)

Wenn alle drei Schutzziele erfüllt sind so stellt ein Informationssystem sicher, dass die richtige Person unverfälschte Daten jederzeit nutzen kann. Das CIA Trippel steht auch in der Kritik nicht alle Fälle abzudecken, so wird z.B. immer wieder angeführt dass Zurechnungsfähigkeit oder Nicht-Abstreitbarkeit (Accountability, Non-Repudiation) damit nicht abgedeckt werden. Das sehe ich allerdings nicht so, denn wenn eine Anforderung an ein IT System ist, dass man nachvollziehen kann wer etwas gemacht hat, so werden dazu eigene Daten erfasst, und deren Integrität (kann nicht verändert werden) und Verfügbarkeit (kann nicht unterdrückt werden) stellen sicher, dass authorisierte Nutzer diese Daten einsehen können.


Die STRIDE Eigenschaften lassen sich mit CIA gut ausdrücken:

Spoofing	Benutzer die sich als andere Nutzer ausgeben können sind nur ein Problem wenn daraufhin Daten unerlaubterweise weitergegeben werden (Vetraulichkeit) oder wenn andere Benutzer sich auf die Urheberschaft von Informationen verlassen (Integrität).
Tampering	Unerwünschtes ändern von Daten oder Code ist ein Angriff auf die Integrität des Systems
Repudiation	Ein System das Nachvollziehbarkeit benötigt kann darüber unverfälschte (Integrität) Aufzeichnung führen sie sich nicht unterdrücken (Availability) lassen.
Information Disclosure	Ein Verstoss gegen die Vertraulichkeit
Denial of Service	Ein Angriff auf die Verfügbarkeit des Systems
Elevation of Priveledge	Angreifer erlangt mehr Rechte als Ihm zustehen. Dies ist ein Problem wenn damit Angriff auf Integrität oder Vertraulichkeit erfolgt

Anhand der Gegenüberstellung wird klar, dass mit den 3 Schutzzielen die meisten Bedrohungen besser klassifizieren lassen.

David LeBlanc, einer der Väter der STRIDE Methode gibt dies in einem Blogpost auch offen zu. Er sieht trotzdem einen Anwendungsfall für die Methode in der Praxis. Ich persönlich würde mir wünschen, wenn SDL hier angepasst wird. Nützlicher sind hier eher Checklisten mit typischen Bedrohungen (und deren Auswirkungen auf die Primären Schutzziele).

Um Java Applets und JAR Files zu signieren nutzt man den jarsigner, der normalerweise ein Java-Keystore (.jks) file nutzt. Es ist allerdings ungünstig Codesigning Zertifikate einfach so in Files herumliegen zu haben (auch wenn man diese gesondert sichert). Es ist anzuraten ein Zertifikat besser in einer SmartCard oder einem Token zu speichern.

Der Oracle jarsigner.exe verwendet die Java Security Provider der JCE API. Um damit ein Hardware Token anzusprechen gibt es im wesentlichen 2 Methoden. Entweder den PKCS#11 Provider (benötigt eine PKCS#11 library (.dll oder .so) des Hardwareherstellers) oder unter Windows den Microsoft CryptoAPI (MSCAPI) treiber. Letzteres hat den Vorteil dass die meisten Smartcards unter Windows 7 oder 2008 bereits Treiber beim einstecken installieren. Diese Minitreiber sind nur begrenzt nutzbar, aber für das signieren reicht es aus.

Bei meinen Versuchen habe ich aber einige Einschränkungen gefunden:

• Es wird Java 5,6 oder 7(>b144) benötigt.
• Ich habe nur die Java Distribution von Sun/Oracle getestet
• In der 64bit Variante wird der Provider aktuell nur von Java 7 ausgeliefert
• Über MSCAPI wird immer in getrenntem Dialog nach PIN gefragt

Anbei Beispielbefehle zum auslesen des Keystores (in dem auch das Codesigning Zertifikat das auf dem USB Token gespeichert ist sichtbar ist) sowie dem Signaturvorgang:

c:\Program Files (x86)\Java\jdk1.6.0_24\bin>keytool -list -storetype Windows-MY

Keystore-Typ: Windows-MY
Keystore-Provider: SunMSCAPI

Ihr Keystore enthält 4 Einträge.
...
FIRMA AG, PrivateKeyEntry,
Zertifikatsfingerabdruck (MD5): 57:EF:97:04:EA:91:EE:FF:CF:BF:7F:75:AE:E1:A2:7D
...
c:\Program Files (x86)\Java\jdk1.6.0_24\bin>jarsigner.exe -storetype Windows-MY
%TEMP%\test.jar "FIRMA AG"

Als Speicher für die Zertifikate verwende ich ein Athena ASEKey Crypto Token in das ich mit den Athena IDProtect Tools auf einem anderen Computer das Codesigning Zertifikat von Verisign (Promo:WINQUAL99) importiert habe. Das Zertifikat ist übrigens ein Authenticode Class 3 Zertifikat das es aktuell für Teilnehmer am Microsoft WinQual Programm für ein Jahr günstig ($99) gibt. Entgegen den Angaben von Verisign lässt sich dieses auch problemlos für Java Signig verwenden.

Einziges Problem bei der Sache, mit -storepass oder -keypass lässt sich die PIN für die SmartCard nicht angeben, diese fragt immer mit einem Popup nach entsprechender Freigabe. Ich habe in den Athena Tools keine Möglichkeit gefunden diese abzuschalten (allerdings geht es mit der PKCS#11 API, wie ich im nächsten Beitrag berichten werde).

c:\Program Files (x86)\Java\jdk1.6.0_24\bin>jarsigner -verify -certs -verbose %T
EMP%\test.jar

         134 Thu Jun 02 23:27:48 CEST 2011 META-INF/MANIFEST.MF
         258 Fri Jun 03 00:04:02 CEST 2011 META-INF/FIRMA_AG.SF
        4764 Fri Jun 03 00:04:02 CEST 2011 META-INF/FIRMA_AG.RSA
           0 Thu Jun 02 23:23:38 CEST 2011 META-INF/
sm     15104 Sun Mar 06 04:56:06 CET 2011 jarsigner.exe

      X.509, CN=FIRMA AG, OU=Software Development, 
                OU=Digital ID Class 3 - Microsoft Software Validation v2,
                  O=FIRMA AG, ST=Baden-Wuerttemberg, C=DE
      [certificate is valid from 21.12.10 01:00 to 22.12.11 00:59]
      X.509, CN=VeriSign Class 3 Code Signing 2010 CA
      [certificate is valid from 08.02.10 01:00 to 08.02.20 00:59]
      [KeyUsage extension does not support code signing]
      X.509, CN=VeriSign Class 3 Public Primary Certification Authority - G5
      [certificate is valid from 08.11.06 01:00 to 17.07.36 01:59]
      [KeyUsage extension does not support code signing]


  s = signature was verified
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
  i = at least one certificate was found in identity scope

jar verified.

Update: Ich habe das ganze gerade mit der b144 von Java 7 getestet, und damit lassen sich sowohl mit 32bit als auch mit der 64bit Version der MSCAPI Provider für die Signatur von JAR Files via Smart Token nutzen.

Kris weißt in einem Tweet auf eine Diskussion zum Thema Sicherheit von Management-Adaptern hin. Im konkreten Fall wurde vermutet dass ein BMC (Der Mikro-Controller der die IPMI Schnittstelle bereitstellt) Spam Mails versendet hatte (nachdem er kompromittiert wurde). In dem Forum wird nicht klar, ob es wirklich der Fall ist und welche Schwachstelle dabei verwendet wurde. Aber in den Kommentaren sind einige sehr bedenkliche Meinungen und Vorgehensweisen zu entdecken:

Management Adressen (SSH, HTTP, Remote-IPMI) werden von einzelnen Admins absichtlich im öffentlichen Netz zugänglich betrieben - oder aus Versehen aus Unkenntnis. Hersteller der BMCs installieren keine oder unsichere Default-Passwörter. Generell waren die Admins der Meinung dass BMCs gar nicht die Ressourcen haben um Spam zu versenden, und es wird unterstellt die Firmware auf den Controllern sei unbedingt sicher.

Das ist natürlich eine naive Annahme. Auf den BMC Mikro-Controllern läuft ein Betriebssystem mit vollem IP-Stack und Anwendungsprozesse (Web Server, SSH Daemon, IPMI Agent, Shell/Menu) und diese können natürlich falsch konfiguriert werden oder verwundbar sein. Die IPMI Firmware wird oft von Administratoren vernachlässigt, weil es nicht in den normalen Update Prozessen des Betriebssystems integriert ist.

Ich sehe folgende Punkte für den Betrieb von Servern mit Management Adaptern (oder Lights-Out Karten) als wichtig an:

• Firmware des BMC in den Update/Patch Prozess aufnehmen
• Mittels physischer Ports oder VLANs BMC in getrenntem Management LAN betreiben
• Zugriff auf Management LAN beschränken, nur über sichere Hops zugreifen lassen
• Server provisioning Prozedur muss sichere Konfiguration der BMC Adapter beinhalten (Zertifikate, Passwörter, User, evtl. SSO, WoL Secret....)
• Verzicht auf Produkte die keine Netzwerksicherheit (Verschlüsselung) bieten

Generell kann man sagen, der Remote-Zugriff auf BMC Funktionen ist vergleichbar mit physikalischem Konsolen-Access (besonders dann wenn hier auch Consolas und Laufwerke gemapped werden können).