- Accueil
- Tous les articles
- Par catégorie
- Les plus récents
- Hacking 101
- Blog
- Vers le vrai hacking
- Sources exemples
Scanning avancé
| << Le Denial of Service (DoS) |
II°) Les scans intelligents
Tout comme dans la page précédente, nous ne vous donnerons pas ici de code permettant de scanner des ordinateurs distants. Tout d'abord, des scanners de vulnérabilité tels Nmap ou Nessus contiennent ces fonctionnalités et les implémentent de fort belle manière. De plus, après ces explications théoriques il devrait vous être facile de construire de tels scanners. Ces techniques sont surtout effectuées pour contourner les méthodes traditionelles de détection des scans.
Le scan SYN, dit scan "mi-ouverture"
L'idée de ce scan est tout simplement de ne pas établir une connexion complète en omettant la troisième étape de l'initialisation de la connexion. En fait, on envoit un paquet SYN sur le port concerné. Si le port est en écoute, un paquet SYN/ACK est renvoyé, le port est donc ouvert. On envoie un paquet RST pour terminer la connexion (nécessaire car si on scanne beaucoup de ports sans RST, on peut DoS la victime de la même façon qu'un Flood SYN pourrait le faire). Cette technique simplissime évite l'ouverture complète de la connexion et ainsi le log de l'IP par la majorité des services ayant accepté une connexion. Sur les systèmes un minimum sécurisé, les demi-connexions sont repérées et logguées, les trois scans suivants sont donc apparus.
Les scans FIN, X-mas ou NULL
Ces trois techniques préfèrent envoyer des paquets qui n'ont aucun sens lorsque que la connexion est fermée et s'appuyer sur les différences d'interprétation du serveur. Effectivement, si un paquet quelconque est envoyé sur un port ouvert, il sera ignoré puisque ce port attend avant toute chose un paquet SYN. Par contre, si le port est fermé, la RFC 793 prévoit le retour d'un paquet RST. En utilisant cette différence, on peut déterminer les ports ouverts et les ports fermés. Le scan FIN envoie un paquet FIN, le scan X-MAS envoie un paquet FIN/URG/PSH et le NULL, vous l'avez compris, envoit un paquet avec tous les flags TCP à off. Attention, cette technique ne marche pas sur certains OS Microsoft, car le géant de l'informatique n'aimant pas à faire les choses comme tout le monde, ne suit tout simplement pas la RFC... Bien sûr, patcher son kernel en supprimant les RST des ports fermés est très efficace contre ces scans. Dans la source de linux, on affiche le code de l'implémentation de TCP pour IPv4 (dans /usr/src/linux-source-2.6.24/net/ipv4/tcp_ipv4.c pour un kernel 2.6.24 par exemple). On cherche la fonction d'envoi des RST :
Spoofer l'host scannant
Une première technique simple pour éviter la détection du scan est de faire participer d'autres hosts du réseau au scan : par exemple, entre chaque test de port, on envoie un paquet spoofé à la cible sur un port quelconque. Ainsi, on ne lancera jamais plus d'une requête à la suite et la victime ne détectera pas un scan massif de ses ports. Vous l'aveez remarqué, les hosts spoofés doivent exister pour éviter que la cible subisse un flood SYN et à terme un DoS.
La deuxième méthode est beaucoup plus technique, elle utilise un ordinateur du réseau inactif (qui n'as pas d'autres échanges réseaux au moment X du scan). Le principe repose sur le changement prédictible de l'IP ID, incrémenté à chaque paquet que le système concerné envoie. Quand l'incrémentation est fixe (on augmente toujours du même nombre d'octets l'IP ID), on peut prédire le prochain nombre. Cette implémentation de TCP est courante, par exemple pratiquement tous les Windows incrémentent leur IP ID de 1 ou 254 (en fonction de l'agencement des bytes) selon les kernels. Notre but ici est d'observer les changements opérés sur l'host inactif afin de détecter ou non des changements dans l'IP ID pour savoir s'il a reçu des informations, explications.
Tout d'abord, l'attaquant envoie plusieurs paquets SYN/ACK au système inactif. A chaque fois, il note l'IP ID et peut ensuite facilement déterminer l'incrémentation que suit le système. Ensuite, l'attaquant fait parvenir à la victime un paquet SYN spoofé avec l'ip inactive en source. Si le port est ouvert, la victime recevant une demande de connexion, elle renvoie un paquet SYN/ACK à la machine inactive. Mais puisque l'host inactif n'a pour lui fait aucune demande de connexion, il va envoyer un paquet RST à la victime. Avec cet envoi, l'IP ID est incrémenté. Dans le cas où le port est fermé, la victime enverra un paquet RST ou rien, ce qui n'occasionnera pas de retour de paquet de la part de l'host inactif.
Ensuite, l'attaquant réenvoie un paquet ACK/SYN à l'ordinateur inactif pour recevoir l'actuel IP ID. S'il a été incrémenté d'un incrément, un seul paquet a été envoyé, donc le port est fermé (le paquet envoyé étant le RST envoyé à la suite du ACK/SYN non-sollicité de l'attaquant). S'il a augmenté de deux incréments, un autre paquet a été envoyé, a priori le paquet RST envoyé à la suite du ACK/SYN non-sollicité de la victime : le port est donc ouvert.
Cette technique est finalement puissante car l'attaquant peut ainsi scanner sans à aucun moment n'avoir besoin de réveler son IP.
L'utilité d'un scan peut paraître réduite de prime abord, mais en réalité, c'est une technique essentielle d'attaque et de sécurité. En effet, la première étape d'un pentest (audit intrusif) est de récupérer des informations sur la cible en général et sur le système d'information. Ainsi, un scanning permet notamment de savoir quels services tournent sur quels machines (et donc en deviner l'utilité, à savoir serveur mail, serveur DNS, etc. afin de cibler l'attaque), mais également de connaître les versions de ces services, afin d'éventuellement détecter de vieux services pouvant être attaqués aisément à l'aide d'exploits publics.
D'un autre côté, de nombreuses entreprises effectuent un scanning régulier de leur infrastructure afin de détecter par exemple d'éventuels ports ouverts qui ne devraient pas l'être (souvent témoins d'une backdoor).
Ceci termine cette section sur les connaissances de base de l'exploitation réseau. Afin d'aller légèrement plus loin, nous vous invitons à consulter le travail qui a été effectué dans le cadre d'un cours projet de système de détection des intrusions : Herkeios. Dans la partie réseau du projet, nous avons diffusé quelques exemples d'implémentation d'attaques de base (SYN flooding, UnNamed Attack, etc.), mais également de techniques de scans exposées ici ou encore de techniques de défense actives (opposées aux défenses passives comme le filtrage par firewalling).
Tout comme dans la page précédente, nous ne vous donnerons pas ici de code permettant de scanner des ordinateurs distants. Tout d'abord, des scanners de vulnérabilité tels Nmap ou Nessus contiennent ces fonctionnalités et les implémentent de fort belle manière. De plus, après ces explications théoriques il devrait vous être facile de construire de tels scanners. Ces techniques sont surtout effectuées pour contourner les méthodes traditionelles de détection des scans.
Le scan SYN, dit scan "mi-ouverture"
L'idée de ce scan est tout simplement de ne pas établir une connexion complète en omettant la troisième étape de l'initialisation de la connexion. En fait, on envoit un paquet SYN sur le port concerné. Si le port est en écoute, un paquet SYN/ACK est renvoyé, le port est donc ouvert. On envoie un paquet RST pour terminer la connexion (nécessaire car si on scanne beaucoup de ports sans RST, on peut DoS la victime de la même façon qu'un Flood SYN pourrait le faire). Cette technique simplissime évite l'ouverture complète de la connexion et ainsi le log de l'IP par la majorité des services ayant accepté une connexion. Sur les systèmes un minimum sécurisé, les demi-connexions sont repérées et logguées, les trois scans suivants sont donc apparus.
Les scans FIN, X-mas ou NULL
Ces trois techniques préfèrent envoyer des paquets qui n'ont aucun sens lorsque que la connexion est fermée et s'appuyer sur les différences d'interprétation du serveur. Effectivement, si un paquet quelconque est envoyé sur un port ouvert, il sera ignoré puisque ce port attend avant toute chose un paquet SYN. Par contre, si le port est fermé, la RFC 793 prévoit le retour d'un paquet RST. En utilisant cette différence, on peut déterminer les ports ouverts et les ports fermés. Le scan FIN envoie un paquet FIN, le scan X-MAS envoie un paquet FIN/URG/PSH et le NULL, vous l'avez compris, envoit un paquet avec tous les flags TCP à off. Attention, cette technique ne marche pas sur certains OS Microsoft, car le géant de l'informatique n'aimant pas à faire les choses comme tout le monde, ne suit tout simplement pas la RFC... Bien sûr, patcher son kernel en supprimant les RST des ports fermés est très efficace contre ces scans. Dans la source de linux, on affiche le code de l'implémentation de TCP pour IPv4 (dans /usr/src/linux-source-2.6.24/net/ipv4/tcp_ipv4.c pour un kernel 2.6.24 par exemple). On cherche la fonction d'envoi des RST :
-
static void tcp_v4_send_reset(struct sock *sk, struct sk_buff *skb)
{
-
struct tcphdr *th = tcp_hdr(skb);
struct {
-
struct tcphdr th;
-
__be32 opt[(TCPOLEN_MD5SIG_ALIGNED >> 2)];
-
} rep;
struct ip_reply_arg arg;
-
struct tcp_md5sig_key *key;
/* Never send a reset in response to a reset. */
if (th->rst)
-
return;
[...]
-
static void tcp_v4_send_reset(struct sock *sk, struct sk_buff *skb)
{
-
struct tcphdr *th = tcp_hdr(skb);
struct {
-
struct tcphdr th;
-
__be32 opt[(TCPOLEN_MD5SIG_ALIGNED >> 2)];
-
} rep;
struct ip_reply_arg arg;
-
struct tcp_md5sig_key *key;
return; /* On quitte directement : aucun paquet RST transmis */
/* Never send a reset in response to a reset. */
if (th->rst)
-
return;
[...]
Spoofer l'host scannant
Une première technique simple pour éviter la détection du scan est de faire participer d'autres hosts du réseau au scan : par exemple, entre chaque test de port, on envoie un paquet spoofé à la cible sur un port quelconque. Ainsi, on ne lancera jamais plus d'une requête à la suite et la victime ne détectera pas un scan massif de ses ports. Vous l'aveez remarqué, les hosts spoofés doivent exister pour éviter que la cible subisse un flood SYN et à terme un DoS.
La deuxième méthode est beaucoup plus technique, elle utilise un ordinateur du réseau inactif (qui n'as pas d'autres échanges réseaux au moment X du scan). Le principe repose sur le changement prédictible de l'IP ID, incrémenté à chaque paquet que le système concerné envoie. Quand l'incrémentation est fixe (on augmente toujours du même nombre d'octets l'IP ID), on peut prédire le prochain nombre. Cette implémentation de TCP est courante, par exemple pratiquement tous les Windows incrémentent leur IP ID de 1 ou 254 (en fonction de l'agencement des bytes) selon les kernels. Notre but ici est d'observer les changements opérés sur l'host inactif afin de détecter ou non des changements dans l'IP ID pour savoir s'il a reçu des informations, explications.
Tout d'abord, l'attaquant envoie plusieurs paquets SYN/ACK au système inactif. A chaque fois, il note l'IP ID et peut ensuite facilement déterminer l'incrémentation que suit le système. Ensuite, l'attaquant fait parvenir à la victime un paquet SYN spoofé avec l'ip inactive en source. Si le port est ouvert, la victime recevant une demande de connexion, elle renvoie un paquet SYN/ACK à la machine inactive. Mais puisque l'host inactif n'a pour lui fait aucune demande de connexion, il va envoyer un paquet RST à la victime. Avec cet envoi, l'IP ID est incrémenté. Dans le cas où le port est fermé, la victime enverra un paquet RST ou rien, ce qui n'occasionnera pas de retour de paquet de la part de l'host inactif.
Ensuite, l'attaquant réenvoie un paquet ACK/SYN à l'ordinateur inactif pour recevoir l'actuel IP ID. S'il a été incrémenté d'un incrément, un seul paquet a été envoyé, donc le port est fermé (le paquet envoyé étant le RST envoyé à la suite du ACK/SYN non-sollicité de l'attaquant). S'il a augmenté de deux incréments, un autre paquet a été envoyé, a priori le paquet RST envoyé à la suite du ACK/SYN non-sollicité de la victime : le port est donc ouvert.
Cette technique est finalement puissante car l'attaquant peut ainsi scanner sans à aucun moment n'avoir besoin de réveler son IP.
L'utilité d'un scan peut paraître réduite de prime abord, mais en réalité, c'est une technique essentielle d'attaque et de sécurité. En effet, la première étape d'un pentest (audit intrusif) est de récupérer des informations sur la cible en général et sur le système d'information. Ainsi, un scanning permet notamment de savoir quels services tournent sur quels machines (et donc en deviner l'utilité, à savoir serveur mail, serveur DNS, etc. afin de cibler l'attaque), mais également de connaître les versions de ces services, afin d'éventuellement détecter de vieux services pouvant être attaqués aisément à l'aide d'exploits publics.
D'un autre côté, de nombreuses entreprises effectuent un scanning régulier de leur infrastructure afin de détecter par exemple d'éventuels ports ouverts qui ne devraient pas l'être (souvent témoins d'une backdoor).
Ceci termine cette section sur les connaissances de base de l'exploitation réseau. Afin d'aller légèrement plus loin, nous vous invitons à consulter le travail qui a été effectué dans le cadre d'un cours projet de système de détection des intrusions : Herkeios. Dans la partie réseau du projet, nous avons diffusé quelques exemples d'implémentation d'attaques de base (SYN flooding, UnNamed Attack, etc.), mais également de techniques de scans exposées ici ou encore de techniques de défense actives (opposées aux défenses passives comme le filtrage par firewalling).
| << Le Denial of Service (DoS) |
9 Commentaires
Afficher tous
| AimiX | 02/10/13 15:24 |
| Merci beaucoup pour ces informations ! |
|
| FrizN | 26/07/12 07:00 |
| Oui totalement. L'idle scan reste plus une belle technique théorique mais est rarement utilisé dans la pratique. |
|
| Anonyme | 25/07/12 17:24 |
| La derniere attaque que vous mentionnez est l'idle port scan il me semble. Comme pour les scans de ports simples, je pense que l'idle scan nécessite d'être effectué dans un environnement maitrisé, où l'on connait les conséquences associées... |
|
| FrizN | 23/07/12 06:27 |
| Les numéros de séquence TCP. |
|
Commentaires désactivés.
Apprendre la base du hacking - Liens sécurité informatique/hacking - Contact
Copyright © Bases-Hacking 2007-2014. All rights reserved.
Copyright © Bases-Hacking 2007-2014. All rights reserved.