Qbi's Weblog - General

Kakenya Ntaiya: Ein Mädchen verlangt Bildung

jens@kubieziel.de (Jens Kubieziel) — Sat, 30 Mar 2013 09:55:54 +0100

Da ich vorhin über die TED-Konferenz schrieb, schiebe ich hier noch ein Video nach. Kakenya Ntaiya erzählt ihre Geschichte. Sie besuchte auf den Willen ihrer Mutter die Schule und erkannte den Wert der Bildung für sich. Heute errichtet sie Schulen und versucht ihre Idee weiterzutragen. Es ist schon erschreckend zu hören, was ihr bzw. ihrer Mutter wiederfahren ist.

Schlechte Vorträge auf der TED und was sie draus machen

jens@kubieziel.de (Jens Kubieziel) — Sat, 30 Mar 2013 09:46:41 +0100

Ich schaue mir gern diverse TED-Vorträge an. Die TED steht für Technology, Entertainment und Design. Die Konferenz will hochklassige Vorträge bieten. Viele davon sind inspirierend, bringen neue Ideen mit oder sind einfach unterhaltsam. Bisher sind mir noch keine schlechten Vorträge untergekommen, höchstens welche, die mich nicht interessieren. Kürzlich lief mir der Artikel »When TED Lost Control of Its Crowd« vom Harvard Business Review über den Weg. Der Autor schrieb von zwei Lokal-Konferenzen, wo höchst fragwürdige Vorträge geboten wurden. Allerdings beschreibt der Artikel sehr gut, wie die Organisatoren der TED darauf reagierten und wie es weiterging. Anstatt nämlich den Kopf in den Sand zu stecken, haben Sie über verschiedene Plattformen mit den Hörern diskutieret und Lehren gezogen.

Der Artikel ist zwar recht lang, aber eine lohnenswerte Lektüre.

Amanda Palmer zur Bezahlung von Musik im Netz

jens@kubieziel.de (Jens Kubieziel) — Sat, 02 Mar 2013 22:42:24 +0100

Mein Podcast-Player lädt unter anderem die neuesten Beiträge der TED-Konferenzen herunter. Amanda Palmer startete ihren Vortrag mit einem Blick in die Vergangenheit. Die Künstlerin arbeitete anfangs als lebendige Säule, d.h. eine der Personen, die im Fußgängerbereich oft anzutreffen sind. Die Lehren, die sie daraus zog, begleiteten sie ihr weiteres Leben.

Amanda Palmer ist eine recht bekannte Künstlerin, der der persönliche Kontakt zu ihren Fans recht wichtig ist. Sie betreibt Couchsurfing und lernt dabei regelmäßig interessante Leute kennen. Dieser Kontakt half ihr, das neue Album über Kickstarter zu finanzieren. Die Künstlerin stellt ihre Alben unter eine CC-Lizenz und bei YouTube findet ihr sehr viel Material.

Bei TED hielt sie einen Vortrag, zur Kunst des Fragens. Dabei stellt sie die Frage: »How can we let people pay for music?«. Der Vortrag ist sehr unterhaltsam. Schaut ihn euch mal an.

Nachklapp zum 29C3

jens@kubieziel.de (Jens Kubieziel) — Sat, 02 Feb 2013 00:03:40 +0100

Jörg und ich produzierten im Januar einen Datenkanal. Dort unterhielten wir uns nochmal über die Eindrücke vom 29C3. Ihr könnt die Sendung als MP3 oder Ogg anhören. Bei Bitlove liegt die Sendung als Torrent.

Google Sea View

jens@kubieziel.de (Jens Kubieziel) — Tue, 22 May 2012 13:46:05 +0200

Google hilft den Piraten! Der Internetkonzern schwächt unsere Sicherheitsarchitektur! So oder so ähnlich könnten demnächst Klagen lauten. Mit Piraten sind dabei durchaus die Seeräuber und nicht die gleichnamige Partei gemeint. Doch warum handelt sich Google derartige Klagelieder ein?

Das U.S. Naval Institute organisierte kürtlich die 2012 Joint Warfighting Conference and Exposition. Neben namhaften US-Generälen und Admirälen sprach dort Michael Jones, der Chief Technology Advocate von Google Ventures. Jones stellte zwei neue Projekte vor. Beide konzentrieren sich auf Informationen zur See.

Ein Angebot will alle Schiffe, die sich auf den Flüssen und Meeren bewegen, verfolgen. Bereits jetzt gibt es Seiten wie Vesselfinder, MarineTraffic und andere. Diese Seiten zeigen die Schiffe meist in der Nähe des Ufers an. Google will den Dienst auch auf die Weltmeere ausweiten. Dazu bedient es sich des Automatic Identification Systems (AIS) . Das System besteht aus einer GPS-Einheit sowie aus einem Sender. Die Sender auf den Schiffen reichen bis ca. 20 nautische Meilen. Wenn die Antennen auf dem Land höher montiert werden, so steigt die Reichweite auf etwa 60 nautische Meilen. AIS soll zm einen Schiffe vor Kollisionen schützen und zum anderen sollen die Häfen den Verkehr besser steuern können.

AIS-Ansicht der Straße von Dover (Quelle: Wikipedia)

Google nutzt Satelliten, um die Position der Schiffe zu ermitteln. Nach Jones’ Worten gibt Google drei Millionen Dollar für das Programm aus. Er wird mit den Worten zitiert: »I watch them and they can’t see themselves. It angers me as a citizen that I can do this and the entire DoD can’t.« Doch was wir dann sehen können, kann eben auch ein Pirat in Somalia sehen. Das heißt, eventuell wird es denen erleichtert, die Schiffe auszuwählen. Auf der anderen Seite fahren in der Region die meisten Schiffe schon in dem Bereich der von AIS und den betreffenden Webseiten eh erfasst wird. Insofern fördert das Projekt aus meiner Sicht nicht die Piraterie. Eventuell wird durch die öffentliche Diskussion der eine oder andere Pirat mit der Nase auf die Möglichkeiten gestossen. Militäraktionen werden wohl ebenso nicht gestört. Denn jedes Schiff kann die AIS-Anlage ausschalten. Damit ist das Schiff quasi unsichtbar.

Das zweite Projekt kartografiert den Meeresboden. Google hat Testläufe mit einem unbemannten Sensor gemacht. Dieser macht Bilder vom Untergrund und setzt diese dann zusammen. Am Ende hat der Nutzer eine Art Google Streetview für das Meer, also Google Sea View.

Das könnte auf der einen Seite natürlich Schatzsucher aktivieren. Endlich könnte Atlantis oder das Bernsteinzimmer gefunden werden. Gleichzeitig besteht seitens der Militärs die Angst, dass auch Leute abgestürzte Spionagesatelliten oder ähnliches suchen. Jones meint darauf ganz richtig, dass andere Länder das ganz genau wie Google machen könnten. Während Google die US-Regierung informiert, halten sich andere Länder sicher nicht daran.

Ich denke, hier sind zwei spannende Angebote unterwegs und bin sehr gespannt, wann die online gehen.

via: AOL Defense: Google Can Track Ships At Sea -- Including US Navy; Detailed Maps Planned of Sea Bottom und AFCEA: Deep Blue Sea to Give Up Its Secrets to Google

Update: Klar gemacht, dass man abgestürzte Satelliten finden könnte.

Gründung des Hackspace in Jena

jens@kubieziel.de (Jens Kubieziel) — Sun, 29 Jan 2012 11:18:44 +0100

Die weltweite Hackerspace-Bewegung ist seit einger Zeit schon in Jena angekommen. Heute wird nun auch der formale Schritt vollzogen. Um 14:45 Uhr treffen sich alle Interessierten am Haupteingang des Intershop-Turms. Eine Viertel Stunde später beginnt die Vereinsgründung.

Rezension des Buches „Web-Sicherheit“ von Sebastian Kübeck

jens@kubieziel.de (Jens Kubieziel) — Tue, 08 Nov 2011 23:13:24 +0100

Da die Rezension etwas länger wurde, gibt es in der Artikelübersicht eine Zusammenfassung und in der erweiterten Ansicht alle Details.

Ich wurde kürzlich auf das Buch „Web-Sicherheit – Wie Sie Ihre Webanwendungen sicher vor Angriffen schützen“ von Sebastian Kübeck aufmerksam. Das Thema Web-Sicherheit spielt im Rahmen meiner Vorlesung zu IT-Sicherheit eine Rolle und daher war ich sehr daran interessiert, das Buch kennen zu lernen.

Der Aufbau des Buches gefiel mir sehr gut. Der Leser kann sich zuerst theoretisches Wissen erarbeiten, steigt dann in praktische Aspekte ein und lernt schließlich, wie er die Probleme umgeht.

Beim Lesen fiel mir dann auf, dass einige Teile meinen Erwartungen nicht gerecht werden. So wäre es bei einem Buch über Webanwendungen wünschenswert, dass es zumindest stichpunktartig auf die Techniken des Internet und des Web eingeht. Dieser Teil fehlt hier fast vollständig. Auch werden relevante Aspekte wie beispielsweise SSL zu kurz behandelt. Demgegenüber halte ich die Erwähnung des BTX-Hacks und anderer im Rahmen des Buches vernachlässigenswert.

Im ersten und zweiten Teil des Buches findet sich ein ausführliches Literaturverzeichnis. Das sollte dem Leser helfen, tiefer in die Thematik einzusteigen. Es wäre besser, dass die Zitierschlüssel geändert werden und mehr auf Fachliteratur statt auf Zeitschriftenartikel verwiesen wird.

Ich kann mich schlecht mit Java als Sprache für das Buch anfreunden. Aus verschiedenen Aspekten halte ich diese für weniger gut geeignet und Sprachen wie PHP, Python oder Ruby wären für mich eine bessere Wahl gewesen.

Im Buch selbst ist nach meiner Meinung zu viel Quellcode zu finden. Mindestens ein Fünftel besteht aus abgedrucktem Quellcode. Dabei ist zu viel Irrelevantes mit gedruckt. Für die Beispiele im Buch reichen oft wenige Zeilen. Code über viele Seiten finde ich zu unübersichtlich. Insbesondere auf Grund der Tatsache, dass sich der Autor auch die Arbeit gemacht hat und eine Demoanwendung mitliefert. Hier wäre es empfehlenswert, einfach die zur Erklärung des Beispiels relevanten Zeilen zu drucken und dann auf die betreffende Datei in der Demoanwendung zu verweisen.

Insgesamt bietet das Buch Licht und Schatten. Es hat viele gute Ansätze, die aber noch ausgearbeitet werden sollten. Wenn der Autor dies in einer nächsten Auflage schafft, so ist das Buch dann zu empfehlen. Derzeit bin ich unsicher, ob das Buch dem Publikum wirklich den erhofften Mehrwert bringt.

Inhalte des Buches

Der Autor gliederte das Buch in folgende Teile:

Grundlagen der Informationssicherheit
Die häufigsten Schwachstellen und deren Vermeidung
Testen und Absichern von Webanwendungen

Im ersten Teil gibt es einen kurzen historischen Abriss zu Computern und deren (Un)sicherheit. Es wird auf die Auswirkungen von Sicherheitsproblemen eingegangen. Schließlich werden einige Prinzipien der Informationssicherheit erklärt und auf kryptografische Verfahren sowie Verfahren zur Authentifizierung erklärt.

Der zweite Teil des Buches beschreibt dann konkrete Schwachstellen. Das Themengebiet reicht von Injections, XSS und CSRF über fehlerhafte Authentifizierung und Autorisierung bis hin zu Buffer Overflows sowie DoS-Attacken.

Der letzte Teil des Buches beschreibt schließlich, wie die Sicherheit von Webanwendungen getestet und wie gefundene Schwachstellen behoben werden können. Es gibt einen Abschnitt zu sicherer Entwicklung von Webapplikationen, Code Reviews und zu Penetration Tests.

Neben dem Buch stellt der Autor eine Demoanwendung zur Verfügung. Die ZIP-Datei besteht aus dem Quellcode sowie einer WAR-Datei zum Einsatz mit dem Apache Tomcat.

Meine Einschätzung

Allgemeines zum Buch

Die grobe Struktur des Buches hat mir gut gefallen. Der Leser kann dadurch an die Hand genommen werden und bekommt zunächst einen Überblick über die Theorie. Später lernt er dann die praktischen Seiten kennen. Schließlich sieht er, wie Fehler zu vermeiden oder zu erkennen sind. Dennoch glaube ich, dass das Buch an einigen Stellen dieser Erwartung nicht gerecht wird. Im Rahmen einer neueren Auflage sollte eventuell an den unten stehenden Punkten gearbeitet werden.

Eine Sache, die mich nach wie vor erstaunt, ist die Wahl der Programmiersprache. Es wird fast einheitlich Java verwendet. Nach meinen Beobachtungen spielt Java bei vielen Schwachstellen im Web eher eine untergeordnete Rolle. Des Weiteren halte ich Java für eine schwierige Lehrsprache. Der Aufwand, den Quellcode zu verstehen, ist beim Leser wahrscheinlich höher, als bei Skriptsprachen, wie PHP, Python oder Ruby. Aus meiner Sicht sollten eben diese Sprachen präferiert werden. PHP-Programmierer erschaffen noch immer eine hohe Zahl verwundbarer Anwendungen. Daher sollte die Sprache die erste Wahl sein. Denn dies macht es den Programmierern unter Umständen einfach, das durch das Buch erworbene Wissen auf den eigenen Arbeitsalltag zu übertragen. Python halte ich für eine sehr gute Lehrsprache. Man merkt dieser immer noch an, dass sie eben genau zu dem Zweck entwickelt wurde. Daher wäre dies ein guter Kandidat. Aber auch in Ruby lassen sich einfache und klare Programme schreiben.

Anfangs habe ich mich sehr über die Demoanwendung gefreut. Denn dies sollte den Lesern des Buches helfen, die Beispiele zu verstehen und sie anleiten, selbst zu experimentieren. Jedoch spielt die Anwendung im Buch nahezu keine Rolle. Obwohl im Buch Quellcode aus der Demoanwendung verwendet wird, gibt das Buch darauf keine (oder zu wenige) Hinweise. Die Codebeispiele erscheinen autark und fallen mehr oder weniger vom Himmel. Hier wäre es sehr zu wünschen, dass auf die Demoanwendung verwiesen wird. Die Codebeispiele sollten immer den Dateinamen enthalten.

Die Referenzen sind nach Kapiteln geteilt. Dabei fehlt auf der Seite 314 „Teil 2“ bzw. es müsste auf Seite 309 „Teil 1“ weggelassen werden. Weiterhin sollte die Referenz auf Seite 317 zu dem Buch von Jeffrey Friedl auf einer eigenen Zeile stehen. Ich finde die umfassende Liste der Referenzen sehr wichtig und gut. So kann der Leser sich weiterführend informieren. Mich hat die Zitierweise der Form [Autor Jahr] bei zitierten Request for Comments (RFCs) und diversen anderen Dokumenten irritiert. Hier wäre es besser, beispielsweise [RFC Nummer] zu verwenden. Dadurch wird klarer, worauf im Text verwiesen wird. Weiterhin bin ich unsicher, wie ich die Trennung der Referenzen in die Teile bewerten soll. Einerseits gefiel mir diese Idee gut. Bei der Lektüre des Buches stellte ich jedoch fest, dass es immer Schwierigkeiten gab, die entsprechende Referenz zu finden. Weiterhin sind durch die Trennung Werke doppelt zitiert. Vielleicht wäre es daher besser, die Trennung wegzulassen. Schließlich wurde der Schlüssel [Daswani 2007] (Seite 310) doppelt vergeben. Mir fiel auf, dass es sehr oft Verweise auf Sekundärquellen (SPIEGEL, Heise etc.) gab. Der interessierte Leser muss schließlich recherchieren, bis er den Originalartikel findet. Ein Verweis zu den Primärquellen wäre daher angebracht.

Der Index des Buches ist sehr gut aufgebaut und sollte den Leser schnell zu den gewünschten Stellen bringen. Hier würde ich mir nur wünschen, dass der Wortanfang bei zusammengesetzten Worten weggelassen wird. Also z.B. bei Sicherheit, Sicherheitsnetz und Sicherheitstest sollte im Index Sicherheit, -netz und -test mit dem Seitenverweis stehen.

Zum ersten Teil

Der erste Abschnitt im ersten Teil möchte eine kurze Geschichte der Computerkriminalität erzählen. Der Autor startet bei frühen Computern in den sechziger Jahren und arbeitet sich bis zum heute vor. Mir kommt dieser Abschnitt zerhackt vor. Denn zuerst wird die Geschichte bis zu den Phreakern erzählt. Im folgenden geht der Autor auf Time-Sharing und den Hacker-Begriff sowie anderes ein. Aber gerade ausgehend von den Phreakern liesse sich die Geschichte gut weiterentwickeln. Denn aus diesen Kreisen entstand letztlich die Hackerbewegung und es entwickelte sich die Forschung um Sicherheit von Rechnersystemen. Weiterhin hätte ich mir gewünscht, dass der Morris-Wurm genauer beschrieben wird. Denn diesen kann man als Prototyp für viele der aktuellen Würmer ansehen.

In „2.2 Was passiert, wenn etwas passiert“ behauptet Kübeck, dass das Bundesinnenministerium Kontakt mit den Betreibern kompromittierter Systeme aufnehmen würde. Dies halte ich für sehr gewagt und mir ist bislang noch kein Fall bekannt, in dem das der Fall war. Falls es überhaupt eine Kontaktaufnahme seitens der Behörden gibt, so eher vom BKA bzw. einem der LKAs oder von Polizeidienststellen. Es wäre dringend nötig, diesen Abschnitt klärend zu gestalten. In der jetzigen Form führt das zu Verunsicherung auf Seiten der Nutzer.

Im Buch wird auf den Abschnitt „2.3 Vorbereitungen für den Ernstfall“ als nähere Erläuterung für das Vorgehen bei Sicherheitsvorfällen verwiesen. Neben allgemeinen Hinweisen gibt es nur einen Verweis auf BSI-Maßnahmen. Der Abschnitt könnte daher ebenso gut weggelassen und vorher ein Verweis eingebaut werden.

Der erste Absatz auf Seite 50 sollte genauer formuliert werden. Es bleibt auch beim mehrmaligen Lesen unklar, welchen Fakt der Autor zum Ausdruck bringen will.

Auf der Seite 56 und anderen ist die Rede von Linux. Es sollte hier besser GNU/Linux heißen.

Die Überschrift auf Seite 60 ist aus meiner Sicht falsch gewählt. Im militärischen Bereich spricht man seit längerem von „Verteidigung in der Tiefe“ (also als 1:1-Übersetzung). Es wäre besser, dies hier beizubehalten bzw. ausnahmsweise mit dem englischen Begriff zu arbeiten. Weiterhin erscheint mir das Beispiel in dem Abschnitt unpassend gewählt. Der Autor geht hier eher auf die Einhaltung der Prinzipien von Kerckhoffs ein. Es sollte besser herausgearbeitet werden, wie gute Defense in Depth aussieht.

Die Referenz auf Seite 61 könnte besser [DSA1571] lauten. Siehe dazu meine oben stehenden Erläuterungen.

Auf der Seite 62 und einigen anderen werden immer wieder Filmbeispiele gebracht. Gerade auf dieser Seite wäre es besser, auf das vielfach angewendete 4-Augen-Prinzip zu verweisen. Dies ist „realer“ als ein Beispiel aus einem Film.

Die Verwendung des Namens „Chuck“ für den Bösewicht ist ungebräuchlich. In der Fachliteratur wird Eve für den passiven bzw. Mallory für den aktiven Angreifer verwendet. Die Begriffe wurde 1978 von Rivest et. al. in „A method for obtaining digital signatures and public-key cryptosystems“ festgelegt.

Auf der Seite 86 wird die Schlüssellänge und das Mooresche Gesetz diskutiert. Hier wäre es wünschenswert, wenn der Autor eine konkrete Empfehlung für Schlüssellängen abgibt. So könnte beispielsweise die ohnehin erwähnte Empfehlung des NIST gedruckt werden.

Beim Listing 6.1 wäre es angebracht, dass Beispiel innerhalb des Buches zu diskutieren und dem Leser klar zu machen, warum dies ein schwacher PNRG ist.

Im Abschnitt 6.4.4 wird behauptet, dass HMAC SHA-1 verwendet. Dem ist nicht der Fall. Ein HMAC kann mit einer beliebigen Hashfunktion erzeugt werden.

SSL bzw. TLS wird im Abschnitt 6.4.8 vergleichsweise kurz behandelt. Das ist jedoch ein wesentlich wichtiges Verfahren im Rahmen des Buches. Daher hätte ich mir gewünscht, dass gerade dies in wesentlich größerem Umfang behandelt wird.

Das Listing 6.3 ist aus meiner Sicht völlig unnötig für das Verständnis und kann gekürzt/weggelassen werden.

Zum zweiten Teil

Als ich mir den zweiten Teil durchlas, fiel mir auf, dass der Autor versucht, den Begriff der Sicherheit sehr weitgehend zu beschreiben. Jedoch fehlt etwas zum ersten Teil des Buchtitels, dem Web. Unter Umständen ist es sinnvoll, auf die Funktionsweise des Internet und des Web einzugehen. Das heißt, man könnte in kurzer Form auf TCP/IP eingehen, HTTP erklären und eventuell Technologien wie AJAX beschreiben. Aus meiner Sicht würde das das Buch in seiner jetzigen Form deutlich aufwerten.

Was mir in diesem Teil besonders gefallen hat, sind die Checklisten am Ende eines jeden Kapitels. Diese bieten dem Leser eine kurze Zusammenfassung und ggf. kann er Details im Kapitel nachlesen.

In Kapitel 8 wird das Thema Injection sehr gut aufgearbeitet und dem Leser sollte nach der Lektüre sowohl die Problematik wie auch Lösungsansätze bewusst sein.

Auf der Seite 123 sind in der ersten Zeile zu große Abstände zwischen den Worten.

Im Listing 9.1 würde die Zeile User: <%=request.getParameter(“user”)%> als Illustration reichen. Die folgende Erklärung zu dem Beispiel fand ich dann sehr gut. Dem Leser sollte damit die Problematik klar werden.

Im Abschnitt Session-Management beschreibt der Autor verschiedene Attribute, die eventuell zu setzen sind. Aus der Beschreibung wird jedoch nicht klar, wo diese zu setzen sind bzw. wer die setzen muss. Ein bis zwei Sätze mehr zur Erläuterung dieser Attribute würde nicht schaden. Weiterhin gehören die Punkte 5 und 6 der Aufzählung zusammen. Daher sollte diese in einem beschrieben werden. Am Ende des Abschnitts weist der Autor darauf hin, möglichst alles im Zusammenhang mit Benutzeraktivitäten zu protokollieren. Dabei sollte beachtet werden, dass es sich dabei regelmäßig um persönliche Daten handelt, die entsprechend schützenswert sind. Grundsätzlich sollten diese Daten eben nicht protokolliert bzw. schnellstmöglich wieder sicher gelöscht werden.

Der folgende Abschnitt 11.5 diskutiert Zwei-Faktor-Authentifizierung und verweist auf 6.4.7. Beide sind jedoch sehr kurz. Dem Leser des Buches wird wahrscheinlich nicht klar, wie dies umzusetzen ist. Weiterführende Erläuterungen oder ein Verweis auf Literatur sollte unbedingt vorhanden sein.

Die Schilderung von Path-Traversal-Verwundbarkeiten auf der Seite 163 ist aus meiner Sicht unvollständig oder unschlüssig. Es wird darauf verwiesen, dass ein Angreifer die Datei /etc/passwd auslesen kann. Danach suggeriert der Autor, dass sich schwache Passwörter errechnen lassen. Auf den diversen GNU/Linux-basierten Systemen sollte dies in der Standardinstallation seit mehr als zehn Jahren nicht mehr möglich sein. Denn die Passwörter sind in der /etc/shadow abgelegt. Die Datei ist nur von root les- und schreibbar. Zugriff auf die Datei besteht, wenn der Webserver mit falschen Nutzerrechten betrieben wird oder eine „kreative“ Installation vorhanden ist. Im folgenden wird beschrieben, dass ein Angreifer sich Root-Rechte verschaffen kann oder, falls dies nicht möglich ist, mittels eines hochgeladenen Skripts Schwachstellen aufspüren kann. Der Beschreibung nach zu urteilen, ist es dem Angreifer möglich sich einzuloggen. Insofern ist unklar, warum er nun extra ein Skript hochlädt. Er könnte genauso also eingeloggter Nutzer das System erforschen. Andererseits benötigt er Schreibrechte auf das DocumentRoot des Webservers. Dies ist auch nicht immer gegeben. Ich würde mir eine klarere Beschreibung des Gesamtvorgangs wünschen. Der Autor sollte hier eventuell mehr verweilen und durchaus auf andere relevante Kapitel (Pufferüberläufe usw.) verweisen.

Die Beschreibung zu Beginn von Kapitel 14 ist zu allgemein gehalten. Dem Leser drängt sich der Eindruck auf, dass hinter Problemen mit einer fremden Webanwendung ein DoS-Angriff steckt. Ich würde mir hier eine differenzierte Betrachtungsweise oder ein anderes Beispiel wünschen.

Der Abschnitt 15.1 heißt „Gefährliche Standardeinstellungen“. Jedoch diskutiert dieser nur das Risiko von Standardpasswörtern. Im Sinne der Überschrift wäre es sinnvoller, weitere Beispiele für gefährliche Standardeinstellungen zu finden.

Die Liste auf Seite 188 hat eine Nennung mit „… oder … oder …“. Ich finde dies ungewöhnlich und besser wäre es, eines der oder wegzulassen.

Auf der Seite 189 empfiehlt der Autor, einen Webserver ausschließlich auf den Ports 80 und 443 Dienste anzubieten. Mir erschließt sich nicht, warum man einen Webserver nicht auf einem beliebigen anderen Port laufen lassen sollte. Für die Sicherheit ist es unerheblich, ob dieser seine Dienste auf Port 80, 8080 oder 31337 anbietet. Eventuell sollte der Autor seinen Gedankengang genauer schildern.

Die Konfigurationsdatei im ersten Absatz auf Seite 190 heißt httpd.conf.

Ich bin über die Wortwahl „Testsystemen zu testen“ auf Seite 192 gestolpert.

Auf der Seite 193 verwendet der Autor den Ausdruck „monolithische Betriebssysteme“. Meines Wissens eignet sich derzeit nur Minix halbwegs für den Produktiveinsatz. Die Standardsysteme sind hingegen allesamt monolithisch. Insofern kann diese Information entfernt werden. Denn wahrscheinlich irritiert diese den Nutzer bzw. im Kontext des Absatzes drängt sich der Eindruck auf, dass nur Microsoft Windows monolithisch wäre.

Zum dritten Teil

Der dritte Teil des Buches beschäftigt sich mit Tests und Absicherung von Webanwendungen. Ich habe diesen Teil nur noch überflogen. Daher kann ich lediglich einen Eindruck schildern.

Der zweite Absatz des 16. Kapitels endet mit einem Satz, der sich über fünf Zeilen erstreckt. Im Sinne der Lesbarkeit sollte der in kleinere Elemente geteilt werden.

Der Teil „glänzt“ wieder mit Codewüsten. Die Seiten 207–214, 225–234, 242–248 und 260–280 bestehen zu großen Teilen nur aus Quellcode. Das ist nahezu die Hälfte des Teils. Wie ich schon an anderer Stelle schrieb, ist weniger mehr. Sinnvoll wäre es, relevante Teile zu drucken und auf den mitgelieferten Code zu verweisen.

Weiterhin macht es den Eindruck, dass das Programm Nikto relevant ist. Es wird mehrfach darauf verwiesen und ein Screenshot des Programms gezeigt. Im Index fehlt ein Eintrag zu dem Programm und wenn es wirklich so relevant ist, sollte es auch genauer beschrieben werden. In der jetzigen Version entsteht der Eindruck, das hier eine Lücke verblieben ist.

Fehler

Seite 71: Wiederspruch -> Widerspruch
Seite 197: Djikstra -> Dijkstra (ebenfalls im Index)

Behördenwillkür bei Jacob Appelbaum

jens@kubieziel.de (Jens Kubieziel) — Mon, 10 Oct 2011 22:30:53 +0200

In Deutschland dreht sich derzeit die Diskussion um den Bundestrojaner, der vom CCC gefunden wurde. Derweil spielt sich in den USA ein anderes Drama ab.

Jacob Appelbaum kann man nur als vielseitigen Zeitgenossen bezeichnen. Er arbeitet beim Tor-Projekt als Entwickler, hat in der Vergangenheit einige spektakuläre Ergebnisse im Bereich der IT-Sicherheit gefunden, engagiert sich bei WikiLeaks, half Hurrikanopfern usw. Die Liste lässt sich beliebig erweitern. Doch eines seiner Hobbys brachte ihm Probleme ein. Auf der Konferenz The Next HOPE hielt er im Juli 2010 einen Vortrag zu WikiLeaks (siehe unten). Seitdem wird Jacob bei jedem Grenzübertritt aus den USA oder in die USA kontrolliert. Das heißt, er wird zum Teil stundenlang festgehalten und befragt. Ihm wurden Geräte weggenommen und anderes mehr. Jetzt werdet ihr euch fragen, auf welcher Basis dies passierte. Dies ist bis heute unklar! Es gibt keine Anklage.

Nachdem das Justizministerium Informationen von Twitter über Jacob Appelbaum und andere Aktivisten wollte, geht die US Regierung noch einen Schritt weiter. Sie forderte von Google und von dem Provider Sonic alle E-Mail-Adressen mit denen Appelbaum in den letzten zwei Jahren kommunizierte. Ein Artikel im Wall Street Journal hat weitere Details zu der Sache.

Welchen Erkenntnisgewinn soll eine solche Sache bringen? Wenn man die diversen Schritte der Behörden verfolgt, drängt sich der Verdacht auf, dass es nur um Schikane geht. Jacob kann man wohl nichts Böses nachweisen und so scheinen die Behörden einfach ein Exempel zur Abschreckung aufzubauen. Ich kann nur hoffen, dass die Vorgang ein Ende hat und Jacob sich wieder seinen Interessen widmen kann.

Anatomie einer Spammail

jens@kubieziel.de (Jens Kubieziel) — Thu, 28 Jul 2011 00:32:50 +0200

Bei der LUG Jena hatten wir kürzlich eine Diskussion über Spammails und Viren. Der Grund war, dass ich die untenstehende E-Mail erhielt. Das ist mal kein alltäglicher Spam. Vielmehr wird hier versucht, mir Malware unterzuschieben. Ich will mal versuchen, die Details hier aufzuschreiben.

Zunächst werfen wir einen Blick auf die E-Mail. Die Received:-Zeilen geben Aufschluss über den Weg der E-Mail. Üblicherweise geht man vom Empfänger zum Absender vor. Der Computer mit dem Namen MeinRechner hat die E-Mail von jengate.thur.de entgegen genommen. Der Rechner mit dem Namen demokritos1.cytanet.com.cy hat die E-Mail dort eingeliefert. Dessen IP-Adresse war 195.14.130.192. Der Rechner, mit dem alles begann, nannte sich selbst charmex.ovh.net. Seine IP-Adresse war 94.23.84.123 und die löste zu dem Namen mail.charmex.net auf.

Wie schon zu vermuten ist, löst die Adresse charmex.ovh.net nicht auf. Die IP-Adresse und der richtige Hostname bringen da schon mehr. Der Domainname wurde von Charmex International aus Barcelona registriert. Wie man in untenstehendem StreetView-Ausschnitt sieht, ist das wohl eine richtige Firma mit Sitz in einer Art Bürogebäude:

Größere Kartenansicht

Das kleine Programm dnsmap sagte mir später, dass es die Namen {ftp,mail,smtp,webmail,www}.charmex.net gibt. In der Tat antworten ProFTPd, Apache, Postfix, Courier usw. an den entsprechenden Ports. Der Apache ist auch der Meinung, dass er aus einer Debian-Distribution stammt. Denn ein curl -I http://www.charmex.net/ führt unter anderem zu der Ausgabe Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny8 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g. Robtex zeigt eine ganze Menge zu DNS-Kram an. Auch zu Charmex wusste es einiges zu berichten.

Der folgende Host demokritos1.cytanet.com.cy ist derzeit in zwei RBLs zu finden. Die komplette Domain ist auch bei rfc-ignorant gelistet. Genauere Informationen findet ihr wieder bei Robtex: zum Domainnamen und zur IP-Adresse.

Wenn man den Header-Zeiler glauben darf, wurde die Software The Bat! eingesetzt. Die Version stammt schon aus den Anfangsmonaten von 2005. Die Software kann man kaufen oder testen. Die Testversionen haben normalerweise enen bestimmten String und bei der gekauften ist theoretisch der Käufer registriert. Bei einer derart alten Version vemute ich jedoch, dass man auf dem Wege nicht mehr den wirklichen Besitzer finden würde.

Der Name des Empfängers ist zwar Schall und Rauch und kann leicht gefälscht werden. Dennoch stolperte ich über Namen. Der kann zwar bedeutungslos sein. Jedoch stimmt der mit dem russischen Namen ?????? überein.

Die Message-ID ist nicht vom Programm The Bat! erzeugt worden. Denn die Versionen bis mindestens 4 erzeugen ein Muster ZUFALLSWERT.DATUM@DOMAIN. Der Wert nach dem Punkt ist eindeutig kein Datum. Nun habe ich etwa 140.000 Mails nach einer Message-ID dieser Form durchsucht. Interessanterweise taucht das Muster nur bei Spammails und erst ab April 2011 auf. Viele dieser E-Mails behaupten von The Bat! verfasst worden zu sein. Ich vermute, dass der Mailer positive Punkte bei Spamerkennungssoftware bringt.

Ziemlich am Ende des Kopfes der E-Mail stehen die Zeilen:

MIME-Version: 1.0                                                    
Content-Type: text/plain;                                                       
        charset=“utf-8”                                                         
Content-Transfer-Encoding: 8bit

Diese passen nicht so recht ins Bild. Die meisten Mailprogramme, die ich kenne, erzeugen je nach dem Inhalt eine andere Zeile. In dieser Kombination habe ich es bisher nur von Skripten gesehen. Daher nehme ich an, dass auch diese E-Mail von einem Skript erzeugt wurde.

Im Header könnte man noch weiter herum orakeln. Aber wenden wir uns lieber dem Text der E-Mail zu. Die Anrede wurde klein geschrieben. Ein weiterer Hinweis auf ein Skript. Denn der Rest der E-Mail hat korrekte Groß- und Kleinschreibung. Wenngleich sich die E-Mail liest, als wäre sie durch den Babelfisch gejagt worden.

Das Interessanteste am Text ist natürlich die URL hxxp://cdmirandes.com/.bestellen/Orden.zip. Ich habe absichtlich hier ein xx reingeschrieben. Wer sich die Datei herunterladen will, soll es wirklich wollen. Die Inhalte sind nicht für jeden Rechner gesund.
Ich habe die URL an Virustotal weitergereicht. Nach dem URL-Scan erkannte nur TrendMicro die Seite als Malware-Seite. Der Rest der Virenscanner meldet diese auch heute noch als „clean“. Die Datei Orden.zip hat knapp 180 kB. Das erste Ergebnis von Virustotal war gemischt. Etwa ein Ein Sechstel aller Virenscanner erkannte irgendetwas Böses an der Datei. Mittlerweile erkennt die Mehrzahl der Scanner die Datei als eine Abart des Zeus- Trojaners. Vier Tage nach meinem ersten Scan lag die Erkennungsrate bei knapp 70%. Heute (zwei Wochen danach) sind 81% der Virenscanner der Meinung, dass es Malware ist. Die Jotti-Virenscanner liefern ein ähnliches Bild. Hier wird wieder klar, wie sehr oder wenig man sich auf einen Virenscanner verlassen kann.

Damit kann man auf die Löschtaste drücken und die E-Mail ins Nirvana schicken. Oder man übergibt die Datei an Seiten wie ThreatExpert, CWSandbox oder anderen und schaut nach, was der Trojaner so anstellt. ThreatExpert führt die Software in einer virtuellen Maschine aus und macht vorher und hinter einen Schnappschuss. Damit werden Änderungen an Dateien, der Registry uvm. sichtbar. Für die ausführbare Datei ergab sich folgende Analyse. Eine wesentliche tiefergehende Analyse liefert der Report von CWSandbox. Hier ist auch zu sehen, dass die Datei eine Netzwerkverbindung aufnehmen wollte. Von dem Hostnamen swarsdf45432.com sollte die Datei cfg1.bin abgerufen werden. Leider findet sich unter dem Namen nichts mehr. Er klingt für mich auch nach Fast Flux. Jedoch findet sich auch eine IP-Adresse 94.60.122.90. Unter der Adresse läuft ein Apache und einige weitere Software. Ein Versuch, die Datei abzurufen, endete mit Fehler 503. Damit stelle ich auch meine Rechercheversuche ein. Aber der geneigte Forscher kann sicher an der einen oder anderen Stelle ansetzen und noch ein wenig mehr herausfinden. Viel Spass!

From hwfend@ovh.net  Tue Jul 12 08:24:07 2011                              
Return-Path: <hwfend@ovh.net>                                             
X-Original-To: jens@localhost                                                   
Delivered-To: jens@localhost                                                    
Received: from MeinRechner (localhost [127.0.0.1])                              
        by MeinRechner (Postfix) with ESMTP id E34A7C12B                        
        for <jens@localhost>; Tue, 12 Jul 2011 08:24:06 +0200 (CEST)      
X-Spam-Flag: NO                                                                 
X-Spam-Status: No, score=0.7 required=5.0 tests=SPF_NEUTRAL version=3.3.0       
X-Spam-Level:                                                                   
X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on taliesin.iks-jena.de 
X-Envelope-To: <jens@kubieziel.de>                                        
X-SMTP-Sender: 195.14.130.192                                                   
Received: from jengate.thur.de [217.17.193.190]                                 
        by MeinRechner with POP3 (fetchmail-6.3.9-rc2)                          
        for <jens@localhost> (single-drop); Tue, 12 Jul 2011 08:24:06 +0200 (CEST)                                                                       
Received: from demokritos1.cytanet.com.cy (demokritos1.cytanet.com.cy [195.14.130.192])
        by jengate.thur.de (8.14.3/8.14.1) with ESMTP id p6C46k2I024729         
        for <jens@kubieziel.de>; Tue, 12 Jul 2011 06:06:49 +0200          
X-Virus-Scanned: By virus scanner at Cytanet                                    
Received: from charmex.ovh.net (mail.charmex.net [94.23.84.123])                
        by demokritos1.cytanet.com.cy (Postfix) with ESMTPA id 8ECA1400422;     
        Tue, 12 Jul 2011 07:06:35 +0300 (EEST)                                  
Received: from [94.23.84.123] by charmex.ovh.net id D9bLMDfi39sn with SMTP; Tue, 12 Jul 2011 06:06:35 +0200                                                    
Date: Tue, 12 Jul 2011 06:06:35 +0200                                           
From: “Dzhozefa” <hwfend@ovh.net>                                         
X-Mailer: The Bat! (v3.5.58.4) Home                                             
X-Priority: 3 (Normal)                                                          
Message-ID: <442115854.74189522192380@charmex.ovh.net>                    
To: <jens@kohlenpotthoppers.de>                                           
Subject: Der Bericht                                                            
MIME-Version: 1.0                                                               
Content-Type: text/plain;                                                       
        charset=“utf-8”                                                         
Content-Transfer-Encoding: 8bit                                                 
Status: RO
Content-Length: 233                                                             
Lines: 8                                                                        
                                                                                
Guten Morgen jens                                                               
Unsere Firma hat das Budget umverteilt, und jetzt ist bei uns Price das Blatt erneuert erschienen                                                              
Herunterladen es kann hier:                                                     
hxxp://cdmirandes.com/.bestellen/Orden.zip                                      
                                                                                
Mit freundlichen Grussen,                                                       
Price Index GmbH.

Schweigen ist Gold

jens@kubieziel.de (Jens Kubieziel) — Sun, 22 May 2011 22:52:44 +0200

Eine alte Redewendung besagt: „Reden ist Silber, Schweigen ist Gold.“ Gerade im Hinblick auf polizeiliche Ermittlungen ist dieser Hinweis wirklich Gold wert.

Auf dem 23C3 begeisterte der Rechtsanwalt Udo Vetter viele Zuhörer mit seinem Vortrag Sie haben das Recht zu schweigen. Er gab damals einige Hinweise, wie man sich bei einer Hausdurchsuchung verhalten soll. Der mit Abstand wichtigste Hinweis fand sich schon im Titel.

Einige Zeit später stieß ich auf ein Video eines amerikanischen Professors (siehe unten). Auch er erklärte seinen Zuhörern, warum es beim Kontakt mit den Polizeibehörden wichtig ist, nichts zu sagen. Dabei ging er recht methodisch vor und machten an verschiedenen Profilen (Schuldige, Unschuldige, Lügner, Ehrliche etc.) klar, dass niemand einen Vorteil hat, ohne Anwalt mit den Behörden zu reden. Der Vortrag wurde von einem Ermittler ergänzt, der seine Rede mit einer vollumfänglichen Bestätigung des Vorredners begann.

Dennoch hat sich diese Erkentnis noch nicht herumgesprochen und sogar hochrangige Personen tappen in die Falle. Der aktuelle The New Yorker beschreibt die Geschichte von Thomas Drake, einem Ex-NSA-Mitarbeiter und Whistleblower. Drake misfiel die enorme Geldverschwendung der Behörde sowie die Unrechtmäßigkeit der Abhörmaßnahmen. Nachdem er intern keinen Erfolg mit seinen Beschwerden hatte, wandte er sich an die Medien. Durch die Berichte in der Baltimore Sun kam es zu Ermittlungen und er wie einige andere stand im Fokus von Ermittlungen. Bei einer Hausdurchsuchung machte er dann wohl einen entscheidenden Fehler:

…, he viewed the raid as a fresh opportunity to blow the whistle. He spent the day at his kitchen table, without a lawyer, talking. […] He also disclosed his computer password.

Insgesamt kooperierte Drake lange Zeit mit den Behörden und versuchte sich dadurch einen Vorteil zu verschaffen. Mittlerweile ist das Ausmaß seiner „Verbrechen“ klar. Laut Anklageschrift soll er fünf geheime Dokumente entwendet und die Behörden belogen haben. Interessanterweise hatte eines der Dokumente keinerlei Sicherheitseinstufung. Nach der Anklage war das falsch eingestuft und hätte geheim sein müssen. Die Schrift behauptet, das hätte er wissen müssen. Ein zweites Dokument wurde drei Monate nach der Anklage deklassifiziert, also als nicht geheim erklärt. Dafür erwartet ihn unter Umständen eine Strafe von 35 Jahren im Gefängnis. Bei der Anklage ist der Punkt mit der Lüge interessant. Denn wie der oben erwähnte Professor schon ausführte, kann eben genau das passieren, wenn man sich mitteilt. Das heißt, erzählt man etwas, dass sich später als unwahr herausstellt bzw. die Ermittler der Meinung sind, dass es unwahr ist, so führt das zu einem Extra-Anklagepunkt.

Aber selbst wenn sich jemand vornimmt, nichts zu sagen, so dürfte das in der realen Situation schwierig sein. Zum einen ist eine Hausdurchsuchung für die meisten eine sehr ungewohnte, belastende Lage. Hier wird es schwer, sich an seine „Vorsätze“ zu erinnern. Zum anderen beschreibt der oben genannte Ermittler die Verhältnisse ganz gut. Er sagt: „Stellen Sie sich vor, ein Normalbürger steigt mit einem Profiboxer in den Ring. Wer wird den Kampf gewinnen?“ Der Profiboxer ist in dem Fall der Ermittler, der eine umfassende Ausbildung darin bekommen hat, wie er Menschen zum Reden bekommt. Aber wer von euch hatte schon eine Ausbildung im Schweigen? Der Ermittler beschreibt auch sehr schön die diversen Tricks, mit denen er sein Ziel erreicht.

Solltet ihr mal in eine solche Situation kommen, dann antwortet einfach auf jede Anfrage eures Gegenübers mit dem Satz: „Bitte nehmen Sie zur Kenntnis, dass ich keine Aussage machen möchte“ (frei nach den Worten von Udo Vetter). Hoffentlich wird dann alles gut.

Vortrag von Udo Vetter:

Vortrag „Don’t talk to the police“:

Podcast rund um die Volkszählung 2011

jens@kubieziel.de (Jens Kubieziel) — Tue, 08 Mar 2011 09:59:34 +0100

Michael Ebeling hat in Zusammenarbeit mit dem Radio Flora einen sechsteiligen Podcast zur Volkszählung 2011 gemacht. Wer noch Informationen zum diesjährigen Zensus und seiner Geschichte sucht, ist hier genau richtig. Folgende Themen werden behandelt:

via zensus11.de

Förderung für TorServers.net

jens@kubieziel.de (Jens Kubieziel) — Thu, 03 Mar 2011 21:27:28 +0100

Moritz Bartl, der Gründer von Torservers.net, kann einen ersten großen Erfolg feiern. Die amerikanische Organisation Access Now unterstützt das Projekt über ein halbes Jahr mit 10.000 US-Dollar. Damit plant TorServers.net weitere Tor-Server zu betreiben und Nutzern in Zensurstaaten freie Informationen zur Verfügung zu stellen.

TorServers.net entstand aus der Überlegung, dass es zu wenige schnelle Tor-Server gibt. Binnen kurzer Zeit gelang es Moritz Bartl einige schnelle Server zur Verfügung zu stellen. Mit der Förderung steht das Projekt nun weiter auf stabilen Beinen. Ich wünsche TorServers.net auf jeden Fall weiter viel Erfolg.

Sind die Niederlande bei Google verboten?

jens@kubieziel.de (Jens Kubieziel) — Wed, 23 Feb 2011 23:10:04 +0100

Bei der LUG Jena gibt es morgen, am 24. Februar 2011, einen Vortrag über die Programmiersprache Go. Ich wollte mich nun etwas durch die Webseite des Projektes klicken. Doch Google mag mich nicht.

Die IP-Adresse gehört dem Tor-Server evoboxes. Dieser wird von TorServers.net betrieben und steht in den Niederlanden. Nun frage ich mich, warum gerade die Niederlande ein „forbidden country“ sind.

Fehlersuche

jens@kubieziel.de (Jens Kubieziel) — Wed, 23 Feb 2011 22:42:33 +0100

Der Bug mit der Nummer 1926 raubt mir derzeit ein wenig den Nerv. Ich sammle Informationen, um diesem ein wenig auf den Grund zu gehen. Dazu tippte ich die folgende Zeile in meine Shell ein:

for file in `find extra-infos-2011-02 -type f`; do
   awk ‘BEGIN {RS=“” } /history (2000-01-01|2008-09-11|…)/ { print $0 }’ \
     >> wrong.2010-07
 done

Die Datei wollte einfach nicht voll werden. Da knapp über 200000 Dateien durchsucht werden, machte ich mir anfangs keine Gedanken. Irgendwann warf ich einen langen Blick auf die Eingabe, dann noch einen und dann noch einen. Schließlich fiel mir auf, dass $file nicht referenziert wird. Kaum macht man es richtig, schon wird die Datei mit Inhalten befüllt.

Coworking in Jena

jens@kubieziel.de (Jens Kubieziel) — Wed, 16 Feb 2011 23:01:29 +0100

Gemeinsam arbeiten, diskutieren, denken oder einfach entspannen. Das ist die Idee von so genannten Coworking-Spaces. Aber auch die Hackergemeinde lebt dieses Motto mit Hackerspaces. Die Mieten in Jena waren bisher einer der Gründe, warum der Jenaer Hackspace das Planungsstadium nicht verlassen hat. Hingegen nehmen die Planungen für einen Coworking-Space gerade konkrete Formen an. Wie Jenapolis berichtet, gibt es morgen, am 17. Februar 2011 ein Treffen. Interessierte können ab 16 Uhr in das Kassablanca (beim Westbahnhof) kommen und Informationen austauschen. Vielleicht kommt dann auch wieder Leben in die Planungen zum Hackspace. Beide Projekte befruchten sich sicher gut.