Deutsch | English
Dieser Blog enthält keine offiziellen Aussagen von CERT.at, sondern persönliche Meinungen einzelner Mitarbeiter.
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

Zeit für eine AMTshandlung?
8. Mai 2017

Letzte Woche veröffentlichte Intel ein Advisory über eine Schwachstelle in "Intel Active Management Technology", kurz AMT. Besagte Schwachstelle erlaubt einem Angreifer, auf einem Rechner mit aktiviertem AMT, die Zugriffskontrollen für eben jenes auszuhebeln, und so administrativen Zugriff zu erlangen - die Features von AMT enthalten, unter anderem, die Einbindung eines Images oder, unter bestimmten Umständen, Konsolenzugriff auf das installierte Betriebssystem.

Zwar gibt Intel selbst an, dass die Schwachstelle Consumer-Geräte nicht betrifft, es ist inzwischen jedoch bestätigt, dass nicht wenige aktuelle Notebooks zumindest theoretischen Support für AMT besitzen. Es gibt mehrere Wege, das Vorhandensein von Intel AMT auf dem eigenen Rechner zu überprüfen, die einfachsten sind:

  • Von extern prüfen, ob einer oder mehrere der TCP-Ports 16993, 16992, 16994, 16995, 623 oder 624 offen sind
  • Prüfen, ob die "Intel Management Engine BIOS Extension" vorhanden ist; diese erreicht man je nach System durch Drücken von CTRL+P während des Bootvorgangs
  • Prüfen des BIOS, ob die Intel AMT-Version aufgeführt wird
  • Nutzung des von Intel bereitgestellten Prüftools

Kurz gefasst ist zu sagen, dass die Sicherheitslücke ein technischer Totalschaden für Intel ist; eine Behebung würde eine Aktualisierung der Firmware benötigen, jedoch erhalten wohl nicht alle der betroffenen Chipsätze überhaupt noch solche Updates (zur Erinnerung: betroffen sind alle Intel Generationen seit Nehalem - diese feiert heuer ihr zehnjähriges Jubiläum), und da diese Firmwareupdates nicht über Windows-Update bereitgestellt werden, ist die Chance, dass besagte Updates flächendeckend eingespielt werden würden, noch geringer.

Die Bedrohung für die Allgemeinheit hält sich allerdings dennoch in Grenzen. Die Zahlen, die Shodan zu dem Thema hat, sind mit etwas mehr als 6000 Hosts weltweit nicht erschreckend hoch, was vor allem daran liegt, dass AMT in den meisten Fällen explizit aktiviert werden muss. Endbenutzer haben dazu keinen Anreiz, und die meisten Unternehmen nutzen für denselben Zweck andere Lösungen (z.B. IPMI, iLO, ..). Auch die bisher kolportierten Angrifsszenarien sind, trotz öffentlich vorhandenem Proof-of-Concept, sehr spezifisch und nicht direkt für die breite Masse gefährlich. Das Fazit ist hier recht klar, dass wir alle sterben werden - aber nicht an dieser Schwachstelle.

Autor: Alexander Riepl

In eigener Sache: CERT.at sucht Verstärkung
8. Mai 2017

Für unser "Daily Business" suchen wir derzeit 1 Berufsein- oder -umsteiger/in mit ausgeprägtem Interesse an IT-Security, welche/r uns bei den täglich anfallenden Standard-Aufgaben unterstützt.

Details finden sich hier.

Autor: Robert Waldner

Nächste >>
Email: reports@cert.at
Tel.: +43 1 5056416 78
mehr ...
Ransomware/Wurm WannaCry
14. Mai 2017 | Seit ...
Kritische Lücke in verbreiteter Webshop-Software Magento - keine Updates verfügbar
14. April 2017 | Wie ...
mehr ...
Tanze (aktualisierten) Samba mit mir
26. Mai 2017 | Die Erinnerung ...
Ein paar Gedanken zu WannaCry
14. Mai 2017 | Wir haben ...
mehr ...
Jahresbericht 2016
Ein Resumee zur digitalen Sicherheitslage in Österreich

(HTML, PDF).
Letzte Änderung: 2017/5/26 - 13:52:38
Haftungsausschluss