Skip to content

SQL Server JDBC Probleme

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.

SSL/TLS BEAST Lücke

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).

STRIDE vs. CIA

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:
ThreatDefinition
SpoofingImpersonating something or someone else.
TamperingModifying data or code
RepudiationClaiming to have not performed an action.
Information DisclosureExposing information to someone not authorized to see it
Denial of ServiceDeny or degrade service to users
Elevation of PriviledgeGain 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:
SpoofingBenutzer 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).
TamperingUnerwünschtes ändern von Daten oder Code ist ein Angriff auf die Integrität des Systems
RepudiationEin System das Nachvollziehbarkeit benötigt kann darüber unverfälschte (Integrität) Aufzeichnung führen sie sich nicht unterdrücken (Availability) lassen.
Information DisclosureEin Verstoss gegen die Vertraulichkeit
Denial of ServiceEin Angriff auf die Verfügbarkeit des Systems
Elevation of PriveledgeAngreifer 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).

jarsigner mit Tokens

jarsigner mit ASEKey Token Dialog unter Windows 7Um 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.

Hardware Security

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).

XSRF Schwachstelle auf dem ePetitions Server

Der ePetitions-Server des Deutschen Bundestages hat leider ein Sicherheitsloch. Das Eintragen und Austragen aus den Petitionslisten erfolgt durch einen einfachen HTTP GET Request ohne Sicherung durch ein Shared Secret (nonce). Deswegen ist es sehr trivial auf einer beliebigen Web Seite Bilder oder iFrames einzubauen die bei einem Besuch unbemerkt für den Besucher eine Anfrage an den Petitionsserver absenden. War der Besucher auf dem Petitionsserver angemeldet so wird die Aktion ohne weitere Nachfrage durchgeführt. Dies geht natürlich nur, wenn der Benutzer auf dem Server bereits angemeldet ist. Aber eine Gültige Login Session beim ePetitionsserver hat jeder der dort schon mal mitdiskutiert hat (das Session cookie läuft solange der Browser nicht geschlossen wird). Auf folgender Seite habe ich einen Proof of Concept erstellt. Besucher dieser Seite (nach der Vorschaltseite) werden in der Liste gegen das Gendiagnose-Gesetz eintragen. Sie müssen sich dort selbst wieder austragen. Wenn Sie die Seite besuchen wollen, so kopieren Sie den Link in die Browser Adresszeile. http://eckenfels.net/w/CompXSRFPetition Das BSI hat übrigend eine Studie zum Web2.0 veröffentlicht in der XSRF als eines der größten Sicherheitsprobleme genannt wird. Man kann zwar nicht behaupten dass der E-Petitionsserver sehr Web2.0 ist, aber immerhin hätte der Bund Ressourcen zur Verfügung gehabt dieses Sicherheitsloch selbst zu entdecken. Übrigens glaube ich nicht, dass die Schwäche in der eingesetzten Foren-Software SMF ist (da diese es an anderer Stelle wie Logout oder Profil richtig macht) sondern eher an der Erweiterung für die Abstimmungen. Über die Firma hinter dem Projekt findet sich einiges im Artikel von Alvar Freude. Vielen Dank an Matthias Bauer für den Hinweis auf dieses Problem.

OAuth Problem

We’d like to publicly show our appreciation for Twitter’s role in helping to minimize premature publicity of this threat, even at its own expense, taking the heat as if it was their own issue in order to allow other companies to address this threat.
Die Abschaltung der OAuth Authentifizierung bei Twitter Services führte zu einem Pressesturm. Das ReadWrite Web Blog hat jetzt eine (etwas aufgeblasene) Zusammenfassung der Ereignisse veröffentlicht. Persönlich finde ich - jetzt nachdem die Fakten klar sind - die ganzen Reaktionen etwas übertrieben. Immerhin ist es weiterhin so, dass Millionen von Anwender OAuth nicht nutzen (können) und Ihre Web 2.0 Passwörter weiterhin in dutzenden Third-Party Anwendungen eingeben um deren Dienste zu nutzen. Ein Session Fixation Angriff, wie er bei OAuth möglich ist hat dabei doch wesentlich weniger weitreichende Konsequenzen. Entsprechend ist auch das Ergebnis, dass alle OAuth APIs wieder aktiviert wurden, und das Protokoll nur in einem langfristigen Community Prozess noch etwas verbessert werden kann. Interessanterweise scheint die Flickr API Authentication dieses Problem z.B. nicht zu haben. Zum einen wird nach einem Authorisierungsversuch der Benutzer auf eine festgelegte WebSeite des Anbieters verwiesen, und zum anderen kann der Authorisierungstoken (frob) nur vom Dienstanbieter mit einem Signierten Request in einen Auth Token umgewandelt werden. Ich hab mir mal ne Mühe gemacht eine kleine Google Appengine Anwendung zu erstellen die diesen Vorgang vorführt.

Datenschutz bei Bahn und Telekom

Gerade fand auf dem 25C3 (Der jährliche Hauskongress des CCC, 2008 unter dem Motto "Nothing to hide") noch ein Vortrag darüber statt, dass die in Deutschland existierenden Grundsätze zum Datenschutz (insbesondere die einstmals fortschrittlichen Grundsätze zur Informellen Selbstbestimmung) eventuell nicht mehr der Bedrohungslage gerecht werden, und eher kontraproduktiv sind: The Trust Situation Why the idea of data protection slowly turns out to be defective Sandro Gaycken Eine These des Vortrags ist es, dass aktuelle in den Medien breit getretene Datenpannen auch positiv auf das Risikobewusstsein der Bevölkerung wirken. Entsprechend war auch der Datenpannen 2008 Vortrag auf dem 25C3 eine gute Zusammenfassung des Jahres. Und weil ich gerade von Pannen rede: der Spitzel-Skandal bei der DB ist ja grade die prominenteste Panne, aber als politischen Selbstmord muss man wohl die letzte Aktion der DB werten: sie haben Netzpolitik.org abgemahnt wegen Veröffentlichung eines Gesprächsprotokolles (das etwas Licht in die Machenschaften der DB bringt, zum Beispiel die Tatsache dass die Bahn ihre Top Manager und deren Ehepartner hat durchleuchten lassen. Delikaterweise wurden die Ehepartner über die Verkäufe der (verbilligten) Fahrkarten für Angehörige ermittelt). Alle Daten die erhoben werden, werden auch missbraucht... Genauso wie die Telekom hat auch die Bahn keinerlei Skrupel auf Bewegungsdaten Ihres Geschäftsbetriebes zuzugreifen (und diese auch noch an Ermittlungsfirmen weiterleiten). Dass die Ermittlungsfirma Network Deutschland GmbH unter anderem Telefonate und Kontenbewegungen durchleuchtet hat legt nahe, dass sie generell an solchen Listen Interesse haben. Update: wie zu erwarten zieht das Thema weite Kreise, bei der TAZ findet sich diese amüsante Zusammenfassung:
Die Bahn legt Wert auf Transparenz. Deshalb stochert sie auch gerne mal in den Privatdaten ihrer Mitarbeiter herum. Wenn es aber um die eigenen Angelegenheiten der Bahn AG geht, sieht es ganz anders aus. Informationen über den jüngsten Datenschutzskandal versucht die Bahn mit juristischen Mitteln zu unterdrücken. Es handele sich hierbei um Geschäftsgeheimnisse, schreiben ihre Anwälte.

Security Checklisten (Einfacher durch SCAP)

Das Hardening von Rechnern besteht typischerweise aus einer Abarbeitung von Checklisten. Ebenso gibt es jede Menge verbindlicher Standards und Security Profile, die eine gewisse Konfiguration von Rechnern voraussetzen. In der Vergangenheit waren diese Arbeiten immer mit handgestrickten Scripten oder kommerziellen Produkten verbunden. Dank der Amerikanischen Cyber Terror Angst werden aber durch diverse Behörden und Regierungsnahe Stellen immer wieder sehr nützliche Innovationen vorangetrieben. Einiges läuft dort inzwischen unter dem Information Security Automation Program: OVAL ist eine XML Sprache zur Beschreibung von Platform Checks. Mit einem OVAL Interpreter können diese ausgeführt werden, und die entsprechenden Reports helfen somit bei der Systemadministration. Neben der OVAL Language gibt es auch das OVAL Repository das eine Reihe von Prüfungen (Vulnerabilities, Patches, Inventory) frei anbietet. Neben der Referenzimplementierung des OVAL Interpreters werden auch noch weitere Open Source Projekte entsprechende Tools anbieten. So zum Beispiel OpenVAS 2.0 Beta. Neben OVAL das auf die Systemtechnische Seite von Security Empfehlungen eingeht gibt es noch das XCCDF (The Extensible Configuration Checklist Description) Format. Schwerpunkt hier ist es die ganzen Punkte einer Checkliste formalisiert darzustellen. Unterstützt werden dabei sowohl Profile (Subsets von Controls) als auch die Integration von automatisierten Checks (z.B. mittels OVAL). In dem Umfeld gibt es eine ganze Reihe Protokollen:
  • CVE - Die öffentliche Software Schwachstellen Datenbank
  • CCE - Configuration Items
  • CPE - Platformen
  • CME - Malware
  • CWE - Software Weakness und
  • CAPEC - Angriffsmuster
Besonders CVE ist dabei sehr weit verbreitet, da es die Unzahl vor Hersteller und Distributoren spezifische Codes vereinheitlicht hat. Diese Notwendigkeit ist insbesondere im Linux Umfeld entstanden, da jeder Distribution ihr eigenes Süppchen gekocht hat. Aber auch die Vereinheitlichung der anderen Dimensionen der Klassifizierung von Schwachstellen macht das Leben eines Systemadministrators oder Security Officers einfacher.

Hash Funktionen

Es gibt Neuigkeiten im Bereich Kryptographie, insbesondere im Bereich der sicheren Hash Funktionen: Halloween war Einreichungsschluss beim NIST Wettbewerb "NIST hash competition" der unter dem Namen SHA-3 einen würdigen Nachfolger für die in Verruf geratenen Hash Algorithmen SHA-1 und MD5 sucht. Es gibt noch keine offiziellen Ergebnisse, aber eine inoffizielle Bewertung im SHA-3 Zoo Wiki der TU-Graz. Außerdem hat NIST eine neue Revision des Secure Hash Standards (SHS) in FIPS 180-3 (PDF) veröffentlicht. Hier werden die folgenden fünf Algorithmen definiert: SHA-1, SHA-224, SHA-256, SHA-384 und SHA-512. Auf die bekanntgewordenen Angriffe gegen SHA-1 geht die FIPS Publikation allerdings nicht ein, die Sicherheitsbewertungen wurden aber entfernt, damit diese in Special Publications schneller aktualisiert werden können. (Via D-kriptik Blog)