2010-08-18 // Full disk encryption with Ubuntu (9.04 Jaunty or newer), LVM and LUKS

I wrote a detailed guide on how to install an encrypted Ubuntu Linux:

The setup is using LUKS and Logical Volume Manager (LVM) to get a secure and flexible system. And to make nearly everybody succeed, there is even a crypt-setup bash script, making the installation faster and easier.

Have fun. :-)

0 Comments | 2010-08-18 written by Andreas Haerter | Permanentlink
Tags:

2010-08-18 // Ebfe's Anti-B00TKIT Project

The ”Ebfe's Anti-B00TKIT Project” is a simple but effective protection against Bootkits, suitable for daily usage. It makes it possible to know if your bootloader was manipulated before booting from disk. A really interesting tool for high-security environments and paranoid persons. :-P

Bootkits like the Stoned Bootkit are used to attack a full disk encryption1) (amongst other things). All “common” data is encrypted on such systems except a small, “special” part: the bootloader. Expressed in simplified terms, the bootloader is needed to store a program which prompts the user for the password to decipher the data and start the encrypted operating system. Bootkits are trying to manipulate the bootloader, making it possible to log the password the user enters and store it within the unencrypted part of the disk afterwards. The user does not see this, he simply gets the normal encryption password promt to start the system. This enables the attacker to come back later to read out the plain, unencrypted password the bootkit stored for him.

Ebfe's Anti-B00TKIT provides a CD to boot from before booting from disk. The program on CD reads out the Master Boot Record entries and displays their checksums (this does only need a few seconds). If all checksums are OK, you can going on to boot from disk by pressing a key. If the checksums are not the same as every day, your harddisk's bootloader was manipulated. To make this check more comfortable, you can create a custom CD containing your original MBR checksums. The CD is able to highlight non-matching checksums automatically then.

Visit the project website for screenshots, how-to and download.

1) e.g. LUKS on Ubuntu or TrueCrypt on Windows
1 Comment | 2010-08-18 written by Andreas Haerter | Permanentlink
Tags:

2010-05-19 // Links: IT security and privacy

0 Comments | 2010-05-19 written by Andreas Haerter | Permanentlink
Tags:

2010-04-19 // HTTP digest authentication with PHP (safe mode enabled)

Doing HTTP digest authentication with PHP is an easy task. The manual entry is providing all needed information as long as you do not skip the last note on the page:

Note: If safe mode is enabled, the uid of the script is added to the realm part of the WWW-Authenticate header.

I just talked to one of my friends who did not notice the safe mode behavior, he had problems because HTTP digest authentication simply did not work on his server where safe mode is active. Unfortunately, the manual is not providing an example working with both active and inactive safe mode, therefore I am releasing one here. You may use the function directly… or better build a nice auth-class for doing the job. However, I think the example should help in both cases providing all needed information for creating your own HTTP digest authentication. Have fun. :-)

http-auth.php
<?php
/**
 * HTTP digest authentication
 *
 * @return true TRUE if everything worked/auth was successful.
 *         In case of errors and/or wrong credentials, the script will be killed
 *         (providing a message to the current client).
 * @author Andreas Haerter
 * @link http://en.wikipedia.org/wiki/Digest_access_authentication
 * @link http://de.wikipedia.org/wiki/HTTP-Authentifizierung
 * @link http://www.php.net/manual/features.http-auth.php
 * @link http://blog.andreas-haerter.com/2010/04/19/http-digest-authentication-with-php-safe-mode-enabled
 * @link http://www.php.net/manual/features.http-auth.php#93427
 */
function http_digest_authentication()
{
	//existing users/credentials
	$users = array("username1" => "password1",
	               "username2" => "password2");
 
	//message to show
	$realm = "Please enter your credentials";
 
	//send needed digest auth headers
	if (empty($_SERVER["PHP_AUTH_DIGEST"])) {
		header("HTTP/1.1 401 Unauthorized");
		header("WWW-Authenticate: Digest realm=\"".$realm."\",qop=\"auth\",nonce=\"".uniqid(mt_rand(), true)."\",opaque=\"".md5($realm."salt-for-opaque")."\"");
		die("unauthorized access");
	}
 
	//parse http digest (inspired through http://www.php.net/manual/features.http-auth.php#93427)
	$mandatory = array("nonce"    => true,
	                   "nc"       => true,
	                   "cnonce"   => true,
	                   "qop"      => true,
	                   "username" => true,
	                   "uri"      => true,
	                   "response" => true);
	$data = array();
	preg_match_all('@(\w+)=(?:(?:\'([^\']+)\'|"([^"]+)")|([^\s,]+))@', $_SERVER["PHP_AUTH_DIGEST"], $matches, PREG_SET_ORDER);
	foreach ($matches as $m) {
		$data[$m[1]] = $m[2] ? $m[2] : ($m[3] ? $m[3] : $m[4]);
		unset($mandatory[$m[1]]); //mandatory part was found, kick it out of the "to do" list (=$mandatory array)
	}
 
	//create valid digest to validate the credentials
	$digest = "";
	if (isset($users[$data["username"]])) {
		$realm_digest = $realm;
		//As mentioned at <http://www.php.net/manual/en/features.http-auth.php>:
		//If safe mode is enabled, the uid of the script is added to the realm part of
		//the WWW-Authenticate header (you cannot supress this!). Therefore we have to
		//do this here, too.
		if (6 > (int)PHP_VERSION //safe_mode will be removed in PHP 6.0
		    && (int)ini_get("safe_mode") !== 0) {
			$realm_digest .= "-".getmyuid();
		}
		$digest = md5(md5($data["username"].":".$realm_digest.":".$users[$data["username"]]) //A1
		              .":".$data["nonce"].":".$data["nc"].":".$data["cnonce"].":".$data["qop"].":"
		              .md5($_SERVER["REQUEST_METHOD"].":".$data["uri"]));                    //A2
	}
	if (empty($digest)
	    || $data["response"] !== $digest) {
		header("HTTP/1.1 401 Unauthorized");
		header("WWW-Authenticate: Digest realm=\"".$realm."\",qop=\"auth\",nonce=\"".uniqid(mt_rand(), true)."\",opaque=\"".md5($realm."salt-for-opaque")."\"");
		die("wrong credentials");
	}
	//if we are here, auth was successful
	return true;
}
?>
0 Comments | 2010-04-19 written by Andreas Haerter | Permanentlink
Tags:

2010-04-13 // GnuPG-Schlüsselhierarchie: passender Algorithmus für jede Aufgabe, Schlüsselaustausch ohne Verlust des Web of Trust

Vor ein paar Wochen habe ich mir einen neuen Key für GnuPG/PGP (im Folgenden einfach “GPG” genannt) zugelegt, weil mein bisheriger abgelaufen ist. Das habe ich zum Anlass genommen mal meine Vorgehensweise zu überarbeiten. Die Erkenntnisse will ich hier festhalten, vielleicht bringt es ja jemandem etwas ;-). Ziel war:

  • Fein granulare Schlüsselhierarchie: Eine GPG-Aufgabe → Ein Schlüssel.
  • Die verschiedenen Schlüssel sollen den jeweils passendsten Algorithmus für die Aufgabe verwenden und bei Bedarf nach relativ kurzer Zeitspanne verfallen dürfen.
  • :!: Der Austausch eines Schlüssels soll NICHT zur Folge haben, dass das eigene Web-of-Trust zerhauen wird.

Dabei ist der letzte Punkt IMHO der Wichtigste. Das erspart einem, dass man wieder mühsam Signaturen für die neue Schlüssel einsammeln muss (den neuen Key vor Ablauf des alten Key mit selbigen zu signieren ist IMHO nur eine Notlösung, aber besser als nix). Die Vorteile liegen auf der Hand:

  • Geeignetere Algorithmen und Schlüsselstärken für die jeweilige Aufgabe
    Beispiel: RSA erzeugt irrsinnig lange Signaturen, ist aber gut für Verschlüsselung geeignet. Wenn man dennoch zur Verschlüsselung auf RSA setzen will, kann man seinen Signierschlüssel über DSA realisieren. Zudem kann man die nötige Schlüssellänge (Bit) besser zwischen Aufgabe und Performance abwägen.
  • Mehr Sicherheit
    Selbst wenn mal ein Schlüssel mit brachialer Großrechnerpower über Jahre geknackt werden könnte, so hat der Angreifer bei regelmäßig wechselnden Schlüsseln dann immer nur einen Teil der Daten und muss für weiteren Zugang zu älteren/neueren Daten erneut genausoviel Aufwand in Kauf nehmen. Dies gilt natürlich auch, wenn ein Schlüssel anderweitig kompromittiert wird (was wahrscheinlicher ist als Brute-Force). Es ist ein deutlicher Unterschied, ob jemand ein einziges Jahr oder z.B. fünfzehn Jahre Kommunikation nachvollziehen kann ;-). Oder ob nur ein Webserver-Login ermöglicht wird oder gleich alle jemals verschickten Daten entschlüsselt werden können.

Read more…

0 Comments | 2010-04-13 written by Andreas Haerter | Permanentlink
Tags:

2007-12-21 // Microsoft und gar nicht so zufällige Zahlen

Bruce Schneier [sic!] hat einen neuen US-Standard zur Erzeugung von Zufallszahlen und den darin enthaltenen Generator Dual_EC_DRBG schon etwas länger im Visier, da er darin eine Backdoor für die NSA vermutet, die über die ggf. gar nicht so zufälligen Zahlen kryptographische Schlüssel angreifen könnte.

Nun ist Bruce Schneier ein bedeutender Krypto-Experte – um so unverständlicher (außer es ist etwas dran, an Schneiers Vermutung ;-)) ist es, dass Microsoft Dual_EC_DRBG ohne Veränderung im SP1 für Vista eingebaut hat und damit bald an seine Kunden ausliefert. Schneier rät daher allen Programmieren einschlägiger Software ab, Dual_EC_DRBG in den eigenen Programmen zu nutzen. Ein Rat, den man befolgen sollte.

0 Comments | 2007-12-21 written by Andreas Haerter | Permanentlink
Tags:

2007-10-04 // Adobe spart wohl am falschen Ende...

Irgendwie ging das an mir vorbei, was da Adobe vor rund einer Woche passiert ist: heise.de: Adobes Webserver sperrangelweit offen. Das CGI-Skript zum Download von Dateien hat einfach mal alles ausgeliefert, was man ihm über einen Parameter übergeben hat, z. B.:

  • http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version= ../../../../../../../../../etc/passwd%00
  • http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=../../../../../../../../../usr/local/apache/conf/ssl.key/www.adobe.com.key%00
  • http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version= ../../../../../../../../../usr/local/apache/conf/ssl.crt/www.adobe.com.crt%00

:-O :-O

Ich bin immer wieder erstaunt darüber, wie oft auch bei professionellen Anwendern über trivialste Fallstricke wie ”../” gestolpert wird. Klar, Fehler können passieren. Ich meine aber, Adobe hat sicherlich genug Kleingeld um Leute zu engagieren, denen Fehler dieser Kategorie eigentlich nicht passieren sollten. Das Ganze hat IMHO neben der allgemeinen Belustigung aber noch etwas wirklich Positives: es ist ein gutes Beispiel, dass nicht immer PHP schuld ist, wenn Anfänger solche Fehler in Serie produzieren. Man schafft dies in jeder Sprache. Das Problem sitzt eindeutig vor dem Bildschirm.

0 Comments | 2007-10-04 written by Andreas Haerter | Permanentlink
Tags:

2007-08-06 // Skype, die Vertrauenswürdigkeit und die Alternativen

Keine Frage – Skype hat Erfolg, erfüllt auf zahlreichen Rechnern brav seinen Dienst und ermöglicht vielen Menschen auf dieser Welt komfortabel und kostengünstig zu kommunizieren. Zudem ist es einfach zu bedienen, daher will ich dem Programm sicher nicht seine Daseins-Berechtigung absprechen. Aber Skype hat auch ein paar unschöne Seiten, die dem normalen Nutzer wohl nicht direkt auffallen. Diese sind zum Teil offensichtlich, anderes kann man ob sehr umfangreicher Verschleierungstaktiken nur erahnen. In jedem Falle sollte man sich darüber informieren und dann abwägen, ob der Komfort von Skype die Nachteile aufwiegt.

Kommmen wir zunächst zu den offensichtlichen Dingen:

  • Skype ist sowohl bei der Signalisierung als auch bei der Übertragung proprietär und redet prinzipiell nur mit Produkten des Herstellers. Setzt man einmal auf Skype, bleibt man also zwangsweise auch dabei, sofern man nicht alle seine Kontakte verlieren will. Andere Lösungen setzen auf Standards und können so auch untereinander und Hersteller-übergreifend kommunizieren.
  • Die Firma hinter Skype ist den Kinderschuhen entwachsen, gehört mittlerweile zu eBay und spielt daher in der Liga “der Großen”. Dort gelten andere Regeln. In Zeiten von Vorratsdatenspeicherung & Co. macht dies nicht gerade Hoffnung, dass der Konzern nicht einfach nur in eigenem Interesse handelt statt sich für seine Nutzer einzusetzen. Das die Signalisierung dazu noch über zentrale Server von Skype im Ausland (wo Datenschutzgesetze fehlen) abgewickelt wird, macht das ganze noch schlimmer.

Kommen wir zu den weniger offensichtlichen Dingen:

Kommen wir zu den Problemen mit der Sicherheit:

  • Skype wird in Netzwerken zu einem Problem. So werden z.B. Firewalls von der Software durchlöchert. Das führt u. a. zu Traffic, der als Administrator nur schwer in den Griff zu bekommen ist.
  • Skype vertraut jedem, der Skype spricht. Soll heißen: Wenn die Software denkt, auf der anderen Seite der Leitung ist ebenfalls ein Skype-Client, entfallen zahlreiche Checks. In Verbindung zu der gut verschleierten und verschlüsselten Datenübertragung sowie dem oben genannten “Lochtrick” bezüglich Firewalls, könnte sich eine Lücke in der Software als ein ultimativer Sicherheits-GAU herausstellen – würden doch Angriffe auch noch wunderbar vor der Entdeckung geschützt. Folie 96 ff. des genannten Vortrags ist diesbezüglich auch ganz interessant.

Genug zu den Nachteilen von Skype für heute. Die Listen würden sich bestimmt noch erweitern lassen, doch widmen wir uns lieber möglichen Alternativen. Für ausführliche Reviews fehlt mir gerade ein wenig die Zeit, Sie folgen ggf. noch. Ich will jetzt aber jemanden, der sich bis hier hin im Text durchgekämpft hat nicht so einfach hängen lassen, und wenigstens ein paar Links zum Einstieg liefern:

Über Erfahrungsberichte zu den genannten Alternativen (gerne auch per Mail) würde ich mich auch freuen…

0 Comments | 2007-08-06 written by Andreas Haerter | Permanentlink
Tags: