Comment effacer ses traces...

 
  Résumé
Tout hacker s'introduisant dans un système connecté (=attaquant puis intrus !! ) cherche à :

- masquer les traces de son passage
- ne pas se faire prendre suite à une intrusion .
Ci-après les méthodes proposées par van Hauser / THC (HTML-version by Markus Hübner).
 
 Un bon hacker doit s'autodiscipliner si il veut durer
toute intrusion dans un système est considérée comme un délit en France et un comportement pénalement répréhensible partout ailleurs.

Règle de Survie 1 : protéger toute donnée en la cryptant

Contre :

les administrateurs systèmes lisant les courriers électroniques :
les autorités enregistrant les numéros de téléphone
la justice saisissant votre ordinateur avec les données de hack
Comment :

Les débutants n'ont besoin que de PGP, d'un logiciel de cryptographie de fichers et de disque dur

N'oubliez pas ! : l'utilisation des logiciels de cryptographie est encore interdit en France

Crypteur de disque dur

Crypteur de fichier Crypteur d'e-mail Crypteur de conversations téléphoniques Crypteur de sessions telnet Sauvegardes des données cryptées Règle de Survie 2 : organiser son intrusion pour éviter d'être identifié

Quoi ? :

Une tentative d'intrusion peut être détectée. Il ne faut pas que l'intrus puisse être identifié et retrouvé

Contre :

Tout administrateur système peut très facilement identifier un intrus en :

Comment :

Utiliser un serveur d'attaque entre le serveur d'origine et le serveur cible

Le serveur d'origine :
serveur initial à partir duquel le hacker se connecte à Internet, généralement par appel téléphonique (accès dialup à un fournisseur d'accès par exemple)
règles :

le dialup ne rend pas nécessaire de modifier les logs d'activité sur le serveur d'origine (adresse IP allouée dynamiquement).
NE RIEN modifier sur ce serveur
utiliser plusieurs comptes utilisateurs
changer de fournisseur d'accès tous les deux mois
ne craquer les mots de passe QUE sur le PC ou la machine appelante
 
Le serveur d'attaque
serveur tampon sur lequel le hacker dispose d'un compte avec un accès ROOT.
En utilisant différents fournisseurs d'accès chaque jour il ne sera pas nécessaire d'utiliser un serveur d'attaque
règles :

localisé de préférence à l'étranger
modifier les fichiers log pour effacer les traces de son passage
changer de serveur d'attaque toutes les deux semaines sans réutilisation avant 1 mois
utiliser un programme de renvoi pour exécuter ISS, SATAN,.. : appelé sur un port spécial, ce programme ouvre automatiquement une connexion avec un autre serveur
ne lancer les programmes comme ypx, iss, satan ... qu'après les avoir renommés : ils n'apparaitront pas en clair dans la liste des processus en cours d'éxécution (PS -l sous Unix)
ne pas rentrer de paramètres dans les lignes de commandes de lancement des programmes comme Telnet, mais utiliser les commandes internes
"telnet" puis "open target.host.com" ...
 
Le serveur cible
serveur cible que le hacker cherche à pénètrer.
règles :
localisé De préférence à l'étranger
ne pas se créer un utilisateur sur un système cible mais plutôt laisser un programme à réinterroger ("bakdoor") comme ping, quota or login puis utiliser fix pour corriger le atime et mtime
faire un "w" pour examiner les utilisateurs connectés. Si l'adresse du serveur d'attaque apparaît dans les références, faire "rlogin serveur cible" pour que l'adresse se transforme en quelque chose comme "tty00"
Sécuriser l'organisation des modes de connexions

A utiliser

Règles La recommendation
Changer les variables d'environnement de votre Telnet :
sous win : accéder aux paramètres de configuration système et logiciel

sous Unix :
SH : <>=<_value>;export <> ; exemple : USER=nobody;export USER
CSH: setenv <> <_value>; exemple : setenv USER nobody
Règle de Survie 3 : gérer son compte utilisateur sur le serveur d'origine

Contre :

les administrateurs du serveur sur lequel se trouve le compte utilisateur
Comment : Règle de Survie 4 : ne rien laisser dans les répertoires HOME ou TMP des serveurs

Quoi ? :

Fichiers d'historique de lancement du Shell Unix
Toute commande peut être mémorisée dans un fichier d'historique : il est recommandé de lancer deux shells à la connexion pour vérifier les données enregistrées dans ce fichier.

Fichiers concernés selon la version d'Unix
 
sh: .sh_history
csh: .history
ksh: .sh_history
bash: .bash_history
zsh: .history

Fichiers de sauvegarde (backup) Unix
dead.letter, *.bak, *~

Contre :

les analyses d'activités d'utilisateurs par les administrateurs du serveur

Comment :

Lister tous les éléments modifiés avant de se déconnecter : ls -altr

Utiliser les commandes csh suivantes pour effacer les données d'historique sans laisser de traces. 

       mv .logout save.1

       echo rm .history>.logout

       echo rm .logout>>.logout

       echo mv save.1 .logout>>.logout
La recommendation

'The first command you should enter after logging in with a hacked account is a shell different from the one you are currently running as login shell. The purpose is to disable history saving of the commands you'll type in while hacking. A history check by the real user or sysadmin reveils your presence and what you did!! If you are running a CSH then execute a SH and vice versa. "

Règle de Survie 5 : comprendre et nettoyer les "logs" des serveurs

Quoi ? :

Sous Unix il faut connaître au minimum 3 fichiers de log importants :

D'autres existent, qui seront abordésci-dessous. Toute connexion par telnet, ftp, rlogin ou rsh est enregistrée dans ces fichiers .
Contre :

l'administrateur du serveur cible peut analyser ces fichiers ou utiliser des commandes statistiques (lastlogin par exemple) pour savoir :

a) quant l'intrusion a eu lieu
b) le serveur d'origine de l'intrusion
c) le temps et une estimation de l'impact de l'intrusion

Comment :

Effacer les traces de son passage des fichiers logs de base WTMP, UTMP, LASTLOG.

Localisation par défaut des fichiers logs : (variable selon les distributions d'Unix)

UTMP : /etc or /var/adm ou /usr/adm ou /usr/var/adm ou /var/log
WTMP : /etc or /var/adm ou /usr/adm ou /usr/var/adm ou /var/log
LASTLOG : /usr/var/adm ou /usr/adm ou /var/adm ou /var/log ou            HOME/.lastlog
Il est stupide d'effacer ces fichiers sur le serveur cible : l'administrateur saura immédiatement que l'intrusion a eu lieu

Il est recommandé d'utiliser un programme de modification de ces fichiers logs.

Il n'existe pas de solution simple pour nettoyer UTMPX ou WTMPX

Autorisation nécessaire :

Normalement ces modifications ne sont possibles que par ROOT

Si l'accès ROOT n'a pas été obtenu, il suffit pour certaines versions d'Unix de faire un rlogin lors de votre connexion sur le serveur pour modifier - le LASTLOG, - les données UTMP (effacées)

Trouver et manipuler tous les autres fichers log

Trouver tous les fichiers ouverts
Comme tous les fichiers log écrivent quelque part, utiliser le programme LSOF - LiSt Open Files - pour identifier tous les fichiers ouverts, vérifier leur contenu et éventuellement le modifier

Trouver tous les fichiers modifiés après la connexion
Juste après la connexion faire "touch /tmp/check" avant de continuer à travailler.
Par la suite faire "find / -newer /tmp/check -print" ou "find / -ctime 0 -print" ou "find / -cmin 0 -print", vérifier les fichiers, identifier les fichiers d'audit et les modifier.

Vérifier les répertoires par défaut
/usr/adm, /var/adm ou /var/log.

Vérifier les serveurs distants recevant les logs (messages envoyés à @loghost)
Problème : pénétrer le serveur de logs et manipuler la messagerie...très compliqué
Pour éliminer le nom d'intrusion des messages à expédier : "grep -v evil.host.com messages > /tmp/tmpfile; mv /tmp/tmpfile messages"

Vérifier la configuration des syslogs
Le programme syslog enregistre les logs dans des fichiers spéciaux.
Son fichier de configuration est /etc/syslog.conf. :

Les entrées kern.*, auth.* and authpriv.* doivent être vérifiées
Les sorties paramétrées doivent être vérifiées
- les fichiers peuvent être modifiés
- les serveurs distants sont identifiés
- les utilisateurs destinataires sont définis : dans ce cas il faut générer de faux logs pour noyer les vôtres : "echo 17:04 12-05-85 kernel sendmail[243]: can't resolve bla.bla.com > /dev/console".
Manipuler les logs sous format texte
Utiliser :
grep-v
linecount wc avec destruction des 10 dernières lignes ("head -LineNumbersMinus10")
éditeur de fichier

Manipuler les logs sous format données
Identifier le programme gérant les données
obtenir le programme
trouver la structure du fichier de données
adapter zap, clear, cloak,... pour produire des fichiers structurés de la même manière

Manipuler les logs de comptabilisation
utiliser acct-cleaner de zhart

Obtenir les programmes nécessaires

LISTE DES PROGRAMMES DE MODIFICATION DES LOGS
ah-1_0b.tar  Change les entrées des logs de comptabilisation
clear.c  Effacement des entrées dans utmp, wtmp, lastlog et wtmpx
cloak2.c  Changement des entrées dans utmp, wtmp et lastlog
invisible.c  Réécrit utmp, wtmp et lastlog avec des valeurs prédéfinies.
marryv11.c  Edite utmp, wtmp, lastlog et données de comptabilisation -***
wzap.c  Effacement des entrées dans wtmp
wtmped.c  Effacement des entrées dans wtmp
zap.c  Réécrit utmp, wtmp, lastlog - Attention : détectable !!!
La recommendation

"Pour modifier le LASTLOG sans toucher au fichier, une fois connecté, lancer un rlogin "serveur cible" avec le login et pass du compte utilisateur hacké. Cela a pour effet d'enregistrer un LASTLOGIN à partir du serveur et non à partir de l'extérieur..."

Règle de Survie 6 : comprendre et manipuler les programmes de sécurité installés

Quoi ? :

Sur les serveurs sécurisés, les programmes de sécurité sont lancés à intervalles périodiques par cron.Ces programmes vérifient les tailles de fichiers ou analysent les logs serveurs. Ils peuvent être également stockés dans les répertoires adm ou ~bin (pour les sniffers)

Contre :

Les détections automatisées de programmes espions installés (sniffers, programmes remplacés ou chevaux de troie) par l'intrus

Comment :

Accéder aux paramètres de cron.
Le répertoire par défaut des crontabs est /var/spool/cron/crontabs.
Vérifier toutes les entrées, surtout les fichiers "root" et analyser les programmes lancés.
Faire par exemple "crontab -l root".

Les programmes d'audit peuvent être : tiger, cops, spi, tripwire, l5,binaudit, hobgoblin, s3,...
Il s'agit de savoir ce qu'ils enregistrent et si ils enregistrent... Si ils sont actifs pour enregistrer les fichiers sniffers installés par les intrus , faire ...

Corriger les résultats des programmes de vérification de tailles de fichiers
Ces programmes sont très faciles à écrire et donc difficiles à identifier dans un système cible.
Pour les plus connus voici les localisations par défaut : (en général protégées)
Programme Localisation par défaut Nom de l'éxé
tripwire /usr/adm/tcheck, /usr/local/adm/tcheck databases, tripwire
binaudit /usr/local/adm/audit auditscan
hobgoblin ~user/bin hobgoblin
raudit ~user/bin raudit.pl
l5 compile directory  l5
Pour modifier les contrôles :
- modifier les paramètres pour ne pas contrôler un fichier
faire "tripwire -update /bin/target" par exemple.
- modifier la liste des fichiers à contrôler

En cas de remplacement d'un programme standard, utiliser la commande "touch" pour modifier les atime and mtime.ctime ne peut être changé que par écriture sur le disque...

En cas d'installation d'un sniffer, crypter les données de sortie...

Règle de Survie 7 :connaître les administrateurs système

Qui est root ?

Pour trouver les 1 à 6 administrateurs système, vérifier le fichier .forward, les entrées d'alias, les sulog pour root, les groupes "administration", le fichier des mots de passe.

Vérifier les mesures de sécurité de root

Après être rentré dans leur répertoire, vérifier les fichiers .history/.sh_history/.bash_history pour retrouver les commandes habituelles, vérifier les fichiers .profile/.login/.bash_profile pour repérer les aliases, vérifier que des auto-security checks ou logging ne sont pas effectués, vérifier les répertoires ~/bin à la recherche des programmes d'audit (ls -alR ~/ ou ls -alH sous HP UX)

Toutes ces informations ne vous sont proposées qu'à titre pédagogique...