LTT Hack - generelle Bewertung Session Token / Auth Token

[Redundanz]

ich kenne mich auch nicht 100% aus, aber manche login sessions überleben ja auch einen rechner neustart. Da fällt der ram schon mal weg. ob's in dem fall genau so ist...keine ahnung

korrekt! rechner neustart sowieso, sogar IP wechsel, browser update, OS update ... etc.

 

[CoMo]

Es war eine .pdf.scr
[...]
Er hätte also stutzig werden müssen, dass im vermeintlichen Dokument plötzlich PDF dabei steht.
[...]
Mit einer Sicherheitslücke in Windows hat das nichts zu tun.

Ganz genau das. Menschliches Versagen. Wie wir ja hier längst herausgefunden haben.

 

[PC295]

Richtig. Mit einem echten "Hackerangriff", wie immer bei gekaperten Account berichtet wird, hat das auch hier nichts zu tun.
Ist auch nicht wunderlich, sonst hätten jetzt sehr viele Youtuber ein Problem, wenn Hacker einen Weg gefunden haben Youtube-Accounts zu übernehmen.

 

[ghecko]

Schalte mal deinen Rechner aus und an, schaue danach ob du hier bei CB noch angemeldet bist

Ich rede hier nicht von der PW-Sammlung die man über den Browser abspeichern kann. Die liegen auf der Festplatte, aber verschlüsselt. Das Tokens einer aktiven Session unverschlüsselt in einem nicht geschützten Speicherbereich liegen wäre hochgradig Kokolores, das glaube ich erst wenn ich es sehe.

 

[Piktogramm]

De facto ist das ja wie nen im Browser gespeichertes Passwort, mit dem Unterschied, dass es abläuft / beim ausloggen gelöscht wird.

Wenn du auf CB gehst und das Sessioncookie vom Forum nutzt, du dich also nur einmal anmeldest und immer angemeldet bleibst, dann ist das Ganze konsistent. Das ist bei Google und die weit verbreitete Möglichkeit sich über OAuth und Facebook/Google/Microsoft bei verschiedenen Diensten anzumelden ebenso.

Hätte gedacht, das wird im TPM gespeichert bzw. es gibt flankierende Schutzmaßnahmen, wie Gerätedaten, die auch imitiert werden müssten...

Viele TPM-Lösungen haben nicht genug Speicher um da gescheit Passwörter und Sessiontokens zu verwaren. Allenfalls wäre es sinnvoll einen zentrales Keymanagement zu haben, welches über das TPM oder eine andere Hardware 2FA Lösung diesen Keymanager zu entsperren. Das Problem bleibt da aber, für die Bequemlichkeit werden die Keymanager einmal entsperrt und spucken danach die Sicherheitsinformationen im Klartext und auf Verlangen aus (mit Einschränkungen, aber die sind meist nicht der Rede wert).

Oder man blockt auf dem Mailserver generell Anhänge mit ausführbarem Inhalt.

Also gar keine Anhänge und da Email auch fröhlich HTML/Javascript enhalten kann am besten gar keine Nutzlast!

Richtig. Mit einem echten "Hackerangriff", wie immer bei gekaperten Account berichtet wird, hat das auch hier nichts zu tun.

Den echten Hackern kommt es nur auf Erfolg drauf an. Der Anspruch ein Konstrukt aus einem Dutzend 0days zu bauen und die Überhack zu liefern besteht nicht (das KnowHow meist auch nicht).

 

[Yuuri]

Mit Linux wäre das nicht passiert

Natürlich, aber das weißt du wohl selbst. Wird halt keine exe runtergeladen, sondern eine tar, welche das x-Flag im Archiv persistiert und dann diese ausgeführt wird.

Session Tokens identifizieren eine bestimmte Session auf einem Server. "Früher" (heute mit Sicherheit auch noch) gab es genug Probleme mit Session IDs in URLs. Genannt seien da unzureichend abgesicherte PHP-Apps. Filtern kann man da problemlos nach PHPSESSID, welche einfach über die URL (statt im Cookie persistiert) durchgereicht wurden. War auch kein Problem, aber wenn man diese dann bspw. über Messenger oder eMails versendet und den Parameter nicht entfernt, hat der andere User plötzlich die eigene Session übernommen. Das ist aber an sich kein PHP-Problem, sondern einfach ein nicht abgesichertes Deployment. Kann mit jeder anderen 0815 Sprache oder jedem anderen Framework genauso passieren, auch heute noch ohne Probleme. SQL-Injections sind ja heute noch genauso möglich, u.a. auch dank der millionenfachen 0815 Tutorials, welche Parameter immer noch direkt in den Query schreiben und vorher ggf. nicht mal escapen.

Also selbst wenn hier eine Session ID abgezogen wurde, dürfte es aber "eigentlich" selbst hierbei nicht passieren, dass sich die Session deshalb so einfach übernehmen lässt. Normalerweise... Aber wer macht das? Wahrscheinlich niemand... Ähnlich zur Situation in der OSS Welt "irgendjemand sieht schon über den Code blablabla...".

"Regulär" (Best Practice, aber wer hält sich dran?) speichert man zur Session selbst noch irgendwelche Hinweise ab, welche den User bzw. die Session ([sehr] grob) identifizieren. Bspw. den User Agent, die IP oder irgendwas ähnliches. Hierbei kann dann also selbst beim einfachen Übernehmen (Copy + Paste) der Session ID diese nicht einfach übernommen werden, da bspw. die originale Session aus Firefox heraus erstellt wurde, die übernommene Session aber bspw. durch Edge aufgegriffen wird. "Normalerweise" sollte die Session somit invalidiert werden, einfach aus Sicherheitsgründen. Script Kiddys nutzen dann einfach regulär curl und setzen den UA nicht mal ansatzweise korrekt, wodurch die Session dann so oder so invalidiert wird, wenn es nicht mal ein Browser ist.

Mal gesponnen: Man könnte den User Agent auch noch granularer differenzieren. Wenn die Session mit Firefox 100 initiiert wird, könnte man bspw. eine Toleranz von drei Versionen einbauen. Heißt Firefox 97 könnte noch zugelassen werden. Wird mit Firefox 96 drauf zugegriffen, wird auch hier die Session invalidiert. "Gute" Hacker kann man damit natürlich nicht ausschließen, aber "Hijacker von der Stange" wird damit der Hahn zugedreht. Und es ist auch keine "absolute Sicherheit" (die es eh nie gibt), sondern zusätzliche Indikatoren.

Man muss sich halt um die eigene und die Sicherheit seiner User kümmern.

Was OWASP dazu sagt

Binding the Session ID to Other User Properties¶

With the goal of detecting (and, in some scenarios, protecting against) user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, this is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session.

Although these properties cannot be used by web applications to trustingly defend against session attacks, they significantly increase the web application detection (and protection) capabilities. However, a skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots) or by using the same outbound web proxy (very common in corporate environments), or by manually modifying his User-Agent to look exactly as the victim users does.

Aber Sicherheit kostet... Und ist unbeqeuem...

Also die User sind hier nicht wirklich dran Schuld, sondern es ist mal wieder eine fehlende Sicherheitsebene auf Anbieterseite, welche man sich einfach einspart und viel zu einfach Schindluder treiben kann. Thematisch fällt das in ein ähnliches Raster wie XSS oder spezieller CSRF bzw. CORS. Session Hijacking sollte heute eigentlich auch "kein Thema" mehr sein, speziell nicht bei solchen Riesen wie Youtube/Google, welche für jeden Scheiß heutzutage selbst deine Handynummer haben wollen, aber dann bei so nem banalem Schwachsinn die Grätsche machen. Peinlich für Youtube/Google.

Das, wie hier mehrfach im Thema genannt, auf "menschliches Versagen" zu schieben ist vollkommen falsch. Denn um die Absicherung der Session, kann sich der User in keinster Weise drum kümmern. Das liegt komplett auf Anbieterseite.

Das betrifft hierbei allerdings nur Sessions und Cookies. JWTs haben prinzipiell die gleichen und noch mehr Probleme, allerdings sollte man diese auch nicht für Sessions verwenden (was man aber natürlich tut).

Naja, falls das wirklich das Problem war, muss Youtube/Google nachbessern. Der Anwender kann da gar nichts machen.

 

[CoMo]

Das Tokens einer aktiven Session unverschlüsselt in einem nicht geschützten Speicherbereich liegen wäre hochgradig Kokolores, das glaube ich erst wenn ich es sehe.

Und da soll jetzt einer zu dir kommen und dir das bei dir zeigen? Schau es dir halt selbst an. Firefox Cookies werden in der cookies.sqlite in deinem Profilverzeichnis gespeichert.

 

[Falc410]

Das Tokens einer aktiven Session unverschlüsselt in einem nicht geschützten Speicherbereich liegen wäre hochgradig Kokolores, das glaube ich erst wenn ich es sehe.

Dann schau halt selbst nach???

Unter Windows speichert Firefox standardmäßig Cookies in einem Profilordner, der in der Regel wie folgt zu finden ist:

C:\Users\<Benutzername>\AppData\Roaming\Mozilla\Firefox\Profiles\<Profilname>.default\cookies.sqlite

Der genaue Pfad kann je nach Windows-Version und Firefox-Version leicht abweichen. Beachten Sie auch, dass der Ordner "AppData" standardmäßig ausgeblendet ist.

Für Chrome sind die Cookies in der Regel in folgendem Pfad gespeichert:

C:\Users\<Benutzername>\AppData\Local\Google\Chrome\User Data\Default\Cookies

Auch hier kann der genaue Pfad je nach Windows-Version und Chrome-Version abweichen und der Ordner "AppData" ist standardmäßig ausgeblendet.

 

[Piktogramm]

Ich rede hier nicht von der PW-Sammlung die man über den Browser abspeichern kann. Die liegen auf der Festplatte, aber verschlüsselt. Das Tokens einer aktiven Session unverschlüsselt in einem nicht geschützten Speicherbereich liegen wäre hochgradig Kokolores, das glaube ich erst wenn ich es sehe.

Beim Firefoox die cookies.sqlite im Profilordner, have fun

Und selbst wenn es der Browser verschlüsselt, dann liegt es im Browser unverschlüsselt vor, wenn der gestartet und das Masterpasswort eingegeben wird. Wenn der Angreifer im Userspace sitzt und damit Dateien vom Profilordner des Browser modifzieren kann, bekommt man da auch Javascript eingeschleußt, um Cookies, Passwörter zu extrahieren bzw. Keylogger (auf Browserebene) einzubinden.

Um Angriffe vom Userspace auf den Userspace zu erschweren, muss man die Computernutzung SEHR unbequem machen. Da kann man selbst in hochsensiblen Bereichen zuschauen, wie die Nutzer selber anfangen Prozesse zu hacken, um um die Sicherheitsmaßnahmen drumherum zu arbeiten. 5Minuten Aufwand um ja nicht das Passwort einzutippen und den Hardware 2FA zu stecken -.-

 

[CoMo]

Für die Ungläubigen:

Wenn ich die einfach so öffnen kann, kann das auch jedes andere Programm auf meinem Rechner, das auf den Firefox-Profilordner zugreifen kann.

Schnapp dir mit deiner Malware meine cookies.sqlite, kopier sie in dein Profil und du bist mit meinem Benutzer eingeloggt. It's that simple.

 

[Ranayna]

Es war eine .pdf.scr

Ich hab es nur am Rande verfolgt, aber war es dass genau, zumindest visuell, eben nicht?

Da soll was mit dem RTL (Right-to-Left) Steuerzeichen gewesen sein, das die echte Dateiendung verbirgt, auch wenn die Endungen eingeblendet werden.
https://unicode-explorer.com/c/202E

Was uebrigends auch unter Linux funktionieren muesste

 

[DFFVB]

Also ich find das schon spannend - war mir komplett unbekannt... das Thema geht ja noch deutlich weiter...

Im NAS - wer dort auf externe Speicheranbieter sichert, der hat da auch Auth Tokens, wenn so nen NAS geklaut wird, kann ein Angreifer auch alle diese Accounts löschen oder lesen

Weiß jemand wie Outlook / Thunderbrid das handhaben? Gleiche Kiste? Kann das einfahc ausgelesen werden?

Sonstige Bereiche in denen das ein Risiko darstellen kann?

 

[duskstalker]

Mit einer Sicherheitslücke in Windows hat das nichts zu tun.

naja doch schon, weil eine .scr datei quasi wie eine .exe ausgeführt wird aber nicht .exe als dateiendung hat. die .scr ist ein windowseigener dateityp. der scam mit der .scr endung geht schon seit einer weile so, da hätte microsoft mittlerweile eine erweiterte "wollen Sie diese Screensafer Datei wirklich ausführen" meldung einführen können - spätestens da wäre klar, dass das keine PDF ist.

 

[DFFVB]

@All Bin jetzt dazu gekommen alles mal hier zu lesen ! Sehr sehr hilfreicher Thread, DANKE an alle die dazu beigetragen haben!

Wenn dich das Thema interessiert, gibt bei YT sicherlich den ein oder anderen Prof der seine IT Sicherheitsvorlesung online gestellt hat. Das kannst du als Einstieg in die Materie nutzen.

Auf jeden Fall, wenn Du Tipps hast gerne, ich finde da insgesamt wenig zu, ein Prof zuM Thema Firewalls und einer zum Thema Kryptographie, was aber extrem mathematisch ist...

Er hätte also stutzig werden müssen, dass im vermeintlichen Dokument plötzlich PDF dabei steht.
Außerdem hätte er es im E-Mail-Programm (oder im Web-Mail) sehen müssen. Dort werden unabhängig von den Ordneroptionen-Einstellungen immer die Dateitypen angezeigt

Es war wohl so, dass es sogar eine ZIP war, die dann entpackt auf 700 MB anwuchs, dass der Virenscanner nicht anschlägt....

Das, wie hier mehrfach im Thema genannt, auf "menschliches Versagen" zu schieben ist vollkommen falsch. Denn um die Absicherung der Session, kann sich der User in keinster Weise drum kümmern. Das liegt komplett auf Anbieterseite.

Sehe ich auch so, wenn das ein bekannter Vektor ist, muss das behoben werden!

 

[BeBur]

"Regulär" (Best Practice, aber wer hält sich dran?) speichert man zur Session selbst noch irgendwelche Hinweise ab, welche den User bzw. die Session ([sehr] grob) identifizieren. Bspw. den User Agent, die IP oder irgendwas ähnliches. Hierbei kann dann also selbst beim einfachen Übernehmen (Copy + Paste) der Session ID diese nicht einfach übernommen werden, da bspw. die originale Session aus Firefox heraus erstellt wurde, die übernommene Session aber bspw. durch Edge aufgegriffen wird. "Normalerweise" sollte die Session somit invalidiert werden, einfach aus Sicherheitsgründen.

Die IP ändert sich auch bei Privatanbietern regelmäßig, das wäre sehr schlechte User Experience wenn man die Session bei jedem IP wechsel invalidiert. Alles andere kannst du faken und die notwendigen Infos auch direkt mitkopieren wenn du das Session Token kopierst.

Sehe ich auch so, wenn das ein bekannter Vektor ist, muss das behoben werden!

Da gibt es nichts zu beheben seitens Anbieter, das Session Token ist deine "haben" 1-Faktor Authentifizierung, wenn das jemand klaut, dann kann er sich einloggen. Da kann der Website Betreiber nichts dran ändern, außer eben 2-Faktor Authentifizierung verlangen die auch dann nicht ausgehebelt wird, wenn der Rechner infiziert ist. Das ist im Prinzip das, wonach jetzt alle High-Profile Influencer super wichtig Accounts schreien müssten, dass das als Option angeboten wird. Ob sie das tun? Keine Ahnung. Das wird bei Google und damit auch für youtube schon ewig lange angeboten, aber "wer hat denn für sowas schon Zeit".

 

[Piktogramm]

Sehe ich auch so, wenn das ein bekannter Vektor ist, muss das behoben werden!

Jain, Google hat ein paar Ecken wo sie ansetzen können, aber allein bekommen die da wenig gelöst. Als Linus beschrieben hat was da stattgefunden hat ist mir folgendes aufgefallen.

1. Es haben zu viele Personen Zugriff auf die YT-Kanäle
2. Die Leute mit Zugriff wickeln über den selben Rechner, selben Account (Windows und Google) sowohl externen als auch sensible interne Dinge ab.
3. Es gab keinen etablierten Prozess für "Incidence Response"
3.1. Das Invalidieren von Tokens scheint seitens LTT nicht etabliert zu sein.

 

[DFFVB]

Mir fehlt das technische Wissen, ich frage mich allerdings, ob das token nicht eine Ableitung bspw des Browserfingerprint o.ä. Sein könnte? Oder andere identifier? Die es zumindest erschweren... Aber ja kann auch gut sein, dass man sagen muss, dass es nicht anders geht, wobei mich @Yuuri s Beitrag das schon glauben lässt.

@Piktogramm ich meine das losgelöst bin linus, klar braucht niemand aus der Buchhaltung Zugriff auf n Youtube Konto. Aber ich meine wieviele Leute haben nur 1 Email Adresse, bei der die eingeloggt bleiben? Das sehe ich als massives Problem, daher auch die Frage nach Outlook /thunderbird

 

[Piktogramm]

@DFFVB
Fingerprinting ist komplett sinnlos, wenn der Angreifer einmal im Userspace bzw. Browser ist, kann nahezu beliebig modifiziert und ausgeleitet werden. Da müsste man (dauerhaft) Aufwand in ein Feature stecken welches keinen realen Vorteil bringt und im Zweifelsfall nur berechtigten Nutzern aus den Sack geht.

Es ist extrem häufig so, dass es keine gescheite Trennung zwischen verschiedenen Rollen gibt.

• Admins mit globalen Überrechten sowie Fernwartungszugängen auf alles sind extern erreichbar
• Backupserver die in der selben Domäne hängen wie der Rechner mit Kundenkontakt
• Die bunte Mischung aus privater Nutzung und unnötig ausgeweitetem Zugang zu Intranetanwendungen auf einem Account/Rechner
• uralte Software die keiner mehr im Blick hat aber ne Brücke zwischen Inter- und Intranet schlägt und deren Sicherheitslücken nur gepatcht sind, weil die Angreifer nicht so gern teilen wie sie abgreifen
• Jeder und auch der beste Freund vom Wachhund haben mindestens lokale Adminrechte

Das taugt noch nichtmal um darauf Bingokarten zu machen, es ist schlicht zu eintönig :/

Edit: Klassiker vergessen, Mitarbeiter hat sich mit Firma verkracht und trägt Zugangs-/Daten raus und auf die Frage wie der Prozess für "Revokation" ausschaut schaut der Chef wie sein Dackel..

 

[Falc410]

Auf jeden Fall, wenn Du Tipps hast gerne, ich finde da insgesamt wenig zu, ein Prof zuM Thema Firewalls und einer zum Thema Kryptographie, was aber extrem mathematisch ist...

Naja an der Uni lernt man halt auch die Grundlagen, das ersetzt keinen Hackingkurs. Es gibt aber einige Youtuber (John Hammond fällt mir da gerade ein) die als Pentester da ein wenig Wissen vermitteln. Ansonsten wenn man die Grundlagen selbst lernen möchte kann man TryHackMe ausprobieren (geht auch kostenlos, ansonsten so 10€ im Monat). Die Folien von der Vorlesung von vielen Unis sind frei verfügbar aber helfen halt auch nur bedingt weiter, da wie gesagt, sehr technisch und da geht es nicht nur um Authentifizierungsprotokolle.

daher auch die Frage nach Outlook /thunderbird

Das hängt vom Mailanbieter ab. Früher war klassisch IMAP / SMTP über Username+Passwort, welches bei jeder Verbindung übertragen worden ist. Die Programme haben diese Information "verschlüsselt" auf dem Rechner abgelegt, so ähnlich wie Windows auch seine Passwörter speichert. Ganz grob gesprochen.
Heutzutage wird auf OAuth gesetzt, welches ein wenig anders funktioniert, hier erhält man auch wieder ein Token welches mitgeschickt wird. Ich gehe davon aus, dass das Token ebenfalls verschlüsselt (oder zumindest gehashed) abgelegt wird. Interessante Frage und ich gehe stark davon aus, dass ein Angreifer auch dieses Abgreifen kann. Aber bei OAuth ist das Token soweit mir bekannt ist, noch irgendwie an den Rechner gebunden. D.h. einfaches kopieren vom Token in eine andere Anwendung funktioniert nicht. Zumindest muss ich dann bei Gmail z.B. das Emailkonto wieder neu verbinden.

ChatGPT spuckt auch gerade nicht mehr viel aus als ich eh schon wusste.

OAuth (Open Authorization) ist ein Protokoll, das es einer Anwendung oder einem Dienst ermöglicht, den Zugriff auf eine geschützte Ressource im Namen eines Benutzers zu beantragen. Es ermöglicht auch Benutzern, Anwendungen den Zugriff auf ihre Ressourcen zu gewähren, ohne ihre Anmeldedaten preiszugeben.
Das OAuth-Protokoll besteht aus mehreren Schritten:

1. Ein Benutzer authentifiziert sich bei einem Dienst (z.B. bei einem sozialen Netzwerk) und möchte einer Anwendung den Zugriff auf seine geschützten Ressourcen gewähren.
2. Die Anwendung sendet eine Anfrage an den Dienst, um eine Autorisierung für den Zugriff auf die Ressourcen des Benutzers zu erhalten.
3. Der Dienst leitet den Benutzer zur Autorisierungsseite weiter, auf der der Benutzer der Anwendung den Zugriff auf seine Ressourcen gestattet oder verweigert.
4. Wenn der Benutzer der Anwendung den Zugriff auf seine Ressourcen gestattet hat, erhält die Anwendung einen Autorisierungscode.
5. Die Anwendung sendet den Autorisierungscode an den Dienst, um ein Zugriffstoken zu erhalten.
6. Das Zugriffstoken wird von der Anwendung verwendet, um auf die geschützten Ressourcen des Benutzers zuzugreifen.
7. Das Zugriffstoken hat eine begrenzte Gültigkeitsdauer und kann bei Bedarf erneuert werden.

OAuth bietet eine sichere Möglichkeit für Benutzer, Anwendungen den Zugriff auf ihre Ressourcen zu gewähren, ohne ihre Anmeldedaten preiszugeben. Es ist ein weit verbreitetes Protokoll, das von vielen Diensten und Anwendungen unterstützt wird.
OAuth und IMAP sind zwei unterschiedliche Protokolle, die für verschiedene Zwecke eingesetzt werden.
IMAP (Internet Message Access Protocol) ist ein Protokoll, das zur Übertragung von E-Mails zwischen einem E-Mail-Client und einem E-Mail-Server verwendet wird. Das klassische Verfahren bei IMAP ist die Übertragung von Benutzername und Passwort des Benutzers an den Server, um eine Verbindung herzustellen und E-Mails abzurufen oder zu senden.
OAuth hingegen ist ein Protokoll, das zur Autorisierung von Anwendungen verwendet wird, um auf geschützte Ressourcen eines Benutzers zuzugreifen, ohne dass der Benutzer seine Anmeldedaten preisgeben muss. OAuth ist also ein Protokoll, das die Sicherheit und den Schutz von Benutzerdaten verbessert.
Ein Beispiel dafür, wie OAuth in Zusammenhang mit E-Mails genutzt wird, ist Gmail. Ein E-Mail-Client, der Gmail unterstützt, kann OAuth verwenden, um eine Verbindung zum E-Mail-Server herzustellen, ohne dass der Benutzer seine Gmail-Anmeldedaten preisgeben muss. Stattdessen wird eine Autorisierung angefordert, um den Zugriff auf die geschützten E-Mail-Daten zu erlauben.
Zusammenfassend kann gesagt werden, dass der Unterschied zwischen OAuth und dem klassischen Verfahren bei IMAP darin besteht, dass OAuth ein Protokoll ist, das zur Autorisierung von Anwendungen verwendet wird, während das klassische IMAP-Verfahren ein Protokoll zur Übertragung von E-Mails ist, das auf Benutzername und Passwort basiert.

 

[Yuuri]

Im NAS - wer dort auf externe Speicheranbieter sichert, der hat da auch Auth Tokens, wenn so nen NAS geklaut wird, kann ein Angreifer auch alle diese Accounts löschen oder lesen

Alles was unverschlüsselt vorliegt. Aber im Falle von Diebstahl, brauchst du kein Session Hijacking betreiben. Auch alles was "automatisch" geht ist potentiell unsicher. Von "sicher" kannst du nur ausgehen, wenn ein externer Faktor hinzugezogen werden muss, wie bspw. eine manuelle Passworteingabe, ein FIDO Key, ... Die Implementierung mal außen vor gelassen.

Weiß jemand wie Outlook / Thunderbrid das handhaben? Gleiche Kiste? Kann das einfahc ausgelesen werden?

https://www.nirsoft.net/utils/mailpv.html

OAuth ist ein anderes Thema, aber es werden auch nur Tokens vergeben. Falls JWTs für die Legitimität ausgegeben werden, kämpfen diese allerdings mit fehlenden Revocation Mechanismen (= Invalidierung der Sessions). Revocations klappen aber bereits bei TLS-Zertifikaten im Browser nicht (CRL, OCSP, CT).

Die IP ändert sich auch bei Privatanbietern regelmäßig, das wäre sehr schlechte User Experience wenn man die Session bei jedem IP wechsel invalidiert.

Aber ggf. das einzig probate Mittel, die Session gegen irgendwas zu härten. Bspw. wenn der User "oberschlau" ist und "anonym" sein will und seinen User Agent deaktiviert. Tja Pech, dann frisst du eben die restriktivere Pille. Auch sollte es bspw. ein PayPal oder eine Bank eher mehr interessieren, ob sich die IP oder der User Agent innerhalb der Sessionlaufzeit ändert. Aus sicherheitstechnischen Gründen wird die Session invalidiert, bevor Schabernack getrieben wird. Ob eine Bank überhaupt lang laufende Sessions erlauben sollte?

Auch ist die IP ein probates Mittel um bspw. die Session an einem Arbeitsplatz zu forcieren. Wir reden hier bei den "Handlungsempfehlungen" nicht um das, was immer gültig ist (bspw. hier das CB Tippspiel zur WM), sondern auch bspw. von Zugängen an industriellen Maschinen, wo die IP bspw. ein vollkommen probates Mittel ist, weil diese sich im typischen Aktionszeitraum sowieso nicht ändert. Auch kann eine Session nach fünf Minuten auslaufen. Vollkommen legitim, je nach Einsatzzweck.

Natürlich ist die IP für Youtube eher weniger ein Kriterium. Aber spätestens beim User Agent reicht die Verknüpfung der Session ID zum User Agent (+ Version, + 1 für evtl. Upgrades?) mindestens dazu. Welcher legitime Fall hätte eintreten sollen, dass die exakt gleiche Session ID an mehrere Browser ausgegeben werden sollte? Dass überhaupt erstmal eine Session ID doppelt vergeben werden sollte...

Alles andere kannst du faken und die notwendigen Infos auch direkt mitkopieren wenn du das Session Token kopierst.

Genau dieser Fall wird damit aktiv auf Serverseite unterbunden. Damit du eben nicht irgendwas einfach "kopieren" kannst und uneingeschränkten Zugriff erhälst. Wenn du mit jedem Request deine Daten erneut fakest, bekommst du halt keine Session. Schluss aus. Ich geh auch nicht in den Club und wechsel alle drei Minuten mein komplettes Outfit um dann dem Türsteher ein "ich war vor drei Minuten schon drin" an den Latz zu knallen.

Heute passiert das LTT, morgen ist es der Admin von Youtube. Gestern war es Atlassian, vorgestern Lastpass. Wer ist morgen dran? 2FA sollte bei sowas auch verpflichtend sein. Gerade Google, wo man für jeden Mist auf "ja, das war ich" klicken muss. Also hätten wir Session Hijacking und Credential Diebstahl abgedeckt. Bleibt mehr oder weniger nur noch eine Sicherheitslücke beim Anbieter als relevanter Angriffsvektor. Ich schließe hier die 5 $ Schraubenschlüssel-Attacke aus. Diebstahl ist ne andere Baustelle, aber hierfür muss der User selbst aktiv werden und gültige Passwörter wechseln und registrierte Tokens zurückziehen.

Jede halbwegs auf Sicherheit bedachte Firma erstellt dir einen Account und fordert dich ggf. in Anwesenheit eines Admins auf 2FA zu aktivieren.

Jain, Google hat ein paar Ecken wo sie ansetzen können, aber allein bekommen die da wenig gelöst.

Mittel gegen Session Hijacking hat einzig Google in der Hand und auch für die Sicherheit ihrer Konten ist einzig Google verantwortlich. Weil sie diejenigen sind, die die Sessions verwalten und vergeben. Gegen Account-Sharing u.ä. kann Google natürlich nicht aktiv vorgehen (außer auch die IPs und User Agents loggen), aber das ist per se auch kein gültiger "Angriffsvektor". Sehr wohl können sie aber Sessions invalidieren, wenn sich unterschiedliche Geräte von unterschiedlichen Standorten anmelden. Ggf. gar über nen längeren Zeitraum gleichzeitig.

Der letzte Request kam aus Timbuktu mit "Samsung Browser" und der jetzige Request kommt aus der Antarktis mit "curl"? Hm ja, klingt legitim. ¯\_(ツ)_/¯

Oder zumindest vor der nächsten Aktion (gerade sowas wie "Account löschen", "tausende Videos löschen" u.ä.) erneut nach dem Passwort fragen. Das hat Linus ja auch im Video erwähnt, dass es schöne tolle Rate Limits für die API gibt, aber will man tausende Videos auf einmal löschen, kann man ohne Probleme gewähren.

Fingerprinting ist komplett sinnlos, wenn der Angreifer einmal im Userspace bzw. Browser ist, kann nahezu beliebig modifiziert und ausgeleitet werden.

Genau dafür ist doch genanntes Szenario gedacht? Damit bei einem unterschiedlichen Browsern/User Agents eben nicht einfach die Session ID rüber kopiert werden kann. Genau dafür hat doch die Gegenseite sicherzustellen, dass sie nicht einfach beliebige Requests frisst und ausführt, sondern die Daten halbwegs auf Plausibilität prüft. Man fixiert sich heute extrem auf TLS und "ob der Server auch wirklich der Server ist", will MITM unterbinden und stellt Schranken noch und nöcher auf, aber bei der Richtung Client -> Server wird geschlampt wie eh und je in den 90ern?

Ja, wenn die Antwort "geht nicht" ist, dann ist Session Hijacking angesagt. Mit eben genau den Problemen, die LTT jetzt hatte. Kann man nichts machen. ¯\_(ツ)_/¯ Dabei ist eine Gegenmaßnahme so extrem billig...

Mit "geht nicht" sagt man doch nur aus, dass man den Zugang zur eigenen Infrastruktur nicht unter Kontrolle hat oder haben will, wenn man sich aktiv dagegen entscheidet. Selbst ein steinaltes os/xtCommerce oder Gambio von 2010 hatte solche erweiterten und auch deaktivierbaren Prüfungen standardmäßig drin, damit Session Hijacking aktiv unterbunden werden kann.

Mit dem gleichen Argument könnte man sagen, dass CSRF Blödsinn ist. Bis irgendwann jemand ein "Bild" (<img>) mit der URL "http://meine-bank.de/uberweisung-ausfuehren/?an=angreifer&wert=1000000" einbindet. Und jeder, der dort aktuell angemeldet ist, wundert sich, warum einem plötzlich Geld auf dem Konto fehlt. Mal abgesehen von der nächsten Lücke, dass Aktionen keinem GET-Request entsprechen sollten.

Es ist extrem häufig so, dass es keine gescheite Trennung zwischen verschiedenen Rollen gibt.

Und auch die Trennung ist egal, denn prinzipiell kann das jeder einzelnen Rolle passieren. Mit den Rollen hast du die Authorisierung (wer darf was?) im Griff, nicht aber die Authentifizierung (wer bin ich?).