IT-Sicherheit und Zufallszahlengeneratoren – II

Im Jahr 2013 hatte ich einen Artikel zur Bedeutung von Zufallszahlen-Generatoren geschrieben. Vor kurzem habe ich dazu eine Mailkommunikation mit einem interessierten Leser führen dürfen, der sich selbst mit hardware-basierten Zufallszahlengeneratoren für IT-Systeme befasst. Dadurch wurde ich motiviert, dieses Thema mal wieder aufzugreifen.

Wir hatten im Artikel
IT-Sicherheit und Zufallszahlengeneratoren – I
festgestellt, dass die Qualität von Zufallszahlen als Element von Sicherheitsverfahren im Besonderen dann größte Bedeutung zukommt, wenn der Algorithmus von Sicherheitsverfahren bekannt ist. Dies gilt typischerweise für Open Source Programme, ist aber auch für viele technische Krypto-Verfahren von Bedeutung.

Ein Beispiel liefert etwa SSL/TLS. Zufallszahlengeneratoren müssen hier qualitativ hochwertige und nicht vorhersagbare statistische Element einstreuen. Dies ist einer der Gründe dafür, warum im Bereich der Herstellung von Software, die gezielt SSL/TLS-basierte Krypto- und Sicherheitsverfahren nutzt, hochwertige SW-Bibliotheken für die Generierung von Zufallszahlen zum Einsatz kommen. OpenSSL-Bibliotheken wären aber auch für Entwickler gewöhnlicher SW- und Web-Anwendungen von großem Interesse.

So würde man sich z.B. als Web-Entwickler freuen, wenn man derartige Bibliotheken auch im Rahmen von Webhosting-Angeboten deutscher Provider nutzen könnte. Mindestens im Jahr 2013 war das aber im Rahmen der Hosting-Angebote der marktdominanten Unternehmen (für Web-Hosting mit PHP-Unterstützung) nach eigener Recherche nicht der Fall.

Dieser Artikel beleuchtet ein wenig die Frage: Warum stellt dieser Zustand ein Problem dar? Wir erläutern dies am Beispiel der Entwicklung von Web-Anwendungen unter PHP. Zur Vertiefung für interessierte Leser verweisen wir unten explizit auf eine Website, die sich der Sicherheit unter PHP widmet, die aber auch für Nutzer anderer Programmiersprachen wie Java und interessierte Anwender von Web-Applikationen von Interesse sein dürfte.

Defizite von PRNGen in der Web-Programmierung am Beispiel PHP

Viele Web-2.0-Applikation beruhen auf der Programmiersprache PHP. Das betrifft u.a. Foren, Blogs, Gästebücher, Diskussionsplattformen, Bug-Tracker, etc.. PHP eignet sich daher gut als Beispiel für die Diskussion der Schwächen von PRNG-Bibliotheken.

Viele der genannten Verfahren setzen im Rahmen von Anmeldungen und/oder der Absendung von Beiträgen sog. Captcha-Verfahren mit zufällig generierten Zahlen und/oder Textsequenzen/Aufgaben ein, um Spammer abzublocken. Nun sind Entwickler meist bequeme Menschen - und setzen daher auf Software-PRNGs, die die PHP-Standardbibkliotheken anbieten.

Lassen sich darauf ohne weitere Zusatzmaßnahmen sichere Verfahren aufbauen? Die Antwort ist eindeutig: Nein!

Für PHP-Kundige aber auch andere Mitmenschen, die sich für die Sicherheit von Web-Applikationen interessieren, möchte ich in diesem Zusammenhang explizit den sehr guten und hinreichend tiefgehenden Artikel

 
(wie auch andere ergänzende Artikel der Website

 
empfehlen. Der genannte Artikel zeigt Einsatzgebiete von SW-PRNGen auf, er analysiert das Thema "unzureichende Entropie der Zufallszahlenverteilung" und leitet daraus einige wirksame Angriffsverfahren ab.

Ausgeführt wird dankenswerterweise auch, dass ein Mix von (deterministischen) mathematischen Konversionen (wie etwa Hashing) oder die Kombination mehrere PRNGs überhaupt nichts nutzt, um unzureichende Entropie zu kompensieren. Schon gar nicht im Fall von Open Source-Software ....

Im Gegensatz zur Meinung von etlichen Entwicklern macht der Artikel auch darauf aufmerksam, dass Verfahren, die auf dem bekannten "Mersenne Twister"-Algorithmus aufbauen (wie mt_rand()), ohne hinreichende Qualität und "Entropie" von Seeds keineswegs als sicher gelten können. Als Konsequenz fordert der Artikel u.a zwingend den zusätzlichen Einsatz von hochwertigen OpenSSL-Erweiterungen oder anderen Quellen hoher Entropie für die Zufallszahlen-Generierung.

Nun ist es leider aber so,

  1. dass die OpenSSL auf dem Ziel-Webserver der PHP-Web-Anwendung installiert sein muss
  2. und das die PHP-Module gegen die SSL-Bibliotheken compiliert und gelinkt sein müssen.

Das ist in den wenigsten Webhosting-Angeboten der Fall. Evtl. auch aus rechtlichen Gründen. So ist man als Entwickler von hochsicheren Lösungen eigentlich fast immer darauf angewiesen, mit eigenen Servern (oder gehosteten Root-Servern) zu arbeiten.

Wir lernen aus dem obigen Artikel jedenfalls, dass Software, die ihre Sicherheitsverfahren auf PRNGen ohne hinreichende Qualität (= "hohe Entropie") von Zufallselementen (Seeds) aufbaut, mathematisch kundigen Angreifern Tor und Tür öffnen kann. Das gilt natürlich nicht nur für die Sprache PHP, sondern auch andere web-relevante Sprachen wie etwa Java oder Ruby.

Sie glauben dennoch, das Thema sei so speziell, dass es in der täglichen Praxis wohl keine Rolle spielen dürfte?

Ein Beispiel aus der Praxis

Wir mussten selber im Rahmen der Implementierung einer Website für einen Kunden, in die ein beliebtes OpenSource Gäste-Buch (auf PHP-Basis) integriert war, erfahren, wie angreifbar PRNG-basierte Sicherheits-Verfahren sein können.

Das Gästebuch nutzte Captcha-Verfahren im Rahmen des Absendens von Beiträgen. Der User musste zufällig generierte und grafisch verzerrt dargestellte Zahlensequenzen beim Abschicken eines Beitrags in ein Formularfeld eingeben. Leider mussten wir feststellen, dass nach einer Weile das Spam-Aufkommen so zunahm, dass wir selbst mit zusätzlichen Text- und Ausdrucksfiltern der Flut nicht mehr Herr werden konnten. Wir hatten es mit einem typischen Fall eines erfolgreichen Angriffs auf die Schwäche von PHP-PRNGen (gemäß eines der Muster aus dem oben genannten Artikel) zu tun.

Wir haben deshalb den Code des Gästebuchs analysiert und letztlich festgestellt, dass die Captcha-Sequenzen nach einer statistischen Analyse tatsächlich vorhersagbar waren. Hierzu reichte eine überschaubare Anzahl von ca. (maximal) 60 Millionen Versuchen zur Seed-Sequenz-Prüfung. Die Analyse ließ sich locker in kürzester Zeit auf einem Laptop bewerkstelligen.

Ein typischer Fall von unzureichender Entropie. Wir änderten das Captcha-Verfahren dann selbst ab - und zwar

  • erstens mit Methoden, die dem Angreifer unbekannt waren
  • und zweitens mit eine Quelle für Seeds hoher Entropie.

Und siehe da: die Anzahl durchkommender Spams ging massiv zurück und hielt sich im Rahmen von Zufallstreffern im Promille-Bereich der Versuche.

Besonders lustig fanden wir, dass wir nach einer Weile tatsächlich auch noch eine Reaktion eines frustrierten Spammers im Rahmen abgewiesener, aber in einem Log-Bereich gespeicherten Beitragsversuches erhielten: Der Autor stellte eingerahmt in eine Reihe von Vulgärausdrücken fest, dass wir das Captcha-Verfahren wohl modifiziert hätten. Er glaube aber immer noch an das Potential seiner statistischen Analysen und würde das geänderte Verfahren früher oder später doch knacken. Er habe gerade nur keine Zeit ...

Hier sieht man mal, mit welchen Methoden in der Spammer-Szene gearbeitet wird.

Nun hatten wir den Vorteil, 2 Maßnahmen kombinieren zu können, von denen eine dem Prinzip von Open Source direkt zuwider lief. Ein Open Source Entwickler muss hingegen vollständig auf hohe Entropie von eingesetzten Zufallszahlen setzen.

OpenSSL unter UNIX/Linux als betroffenes Beispiel unzureichender Seed-Qualität

Trotz der Empfehlungen des oben erwähnten Artikels, der die Flankierung von PHP Software-PRNGen durch OpenSSL-Zufallsgeneratoren für Seeds empfiehlt, kann man mal die Frage stellen:

Wie sicher ist eigentlich OpenSSL selbst im Praxiseinsatz? Diese Frage ist deshalb von Bedeutung, weil es hier um den Kern sicherer Kommunikation mit Webseiten im Internet geht.

Für eine kritische Haltung muss man gar nicht mal auf den Heartbleed-Bug zurückgreifen oder gar Backdoors im (RSA-) Algorithmus vermuten:

 

Ein sehr schöner Artikel zu den diesjährig bekannt gewordenen grundlegenden Schwächen ist folgender:

 

Nach Meinung von Fachleuten führ(t)en aber schon sehr viel trivialere Umstände in der Praxis zu erheblichen OpenSSL-Schwächen. Folgender Artikel zeigt, dass auch die Entropie von OpenSSL unter bestimmten Umständen durch eine falsche Wahl von Seeds selbst wieder zu gering werden kann:

Auch der OpenSSL-Generator muss mit Seeds hinreichender Qualität versehen werden. Prozess IDs als Zusatz-Seed, auf die zumindest frühere OpenSSL-Implementierungen unter UNIX/Linux zurückgriffen, erweisen sich in diesem Zusammenhang interessanterweise und überraschenderweise als untauglich.

Dieses Beispiel zeigt, wie intrikat und kompliziert das Zusammenspiel von PRNG-Algorithmen und statistischen Seeds in einem konkreten Betriebssystem-Umfeld werden kann. Nicht gerade beruhigend? Der folgende Artikel befasst sich auch mit der damaligen OpenSSL-Schwäche und vertritt - wie ich - die Meinung, dass gerade wegen solcher Probleme Open Source wichtig ist:

 

Genug für heute. In einem weiteren Beitrag

IT-Sicherheit und Zufallszahlengeneratoren – III

werfen wir einen Blick auf einige weitere sicherheitsrelevante Verfahren, die eine hohe Qualität von Zufallszahlen erfordern.

Philosophische Fragen

Wie schon im letzten Blog-Artikel zu diesem Thema lassen wir den Leser mit ein paar "philosophischen" Fragen zurück:

Gehört es nicht zur Aufgabe einer modernen Staatsverwaltung, der heutigen Informationsgesellschaft, die den Staat trägt, einen (Web-) Service anzubieten, über den Entwickler und die Wirtschaft bei Bedarf kostenfrei ganze (verschlüsselte) Dateien mit hochwertigen Zufallszahlen abrufen können? Wäre ein solches Angebot nicht im nationalen Interesse? Eine Institution für ein solches öffentliches Angebot wäre in Deutschland etwa das BSI.
 
Natürlich fallen einem sofort zwei Fragen ein, die kritische Zeitgenossen aus zwei unterschiedlichen Perspektiven zu einem solchen Angebot stellen könnten:

  • Kann man einer solchen (staatlichen) Quelle von Zufallszahlen trauen? Unter welchen Voraussetzungen?
  • Kann dieses Angebot nicht auf von bösen Zeitgenossen genutzt - besser: missbraucht - werden? Wie sähe die Nutzen/Schadens-Bilanz aus?

Viel Spaß beim Nachdenken!

Peer-to-Peer-Software, UDP, Firewall Hole Punching, Skype – Sicherheitsrisiken

Na, das war ja klar. Nach dem Beitrag zur Netzwerk-Misere im Bundestag wurde ich von Bekannten natürlich gefragt, warum ich ausgerechnet das auch von ihnen geliebte und viel genutzte Skype als potentielles Problem erwähnte. Man müsse ja wohl Software von großen Herstellern vertrauen können. Tja, ....

Das ist nun wirklich eine sehr unangenehme Frage. Aber eine, der sich zumindest professionelle Netzwerk-Administratoren ggf. ausgesetzt sehen, wenn sie im Rahmen einer Risikoanalyse und Risikobewertung für sicherheitsrelevante Netzwerkbereiche in ihrem Unternehmen das komplette Spektrum potentieller Gefahren erfassen wollen.

Trauen wir einer Software, die gezielt von innen Löcher in NAT Firewalls bohrt? Die aufgrund von Schwächen des UDP-Protokolls dann von irgendwelchen (!) externen Systemen und nicht nur vom Zielsystem unserer Kommunikation angesprochen werden kann? Die potentiell in der Lage ist, Daten von innen nach außen und von außen nach innen zu transportieren, ohne dass wir den Prozess im Detail kontrollieren könnten, gerade weil die Übertragung verschlüsselt erfolgt?

Was geschieht, wenn eine solche Software einmal über Exploits von Dritten für unlautere Zwecke genutzt werden kann? Überwiegt der potentiell mögliche Schaden wirklich den Nutzen, den eine Kommunikations-Software vom Schlage Skype unzweifelhaft mit sich bringt? Hinzu kommen die aktuellen Nutzungsbestimmungen von Microsoft, die sich jeder Systemadministrator und Sicherheitsverantwortlicher genau zu Gemüte führen sollte, das sie das Mitschneiden und Speichern der Kommunikationsinhalte potentiell zulassen. Vertraut man seine Kommunikation einem SW-Provider an, der sie ggf. irgendwo (im Ausland) und unter ungeklärten Sicherheitsvorkehrungen speichert?

Ich kann diese Fragen natürlich nicht pauschal beantworten. Es geht auch nicht speziell um Skype, sondern mehr um die Tatsache, dass eine ganze Reihe moderner Kommunikations- und auch Games-Softwarelösungen für Peer-to-Peer-Verbindungen [P2P-SW] gezielt so programmiert wird, dass sie (NAT-) Firewalls aushebeln. Dazu gibt es haufenweise Artikel im Internet - auch aus dem Bereich der Forschung. Also im Klartext:

Es gibt viele kluge Köpfe, die sich intensiv und erfolgreich Gedanken dazu machen, wie man mittels geschickt programmierter Peer-to-Peer-Software im IT-Alltag Firewalls umgehen und Verbindungen zu anderen Systemen, die ebenfalls durch Firewalls geschützt sind, aufbauen kann. Und ferner: Wie man einmal von innen eröffnete UDP-Kommunikationskanäle auch von anderen äußeren Systemen als dem vom Nutzer angewählten Kommunikations-Zielsystem für Dialoge mit der innerhalb der Firewall befindlichen SW nutzen kann?

Ich finde, man kann sich diese Tatsachen - und was sie im Kern bedeuten - gar nicht oft genug klarmachen, wenn man entsprechende Softwarepakete installiert. Dennoch: UDP-basierte Kommunikationsprogramme können selbst im Firmenumfeld nützlich sein - aber Sicherheit kann es nur geben, wenn man den Code dieser Programme kennt, ihnen daher wirklich vertrauen kann und die Kommunikation gezielt auf bestimmte Target-Systeme begrenzen kann.

Der geneigte Leser erkennt sicher, dass im professionellen Umfeld die Frage des Einblicks in den Source Code eine entscheidende Rolle bei der Risikobeurteilung spielen wird. Ist dieser Einblick nicht gegeben, so hat man es - schon aufgrund der UDP-Schwächen - mit einem potentiellen Risiko zu tun, das zumindest im Rahmen einer Sicherheitsstrategie für Unternehmen bewertet werden muss.

Ich denke, es ist im Rahmen dieses Blogs legitim, den Blick auf diese Tatsache zu lenken.

Eine Maßnahme zur Begrenzung von Risiken im Firmenumfeld kann ja z.B. sein, dass man bestimmte abgeschottete Netzwerkbereiche oder autonome Hochsicherheitsnetze etabliert, dort P2P-Software vom Schlage Skype gar nicht oder nur für bestimmte Zielsysteme zulässt und generell UDP-basierte (ausgehende) Verbindungen sperrt.

Ein weiterer Punkt ist der, dass ein Befassen mit populärer Software, die gezielt Firewalls umgeht, das Bewusstsein dafür schärfen kann, mit welchen Methoden platzierte Trojaner nach einem erfolgreichen Angriff u.a. arbeiten werden - und wie man im Ernstfall damit umgehen muss. In diesem Sinne ist es aus Sicherheitsperspektive durchaus sinnvoll, sich mit Firewall Hole Punching und Skype-ähnlicher Software, die z.B. STUN-Techniken benutzt, auseinanderzusetzen. Für diejenigen, die sich intensiver damit befassen wollen, habe ich nachfolgend ein paar Links zusammengestellt.

Dass auch manche Regierungen der westlichen Welt sich zu Recht intensiv mit dem Thema P2P-SW und u.a. auch Skype auseinandersetzen, zeigt u.a. der erste Link. Den dortigen Ausführungen ist kaum etwas hinzuzufügen. Ich gehe davon aus, dass auch meine Bekannten nach der Lektüre besser verstehen, warum ich das Thema im vorletzten Artikel ansprach.

Überblick über Risiken
http://www.ncsc.govt.nz/assets/NCSC-Documents/NCSC-Skype-Guidance-1.1.pdf
http://www.scip.ch/?labs.20140918

Technik und Risiken
https://www.rfc-editor.org/pdfrfc/rfc5128.txt.pdf

Hinweise auf spezielle Risiken
http://www.networkworld.com/article/2220923/microsoft-subnet/skype-exploits--i-know-where-you-are--what-you-are-sharing--and-how-to-best-stalk-y.html
http://www.makeuseof.com/tag/researchers-discover-skype-flaw-lets-hackers-track-news/

Informationen für Administratoren vom Hersteller
http://download.skype.com/share/business/guides/skype-it-administrators-guide.pdf
http://kirils.org/skype/stuff/pdf/2006/guide-for-network-admins-30beta.pdf

Einführende Artikel über die Umgehung von NAT Firewalls
http://www.heise.de/security/artikel/Wie-Skype-Co-Firewalls-umgehen-270856.html
http://www.h-online.com/security/features/How-Skype-Co-get-round-firewalls-747314.html
http://resources.infosecinstitute.com/udp-hole-punching/
http://www.it-administrator.de/lexikon/udp_hole_punching.html
http://www.cyberciti.biz/tips/howto-linux-iptables-bypass-firewall-restriction.html

Mehr Theorie
http://www.mi.fu-berlin.de/inf/groups/ag-tech/teaching/2009-10_WS/S_19510b_Proseminar_Technische_Informatik/fehrmann10you_slides.pdf
http://archive.cone.informatik.uni-freiburg.de/teaching/lecture/peer-to-peer-w12/slides/p2p12-16.pdf
https://www.goto.info.waseda.ac.jp/~wei/file/wei-apan-v10.pdf

Ausblick
https://www.iab.org/wp-content/IAB-uploads/2014/12/semi2015_huitema.pdf

Gefahr durch unzureichende Analyse ausgehender Netzwerk-Verbindungen

In einigen früheren Artikeln dieses Blogs hatte ich u.a. angedeutet, dass auch der Analyse und dem Unterbinden ausgehender Verbindungen von einem PC oder erst recht von einem Server im eigenen Netzwerk große Bedeutung zukommt. Das gilt für Verbindungen zu Zielpunkten im IT-Netzwerk - vor allem aber zu Systemen im Internet.

Die aktuelle Untersuchung eines der Servers der Partei "Die Linken" im Bundestag - siehe

https://netzpolitik.org/2015/digital-attack-on-german-parliament-investigative-report-on-the-hack-of-the-left-party-infrastructure-in-bundestag/

- zeigt nun gerade, dass ein systematisches Verhindern von ausgehenden Verbindungen zumindest eine bestimmte Malware, die dort als Teil der Attacke auf das Netzwerk des Bundestages beschrieben wurde, in ihrer Wirksamkeit beschränkt hätte. Ich finde das doch recht lehrreich.

Leider muss man sagen, dass

  • dass erstens das Thema ausgehender Verbindungen von einigen System-Administratoren unterschätzt wird
  • dass zweitens standardmäßig eingerichtete Firewalls und Security Software sowohl unter Windows als auch Linux diesen Aspekt von Haus aus zu wenig beachten.
  • dass drittens das Aufstellen von Regeln zur Kontrolle ausgehender Netzwerk-Verbindungen sowie das Einbinden von Black/White-Lists zu Ziel-IP-Adressen durchaus anspruchsvoll werden kann.

Im Besonderen erlauben viele Admins grundsätzlich ausgehende HTPPS-Verbindungen auch von Servern, um so automatische und direkte Verbindungen mit Update-Servern im Internet (die ihre IP-Adresse regelmäßig ändern) etablieren zu können. Nicht jeder Admin sieht sich schließlich in der Lage, einen eigenen lokalen Update Server im Hausnetz zu konfigurieren. Und so werden halt Kompromisse geschlossen .... und auch bekannte "böse" Zieladressen der versuchten Verbindungen nicht herausgefiltert.

Neben vielen Security-Produkten für MS Systeme fällt aber z.B. auch die Susefirewall2 in ihrer Standardinstallation dadurch unangenehm auf, dass ausgehende Verbindungen eines Linux-Systems zunächst einmal grundsätzlich erlaubt werden.

Nimmt man wie im letzten Artikel dieses Blogs propagiert, als Admin dagegen den Standpunkt ein, dass ein hinreichend klug geführter (und ausreichend finanzierter) Angriff früher oder später zu einem Eindringen von Malware führen wird, so ist gerade dann eine Begrenzung ausgehender Netz-Verbindungen ein Muss:

  • um aktive Software, die ungewünschte Verbindungen nach außen aufnimmt, zu entdecken
  • und natürlich, um selbige ungewünschten Verbindungen zu verhindern.

Fazit - auch wenn es für den einen oder anderen bereits eine Binsenweisheit sein mag:
Liebe Admins - im Bundestag und anderswo - kümmert euch intensiv um das Eingrenzen ausgehender Verbindungen, nutzt dabei Blacklists für Zielpunkte auch von https-Verbindungen und überlasst die Kontrolle ausgehender Verbindungen keinesfalls allein installierten Standardprodukten.

Wir wollen und können nicht verhindern, dass ein User von einem PC unseres Netzwerks aus im Internet surft. Wir können aber verhindern, dass beliebige Prozesse/Programme von beliebigen Systemen in unserem Netzwerk zu beliebigen Systemen da draußen Verbindungen aufbauen. Auch wenn das deutlich mehr Arbeit erfordert als pauschale Freigaben.