Beiträge vom » Januar, 2010 «

Dumme Registrierung für Downloads

Sonntag, 31. Januar 2010, 14:46 Uhr | Autor: ich

Auf der Seite “Web 2.0 Gefahren” (de.securitypoint.westcon.com) gibt es neben der Reklame für websense auch ein kleines Bildchen auf dem “Download” steht. Dort soll es u.a. etwas zur “Prognose über die Web Gefahren 2010″ zum runterladen geben. Wenn ich darauf klicke, um zum erhofften Download zu gelangen, so bekomme ich nur ein Formular angezeigt, in dem die Felder “First Name”, “Last Name”, “Company”, “Email” und “Phone” ausgefüllt werden müssen!

Wenn ich so etwas sehe… da bekomme ich soooooo einen Hals…

Ok, dann gebe ich eben Fakedaten ein und eine der vielen Wegwerf-E-Mail-Adressen, die es genau für solche Fälle gibt. Nun erwarte ich entweder direkt einen Link zum Download oder eine E-Mail in der der Link enthalten ist. In Ausnahmefällen wird auch schon mal an die versendete E-Mail das gewünschte Dokument angehängt. Njet! Es gab zwar gleich drei E-Mails, einen Dank und zwei Abwesenheitsnotizen, aber keinen Link zum Download!

(Wird JavaScript im Browser deaktiviert, so reicht es auch aus nur die E-Mail-Adresse einzugeben, um nichts sinnvolles zugesendet zu bekommen. <g>)

Wenn ich mir das E-Mail-Formular genauer anschaue, dann sehe ich u.a. ein hidden-Feld mit dem Namen “emailto” und darin sind drei E-Mail-Adressen enthalten. Die HTML-Seite des Formulars kann ich natürlich auch bei mir abspeichern und dann das Feld “emailto” mit einer E-Mail-Adresse meiner Wahl bestücken… :O)
Spam vom Formular
So sieht also die E-Mail aus die die morgen sehen werden…

Da in dem Formular auch die anderen Bestandteile der E-Mail (Betreff und Inhalt) in hidden-Feldern enthalten sind, könnte man dieses auch zum Versenden eigener Nachrichten verwenden.


Wer ist das denn überhaupt, der da so viele Dummheiten begeht?

ÜBER WESTCON SECURITY
Westcon Security, ein Unternehmensbereich der Westcon Group, ist führender Spezialdistributor von hochentwickelten Security-Lösungen.
Westcon Security bietet genau die Services, Trainings, Support und das Lösungs-Programm, um unsere Kunden dabei zu unterstützen noch profitabler und wettbewerbsfähiger zu werden.

Aha, zum Glück haben die nichts mit IT-Security zutun, ich dachte schon…


Und natürlich finde ich dort auch weitere Hinweise zu meinem Lieblingsthema

Noch ein Hinweis zur Datenschutzerklärung: BVDW: Einsatz von Google Analytics nur mit Datenschutzhinweis rechtmäßig (heise.de)


Irgendwie tun mir ja die Mitarbeiter dort leid, die die Berge an E-Mails bekommen die wertlos sind, und dies nur weil irgendwer der Meinung ist, Adressdaten generieren zu müssen, die natürlich auch wertlos sind. Das mit den Fakedaten in solchen Formularen mache ja nicht nur ich so. Jeder der schon einmal irgendwo seine echten Daten angegeben hat und dieses Geschmeiß dann über Jahre nicht abschütteln konnte, wird es gewiss genau so machen wie ich.


Ich habe auch eine “normale” E-Mail-Adresse benutzt, da es manchmal mit den Wegwerf-E-Mail-Adressen Probleme gibt, wenn es Dateianhängen gibt. Dabei bin ich dann auf eine kuriose Fehlermeldung von Microsoft gestoßen, die den Normaluser wahrscheinlich verunsichern wird: “Sie konnten nicht abgemeldet werden, da Drittanbietercookies offensichtlich von Ihrem Browser blockiert werden.” Und wieder ein sehr schöner Beitrag von Microsoft zum Datenschutz…


Und dies alles nur, weil mal wieder jemand zu dumm ist einen Download korrekt anzubieten. :O)


Thema: Korinthenkacker, Microsoft, Reklame, Sicherheit | Kommentare geschlossen

LFI kann so gefährlich wie RFI werden

Samstag, 30. Januar 2010, 14:38 Uhr | Autor: ich

Bei einem Angriff per Cross-Site Scripting (de.wikipedia.org) wird ein Scriptcode nur im Browser ausgeführt, d.h. es ist nur JavaScript oder VBScript möglich. Bei solchen Angriffen ist i.d.R. “nur” der Besucher einer Website das Ziel.

Ein Angriff per Remote File Inclusion (de.wikipedia.org), kurz RFI, zielt hingegen auf den Server direkt ab und in der Folge natürlich auch auf die Besucher.

Der Begriff Remote File Inclusion beschreibt eine Sicherheitslücke in Skript-basierten Webanwendungen, die es einem Angreifer ermöglicht, unkontrolliert Programmcode in den Webserver einzuschleusen und dort auszuführen.

Wurde ein Server über solch eine Schwachstelle kompromittiert, so hat ein Besucher kaum die Möglichkeit dies zu erkennen oder sich gar dagegen zu schützen.

Über die WordPress-Scripte wird hier z.B. ab und an versucht ein PHP-Script zu injiziert. In diesen Scripten stecken unglaublich viele Funktionen. Ohne nun ins Detail zu gehen: Es ist alles möglich was eine serverseitige Scriptsprache wie PHP bietet. Ich glaube jedem ist klar was ein Angreifer mit einem solchen Script auf einem Server ausspähen, verändern, löschen oder hinzufügen kann.

Das lokale Gegenstück dazu nennt sich Local File Inclusion (LFI). Hier werden lokale Dateien, also die bereits auf dem Server liegen, injiziert. Im ersten Moment denkt man vielleicht: “Wo ist dabei die Schwachstelle?” Darüber kann man z.B. Dateien auslesen in denen Zugangsdaten gespeichert sind oder Informationen darüber, wie der Server konfiguriert ist, was u.U. für weitere Angriffe nutzbar ist. Aber…

Über eine LFI-Schwachstelle können, unter schlechten Umständen, auch neue Dateien auf dem Server erstellt werden!

Zugriffe von Websitebesuchern werden in verschiedenen Logfiles protokolliert. Wird z.B. eine URL aufgerufen die es nicht gibt, so wird ein Eintrag in dem Logfile für Fehler geschrieben, in der die fehlerhafte URL protokolliert wird. Wird nun die nicht existente URL geschickt gewählt, so kann ein Angreifer eine Zeile im Logfile schreiben lassen, die für einen Angriff nutzbar ist. Diese Zeile selber tut noch nichts gefährliches am Server, da es nur eine Datei im Textformat ist. Wird nun aber dieses Logfile per LFI selber aufgerufen, so wird das injizierte Script ausgeführt. Über diesen kleinen Logfile-Umweg kann ein Angreifer, obwohl keine RFI-Schwachstelle vorliegt, sein eigenes Script vom Server ausführen lassen und dieses kann auf dem Server dann auch neue Dateien abspeichern.

Hier mal wieder ein kleines Video:

Mein kleines Beispielscript mag auf den ersten Blick konstruiert wirken, aber dies täuscht nur…

Das Aufbohren der LFI-Schwachstelle zu einer sehr schwerwiegenden Lücke ist nicht neu und warum mache ich mir dann so viel Arbeit? Weil es (angebliche) IT-Security-Fachleute gibt, die LFI als eine Schwachstelle erklären, über die man “nur” Daten auslesen könnte.

Thema: Sicherheit | Kommentare geschlossen