LTT Hack - generelle Bewertung Session Token / Auth Token

DFFVB

Rear Admiral
Registriert
Dez. 2015
Beiträge
5.602
Hallo zusammen,

nachdem LTT gehackt wurde, hab ich mir das mal etwas angeschaut, und die Malware hat Session Tokens geklaut... ich wusste nicht, dass diese so transportabel sind. Bzw. einfach ausgelesen werden und dann eingesetzt werden können. De facto ist das ja wie nen im Browser gespeichertes Passwort, mit dem Unterschied, dass es abläuft / beim ausloggen gelöscht wird. Hätte gedacht, das wird im TPM gespeichert bzw. es gibt flankierende Schutzmaßnahmen, wie Gerätedaten, die auch imitiert werden müssten...

Hat dazu jemand mehr Infos, wo man das nachlesen kann/ was das für praktische Implikationen hat?
 
DFFVB schrieb:
Bzw. einfach ausgelesen werden und dann eingesetzt werden können.
Na ja, so einfach war das dann doch nicht. Es war ein Mitarbeiter, der versucht hat, ein als .pdf getarntes irgendwas aus der Mail eines Sponsors zu öffnen. Darin war ein Programm, die die ganzen Session-Daten des Browsers kopiert und verschickt hat.
Also war auch hier der Angriffsvektor wieder menschliches Versagen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Xero261286
ghecko schrieb:
Also war auch hier der Angriffsvektor wieder menschliches Versagen.
naja ein PDF zu öffnen würde ich nicht als menschliches Versagen werten. wohl eher eine ungepatchte schwachstelle im pdf reader.
 
ghecko schrieb:
Also war auch hier der Angriffsvektor wieder menschliches Versagen.
Das wird er wohl auch immer bleiben. Aber man kann es mitunter nicht mal vorwerfen, wenn ich sehe, wie frappierend authentisch und vor allem schlüssig (wohl das größere Problem) manche Phishingmails daherkommen mittlerweile.

Aber ja, durch die Vielzahl gehackter YT-Kanäle der jüngeren Vergangenheit ist auch mir das Thema Session Token überhaupt erst so in den Fokus gerückt. Hatte ich vorher auch nicht so recht auf dem Radar.


honky-tonk schrieb:
... wohl eher eine ungepatchte schwachstelle im pdf reader.
Es war keine PDF-Datei. Es war eine .scr (Screensaver) Datei getarnt als PDF samt Icon. Man KÖNNTE es erkennen, aber je nach Rahmenbedingung auch leicht übersehen.
 
  • Gefällt mir
Reaktionen: DFFVB und honky-tonk
honky-tonk schrieb:
naja ein PDF zu öffnen würde ich nicht als menschliches Versagen werten. wohl eher eine ungepatchte schwachstelle im pdf reader.

So wie ich mitbekommen habe, war das keine echte PDF, sondern eine Windows screensaver Datei getarnt als PDF.

also eine Sicherheitslücke in Windows.
 
  • Gefällt mir
Reaktionen: cruse und honky-tonk
Um an Session Cookies zu gelangen, benötigt man erst mal psysischen oder Remote-Zugang zum System. In diesem Fall war wohl durch eine Malware Remote-Zugang gegeben.

Und das "PDF" war wohl eine ausführbare Datei und kein PDF. Also keine Sicherheitslücke, sondern klassisches menschliches Versagen.
 
Oder man blockt auf dem Mailserver generell Anhänge mit ausführbarem Inhalt.
Klar es ist leider wirklich so einfach Session Cookies zu klauen. Da gibts keinen Schutz durch die UAC, unzureichenden Schutz durch Google selbst (was Linus im Antwortvideo darauf ja auch anspricht) und vor allem unzureichende Reaktion des Supports bei einem so offensichtlichen und verbreiteten Angriff.
 
  • Gefällt mir
Reaktionen: LukS
... oder man verwendet ATP Sandboxing bei Email-Anhängen.

So lustig wie die Truppe und deren Videos sind, als Firmen-ITler stellt es mir doch hin und wieder die Nackenhaare auf. (Stichwort Selbstbauserver, etc.)
 
  • Gefällt mir
Reaktionen: MortyMcFly und DFFVB
ghecko schrieb:
Darin war ein Programm, die die ganzen Session-Daten des Browsers kopiert und verschickt hat.

Und genau da würde ich ansetzen, warum ist das so ohne weiteres möglich?

duskstalker schrieb:
Sicherheitslücke in Windows

Ich weiß nicht, ob es da sist, ein Programm was ich ausführe liest Informationen aus teilt sie mit... der einzige Vorwurf wäre, ggf dass die Ziel IP als malicious erkannt sein könnte und folglich geblockt sein sollte?

CoMo schrieb:
Und das "PDF" war wohl eine ausführbare Datei und kein PDF. Also keine Sicherheitslücke, sondern klassisches menschliches Versagen

Genau und daher sollte man so Session Tokens schon sicherer gestalten...
 
Die Screensaver Datei installierte einen Trojaner, der wiederum kopierte die Session Tokens und versendete diese.

Mit Zugriff auf das Gerät eines Benutzers kann man mit genug Aufwand praktisch alle Sicherheitsmechanisment aushebeln. Da nützt auch TPM etc. nicht viel, da ich ja den Zugriff darauf habe.

Wie die Vorredner schon sagten, gegen menschliches Versagen helfen nur Sensibilisieren und Trainings.
 
ghecko schrieb:
Sicher? Würde mich ziemlich wundern wenn die Tokens einer aktiven Sitzung außerhalb des RAM abgelegt werden.
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
 
es ist oft bei medienwirksamen "hacks" (deren exploit nichtmal aktuell sein muss) so, dass sich im nachgang die fragen/diskussionen in die tiefen der it-sicherheitstheorie und auf der anderen seite in die "welche person/software/hardware war schuld" aufsplitten. und dann gehts immer hin und her "ja aber man hätte keinen anhang einfach öffnen dürfen" "ja aber mailserver-scanner hätte es schon abfangen müssen" "ja aber mit dem neuen cvs-1234 patch für outlook wäre es nicht passiert, also klarer fall von updates vergessen..." etc.

auch denken vielleicht viele bei solchen news: "oh jetzt gibt es eine neue einfache möglichkeit meine accounts zu übernehmen, ohne dass ich viel dagegen tun kann."


wichtig zu verstehen ist einfach, dass hier

- eine schadsoftware im email anhang weder vom mailserverfilter, noch vom lokalen antivirus, noch vom user als solches erkannt wurde.

- diese schadsoftware vom user ausgeführt wurde

- ohne schadsoftware kein zugriff auf den rechner und sämtliche daten möglich gewesen wäre!!

- der zugriff auf das dateisystem des rechners ein abgreifen von systeminformation, geräteid(s), session data+cookies von allen installierten browsern, sonstigen identifiern möglich gemacht hat. sprich, der rechner musste kompromittiert werden, um an die sessiondaten und systemidentifier zu kommen.

- diese daten es ermöglichen ein für die gegenstelle (youtube/google, etc.) glaubwürdiges abbild des originalrechners vorzuspielen und somit den zustand "eingeloggt" auf diesem klon-rechner (in kontrolle des "hackers") ohne zutun, aber natürlich mit viel präziser vorbereitung, zu erhalten. vielleicht hat der angreifer dazu noch versucht eine location recht nah zum originalrechner zu spoofen. z.b. schlagen dienste alarm wenn man sich von einer sekunde auf die andere mit einer ip vom anderen ende des globus einwählt. aber wenn du mal ins café um die ecke gehst oder zu nem kumpel dann hast du dort ja auch gleich dein youtube/facebook/etc. offen und musst dich nicht erneut einloggen obwohl die ip wechselt.

hieran sieht man auch, dass komfort bei diesen großen sozialen diensten einer sicherheit vorgezogen wird, bei dieser form von angriff jedenfalls. denn natürlich könnte man sitzungen auch serverseitig ablaufen lassen, wie bei fritzbox z.b., oder auch tatsächlich bei wechsel der ip einen relogin verlangen. aber das wäre nicht "komfortabel".
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: M-X
Sind wir mal ehrlich, das ist alles nichts neues. Nur mit zunehmender Verbreitung im Neuland werden die Probleme halt breiter bekannt. Technisch muss bei dir irgendwo dieser Token liegen, wenn der irgendwo liegt, kannst du den auch klauen. Und was TPM angeht, schau mal wofür das da ist, das hat überhaupt nichts mit irgendwelchen Tokens zu tuen.

Zum Glück haben die Browser/Webserver mittlerweile mehr Schutzmaßnahmen gegen XSS, CSRF und wie sie alle heißen an Bord. Damals (TM) konntest du noch leichter Schindluder treiben, in der Uni haben wir mal die Tokens einer anderen Website ausgelesen. Die Zeiten sind heute vorbei, wenn nicht eben ein total dusseliger Web Dev sein erstes Projekt live setzt und von dem ganzen Zeug noch nichts gehört hat.

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.

ghecko schrieb:
Schalte mal deinen Rechner aus und an, schaue danach ob du hier bei CB noch angemeldet bist ;)
 
  • Gefällt mir
Reaktionen: DFFVB und LukS
Also mit Linux kann das genau so passieren. Ja ein Session Cookie wird dazu verwendet, dass die Webanwendung dich wieder erkennt. Wenn du dich einloggst wird ein Session Cookie auf deinem PC abgelegt und nicht im TPM sondern ganz normal auf der Festplatte. Der Browser schickt das bei jedem Request an die Webseite mit damit der Server weiss, wer du bist. Wann die Session beendet wird bestimmt erst einmal die Webanwendung. Deine Bank wird dich i.d.R. nach wenigen Minuten ausloggen, Facebook und Youtube fordern dich nur alle paar Monate auf, dich wieder neu einzuloggen.

Wenn ein Angreifer an dein Session Cookie kommt, kann er das einfach benutzen und ist dann mit deinem User eingeloggt wenn er es mit deinem Request mitschickt. Du kannst über die Entwickler Konsole im Firefox / Chrome selbst nachschauen welche Cookies eine Webseite bei dir abgelegt hat. Einfach auf einer Webseite irgendwo rechts hinklicken und auf Inspizieren gehen. Allein auf Computerbase sieht du da einige.

Wie jetzt ein Angreifer an die Session ID kommt ist unterschiedlich. Wenn der Browser eine Schwachstelle hat, bzw. veraltet ist, reicht es schon aus wenn du auf einer Webseite bist auf der bösartiger Code ist. Über Javascript kommt man über eine Zeile an die Session dran. Wenn die Webseite noch dazu eine XSS Lücke hat, könnte ein Angreifer bösartigen Javascript auf einer vertrauenswürdigen Seite unterbringen. Dagegen kannst du dich nicht schützen, ausser du benutzt NoScript und verbietest Javascript (ist aber nicht praktikabel). Immerhin greifen Browser nicht mehr auf Session Cookies von fremden Seiten zu (also die nicht zum aktuellen aktiven Tab gehören). Aber auch hier gibt es immer wieder Umwege wie das doch klappt.

Wenn du natürlich ein anderes Programm hast was bösartigen Code ausführt wie jetzt z.B. ein PDF Reader oder ein Office Dokument mit Makros etc. dann kann dieser Code einfach die Session Cookies von der Festplatte lesen. Die müssen ja zugreifbar sein, da dein Browser i.d.R. mit denselben User-Rechten läuft wie dem User mit dem du angemeldet bist. Da kannst du dich also gar nicht vor schützen, ausser eben nur vertrauenswürdige Programme ausführen und regelmässige Updates einspielen oder eben Dinge nur in einer Sandbox ausführen / öffnen die dann keinen Zugriff auf die normalen Daten der Festplatte haben. Aber alle Programme die du mit deinem User startest, können auch in deinem Browser-Profil Ordner lesen.

Deswegen ein paar allgemeine Tipps:
Wenn du in einer kritischen Seite eingeloggt bist, nicht gleichzeitig mit dem selben Browser in einem anderen Tab auf anderen Seiten surfen (Stichwort XSS oder CSRF - letzteres kommt zum Glück kaum noch vor). Und immer auf ausloggen klicken - das sollte (sofern die Webanwendung korrekt programmiert ist) die Session serverseitig invalidieren.
 
  • Gefällt mir
Reaktionen: DFFVB und LukS
duskstalker schrieb:
So wie ich mitbekommen habe, war das keine echte PDF, sondern eine Windows screensaver Datei getarnt als PDF.

also eine Sicherheitslücke in Windows.
Es war eine .pdf.scr
Die Ordner-Optionen sind standardmäßig so konfiguriert, dass bekannte Dateitypen ausgeblendet werden.
Somit sieht es im Explorer so aus, dass es sich um eine PDF handelt. PDF gehört aber hier zum Dateinamen.
Zumal PDF ebenfalls als bekannter Dateityp ausgeblendet wird.

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.

Mit einer Sicherheitslücke in Windows hat das nichts zu tun.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: CoMo und Redundanz
Zurück
Oben