Deutsch | English
Dieser Blog enthält keine offiziellen Aussagen von CERT.at, sondern persönliche Meinungen einzelner Mitarbeiter.
Workaround? Abdrehen!
21. März 2017

Langsam gibt es erste Details zu den 0-days, die im Vault-7-Leak enthalten sind.

Betroffen sind u.A. Switche von Cisco. Patches sind noch nicht für alle Modelle verfügbar, laut Heise gibt es aber folgenden Workaround:

Bis dahin empfiehlt der Hersteller Telnet auf betroffenen Geräte zu deaktivieren und bis zum Erscheinen des Patches auf SSH zu setzen.

Das ist meiner Meinung nach viel zu kurz gegriffen. Wir empfehlen:

  • Wir haben 2017, telnet ist obsolet. Ja, es mag ab und zu noch irgendwelche obskuren Devices geben, die nur telnet können, aber halbwegs aktuelle Switche und Router können schon lange ssh. Wenn das die aufgespielte Firmware nicht kann, dann stehen die Chancen gut, dass diese so alt ist, dass sie noch eine Reihe von weiteren bekannten Sicherheitslücken aufweist. Von telnet auf ssh umsteigen ist daher kein "Workaround", sondern eine längst überfällige Sicherheitsmaßnahme.
  • Management-Plane Protection. Egal ob telnet, ssh oder snmp: kein Router, Switch oder CPE sollte diese Interfaces für das ganze Internet erreichbar haben. Optimalerweise sind diese nur über ein Wartungsnetz per VPN erreichbar, aber auch schon strikte Filter auf Basis Source-IP-Adresse helfen enorm. Barry Greene hat im Rahmen der NANOG eine umfassende Präsentation zum Thema Sicherheit für ISPs erstellt.
Wir überlegen, auf Basis von Scans von Shadowserver die österreichischen ISPs darüber zu informieren, auf welchen IP-Adressen der Telnet-Port erreichbar ist. Betroffen sind aktuell rund 9000 IP-Adressen in Österreich. Input und Feedback dazu ist willkommen!

Autor: Otmar Lendl

Propaganda auf Twitter
15. März 2017

Der echte Groundhog Day ist noch nicht lange her, und manchmal kommt es einem so vor, als wäre im Internet jeden Tag "Groundhog Day": manche Sachen wiederholen sich einfach viel zu oft.

Aktuell geht es um missbrauchte Twitter-Accounts. Das hatte wir schon im November: twittercounter.com hatte ein Problem, und schon werden Tweets unter falschem Namen verteilt. Das gleiche ist gerade wieder passiert, dieses mal wurde pro-türkische Propaganda verteilt. Siehe WebStandard, FuZo, ...

Weil das in den Medien wieder großes Echo findet, hier meine Einschätzung dazu:

Fast immer, wenn es Spannungen zwischen Staaten gibt, versuchen nationalistische "Hackergruppen" im Internet Propaganda für die eigene Seite zu machen und Online-Auftritte der Gegenseite mit virtuellem Graffiti zu beschmieren. Das können "Defacements" auf Webseiten sein, oder eben Einbrüche in Social Media Accounts.

Natürlich wird hier zuerst versucht, möglichst prominente Opfer zu finden. Gelingt das nicht, dann gehen diese Gruppen rein opportunistisch vor: wer halbwegs in das Beuteschema fällt und verwundbar ist, der wird zum Opfer dieser juvenilen Propaganda-Aktionen.

Daher die Empfehlung: Schauen sie auf die Sicherheit ihrer Webseite und ihrer Social Media Accounts! Es wäre doch hinreichend peinlich, wenn unter ihrem Namen Propaganda für nationalistische oder islamistische Gruppen verteilt wird.

Autor: Otmar Lendl

Lernkurve mit neuem Feed
3. März 2017

Wir sammeln aus vielen Quellen Informationen zu Infektionen und anderen Sicherheitsproblemen im österreichischen Internet und geben diese an die Netzbetreiber weiter. Details dazu stehen in unserem Jahresbericht.

Kürzlich haben wir eine neuen Anbieter in unser Portfolio aufgenommen, der unser Lagebild zu Infektionen verbessern sollte. Seit vorgestern verteilen wir Daten aus dieser Quelle.

Wir bekamen von einigen Seiten Feedback, dass hier was nicht stimmen kann. Es wurden IP-Adressen als infiziert gemeldet, die nie und nimmer von der angegebenen Malware befallen sein können.

Was ist passiert?

Der klassische Sensor für einen Datenfeed ist ein http-Sinkhole: Man besorgt sich Domains, welche die Malware für Command & Control Kommunikation benutzt, setzt die A Records so, dass die Domain auf einen Webserver zeigt, den man selber betreibt. Aus dem Access-Log dieses Webservers extrahiert man dann IP-Adressen und Timestamps.

Neben diesen Web-Sinkhole Daten sind in unserem neuen Feed aber auch Information aus Nameserver-Querylogs enthalten. Bevor die Malware die TCP-Verbindung zum Sinkhole aufbauen kann, muss sie die Domain auflösen. Das kann natürlich auch beobachtet werden und das sind auch sinnvolle Hinweise auf Infektionen.

Aber: die IP-Adresse, die bei der Namensauflösung in den Sensoren aufschlägt, ist typischerweise nicht des infizierten PCs, sondern die des rekursive Nameservers, den dieser gefragt hat.

Diesen Fall hatten wir in unserem Datenschema so nicht vorgesehen, worauf unsere Mails an die Netzbetreiber diesen Unterschied nicht kommuniziert haben.

Wir bitten daher um Entschuldigung; das lief nicht so gut, wie es von uns erwartet wird. Wir werden an unserer Qualitätskontrolle arbeiten. Bei manchen Themen werden wir aber immer auf das Feedback von den Netzbetreibern angewiesen sein.

Macht es überhaupt Sinn, dass wir Daten zu DNS-Requests aussenden?

Meiner Einschätzung nach ist das für ISPs sinnlos, da dort ziemlich sicher kein Query-logging am Nameserver gemacht wird, und daher das Ausforschen des infizierten Clients nicht möglich ist.

Für Firmennetze kann das aber sehr wohl Sinn machen: Dort mag die Firewall den C&C Request blockieren, der Nameserver kann Logs haben und so ist das ein sinnvoller Weg, eine Infektion zu erkennen.

Wir werden vorerst diese DNS basierten Event-Typen nicht mehr weitergeben.

Autor: Otmar Lendl

Wir werden alle an der Cloud verbluten .. oder so
1. März 2017

Ich bin froh, dass mein Arbeitgeber nicht an Voodoo oder böse Geister glaubt, ansonsten hätte ich meinen Arbeitsplatz wohl schon längst verloren - denn ich dürfte kein Glück bringen. Die meisten der medial grossen Schwachstellen in den letzten Jahren, die auch uns viel Arbeit bereitet haben, wurden während einer Zeitspanne veröffentlicht, in welcher ich nicht im Büro war.

Das gilt für CVE-2014-0160 ("Heartbleed") und CVE-2014-6271 ("Shellshock"), ebenso für CVE-2015-1538 ("Stagefright"), und auch folgendes erblickte ich bei einem Kaffee in meinem Wohnzimmer, anstatt an meinem Schreibtisch:

taviso tweet

Daraus wurde, wie wir jetzt wissen, "Cloudbleed". Andere Leute mit viel mehr Erfahrung und Fachwissen als meine Wenigkeit haben bereits über die verschiedensten Aspekte (Der offizielle Bugreport, Cloudflare selbst hat einen detaillierten Blogpost verfasst, es gibt einen Bericht aus IR-Perspektive, ..) des Vorfalls geschrieben und auch die Massenmedien sind auf den Zug aufgesprungen, teilweise in einem mehr als panischen Tonfall, quasi das technische Equivalent zu "Wir werden alle sterben!".

Fraglich ist, ob das in irgendeiner Weise hilfreich ist, ganz abgesehen davon bleibt die Frage offen, ob diese Herangehensweise ob des Problems gerechtfertigt ist - insbesondere im Angesicht der vorhandenen Fakten.

Der Name 'Cloudbleed' hat viele Seiten dazu verleitet, einen Vergleich zu 'Heartbleed' herzustellen. Ganz abgesehen davon, dass es sich hierbei um zwei technisch grundverschiedene Dinge handelt (Okay, es sind beides Softwareschwachstellen.), auch in dem Auswirkungsgrad unterscheiden sie sich enorm. Während Heartbleed es ermöglichte, aktiv private Daten aus dem Speicher von Serversystemen abzusaugen, so ist Cloudbleed wesentlich subtiler.

Ein Versuch, Fakten zu sammeln

In dem oben verlinkten Incident Report schreibt Cloudflare selbst:

The greatest period of impact was from February 13 and February 18 with around 1 in every 3,300,000 HTTP requests through Cloudflare potentially resulting in memory leakage (that's about 0.00003% of requests).
(Tavis Ormandy spricht von einer potentiell längeren Zeitspanne.) Auf den ersten Blick wirkt das wie ein winziger Prozentsatz, bedenkt man aber, dass die Anzahl der Requests, die Cloudflare in der Sekunde bearbeitet, wohl in die höheren Millionen geht, dann sieht das Bild schon wieder etwas anders aus.

Wiederum: Nicht jeder dieser 0.00003% geleakten Requests beinhaltet wohl sensible Daten. Statischer Content (Bilder, CSS, ..) macht einen viel grösseren Anteil aus, als beispielsweise Passwörter, welche sich vielleicht nur in jedem zehten oder hundertsten Request befinden, was das Risiko weiter minimiert. Auf der anderen Seite beinhaltet jede Anfrage an eine Seite, die Authorisierung verlangt, wohl einen entsprechenden Auth-Token. Deren Anzahl ist also, im Vergleich, wesentlich grösser.

Doch selbst, wenn die Anfragen zu der eigenen Seite nicht leaken, bedeutet das nicht, dass das nicht durch andere Seiten passiert:

Because Cloudflare operates a large, shared infrastructure an HTTP request to a Cloudflare web site that was vulnerable to this problem could reveal information about an unrelated other Cloudflare site.

Cloudflare selbst hat versucht anhand von Caches von Suchmaschinen zu etablieren, wie viele Seiten definitiv betroffen waren:

The infosec team worked to identify URIs in search engine caches that had leaked memory and get them purged. With the help of Google, Yahoo, Bing and others, we found 770 unique URIs that had been cached and which contained leaked memory. Those 770 unique URIs covered 161 unique domains. The leaked memory has been purged with the help of the search engines.

Das ist allerdings nur ein absolutes Minimum, da Cloudflare wohl nicht die Kooperation aller Suchmaschinen hatte, und es hunderttausende 'unabhängige' Crawler gibt, die das Netz nach den verschiedensten Dingen durchforsten. Die Chancen stehen also gut, dass die 'Dunkelziffer' der Seiten, deren Requests geleakt sind, noch wesentlich höher ist.

Auf Github, Pastebin und diversen anderen Seiten finden sich Listen von Seiten welche, mal verifiziert, mal nicht, das CDN von Cloudflare nutzen und dementsprechend angeblich bedroht oder betroffen waren. Gänzlich abgesehen davon, dass manche dieser Listen von fragwürdiger Qualität sind, sagt die Verwendung von Cloudflare recht wenig über die Sensibilität der darauf gehosteten Daten aus. Es gibt genügend statische Seiten ohne jegliche Benutzereingaben, oder Seiten, die auf DNS-Ebene auf andere Seiten verweisen, die wiederum im Netz von Cloudflare sitzen.

Im Grossen und Ganzen gibt es einfach keinerlei Möglichkeit, die Auswirkungen dieser Schwachstelle mit statistisch sauber verwertbaren Daten abzuschätzen. Da wo Beispieldaten vorhanden sind, kann ein Leak nachgewiesen werden. Aber die Abwesenheit von geleakten Daten ist gleichzeitig nicht die Anwesenheit von Gewissheit oder Sicherheit. Die Anzahl an Unbekannten ist einfach viel zu gross.

Was also tun? Rational bleiben und sich nicht von etwaiger Panik anstecken lassen. Ja, der Vorfall ist auf höherer Ebene und etwas abstrakt betrachtet nicht schön und definitiv nicht zu unterschätzen, als Seitenbetreiber ist es vielleicht eine gute Idee, proaktiv alle aktiven Sessions zu invalidieren (Google hat das in direktem zeitlichen Zusammenhang mit der Veröffentlichung getan, ein Schelm wer da Böses denkt!).

Für den 'normalen' Internetnutzer ist die Gefahr, die von dieser Schwachstelle ausgeht, aber als gering einzustufen. Die Chance, sich durch veraltete Browserplugins mit Malware zu identifizieren oder sein Passwort im WLAN von Starbucks durch einen Dritten gestohlen zu sehen ist um viele Potenzen höher und realistischer. Selbst ein Lottogewinn ist (wieder: statistisch betrachtet) wesentlich wahrscheinlicher.

Natürlich ist es wie immer ein guter Anlass zu überlegen, ob man Passwörter wiederverwendet (und damit aufzuhören) und seine Sicherheitspraktiken durchzugehen. Aber wir werden nicht alle sterben. Zumindest nicht daran.

Last but not least sei mir noch ein kleiner Seitenhieb in Richtung der Twittersphäre (tm) gestattet: Wenn Mensch so viel Zeit damit verbringen würde, selbst Bugs in hochkomplexen Systemen zu suchen, beziehungsweise diese zu betreiben, anstatt Tavis Ormandy aufgrund von Kleinigkeiten zu kritisieren oder Cloudflare unreflektiert zu bashen .. die Welt wäre wohl ein besserer Ort.

Autor: Alexander Riepl

Nächste >>
Email: reports@cert.at
Tel.: +43 1 5056416 78
mehr ...
Kritische Sicherheitslücken in Adobe Flash Player/Libraries - Patches nun auch für Microsoft Browser verfügbar
22. Februar 2017 | Beschreibung Adobe ...
Update: Kritische Lücke in Microsoft Windows ermöglicht DoS / Remote Code Execution via SMB - Updates nun verfügbar
3. Februar 2017 | ...
mehr ...
Workaround? Abdrehen!
21. März 2017 | Langsam ...
Propaganda auf Twitter
15. März 2017 | Der echte ...
mehr ...
Jahresbericht 2016
Ein Resumee zur digitalen Sicherheitslage in Österreich

(HTML, PDF).
Letzte Änderung: 2017/3/21 - 10:25:55
Haftungsausschluss