Multilogin- und Hijacking-Detection

Multilogin- und Hijacking-Detection

Marc Ruef
von Marc Ruef
Lesezeit: 7 Minuten

Die angewandte Sicherheit versucht stets das Risiko bzw. die Auswirkungen von Angriffen zu reduzieren. Eine einfache, jedoch gerne übersehene Methode liegt im Erkennen von _Multilogin_-Versuchen. Diese kann man wie folgt definieren:

Als Multilogin wird der Zustand bezeichnet, bei dem sich einer oder mehrere Benutzer mehrfach mit dem gleichen Konto in der gleichen Anwendung einloggen.

Bei so mancher Anwendung ist dies von Nutzen, ja gar erforderlich. Zum Beispiel dann, wenn zwei SSH-Logins auf einem Remote-Server umgesetzt werden sollen, um zwei Config Files zu editieren oder ein gerade geschriebenes Shell-Skript auszuprobieren.

In vielen Fällen sind Multilogins jedoch nicht erwünscht, deuten sie gar oftmals auf eine Kompromittierung durch Hijacking hin. Zum Beispiel dann, wenn ein Angreifer mittels Social Engineering oder Cross Site Scripting die Login-Daten entwenden konnte und diese zeitgleich mit dem legitimen Login weiterverwenden möchte.

Das Erkennen von Multilogins ist eine einfache und zuverlässige Lösung, um unerwünschte Zweitzugriffe zu erkennen. So wie zum Beispiel die nachfolgend gezeigte Fehlermeldung des Alcatel-Lucent Softphone Clients. Hier wird der Zweitlogin auf die Problematik mit der Warnmeldung hingewiesen. Dieser kann nun entscheiden, ob er den Erstzugriff terminieren und dessen Zugriff übernehmen will. Oder ob der Zweitzugriff abgebrochen wird und damit der Erstzugriff bestehen bleibt.

Softphone von Alcatel-Lucent zeigt eine Multilogin-Fehlermeldung an

Es gibt also verschiedene Herangehensweisen, wie derlei Zuständen entgegnet werden kann. Die nachfolgende Tabelle listet diese in Bezug auf die gewünschte Priorisierung auf und unterscheidet, ob je nachdem die Aktion auf den Erst- oder den Zweitlogin angewendet werden soll:

Aktion Erstlogin Zweitlogin
Ignorieren des Multilogins 7 8
Generieren eines Log-Eintrags 3 4
Anzeigen einer Warnmeldung 2 5
Terminieren der Verbindung 6 1

Da es sich beim Zweitlogin tendenziell eher um den Angreifer handelt, sollte diesem restriktiv entgegnet werden. Das Terminieren der Verbindung sollte also eher nicht auf dem Erstlogin zum Einsatz kommen, da sich sonst hiermit Denial of Service-Attacken umsetzen liessen. So ebenfalls die Begründung bei der Spezifikation von Skype:

as skype is moving out of the desktop and into mobile devices (which will be used in parallel with the desktop clients) we are definitely not going to remove the possibility to log in from multiple locations simultaneously. however redesigning the multi-device presence takes time and is not likely to happen in near future. (sic)

Doch ebenso sollte auf umfassende Warnmeldungen beim Zweitlogin verzichtet werden, um einem potentiellen Angreifer nicht ungewollt technische Details in die Hände zu spielen. Zum Beispiel sollte nicht angegeben werden, welcher Benutzer und von welchem System er den Erstlogin benutzt.

Zum Schluss muss gesagt werden, dass das Umsetzen einer intelligenten Lösung einmal mehr von den Anforderungen des jeweiligen Produkts abhängig ist. Ein Online-Banking wird wohl ganz anders reagieren wollen, weder eine Social Network-Webseite. Nachfolgende Tabelle listet exemplarisch die unterschiedlichen Applikationstypen und die vorzugsweise beobachteten Eigenschaften auf.

Applikationstyp Logging Warnung Logout Lockout
Webforum nein ja/nein nein nein
Social Network Webseite nein ja/nein nein nein
Webmailer nein ja/nein ja/nein nein
Voice-over-IP Telefon nein ja ja/nein nein
Online Banking ja ja ja/nein ja/nein

Mit Facebook ist das bisweilen populärste Soziale Netzwerk und greift auf einen leicht abgeänderten Mechanismus zurück. So kann ein Benutzer per SMS oder Email über die neue Anmeldung durch einen bis dato unbekannten Endpunkt (z.B. Computer, Telefon, iPad, etc.) informiert werden. Dadurch wird ein Monitoring/Alerting möglich, welches eine unmittelbare Reaktion ermöglichen kann. Und durch das Tracking dieser Zugriffe im Profil können die mit einem Konto verlinkten Systeme eingesehen. Die jeweiligen Benutzer bekommen bei einem Login selbst direkt nichts von diesen Mechanismen mit.

Über den Autor

Marc Ruef

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

Sie wollen Ihr Log und Monitoring auf das nächste Level bringen?

Unsere Spezialisten kontaktieren Sie gern!

×
Konkrete Kritik an CVSS4

Konkrete Kritik an CVSS4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentisierung

Voice Authentisierung

Marc Ruef

Bug-Bounty

Bug-Bounty

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv