Qbi's Weblog

Woher kommen eigentlich Viren, Würmer und andere Schadsoftware? Über welchen Weg brechen Angreifer in Computersysteme ein? In vielen Fällen heißt die Antwort »Buffer Overflow« oder Pufferüberlauf. Jörg und ich sind der Frage nachgegangen, was so ein Buffer Overflow eigentlich ist. Wir versuchen anhand einer Analogie mit Kisten und deren Inhalten das Wesen des Überlaufs zu erklären. Anschließend bieten wir einige Lösungen für das Problem an. Neugierig geworden? Dann hört mal in den Datenkanal 19 rein:

• DK19 als MP3
• DK19 als OGG

Durch Bitlove könnt ihr beide Dateien über BitTorrent herunterladen.

• MP3 als BitTorrent
• OGG als BitTorrent

Viel Spass beim Anhören und, falls ihr mögt, könnt ihr flattrn.

Geek and Poke beschreibt sehr schön, wie sich ein Security-Geek in einem Restaurant beschweren kann:

Das National Institute of Standards and Technology (NIST) gab heute bekannt, wer den SHA-3-Wettbewerb gewonnen hat: Keccak. Der Algorithmus wird nun die neue Empfehlung für einen kryptografischen Hash. Er stammt von den Forschern Guido Bertoni, Joan Daemen, Michaël Peeters und Gilles Van Assch. Besonders erwähnenswert ist Daemen. Denn er war schon für den Verschlüsselungsalgorithmus AES zuständig, der vor mehr als zehn Jahren standardisiert wurde.

Die bisher oft genutzten Algorithmen benutzen das so genannte Merkle-Damgård-Verfahren. Keccak geht einen neuen Weg (cryptographic sponge). Das erinnert mich ein wenig an AES. Denn auch damals kamen die Standardisierer von dem Feisteldesign ab.

Daniel Bernstein hat Benchmarks für verschiedene Algorithmen auf verschiedenen Plattformen gemacht. Nach der Seite ist beispielsweise BLAKE wesentlich schneller als Keccak. Im Allgemeinen scheint SHA-3 in Hardware gegossen schneller als SHA-2 zu sein. Aber die Softwarevariante ist wesentlich langsamer. Mal sehen, was die nächsten Tage ergeben. Aber momentan kann man wohl Bruce Schneier recht geben, der mal sagte, dass niemand SHA-3 nutzen wird. Nichtsdestotrotz: Alles Gute zur Wahl.

Zwischen den Feiertagen werden ja gern mal unausgegorene Ideen in die Welt hinaus geblasen. So fühlt sich die Meldung an, die bei ZEIT Online zu lesen war: Kinderporno-Fahndung bei allen Internetnutzern. Kai Biermann schreibt dort, dass die Initiative White IT die Internetanbieter dazu bringen will, selbst auf die Suche nach Mißbrauchsbildern gehen soll. Dazu gibt es eine Datenbank, in der alle Bilder vermerkt sind und zu jedem Bild existiert eine Prüfsumme (Hash). Der Internetanbieter berechnet seinerseits die Prüfsumme von Bildern aus dem Datenstrom seiner Kunden. Falls es eine Übereinstimmung mit dem Eintrag in der Datenbank gibt, so schlägt die Software Alarm.

Doch wie sinnvoll ist eine derartige Idee? Oberflächlich betrachtet klingt das vielversprechend. Aber schaut euch mal die vier Bilder unten an. Entdeckt ihr einen Unterschied?

>

Die Prüfsummen (SHA-224) der Dateien sind 7fab23221b7a000ec0ab18431d58e2e58c16e3093bbf54084f22e802, c33230b4341d8b1f08a90382e27a145dff1d8208b5c25195674ee2e8, 69ff77157382503ae68d1cf4354034b640c7593465e383a0db51df9b und 87426dcee42ceb7f507eac515f5620bcb359364405a0abbd240364d8. Also rein technisch sind diese verschieden. Der Screenshot wurde in verschiedenen Formaten gespeichert und mit unterschiedlichen Qualitätsstufen. Wenn man das Spiel weitertreibt, könnten mehrere tausend (eventuell sogar Millionen) Varianten des Bildes angefertigt werden, die alle gleich aussehen, aber unterschiedliche Prüfsummen besitzen. Das Prüfprogramm müsste eben alle diese Varianten kennen oder die Änderungen intelligent erkennen. 

Aber selbst im letztgenannten Falle bieten sich derartig viele Möglichkeiten, dass Erkennungsprogramm zu umgehen, das die Idee besser schnell wieder beerdigt gehört. Denn während bei der Vorratsdatenspeicherung  „nur“  auf die Verbindungsdaten zugegriffen wurde, schauen hier beliebige Internetanbieter direkt in die Inhalte der Kommunikation hinein. Der Plan geht also wieder einen Schritt weiter in Richtung Vollüberwachung.

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.

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

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.  

Continue reading "Behördenwillkür bei Jacob Appelbaum"

Bei Twitter war kürzlich mal wieder ein nettes Mem zu beobachten. Es entstand eine Folge von „The great thing about $PROTOCOL jokes is $PROTOKOLLEIGENSCHAFT.“-Sätzen. Zu finden ist das Ganze unter dem Hashtag #protolol. Naja, lest selbst:

• The great thing about TCP jokes is that you always get them.
• The great thing about IP over Avian Carrier jokes is that if your joke gets fragmented, you at least get free dinner.
• The great thing about WebDAV jokes is you can tell many different versions of the same joke and people will still listen.
• The great thing about Zeroconf jokes is that you can just walk up to strangers and tell them, no introduction necessary.
• The great thing about IPP jokes is that you always end up with a paper record of the joke in question.
• The great thing about Nessus jokes is that they’re often inaccurate and poorly worded.
• The great thing about rsync jokes is that it only tells them if you haven’t heard them before.
• The great thing about bacterial transformation jokes is that there are always a lot of fungis involved.
• The great thing about DHCP jokes is that you can lend them to others and take them back when you want.
• The great thing about DNS jokes is that you don’t have to tell them with authority.
• The great thing about BGP jokes? Anyone can claim they are their own, all you can do is hope your neighbours like them.
• The great thing about nerdy jokes is that they follow a general pattern of self-referentiality that can be abstracted out.
• The great thing about ASLR jokes is you never know where they’re going.
• The great thing about antivirus jokes is you only need to change them a little and they’re funny again.
• The great thing about encryption jokes is d0842c7091158f8a8e6c89ed0cf4ec07.
• The great thing about gmail jokes is the chinese read them before you do.
• The great thing about TLS jokes is that you can tell if it’s not original.
  
• The great thing about XML jokes is that you can put anything into them.
• The great thing about Java jokes is waiting for them to begin.
• The great thing about Teredo jokes is that you can tell smart jokes even when surrounded by dumb peers.
  
• The great thing about PGP email encryption jokes is that nobody can read their own encrypted email because it’s so unusable.
• The great thing about RFC 862 jokes is the great thing about RFC 862 jokes.
• The great thing about source routing jokes is that someone else get in trouble for telling them at your instigation.
• The great thing about DNS jokes is that they work on so many levels.
• The great thing about fragmentation jokes is
• The great thing about IGMP jokes is that you can be selective in who gets them.
• The great thing about ARP jokes is they’re unauthenticated.
• The great thing about IPv6 jokes is that there are so many of them.
• The great thing about ICMP error jokes is that nobody can ever reply to them.
• The great thing about UDP jokes is that even if you don’t get them, nobody notices.
• The worst part of SSH jokes is that, even when they’re not funny, you suck it up and just pretend they were anyway.
• The best thing about XMPP jokes is that you can tell when they’re available.
• The problem with greylisting jokes is, that you always have to tell them twice.
• The sad thing about Kerberos jokes is that you first have to buy a ticket to join the laughter.
• The problem with PGP jokes is that you need to gain everybody’s trust before they can laugh with it.
• The best GFW jokes are inaccessible from China.
• The sad thing about IPv6 jokes is that almost no one understands them and no one is using them yet.
• The best thing about proprietary protocol jokes is REDACTED. 
• The best thing about SMTP jokes is, you had me at HELO. 
• The best part about WAF jokes is there are a hundred ways to tell them, and everyone is sure to get them.
• The problem with git jokes is everyone has their own version.
• Everybody loves MitM jokes. Well, everybody except Alice and Bob that is.
• The worst thing about Perl jokes is that next morning you can’t understand why they seemed so funny.
• I don’t make SQLi jokes myself, I get them FROM USERS.
• The good thing about OTR jokes is that you forget the punchline afterwards.
• The best thing about Skype jokes is the ridiculous lengths they’ll go to, to be told at all.
• The best thing about mathematical jokes is left as an exercise for the reader.
• The best thing about Twitter API jokes is that you can only make 100 of them per hour.
• The problem with 802.11 jokes is that somebody far away is always listening.
• The problem with BGP jokes is the need for a local default joke, just in case you reject all of the other jokes coming in!
• The problem with telling NTP jokes is that you’re constantly adjusting your timing.
• The worst thing about HTML jokes is that your audience doesn’t always GET it.
• The good thing about pure functional jokes is, telling them has no side effects.
• The good thing about Twitter jokes is they’re so short.
  
• The problem with ASCII jokes is having to leave out the good bits.
• The bad thing about DVCS jokes is they’re all clones of each other …
• The best part about a CISSP joke, is you don’t have to know anything about security to get it.
• The problem with CSS jokes is that everyone understands them differently.
• The great thing about integer overflow jokes is that GCC doesn’t think they’re funny.
• The problem with standards jokes is that there are so many to choose from.
• The problem with IPv4 jokes is there aren’t enough for everyone.
• The problem with dining cryptographers network jokes is that you never know who told them.
• The problem with DRM jokes is that you can’t share them with your friends.
• The best part about TTL jokes is that they can only be told so many times.
• The problem with anonymity jokes is that any jackass can take the credit for them.
• The problem with TCP jokes is that people keep retelling them slower until you get them.
• The bad thing about Turing machine jokes is you never can tell when they’re over.
• The great thing about HTML jokes is that you’re never quite sure when they end.

Eine Zusammenstellung gibt es auch bei attrition.org.