Multilogin- und Hijacking-Detection

Multilogin- und Hijacking-Detection

Marc Ruef
by Marc Ruef
time to read: 7 minutes

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.

About the Author

Marc Ruef

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

You want to bring your logging and monitoring to the next level?

Our experts will get in contact with you!

×
Specific Criticism of CVSS4

Specific Criticism of CVSS4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentication

Voice Authentication

Marc Ruef

Bug Bounty

Bug Bounty

Marc Ruef

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here