Skip to content

Das "Erraten" geheimer URLs

Ab und an hat man als Nutzer den Wunsch, ein Dokument, ein Bild oder eine andere Datei mit Freunden, Bekannten oder Kollegen zu teilen. Dafür lassen sich mittlerweile Cloud-Speicherdienste wie Dropbox, Google Drive oder auch Microsofts OneDrive nutzen, die nicht nur Dateien speichern, sondern auch zwischen verschiedenen Rechnern synchronisieren und für Dritte abrufbar machen können. Zumindest früher war es hingegen üblich (und ist vielleicht auch jetzt noch hier und da verbreitet), einfach den eigenen Webspace für diese Zwecke zu nutzen, also die Datei hochzuladen und den Adressaten die URL bzw. den Link mitzuteilen.

Security by obscurity

Gar nicht so selten wurde dabei - und wird auch weiterhin bei den Cloud-Diensten - darauf gesetzt, dass schon niemand den richtigen Dateinamen wird erraten können, so dass auf Zugriffskontrollen (im einfachsten Falle per .htaccess-Datei des Webservers oder vergleichbaren Mechanismen) verzichtet wird. Gerade bei den Cloud-Diensten ist eine Zugriffskontrolle oft auch nur möglich, wenn jeder Nutzer selbst über einen Account bei diesem Dienst verfügt, was nicht immer der Fall ist. Diese Vorgehensweise stellt natürlich ein kalkuliertes Risiko dar, geht aber meistens wohl gut - wenn man die simple Vorsichtsmaßnahme beachtet, seinem Webserver zu verbieten, Verzeichnisinhalte anzuzeigen, und wenn die URL nicht auf irgendeine Weise Dritten - insbesondere einer Suchmaschine - bekannt wird. Letztere Gefahr sollte man nicht unterschätzen; führt bspw. aus dem zu teilenden Dokument ein Hyperlink zu anderen Inhalten, übermittelt der Browser die “geheime” URL in der Regel als Teil des Referer-Headers. Als böse Falle können sich auch Webserver-Zugriffsstatistiken erweisen, die ungeschützt im Netz stehen, oder auch Browser und deren Add-Ins, die zu welchem Zweck auch immer die Adressen der besuchten Webseiten bzw. -dokumente an Dritte übermitteln, oder Proxy-Server, oder ungesicherte WLANs, oder … Insgesamt erscheint das Risiko jedoch überschaubar.

Wirklich problematisch allerdings wird es, wenn die “geheime” URL sich erraten oder durch simples Ausprobieren erreichen lässt. Und dieses Problem haben - prinzipbedingt - die beliebten URL-Verkürzer wie bit.ly, goo.gl und Co.

Continue reading "Das "Erraten" geheimer URLs"

Vom Advisory zum Exploit binnen eines Tages

Am Freitag, dem dritten Mai, wurde ein Warnhinweis (Advisory) auf eine weit verbreitete Fehlkonfiguration in der Kombination von Exim mit Dovecot publiziert: ein offenbar seit 23.10.2009 im Dovecot-Wiki veröffentliches Konfigurationsbeispiel für Exim, mit dem eingehende E-Mails durch den zu Dovecot gehörenden LDA deliver ausgeliefert werden sollen, enthielt auch die Option "use_shell", die dazu führt, dass der Aufruf insgesamt zur Ausführung an die Shell weitergegeben wird. Das is potentiell unsicher, wie auch die Exim-Dokumentation erläutert:

Not running the command under a shell (by default) lessens the security risks in cases when a command from a user’s filter file is built out of data that was taken from an incoming message. If a shell is required, it can of course be explicitly specified as the command to be run. However, there are circumstances where existing commands (for example, in .forward files) expect to be run under a shell and cannot easily be modified. To allow for these cases, there is an option called use_shell, which changes the way the pipe transport works. Instead of breaking up the command line as just described, it expands it as a single string and passes the result to /bin/sh. The restrict_to_path option and the $pipe_addresses facility cannot be used with use_shell, and the whole mechanism is inherently less secure.

Wenn es jemandem gelingt, ausführbaren Code in diesen Aufruf einzuschleusen, kann er fremden Code mit den Rechten von Exim ausführen, die im Moment der Auslieferung von Mail mit dem LDA deliver bestenfalls Zugriff auf alle Mailboxen ermöglichen und bei leichtsinniger Konfiguration - die im Dovecot-Wiki als eine Konfigurationsmöglichkeit ausdrücklich genannt wird! - schlimmstenfalls sogar root sind. Und dieses Einschleusen ist ausgesprochen einfach, enthält der Aufruf von deliver doch u.a. den Absender der E-Mail, den sog. Envelope-From (oder auch Return-Path), bspw. so: command = /usr/local/libexec/dovecot/dovecot-lda -d $local_part@$domain -f $sender_address

$sender_address ist hier der problematische Parameter, denn diesen Parameter kann der Absender der E-Mail frei setzen. Durch die Option use_shell wird der obige Aufruf nach Ersatz der Variablen ohne jede Modifikation komplett an die Shell übergeben und ggf. entsprechender Code ausgeführt.

Am 02.05.2013 wurde das Beispiel im Wiki für Dovecot 1.x und auch in der Dokumentation für Dovecot 2.x berichtigt, am 03.05.2013 wurde das Advisoy veröffentlicht.

Continue reading "Vom Advisory zum Exploit binnen eines Tages"
tweetbackcheck