Month: Juli 2014

Der Zertifikats-Kürzel-Irrsinn hinter dem Nachnamen

Leave a Comment

Aus Marketing-Gründen bin ich z.B. bei LinkedIn selbst nicht besser, trotzdem nervt es so etwas in Fachzeitschriften zu lesen (fiktives Beispiel):

Der IT-Sicherheitsexperte Patrick Sauer, MSc, Diplom(FH), CISSP, CISM, OSCP, TISP, CPSSE, DSB-TÜV hat gestern mit seinem Kollegen Max Mustermann, PhD, MSc, CISSP, CISA, CISM und Frau Maxi Musterfrau, CISA, ISMS Auditor/Lead Auditor nach ISO/IEC 27001 nichts bahnbrechendes geschaffen, allerdings mussten die Titel und Zertifikate dringend einmal wieder leicht dezent in den Vordergrund gebraucht werden.

Akademische Abschlüsse wie B.Sc., M.Sc. oder Ph.D. hinter dem Nachnamen – okay. Aber muss man wirklich Zertifikate dahinten setzen? Und dann auch noch mehrere? Ganz ehrlich: Das liest sich in Fließtexten besonders – äh – suboptimal! Eins wäre ja noch ok, man könnte es auch hinter dem Nachnamen in Klammern setzen, aber diese aktuelle Unsitte Security-Zertifikate wie akademische Abschlüsse hinter dem Namen zu führen, ist in manchen Situationen nur noch peinlich.

Aufgrund meines CISM von der ISACA steht bei Post von dieser Organisation in der Anschrift direkt „Patrick Sauer, CISM“. Manchmal frage ich mich, was mein Postbote wohl denken muss. Ich sollte beim Briefkasten vielleicht einfach meine gesammelten Zertifikate aufzählen. Hat zwar kaum jemand auch nur eine Idee, was das sein soll, aber irgendwie muss man sich hochkompetent hervorzeigen.

Nur eine Meinung vom IT-Sicherheitsexperten Patrick Sauer, MSc, Diplom(FH), CISSP, CISM, OSCP, CPSSE, DSB-TÜV zur Unsitte Zertifikate hinter den Nachnamen zu setzen…..

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.