vBulletin Cookie Verschlüsselung

[mgutt]

Hallo!

Ich habe ein Problem mit diversen Opera- und FF3-Nutzern und Cookies. Mittlerweile habe ich herausgefunden, dass es große Probleme gibt, wenn man bei jedem Autologin ein neues Autologin-Cookie setzt (ist aus Sicherheitsgründen bisher bei mir so geregelt).

Nun sagen mir alle diese Nutzer, dass sie bei vBulletin-Foren diese Probleme nicht hätten. Nun frage ich mich wie vBulletin das ganze abarbeitet.

Ich habe leider nur eine ältere 3.6.1 Version von vBulletin zur Hand und da habe ich grob überschaut keine Verbindung zu dem USER_AGENT gefunden bzw. mein Test hat ergeben, dass unabhängig von Browser und IP immer die gleiche Autologin-ID (=password-hash) generiert wird.

Was ich von der aktuellen Version weiß ist, dass es nicht von der IP abhängig ist. Auch ist das Cookie nicht komplett vom USER_AGENT abhängig, denn nach einem Update ist das Autologin-Cookie auch noch aktiv. Nehme ich aber meine Cookie-Daten z.B. aus FF3 und schreibe sie in Opera in das Cookie, dann bin ich nicht eingeloggt. Also gehe ich mal davon aus, dass die aktuelle Version von vBulletin nun folgendes macht:
- ignoriert IP
- setzt nur eine Autologin-ID in Abhängigkeit zum Passwort, vermute mal nen Salt und dazu noch einen kleinen Teil des USER_AGENTs

Bis hier hin war ich mir soweit sicher, das vBulletin den Namen des Browsers ohne die Versionsangabe speichert.

Nur ein 2. Test hat dem widersprochen. Ich habe die Daten von einem Freund genommen und wir haben beide FF3 und seine Daten haben nicht funktioniert. Also verarbeitet vBulletin scheinbar die Cookies nicht nur fehlerfreier, sondern auch sicher.

Was genau verarbeitet vBulletin, damit sowas funktioniert? Werden noch andere Daten neben dem USER_AGENT in die Berechnung der Autologin-ID einbezogen (=password-hash) und vor allen Dingen wie :P

Gruß
Marc

EDIT:
Also das verstehe ich nicht. Ich habe eine vB Version 3.6.1 und eine 3.7.0 Beta, beide haben eine einfache MD5-Verschlüsselung des Passwortes und die User-ID ist gar nicht verschlüsselt. Ich kenne aber ein Forum mit vB 3.6.7 wo PW und User-ID scheinbar mit SHA1 oder ähnlichem verschlüsselt wurden. Hat jemand so eine Version zufällig zur Hand und kann mal schauen? Gerne schaue ich auch selber, falls mir jemand einen temporären Zugang einräumen kann.

[cortex]

Zitat von mgutt

Mittlerweile habe ich herausgefunden, dass es große Probleme gibt, wenn man bei jedem Autologin ein neues Autologin-Cookie setzt (ist aus Sicherheitsgründen bisher bei mir so geregelt).

du nennst eine autologin-funktion in einem atemzug mit sicherheit...?

möchte dir nicht zu nahe treten / versteh mich bitte nicht falsch, aber aus deinen bisherigen beiträgen gewinne ich zunehmend den eindruck, dass du überwiegend an symptomen / pitfalls herumdokterst, anstatt sicherheit als wesentlichen teil des anwendungsdesigns zu verstehen. das "grosse bild" wird sehr ausführlich in diesem buch behandelt; es ist für fortgeschrittene anwender wie dich zugeschnitten.

cx

[mgutt]

Hi!

Danke, etwas für die Sammlung ;)

Den Eindruck gewinnst Du deshalb, weil ich mich neben der Sicherheit, auch um die Performance kümmere. Ich will also die Sicherheit, aber nur mit der bestmöglichen Performance. Daher überdenke ich aktuell alle bestehenden Routinen.

Ich kenne mich im Hacking ganz gut aus. Also external file inclusion, internal file inclusion, xss oder mysql injection ist alles kein Thema. Ich weiß auch worauf es bei Cookies ankommt, habe nur aktuell Probleme mit FF3 und Opera 9, weil bei mir die Autologin-Cookies (aus Sicherheitsgründen) bei jedem View überschrieben werden. Die beiden Browser mögen das nicht. FF3 nimmt irgendwann identische Cookies doppelt an und Opera 9 sperrt gänzlich den Zugriff auf das Cookie. Beides vermutlich Browser-Bugs, aber sie treten jetzt schon so oft auf, dass ich mein System grundlegend ändern möchte.

Und nun habe ich bei vB gesehen, dass dort dieses Problem nicht existiert (weil das Autologin-Cookie immer die gleichen Daten enthält und nie überschrieben wird).

Nur was ich interessant fand ist, dass ich das Cookie eines Freundes nicht "stehlen" konnte. Und das ist das was ich mir aktuell nicht erklären kann, weil wir beide FF3 hatten. Mittlerweile bin ich durch meine eigenen vBulletin-Versionen (3.6.1 und 3.7.0 Beta) und einer umfassenden Recherche der Meinung, dass die sha-Variante, die ich bei jemanden gesehen habe, gar nicht von vBulletin stammt, sondern eine Eigenentwicklung ist. Deswegen versuche ich mich mal in der Modifikation einzelner Header, um herauszufinden, was dort verarbeitet wird und was nicht.

Das ein Autologin-Cookie keine wirkliche Sicherheit bietet, weiß ich selber, aber wenn das Cookie nach dem Diebstahl nicht funktioniert, hemmt das erstmal enorm.

Aktuell dachte ich daran die user_id und das pw jeweils als hash in Cookies zu hinterlegen. Und zwar so:

PHP-Code:

if ($user_browser_version >= BROWSER_VERSION) {
   $user_pw_hash = md5(FILE_SALT . BROWSER_NAME . OS_NAME . PROVIDER_NAME . USER_SALT . md5(USER_PW));
   $user_id_hash = md5(FILE_SALT . BROWSER_NAME . OS_NAME . PROVIDER_NAME . USER_SALT . md5(USER_ID));
} 


Legende:
FILE_SALT = Dieser Salt kommt aus einer Datei. Der Hacker benötigt also FTP-Zugriff um den Hash nachzubilden. Wenn sich diese Datei dann noch außerhalb des Roots befindet, ist die Sache "perfekt".

BROWSER_NAME = Hier nur die "Marke" des Browser (ie, ff, opera, usw.). Nur die Marke, damit der Autologin nach einem Update auch noch funktioniert. Verhindert zum Teil den Cookie-Diebstahl, weil der Browser des Diebes identisch sein muss.

BROWSER_VERSION = Enthält die Browserversion des Besuchers, während $user_browser_version, die Version des letzten Logins enthält. Das Cookie wird nur dann akzeptiert, wenn die übermittelte Browserversion größer oder gleich der vom letzten Login war. Sofern also jemand das Cookie klaut und eine ältere Version einsetzt, wird das Cookie abgelehnt.

optional PROVIDER_NAME = Hier die "Marke" des Providers (arcor, telekom, aol, etc.). Der einfachste Weg wäre es die letzten 6 Stellen des Hostnamens zu extrahieren (in den Logfiles war "qsc.de" das Kürzeste, was ich finden konnte). Das Problem ist nur, dass gethostbyaddr() ziemlich lahm sein kann (falls IP nicht im DNS / DNS nicht erreichbar) und daher sollte man alle IPs nur einmal prüfen. Das gibt dann recht viele Datensätze, ist also unter Umständen etwas suboptimal. Auch kann ein Nachteil an der Sache sein, dass der User ausgeloggt ist, sofern er sich in verschiedenen Netzen bewegt. z.B. mit seinem Laptop im Büro und dann noch mal zu Hause. Das bekommt man in den Griff, wenn man mehrere Hosts zulässt z.B. max. 2. Auch das schützt vor Cookie-Diebstahl. Der Hacker müsste sich mit dem gleichen Provider einloggen, damit er das Cookie gebrauchen kann.

optional OS_NAME = Hier der Typ (2000, XP, VISTA, MAC, usw.). Ansonsten identisch mit BROWSER_NAME.

USER_SALT = Dieser Salt ist Teil der User-DB-Tabelle und demnach Unique

$user_id_hash = Auch als Hash, damit ein gestohlenes Cookie keinem bestimmten User zugeordnet werden kann.

P.S. die Sache mit dem besagten vBulletin-Forum ist übrigens geklärt. Dort wird der komplette HTTP_USER_AGENT als Salt verwendet. Entsprechend ist nach einem Update des Browsers oder nach einer Installation eines Plugins, dass den USER_AGENT beeinflusst (z.B. Office), der Autologin nicht mehr aktiv. Die letzte Bestätigung werde ich dazu bekommen, sobald es wieder ein Update von FF gibt.

[cortex]

grüss dich,

Zitat von mgutt

Das ein Autologin-Cookie keine wirkliche Sicherheit bietet, weiß ich selber, aber wenn das Cookie nach dem Diebstahl nicht funktioniert, hemmt das erstmal enorm.

ich habe auf äusserungen wie diese abgezielt, als ich vom sicherheitsgerichteten anwendungsdesign sprach und einem - IMHO - mangelnden verständnis deinerseits. dass du dich nach eigenen aussagen im hacking ganz gut auskennst... ich wage gar nicht, deine fähigkeiten zu bezweifeln - deine aufzählung möglicher angriffsklassen ist schon beeindruckend. allerdings sprach ich vom big picture - dort liegen u.u. deine schwächen.

das konzept eines automatischen user-logins läuft jedem bestreben, eine anwendung so sicher wie möglich zu machen, zuwider - dass ein autologin-cookie gar sicherheit bietet (ob nun wirklich oder scheinbar)... nun gut, du machst das schon.

cx

[mgutt]

Ja es sind ja "nur" Community-Logins.

Sollte jetzt keine Grundsatzdiskussion werden. Ich streite nicht ab, dass Autologin unsicher ist. Aber wenn man es braucht, muss man ja nicht gleich das Passwort in Klarschrift hinterlegen ;)

Falls noch jemand Anmerkungen zur Hash-Generation machen möchte, dann immer her damit.

[mgutt]

Also ich bin weg von allen Werten außer PROVIDER_NAME.

Alle anderen Werte lassen sich über den User-Agent nachbilden. D.h. wenn der Cookie-Dieb einfach hingeht und das Cookie mit den gleichen Agent Angaben schickt, hat er das System bereits ausgehebelt. Browser geht vielleicht noch gegen Noobdiebe, aber Browserversion wäre zu nervig, weil der Nutzer ständig ausgeloggt wird, wenn er ein Update macht (was bei Firefox ja nicht selten ist).

PROVIDER_NAME ist allerdings eine nette Sache, die mir nicht aus den Kopf geht und die ich bisher nirgends gesehen habe. Da muss der Dieb erstmal wissen, dass er sich nur über den Anbieter des Bestohlenen einloggen kann. Das macht das ganze gleich in mehrfacher Hinsicht sicher, da er erstmal über einen Proxy an eine solche IP kommen muss, ansonsten könnte man ihn ja strafrechtlich verfolgen.

Was würde gegen die Nutzung von Folgendem als Salt für den Autologin-Hash sprechen?

$provider_name = substr(gethostbyaddr($_SERVER['REMOTE_ADDR']), -6);

[vt1816]

Dabei vergisst Du aber dynamische bzw. unauflösbare IP-Adressen.

[mgutt]

Also unauflösbare kann ich nachvollziehen. Die müsste man dann außen vor lassen. Aber dynamische IPs decke ich doch ab?!

z.B. sehen die Provideradressen so aus:
Arcor: dslc-082-083-101-004.pools.arcor-ip.net
Alice DSL: e183144165.adsl.alicedsl.de
Telekom Modem & ISDN: p5b063fab.dip.t-dialin.net
Telekom DSL & ATM: p5098c516.dip0.t-ipconnect.de (von [url=http://board.gulli.com/thread/718488-t-com-t-ipconnect-statt-t-dialin/#3]hier[7url])
Hansenet: d121138.adsl.hansenet.de
Kabel Deutschland: 188-193-41-235-dynip.superkabel.de
Unity Media: ip-88-153-90-13.unitymediagroup.de
Telefonica Deutschland: brmn-4d0adee7.pool.mediaways.net
usw.

Die Struktur erscheint mir immer gleich zu sein. Erst kommt die IP als Subdomain, dann der Host. Und ich extrahiere ja nur die letzten 6 Stellen, so dass ich doch eigentlich kein Problem bekommen dürfte (alternativ könnte ich auch die komplette Domain extrahieren). Oder wechseln die Anbieter auch die Domains? Spontan kann ich in meinen Logs nichts finden.

[DokuLeseHemmung]

Du meinst, wenn ich meinen Laptop mal woandershin mitnehme, dann tuts das Dauerlogin nicht mehr, weil du das als Angriff wertest?
Verrückt!

[vt1816]

Zitat von mgutt

[...]
Die Struktur erscheint mir immer gleich zu sein. Erst kommt die IP als Subdomain, dann der Host. Und ich extrahiere ja nur die letzten 6 Stellen, so dass ich doch eigentlich kein Problem bekommen dürfte (alternativ könnte ich auch die komplette Domain extrahieren). Oder wechseln die Anbieter auch die Domains? Spontan kann ich in meinen Logs nichts finden.

Du hast zum Beispiel AOL vergessen. Da kann jede Anfrage von einer anderen IP-Adresse kommen.