My Universe Blog » Entries Tagged as security

Blog entwanzt

Posted by Jesco Freund at Nov. 16, 2008 11:02 p.m.

Was aus Bequemlichkeit meinerseits bisher nicht geschehen ist, habe ich heute mal in Angriff genommen. Aus dem Blog sind alle datenschutzfeindlichen Bestandteile rausgeflogen, also Google Analytics und die Adsense Werbung. Die Statistiken konnte ich mir hier mangels Flashplayer sowieso nicht anschauen, und die Werbeeinnahmen waren weniger als lächerlich ($7,58 für knapp 12.000 Impressions und 22 Klicks – so wenig, dass sie sogar unter der Auszahlungsgrenze von $10 lagen). Auch das Technorati-Geraffel hab ich mal rausgeworfen, auch wenn das glaube ich nicht von selbst an deren Server zurückgestreut hat…

No comments | Defined tags for this entry: blog, freedom, privacy, security, advertising

FreeBSD Audit – Big Brother is Watching You!

Posted by Jesco Freund at Nov. 15, 2008 8:01 p.m.

Wer sicherheitskritische Systeme betreibt, weiß gerne, was sich auf diesen alles abspielt. Dadurch lassen sich versuchte Einbrüche frühzeitig erkennen und unterbinden, Amok laufende Prozesse rechtzeitig in ihre Schranken weisen – und falls alles bereits zu spät ist, helfen detaillierte Aufzeichnungen immerhin noch bei der forensischen Analyse. Für eine feingranulare Überwachung aller Systeminteraktionen (Login, Logout, Zugriff auf Dateien, Start/Stop von Prozessen, Systemaufrufe etc.) bietet FreeBSD seit Version 6.2 das Security Event Auditing Subsystem, eine zu Solaris und Mac OS X kompatible Implementierung von Suns BSM. Seit FreeBSD 7 ist Auditing bereits im GENERIC-Kernel aktiviert und das einrichten und aktivieren der Event-Überwachung damit nicht mehr sonderlich kompliziert. Es gilt lediglich, ein kuscheliges Plätzchen für die Logs zu schaffen, die Konfiguration ein wenig anzupassen und den Audit-Dienst zu starten.

continue reading FreeBSD Audit – Big Brother is Watching You!

No comments | Defined tags for this entry: FreeBSD, security

Verschlüsseltes Image mit aespipe

Posted by Jesco Freund at Nov. 15, 2008 11:07 a.m.

Von meinem frisch aufgesetzten Server benötigte ich ein Wiederherstellungs-Image, damit ich im Falle eines Falles nicht erst den Support des Anbieters bemühen muss, um mir für die Installation von FreeBSD ein CD-Laufwerk anzuschließen. Klar, kein Problem, lässt sich aus dem Rettungssystem heraus mit dd ganz einfach erzeugen. Die Sache hat allerdings zwei Haken: Zum einen befinden sich auf der Platte mittlerweile Daten, die nicht unbedingt in die falschen Hände geraten sollten (wie z. B. die Passwort-Datenbank), zum anderen erzeugt dd ein Raw Image und liest dabei stur alles von der Platte ein, auch aus Bereichen, die keine Daten enthalten (sollten).

Wurde die Platte vor der Installation „genullt“, dürften die nicht genutzten Bereiche aus großen zusammenhängenden Blöcken von Nullen bestehen und sich damit leicht komprimieren lassen. Hat man das (wie ich) versäumt, würde man mit dd auch den ganzen verstrahlten Bitmüll mitsichern, den der Vormieter eventuell auf den Platten hinterlassen hat. Das lässt sich aber auch nachträglich relativ leicht korrigieren, indem man einfach auf jeder Partition eine große Datei anlegt, die nichts als Nullen enthält:

dd if=/dev/zero of=null.img bs=64k
rm null.img

dd schreibt automatisch so lange Nullen in die Datei, bis der Datenträger voll ist. Beim Löschen wird nur der Verweis auf die Datei entfernt, so dass jetzt der leere Platz in der betreffenden Partition binär genullt ist.

Nun zum Problem der Datensicherheit: hier schafft das kleine Tool aespipe Abhilfe. Gerade beim erstellen von Images ist es äußerst praktisch, da es sich – wie der Name schon vermuten lässt – einfach per Pipe mit in den Erstellungsprozess einbinden lässt. So etwa erstelle ich ein verschlüsseltes Image und lade es gleich auf den Backup-Server:

dd if=/dev/sda bs=64k | bzip2 -c - | aespipe -e AES256 -T | ncftpput -c -V -u <user> -p <password> <backup-server> sda-<datum>.img.bz2.aes

Ein Restore würde nun genau andersherum erfolgen (vorausgesetzt, man hat die von aespipe geforderte 20-stellige Passphrase nicht vergessen ):

ncftpget -c -V -u <user> -p <password> <backup-server> sda-<datum>.img.bz2.aes | aespipe -d AES256 | bunzip2 -c - | dd of=/dev/sda bs=64k

2 comments | Defined tags for this entry: backup, privacy, security, server

Spielverderber

Posted by Jesco Freund at Oct. 5, 2008 7:46 p.m.

Auf zwei Neuerscheinungen für diesen Herbst habe ich mich richtig gefreut: Sacred 2 „Fallen Angel“ und Command & Conquer Red Alert 3. Zu meinem Entsetzen musste ich jetzt allerdings feststellen, dass beide Spiele mit dem berüchtigten Kopierschutz [1] SecuROM von Sony ausgeliefert werden bzw. werden sollen (RA 3 ist ja noch nicht im Handel). Um zu verstehen, warum ich so wenig begeistert von SecuROM bin, muss man sich kurz die Funktionsweise vor Augen führen:

SecuROM veranlasst während der Installation eine Online-Aktivierung beim Hersteller des Spiels. Dabei wird auch überprüft, wie häufig bzw. auf wie vielen verschiedenen Rechnern das Spiel bereits installiert wurde. Soweit ist das nichts neues, Microsoft geht ähnlich vor. C&C RA3 soll auf 5 Installationen begrenzt sein, Ascaron verzichtet auf diese Limitierung. Zusätzlich wird allerdings ein neuer Windows-Systemdienst installiert („SecuROM User Access Service (V7)“ – im Taskmanager als „UAService7.exe“ zu bewundern), der mit Administrator-Rechten (Ring 3) ausgeführt wird. Dieser Dienst wird permanent ausgeführt (auch wenn das Spiel gerade nicht verwendet wird) und wird auch bei der Deinstallation des Spiels nicht wieder vom Rechner entfernt. Einige Malware-Scanner bewerten den Dienst darüber hinaus als Rootkit, was aber angesichts der funktionalitätsbedingt (Stichwort: SCSI-Blacklisting) notwendigen interaktiven Eingriffe in Systemaufrufe nicht weiter verwunderlich sein dürfte.

Durch den Dienst in Verbindung mit der Aktivierung ist es möglich, das Spiel auch ohne Original-DVD im Laufwerk zu spielen. Damit ist der Umgang mit SecuROM-geschützter Software vordergründig etwas entspannter als bei klassischen datenträgergestützten Schutzverfahren. Warum also die Kritik? Zum einen gilt für den Aktivierungsmechanismus dasselbe wie bei Windows seit XP: nach einer gewissen Anzahl Aktivierungen muss man mit dem Hersteller in Kontakt treten, der dann darüber entscheidet, ob die Software weiter genutzt werden kann oder nicht. Somit erwirbt man beim Kauf des Spiels gar kein unbefristetes Nutzungsrecht, wie man es eigentlich von kommerzieller Software bisher gewohnt war.

Ein weiterer Nebeneffekt ergibt sich aus dem sog. „SCSI-Blacklisting“: Um die Verwendung von DVD- oder CD-Images in Verbindung mit Laufwerksemulatoren zu unterbinden, blockiert SecuROM den Zugriff auf emulierte SCSI-Geräte. Unangenehmer Weise wirkt sich dies auch auf Programme aus, die emulierte SCSI-Geräte zu legitimen Zwecken nutzen. Über Probleme wurde bereits bei der Verwendung der Brennsoftware Nero Burning ROM (bzw. deren Backup-Komponente) und in Einzelfällen auch mit SCSI-emulierenden USB-Geräten (Kartenleser u. ä.) berichtet.

Viel kritischer ist aber die Tatsache, dass der genannte Systemdienst regelmäßig den Hersteller über Internet kontaktiert. Welche Daten genau ausgetauscht werden, ist nicht bekannt, da die Kommunikation verschlüsselt erfolgt. Da durch die Aktivierung aber eine eindeutige Zuordnung zu einer Person gegeben ist, muss aus Datenschutzsicht das schlimmste befürchtet werden: Profiling. Da der SUAS permanent im Hintergrund läuft und über Administrator-Rechte verfügt, könnte er nicht nur verfolgen, mit welchen Programmen (und Spielen der Konkurrenz) der Anwender hantiert, sondern theoretisch auch beliebige Daten auf der Festplatte auslesen, Mails beim Schreiben oder Lesen mitschneiden und Passwörter ausspionieren. Kurz gesagt, im Zweifel könnte SecuROM all das, wovon BKA, BND und Verfassungsschutz zur Zeit träumen (Stichwort: Bundestrojaner). Und das beste daran: wir installieren uns den Mist sogar freiwillig…

Ich werde es mir jedenfalls sehr gut überlegen, ob die beiden Spiele noch einen weiteren Blick wert sind. Dass Sacred 2 mit einer entschäften Version (keine Limitierung der Anzahl an Aktivierungen) daher kommt, sollte nicht darüber hinwegtäuschen, dass damit noch lange nicht gesagt ist, dass keine Daten über das Nutzerverhalten gesammelt werden. Wenn ich die Rezensionen bei Amazon richtig deute, sehen dass viele andere Verbraucher ebenso. Hoffentlich reagieren die Hersteller – sonst könnten beide Spiele gewaltig floppen.

2 comments | Defined tags for this entry: freedom, computer games, privacy, security, software

CCC-Bericht attestiert Unzulänglichkeit des Hackerparagraphen

Posted by Jesco Freund at July 26, 2008 1:09 p.m.

Der Chaos Computer Club hat in seiner kürzlich veröffentlichten Stellungnahme zu §202c StGB („Hackerparagraph“) an das Bundesverfassungsgericht die Anwendbarkeit des Gesetzes sowie seine Auswirkungen untersucht. Das wenig überraschende Ergebnis: Der Paragraph ist ungeeignet, das eigentliche Ziel (Unterbindung von Cyberkriminalität) wirksam zu unterstützen. Darüber hinaus stellt er eine Behinderung deutscher Unternehmer und Forscher im internationalen Wettbewerb dar, was nicht nur wirtschaftlich inakzeptabel ist, sondern auch Deutschland mittelfristig von Entwicklungen im IT Security Sektor abkoppelt. Den gesamten Bericht als PDF gibt es hier.

No comments | Defined tags for this entry: politics, privacy, security

OpenSSH 5.0 released

Posted by Jesco Freund at April 3, 2008 11:36 p.m.

Kurz nach der Veröffentlichung von Version 4.9 steht seit heute Version 5.0 zum Download bereit (siehe Ankündigung auf undeadly.org). Die neue Version behebt ein Sicherheitsproblem, das im Zusammenhang mit Forwarding von X11-Verbindungen besteht (siehe entsprechende OpenBSD errata).

No comments | Defined tags for this entry: security

Virtuelle Brunnenvergifter

Posted by Jesco Freund at March 3, 2008 5:05 p.m.

FreeBSD hat ihn, Open- und NetBSD auch. Gentoo hat noch ein bisschen „age“ draufgepackt und gleich das Basissystem plus Kernel mit hineingepackt. Die Rede ist vom Ports- oder Portage-Tree, einem Verzeichnisbaum voller Bauanleitungen und Patches, der bei den genannten Betriebssystemen das herkömmliche Paketverwaltungssystem à la RPM, PKG, DEB etc. ersetzt oder ergänzt. Soweit nichts ungewöhnliches, doch unter bestimmten Umständen kann ein solcher Source Tree zum Angriffsvektor werden.

Kombiniert man eines der genannten Systeme mit einer nahezu beliebigen Virtualisierungstechnik (egal ob Xen, OpenVZ, Jails oder einfach nur gehärtete Chroot-Umgebungen), erscheint es schon bei einigen wenigen Instanzen interessant, den Quellenbaum nur einmal zentral für alle Instanzen vorzuhalten – das spart nicht nur Speicherplatz, sondern auch Bandbreite, und zwar in erheblichem Maße. Allerdings ist der gemeinsame Source Tree, egal ob über NFS oder mount-bindings bereitgestellt, nun auch von jeder virtuellen Instanz aus zugänglich. Die Kompromittierung eines virtuellen Subsystems könnte also auch die Kompromittierung des Ports- oder Portage Trees nach sich ziehen und einer Angriffsform Tür und Tor öffnen, die man als Ports Tree Poisoning bezeichnen kann. Hierbei wird gezielt ein Metapaket manipuliert (z. B. ein zusätzlicher Patch mit untergeschoben), wobei auch Digest-Files und das ggf. vorhandene Changelog mit angepasst werden, um die Paketverwaltungswerkzeuge zu überlisten. Gelingt dies einem Angreifer bei einem Port oder ebuild, der in wahrscheinlich allen virtuellen Instanzen installiert ist (ein gutes Ziel wäre eines der Paketmanagement-Tools selbst, OpenSSH o. ä.), bestehen große Chancen, dass der Admin des Systems mit dem nächsten Update aus der vergifteten Quelle schöpft und damit dem Angreifer sprichwörtlich die Schlüssel zum System überreicht.

Die Gefahr für ein solches Horrorszenario stellt sich je nach System allerdings ein wenig unterschiedlich dar. Bei Gentoo Linux etwa könnte der Portage-Tree den virtuellen Instanzen read-only zur Verfügung gestellt werden – kein Problem, da emerge die Kompilier-Arbeit in /var/tmp erledigt und nicht in einem Unterverzeichnis des ebuilds. Außerdem erfolgt die Synchronisierung des Portage-Trees mittels rsync; dabei wird der gesamte Tree überprüft und Fremdkörper zuverlässig entfernt. Entsprechende Sorgfalt vorausgesetzt, spricht hier also wenig gegen Source Tree Sharing – ein (minimales) Restrisiko besteht dennoch.

Deutlich risikoreicher nimmt sich die Lage bei FreeBSD aus: Der Ports-Tree darf nicht read-only sein, da das kompilieren der Pakete in einem Unterverzeichnis (./work) des jeweiligen Ports erfolgt. Updates des Ports-Trees erfolgen entweder direkt per CVS (csup bzw. cvsup) oder über Patches (portsnap). Dabei werden aber nur Änderungen übermittelt, die am zentralen Ports-Tree vorgenommen wurden. Manipulationen an nicht von Updates betroffenen Ports fallen hingegen nicht auf und werden auch nicht überschrieben. Ports Tree Sharing für FreeBSD Jails ist also indiskutabel, wenn das betreffende System zumindest minimalen Sicherheitsanforderungen genügen soll.

Fazit: Wird eine OS-Level-Virtualisierung à la Jails eingesetzt, um die Gesamtsicherheit eines Systems zu erhöhen, sollte man sich diesen Sicherheitsgewinn nicht durch unbedachte „Tunnel“ zunichte machen. Auch wenn Ports- und Portage-Tree sich auf den ersten Blick stark ähneln – es sind die Details in der Implementierung, die hier über sicher oder nicht sicher entscheiden.

2 comments | Defined tags for this entry: FreeBSD, Gentoo, security, hardware virtualization

Automatische Update-Benachrichtigungen

Posted by Jesco Freund at March 2, 2008 2:21 p.m.

Wer viele Server administriert, die auch noch mit verschiedener Software bestückt laufen, wird den Komfort zu schätzen wissen, täglich per E-Mail über verfügbare Updates auf dem laufenden gehalten zu werden. Auf Linux-Systemen, die mit Debian's Paketmanager aptitude ausgestattet sind, lässt sich dazu das folgende kleine Skript verwenden:

#!/bin/bash

/usr/bin/aptitude update > /dev/null 2>&1

lfile=$(/bin/mktemp /tmp/uck.XXXXXXXXXX)
/usr/bin/aptitude -s --purge-unused -q -y -Z safe-upgrade > $lfile 2>&1
/bin/cat $lfile | /usr/bin/mail -s "Update check report for `/bin/hostname -s`" your.name@your-domain.tld
rm $lfile

Wichtig: Auf jeden Fall den Schalter -s verwenden – zu entscheiden, welche Veränderungen tatsächlich am System vorgenommen werden sollen, ist immer noch Aufgabe des Admins.

2 comments | Defined tags for this entry: Debian, security, Ubuntu

Google – ein schlechter Verlierer?

Posted by Jesco Freund at Dec. 2, 2007 12:20 p.m.

Es tut uns Leid,

…aber Ihre Abfrage kann momentan nicht verarbeitet werden. Ein Computervirus oder eine Spyware-Anwendung sendet uns automatische Abfragen zu und es scheint, dass Ihr Computer bzw. Ihr Netzwerk infiziert wurde.

Wir werden Ihren Zugriff schnellstmöglich wiederherstellen, also probieren Sie es bald noch einmal. In der Zwischenzeit empfehlen wir Ihnen, anhand eines Virenscanners oder Spyware-Entferners zu überprüfen, dass auf Ihrem Computer kein Virus oder andere Störsoftware vorhanden ist.

Wir entschuldigen uns für eventuell entstandene Unannehmlichkeiten und hoffen, dass Sie bald wieder bei Google vorbeischauen.

Mit diesem Text und HTTP-Status 403 quittiert Google den Versuch, über Tor/Privoxy eine Suchanfrage zu stellen. Eine Erklärung wäre, dass über die Tor-Proxies naturgemäß viele Anfragen bei Google landen und deren Server das dann als Hammering interpretieren. Beim Surfen über andere Proxies habe ich dergleichen aber noch nie erlebt – möge sich jeder selbst seinen Reim drauf machen.

No comments | Defined tags for this entry: google, privacy, security

Unklare Rechtslage

Posted by Jesco Freund at Oct. 27, 2007 4:37 p.m.

(1) Wer eine Straftat nach § 202a oder § 202b vorbereitet, indem er

1. Passwörter oder sonstige Sicherungscodes, die den Zugang zu Daten (§ 202a Abs. 2) ermöglichen, oder

2. Computerprogramme, deren Zweck die Begehung einer solchen Tat ist,

herstellt, sich oder einem anderen verschafft, verkauft, einem anderen überlässt, verbreitet oder sonst zugänglich macht, wird mit Freiheitsstrafe bis zu einem Jahr oder mit Geldstrafe bestraft.

(2) § 149 Abs. 2 und 3 gilt entsprechend.

Quelle: § 202c StGB

Seit August dieses Jahres gilt besagter Gesetzestext, besser bekannt als „Hackerparagraph“. Dank der (bewußt?) weitgefassten und schwammigen Formulierung und mangels verfügbarer Urteile eines Bundesgerichts ist bis heute die Rechtslage für Betreiber von Spiegelservern ungeklärt. Je nach Auslegung könnte die Bereitstellung der Quelltexte von Programmen wie Nmap oder Wireshark als Überlassung von Computerprogrammen gewertet werden, die (potenziell) zur Begehung einer Straftat nach § 202a oder § 202b genutzt werden können. Damit wäre implizit der Tatbestand der Vorbereitung einer solchen Straftat gegeben, die nach dem oben zitierten Paragraphen mittlerweile ebenfalls strafbar wäre.

Die Hoffnung auf Nachbesserung seitens des Gesetzgebers habe ich mittlerweile aufgegeben, bleibt also nur noch die Klärung durch ein Gericht. Dem Risiko einer strafrechtlichen Verurteilung kann und will ich mich nicht aussetzen; aus diesem Grund habe ich heute den Inhalt des distfiles-Verzeichnisses von meinem inoffiziellen Gentoo-Spiegel entfernt, da dieses unter anderem auch Quelltexte der beiden genannten Tools enthält.

Persönliche Anmerkung meinerseits: Wehe, ich höre noch mal einen Politiker der beiden Großkoalitionäre darüber jammern, dass qualifizierte Fachkräfte ins Ausland abwandern, solange dieses Damokles-Schwert über den Köpfen der IT-Spezialisten und Sicherheitsexperten dieser Republik schwebt.

1 comment | Defined tags for this entry: civil rights, freedom, security, software