Deutsch | English
Dieser Blog enthält keine offiziellen Aussagen von CERT.at, sondern persönliche Meinungen einzelner Mitarbeiter.
In eigener Sache: Umstellung der Tageszusammenfassungen
19. Juni 2017

In der Woche vom 3.-7. 7. 2017 werden wir das Format unserer Tageszusammenfassungen anpassen. Inhaltlich bleibt alles wie gewohnt, wir werden aber der besseren Übersichtlichkeit halber den Inhalt in mehrere Sektionen unterteilen. Damit sollte es einfacher werden, den jeweils gewünschten Content schnell zu finden.

Wobei, eine inhaltliche Änderung wird es doch geben: der Titel wird nicht mehr "End-of-Shift report" sondern "End-of-Day report" lauten. Wir gehen davon aus, dass dies kein gravierendes Problem darstellen wird...

Autor: Robert Waldner

In eigener Sache: Umstellung auf wöchentliches Wartungsfenster
9. Juni 2017

Um die Administration zu erleichtern, werden wir ab 22. 6. 2017 auf ein wöchentliches Wartungsfenster umstellen: dieses wird jeweils am Donnerstag von 19-22h sein. Falls also notwendige Wartungsarbeiten anstehen, die in diesem Zeitraum durchgeführt werden können, werden wir dies nicht mehr extra ankündigen.

Es gehen dabei keine Daten verloren, es kann jedoch in manchen Bereichen zu entsprechend kurzen Verzögerungen (zB bei automatisierten Emails) bzw. Unterbrechungen (zB Datenfeeds) kommen. Da das Wartungsfenster ausserhalb unserer regulären Service-Zeiten (im Wesentlichen Mo-Fr 8-18h, siehe auch https://cert.at/about/contact/contact.html) liegt, ändert sich bei der Bearbeitung "normaler" Vorfälle dadurch nichts.

Warungsarbeiten ausserhalb dieses Zeitfensters, wie auch grössere/längere Unterbrechungen, werden wir natürlich wie gewohnt jeweils möglichst frühzeitig ankündigen.

Autor: Robert Waldner

Tanze (aktualisierten) Samba mit mir
26. Mai 2017

Die Erinnerung an CVE-2017-0144, und die Auswirkungen von WannaCry, ist bei uns allen noch frisch im Gedächtnis verankert, und damit keine Langeweile aufkommt, hat Samba nun ein Advisory bezüglich einer kritischen Schwachstelle veröffentlicht:

All versions of Samba from 3.5.0 onwards are vulnerable to a remote code execution vulnerability, allowing a malicious client to upload a shared library to a writable share, and then cause the server to load and execute it.
Der "Vorteil" bei dieser Lücke ist, dass es einen authentifizierten Benutzer mit Schreibrechten benötigt, um sie auszunutzen, oder komplett deaktivierte Zugriffskontrolle.

Die Zahl der auf diese Weise potentiell betroffenen Systeme in Österreich ist, laut simpler Suche bei Shodan, vergleichsweise gering, dennoch raten wir natürlich zum raschen Einspielen des Patches, vor allem in Anbetracht der öffentlichen Verfügbarkeit von Exploits. Für Systeme, auf denen eine Aktualisierung nicht möglich ist (beispielsweise NAS-Systeme von der Stange) gibt es einen empfohlenen Workaround.

Gleichzeitig kann dies als Anlass genommen werden, die Wahl von SMB als Protokoll für Dateizugriffe über das Internet zu überdenken, erfahrungsgemäss sorgen Verbindungen mit hoher Latenz für merkbare Probleme mit Samba, und standardmässig erfolgt der Datentransfer unverschlüsselt - hier gibt es heutzutage bessere Alternativen.

Autor: Alexander Riepl

Ein paar Gedanken zu WannaCry
14. Mai 2017

Wir haben heute unsere offizielle Warnung bezüglich der WannCry Ransomware veröffentlicht. Ich will in diesem Blogbeitrag ein bisschen Kontext liefern, und etwas strategischer denken.

Erstens: wie viele hat es wirklich erwischt?

Dazu gibt es mehre Blickwinkel und Datenquellen.

Einerseits sind das diejenigen Organisationen, bei denen die Ransomware-Komponente von WannaCry voll zugeschlagen hat. Diese haben zum Teil bei der Polizei Anzeige erstattet, daher sind dort Daten dazu vorhanden. Die Dunkelziffer wird aber - wie immer bei diesen Sachen - hoch sein. Viele, insbesondere wenn der Schaden klein war, sparen sich die Zeit für die Bürokratie und stecken ihre Energie lieber in die Wiederherstellung des Betriebs. So sehr wir das verstehen, so sehr ist das aber aus gesamtstaatlicher Sicht nicht gut: wir bekommen kein volles Bild der Probleme, daher kann der Staat seine Ressourcen nicht an die richtigen Stellen leiten. Bei uns (CERT.at) melden sich typischerweise nur ganz wenige dieser Gruppe.

Die CERTs stützen sich auf eine andere Datenquelle: der vielbeschriebene "Kill-switch" (in Wirklichkeit der Test der Malware, ob sie in einer Analyseumgebung läuft, in der alle Domains valide sind) besteht aus einem erfolgreichen http-Request. Diese werden vom Researcher, der das gefunden hat, mitprotokolliert und im globalen Datenverbund der CERTs weitergegeben. Wir wissen daher primär, wo in Österreich die Malware zwar vorhanden ist, aber nicht aktiv geworden ist oder gestoppt wurde. Die Zahl ist so gemessenen IP-Adressen ist überschaubar: weniger als 100.

Zweitens: warum ist das global so groß geworden?

Ransomware ist ja nichts Neues. Bis jetzt sahen wir aber entweder die Massenverbreitung über die üblichen Kanäle Phishing und Exploit-Packs, oder aber die manuelle Kompromittierung eines High-Profile Zieles, ein händisches "lateral movement" und dann die Platzierung der Malware. Letzteres war bei den SAMSAM-Angriffen auf Spitäler die beobachtete Vorgangsweise. Was wir jetzt gesehen haben, ist schlichtweg die Automatisierung der Weiterverbreitung innerhalb einer Organisation. Damit skaliert das Ganze plötzlich um Größenordnungen besser.

Wir sehen den gleichen Effekt immer wieder im Webbereich. Wenn mal wieder Wordpress, Joomla & co eine gröbere Lücke haben, dann gibt es vereinzelnd Defacements und anderweitig manipulierte Webseiten. Dann und wann programmiert aber jemand den ganzen Prozess aus, und dann raschelt es bei uns im Ticketsystem weil dann innerhalb von kurzer Zeit hunderte Webseiten betroffen sind.

Wann jemand das Ausnutzen einer Schwachstelle voll automatisiert, oder gar gleich einen Wurm dafür schreibt, lässt sich nicht vorhersagen. So etwa hatten wir das für den Schannel Bug erwartet gehabt (und sogar einen Honeypot dafür gebaut), da kam aber gar nichts. Dass jetzt EternalBlue / SMB / MS17-010 dafür benutzt wurde, mag mehr oder weniger Zufall sein. Für Ransomware eignet sicher das jedenfalls sehr gut, da damit die Malware direkt auf den Fileservern agieren kann. Dass die Shadow Brokers gleich den Exploit geliefert haben, und man den nicht aus dem Patch reversen musste (wie damals bei Conficker), erleichterte sicher die Arbeit.

Drittens: warum geht das überhaupt?

Da spielen meiner Meinung nach zwei Faktoren zusammen.

Erstens, es ist immer noch viel zu einfach, jemand anderem böse Code unterzujubeln. Die Angriffsfläche moderner (oder noch schlimmer, nicht ganz moderner) PCs ist extrem groß. Dabei geht es nicht nur um Schwachstellen in Standardanwendungen, sondern oft genug um den einen falschen Mausklick, mit dem der Benutzer die Sicherheitsmaßnahmen des Systems aushebelt. Das können Macros in Office-Dokumenten sein oder Scripte in esoterischen Fileformaten, die per Mail oder Web dem Opfer mit einer netten Story untergejubelt werden. Social Engineering funktioniert immer noch bestens.

Zweitens, kaum eine Organisation schafft es, seine interne IT wirklich am Stand der Technik zu betreiben. Mal sind es Legacy-Systeme, die auf nicht mehr unterstützen Betriebssystemen fahren, mal sind es Verzögerungen über Monate in der Einspielung von Patches, mal sind es Inkompatibilitäten, die eine Aktualisierung verhindern (Hallo Java!), mal ist es schlicht ein Ressourcenmangel in der IT-Abteilung.

Oder anders gesagt: müssten wir mit unsere IT jedes Jahr das Pickerl (oder zum TÜV) machen lassen, dann würde so manches massiv bemängelt werden. Zertifizierungen nach diversen Sicherheitsnormen sollten das theoretisch besser machen, aber das ist in manchen Bereichen nur ein "wir haben einen gut dokumentierten Prozess, nach dem wir unser Schlamassel verwalten".

Das alles ist in den meisten Fällen nicht böswillig, sondern bloß eine Folge der täglichen Triage der IT-Abteilungen. Nur so ist es zu erklären, dass Conficker immer noch in diversen Firmennetzen herumspukt. "Ja, wir sollten das aufräumen, aber welches andere Projekt kann ich deswegen zurückstellen?" Damit habe ich fast überall irgendwo bekannte Schwachstellen, die aber hoffentlich nicht von extern aus angreifbar sind. Es kommt leider viel zu oft vor, dass man sich zu sehr auf den Perimeterschutz verlässt. Ich werfe hier jedenfalls nicht den sprichwörtlichen ersten Stein.

Nimmt man das zusammen, wird das Problem klar: Eine Erst-Infektion irgendwo ist leider fast Tagesgeschäft in größeren Organisationen, und wenn dieser Code zum systematischen Suchen und Ausnutzen von Schwachstellen benutzt wird, da kann das einen bösen Effekt haben.

Viertens: wohin geht die Reise?

Ein guter Teil der Probleme stammt aus einem verbockten IT Lifecycle Management. Wir planen sehr oft nur die Inbetriebnahme, und nicht immer auch die laufende Wartung und das Ende der Lebensdauer von Systemen. Das fängt an bei Commodity-Betriebsystemen als Komponenten in integrierten Systemen (Angeblich wird manchmal immer noch XP ausgeliefert) an, geht über Handys (wie lange bekommt das typische Android-Gerät Updates?), ganz normalen Servern (wie oft Windows Server 2003 noch eingesetzt wird, ist erschreckend) bis hin zu Internet-of-Things (IoT) Devices.

Viel von dem, was wir jetzt (ver-)bauen, hat keine garantierte Software-Wartung bis zum Ende der Lebensdauer der Hardware. Mir gefällt die Metapher des IT oder technical debt sehr gut.

Analog zum realen Leben: Ja, ich kann die Wartung meines Autos, oder die Reparaturarbeiten an meinem Haus, oder an Straßen- und Schieneninfrastruktur hinauszögern. Das wird nicht gleich dramatische Konsequenzen haben.

Aber irgendwann holt mich das alles ein.

Genau so einen Moment haben wir gerade eben mit WannaCry erreicht.

Jetzt kam ein Exekutor, der die Schulden eintreibt.

Fünftens: wieder einmal geht die Strategie der USA nach hinten los

Die NSA saß lang auf dem 0-day und sah es als wichtiger an, ihre offensiven Fähigkeiten zu erhalten, als die eigene Industrie gegen diese Schwachstelle zu schützen. Dafür zahlen sie jetzt. Ich bin gespannt, ob die Vorgehensweise dort überdacht wird. Microsoft hat sich schon deutlich kritisch geäußert.

Wir hatten genau das gleiche auch bei TLS, siehe meinen Blog-post zu DROWN.

Ein weiterer Punkt passt hier noch dazu (und auch die Idee ist nicht von mir): will ich als kleiner Staat meine bescheidenen Mittel effizient gegen die Bedrohung durch einen Cyberwar einsetzen, dann sind all diese 0-days, die von meinen potentiellen Gegner gehortet werden, die Ressourcen, die ich angreifen will. Und im Gegensatz zu klassischem Krieg kann ich die auch schon zu Friedenszeiten angreifen. Wie? Indem ich selber die 0-day Suche mache oder fördere und die Ergebnisse nicht selber horte, sondern an die Hersteller melde und so den Wert dieser 0-days radikal verringere.

Im Vergleich zu klassischer militärischer Hardware kostet das einen Pappenstiel. Investitionen in oder Nachbauten von der Zero Day Initiative oder Project Zero sind genau das, was kleiner Staaten machen sollten.

Das darf natürlich nicht die einzige Maßnahme zur Erhöhung der Cyber Security sein.

Vergesst das Arms-Race mit der NSA, das gewinnt ihr nicht. Aber ihr könnt global an der Cyber-Abrüstung arbeiten, indem ihr Forschung + Responsible Disclosure macht.

[Addendum, 23.5.: Beim Browser-Tabs wegräumen kam mir wieder folgender Artikel unter. Der passt hier gut an das Ende.]

Autor: Otmar Lendl

<< Vorige Nächste >>
Email: reports@cert.at
Tel.: +43 1 5056416 78
mehr ...
Neue Variante von Ransomware/Wurm "Petya"
28. Juni 2017 | Seit ...
Ransomware/Wurm WannaCry
14. Mai 2017 | Seit ...
mehr ...
In eigener Sache: CERT.at sucht Verstärkung
18. Juli 2017 | Für unser ...
Petya Updates #3 - Die Hoffnung auf einen Kill-Switch
27. Juni 2017 | Petya ...
mehr ...
Jahresbericht 2016
Ein Resumee zur digitalen Sicherheitslage in Österreich

(HTML, PDF).
Letzte Änderung: 2017/7/18 - 15:27:48
Haftungsausschluss