Beiträge von zagon

ich hab doch hier heute einen beitrag gepostet...
inhalt:
no comment?

mfG
Zagon

earlyhost,

>>ist nicht gerade nett (nett ausgedürckt)

ja das dacht ich mir, aber nochmal, es ist absolut nicht böse gemeint!

zu den Variabeln.

ich übergebe bei einem Link im query eine variabel...

URL.de/index.php?_POST[conf]=2

zB...

nun, dieses _POST ist so wie jedes query als _REQUEST (ein array) index (array-key) zu finden.

$_REQUEST[_POST][conf] = 2 sollte es heißen.

nun, wenn du durch dieses request läufst - bei dir mittels foreach - und dann jeden array index als variabelnamen anlegst... dann hast du quasi eine "junk" $_POST variabel angelegt.

und da beginnt der fehler.

foreach($_REQUEST as $key => $val)
{
 if (isSet ($_REQUEST[$key])) $$key = $_REQUEST[$key];
 // wenn hier nun der erste key _POST ist...
 // dann gilt:
 // if (isSet ($_REQUEST[_POST])) $_POST = $_REQUEST[_POST][conf];
 // -> unfeine geschichte, weil wir jetzt ohne per POST datenübertragung eine POST superglobale angelegt haben.
}

wie du nun siehst, hat dieses _POST nichts mit einem per zB Formular mit method="POST" übergeben zu tun... ist aber dann später im PHP durch das script doch das gleiche.

hier 2 testscripts:
das erste zeigt die art und weise, wie du es im script hattest...
also das zerlegen der _REQUEST Superglobal und das anlegen der einzelnen keys als variabel...
http://www.zagon.at/test/globals2_.php

und hier nun das script mit dem gefilterten _REQUEST.
http://www.zagon.at/test/globals_.php

siehst du was ich meine? die normale $_POST variabel geht durch den filter, eh klar.

wieso meinst du stellt man sich die register_globals auf off?
du machst mit den paar zeilen aus einem server mit register_globals off, einen mit on.

deswegen besteht auch die möglichkeit, $securityconfig[scriptblocker] zu erstellen, weil du die $securityconfig noch vor der foreach schleife in der global.php aus der Datenbank ausliest und erstellt.
ich überschreibs dann einfach per URL-Query...

also, sry, ich wollte dich nicht beleidigen! ich hab dir schon etwa 4 mal geschrieben, dass ich deine arbeit bewundere, weil du als firmenfremde person für die sicherheit einer software beitragen möchtest.

mfG
Zagon

PS:
>>Klar jeder macht Fehler und du bist auch nciht gerade perfekt!

um gottes willen, ich will auch nicht perfekt sein und bins auch nicht - zum glück, denn auch ich bin ein mensch.

Zitat

Original von DodCom
also ich fand es nicht toll das zagon mit meinem nick im forum herumgesurft ist

da bin ich froh....das er nur ne lücke aufgedeckt hat :]

das war nicht dein nick.
dazu hätte ich deinen password hash gebraucht.
um das gings auch nicht, sondern darum, mit fremden scripten am forum zu spielen (flooden, regflooding etc..., im ungepatchten forum per script nach dem admin pwt hash zu suchen etc...).

mal wertefrei, der programmierstil erinnert an einen anfänger (hm, ne net so arg) eher leicht fortgeschrittenen, da dachte ich, ein paar tipps kommen schon nicht in die falsche kehle... ich will um gottes willen niemanden beleidigen oder schulmeistern!!!

grüße
Zagon

>>gewähre ich keine Sicherheit

die gewähre ich bei den standard systemen auch nicht (nicht mehr, nachdem was ich sehe)
... wo ich trotz ip sperre in dodcoms forum surfen konnte durch diese lücke.

>>earlyhost wird schon auf Leute eingehen, die ihm kompetent erscheinen
keine sorge, ich erwarte mir nichts. zeitmangel etc.

aber wenn ein tool schon security heißt, soll es die auch bieten. wenn mir was auffällt, werd ichs doch posten dürfen, oder wollt ihr das nicht. kanns auch einstellen

mfG
Zagon

weil dodcom freundlich nach einer lösung gebeten hat, hab ich ihm eine "NOTlösung" geschickt, die klappt...
(es ist somit auch ein fix für die $bedingung die bisher ohne weitere maßnahmen in die datenbank gesandt wurde. (addslashes udgl...))

es ist in der security.php des boardroots zu suchen:

$request = $_REQUEST;
foreach ($request as $key => $temp) {
  if (isset($_REQUEST[$key])) $$key = $_REQUEST[$key];
}

und ausnahmslos durch das zu ersetzen:

$_disabled = array('_POST', '_GET', '_SERVER', '_COOKIE', '_REQUEST', '_FILE', 'securityconfig', 'bedingung');


foreach ($_REQUEST as $key => $temp) {
  if (isset($_REQUEST[$key]) AND !in_array($key, $_disabled)) $$key = $_REQUEST[$key];
}

diesen programmierstiel gewöhnt man sich eher ab.

mfG
Zagon
PS: geht mit der basic 2.0.0 und der jetzt aktuellen pro. (2.0.1 ??)

ja, scheint aber mit gewissen einstellungen zusammen zu hängen,

weil bei euch kommt sowieso jede Referer adresse ohne block durch?! oder nur weil ich eingelogged bin (trusted user?!)

ka, wie gesagt, ich spreche für die / von der basic...

mfG
Zagon

ich lösche den link zu deinem forum sollt dich jedoch nicht weiter beunruhigen (der link selbst).

wieder einschalten brauchst du es nicht, es ist nur für den einen aufruf abgedreht.

ich weiß nicht, was du einsetzt, ich habs auf meinem testforum nur mit dem basic script getestet. das kann man eben für den einen aufruf deaktivieren.
ansonsten kann ich dir eine lösung zukommen lassen.

=)

>>warum arbeitet ihr nicht zusammen:
weil auch ich meine projekte habe, die mir zeit rauben
ich habe ihn jedoch darauf hingewiesen, das müsste langen. das problem hier ist ja in 1 sec behoben.

nichts, nur das securitysystem abschalten, mehr net.

hier 2 testbilder:
das zweite konnte ich nur als gif speichern, ich hab hier in der arbeit nur MS Paint, das zickt ständig rum.

ja, hast recht, hätte ich hier auch zeigen können, sry.
ich versichere dir, es macht nichts schlimmes.

das erste bild (das größere) zeigt, wie man ins forum reinkommt, obwohl das script meinen client gesperrt hat - siehe bild 2?

nur für den testlink! er tut ja nichts böses.

aha...

und wie nennen wir das:
http://www.web-dev.at/forums/wbb/thread.php?threadid=12

(dodcom, sry, ich hab jetzt schnell dein board genommen als bsp.)
mfG
Zagon

Hallo,

ja, ich hätte dazu sagen müssen... die Boardroot security.php ist "unsicher".
es geht jetzt um flooding tools, oder zB um die SQL-injection bei ungepatchten foren, weil fremdscripte nicht mehr geblockt werden. nicht um die "übernahme" des acp.

man kann sich selbst seine Superglobalen erstellen lassen durch dein script.
_POST, _GET, _COOKIE, etc... alles kein problem.
oder eben andere arrays, wie in dem fall die securityconfig[xcy]...

auch das wbb selbst versäumt es, die Superglobalen nach dem zu filtern, aber es erzeugt wenigstens nicht wie dein script aus jedem Superglobal key eine variabel.

was meinst du mit dem:
>>zu bedenken ist aber, dass die wenigsten Server diese Zeilen überhaupt benötigen.

welche zeilen benötigen die wenigsten server?

>>Nocheinmal: Diese Sicherheitslücke kann nur ausgenützt werden, wenn das Script schon nicht ganz fehlerfrei programmiert wurde.

ja, das ist in deinem script (boardroot/security.php) der fall.

>>Dazu reicht schon die SQL INjection im $_POST. $_GET ist da meistens gar nciht nötig...

???

mfG
Zagon

PS: es ist dir keiner böse,
>>auch wenn das vielleicht einige nicht befriedigen aknn

ich wollt dir nur zeigen, dass in der datei unsicher programmiert wurde.

PPS:
dieser Fehler wäre in 2 sekunden gepatched...

Jawohl

das hier:
>>dennoch ist eine phrase wie "ja wir tun schon" für die klientel nicht zufriedenstellend. mM
(tippfehler)

war in dem sinn nicht mehr auf dich bezogen, wir kennen diese antworten aus anderen bereichen *gg

grüße
Zagon

sry, hab mich verlesen.
dann nehm ich natürlich mein geschwafel in dem post (sicherheitsaspekte in der security.php) zurück!

dennoch ist eine phrase wie "ja wir tun schon" für die klientel nicht zufriedenstellent. mM

grüße und nochmal sry
Zagon

@earlyhost:
das erinnert mich an Woltlab... "Ja, wir tun eh schon". wer wir? und wann?
sonst kein kommentar zu der lücke?

Bist nicht der meinung, dass diese Fehler einer sofortigen reaktion bedürfen?
schließlich wirkt der fehler so, als gäbe es dein addon nicht am server.

DodCom...
ich hab deinen link gelesen, leider ist nicht jeder sein eigener server"admin".
hardened php hab ich deswegen aus dem text entfernt, hat keinen weiteren sinn, darauf einzugehen. ich kenns selbst nur vom lesen, aber es hat mich soweit interessiert, dass ichs mal local testen werde.

mod_security kann man wahrscheinlich kicken, wenn man sauber programmiert...

Die Schablone wird mMn nicht benötigt im moment...

Wird diese Codezeile auch in der Security Pro verwendet?

$request = $_REQUEST;
foreach ($request as $key => $temp) {
  if (isset($_REQUEST[$key])) $$key = $_REQUEST[$key];
}

dank dieser schleife ist es einem möglich, den scriptblocker, die ipprüfung udgl. fein auszuschalten.

ob eine injection in dem script möglich ist, weiß ich noch nicht, habs noch nicht versucht. in den sql query kann man aber recht viel übergeben. ungeprüft werden variabeln an die datenbank gesendet...

So viel gemütlichkeit muss mMn nicht sein, dass man ALLE Superglobalen variabeln umwandelt...

mfG
Zagon

PS: Nachtrag -> auch bei der Pro scheint es zu gehen...
So wie es also jetzt ist, bietet es recht wenig schutz...

wie wäre es damit, das bild zu verschieben, in einen ordner, der für public "offen" ist?

Hy

@Module:
Man kann doch module hinzufügen, über den ACP link "Sicherheitsmodule (0)"

klickt man da drauf, kommt eine grafik, die einem eine procedur dauer nachahmen soll. wenn die seite fertig geladen hat, erscheint ein forumular, mit dem man per HTTP moduldateien hochladen kann/installieren kann.

klick ich jetzt auf "Modul installieren", ein button neben dem dateifeld, so lädt das teil, und zeigt mir dann einen fehler:

Zitat

Es traten ein/mehrere Fehler auf. Bitte behebe die Fehler!

Enpacke das Modulverzeichniss und lade den gesamten Inhalt in das Verzeichnis acp/security/module/.
weiter.

eh klar... ich habe ja nichts eingetragen.

klick ich auf "weiter":

Zitat

Warning: file(): Unable to access ./security/module/info.txt in /forums/acp/security_module.php on line 104

Warning: file(./security/module/info.txt): failed to open stream: No such file or directory in /forums/acp/security_module.php on line 104

Warning: Invalid argument supplied for foreach() in /forums/acp/security_module.php on line 105

Warning: Cannot modify header information - headers already sent by (output started at /forums/acp/security_module.php:104) in /forums/acp/security_module.php on line 217

wohl auch klar, es gibt die dateien ja nirgends.

und nun gehe ich retour auf die liste durch klicken des ACP links "Sicherheitsmodule (0)":
..bild im anhang.

du trägst also inhalt in die Datenbank ein, ohne zu prüfen oder bevor du prüfst, ob daten da sind.

grüße
Zagon

Nachtrag: habs bild vergessen.

Forumversion: wbb 2.3.2
Sicherheitssystem: [ ] pro [X] basic
Version des Sicherheitssystems: v 2.0.0

PHP Version: völlig egal
MySQL Version: auch egal

Hy,

mir sind Kleinigkeiten aufgefallen:
* der link im welcome menü des ACP "» Meldung(en) akzeptieren" funktioniert nicht, da er keine fürs ACP erforderliche SID mit sich führt.

* Module laden: es wird zwar eine fehlermeldung gezeigt, wenn der ordner module leer ist, es wird aber dennoch ein leeres modul in der liste gezeigt.

Kein Fehler, aber ein kleiner Aufruf:
* Man kann sich trotz Security System von fernen Rechnern registrieren, sprich, ein spamregister schutz ists nicht, es sollte möglichst auf 2.3.3 umgestiegen werden um die captcha bilder zu bekommen, oder man sollte sich irgend ein addon einpflegen, das dies ermöglicht (mit besseren captchas).

zu dem captcha bild im ACP noch eine kleinigkeit:
recht unsicher, da mehr oder weniger einheitliche schriftfarbe, keine verzerrung, keine drehung etc... und kein hintergrund.
wobei, das standardbild von woltlab ist auch keine sicherheit.

feine arbeit, der rest
mfG
Zagon