UPnProxy – oder zu was Plug and Play/Pray noch so alles missbraucht werden kann

UPnProxy – oder zu was Plug and Play/Pray noch so alles missbraucht werden kann

Wer erinnert sich noch an “Universal Plug and Play”? Es wurde von Microsoft in den 90ern erfunden, um die lästigen Treiber-Installationen unter Windows zu vereinfachen. Die Idee dabei war, dass sich Geräte über Port 1900 von ganz alleine finden können, und der Benutzer gar nichts mehr tun muss, um beispielsweise seinen neuen Joystick zu verwenden. Also Einstecken und Spielen. Die Idee dahinter war also wie so oft eine Gute, aber in der Praxis lief das nicht immer (um nicht zu sagen selten) reibungslos, so dass sich schnell der Begriff “Plug and Pray” verbreitete, der dieses Protokoll verspotten sollte.

Da dieses Protokoll keinerlei Sicherheit beinhaltet, da ihm Authentifizierung und Autorisierung fehlen, ist es ausschließlich für das interne LAN gedacht. UPnP darf also unter keinen Umständen ins offene Internet exponiert werden, denn dann werden Tür und Tor geöffnet für Neugierige und Angreifer. “Hey, kommt in mein LAN, ich zeige Euch gerne alles was ich habe” – das wäre die native Botschaft von einem ins Internet losgelassene UPnP.

Man sollte meinen, dass es deshalb klar sein sollte, dass UPnP niemals ins Internet losgelassen werden sollte, da es so ganz ohne Sicherheitsmechanismen nur für absolut vertrauenswürdige Umgebungen gemacht ist. Leider, leider… ist dem nicht so. Im Gegenteil. Viele namhafte Hersteller von Routern bieten ein “Feature” an: “Expose UPnP to WAN”. Gemäß einer Analyse von Akamai sind bis zu 4,8 Millionen Geräte betroffen.

Ein nicht-versierter Heim-Admin, der dieses Feature aktiviert, würde damit das Unvernünftigste tun, was in der heutigen Zeit in der Internet-Welt denkbar ist. Aber er wird noch schlimmer: Einige der Hersteller haben dieses Feature standardmäßig auch noch aktiviert. Das ist wirklich das Allerletzte – beim Schreiben dieser Zeilen fehlen mir vor lauter Entsetzen fast schon die Worte. Also am besten gleich den eigenen Router zuhause checken, ob dieser ein solches Feature hat und sicherstellen, dass es inaktiv ist.

Die Folge eines über UPnP ins Internet exponierten Routers ist, dass dieser zunächst für Brute-Force-Angriffe auf die Admin-Oberfläche erreichbar ist. Was vorher nicht der Fall war. Es ist nur eine Frage der Zeit und der Qualität des verwendeten Passworts, wie lange dieses dem Brute-Forcing standhält. Üblicherweise nicht besonders lange. Es kommt dann wie es kommen muss: der Router wird übernommen und von den bösen Buben geentert und missbraucht. Für Botnetze und andere Schweinereien.

Ein neuer Trend der kriminellen Machenschaften im Zusammenhang mit Botnetzen ist UPnProxy. Dazu wird einer der Millionen verwundbaren privaten Heimroutern für zur Verschleierung von Angriffen missbraucht, in dem er als Proxy fungiert. Wenn ein Opfer bzw. eine Strafverfolgungsbehörde versucht, einen Angreifer zurückzuverfolgen, dann führt die Route dadurch nicht direkt zum Angreifer, sondern über die verwendeten Proxies, die die Route dadurch zu verschleiern versuchen. UPnProxy ist damit ein weiteres wichtiges Instrument der organisierten Kriminalität, Angriffe noch schwerer zurückzuverfolgen.

Einmal mehr zeigt sich hier, wie ein zunächst gut gemeintes Feature (bzw. Protokoll) missverstanden wird, und durch Unwissenheit und Ignoranz zum Desaster der Internet-Sicherheit wird.

Mehr zu diesem Thema bei Bleeping Computer.

Erste Geldstrafe in Deutschland für fahrlässige Sicherheit in Web-Anwendung

Erste Geldstrafe in Deutschland für fahrlässige Sicherheit in Web-Anwendung

Seit dem die DSGVO in Kraft ist, drohen Geldstrafen für Betreiber von Web-Anwendungen, die fahrlässig mit dem Thema Sicherheit umgehen. Wie heise Security berichtet, wurde deshalb gegen Knuddels.de eine Strafe von EUR 20.000 verhängt, weil Passwörter von Benutzern im Klartext gespeichert wurden. Dies ist nach den Untersuchungen herausgekommen, nachdem ein Hackerangriff erfolgt ist und analysiert wurde. Weitaus größer als die finanzielle Strafe dürfte jedoch die nun stark beschädigte Reputation von Knuddels.de sein, sowie das verlorene Vertrauen bei den 2 Millionen registrierten Usern.

Wie wichtig es ist, Passwörter sicher abzuspeichern, zeigt sich mustergültig an diesem Beispiel. Ist der Zugriff auf die unverschlüsselten Passwörter erst einmal möglich, dann sind zahlreiche Benutzer betroffen und damit kompromittiert. Da es von vielen Personen außerdem gängige Praxis ist, ein und das selbe Passwort auf mehren Portalen zu verwenden, sind durch einen solchen Raub gleich alle Accounts gefährdet, auf denen dieses Passwort gültig ist. Die Aufklärungsarbeit, die dazu bei den Anwendern gemacht werden muss, stößt oft auf taube Ohren. Aus Bequemlichkeit setzen sich Passwort-Management Programme wie KeePass oder LastPass nur sehr schleppend durch, aber sie scheinen der einzige Ausweg zu sein, um auf jeder Webseite ein eigenständiges, genügend komplexes Passwort zu haben.

Der einzig richtige Weg, wie ein Passwort abgespeichert werden muss, ist: überhaupt nicht. Zumindest nicht im Klartext – und auch nicht verschlüsselt. Verschlüsselte Passwörter können nämlich wieder entschlüsselt werden, was bei einer Passwortprüfung überhaupt nicht notwendig ist. Statt dessen sollte nur der Passwort-Hash abgespeichert werden, und zwar mit einem sicheren Hash-Algorithmus, z.B. PBKDF2 oder bcrypt. Die Prüfung, ob das vom Benutzer eingegebene Passwort dann das Richtige ist, findet folgendermaßen statt: Die Web-Anwendung, die die Benutzereingabe verarbeitet, hasht das Passwort ebenfalls und vergleicht dann nur noch den Hash mit dem Hash aus der Datenbank. Stimmen diese überein, wurde das Passwort richtig eingegeben.

Mehr Informationen über sichere Passwortverwaltung und sichere Programmierung finden sich auf den OWASP-Seiten, und können auch auf einer Secure Coding Schulung gelernt werden.

 

Multifaktor-Authentifizierung, bitte nicht mit SMS

Multifaktor-Authentifizierung, bitte nicht mit SMS

Die klassische Authentifizierung erfolgt üblicherweise mit Benutzername und Passwort. Da aber Passwörter gerne mal in die falsche Hände geraten, wie inzwischen zig fach bekannt, sei es durch Ausspähen auf dem Transportweg, durch Auslesen des Passwort-Speichers, oder durch Knacken mit Brute-Force-Tools, braucht es einen weiteren “Faktor”, der die Authentifizierung sicherer macht. Also eines weiteren Merkmals, das über einen alternativen Kanal abgefragt wird. Auch Multifaktor-Authentifizierung genannt.

In den letzten Jahren wurde vor allem im Banking-Umfeld die SMS verwendet, um neben dem Passwort oder der PIN, ein weiteres Merkmal des Benutzers abzufragen. Die Bank schickt also nach dem Login via Benutzername und PIN eine SMS an den Kunden, damit er sich durch Eingabe dieser gegenüber der Bank legitimiert. Dass aber SMS nicht sicher sind, zeigt sich vermehrt durch Bekanntwerden immer neuer Vorfälle. Wie das Magazin TechCrunch.com berichtet, wurde eine Datenbank des kalifornische Telekomanbieters Voxox kompromittiert, so dass Millionen gesendeter SMS Nachrichten für jedermann offen lesbar waren – und zwar in Echtzeit, so dass beispielsweise Passwort-Rücksetzungstoken einsehbar waren, quasi gleichzeitig zum Versand an den eigentlichen Adressat. Ganz abgesehen von privaten Daten und anderen geheimen Informationen. Mit solcherlei Pannen ist es also keine Hilfe, SMS als zweiten Faktor für die Sicherheit zu verwenden. Im Gegenteil.

Es stellt sich also die Frage, warum ein Telekomanbieter überhaupt versendete SMS abspeichern. Geht man dieser Frage nach, stellt man schnell fest, dass diese sogar dazu verpflichtet sind, SMS in ihren Datenbanken aufzubewahren, da es sich technisch gesehen dabei um ein Kommunikationsprotokoll handelt, für das Aufbewahrungspflicht besteht. Mindestens 10 Jahre müssten SMS gespeichert werden.

Was lernen wir daraus? SMS taugen nicht für die Multifaktor-Authentifizierung. Vielleicht sollte ich einer meiner Banken, die das immer noch praktiziert, mal deutlich sagen. Bei den meisten Banken wurde inzwischen umgestellt, was die TANs angeht, auf smartTAN bzw. pushTAN, oder wie auch immer die jeweilige Bank das Verfahren nennt, bei dem eine Smartphone-App zum Einsatz kommt.

Threat Modelling

Threat Modelling

Unter Threat Modelling versteht man das systematische Modellieren von Bedrohungen, wie sie in Web-Anwendungen vorkommen. Dabei wird betrachtet, welche Schnittstellen ein System nach außen hin hat, wie die Daten von vorne bis hinten durch System fließen, und an welchen Stellen kritische Übergänge stattfinden, an denen besondere Vorsorge getroffen werden muss.

Als Ergebnis der Bedrohungsanalyse soll eine gute Übersicht aller Bedrohungen herauskommen, die die Grundlage des Risk-Managements darstellt. Beim Risk-Management werden die Risiken bewertet und entsprechende Maßnahmen abgeleitet, je nach Situation und Kriminalität der Web-Anwendung.

Eine ausführliche Beschreibung dieser Thematik wurde hier veröffentlicht, mit ausführlichen Erklärungen und Beispielen.

Zur 9-teiligen Serie Threat Modelling – Bedrohungsanalyse gehts hier.