Archiv verlassen und diese Seite im Standarddesign anzeigen : Admin Passwort ungeschützt
Masterphil
04.04.2012, 00:20
Nabend an euch alle, zur Zeit werden wieder massiv Leute und Seiten gehackt, auch ich war betroffen, jemand war mal eben auf meinem EF drauf obwohl dieser ein absolut sicheres Passwort hatte. (Schaden für mich war diesmal 0 zum Glück und andere Geschädigte haben ihr Lose zurückbekommen die der Hacker über meinen EF transferieren wollte)
Habe lange überlegt, der Hacker musste mein EF Passwort wissen.
Keylogger ausgeschlossen da ich davor 1-2 Monate nicht im EF war.
Nun schaue ich mal interessehalber in meine DB, Userdaten alle userfreundlich als Hashs gespeichert, , denke ich mir mal nach dem Admin Passwort schauen, im Klartext gespeichert, schaue zur EF anbindung auch Klartext.
Ich denke mal dies ist nicht Sinn der Sache das diese sensiblen Daten im Klartext dastehn.
Wir sollten hier also an einer Lösung arbeiten.
MfG
So als denkanstoß:
EF Password muss im klartext sein sonst könnte sich das script ja nicht mit deinem pw im ef einloggen und die lose der user transferieren.
Ist das Passwort im md5 hash (o.ä.) ist es für das script unbrauchbar, ist es in einem zurückverfolgbaren hash gespeichert d.h. man kann ihn wieder ins klare umwandeln, bringt es eigentlich auch nichts da, wenn sich ein hacker die mühe macht eine seite zu hacken stören die 5 min für das pw knacken auch nicht.
---------------
Die frage bei dir ist nun, wie kommt er den an die PW's, ist er direkt in die DB reingekommen (wenn ja, wei kommt er an das pw, keylogger?) oder hat eine lücke ausgenutzt wodurch er dies auslesen konnte ?
Ich glaube er meint die Eingabefelder im Adminforce, dort stehen diese in normalen input text Feldern drin. Ich habs bei mir auf input type="password" geändert, funktioniert ja genauso. :-)
Mit den in der db gespeicherten PW's hat Xenon recht, die müssen im Klartext an klamm.de gesendet werden, da müsste notfalls Klamm ne Änderung vornehmen.
dersepp33
04.04.2012, 11:51
Wie wäre es denn, wenn das EF-Passwort im Script und nicht in der DB gespeichert wird?
Masterphil
04.04.2012, 13:22
Gegendenkanstoss:
Wie bei den Usern wird das EF Passwort nur verschlüsselt gespeichert.
Dann kommt eine neue Funktion welche das Passwort dann wenn Klamm es benötigt halt entschlüsselt und dann an Klamm sendet.
Wenn dies bei den Usern klappt warum nicht auch bei dem EF ?
Und Adminforce Login halt wie bei den Usern, wenn der Admin dann doch sein passwort vergisst, kann man es in der DB ja immernoch mit einem bekannten Hash ersetzten.
Wenn sich nun jemand ins Adminforce einhackt, wie auch immer, der EF aber auch geschützt ist per Hash, guckt der Hacker blöde da er nicht ans EF Passwort kommt, und dieses zu ändern würde ihm nichts bringen.
MfG
G
Wie bei den Usern wird das EF Passwort nur verschlüsselt gespeichert.
Dann kommt eine neue Funktion welche das Passwort dann wenn Klamm es benötigt halt entschlüsselt und dann an Klamm sendet.
Wenn dies bei den Usern klappt warum nicht auch bei dem EF ?
Wenn ich dich richtig verstanden habe, meinst du dass man das EF Pw als hash speichern sollte wie bei den usern ?
Nein, dass geht nicht, da wenn sich der user einloggt und "12345" eingibt wird es in ein hash gewandelt und mit dem hash in der DB verglichen, die user hashes werden NICHT!!! entschlüsselt, das geht nicht.
Nutzt man ein zurückverfolgbaren hash/ zuentschlüsselbaren hash:
.....ist es in einem zurückverfolgbaren hash gespeichert d.h. man kann ihn wieder ins klare umwandeln, bringt es eigentlich auch nichts da, wenn sich ein hacker die mühe macht eine seite zu hacken stören die 5 min für das pw knacken auch nicht.
Das Problem ist ja meist, dass die Hacker sich Zugang verschaffen z.B über die Scripte und vms bietet da enorm viele Möglichkeiten. Was ich in den letzten Monaten noch an Möglichkeiten gefunden habe im Script selbst und vor allen Dingen auch in den unterschiedlichsten Addons, ist schon der Hammer. Die Lösung die EF daten nicht in der db zu speichern wäre an sich schon nen guter Ansatz denke ich mal. Ob es aber wirklich Sinn macht es in eine txt zu setzen bezweifle ich irgendwo, da da der Zugriff ja für nen Hacker an sich noch einfacher wird.
Besser wäre denke ich mal die Lücken weiter zu schliessen und vor Einbau eines neuen Addons wirklich zu schauen dass gerade wo User was übertragen wirklich auf Sicherheit geschaut wird. Es gibt da sooooo einfach einzubauende Sachen wie über Addslashes oder htmlspecialchar und ähnliches.
Klar, jeder Tresor ist nur so sicher bis er geknackt wird, aber wir können doch alle schauen dass wir es den Leuten so schwer wie möglich machen an unsere Daten zu gelangen
Masterphil
04.04.2012, 19:15
Wenn ich dich richtig verstanden habe, meinst du dass man das EF Pw als hash speichern sollte wie bei den usern ?
Nein, dass geht nicht, da wenn sich der user einloggt und "12345" eingibt wird es in ein hash gewandelt und mit dem hash in der DB verglichen, die user hashes werden NICHT!!! entschlüsselt, das geht nicht.
Nutzt man ein zurückverfolgbaren hash/ zuentschlüsselbaren hash:
Ok,das leuchtet natürlich ein, habe ichs mir wohl doch etwas einfach vorgestellt.
In eine Datei würde ich die EF Daten auch nicht tun wollen, reicht ja das in einer Datei schon alle Daten für die Datenbank stehen.
Gibt also mehr als eine Stelle wo man ansetzten könnte, wenn der Hacker die functions hat, hat er die DB und damit auch den EF.
MfG
Mehrere Stellen ist gut *lol*
Ich habe ein vms1.1 und bin immer noch damit zugange einzelne Dateien zu sichern, wobei das Grundscript gar nicht mal mehr das Problem ist sondern vielmehr die ganzen Addons, auch die welche in letzter Zeit geschrieben wurden oder Erweiterungen und haste nicht gesehn. Zu wenig coder achten wirklich drauf was sie da tun
... Was ich in den letzten Monaten noch an Möglichkeiten gefunden habe im Script selbst ...
Im Grund-Skript selbst? Bitte hier mitteilen oder einem Admin/Mod als PN schicken, danke. :thumb: (EDIT: achso, VMS 1.1, na dann ;-)
Das Problem ist tatsächlich, dass man das EF Passwort nicht zu 100% absichern kann, es wird für die Schnittstellentranssaktionen in einer verwendbaren Form benötigt, die auch der Angreifer verwenden kann.
KLamm könnte da aufwändigere Dinge anbieten, die will aber dann eh kein Webbi benutzen :biggrin1:
Da von vielen Webbis EMailadressen bekannt sind (hoffentlich mind. die im Impressum!) kann man diesen auch einfach massig Trojaner schicken, iwann werden sie schon schwach :suspicious:
Aber, man kann das Ganze natürlich schon weiter absichern:
Passwort wird im Adminforce nicht angezeigt (auch nicht als type="password", was nur Punkte im Browser anzeigt, aber das Passwort trotzdem im Klartext vorhanden ist :frusty:)
Passwort verschlüsseln
Ob man es nun in der Datenbank speichert oder in einer Datei, ist relativ egal, man weis ja vorher nicht, ob der Angreifer nun Zugriff auf die DB oder FTP bekommt :wink:
Zum Verschlüsseln gibt es diverse Methoden, allerdings muss dazu immer ein Schlüssel gespeichert werden, außer der Webbi soll diesen bei jeder Transaktion von Hand eingeben. Damit dieser Schlüssel nicht dem selben Problem wie das EF Passwort unterliegt, muss dieser nicht in der SQL Datenbank und auch nicht über den FTP erreichbar gespeichert werden.
Also nur eine Lösung für Webbis mit root-Zugriff auf ihren Server, und selbst dann ist es noch denkbar, dass der Angreifer einfach die Schnittstellen Datei via gehacktem FTP manipuliert, und dadurch an das Passwort kommt.
Ergo den Großteil der Lose in EF-Tresor, Auszahlungssumme auf der Seite begrenzen und tägl. die EF Transaktionen kontrollieren....
Jo jpwfour, vms1.1 aber bitte glaube mal nicht das die erhöhten Versionen besser sind, es beginnt mit der Userprofil und endet im Grunde genommen im Admin ................ Wenn ich Dir jeden gefundenen bug oder Fehler senden sollte, sorry, da bin ich länger als nur nen paar Tage beschäftigt mit. Warum? weil ich mittlerweile so ziemlich alles komplett durch gehe und die einzelnen Variablen weitgehend absichere. Die verschiedenen Zusatzmöglichkeiten kennst Du ja.
Was ich festgestellt habe ganz grob ist an sich dass die 1.2 und höheren Versionen zwar das Design auf css umgestellt haben aber an sich am ursprünglichen Grundscript nur wenig verändert und auch wenig gesichert wurde. Einzelne Hauptfunktionen in der functions.lib.php o.k. jo, das gemacht worden, aber ansonsten und das das ausreichend ist kann ich nicht bestätigen.
Nehmen wir die Schnittstelle ............ ist klamm platt wird ......... Du weisst was ich meine denke ich mal und da hast an sich schon den ersten simpel ausnutzbaren "Bug"
Einfach zu beseiten durch @ noch besser zu beseitigen durch display error Off ........
Schau einfach mal durch und ich denke Du findest dann noch viel viel mehr extrem simpel ausnutzbare Geschichten
... zu beseitigen durch display error Off ........
...
Ok, sowas wird bei "solchen" Skripten dann iwie vorausgesetzt. Also dass serverseitig PHP schon ausreichend sicher vorkonfiguriert ist. Da aber viele VMS noch auf PHP4 :der: betrieben werden, Fehlermeldungen an den Aufrufer ausgegeben etc., kann manden Leuten halt auch schlecht helfen.
.htaccess Passwortschutz fürs Adminforce wird an vielen Stellen empfohlen, machen aber auch nur wenige. Sicherheit kommt zum Großteil durch den Webbi selber.
Wenn ich dran denke, wie viele PNs ich der Art bekomme:
"Du, kannst du mir nicht Addon XY einbauen? Addon & FTP Daten im Anhang"... :rolleyes:
Das jeder "Progger" mit den FTP Daten automatisch Komplettzugriff erlangt, ist Vielen wohl nicht bewusst oder es stört sie nicht (solang bis dann doch was passiert).
Ein paar Webbis konnte ich immerhin von der Nutzung einer Versionsverwaltung (bspw. SVN) überzeugen, das schützt nicht nur vor Angreifern, sondern hauptsächlich vor unsachgemäßem Verhalten des Webbis und der sg. "Progger" :thumb:
Wir reden hier nicht von irgendwelchen Versionen und ob php4 oder php5, sondern davon, dass einfach sehr sehr viele Addons kaum bis keine Variablen Absicherung haben und das so ebenfalls jedem Tür und Tor geöffnet ist.
Klar die Mails kannste mal Daten im Anhang *lol* o.k. da sind sich viele nicht klar drüber was sie da wirklich tun. Gerade Neulinge im Net sind da doch zu vertrauensselig und schauen auch nicht danach wer das ist der ihnen da was machen soll. Habe da auch schon so einige Klamotten erlebt *lol*
Was mir aber immer wieder auch auffällt ist z.B. wenn bei vms ein update kommt *lol* ............. tolle Sache, aber alte Fehler bleiben drin. .......... *lol*
z.B. die Geschichte mit dem reload der fehlte oder immer noch fehlt??? in der topframe_forced
und viele viele weitere Kleinigkeiten
Es kann doch nicht Sinn der Sache sein ein Update heraus zu bringen wo alte Fehler nicht bereinigt werden oder wo z.B. sicherheitsrelevante Sachen die bekannt sind nicht gefixt sind ................... sorry, das ja so als kaufe ich nen frisch auf den Markt gekommenes Auto wo der Motor fehlt oder die Bremsen runter sind oder so was
Wir reden hier nicht von irgendwelchen Versionen und ob php4 oder php5, sondern davon, dass einfach sehr sehr viele Addons kaum bis keine Variablen Absicherung haben und das so ebenfalls jedem Tür und Tor geöffnet ist.
Klar die Mails kannste mal Daten im Anhang *lol* o.k. da sind sich viele nicht klar drüber was sie da wirklich tun. Gerade Neulinge im Net sind da doch zu vertrauensselig und schauen auch nicht danach wer das ist der ihnen da was machen soll. Habe da auch schon so einige Klamotten erlebt *lol*
Was mir aber immer wieder auch auffällt ist z.B. wenn bei vms ein update kommt *lol* ............. tolle Sache, aber alte Fehler bleiben drin. .......... *lol*
z.B. die Geschichte mit dem reload der fehlte oder immer noch fehlt??? in der topframe_forced
und viele viele weitere Kleinigkeiten
Es kann doch nicht Sinn der Sache sein ein Update heraus zu bringen wo alte Fehler nicht bereinigt werden oder wo z.B. sicherheitsrelevante Sachen die bekannt sind nicht gefixt sind ................... sorry, das ja so als kaufe ich nen frisch auf den Markt gekommenes Auto wo der Motor fehlt oder die Bremsen runter sind oder so was
Dies ist korrekt so wird auch in zukunft nicht mehr passieren...
nur aktuell steht bei mir noch was vorrangig vor einem update des VMS.
Gut, wenn Du so weit bist gib Bescheid, evtl, wenn ich dann auch Zeit habe können wir das gern gemeinsam in Angriff nehmen
.htaccess Passwortschutz fürs Adminforce wird an vielen Stellen empfohlen, machen aber auch nur wenige. Sicherheit kommt zum Großteil durch den Webbi selber.
Man könnte dazu noch den ordner umbenenn, ganz nachdem motto:
domain.de/sds8df79sg0fgfdsnzdfgzndgs8q56d87f5sdfb/
so, nun kann keiner das adminforce finden außer dem admin. der kann das als lesezeichen o.ä. abspeichern falls er sich das nicht merken kann :biggrin1:
Masterphil
05.04.2012, 11:24
Man könnte dazu noch den ordner umbenenn, ganz nachdem motto:
domain.de/sds8df79sg0fgfdsnzdfgzndgs8q56d87f5sdfb/
so, nun kann keiner das adminforce finden außer dem admin. der kann das als lesezeichen o.ä. abspeichern falls er sich das nicht merken kann :biggrin1:
Hört sich nach einer guten Idee an, jedoch müssten dann alle Pfade im alten Adminforce angepasst werden, und fast jede Datei gecheckt werden.
Also erstmal sollten wir das AdminPassowrt selbst nur noch verschlüsselt speichern, hier könne wir ansetzten, es ist eine kleine Änderung. Übers We werde ich mich da mal ranmachen wenn keiner zuvorkommt.
MfG
Hört sich nach einer guten Idee an, jedoch müssten dann alle Pfade im alten Adminforce angepasst werden, und fast jede Datei gecheckt werden.
Nein, da die links so sind, dass man den link ohne probleme ändern kann (hatte ich auch schon so gemacht). Und auch wenn es nicht gehen sollte, macht man replace "adminforce => sds8df79sg0fgfdsnzdfgzndgs8q56d87f5sdfb"
Also erstmal sollten wir das AdminPassowrt selbst nur noch verschlüsselt speichern, hier könne wir ansetzten, es ist eine kleine Änderung. Übers We werde ich mich da mal ranmachen wenn keiner zuvorkommt.
MfG
einfach bei pageconfig.php da wo er es einsätzt, folgendes amchen die md5hash funktion eingeben (md5hash(); oder so)
auron2008
05.04.2012, 21:56
Hört sich nach einer guten Idee an, jedoch müssten dann alle Pfade im alten Adminforce angepasst werden, und fast jede Datei gecheckt werden.
Nö weil relative Pfade verwendet werden :thumb:
Nö weil relative Pfade verwendet werden :thumb:
Nein, da die links so sind, dass man den link ohne probleme ändern kann (hatte ich auch schon so gemacht). Und auch wenn es nicht gehen sollte, macht man replace "adminforce => sds8df79sg0fgfdsnzdfgzndgs8q56d87f5sdfb"
*Zeichen voll*
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.