Archiv für den Monat: Juli 2014

27 07, 2014

Der Zertifikats-Kürzel-Irrsinn hinter dem Nachnamen

von |27. Juli 2014|Zertifizierung|0 Kommentare|

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…..

26 07, 2014

Penetration Testing von IPv6-Netzwerken

von |26. Juli 2014|Pentest|0 Kommentare|

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.

25 07, 2014

PCI DSS 3.0 – Requirement 6.6 (WAF): Monitoring Only – „Is configured to either block web-based attacks, or generate an alert.“

von |25. Juli 2014|English|0 Kommentare|

Today I was working on a presentation about PCI DSS 3.0. Since a major client of me is an international payment service provider doing credit card transaction, I am quite familiar with PCI DSS 2.0. I have already read the new Standard a few months ago, but today I stumbled about an interesting sentence in the Testing Procedure for PCI Requirement 6.6 (WAF) that makes me wonder about PCI DSS 3.0.

PCI DSS Requirement 6.6 forces companies to either use a Web Application Firewall (or some technical equivalent) or forces companies to perform manual or automated application vulnerability security assessments after every change:

6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
[..]
– Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.

Doing automated application vulnerability security assessment is a little bit tricky and needs a software development team and process on a high maturity level. I assume that most companies comply with Requirement 6.6 by using a Web Application Firewall (WAF). Companies can write their own rule sets for a WAF, use a rule set from the WAF’s vendor or use some rule set from OWASP (OWASP CRS Core Rule Set). Anyway it is useful to activate the blocking / enforcing mode of the WAF to actually prevent attacks. That is industry best practice and is or better maybe was required by PCI DSS when companies deployed a WAF to comply with Requirement 6.6

Despite a lot other changes there is a new sentence in the Testing Procedure of PCI Requirement 6.6, which seems a little awkward. Pay attention to the last sentence:

6.6 For public-facing web applications, ensure that either of the following methods is in place as follows:
[..]
Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows:
– Is situated in front of public-facing web applications to detect and prevent web-based attacks.
– Is actively running and up to date as applicable.
– Is generating audit logs.
Is configured to either block web-based attacks, or generate an alert.

So, I want to repeat it: WAF „Is configured to either block web-based attacks, or generate an alert.” Sorry, but what the fuck? After years of PCI DSS now it is okay to deploy a WAF in monitoring mode. At least it needs to generate alerts…

If found two links on the web, which also states this as a problem. Someone in a high position at Gartner[1] and some slides about PCI 3.0[2]. I tried to clarify this with our QSA Company, but just did a short answer, that a WAF needs to block attacks and no comment to this last sentence in Testing Procedure of 6.6. I decided to write an E-Mail to the PCI DSS Council and hope to get an answer that explains it. I will post the answer, if and once I get one.

For the security of customers’ credit card information I really hope this is some sort of mistake or typing error. Anyway I assume there will be some QSAs out in the world, which will accept a WAF in monitoring mode – It doesn’t matter if it was an error, if PCI DSS is treated like a law text and not correctly interpreted. And if this is no error and done on purpose, I wouldn’t really understand that change of mind in the PCI Council.

[1] http://blogs.gartner.com/anton-chuvakin/2013/11/08/briefly-on-pci-dss-3-0/
[2] https://www.netspi.com/blog/entryid/207/things-not-to-overlook-in-the-new-pci-dss-3-0

10/30/2014: The Council’s response.

23 07, 2014

First Car-Hacking: Tesla S

von |23. Juli 2014|IT-Sicherheit|0 Kommentare|

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..

23 07, 2014

Holidaycheck erlaubt keine Bewertungen ohne erfolgreiche Übernachtung beim Waldhotel Dornröschenshöh

von |23. Juli 2014|Allgemein|0 Kommentare|

Nach meinen sehr negativen Erfahrungen im Waldhotel Dornröschenshöh (Haare im Bett und Rausschmiss nach meiner Kritik) hatte ich eine Bewertung beim Portal Holidaycheck abgegeben. Die wurde anschließend vom Hotelier des Waldhotels Dornröschenshöh beim Portal Holidaycheck bemängelt: Ich hätte gar nicht in dem Hotel übernachtet.

Das ist natürlich korrekt. Soweit kam ich leider nicht. Dass der Hotelier aktiv gegen seine Bewertungen vorgeht und Holidaycheck in solchen Fällen keine Ausnahme ihrer Richtlinien zulässt, finde ich sehr schade:

Sehr geehrter Herr  Sauer,

vielen Dank für Ihre freundliche Rückmeldung per E-Mail.

Damit bleibt Ihre Bewertung mit der ID 13[…] dauerhaft offline.

Bitte beachten Sie, dass eine Hotelbewertung auf unserem Portal generell nur dann möglich ist, wenn auch tatsächlich die volle Leistung (mindestens eine Übernachtung) in Anspruch genommen wurde.

Für weitere Fragen stehen wir Ihnen selbstverständlich gerne zur Verfügung!
Antworten Sie einfach auf diese E-Mail.

Freundliche Grüße vom Bodensee
XXXXXX XXXXX

Muss ich jetzt wirklich erst eine Nacht im Waldhotel Dornröschenshöh bleiben, um es bei Holidaycheck bewerten zu können – ernsthaft? Welche Aussagekraft haben dann Bewertungen bei Holidaycheck und insbesondere von diesem Hotel, wenn nicht alle (Beinahe-)Kunden eine Bewertung abgeben dürfen…

23 07, 2014

Der Schwachpunkt PCI Compliance über SAQs

von |23. Juli 2014|PCI DSS|0 Kommentare|

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

21 07, 2014

Deutschland entdeckt die Spionageabwehr

von |21. Juli 2014|Netzpolitik|0 Kommentare|

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.

19 07, 2014

Waldhotel Dornröschenshöh: Schwarze Haare im Bett & Rausschmiss

von |19. Juli 2014|Allgemein|0 Kommentare|

Normalerweise poste ich nur security-bezogene Themen, aber in diesem Fall möchte ich eine Ausnahme machen. Ich wollte gestern am Edersee 1-2 schöne Tage verbringen. Als Hotel hatten wir das Waldhotel Dornröschenshöh ausgewählt.

Der Empfang war sehr wortkarg, aber noch ok. Danach bin ich direkt zum See. Zurück im Hotelzimmer vom Waldhotel Dornröschenshöh erwartet mich in der Dusche ein sehr offensichtliches langes Haar an der Wand. Okay, kann passieren und man kann es selbst wegmachen. Für 90€ das Doppelzimmer kann man das noch akzeptieren. Fertig mit duschen, geht es ab ans Waschbecken. Wieder Haare. Ob hier eigentlich jemand geputzt hat?

Leicht verärgert gehe ich ans Bett und sehe folgendes:

Waldhotel Dornröschenshöh Haare 1

 

Aber es fällt direkt noch eins auf:

Waldhotel Dornröschenshöh Haare 2
 

Jetzt einmal ernsthaft – ich erwarte schon ein paar Grundlagen in der Hygiene in einem Hotelzimmer.  Lange schwarze Haare fallen auf. Immerhin sind lange Haare keine Schamhaare, bei den anderen kurzen Haaren war ich mir leider nicht sicher.

Zumindest das verdreckte Bett bin ich nicht bereit zu akzeptieren. Ich gehe zur Rezeption vom Waldhotel Dornröschenshöh und erkläre freundlich die Situation und bitte darum, dass ich ein frisches und sauberes Bett bekomme.

Panik bricht aus. Der Familienbetrieb scheint nicht in der Lage zu sein mit dieser Situation umzugehen. Das Zimmer wird besichtigt, ich zeige die Missstände. Es gibt offensichtlich Schwierigkeiten gegen 20 Uhr noch die Putzfrau zu bestellen. Saubere Ersatzzimmer stehen nicht zur Verfügung. Jetzt könnte natürlich das Personal vom Hotel das Bett selbst frisch machen…

Aber was passiert: Ich werde lautstark darum gebeten, sofort das Zimmer zu räumen. Ich habe schon einige Hotelbesuche hinter mir, aber das toppt alles. Ich habe mich nicht über den hässlichen Teppich beschwert oder den kaputten Boden im Eingangsbereich. Ich wollte nur ein sauberes Bett. Das war definitiv zu viel verlangt.

Ich sei ja viel zu pingelig und in München gibt es auch dreckige Zimmer – ich hatte einen Mietwagen von Sixt und komme nicht aus München, egal.  Ich hatte während der Situation mit drei Personen Kontakt – vom Chef bis hin zu den Mitarbeitern durchweg alle unfreundlich und ohne Verständnis. Es wurden Aussagen getroffen, dass Haare in den Zimmern und Betten ja normal seien.

Meine Bewertung nach dieser Erfahrung:
Kundenzufriedenheit Note 6, Hygiene Note 6 und Freundlichkeit Note 6. Nie wieder!