Tag Archives: Sicherheit

JavaMail and TLS: Turn on the security switch!

While talking to Ge0rg about latest issues in Java TLS we stumbled upon the question whether the JavaMail API would have similar problems.

Naturally one would expect that Java’s SSL implementation is secure. However, this is not the case: Special care needs to be taken regarding Man-In-The-Middle attacks: While a certificate may turn out to be valid, you cannot be sure that it has the right origin!

The problem is known for a while and library maintainers are taking steps to avoid it. However, for compatibility reasons those features may need to be turned on.

For JavaMail version 1.5.2 the SSLNOTES.TXT says specifically:

— Server Identity

Check RFC 2595 specifies addition checks that must be performed on the server’s certificate to ensure that the server you connected to is the server you intended to connect to. This reduces the risk of “man in the middle” attacks. For compatibility with earlier releases of JavaMail, these additional checks are disabled by default. We strongly recommend that you enable these checks when using SSL. To enable these checks, set the “mail..ssl.checkserveridentity” property to “true”.

Here is the thing that most examples forget: You need to switch that feature on!

To use SSL at all, you need to turn it on, either by specifying “imaps” in the property mail.store.protocol or by setting mail.imap.starttls.enable to “true”. Replace imap respectively for other protocol suites (e.g. smtp).

Update 2014-08-05: Inserted the Link to Georg’s blog post about latest issues in Java TLS.

WordPress Key-Generator reloaded

Das Gegenteil von »gut« ist »gut gemeint«. Im konkreten Fall hätte ich nicht gedacht, dass die Jungs von WordPress immer noch den Service anbieten, mit dem sich die notwendigen Keys generieren lassen kann, die man in die Config eintragen muss.1

Ich hatte das schon beim Upgrade auf Version 2.6 im Beitrag »Keys für Upgrade auf WordPress 2.6« thematisiert. Anscheinend hat das niemanden interessiert.

Egal wie groß das Vertrauen zu Anbieter XY sein mag. Es ist sicherheitstechnisch betrachtet äußerst fragwürdig, sich seine Schlüssel von jemand anderem generieren zu lassen. Selbst drei mal einen Apfel auf die Tastatur fallen lassen, ist da noch sicherer. Also Leute: Hirn einschalten, Schlüssel selbst generieren. Möglichkeiten das auf seinem eigenen Rechner zu tun, gibt es wie Sand am Meer, da braucht man keine Website von wordpress.org dafür!

  1. siehe Neue Schlüssel ab WordPress 3.0 für die Konfiguration []

Gebrauchte Daten kaufen

In den letzten Wochen habe ich für dienstliche Zwecke vier alte Speicherkarten vom Typ MMC gebraucht bei der elektronischen Bucht erstanden. Auf allen vieren waren noch Daten drauf. Sicher, die waren frisch formatiert, aber alle nur im Schnelldurchlauf. Neues Dateisystem anlegen und fertig. Kein einziger der Verkäufer hielt es für notwendig, wirklich alle Daten zu löschen.

Ich bin nun kein Forensiker und meine Zeit für solchen Spielkram ist begrenzt. Aber da ich den coolen Hex-Editor Bless sowieso installiert und Images der Karten angelegt hatte, um Partitionstabellen und Volume Boot Records zu untersuchen, hab ich natürlich noch kurz weiter über die Dumps geschaut. Beim wirklich nur flüchtigen drüber Gucken habe ich Kartendaten für ein Navigationsgerät, Musikdateien im mp3-Format und Tabellen mit Adressen von Ärzten1 gefunden. Gerade bei letzterem handelt es sich um sensible Daten, die man vermutlich nicht wissentlich weitergegeben hat. Da rollen sich mir ja dann schon die Fußnägel hoch.

Damit die ganze Aufregung hier nicht umsonst ist, noch ein kleiner Tipp, wie man hier zwei Fliegen mit einer Klappe schlagen kann. Man benutzt einfach das Tool badblocks unter Linux im Schreibmodus. Vorsicht ist angebracht, mit Datenträgern, die man noch braucht, wenn aber wirklich alles gelöscht werden kann, dann hier der Auszug aus der manpage mit der passenden Option:

-w Use write-mode test. With this option, badblocks scans for bad blocks by writing some patterns (0xaa, 0x55, 0xff, 0x00) on every block of the device, reading every block and comparing the contents.

Das Programm schreibt also bestimmte Muster auf die Karte und liest diese dann nochmal zurück und zwar für jeden einzelnen Block. Wenn Fehler dabei auftreten, werden die gemeldet und man kann den Datenträger wegwerfen. Wenn keine Fehler auftreten, kann man die Karte ruhigen Gewissens verkaufen und sicher sein, dass ausschließlich Nullen drauf stehen.

Ganz wichtig: damit das funktioniert, führt man badblocks mit root-Rechten aus und lässt es auf das ganze Device los. Da muss man vorher das passende rausfinden und 100% (und kein µ weniger) sicher sein, dass man das richtige erwischt hat. Wenn noch ein Filesystem auf der Karte ist, einfach mounten und mit mount nach dem Device gucken. Oder mit dmesg anzeigen lassen, wie die Karte beim Anstecken erkannt wurde. Oder aus /proc/partitions das Device mit der passenden Größe ablesen. Oder am besten alle Möglichkeiten zusammen. Der fertige Befehl in meinem Fall hier und heute:

Falls man nun gerade kein Linux zur Hand hat, bitte in Windows beim Formatieren unbedingt vermeiden die »Schnellformatierung« zu aktivieren. Oder am besten nach der Formatierung nochmal das Programm h2testw der c’t drüber laufen und Daten schreiben lassen, damit wenigstens die Adressdaten der Homöopathen verschwinden. Nicht dass die am Ende noch wer aufsucht, oder vermöbelt oder potenziert oder so …

Ach ja und abgesehen vom Verkaufen von alten Datenträgern: die erwähnten Programme sollte man auch auf jeden frisch neu erworbenen Datenträger loslassen, um sicherzugehen, dass der auch funktioniert. Ist mir nämlich in den letzten Wochen mit einer neuen Festplatte und einem neuen USB-Stick passiert, dass die gleich vom Start weg defekt waren und umgetauscht werden mussten.

  1. und Homöopathen, man beachte die Unterscheidung … ;) []

SpamAssassin: Von der Zeit eingeholt

Heute kam die berechtigte Beschwerde eines Webserver-Mitnutzers, dass viele E-Mails neuerdings fehlerhaft als Spam klassifiziert würden. Als fähiger Informatiker hat er auch gleich noch ein Beispiel mitgeliefert. Darin wurde eine Regel sichtbar, die ich bislang noch gar nicht weiter beachtet habe und die bis zum Beginn dieses Jahres durchaus sinnvoll war:

FH_DATE_PAST_20XX

Diese Regel vergibt Punkte fuer alle E-Mails die ab dem 01.01.2010 datiert sind. Und nicht nur ein paar Zehntel, sondern bis zu 3.5 Punkte — bei insgesamt 5 nötigen Punkten für eine Spam-Klassifizierung macht das sehr viel aus. Effektiv wurde damit die Grenze für Spam auf 1.5 Punkte herabgesetzt.

Die Lösung ist im Apache-Wiki zu finden und wurde gleich noch mitgeliefert: In der lokalen Konfiguration muss diese Regel manuell deaktiviert werden, indem man die vergebenen Punkte auf 0.0 setzt. (Ein sa-update hatte bei mir keinen Effekt.)

Das ist mal ein schönes Beispiel dafür, dass insbesondere Regeln, die nicht global gültig sind und bleiben, regelmäßig begutachtet und gegebenenfalls überarbeitet werden müssen.

Resistente Virenschleuder

Als die Europäer das amerikanische Festland eroberten und die fälschlicherweise als Indianer bezeichneten Ureinwohner verdrängten, brachten sie neben Waffen und billigen Geschenken unbeabsichtigt noch etwas anderes mit: Krankheiten, gegen die sie selbst resistent waren, die den Indianern aber schwer zusetzten.

Warum erzähle ich das?

Als Linux in verschiedenen Distributionen begann, den Desktop zu erobern und mit der Ausbreitung des Internets auch Viren, Würmer und andere Malware populär wurden, stellte sich eines heraus: So richtig betroffen waren nur die Windows-Nutzer. Einen Virus für Linux zu schreiben, war ungleich schwerer und die Zahl der Nutzer war doch nicht hoch genug, als dass es sich lohnte. Folglich ist der Linux-Nutzer (und jeder Nutzer anderer Betriebssysteme) gegen die Windows-Viren resistent. Was besagten Nutzer jedoch nicht davor bewahrt, unwissend Überträger zu sein. Denn niemand verhindert, dass er auf seiner Festplatte, seinem USB-Stick und in seinen E-Mails Dateien hat, die eine Form von Schädling enthalten. Ein Windows-Nutzer, der eine Datei eines Linux-Nutzers weniger argwöhnisch öffnet, weil er ihm vertraut, wird so doch das Opfer einer Attacke gegen sein System. Ein Vertrauensbruch, der so nicht beabsichtigt war.

Jeder Windows-Nutzer lernt beizeiten, einen Virenscanner zu installieren, um sich gegen Schädlinge zu schützen. Linux-Nutzer fühlen sich sicher und brauchen solche Software nicht. Damit werden sie zum idealen Überträger, da sie nicht einmal wissen, was sich auf ihrer Platte tummelt.

Aufgefallen ist mir das, als mir jemand schrieb, in einer von mir hochgeladenen Datei (die ich auch von anderer Stelle per USB-Stick empfangen habe) einen Virus entdeckt zu haben. Zwar handelte es sich um einen Fehlalarm, trotzdem macht dies eines klar: Selbst wer nicht betroffen ist, sollte seinen Datenbestand hin und wieder nach Viren untersuchen!

Freie Virenscanner gibt es zum Beispiel mit ClamAV, die man per Cron-Job regelmäßig über seine Daten jagen kann. USB-Sticks lassen sich bei Bedarf automatisch überprüfen, wenn man auf die Daten zugreift, und schon ist das Netz ein wenig dichter und die Gefahr, selbst zur Virenschleuder zu werden, ein Stück geringer.

Andere Länder, andere Adressen

Wie der eine oder andere vielleicht mitbekommen hat, halte ich mich derzeit in Trondheim auf. Für die weniger Kundigen der europäischen Geografie: das ist in Norwegen. Ein paar gute Freunde von mir, haben dieser Tage ihren DSL-Anschluss bekommen, bei einem der örtlichen Provider, der auch gleich ein DSL-Modem mit integriertem Router (ohne WLAN) mitgeliefert hat. Das Ding, das über vier Fast Ethernet Ports verfügt, angestöpselt, Zugangsdaten braucht man dank Fernkonfiguration ja heutzutage nicht mehr und los geht’s…

Interessant war dann, was der DHCP-Server des Providers (Tele2) tut. Ich bekam mit meinem Notebook eine IP 90.***.***.*** aus einem öffentlichen Adressbereich und mit einer Subnetz-Maske von 255.255.248.0. Wie bitte? utrace* sagte zunächst, dass ich eine IP aus Trondheim hätte. Ich befand mich in einem Subnetz für 2046 Hosts und die IP sollte öffentlich sein? Ein SSH von unserem Root-Server auf mein Notebook bestätigte dies. Auf ein

antworteten auch noch 2010 Hosts und da würden die guten Menschen jetzt direkt ihre Windows-Kisten mit reinhängen? Womöglich noch ohne Firewall? Nix da! Für WLAN war eh der alte NAT-Router geplant und der wurde flux mal eben an die Kiste vom Provider gehängt. Jetzt surfen die Schäfchen brav in 192.168.1.1/24 und was da draußen passiert, stört nicht weiter.

Interessanterweise hatte der NAT-Router per DHCP übrigens eine ganz andere IP-Adresse aus dem Raum Oslo bekommen mit einer wesentlich stärker eingeschränkten Subnetz-Maske, ich glaube sogar für nur 2 Hosts. Da würde mich ja mal interessieren, wie der DHCP das erkannt hat. Der muss ja dann doch irgendwie Mac-Adressen auswerten oder ähnliches.

HowTo: CAcert Zertifikat für eisfair-Webserver

Der Apache-Webserver für eisfair kann selbstverständlich auch mit SSL umgehen. Das ist beispielsweise sinnvoll für alle Anwendungen, die man auf dem heimischen Server laufen lassen möchte und die Authentifizierung verlangen, damit die Passwörter, die über’s Netz gehen definitiv verschlüsselt sind. Auch die Inhalte wie beispielsweise die vom Webmailer bleiben der Öffentlichkeit lieber verborgen.

Wenn man bei CAcert angemeldet ist, liegt es nahe, sich auch für den eisfair-Server zu Haus ein passendes Zertifikat ausstellen zu lassen. Voraussetzung dafür ist folgendes:

  • eisfair-Server mit den installierten Paketen apache2 und certs
  • Account bei CAcert und genügend Punkte zum Erstellen eigener Server-Zertifikate

Sind alle Voraussetzungen erfüllt, geht man wie folgt vor. Zunächst ruft man auf dem eisfair-Server das Setup-Menü auf und geht ins Service-Menü von certs. Dort wählt man den Punkt Manage certificates. Daraufhin ändert man über 1 den key type auf web server. Als nächstes wählt man Punkt 10 (create a new key or select an exiting one [apache]), sonst schlägt der folgende Punkt fehl. Nun wählt man Punkt 11 (create certificate request), das verlangt CAcert nämlich später beim Erstellen des Zertifikats. Bei den Eingaben kann man sich weitestgehend an die Vorgaben halten. Wichtig: Als Common Name die Domain (FQDN) angeben, unter der der Server später erreichbar sein soll, beispielsweise www.example.dyndns.org, wenn man das später von draußen so im Browser eintippt, um den Heimserver zu erreichen. Als Challenge passwort gibt man einen einfachen Punkt ein.

Der Certification Request liegt jetzt unter /var/certs/ssl/csr/apache.csr. Den Inhalt dieser Datei benötigt man, um nun auf der Webseite von CAcert sein Zertifikat zu beantragen. Also kopiert man den Inhalt der Datei und loggt sich bei CAcert ein. Dort wählt man auf der rechten Seite Server Zertifikate und Neu. Nach einem langen, wichtigen Text gibt es unten ein großes Eingabefeld, in das man nun den Inhalt der Zwischenablage beziehungsweise den Certification Request einfügt. Anschließend auf Abschicken klicken, nochmal den Common Name gegenprüfen und nochmal Abschicken klicken.

Daraufhin zeigt die CAcert-Webseite das neue Zertifikat an. Das kopiert man und speichert es auf dem eisfair-Server in eine Datei mit der Endung .pem, beispielsweise www_example_dyndns_org.pem. Diese Datei kopiert man nun mit root-Rechten nach /var/certs/ssl/certs/. Anschließend ruft man ebenfalls mit root-Rechten einmal das Skript /usr/bin/ssl/c_rehash auf.

Mit einem aktuellen apache2 (probiert mit 1.3.4) wird man bei Aktivierung der Option APACHE2_SSL in der Konfiguration beim ersten Aktivieren einmal durch die komplette Zertifikat-Erstellungsprozedur geschickt, die genutzt wird, wenn der eisfair-Server selbst eigene Zertifikate ausstellt. Da wurstelt man sich einmal durch. Anschließend muss man dem Apache aber noch das CAcert-Zertifikat unterschieben. Wenn vHosts verwendet werden, gibt man den oben vergebenen Dateinamen einfach ohne Endung in der Variablen APACHE2_VHOST_?_SSL_CERT_NAME an. Verwendet man keine vHosts ist noch etwas Trickserei erforderlich. Der Apache erwartet das Zertifikat dann in /usr/local/ssl/certs/apache.pem bzw. (da /usr/local/ssl nur noch ein Symlink auf /var/certs/ssl ist) /var/certs/ssl/certs/apache.pem.

Jetzt gibt’s mehrere Möglichkeiten: apache.pem mit der neuen Datei überschreiben, einen symbolischen Link mit dem Namen apache.pem auf die neue Datei setzen oder den entsprechenden Teil aus der neuen Datei im Editor kopieren und in apache.pem ersetzen. Die zweite Variante (root-Rechte):

Anschließend den Webserver nochmal neu starten, fertig. Der Apache ist fortan über https://www.example.dyndns.org mit einem von CAcert signierten Zertifikat erreichbar.

Organisiertes Vertrauen

Eine Idee, die ich heute Nachmittag schon hatte, nachdem Keysigning, GeoCaching und verwandte Dinge gerade mehr oder weniger unsere Gesprächsthemen sind:

Es wäre doch nett, ein Portal zu haben, mit dessen Hilfe man Keysigning-Parties (KSPs) jeglicher Größenordnung organisieren könnte.

Ich stelle mir das so vor:

Man meldet sich dort an und bekommt dann die Möglichkeit, neben seinen aktuellen Schlüsseln auch seinen Aufenthaltsort anzugeben. Damit ist es schonmal leicht, herauszufinden, wer in der Umgebung noch einen PGP-Schlüssel besitzt.

Wer eine KSP organisieren möchte, legt ein entsprechendes Event mit Termin und Austragungsort an. Anschließend können andere Nutzer sich dafür anmelden, wobei sie gegebenenfalls sogar automatisch auf die KSP in ihrer Nähe hingewiesen wurden.

Eine dritte Funktion könnte eine Art Marktplatz sein, auf dem man sich zum Key-Signing verabreden könnte. Wer kein Problem damit hat, mal einen Schlüssel zu verifizieren, gibt das entsprechend bekannt (z.B. durch ein Häkchen im Profil und eine Angabe von Orten, an denen man ihn leicht treffen kann) und wenn man Leute sucht, die einen neuen Key verifizieren, kann man dort einfach auflisten lassen, wer denn in Frage kommt oder eine entsprechende Anfrage stellen und hoffen, dass sich jemand anbietet (auf diese Art lässt sich vermeiden, dass sinnlos Daten ausgespäht werden).

Nebenbei gibt es natürlich Informationen und Tools für KSPs, zum Beispiel eine Möglichkeit, sich ein nett designtes Formular mit allen Fingerprints der KSP-Teilnehmer herunterzuladen oder eine Liste mit Schlüsselschnipseln zum Ausschneiden und Weiterverteilen.

Wenn viel Serverlast ürbrig ist, kann man sogar Vertrauensnetzwerke berechnen und visualisieren. Der Kreativität sind da keine Grenzen gesetzt.

Falls es eine solche Plattform schon gibt oder jemand Lust hat, das umzusetzen: Lasst es mich wissen! Ich habe im Moment leider keine Zeit dazu.

Keys für Upgrade auf WordPress 2.6

Gestern kam mal wieder ein neues Update für WordPress. Wir setzen hier die DE-Edition ein und da gibt es auch eine detaillierte Anleitung zum Upgrade. Dort wird einem verraten, dass es für WordPress 2.6 neue Variablen in der Datei wp-config.php gibt. Der entsprechende Abschnitt in der wp-config-sample.php sieht so aus:

Jetzt ist da eine Seite angegeben, auf der man sich diese Keys erzeugen lassen kann. Das ist für den DAU ganz nett, aber schrieb nicht fefe gerade die Tage:

Man sollte denken, niemand könnte je so unglaublich dämlich sein, sich einen Krypto-Schlüssel von jemand anderem generieren zu lassen

Glücklicherweise gibt es ja noch mehr Möglichkeiten zufällige Zeichenketten zu erzeugen. Eine davon habe ich vor einigen Monaten im Beitrag Kleiner Passwortgenerator in Perl vorgestellt. Was der Beitrag verschweigt: Ich hatte wenige Tage später noch eine kleine Anpassung an dem Skript vorgenommen, die es erlaubt, beim Aufruf die Anzahl der zurückzugebenden Zeichen als Parameter zu übergeben. So war es ein leichtes die nötigen Keys für die Konfigurationsdatei von WordPress zu generieren:

perl genpasswd.pl 64

Das veränderte Skript ist jetzt übrigens auch über Penguineering Tools abrufbar.

Security by Obscurity

Im April hatte ich über die Sicherheitslücke in Chipkarten des Typs Mifare Classic geschrieben, die auch als Studentenausweis an der Uni Magdeburg dienen. Der Hersteller InterCard hatte Anfang April angekündigt sich zügig mit seinen Kunden in Verbindung zu setzen. Davon hat man hier an der Uni bisher nichts gemerkt.

Unabhängig davon ist heute bekannt geworden, dass NXP, der Hersteller der Chips, eine niederländische Universität verklagt hat, damit die keine Paper zu der Thematik veröffentlichen. Fefe schreibt dazu:

Das sagt mir persönlich ja immer alles, was ich über eine Firma wissen muß, wenn die ihre Sicherheitslücken nicht fixen und dazu stehen sondern den Boten unter Beschuß nehmen.

Ich frage mich, wie die sich das vorstellen. Die Niederländer sind ja lange nicht die einzigen, die Details zu der Sicherheitslücke veröffentlicht haben. Da gab’s einen Vortrag auf dem 24C3, die c’t hat lang und breit drüber berichtet und all diese Informationen sind seit über einem halben Jahr öffentlich, lange genug Zeit also für böse Buben sich da schlau zu machen und das Wissen zu speichern. Viel interessanter ist die Frage, wie sie die bestehenden Systeme absichern oder auf neue Systeme migrieren wollen. Wäre glatt mal interessant beim hiesigen Studentenwerk anzufragen, ob der Hersteller schon Kontakt aufgenommen hat und was da möglicherweise hinsichtlich neuer Karten o.ä. geplant ist.