| ledoc | | lovers | | Nouveau membre |  | | 44 messages postés |
|  Posté le 28-11-2009 à 09:10:50   
| Effacer ses traces rester furtif
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
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 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 :
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)
--------------------
Bonjour a tous , G'Day All / Désolé pour certain tutorial qui sont en anglais / Et bon Hack! / |
|
