Author: Patrick Sauer

Penetration Testing von IPv6-Netzwerken

Leave a Comment

Ein gewöhnliches IPv4-Netzwerk besteht nicht aus sonderlich vielen IP-Adressen. Ein /24er Block besteht aus 256 Adresse. Selbst bei einem wesentlich größerem /22 existieren nur 1.024 Adressen. Auch wenn nicht alle nutzbar sind (Network, Broadcast) bleiben wir einmal bei diesen Zahlen.

Relativ am Anfang eines Penetrationstests einer IT-Infrastruktur bzw. einem Netzwerk steht die Identifizierung der Live-Hosts, also der IP-Adressen, die tatsächlich einem Host zugewiesen sind. Das kann durch einen kurzen Ping-Sweep passieren oder man ignoriert ICMP und scannt den maximalen Port-Range über TCP und UDP. Vergleicht man beide Fälle anhand eines /22er-Blocks ergibt das bei einem Ping-Sweep 1.024 zu verschickende Anfragen und bei einem Scan über den gesamten Port-Bereich inkl. TCP und UDP bereits 1.024*65.535*2 = 134.215.680 – über 130 Millionen Anfragen, um absolut zuverlässig alle aktiven Hosts in einem /22 erkennen zu können.

Definitiv ist der Scan über alle Ports relativ zeitintensiv, aber noch realisierbar. Gehen wir einmal davon aus, dass ein Host jede Anfrage mit CLOSED o.ä. beantwortet und der Scanner nicht in einen Timeout läuft. Bei einer angenommenen Netzwerk-Latenz von 1ms (Gigabit-Ethernet) dauert der Scan – sofern nicht parallelisiert – ca. 37 Stunden. Wird der Scan um den Faktor 10 parallelisiert, ist er in 3,7 Stunden fertig. Selbst der komplette Scan eines etwas größeren IPv4-Netzes ist kein gigantisches Problem.

Und dann kam IPv6.

Nachdem der Adressraum bei IPv6 128bit beträgt, im Gegensatz zu 32bit bei IPv4, sind die Netze wesentlich größer. Gehen wir einmal von einem kleineren /56 IPv6-Netz aus. Das sind gerade einmal 9.223.372.036.854.775.808 Adressen. Also knapp 10^19 Adressen. Selbst wenn man nun auf einen vollständigen Scan verzichtet und nur einen Ping-Sweep zur Erkennung der Live-Hosts nutzt, sind das immernoch 10^19 Anfragen, die verschickt werden müssen. Nehmen wir an, wir verschicken (unrealistischer Weise) 100.000 Anfragen gleichzeitig, die alle in 1ms beantwortet werden. Wie lange dauert dann nur ein simpler Ping-Sweep über ein /56-Netz? 10^11 Sekunden bzw. 27.777.777 Stunden bzw. 1.157.407 Tage bzw. 3.170 Jahre. Ein Scan über ein komplettes „kleines“ IPv6-Netz – unmöglich!

Es gibt zwar verschiedene statische Häufungen, wie Netzwerk-Administratoren IPv6-Adressen vergeben, aber selbst die Berücksichtigung beliebter Bestandteile von IPv6-Adressen wie „:dead:“, „:b00b:“, „:cafe:“ oder „:babe:“ schränkt die Auswahl nicht zuverlässig genug für einen Penetrationstest ein.

Ein anderer Ansatz ist das Sniffen des gesamten IPv6-Verkehrs über Mirror/Monitoring-Ports an zentralen Core-Switche über eine gewisse Dauer. Das setzt natürlich nicht nur die grundsätzliche technische Möglichkeit voraus, sondern auch die Kooperation des Unternehmens. Sofern man einmal betriebliche oder datenschutzrechtliche Bedenken außen vor lässt – Datenschutzbeauftragte (Abgreifen von personenbezogenen Daten) und Betriebsräte (Achtung mögliche Leistungskontrolle) werden das in der Praxis sicherlich zu verhindern wissen. Technisch grundsätzlich möglich, ob wirklich umsetzbar sei einmal dahingestellt.

Bleibt eigentlich nur noch eine Liste mit IPv6-Adressen von den Administratoren des Zielnetzwerks zu erfragen. Idealerweise wird der Bestand von Hosts und verwendeten IP-Adressen in irgendeiner Datenbank oder Datei gepflegt. In wie weit solch eine Liste vollständig ist, kann man naturgemäß von außen nicht wirklich beurteilen. Es bleibt nur noch übrig, diese Liste mit möglichen weiteren IP-Adressen zu ergänzen, die man z.B. durch DNS Enumeration o.ä. gewinnen kann.

Egal wie, absolut vollständige Penetrationstests von IPv6-Netzwerken sind fast unmöglich zu garantieren. Ein Penetrationstests von IPv6-Netzwerken kann vollständig sein, muss er aber nicht. Das schlimmste daran ist, dass man nicht wissen wird, ob ein Test nun alle Hosts betrachtet hat oder nicht.

First Car-Hacking: Tesla S

Leave a Comment

Endlich, es hat auch lange gedauert. Stimmen die Bericht auf SPON und in der FAZ, ist es chinesischen Studenten gelungen über eine Schwachstelle in einer Handy-App zur Fernsteuerung des Autos einen Tesla S während der Fahrt zu hacken: Lampen einschalten, Schiebedach öffnen & mehr.

Warum muss man eigentlich alles aus dem Internet fernsteuern können? Und muss ich wirklich mein Auto per App steuern können? Ist das wirklich die Welt, in der wir leben wollen: Haustür per App öffnen/verschließen, per App den Ofen anschalten, das Auto öffnen/schließen, die Waschmaschine starten?

Sicher, es ist bequem. Und was passiert, wenn einem das Smartphone gestohlen wird? Per Passwort-Reset über das auf dem Handy eingerichtete Mailkonto können schon die meisten Online-Accounts gekapert werden. Zukünftig wird dann noch das Auto übernommen oder gleich das Haus als Party missbraucht, wenn man im Urlaub ist.

Dabei können Hacker zukünftig über die Fernsteuerung von Autos noch viel mehr Schäden anrichten: Anonyme Morde & terroristische Attacken per Car-Hacking? An den Meistbietenden zu verkaufen. Ich hoffe zwar, dass die Autoindustrie aus diesen akademischen Hacks am Telsa S schnell genug lernt und in allen Bereichen der Fahrzeugentwicklung IT-Sicherheit einen sehr hohen Stellenwert bekommt, aber ich glaube nicht daran.

Und dabei gibt es noch ganz andere Herausforderungen: Sicherheitsupdates beim Auto! Wie lange werden Autos zukünftig mit Updates versorgt? Wie schnell werden sie ausgeteilt? Was passiert bei Software-Bugs durch das Update? Patch-Day am 1. Mittwoch des Monats bei Tesla? Gruselige Vorstellung.

Es wird sicherlich noch eine Zeit dauern, bis Autos nicht nur ständig online und per App steuerbar sind, sondern diese Features auch in den Massenmarkt kommen. Hoffentlich lernt die Autoindustrie aus den Fehlern anderer, bevor sie sie selbst begeht. Am besten werfen sie einfach mal einen Blick auf das Update-Chaos bei Android und gebrandeten Versionen der Mobilfunkprovider. Man darf gespannt sein..

Der Schwachpunkt PCI Compliance über SAQs

Leave a Comment

Grundsätzlich müssen alle Unternehmen PCI DSS erfüllen, die Kreditkartendaten bzw. Karteninhaberdaten weiterleiten, speichern oder in irgendeiner anderen Art und Weise verarbeiten. Dies bezieht sich insbesondere auf die vollständige PAN (Personal Account Number), d.h. der Kreditkartennummer sowie auf die weiteren Authentifizierungsdaten des Karteninhabers  wie z.B. Prüfsumme und PIN. Die Anforderungen sind grundsätzlich für alle Unternehmen gleich.

Allerdings gibt es enorme Unterschiede im Nachweisverfahren der PCI DSS Compliance, also im Nachweis der eigenen Konformität zum Standard. Das Nachweisverfahren unterscheidet sich zwischen VISA, MasterCard & Co zwar teilweise im Detail, jedoch ist es im Groben identisch. Ausgehend von VISA Europe[1] muss ein Händler (Merchant) seine PCI DSS Compliance durch einen unabhängigen Auditor (QSA – Qualified Security Assessor) nachweisen lassen, wenn er jährlich über sechs Millionen VISA Transaktionen abwickelt. Er ist in diesem Fall ein sogenannter Level 1 Merchant und muss einen Vor-Ort-Audit in Auftrag geben, bezahlen und  auch erfolgreich abschließen. Unterhalb der Grenze von sechs Millionen Transaktionen entfällt dieser Nachweis. Ab diesem Merchant Level 2 reicht das Ausfüllen und Unterschreiben eines Selbstfragebogens (SAQ – Self Assessment Questionnaire) – ein unabhängiger Audit ist nicht mehr notwendig. Der Merchant attestiert sich sozusagen selbst die PCI DSS Compliance.

Es gibt verschiedene SAQs – SAQ A, C-VT, C und D – wobei ein Merchant in einem SAQ A bestätigt, dass er hat niemals eine digitale Zugriffsmöglichkeit auf die PANs & Co besitzt. SAQ D ist die maximale Steigerung und beinhaltet alle PCI DSS Anforderungen.

In beiden Fällen (Merchant Level 1 und Level 2) muss der Merchant zusätzlich noch einen externen Schwachstellen-Scan bei einem vom PCI Council akkreditierten ASV (Approved Scanning Vendor)  durchführen lassen und ihn ohne pci-relevante Schwachstellen bestehen. Dieser Scan besitzt meiner Meinung nach allerdings keine hohe Aussagekraft: Er kann nur offensichtliche Schwachstellen von außen finden. Zusätzlich lässt sich ohne kompletten Review der IT auch nur sehr schwer beurteilen, ob wirklich der gesamte Adressbereich geprüft wurde.

Gerade Merchants, die selbst Zugriff auf die PAN haben möchten und / oder ihre Zahlungsabwicklung nicht komplett outsourcen wollen, stehen prinzipiell vor der Wahl:

Die technischen, organisatorischen, personellen und damit auch finanziellen Herausforderungen des PCI DSS annehmen oder ein (in der Tat erhebliches) Risiko akzeptieren und den SAQ C-VT, C oder D nicht wahrheitsgemäß ausfüllen.

Das SAQ-Verfahren ist für Merchants sicherlich kostengünstig, stellt aber ein großer Schwachpunkt in der nach unten verzweigten Kette der PCI DSS Compliance dar. Selbst wenn der Merchant eine korrekte Compliance beabsichtigt, braucht er unabhängige interne Kontrollverfahren zur Sicherstellung der Compliance. Die müssen zudem tatsächlich wirksam sein.

Ich halte grundsätzlich einen unabhängigen Audit oder das komplette outsourcen der Zahlungsabwicklung an einen Dienstleiter für sinnvoller. Die SAQs sind eine nicht kalkulierbare Schwachstelle im Nachweisverfahren der PCI DSS  Compliance.

[1] http://www.visaeurope.com/en/businesses__retailers/payment_security/merchants.aspx

Deutschland entdeckt die Spionageabwehr

Leave a Comment

Wir schreiben das Jahr 1999. Die deutsche Regierung möchte ihre nachrichtendienstliche Abwehr aufrüsten: Jetzt soll in IT-Sicherheit investiert werden. Unser Außenministerium, unser Verteidigungsministerium und unser Justizministerium sollen ihre interne Kommunikation auf Sicherheitsmängel prüfen lassen. Und als besondere Maßnahme will der NSA-Ausschuss eine Schreibmaschine zur Spionageabwehr nutzen.

Moment. NSA-Ausschuss? Wir sind ja schon in 2014. Macht nix. Die technologische Entwicklung kann ein deutscher Nachrichtendienst auch einmal verschlafen. Die anderen Behörden sind ja auch nicht besser. Wir prüfen im Jahr 2014 einmal grundsätzlich, wie sicher die IT unserer Volksvertretung ist. Derweil wird in Untersuchungsausschüssen wieder die Schreibmaschine benutzt. Tolle Leistung.

Unsere Regierung sollte über einen „Beauftragter der Bundesregierung für Informationssicherheit“ nachdenken. Wir haben welche für die IT und für den Datenschutz. Aber einen CISO in oder unterhalb der Bundesregierung haben wir keinen.

Wahlpflichtfach „PCI DSS“ an der FH Brandenburg im Studiengang Security Management

Leave a Comment

Ich hatte vor einigen Monaten der Studiengangsleitung vom Master-Studiengang Security Management (Fachhochschule Brandendburg) angeboten, ein Wahlpflichtfach über den Payment Card Industry Data Security Standard (PCI DSS) zu halten. Das wurde nun angenommen und so wie es aussieht, soll es im nächsten Wintersemester im Dezember als Blockveranstaltung stattfinden. Ich hoffe, dass es klappt und freue mich darauf, dem Studiengang etwas zurückgeben zu können, bei dem ich selbst meinen Master gemacht habe.

Nervige Personalagenturen: Projektangebote als PHP- oder Python-Entwickler bei IT-Sicherheitsexperten

Leave a Comment

Liebe Personalagenturen,

ich bin Information Security Consultant. Ich bin kein PHP- und/oder Python-Entwickler. Wie viele andere IT-Professionals kann ich Software programmieren bzw. entwickeln. Auch in den Programmiersprachen PHP und Python. Ich bin dennoch kein Entwickler. Trotzdem bekomme ich regelmäßig per E-Mail-Anfragen als Freelancer für PHP bzw. Python, nur weil ich diese in meinem Profil unter Programmierkenntnisse aufgelistet habe.

Anscheinend wird einfach per Suchfilter in den Profilen nach Schlagwörtern gesucht und massenhaft E-Mails versendet. Das eigentliche Profil scheint sich dann niemand mehr anzusehen. Bei den Margen einer erfolgreichen Vermittlung ist das anscheinend auch zu viel verlangt. Schreibt man dann die Versender der E-Mails an, mit der Bitte solche Projekte nicht mehr zu schicken, erhält man eine sehr professionelle Reaktion: Nämlich gar keine. Eine 1A-Leistung.

Recht lustig ist es dafür, von mehreren Vermittlern derselben Agentur kontaktiert zu werden. Doppelt hält besser? Ach, drei- oder vierfach ist noch besser. Sinn? Unsinn? Eigentlich nur noch nervig.

Nachdem ich noch Geschäftsführer eines Beratungsunternehmens bin, bekomme ich auch ungewollt Profile von Bewerben geschickt. Witzig ist diese Pseudo-Anonymität. Als ob es nicht Google, LinkedIn und Xing gäben würde. Die Informationen in einem anonymen Lebenslauf sind oft vollkommen ausreichend, um die Person zu identifizieren.

Personalagenturen = nervig? Sicher nicht alle, aber das Niveau könnte insgesamt deutlich steigen. Hauptsache Umsatz generieren und Personal wie Vieh anbieten, schreckt mich eher von einer Zusammenarbeit ab.

Mit freundlichen Grüßen,

Patrick Sauer

Master of Science in Security Management
Diplom Wirtschaftsinformatiker (FH)
Certified Information Systems Security Professional (CISSP)
Certified Information Security Manager (CISM)
Offensive Security Certified Professional (OSCP)
TeleTrusT Information Security Professional (T.I.S.P.)
ISSECO Certified Professional for Secure Software Engineering (CPSSE)
Datenschutzbeauftragter DSB-TÜV

Vortrag beim T.I.S.P Community Meeting 2014 in Berlin

Leave a Comment

Ich hatte einen Vortrag für das T.I.S.P Community Meeting 2014 in Berlin eingereicht. Er wurde akzeptiert und ist nun auch im offiziellen Programm.  Ich werde über die  Schwächen im PCI DSS (Payment Card Industry Data Security Standard) referieren. Am Montag 03.11.14 um 14:00 Uhr auf dem T.I.S.P. Community Meeting 2014. Ich hoffe auf zahlreiche Zuhörer und freue mich auf eine interessante Diskussion im Anschluss. Ich werde den Vortag später hier als PDF veröffentlichen.

Der TrueCrypt-Selbstmord

Leave a Comment

Unter truecrypt.sourceforge.net warnt das Projekt vor dem Einsatz der eigenen Software:

WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues

This page exists only to help migrate existing data encrypted by TrueCrypt.
The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP. [..]

Die alten Softwareversionen wurden entfernt und die aktuelle Variante von TrueCrypt erlaubt nur noch das Entschlüsseln von existierenden Datenträgern. Die digitale Signatur der aktuellen Software ist echt. Entweder ist das ein grandioser Hack oder das Projekt hat aufgegeben. Im Netz kursieren die ersten Gerüchte, dass dahinter in irgendeiner Form die NSA oder andere Geheimdienste stecken sollen. Ob das stimmt, wird sich eher nicht bestätigen lassen.

Aktuell kann man nur annehmen, dass die Entwicklung von TrueCrypt eingestellt wurde. Nachdem die Software nicht unter einer freien Lizenz steht, kann das Projekt nicht geforkt werden. Somit können auch keine Security-Fixes mehr veröffentlicht werden.

TrueCrypt scheint Selbstmord begangen zu haben.

Ping Flood gegen Quizduell in der ARD

Leave a Comment

Eigentlich hat es mich nicht interessiert: Quizduell in der ARD mit Jörg Pilawa. In der Show sollte versucht werden, die Zuschauer über eine eigene App interaktiv mit raten zu lassen. In der ersten Sendung brach die IT zusammen. Danach wurden noch Berichte von einem Datenleck mit 50.000 Nutzern laut. Jetzt stoß ich zufällig im Zappen darauf.

Am Anfang der dritten Sendung wurde nun veröffentlicht, dass man einer DoS-Attacke ausgesetzt war, die über viele SSH-Agents mittels ping requests ausgelöst wurde Die Aussage hat sich Herr Pilawa von der eigenen IT geben lassen. Mich würde interessieren, woher die das mit dem SSH haben und welche Rolle das bei einem Ping Flood spielen soll. Also zumindest soll die Leitung dicht gemacht worden sein.

Dann entschuldigte sich Pilawa noch, dass auch sie einen Fehler gemacht haben. Durch die Verknüpfung von Daten wie Wohnort oder Geschlecht sollten Auswertungen vollzogen werden, ob sich statistische Merkmale in der Beantwortung von richtigen oder falschen Fragen ableiten lassen. Das habe die Server überlastet.

Also wir lassen uns lahmlegen durch einen relativ unspektakulären Ping Flood und sorgen durch falsch dimensionierte Hardware noch dafür, dass auch ohne den DoS nichts funktionieren würde. Weil das aber noch nicht genug ist, bauen wir noch ein Datenleck ein, sodass Unbefugte Zugriff auf personenbezogene Daten erhalten können.

Die gesamte Leistung wurde von unseren Rundfunkbeiträgen bezahlt. Anscheinend ist der Rundfunkbeitrag noch nicht hoch genug, sodass man sich keinen vernünftigen Dienstleister hat leisten können.