Thema: Sicherheitshinweis - Google Code Search

Zitat von DietmarH

Das kann ich mir nicht vorstellen. Ein korrekt konfigurierter Apache liefert keine ungeparste *.php aus.

Nein, die php files liefert er glücklicherweise noch nicht.
Es geht wirklich "nur" um gepackte Dateien. bzw. Verzeichnisse die keine index.html/php/etc. enthalten.

Zitat von elkuku

Nein, die php files liefert er glücklicherweise noch nicht.
Es geht wirklich "nur" um gepackte Dateien. bzw. Verzeichnisse die keine index.html/php/etc. enthalten.

Jetzt stimmt mein Weltbild wieder

Um ganz ehrlich zu sein: Wer in Verzeichnissen, in denen mod_autoindex wegen fehlender Direktive aktiv wird, irgendwelche Dateien mit vertraulichen Daten lagert, ist ein kleines bißchen wahnsinnig. Nicht umsonst liegt bei Joomla in jedem Verzeichnis, das an sich nur Datendateien enthält, eine leere index.html.

Zitat von DietmarH

Jetzt stimmt mein Weltbild wieder

Um ganz ehrlich zu sein: Wer in Verzeichnissen, in denen mod_autoindex wegen fehlender Direktive aktiv wird, irgendwelche Dateien mit vertraulichen Daten lagert, ist ein kleines bißchen wahnsinnig. Nicht umsonst liegt bei Joomla in jedem Verzeichnis, das an sich nur Datendateien enthält, eine leere index.html.

Zitat von Brian Teeman

I have found the passwords of numerous sites that have the backup archive in directories that do not allow directory listing eg /

???
Ich denke, man sollte die User im Moment grundsätzlich dazu bewegen, ihre komprimierten Backups nicht auf dem Server zu lagern.

Hier gibt's noch FAQs (in Englisch):
http://www.google.com/help/faq_codesearch.html
Dort schreiben sie auch, dass sie angeblich die robots.txt respektieren... naja

Zitat von elkuku

???

Ich hab's (noch) nicht ausprobiert. Mir ist nach der Beschreibung von mod_autoindex noch nicht ganz klar, ob ein Listing nicht trotz existierender index.html explizit angefordert werden kann.

Ich denke, man sollte die User im Moment grundsätzlich dazu bewegen, ihre komprimierten Backups nicht auf dem Server zu lagern.

Das ist grundsätzlich eine gute Idee, nicht nur jetzt. Ein Archiv in einem frei zugänglichen Verzeichnis ist durch nichts gegen Herunterladen geschützt. Security by obscurity war noch nie ein wirklich funktionierender Schutz.

Bei .htaccess/.htusers geschützten Verzeichnissen sehe ich nach dem derzeitigen Kenntnisstand allerdings kein Problem. Da läßt der Apache nur tatsächlich autorisierte Zugriffe zu.

Dort schreiben sie auch, dass sie angeblich die robots.txt respektieren... naja

Selbst wenn der Google-Bot sich daran hält: Es ist keine wirksame serverseitige Sperre, die einen böswilligen Bot ausbremsen kann, sondern mehr ein üblicherweise wirkungsloses Schild "Bitte den Rasen nicht betreten". Daran hält sich auch niemand
Und in den Händen von Leuten, die auf genau diese Daten aus sind, sind die Archive noch schlechter aufgehoben als in den Google-Listen.

Also mal ehrlich: Wer sein Backup als zip oder sonst was in irgend ein Verzeichnis packt oder gar in den Webroot legt, der agiert ungefähr so fahrlässig wie ein Autofahrer, der meint, das er sowieso immer drei Ersatzreifen dabei hat... und deswegen keines im Kofferaum braucht

Zweiter Punkt: Das die configuration.php immer noch im Webroot liegt, wo man sie nicht schützen kann, ist ein Manko welches ich immer noch als grob schlammpig einstufe (schon seit dem ich mit Joomla angefangen habe).

OK, dieses Posting hilft jetzt keinem, aber hier fällt (langsam aber sicher) ein Rattenschwanz an Fahrlässigkeiten auf das Joomla/Mambo zurück, wie es mit den massenhaften Hacks schon vor einiger Zeit begonnen hat. Solange ein System ein Schattendarsein führt merkt man das nicht, aber bei beliebten Anwendungen geht das ruckzuck und der Imageschaden ist kaum wieder gut zumachen. Wer installiert heute noch guten Gewissens ein phpBB ... ?

zum Dir-Listing:
Kann man meines Wissens nicht anfordern, wenn eine index-Datei existiert.

zum ungeparsten PHP:
Sollte nicht passierten - aber kann trotzdem vorkommen.

Bots durch robots.txt aussperren:
Ungefähr so wirksam wie ein Baustellenschild: "Spielen verboten"

Zitat von flotte

Zweiter Punkt: Das die configuration.php immer noch im Webroot liegt, wo man sie nicht schützen kann, ist ein Manko welches ich immer noch als grob schlammpig einstufe (schon seit dem ich mit Joomla angefangen habe).

Ja, ist es. Aber solange der Apache brav seinen Job macht, kommt trotzdem niemand ohne höhere Rechte an den Inhalt.

zum Dir-Listing:
Kann man meines Wissens nicht anfordern, wenn eine index-Datei existiert.

Der Meinung bin ich an sich auch, aber wie kommt der Bot dann an die (ja hoffentlich nirgends verlinkten) Dateinamen?

zum ungeparsten PHP:
Sollte nicht passierten - aber kann trotzdem vorkommen.

Wodurch? Kann man das erzwingen?

Zitat von DietmarH

Wodurch? Kann man das erzwingen?

Fehlfunktionen lösen das aus. Gabs sogar schon hier im Forum solche Meldungen. Auch eine PHP-Version hatte dieses Problem schon mal :-)
Solche Fehlfuntionen kann man auch in bestimten Umgebungen provozieren. (Ich möchte das nicht näher beschreiben.)
In genau dann ist die configuration.php schön sichtbar. Wäre Sie in einem Unterverzeichnis, dann könnte man ein deny draufgeben, so das nur Scripte Zugriff haben.

Zitat von Andi

Google scheint schon etwas unternommen zu haben, jedenfalls liefern suchen nach "$mosConfig_password" o.ä. keine Ergebnisse. Oder denke ich da zu einfach?

Der Suchstring sollte mit " geklammert werden, da das $-Zeichen ein Metazeichen bei regulären Ausdrücken darstellt. z.B. "$mosConfig_password"
Die erweitere Codesuche ist noch hilfreicher.

Treffer ergeben sich genug. Die Passwörter (zum Einloggen) wurden unkenntlich gemacht. Die smtp-Informationen sind aber vollständig zu lesen. Das könnte für den ein oder anderen Spammer doch schon interessant werden.

Essenz:
SQL-Dumps bzw. gepackte Backups der Joomla-Präsenz haben auf dem Web-Server nichts zu suchen. Dabei ist das Verzeichnis egal. Nicht-PHP Dateien (zip, sql, gz etc.) werden auch in Unterverzeichnissen gefunden.

Herbert