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 : cryptage

 Règle de survie 2 : organiser sa connexion
 Règle de survie 3 : gérer le compte utilisateur
 Règle de survie 4 : balayer derrière soi
 Règle de survie 5 : manipuler les logs
 Règle de survie 6 : manipuler les programmes de sécurité
 Règle de survie 7 : qui est l'administrateur ?

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

  MsDos : SFS v1.17 ou SecureDrive 1.4b
 Amiga : EnigmaII v1.5
 Unix : CFS v1.33

Crypteur de fichier

 Triple DES
 IDEA
 Blowfish

Crypteur d'e-mail

 PGP v2.6.x

Crypteur de conversations téléphoniques

 Nautilus v1.5a

Crypteur de sessions telnet

 SSH
 DES-Login

Sauvegardes des données cryptées

 PK ou WIN ZIP
 ARJ

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 :

 vérifiant les fichiers log enregistrant toute activité

 analyser les fichiers espions (sniffers) installés par l'intrus
 utiliser des programmes d'audit comme loginlog,
 vérifier les connexions en cours avec "netstat"
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

 Hacker / Serveur d'origine : de préférence un accès via modem pour connexion

par dialup.
 Hacker / serveur d'attaque : telnet du serveur d'origine sur le serveur d'attaque
 Hacker / serveur cible : telnet du serveur d'attaque sur le serveur cible

Règles

 Le serveur d'origine peut connaître le numéro appelant.

Ne pas utiliser son numéro de téléphone réel mais passer par un système de
rappel (carding/bluebox/hack d'un PABX) Cette précaution est parfois inutile
car les compagnies de téléphone (privées - ATT -ou publique -Danemark -)

 D'anciens clients telnet exportent la variable USER. En modifiant le telnetd un

administrateur peut obtenir le nom de tous les connectés

Les nouvelles versions exportent les variables UID, MAIL and HOME
Avant tout telnet, il faut donc changer les variables USER, UID, MAIL et PWD,HOME.
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 nobodyRè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 :
  Ne pas utiliser son compte utilisateur pour tout ce qui a trait aux activités de
Hack
 Ne pas laisser de fichiers ou outils de Hack sur son répertoire utilisateur
 Systématiquement supprimer les messages électroniques reçus sur le serveur de
messagerie (si POP3 utiliser get + delete)
 Ne pas utiliser son adresse email réelle (commande EXPN de sendmail sous Unix
!)
 N'accepter de recevoir ou d'envoyer que des messages cryptés

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 :

 WTMP - chaque connexion/déconnexion avec l'heure, le serveur et le terminal

concernél

UTMP - tous les utilisateurs connectés à un moment donné

LASTLOG - origine des connexions
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.

 ZAP (or ZAP2) : remplacement de la dernière donnée de connexion par des

zéros

Peu efficace car le CERT distribue des programmes vérifiant les données à
zéro.

 CLOAK2 : modification des données

 CLEAR : effacement des données

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

 mise à jour des fichiers de données du programme (utiliser le mode

apprentissage)
 modifier le programme ...

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