Tag Archives: Sicherheit

Indirekter SPAM

HowTo: Standard-Dateiberechtigungen im Apache

Die Aufgabe: Dateien, die vom Apache HTTP-Server erzeugt werden, sollen bestimmte Zugriffsrechte erhalten.

Seit wir das Antiblau-Blog mit einem Cache versehen haben, bekomme ich regelmäßig E-Mails von dem Script, das sich normalerweise um die Korrektur der Berechtigungen in den WWW-Verzeichnissen kümmert (die Struktur lässt sich mit den Standardmechanismen der Unix-Dateiberechtigungen nicht mehr abbilden und ACLs habe ich nicht). Der Grund ist, dass die Cache-Dateien mit der Gruppe des Apache, statt mit der Gruppe des Webspaces, und mit den falschen Zugriffsrechten erzeugt wurden.

Die Gruppenberechtigung lässt sich leicht korrigieren, indem das Gruppen-Stickybit des übergeordneten Verzeichnisses gesetzt wird:

chmod g+s cache

Schwieriger ist die Anpassung der Zugriffsrechte von 640 auf 660. Hierfür muss der Apache so konfiguriert werden, dass auch Gruppen Schreibrechte erhalten. Das geschieht über die umask-Variable (umasks legen fest, welche Berechtigungen bei einem chmod wieder gelöscht werden), die in der envvars-Konfiguration angegeben werden.

Dazu habe ich in die Datei

/etc/apache2/envvars

den Eintrag

umask 002

eingefügt, den Apache neu gestartet und schon war das Problem behoben.

Sicherheitslücken beim Studentenausweis der OvGU

2 Replies

Die Studenten der Otto-von-Guericke-Universität Magdeburg bekommen einen Studentenausweis mit RFID-Chip. Das ist schon seit einigen Jahren so und eigentlich sehr praktisch. Ähnlich wie bei der Geldkarte kann man Geld auf die Karte laden. Damit kann man in der Mensa und den Cafeterien des Studentenwerks sein Essen bezahlen, in der Bibliothek kopieren und sich an speziellen Automaten zurückmelden. Die drucken dann auch das neue Gültigkeitsdatum auf die Karte, so dass man bei den Magdeburger Verkehrsbetrieben stets einen gültigen Fahrausweis hat. Zusätzlich ist noch ein Strichcode vorn drauf, damit dient der Studentenausweis auch als Nutzerausweis der Bibliothek. Das System kommt von der Firma Intercard.

Vor einigen Monaten fiel mir auf, dass im Foyer der Mensa zwei kleine Automaten aufgestellt wurden, die den aktuellen Ladebetrag der Karte anzeigen. Diese Automaten sind im Gegensatz zu den Lesegeräten an den Kassen der Mensa sozusagen autark, nur ein Stromkabel ist angeschlossen. Der logische Schluss: der Geldbetrag ist direkt auf der Karte gespeichert. Die naheliegende Vermutung: wenn es gelänge, den RFID-Chip entsprechend zu manipulieren, ließe sich Guthaben erschleichen. Da ich kein gewiefter Hacker bin, blieb es bei einer Nachfrage beim Studentenwerk, wo man mir einerseits bestätigte, dass der Betrag tatsächlich auf der Karte gespeichert ist und andererseits versicherte, dass das System sicher sei und ich mich bei weiteren Fragen an den Hersteller wenden solle – habe ich nicht gemacht. Das ganze passierte wie gesagt im letzten Jahr.

Vor einigen Wochen nun erschien in der c’t 8/08 ein Artikel mit dem Titel »Chiptease – Verschlüsselungssystem eines führenden Bezahlkartensystems geknackt«. Das ganze las sich zunächst wie der jährliche Aprilscherz der Redaktion. Doch weit gefehlt, der eigentliche Aprilscherz war richtig absurd und relativ leicht zu enttarnen, dies hier hatte Hand und Fuß. Die Autoren hatten den RFID-Chip freigelegt und dann Layer für Layer abgeschliffen und abfotografiert, um aus der Halbleiterstruktur auf die Funktionsweise und damit die verwendete Verschlüsselungstechnik schließen zu können.

Eine kurze Recherche ergab, dass der untersuchte und millionenfach verbreitete Chip vom Typ »Mifare Classic« auch von Intercard eingesetzt wird. Die c’t verweist in ihrem Artikel auf eine Untersuchung des niederländischen OV-Chipkaart-Systems. Die Stellungnahme, die Intercard am 7.4.2008 veröffentlicht hat, liest sich recht interessant:

Zur Verschlüsselung der Systemdaten und -informationen wird der geheim gehaltene sogenannte CRYPTO1 Chiffrieralgorithmus eingesetzt, welcher nur mit speziellen NXP Bausteinen umgesetzt und verarbeitet werden kann. Diese Bausteine sind auch in den Mifare Lesemodulen eingebaut. Die Schlüssellänge beträgt 48 Bit, daraus ergeben sich über 280 Billionen Kombinationsmöglichkeiten.

Punkt 1: Security by Obscurity. Die erfolgreiche Kryptoanalyse hat wieder einmal gezeigt, dass dieses Konzept auf äußerst wackeligen Füßen steht. Punkt 2: Schlüssellänge. Mag das Mitte der 90er noch Stand der Technik gewesen sein, in »Kleiner Passwortgenerator in Perl« haben wir letztens erst Schlüssellängen diskutiert und 48 bit sind heutzutage lächerlich wenig. Intercard schreibt völlig zurecht:

Fazit
Die einfache Struktur der aufgedeckten Rechenregel, voraussagbare Zufallszahlen sowie
Zusammenhänge zwischen Karten-ID und Schlüssel lassen einen erfolgreichen Angriff auf
die Karte gewissermaßen recht einfach erscheinen.
Die Aussage “Verschlüsselungsalgorithmus Mifare Classic nachvollzogen” muss also
im Grundsatz als korrekt bewertet werden !

Die möglichen Gefahren sind klar. Da aber die Karte an der Uni hier, soweit ich weiß, nicht als Zugangskarte sondern nur als elektronische Geldbörse dient, ist dieser Punkt für mich am interessantesten. Im Hintergrund des Bezahlsystems wird ein sogenanntes Clearingsystem benutzt. Das bedeutet, dass sämtliche Transaktionen an Aufladeautomaten und Kassen geloggt und ausgewertet werden. Bei Unstimmigkeiten, die bei manipulierten oder geklonten Karten logischerweise auftreten, können die entsprechenden Karten anhand ihrer Seriennummer gesperrt werden. Insofern mache ich mir um meine Karte erstmal keine großen Sorgen, würde aber dennoch empfehlen keine allzu großen Beträge aufzuladen.

Nach einer Bestätigung der Schwächen des Kartensystems vom 19.3.2008 schreibt heise letzte Woche übrigens in »Aus für RFID-System Mifare Classic?«, dass auch das Nachfolgesystem Mifare Plus anfällig ist. Mehr und ausführliche Information zum Thema sowie den Vortrag zum Thema auf dem 24C3 findet man auf der Homepage von Karsten Nohl.

Eins noch, Intercard hatte in dem oben verlinkten PDF noch folgendes angekündigt:

Weitere Vorgehensweise
InterCard wird für seine Kunden sehr zeitnah (ca. 4 – 6 Wochen) eine Migrationsstrategie auf
eine neue Kartentechnologie ausarbeiten und vorstellen.

Wer da nähere Informationen in Bezug auf die OvGU hat, kann die gern an mich weiterleiten.

Kleiner Passwortgenerator in Perl

12 Replies

Aus der Reihe »Schnelles Kamel-Gehacktes« heute der Beitrag, wie man quick’n’dirty einen Passwortgenerator in Perl schreibt. Anforderungen vorher: 8 Zeichen, weil viele Linuxe sowieso dahinter abhacken; nur Zeichen, die in den ersten 7 Bit der ASCII-Tabelle stehen und dann auch nur welche, die man direkt oder mit Umschalttaste (Shift) eingeben kann, nichts wozu man AltGr oder ähnliches bräuchte. Dazu braucht man eine ASCII-Tabelle und dann geht’s los:

#!/usr/bin/perl -w
# $Id: gen_passwd.pl 111 2008-02-06 13:45:24Z alex $
use strict;

my @allowed_chars;
# ASCII von 0x21 bis 0x3f
# das sind die meisten Sonderzeichen und die Ziffern
for (my $i=0x21; $i<=0x3f; $i++) {
	push @allowed_chars, chr($i);
}

# ASCII von A bis Z
for (my $i=0x41; $i<=0x5a; $i++) {
	push @allowed_chars, chr($i);
}

# ASCII von a bis z
for (my $i=0x61; $i<=0x7a; $i++) {
	push @allowed_chars, chr($i);
}

push @allowed_chars, chr(0x5f); # '_'

my $char_count = scalar @allowed_chars;

for (my $i=0; $i<8; $i++) {
	print $allowed_chars[int rand $char_count];
}

print "\n";

Diese Passwörter eignen sich gut als initiale Passwörter für neue Nutzer. Die Nutzer sollten sodann aufgefordert werden, sich mit passwd ein neues zu setzen. Da so ein zufälliges Passwort mit Zahlen und Sonderzeichen sehr schwer zu merken ist, werden sie dieser Aufforderung sicher nachkommen.

Nicht das gesamte System verschlüsseln

3 Replies

Nach etwas oberflächlicher Recherche bin ich der Meinung, das Internet quillt über von Anleitungen zur Verschlüsselung ganzer Partitionen, ja ganzer Rechner (bis auf den MBR), mit allen Auswüchsen, die man sich denken kann und auch noch Motivationen und Begründungen dazu. Verschlüsselung der root-Partition, LVM auf einem verschlüsselten physical volume, verschlüsselte logical volumes in ansonsten unverschlüsselten LVM Dingern, das ganze noch mit und ohne RAID oder mit /boot noch auf dem USB-Stick, wahlweise mit Keyfiles oder herkömmlichen Passwörtern usw. Die Ansätze zur Verschlüsselung sind ähnlich vielfältig: dm-crypt mit und ohne luks, das klassische loop-aes oder truecrypt, um nur einige zu nennen.

Ich will einfach nur unter Debian Lenny eine Datenpartition verschlüsseln, kein RAID, kein LVM, boot-, root- und swap-Partition dürfen auch unverschlüsselt bleiben und das ganze am besten ohne einen eigenen Kernel kompilieren zu müssen und ohne Installation mit Live-CD oder sonstigen Spielerchen.

Ich habe also HowTos, Tutorials und manpages gewälzt und die Wahl fiel auf dm-crypt mit luks. Das ist aktuell, es ist alles bei Debian schon dabei und der Kernel muss nich neu kompiliert werden. Kurz noch die Grundvorraussetzungen hier: /boot auf CF-Karte als hda1, root-Partition ist hdd1 und swap hdd2, die Daten sollen alle auf hdd3 landen. Die ganze Einrichtung spielt sich mit root-Rechten ab, da wir nicht bei Ubuntu sind, einfach als root einloggen dafür! Die ersten Schritte bestehen darin, die nötigen Kernel-Module zu laden und das Programm cryptsetup zu installieren:
modprobe aes modprobe dm-crypt modprobe dm-mod aptitude install cryptsetup

Die Partition, die verschlüsselt werden soll, darf nicht gemountet sein, ein Mountpoint sollte für später vorhanden sein, einfach das gewünschte Verzeichnis anlegen. Bei mir wird das /mnt/data sein. Als nächstes wird die Partition für die Verschlüsselung vorbereitet und geöffnet, quasi dem Device-Mapper bekannt gemacht. An diesem Punkt bitte darauf achten, dass alle Daten, die sich noch auf /dev/hdd3 befinden, danach unwiederbringlich verloren sind.
cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/hdd3 cryptsetup luksOpen /dev/hdd3 data

Beim ersten Aufruf wird nach einem Kennwort gefragt, das später als Schlüssel dient. Der zweite Aufruf öffnet sozusagen die verschlüsselte Partition, daher ist das Kennwort nochmal einzugeben. Jetzt kann man über /dev/mapper/data auf die verschlüsselte Partition zugreifen. Der erste Schritt: formatieren. Ich habe das ganze mit einer etwa 227 GB großen Partition und einem Pentium 133 getan. In der Zeit kann man ganz entspannt Kaffee kochen, trinken, die Kaffeemaschine sauber machen, Pizza backen, Pizza essen, den Ofen sauber machen…
mkfs.ext3 -v -L DATA /dev/mapper/data

Mounten klappt von Hand dann schonmal. Jetzt soll es noch so eingerichtet werden, dass die Partition auch beim Boot gemountet wird. Dazu werden die nötigen Kernelmodule, die vorhin von Hand geladen wurden in /etc/initramfs-tools/modules/ eintragen. Das sind
aes dm-crypt dm-mod sha256

Danach nochmal die initrd neu bauen lassen mit
update-initramfs -u -k all

Als nächstes wird die /etc/fstab angepasst. Dort einfach /dev/hdd3 durch /dev/mapper/data ersetzen oder die Zeile neu anlegen. Weiterhin ist es noch nötig, die Datei /etc/crypttab anzupassen:
data /dev/hdd3 none luks,retry=1,cipher=aes-cbc-essiv:sha256

Das war’s. Das ist alles, mehr ist nicht zu tun. Beim booten wird man nach dem Passwort gefragt, der Rest läuft wie gewohnt. Noch ein Wort zur Performance: da nur die Datenpartition verschlüsselt ist, machen sich natürlich nur Zugriffe darauf bemerkbar. Kopieren mit rsync+ssh lastet den Rechner voll aus, das war vorher auch schon so, da ssh hier den Prozessor bereits zu voller Auslastung treibt. Mit zusätzlicher Verschlüsselung der Datenpartition sieht das in top dann so aus, als würden ssh und kcryptd/0 zu ungefähr gleichen Teilen für die CPU-Last verantwortlich sein. Mehr Aussagen kann ich dann machen, wenn die Daten wieder zurückgeschrieben sind, morgen oder übermorgen…

antiblau blog

tech blog, another one …