Sicherheitsverletzung!! Zugriff wurde verweigert!

[badknight]

wenn du in jeder Datei die FTAN auskommentieren willst, kannst du auch gleich auf eine 2.8.1 installation gehen

[spawnferkel]

Hallo,
das will ich eigentlich nicht, deswegen habe ich ja auch geschrieben, dass ich noch nach einer "richtigen" Lösung suche.
viele Grüße
Alexander

[jacobi22]

Sehe ich auch so,
Sinn und Zweck der Sache ist eben u.a., jedes ankommende Formular auf Echtheit zu prüfen und das Wort Jedes muß man eben wörtlich nehmen. Alles, was im Backend läuft, wird über Formulare eingestellt, das Anlegen von Seiten, Ändern von Einstellungen, Einfügen der Inhalte, Bilderuploads, eben alles.

[mlennartz]

Sinn und Zweck der Sache ist eben u.a., jedes ankommende Formular auf Echtheit zu prüfen und das Wort Jedes muß man eben wörtlich nehmen. Alles, was im Backend läuft, wird über Formulare eingestellt, das Anlegen von Seiten, Ändern von Einstellungen, Einfügen der Inhalte, Bilderuploads, eben alles.

Richtung, aber wenn eine echtes Formular als gefälscht eingestuft wird, läuft einiges schief.

Und wenn - so bei mir - dieses zickige Verhalten der 2.8.2 dazu führt, dass ich die Installation auf 2.8.1 zurück setze, habe ich wirklich unglaublich viel an Sicherheit gewonnen. Machen wir uns doch nichts vor: Open Software und Interpreter-Sprachen sind potentiell unsicher.

[spawnferkel]

Hallo zusammen,

ich würde mich freuen, wenn wir den Dialog wieder auf das eigentliche Thema zurück führen könnten. 100%ige Sicherheit wird es nun eh nicht geben, ob nun OS oder nicht. Wie kann ich es schaffen, dass meine Installation läuft ohne Zeilen auskommentieren zu müssen? Also wenn ich der Einzige sein sollte, der das Problem noch hat, dann ist es mir ehrlich gesagt nicht so wichtig. Aber ich denke es werden noch weitere Benutzer auf dieses Problem stossen und ich finde es sehr schade, dass es dafür keine (zufriedenstellende) Lösung gibt.

lg

Alex

[BlackBird]

Fakt ist, daß es tatsächlich keine zufriedenstellende Lösung gibt. Ich habe mit 2.8.2-Installationen das gleiche Problem wie Du, die sind bei mir komplett unbedienbar. Kannst Du auch hier im Forum nachlesen. Das Problem haben viele. Neulich hab ich über 30 Anläufe gebraucht, um einen Typo in einer WYSIWYG-Sektion zu korrigieren. Hätte ich DB-Zugriff gehabt, hätte ich das per direktem Eingriff gelöst. Ich werde wohl künftig die Wartung von 2.8.2-Installationen ablehnen müssen.

Was meinen Ton gegenüber Dietmar angeht, das ist eine lange Geschichte, die hier nicht aufgewärmt werden muß.

Wenn man eine Gültigkeitsdauer von 24 Stunden programmiert und sich dann wundert, daß das tatsächlich so funktioniert ("Wir wüßten selber gern, woran das liegt") - sorry, dann ist irgendwas Grundlegendes faul. Sicherlich ist es so, daß es bei manchen _trotzdem_ problemlos funktioniert, bei anderen hingegen nicht. Da aber klar ist, daß es irgendwo bei der FTAN zu suchen ist, sollte es wohl möglich sein, das Problem zu lokalisieren. Wenn ich Zeit hätte, würde ich es vielleicht sogar selber suchen, allein schon deshalb, weil es mich aufregt, wenn ich meine Kunden nicht mehr richtig betreuen kann, aber leider habe ich keine.

Du könntest folgendes noch versuchen:

* Lösche die Cookies
* Lösche, wenn möglich, die vorhandenen Sessions (auf dem Server)
* Probiere es von einem anderen PC
* Probiere einen anderen Browser, z. B. eine Portable-Version

Wenn es dann immer noch nicht klappt: Installiere 2.8.1. Ich persönlich bin der Meinung, daß der Zuwachs an Sicherheit durch die FTAN nicht so gewaltig ist, daß man sich den Ärger antun muß. Aber das ist _meine_ _ganz_ _persönliche_ _Meinung_, die niemand teilen muß.

[jacobi22]

ich würde mich freuen, wenn wir den Dialog wieder auf das eigentliche Thema zurück führen könnten.

das Thema hatte nicht gewechselt 

Was hattest du denn gemacht? Vers 2.8.2 komplett neu aufgesetzt oder bei einem Update Teile der Installation überschrieben oder oder? Da siehst du schon, das das ziemlch komplex ist. Wenn das Problem bei jedem auftritt, kann man sagen, hier läuft was verkehrt, aber so sind die Voraussetzungen immer anders. Einer macht ein Upgrade "nach Gefühl", tauscht nur bestimmte Sachen, einer nach Anleitung, man nutzt unterschiedliche Browser mit unterschiedlichen Einstellungen etc.  Das Verhältnis Downloads zu Fehlerrückmeldungen mit brauchbaren Hinweisen zur Fehleranalyse ist so klein, das man da keine Schlußfolgerungen ziehen kann. Persönlich glaub ich (bis mich jemand eines besseren belehrt), das es ein Sessionproblem ist, was aber auch heißen würde, das man es mit einem bereinigtem System (Cache, temp-Ordner, Sessions leeren) wieder zum laufen bekommen müßte. Da ich das Problem selbst nicht habe, gehe ich auch davon aus, das ich z.b. deins, sofern die Installation auch dem Original entspricht) ohne diese Fehlermeldung bedienen könnte. Aktuell habe ich 5 2.8.2.-Installationen im Web mit 17 Redakteuren und von denen hat keiner je diese Fehlermeldung gesehen, wenn ich von meinen jeweils nach Einrichtung und vor Umstellung des SecureSwitch erschienenden Meldungen mal absehe.

Dein Problem, so denke ich, liegt in deinem ersten Posting

ich habe gerade von 2.8.1 auf 2.8.2 geupdated und bin auf auch dieses ominöse Problem gestossen. Jetzt habe ich hier gerade viel über das Admin-Tool SecureSwitch gelesen, aber dies erscheint gar nicht in meiner AdminTool liste. Habe ich was falsch gemacht beim Update oder muss das Tool Extra installiert werden?

Ich hätte alle Ordner bis auf pages, media, deinem Template und die Module, die nicht in der Basisversion drin sind, also nachträglich installiert wurden, geleert und aus dem aktuellem DL Paket mit SP1 wieder neu reinkopiert. Im SecureSwitch habe ich den Secretwert geändert in eine persönliche Kombination, die Secrettime steht bei mir auf 3600, die IP-Kontrolle auf 4 (bei mir Okay, da ich eine Fest-IP habe). Als Cleanerprogramm nutze ich CCleaner, da ich viel mit verschiedenen Browsern arbeite, geht das Bereinigen so schneller als wenn ich jeden Cache einzeln leere.
Ob das alles bei dir etwas nützt, kann ich nicht sagen, ich glaub, wenn das überall so funktioniert, wäre ich der Held - auch, wenn die Ursache für das Problem damit nicht gefunden ist.

[spawnferkel]

Hallo zusammen,

danke erstmal für die ausführlichen Antworten.

Ich habe zum Glück nicht die Sorge, dass ich eine Kundeninstallation zerschossen habe, unsere WB Install. ist eher für interne Zwecke.

Als ich mich für die Version 2.8.2 entschieden habe, habe ich dies natürlich auch wegen der Sicherheit aber hauptsächlich wegen den BugFixes und der neuen JQuery Version.

Jetzt steht bei den Release Notes: "Hinzufügen der SecureForm.mtab.php die unter der Pflege der WebsiteBaker Community steht. Mit dem optionalen SecureForm Switcher, lässt sich zwischen SingleTab und MultiTab hin und her schalten."

Da steht ganz klar, dass es optional ist und ich frage mich da nur, warum kann man in dem SecureSwitcher nicht einen einfachen "An" und "Ausschalter" implementieren.

Weiterhin fehlt mir eine Dokumentation über diese FTAN. Wie funktioniert sie? Unter dem Handbuch für Entwickler finde ich gar nichts?! Ich denke Ziel dieser FTAN-Geschichte müsste es doch auch sein, dass Entwickler es in die eigenen Module mit übernehmen können.

Mir erscheint das alles sehr unausgegoren, dass ist natürlich nur meine pers. Meinung und soll keines Falls die Arbeit der Menschen kritisieren, die viele Stunden investieren, um das CMS sicherer zu machen.

Ich werde jetzt einfach auf die 2.9 warten und hoffen, dass dann alles wieder "Out-Of-The-Box" funktioniert. Persönlich finde ich es sehr schade, dass man dieses Problem nicht an der Wurzel packen kann, da ich mir vorstellen kann, dass es immer wieder Benutzer geben wird, die dieses Problem haben werden und die soll man dann alle auf diesen Thread verweisen mit dem Hinweis: "Derzeit weiß niemand genau woran das liegt" Das ist bitter.

Ich habe es jetzt auf jeden Fall mit verschiedenen Browsern und verschiedenen Betriebssystemen probiert und nach einer Anleitung die zum Upgraden befolgt habe. Wünsche allen noch weiterhin viel Erfolg bei der Arbeit mit und an Websitebaker und bedanke mich herzlichst für die Hilfestellungen, besonders bei BlackBird, Dietmar und Uwe. Bis bald mal wieder. Alexander

[BlackBird]

Wenn es für interne Zwecke ist, ist Sicherheit doch eigentlich nicht so wichtig, oder?

Meiner Ansicht nach kannst Du problemlos die 2.8.1 nehmen. Die läuft stabil und macht wenig Zicken. Du solltest nur das Backup-Modul deinstallieren, sofern der Server öffentlich zugänglich ist. (Also nicht nur im Intranet erreichbar.) DAS hat nun WIRKLICH eine gravierende Sicherheitslücke.

[DarkViper]

...
Das Verhältnis Downloads zu Fehlerrückmeldungen mit brauchbaren Hinweisen zur Fehleranalyse ist so klein, das man da keine Schlußfolgerungen ziehen kann. Persönlich glaub ich (bis mich jemand eines besseren belehrt), das es ein Sessionproblem ist, was aber auch heißen würde, das man es mit einem bereinigtem System (Cache, temp-Ordner, Sessions leeren) wieder zum laufen bekommen müßte.
...

Mit der Schlussfolgerung liegst Du schon fast richtig. Auch ich habe hier schon x-fach versucht, den Fehler bewusst zu reproduzieren, habe es aber noch nicht eindeutig geschafft. Im Ausschlussverfahren konnte ich jedoch die 'etwas' unsaubere, rudimentäre Sessionverwaltung von WB, dabei speziell das Sessioncookie zu 99% als Fehlerquelle lokalisieren. Die originale Klasse SecureForm läuft unverändert in anderen Programmen mit stabiler Sessionverwaltung einwandfrei und ohne den bekannten Fehler auch nur einmal zu zeigen.
Für mich bedeutet das, dass einer der nächsten Fixes ein neues Sessionhandling enthalten wird, das das leidige Problem ein für allemal beseitigen wird. Unabhängig davon ist auch eine neue Version der SecureForm in Arbeit(aus der 2.9), die Einmal-Tokens auch bei mehreren offenen Tabs/Instanzen des Browsers verwalten kann. Dass die Klasse 100% schnittstellenkompa tibel zur bisherigen sein wird, ist sicher.

...
Weiterhin fehlt mir eine Dokumentation über diese FTAN. Wie funktioniert sie? Unter dem Handbuch für Entwickler finde ich gar nichts?! Ich denke Ziel dieser FTAN-Geschichte müsste es doch auch sein, dass Entwickler es in die eigenen Module mit übernehmen können.
...

Zusätzlich zur bereits vorhandenen Inline-Doku der Klasse ist eine ausführlichere 'Einbauanleitung' in Arbeit.

Werner

[marmot]

Hallo,
nachdem auch ich mit der Sicherheit von WB konfrontiert wurde, habe ich mir mal die Zeit genommen die Sache zu untersuchen und zumindest aus meiner Sicht das Problem klar lokalisiert.
WB arbeitet mit zwei Mechanismen, nämlich der FTAN und dem IDKEY. Leider kommen sich beide in die Quere . Das Problem liegt in der SecurForm.php. Dort werden für FTAN und IDKEY Session Keys aus einem Fingerprint erzeugt. Warum man hier nicht feste Namen vergibt erschließt sich mir nicht, denn es kommt ja auf den Wert an. Jedenfalls sind die Methoden in Zeile 48 und 52 so unglücklich gewählt, dass sich z.B. für einen Fingerprint, der mit "3" beginnt und mit "d" endet der gleiche Key ergibt. Anders gesagt: FTAN und IDKEY werden mit gleichem Namen in der Session gespeichert und überschreiben sich deshalb in manchen Fällen. Da der Fingerprint unter anderem vom Browserstring und der IP abhängt, erklärt sich auch, warum es manchmal geht und manchmal nicht. Man kann einfach einen der Keys kürzen und alles sollte gut sein. Also z.B. aus Zeile 52

Code:

substr($this->_fingerprint, hexdec($this->_fingerprint[strlen($this->_fingerprint)-1]), 16);

die Zeile

Code:

substr($this->_fingerprint, hexdec($this->_fingerprint[strlen($this->_fingerprint)-1]), 14);

machen.
Ich schlage vor die Sache mal ernsthaft zu testen, bevor hier gepsotet wird, dass es nicht funktioniert .

Grüße

[BlackBird]

Bei dem ursprünglich vorgeschlagenen Verfahren, auf dem NorHei's Patch basiert (oder basieren sollte), wäre das Speichern der FTAN oder eines sonstwie gearteten ID-Keys in der Session unnötig gewesen. Schade, daß sich das nicht durchgesetzt hat; es hätte sicherlich einige Fehler vermeiden können.
Wollen wir hoffen, daß marmot's Analyse endlich Abhilfe bringt!

[DarkViper]

@marmot:
grummel.. hätte ich eigentlich sehen müssen, dass bestimmte Zeichenpaare den identischen Offset ergeben.
Aber wie so oft, sieht man manchmal den Wald vor lauter Bäumen nicht.
Nichts desto trotz...  eine entsprechend modifizierte Version ist bereits im Test..  thx.

[NorHei]

Hatte doch gesagt da stimmt was nicht, ich bekomm gelegentlich noch Sicherheitsverletzu ngen, da muß was kollidieren   

@marmot
Gute Arbeit !

[BlackBird]

Hmmm... Mir ist jetzt aufgefallen, daß man bei einer "Sicherheitsverletzu ng" einfach nur ein paar mal F5 drücken muß, um die Aktion zu wiederholen. Irgendwann geht's dann. Ist _das_ jetzt nicht eigentlich eine Sicherheitsverletzu ng? (Ernst gemeinte Frage, mir scheint das doch dem Konzept zuwider zu laufen.)

[jacobi22]

Sehe ich nicht so. Der authentifizierte Absender ist ja auch beim Reload immernoch der Gleiche. Hast du denn die Änderungen von marmot mal eingebaut? (es gab auch schon eine gepatchte Version der SecureForm.php, finde aber den Link dazu gerade nicht)

[BlackBird]

Ja, schon, aber wenn beim ersten Absenden eine Sicherheitsverletzu ng festgestellt wurde, müßte sie ja auch beim Reload noch vorhanden sein. Die Frage ist halt, was passiert, wenn das erste Absenden WIRKLICH eine Sicherheitsverletzu ng war und der Hacker dann einfach oft genug F5 drückt?

Den Patch kann ich nicht einbauen, ist nicht mein Server / meine WB-Installation. Spielt für die eigentliche Frage aber auch keine Rolle, denke ich.

[DarkViper]

Die Frage ist halt, was passiert, wenn das erste Absenden WIRKLICH eine Sicherheitsverletzu ng war und der Hacker dann einfach oft genug F5 drückt?

Falls kein gravierender Rechenfehler in der Auswertungsroutine steckt, könnte eventuell eine positive Validierung bei Wiederholungen nur erfolgen, wenn die gesendeten Daten zwischendurch immer wieder neu manipuliert werden.
Ein Druck auf F5 ist ja nichts anderes, als den vorhergehenden Request mit identischen Daten zu wiederholen. Auch kann der beschriebene Fehler nur auftreten, wenn mehrfach verwendbare Tokens(FTANs) verwendet werden. Auch die Verwendung eines konstant gleichen Namens für den Tokenwert ehöht das Risiko deutlich.

Aus genau diesen Gründen benutzt die originale SecureForm ausschließlich OneTime-Tokens, bei denen sowohl der Name als auch der Wert zufällig generiert werden.
Man kann meinetwegen zufällig den richtigen Namen erraten, kaum aber gleichzeitig auch noch den richtigen Wert. Sobald ein gültiger Name ein einziges mal mit einem falschen Wert übergeben wird, wird der Name sofort aus der Liste gelöscht und kann daher kein weiteres Mal benutzt werden.
Die Wahrscheinlichkeit, auf Anhieb 2 unterschiedliche, je 16-stellige Hexzahlen ( ~3,4^38 = 340.282.366.920.938 .463.463.374.607.43 1.768.211.456 Möglichkeiten ) zu erraten ist doch um viele Potenzen geringer als das immer so verniedlichte Restrisiko eines Supergaus im nächstgelegenen AKW.

Seit heute ist übrigens die neueste, originale SecureForm im Test, die erst mal MultiTabs erlaubt und zudem mit zeitlich begrenzten OnTime-Tokens arbeitet. Sie wird die nächsten Tage als Fix oder evt. auch schon im SP2 verfügbar sein.

[einteik]

Seit heute ist übrigens die neueste, originale SecureForm im Test, die erst mal MultiTabs erlaubt und zudem mit zeitlich begrenzten OnTime-Tokens arbeitet. Sie wird die nächsten Tage als Fix oder evt. auch schon im SP2 verfügbar sein.

Wird die SVN wiederbelebt? Gerne will ich Tests an Websitebaker Projekten durchführen in Testumgebungen. Eine Betaversion oder eine öffentliche Entwicklung wie bei OS Projekten üblich denke ich hilft.

[BlackBird]

Aus genau diesen Gründen benutzt die originale SecureForm ausschließlich OneTime-Tokens, bei denen sowohl der Name als auch der Wert zufällig generiert werden.

Was heißt jetzt "die originale"? Auf dem betreffenden Server ist der Multitab-Patch nicht aktiviert. Sollte das dann nicht "die originale" sein?

[jacobi22]

"Die Originale"  - damit ist wohl die SecureForm.php gemeint, die mit WB 2.8.2 bis Version 1506 SP1 geliefert wurde. Diese läuft u.a. mit den Grundeinstellungen "Singletab"

Um den Sicherheitsfehler auszuschalten haben einige auch verschiedene Funktionen manupuliert oder auch deaktiviert, darum wohl die Betonung auf "originale"

Gerne will ich Tests an Websitebaker Projekten durchführen in Testumgebungen.

Ich persönlich teste neue CMS-Versionen erst mal für mich bevor ich meine Kunden damit "überfalle"

[DarkViper]

Ich habe in meinem obigen Post die SecureForm.php als 'original' bezeichnet, um sie deutlicher von privat gepatchten Versionen sowie der SecureForm.mtab.php (Multitab) zu unterscheiden.

Im Moment wird das SP2 vorbereitet, das dann neben einer Menge anderer Fixes auch bereits die aktuellste Version der SecureForm enthält.

Zusätzlich ist derzeit auch eine völlig überarbeitete SecureForm in Arbeit und wird (allerdings erst nach dem SP2) als HotFix zu Testzwecken veröffentlicht. Diese Version beherrscht dann von Haus aus auch MultiTab und beseitigt dadurch die derzeitige, leichte Versions-Verwirrung.

[isd]

Wann wird es denn das SP2 nun geben?
Oder alternativ: Wie kann man das Problem der Sicherheitsverletzu ngen im FF beheben?

1. Änderung der SecureForm.php wie von marmot vorgeschalgen.
2. Umgestellt auf Multitab.
3. Cache geleert.
4. config.php um 'WB_SECFORM_SECRETTI ME' ergänzt

=> Alles ohne Erfolg. Sicherheitsverletzu ng bleibt 24 STd. bestehen. Das nervt gewaltig!

[Luisehahne]

Gehe mal auf Downloadseite und lade dir dann auch zusätzlich das Hotfix runter

Dietmar

[ruebenwurzel]

Hallo,

Wann wird es denn das SP2 nun geben?

Ist bereits seit einiger Zeit auf dem Markt: http://www.websitebaker2.org/de/download/neueste-version.php

1. Änderung der SecureForm.php wie von marmot vorgeschalgen.

Würde ich nicht machen, nimm bitte unverändert die Datei, die im SP2 drinne ist

2. Umgestellt auf Multitab.

Das behebt auf jeden Fall das Problem wenn die neueste Datei aus dem SP2 genommen wird.

3. Cache geleert.

Ist nie verkehrt

4. config.php um 'WB_SECFORM_SECRETTI ME' ergänzt

Hab ich auch noch nie gebraucht, versuch es bitte mal ohne diese Ergänzung.

Bin gespannt auf das Ergebnis.

Gruß
Matthias