This leaves a good trace wherever you go. Simply by the fact that the MAC-Address being used every time you do a connection to any wlan. This is often stored, but How long? There are good example where this information is begin havest for money.

Beside, You never know who else listen and might want uses this data. To mitigate this problem I do following: I generate a random mac address for each new connection.

Keep reading here

in diesem Blogpost möchte ich euch das Tool „Integrit“ vorstellen. Damit lässt sich ein Snapshot des Dateisystems erstellen und zu späteren Zeitpunkten überprüfen, ob sich Dateien geändert haben.

Die Installation und Konfiguration

Das Programm gibt es als Paket in den meisten Paketquellen, sodass man es einfach installieren kann:

sudo apt-get install integrit

Danach findet man zwei Konfigurationsdateien in /etc/integrit/

ls /etc/integrit 
insgesamt 16K
drwxr-xr-x 2 root root 4,0K Nov 30 16:43 .
drwxr-xr-x 117 root root 4,0K Dez 1 00:00 ..
-rw------- 1 root root 2,3K Nov 30 16:43 integrit.conf
-rw------- 1 root root 836 Nov 30 16:10 integrit.debian.conf

Eine ausführliche Dokumentation der Konfiguration bzw. Nutzung von Integrit findet man hier: http://integrit.sourceforge.net/texinfo/integrit.html

In der „integrit.debian.conf“ sollte man unbedingt die folgenden zwei Variablen setzen:

CONFIGS="/etc/integrit/integrit.conf"
EMAIL_RCPT="meine@email.tld"

Danach muss man sich an die Hauptkonfiguration setzen. Diese ist meiner Meinung nach ganz gut kommentiert. Man kommentiert die Optionen „known“ und „current“ aus:

known=/var/lib/integrit/known.cdb
current=/var/lib/integrit/current.cdb

Danach kann man sich überlegen, welches das Wurzelverzeichnis der zu überprüfenden Dateien sein soll. Ich hab mich mal auf „/var/www/virtual“ beschränkt, um nur die Webseiten zu überwachen.

root=/var/www/virtual

Falls man bestimmte Unterverzeichnisse ignorieren möchte, so schreibt man die Pfade mit einem vorangesetzten Ausrufezeichen in die Datei:

!/var/www/virtual/meine.website/tmp
!/var/www/logs/accces_log

Erste Ausführung

Integrit nutzt zwei separate Datenbanken für die Überprüfung. Die erste der Datenbanken ist die Ausgangsdatenbank „known.cdb“, welche die zu überwachenden Dateien in einem sicheren Ausgangszustand beinhaltet. Diese sollte man nach Möglichkeit auf einem schreibgeschützten Medium aufbewahren.

Um diese Datenbank zu erstellen, geht man folgendermaßen vor:

sudo integrit -C /etc/integrit/integrit.conf -u

Nun erstellt Integrit die zweite Datenbank namens „current.cdb“, in der die aktuellen Dateiinformationen gespeichert werden. Nachdem der erste Durchlauf erfolgreich durchgelaufen ist, macht man die „current.cdb“ zur „known.cdb“:

sudo mv /var/lib/integrit/current.cdb /var/lib/integrit/known.cdb
sudo chmod -w /var/lib/integrit/known.cdb
sudo chattr +i /var/lib/integrit/known.cdb

Die letzten beiden Kommandos sorgen dafür, dass man die Datei nicht so leicht wieder bearbeiten kann. (Das ist aber immer noch keine Ausrede für ein getrenntes Backup ;))

Automatische Überprüfung

Bei der Installation wird direkt die Datei /etc/cron.daily/integrit angelegt. Diese lädt bei der Ausführung die /etc/integrit/integrit.debian.conf, welche wiederum die dort eingetragenen Konfigurationsdateien einbindet.

Emailbenachrichtigung

Hat man in der /etc/integrit/integrit.debian.conf eine Email angegeben, so wird einem der Überprüfungsbericht per Email zugeschickt:

start: integrit -C /etc/integrit/integrit.conf -cu
integrit: ---- integrit, version 4.1 -----------------
integrit:                      output : human-readable
integrit:                   conf file : /etc/integrit/integrit.conf
integrit:                    known db : /var/lib/integrit/known.cdb
integrit:                  current db : /var/lib/integrit/current.cdb
integrit:                        root : /var/www/virtual
integrit:                    do check : yes
integrit:                   do update : yes
changed: /var/www/virtual/meine.website   m(20141115-212730:20141201-100653) c(20141115-230630:20141201-100653) 
new:     /var/www/virtual/meine.website/foo   p(644) t(100000) u(0) g(0) z(0) m(20141201-100653) 
new:     /var/www/virtual/meine.website/foo   s(9c1185a5c5e9fc54612808977ee8f548b2258d31) 
integrit: checking for missing files --------------
integrit: current-state db RMD160 -------------- 
integrit: 9dde6c7cf3f5def49702a2513211f0e4ebf170bd  /var/lib/integrit/current.cdb
exit: 1

So hat man immer im Blick, ob sich Dateien geändert haben.

~ Sebastian

in diesem Blogpost möchte ich euch erzählen, wie man auf per Vhost-Basis den Apache-Webserver mit verschiedenen Benutzerrechten ausstattet. Das ist dahingehend wichtig, da man verschiedene Webseiten voneinander trennen möchte. Sollte eine Webseite gehackt werden, so kann der Angreifer nicht sofort alle anderen Webseiten mitnehmen.

Wir werden zur Lösung dieses Problems das Modul „mpm-itk“ nutzen. Dieses lässt sich leicht installieren:

sudo apt-get install apache2-mpm-itk

Es könnte sein, dass dabei „mpm-prefork“ deinstalliert wird, aber das stört nicht weiter.

Als nächstes kann man in seinen VHost-Konfigurationsdateien folgenden Eintrag hinzufügen:

  <IfModule mpm_itk_module>
    AssignUserId USER GROUP
  </IfModule>

Wobei „USER“ der zu nutzende Benutzer und „GROUP“ die zu nutzende Gruppe ist. Gibt man diese Direktive nicht an, so werden die Standardrechte von Apache genutzt. Das kann je nach Konfiguration www-data oder root sein.

Die Ordnerstruktur kann zum Beispiel so aussehen:

/var/www/ - 775 (root:root)
-----> vhost1 - 700 (user1:user1)
--------> index.php - 777 (user1:user1)
-----> vhost2 - 700 (user2:user2)
--------> index.php - 777 (user2:user2)

Nun ist jede/r Webseite/VHost in sein eigenes Verzeichnis mit seinem eigenen Benutzer eingesperrt und Übergriffe auf andere Seiten sind nicht möglich.

~ Sebastian

in diesem Blogpost soll es um die Einrichtung von „unattended upgrades“ gehen. Aufgabe der unbeaufsichtigten Upgrades wird sein, Sicherheitsupdates auf meinen Servern automatisch und ohne Nachfrage jede Stunde zu installieren (falls verfügbar).

Die folgenden Schritte orientieren sich an der Debian-Distribution und apt. Für andere Distributionen bzw. Paketmanager wird es wahrscheinlich ähnliche Lösungen geben.

Installation und Konfiguration

Die Installation des Paketes geht relativ schnell über den Paketmanager:

sudo apt-get install unattended-upgrades

Als nächstes müssen noch zwei kleine Konfigurationsdateien angelegt werden.

20auto-upgrades

Für die kleinere der beiden Konfigurationsdateien (/etc/apt/apt.conf.d/20auto-upgrades) hat man zwei Möglichkeiten:

Option 1:

Man erstellt manuell die Datei „/etc/apt/apt.conf.d/20auto-upgrades“ mit folgendem Inhalt:

APT::Periodic::RandomSleep "900";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Die Optionen können später noch genauer nachgelesen werden, eine kurze Erklärung soll es hier aber schon geben:

• APT::Periodic::RandomSleep „900“ – Warte zwischen 0 und 900 Sekunden (15 Minuten) bevor die Updates heruntergeladen werden. Das soll die Mirror-Server entlasten.
• APT::Periodic::Update-Package-Lists „1“; – Update die Paketlisten
• APT::Periodic::Unattended-Upgrade „1“; – Führe unbeaufsichtigte Upgrades durch

Option 2:

Man führt den folgenden Befehl aus:

sudo dpkg-reconfigure unattended-upgrades

Aus den Angaben wird dann die o.g. Datei erzeugt.

50unattended-upgrades

Mit dieser etwas längeren Konfigurationsdatei kann man noch etwas Feintuning betreiben. Die Datei findet man unter „/etc/apt/apt.conf.d/50unattended-upgrades“. Der Inhalt sollte so ähnlich aussehen:

// Automatically upgrade packages from these origin patterns
Unattended-Upgrade::Origins-Pattern {
 // Archive or Suite based matching:
 // Note that this will silently match a different release after
 // migration to the specified archive (e.g. testing becomes the
 // new stable).
// "o=Debian,a=stable";
// "o=Debian,a=stable-updates";
// "o=Debian,a=proposed-updates";
 "origin=Debian,archive=stable,label=Debian-Security";
 "origin=Debian,archive=oldstable,label=Debian-Security";
};

// List of packages to not update
Unattended-Upgrade::Package-Blacklist {
// "vim";
// "libc6";
// "libc6-dev";
// "libc6-i686";
};

// This option allows you to control if on a unclean dpkg exit
// unattended-upgrades will automatically run 
// dpkg --force-confold --configure -a
// The default is true, to ensure updates keep getting installed
//Unattended-Upgrade::AutoFixInterruptedDpkg "false";

// Split the upgrade into the smallest possible chunks so that
// they can be interrupted with SIGUSR1. This makes the upgrade
// a bit slower but it has the benefit that shutdown while a upgrade
// is running is possible (with a small delay)
//Unattended-Upgrade::MinimalSteps "true";

// Install all unattended-upgrades when the machine is shuting down
// instead of doing it in the background while the machine is running
// This will (obviously) make shutdown slower
//Unattended-Upgrade::InstallOnShutdown "true";

// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. A package that provides
// 'mailx' must be installed. E.g. "user@example.com"
// Unattended-Upgrade::Mail "root";

// Set this value to "true" to get emails only on errors. Default
// is to always send a mail if Unattended-Upgrade::Mail is set
//Unattended-Upgrade::MailOnlyOnError "true";

// Do automatic removal of new unused dependencies after the upgrade
// (equivalent to apt-get autoremove)
//Unattended-Upgrade::Remove-Unused-Dependencies "false";

// Automatically reboot *WITHOUT CONFIRMATION* if a 
// the file /var/run/reboot-required is found after the upgrade 
//Unattended-Upgrade::Automatic-Reboot "false";


// Use apt bandwidth limit feature, this example limits the download
// speed to 70kb/sec
//Acquire::http::Dl-Limit "70";

Ich gehe davon aus, das die Kommentare für sich selbst sprechen. Per Default werden auch nur Security-Updates installiert, wobei im Zweifel auf ein Reboot verzichtet wird.

Eine Anmerkung noch zu der Email-Option:

Unattended-Upgrade::Mail "root";

Möchte man diese nutzen, so muss das „mail“ Kommando verfügbar sein. Am Besten installiert man sich dazu einfach das Paket „bsd-mailx“.

Fazit

Unattended-Upgrades ist ein ganz nettes Tool, mit dem man zeitnah kritische Sicherheitsupdates einspielen kann. Das Tool informiert den Administration nach erledigter Arbeit über die ausgeführten Schritte, sodass trotzdem die volle Kontrolle erhalten bleibt.

~ Sebastian

Honeypot – Virtuelle Umgebung

Kippo arbeitet dabei in einer virtuellen Umgebung in der kaum Befehle ausführbar sind. Genauer gesagt, führen Kommands wie „mount“, „dmesg“ usw. nur zur Ausgabe eines lustigen Satzes. Der einzige Befehl, welcher „korrekt“ simuliert wird „wget“. (Es ist nicht wget, sondern eine Nachimplementierung in Python) Alle vom Angreifer heruntergeladenen Dateien werden in einem gesonderten Verzeichnis gesammelt, sodass man sich diese später genau anschauen kann. Versucht der Angreifer eine heruntergeladene Datei auszuführen, passiert nichts und er bekommt nur einen lustigen Satz zu lesen.

Alle Befehle, welche vom Angreifer ausgeführt werden, werden in einer Logdatei gespeichert, welche man sich später beliebig oft anschauen kann. Das sieht dann in etwa so aus:

Die Installation von Kippo

Das ganze Projekt basiert u.a. auf Python. Es müssen folgende Pakete installiert werden:

> sudo apt-get install git build-essential python-dev libmysqlclient-dev python-virtualenv python-pip unzip

Als nächstes legen wir einen unprivilegierten Benutzer für Kippo an:

> sudo useradd -m -s /bin/bash kippo
> sudo su kippo

Der nächste Schritt besteht darin, eine virtuelle Umgebung zu erstellen und in diese hineinzuwechseln:

> virtualenv env
> . ./env/bin/activate

In dieser virtuellen Umgebung können wir dann noch weitere Python-Pakete installieren:

> pip install twisted
> pip install pyasn1
> pip install pycrypto

Anschließend loggen wir uns aus der virtuellen Umgebung aus und klonen das Kippo-Respository:

> deactivate
> git clone https://github.com/desaster/kippo.git
> cd kippo

Damit ist die Installation von Kippo abgeschlossen.

Die Konfiguration

Kippo konfigurieren

Als nächstes muss man die Kippo noch etwas konfigurieren. Das Projekt liefert eine Basiskonfiguration mit, die man übernehmen kann:

> cp kippo.cfg.dist kippo.cfg
> vim kippo.cfg

Folgende Zeilen sollte man anpassen:

• ssh_port = 22222 (Einen Port >1024 auswählen)
• hostname (Einen passenden Hostnamen festlegen)
• textlog (Beide Zeilen auskommentieren)

Die Standardlogindaten sind folgende:

• root:12345

Weitere Passwörter hinzufügen

Ich habe meinem Honeypot noch 10.000 weitere Passwörter hinzugefügt:

wget http://xato.net/files/10k%20most%20common.zip
unzip 10k\ most\ common.zip
rm 10k\ most\ common.zip
cat 10k\ most\ common.txt | while read pw; do echo "root:0:$pw" >> data/userdb.txt done

Weitere Benutzer kann man entsprechend hinzufügen. Einfach „root“ durch den gewünschten Benutzernamen ersetzen.

Dateisystem aktualisieren

Optional kann man noch das virtuelle Dateisystem aktualisieren. Dazu muss man sich Rootrechte besorgen (am besten den Benutzer kippo vorher ausloggen) und ein Script ausführen:

exit
sudo su 
cd /home/kippo/kippo
mv fs.pickle fs.pickle.bak
./utils/createfs.py | tee -a fs.pickle
chown kippo:kippo fs.pickle
exit

SSH Port anpassen

Damit Kippo später den SSH-Server spielen kann, müssen wir den eigentlichen SSH-Server auf einen anderen Port umsiedeln. Dazu bearbeitet man am Besten die /etc/ssh/sshd_config und setzt dort den Port z.B. auf „122“.

sed -i -e "s/Port 22/Port 122/g" /etc/ssh/sshd_config
sudo /etc/init.d/ssh restart

Wichtig: Nicht vergessen in der Firewall den neuen Port freizuschalten!

Wenn man sich zum Server verbinden möchte, dann muss man dem SSH-Programm mit dem Switch „-p“ mitteilen, zu welchem Port es gehen soll:

ssh -p 122 user@host

Port-Forwarding

Da Kippo auf dem Port „22222“ lauscht, müssen wir einen Portforward mittels Iptables einrichten.

sudo iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 22222

Wir brauchen diese Regel, da unprivilegierte Nutzer nur Ports >1024 belegen dürfen. Wir möchten Kippo natürlich nicht mit Rootrechten laufen lassen ;)

Kippo starten

Es gibt zwei Möglichkeiten Kippo zu starten. Allgemein kann es ein paar Sekunden dauern, bis Kippo hochgefahren ist.

Im Vordergrund

Man aktiviert die virtuelle Umgebung und führt dann Kippo aus.

> . ./env/bin/activate
(env)$ twistd -n -y kippo/kippo.tac

Diese Variante ist gut zum Debuggen.

Im Hintergrund

Dazu ruft man einfach die „start.sh“ auf und Übergibt den Pfad zur virtuellen Umgebung:

~/kippo> . ../env/bin/activate
~/kippo>./start.sh ../env

Logs anschauen

Zum Anschauen der Hackangriffe, sucht man erstmal die verschiedenen Logs heraus:

kippo@host:~/kippo$ ls log/tty/
20141016-215452-5117.log 20141017-154123-1028.log 20141017-154811-967.log 20141017-161823-1127.log

Nun ruft man das Playback-Tool auf:

./utils/playlog.py log/tty/20141016-215452-5117.log

Fazit

Ich werde den Honeypot mal eine Weile laufen lassen und falls interessante Ergebnisse hängen bleiben, dann werde ich darüber natürlich bloggen.

~ Sebastian

Whonix-Konzept (Quelle: www.whonix.org)

Durch diesen Trick kann die Workstation nicht mehr so einfach die echte IP-Adresse verraten, die echte IP ist nicht auf der Workstation gespeichert.

Wenn man schon VirtualBox nutzt sollte die Installation von Whonix recht schnell gemacht sein. Einfach die Systemabbilder von der Whonix-Webseite herunterladen und installieren. Auf der Webseite von Whonix sind diese Schritte auch noch ausführlich dokumentiert.

Fazit: Sieht gut aus. Einfach mal ausprobieren.

Ansonsten: Whonix sucht auch noch Mitwirkende.

Mit ein wenig Konfigurations-Fuu lässt sich das ohne Probleme umsetzen.

Die Ausgangssituation

Ich habe zwei Server:

Server A

• OpenVPN Server im 10.10.0.1/24 Netz
• Setzt Default-Route beim Client (push „redirect-gateway def1 bypass-dhcp“)

Server B

• OpenVPN Client mit 10.10.0.10/24 IP am tun1
• Benutzer dessen Traffic weitergeleitet werden soll namens „yacy“

Wie anfangs schon erwähnt möchte ich nur den ausgehenden Traffic des Benutzers „yacy“ über das VPN zu Server A schicken. Folgende Probleme gilt es also auf Server B zu lösen:

• Droppen der „Default“ Route
• Weiterleitung des ausgehenden Traffics des „yacy“ Benutzers
• Der restliche Traffic soll uneingeschränkt über das eth0 Netzwerkinterface laufen

Die Umsetzung

OpenVPN Konfiguration anpassen

Um das erste Problem zu lösen, müssen wir unserem OpenVPN Client mitteilen, das er die vom OpenVPN Server gepushte Default Route nicht annehmen soll. Dazu muss man die folgende Option in die entsprechende „.ovpn“ Konfigurationsdatei eintragen:

#No default route
route-nopull

Trafficweiterleitung

Wir werden später mittels den Iptables Pakete von unserem Benutzer markieren, um diese eine bestimmte Route zu schicken. Dazu erstellen wir zunächst eine neue Routing-Tabelle mit dem Namen „vpn.out“.

echo 201 vpn.out | sudo tee -a  /etc/iproute2/rt_tables

Danach erstellen wir eine Regel, welche alle Pakete mit der Markierung „1“ durch die Tabelle „vpn.out“ jagt:

sudo /sbin/ip rule add fwmark 1 table vpn.out

Bisher sollte unsere neue Routing-Tabelle noch leer sein und die Pakete wissen noch nicht wohin. Das ändert sich jetzt:

sudo /sbin/ip route add default via 10.10.0.10 dev tun1 table vpn.out

Default-mäßig werden alle Pakete die in diese Tabelle kommen über das tun1 Device zum Server A geschickt.

Als nächstes bringen wir unserem „tun1“ Device bei, das es etwas lockerer mit der Überprüfung der Routebarkeit von Paketen sein soll. Der Wert „2“ erlaubt das Akzeptieren des Paketes falls es irgendwie auf irgendeinem Device geroutet werden kann.

sudo /sbin/sysctl -w net.ipv4.conf.tun1.rp_filter=2

Als nächstes müssen wir sicherstellen das alle Pakete vom Benutzer „yacy“, die das System über eth0 verlassen wollen, mit „1“ markiert werden. Dazu verwenden wir die Iptables:

sudo /sbin/iptables -t mangle -A OUTPUT -m owner --uid-owner yacy -o eth0 -j MARK --set-mark 1

Zuletzt müssen wir uns noch darum bemühen das die Pakete auch wieder zu uns zurück finden. Ein Source-NAT ist dafür genau richtig:

sudo /sbin/iptables -t nat -A POSTROUTING -o tun1 -j SNAT --to-source 10.10.0.10

Fertig :)

~ Sebastian

Meine Highlights waren: 

• Gehaxelt war da!
• YUR war da!
• Die Leute von Uberspace persönlich getroffen (Sind echt ganz nette Menschen)
• Hab einen Open Mandriva USB-Stick bekommen
• Berlin Linux User Group getroffen
• Und ein echt guter Vortrag über freie Softwaretools

Ich hoffe der Linuxtag findet auch nächstes Jahr wieder statt.

ich hab in letzter Zeit doch etwas häufiger eine nette Email von Fail2Ban bezüglich dem SSH-Port erhalten. Dabei kam es u.a. vor, dass alle 10 Minuten derselbe Angreifer gebannt wurde. Durch einen kleinen Fehler bei den Kommentaren in der Konfigurationsdatei wurde die falsche Bantime verwendet.

Es gibt nämlich 2 verschiedene Kommentarzeichen in der Fail2ban-Konfigurationsdatei.

Einmal das einfache Rautezeichen:

#Ich bin eine Kommentarzeile

Dieses kommentiert eine ganze Zeile aus, egal wo es in dieser steht. Zum Beispiel ist die folgende Zeile ebenfalls ein Kommentar:

Das ist doch komisch! # Warum nicht?

Da ich mit großen Zahlen nicht unbedingt arbeiten kann, sah die BanTime Einstellung bei mir so aus:

bantime  = 86400 #1 Tag

Das führt leider dazu, das Fail2Ban diese Zeile ignoriert und daher seine 10 minütige bantime nutzt. Hätte man mal ins /var/log/fail2ban.log geschaut wäre das einem auch aufgefallen…

2014-04-10 12:59:02,036 fail2ban.filter [25385]: INFO    Set maxRetry = 1
2014-04-10 12:59:02,037 fail2ban.filter [25385]: INFO    Set findtime = 600
2014-04-10 12:59:02,038 fail2ban.actions[25385]: INFO    Set banTime = 600
2014-04-10 12:59:02,132 fail2ban.jail   [25385]: INFO    Jail 'ssh' started

Richtig lautet es daher so hier:

bantime  = 86400 ;1 Tag

Das Semikolon ist das Kommentarzeichen, welches ab Erscheinen den Rest der Zeile auskommentiert. Also das, was man eigentlich vom „#“-Zeichen erwartet hätte.

Nun ja, jetzt sind wir schlauer :)

~Sebastian

Die SQL Injection

Die folgend beschriebe SQL Injection Lücke klaffte bei einem großen Unternehmen. Man war in der Lage über einen numerischen Parameter das Query zu manipulieren. Die Daten des Querys wurden an ein Mail-Script übergeben, um Inhalte einer Datei an eine Email zu verschicken.

Hier war meine Neugier geweckt, denn vielleicht könnte man über die SQL Injection die Pfadangabe zur ausgelesenen Datei verändern und somit an andere Inhalte gelangen?

Nach ein paar Anfragen war die Spaltenanzahl des Querys bestimmt. Der Versuch das Query mit einem „union select“ zu erweitern scheiterte jedoch. Ernüchterung :(

index.php?fileid=1+and+1=2+union+select+1,2,3,4,5,6+--+

Als nächsten Ansatz wollte ich die MySQL-Version herausfinden, denn „union“ gibt es erst seit MySQL 5.0:

index.php?fileid=1+and+5=substr(version(),1,1)+--+

Dieses Query scheiterte jedoch auch. Eine normale bool’sche Anfrage wurde korrekt interpretiert. Das roch nach einem Blacklist-Filter.

Die Lösung – SQL Injection ohne Kommata

Die Überschrift verrät die Lösung eigentlich schon. Nach ein wenig rumspielen viel mir auf, dass der eingesetzte Filter nur auf das Komma-Zeichen ansprang und die Ausführung des Querys dadurch verhindert wurde. Die folgenden Anfragen bestätigten mir das:

index.php?fileid=1+and+1=1+/**Funktioniert**/
index.php?fileid=1+and+1=1+/** , Funktioniert nicht mehr **/

Mir war klar, dass ein Großteil aller SQL Anfragen Kommata enthält, sodass eine „union“-Injection nicht mehr möglich sein wird. Es gäbe keine Möglichkeit die selektierten Spalten ohne Kommata abzutrennen, ohne einen SQL Fehler zu erzeugen.

Somit war die mögliche File-Inclusion Attacke nicht mehr umsetzbar. Da Blacklists allgemein unsicher sind, wollte ich an dieser Stelle noch nicht aufgeben, und trotzdem eine funktionsfähige SQL Injection hinbekommen.

Die Lösung bestand darin, dass MySQL zu manchen Funktionen alternative Funktionsaufrufe akzeptiert. Statt

index.php?fileid=1+and+5=substr(version(),1,1)+--+

lässt MySQL auch folgendes zu:

index.php?fileid=1+and+5=substr(version() FROM 1 FOR 1)+--+ //ODER:
index.php?fileid=1+and+5=mid(version() FROM 1 FOR 1)+--+

In den letzten Exploits ist kein Komma mehr vorhanden, sodass der Filter umgangen wird und man die Lücke trotzdem ausnutzen konnte.

Fazit

Wie immer: Finger weg von Blacklist-Filtern!

Diese lassen sich nämlich fast immer mit irgendwelche Tricks umgehen. Man sollte lieber auf Prepared Statements nutzen. Das werde ich demnächst einen Artikel schreiben.

~Sebastian