Federlesen #14: Mehr Sicherheit bei und mit Apache-Produkten

Inhaltsverzeichnis

Nicht erst durch PRISM und XKeyscore hat das Thema Sicherheit eine große Aufmerksamkeit in der Öffentlichkeit erlangt. Da Open-Source-Software der Apache Software Foundation bei Entwicklern und Administratoren beliebt ist, stellt sich die Frage, wie sicher diese Produkte sind und welche Möglichkeiten es gibt, ihr Sicherheitsniveau zu erhöhen.

Die oft diskutierte Frage, ob Open-Source-Software sicherer als kommerzielle Software ist, lässt sich nur schwer beantworten, da das Thema Websicherheit viele Aspekte hat. Hier spielt nicht nur die Zahl oder die Kritikalität der gemeldeten Sicherheitslücken eine Rolle, sondern auch der Umgang damit. Neben den Herstellern sind genauso die Nutzer der Software in der Pflicht, sich frühzeitig und regelmäßig mit Sicherheit zu beschäftigen. Einen automatisierten Sicherheitsdienst gibt es bei Apache nicht, hier ist es nötig, selbst die vorhandenen Informationen gezielt zu nutzen.

Eine gute Einstiegsstelle ist die Common Vulnerabilities and Exposures List (CVE), die seit 1999 die MITRA Corporation MITRE kostenlos zur Verfügung stellt. Um Mehrfachnennungen gleicher Schwachstellen zu vermeiden, werden gemeldete Fehler mit einem eindeutigen Bezeichner (CVE-YYYY-NNNN) und einer Risikoeinschätzung pro Meldejahr zentral erfasst und kategorisiert. Da die Sicherheitslücken allein durch die große Vielzahl der Produkte zugenommen haben, kann die vierstellige fortlaufende Nummer ab Anfang des nächsten Jahres bei Bedarf auch länger sein. Wie bisher erhalten nur die Nummern 1 bis 999 führende Nullen, um vierstellig zu sein.

Apache hält derzeit den Platz 13 der Top-50-CVE-Listen mit 470 gemeldeten Fehlern in 80 Produkten, was durchschnittlich sechs Fehler pro Produkt bedeutet. Bei den häufigsten Sicherheitsfehlern, die sich auch in anderen Listen wie der von OWASP wiederfinden, handelt es sich um DoS-Attacken (Denial Of Services), Cross-Site Scripting (XSS) und Bypass-Operationen.

Möchte man nach bekannten Sicherheitslücken in Apache-Produkten suchen, wird man in dem Bugtracker oder den Change-Protokollen der Produkte fündig. Etwas komfortabler geht es für alle Apache-Produkte über folgende Abfrage in der CVE-Datenbank, die sich dann noch gezielt verfeinern lässt. Alternativ, wenn auch nicht ganz aktuell, kann man in der National Vulnerability Database (NVD) des NIST-Instituts suchen.

Allgemeine Informationen zum Thema Sicherheit bei der Apache Software Foundation finden sich unter http://www.apache.org/security/, für das ein eigenes Sicherheits-Team mit der E-Mail-Adresse security@apache.org projektübergreifend zuständig ist. Einige Apache-Produkte betreiben eine eigene Seite, die die behobenen CVE-Schwachstellen auflistet, und eigene Mailinglisten, wie security@tomcat.apache.org, oder deren Archiv unter. Für den Apache-HTTP-Server, Tomcat oder Struts-Webframework gibt es Sicherheitsberichte für jede unterstützte Version.

Da Vorbeugen besser als Heilen ist, helfen auch spezielle Hinweisseiten, wie

• http://wiki.apache.org/tomcatq/FAQ/Security
• http://tomcat.apache.org/tomcat-8.0-doc/security-howto.html
• http://httpd.apache.org/docs/trunk/misc/security_tips.html

weiter, potenzielle Sicherheitslücken bereits bei der Konfiguration zu vermeiden. Den letzten Einbruch und Diebstahl der Nutzerdaten hätten die Betreiber des Apple-Entwicklerportals vermeiden können, wenn sie die ausgenutzte Schwachstelle CVE-2013-2251, die mit Struts 2.3.15 bereits behoben war, rechtzeitig aktualisiert hätten.

Türsteher und Filter

Um nicht jedem Zutritt zu gewähren, hat es sich bei Webanwendungen bewährt, einen Proxy zu verwenden. Beliebt ist dabei das Reverse Proxy Module des Apache-HTTP-Servers. Statt eines HTTP-Servers lässt sich auch der Apache Traffic Server als Cache-Proxy oder das Firewall-Modul mod_security einsetzen, um den direkten Zugriff auf die nachgelagerten Systeme zu erschweren.

Mit einem zwischengeschalteten Filter lassen sich CSRF-Angriffe (Cross-Site Request Forgery) verhindern. Für Tomcat 6 und 7 ist der Token-basierte CsrfPreventionFilter bereits für die Verwaltungsanwendungen Manager und Host aktiviert oder kann auch in den eigenen Webanwendungen einfach in der Datei WEB-INF\web.xml aktiviert werden. Für den Apache-Server gibt es ein noch recht neues, unter der LGPLv2 stehendes Modul mod_csrf zum Verhindern von CSRF-Angriffen.

Verschlüsselung

Verschlüsselte Nachrichten

Erst Anfang des Jahres wurden manipulierte Installationsdateien des Apache-Servers entdeckt, die eine Backdoor öffneten. Deshalb sollten Dateien vor der Installation besser überprüft werden. Zur Kontrolle, ob ein Apache-Release nicht manipuliert wurde, werden diese zusammen mit einem dafür gültigen MD5-Hash-Wert zur Verfügung gestellt. Wer zum Beispiel die heruntergeladene binäre Tomcat-Installationsdatei und die dazu gehörige Datei mit dem MD5-Hash in ein Verzeichnis legt, kann mit md5sum -c apache-tomcat-7.0.42.zip.md5 überprüfen, ob die Zip-Datei denselben Hash-Wert enthält. Noch etwas genauer geht es mit der PGP-Verschlüsselung (Pretty Good Privacy). Hierzu muss man vorher die OpenPGP-Schlüssel der Release-Manager herunterladen, importieren und mit den OpenPGP-Signaturen in der ASC-Signaturdatei gegen die Release-Datei verifizieren. Das geht in mehreren Stufen:

gpg --import KEYS und gpg --verify apache-tomcat-7.0.42.zip.asc

Schließlich ist zu verifizieren, ob der Fingerabdruck zum angegebenen Benutzer passt. Wer nicht die Schlüssel von Apache, sondern lieber von einem öffentlichen Server verwendet, kann diese mit gpg --keyserver pgpkeys.mit.edu --recv-key 2F6059E7 für den angegebenen Release-Manager versorgen und dann mit gpg --fingerprint 2F6059E7 validieren.

Um das Lesen von Texten zu erschweren, kann man diese verschlüsseln. Ein einfache Möglichkeit besteht darin, diese durch einen Hash-Wert zu ersetzen. Bei Passworten sollte dieser unbedingt um einen weiteren Salt-Wert ergänzt werden. Neben dem verwendeten Algorithmus spielt auch die Länge des Schlüssels oder Hash-Werts eine große Rolle, um die Berechnung des ursprünglichen Werts zu erschweren. Der Message-Digest-Algorithmus 5 (MD5) ist eine nach RFC 1321 standardisierte und deshalb weit verbreitete Hash-Funktion, um aus einer Nachricht einen 128-Bit-Hash-Wert zu erzeugen. Wer nicht selbst mit der Java-API einen kryptographischen Hash-Wert erstellen will, kann das auch mit Apache Commons Digest oder Apache Shiro tun. Mit Commons Digest wird ein einfacher MD5-Hash erstellt und mit Shiro ein mit einer Zufallszahl gesalzener SHA512-Hash.

import org.apache.shiro.crypto.hash.Sha512Hash;
public class MD5 {
    public static void main(String[] args) {
        String salz = org.apache.commons.
                lang3.RandomStringUtils.randomAlphanumeric(16);
        System.out.println(salz);
        String md5 = org.apache.commons.codec.digest.DigestUtils
                .md5Hex("MeinPasswort") + salz;
        Sha512Hash sha512Hash = new Sha512Hash("MeinPasswort", salz);
        System.out.println(md5 + " " + sha512Hash);
    }
}

Seit dem JDK 1.4 gibt es für kryptographische Algorithmen die Java Cryptography Extension (JCE), die Teil der Java Cryptography Architecture (JCA) ist. Da die Vereinigten Staaten den Export kryptographischer Systeme beschränkt, werden mit der Java-Laufzeitumgebung nur kurze und damit schwache Schlüssel ausgeliefert. Stärkere Schlüssel sind bei Oracle oder IBM für die jeweilige Java-Version separat herunterzuladen. Die geänderten Policy-Dateien local_policy.jar und US_export_policy.jar kopiert man einfach in das jre/lib/security-Unterverzeichnis.

Welche Security-Provider installiert sind und welche Schlüssellängen unterstützt werden, lässt sich leicht mit folgendem Programm herausfinden:

System.out.println("Security-Provider:");
for (Provider prov : Security.getProviders()) {
    System.out.println("  " + prov + ": " + prov.getInfo());
}
    System.out.println("\nMaxAllowedKeyLength in:'" + "  DES     = "
    + Cipher.getMaxAllowedKeyLength("DES")
    + Cipher.getMaxAllowedParameterSpec("DES") + "\n"
    + "  Triple DES = "
    + Cipher.getMaxAllowedKeyLength("Triple DES")
    + Cipher.getMaxAllowedParameterSpec("Triple DES") + "\n"
    + "  AES        = " + Cipher.getMaxAllowedKeyLength("AES")
    + Cipher.getMaxAllowedParameterSpec("AES") + "\n"
    + "  Blowfish   = "
    + Cipher.getMaxAllowedKeyLength("Blowfish")
    + Cipher.getMaxAllowedParameterSpec("DES") + "\n"
    + "  RSA        = " + Cipher.getMaxAllowedKeyLength("RSA")
+ Cipher.getMaxAllowedParameterSpec("DES") );

Das am meisten verwendete Verschlüsselungsprotokoll ist TLS beziehungsweise HTTPS. Auch hier gibt es mit mod_ssl ein standardmäßig aktiviertes Modul für den Apache-Server. Bei der Konfiguration des SSL Connector sollte man darauf achten, eine SSLCipherSuite mit starken Algorithmen und ein öffentliches Zertifikat vertrauenswürdiger Provider zu verwenden. Im neuen Tomcat 8 gibt es deswegen eine einfache Möglichkeit, sich die konfigurierten CipherSuiten anzeigen zu lassen. Alternativ geht das auch mit folgendem Programm:

SSLSocketFactory sslsockfact = 
(SSLSocketFactory) SSLSocketFactory.getDefault();
String[] supportedCipherSuites = 
sslsockfact.getSupportedCipherSuites();
System.out.println("supported CipherSuites:");
for (int i = 0; i < supportedCipherSuites.length; i++) {
        System.out.println(supportedCipherSuites[i]);
}

Da es verschiedene Versionen des Secure Sockets Layer (SSL) und seines Nachfolgers Transport Layer Security (TLS) gibt, sollte man die unterstützen Protokolle abfragen, etwa mit folgendem Programm:

System.out.println("Supported SSL-Protocols:");
SSLSocket sslsocket = 
(SSLSocket) sslsockfact.createSocket("heise.de", 80);
String[] supportedProtocols = sslsocket.getSupportedProtocols();
for (int i = 0; i < supportedProtocols.length; i++) {
        System.out.println(supportedProtocols[i]);
}

Im kommenden Java 8 spielt das Thema Sicherheit eine große Rolle, sodass hier einige kryptographische Algorithmen, wie der Diffie-Hellman-Algorithmus (DHE) für 2048 Bytes oder Hash-Funktionen wie SHA-224, SHA-256, SHA-384 und SHA-512 Message-Digest sowie längere Schlüssel möglich sind. Um XML-Nachrichten zu signieren, gibt es den JSR 105 (Java XML Digital Signature 1.1). Die Implementierung unter javax.xml.crypto führte Java 6 ein, sie basiert auf dem Apache-Projekt Santuario, das vorher unter Apache XML Security bekannt war. Mit Java 8 wird der Standard dann vollständig unterstützt.

Fazit

Geheimdienste, Trojaner, Viren und Hacker werden ständige Begleiter bei der Reise durch das Internet bleiben. Zum wachsamen und verantwortungsvollen Umgang mit dem Thema Sicherheit gehört der Einsatz aktueller und korrekt konfigurierter Software. Mit einer starken Verschlüsselung lässt sich zumindest das Ausspähen kritischer Informationen erschweren. Achtsamkeit, Selbstverantwortung und schnelle Reaktionsfähigkeit spielen beim Einsatz von Open-Source-Software eine große Rolle. Die Apache-Produkte bieten viele Möglichkeiten, das Sicherheitsniveau zu heben – wenn man weiß wie.

Frank Pientka
ist Senior Software Architect bei der Materna GmbH in Dortmund. (ane)