Technique de scan avance

Autres technique de scanning avancé

Dans cette article, nous allons voir des options plus avancées de scanne. Pour ce faire nous utiliserons plusieurs outils :

  • Nessus
  • Nmap (NSE)
  • Modules Metasploit
  • Xprobe2
  • Lbd
  • OpenVas

Nous allons aussi utiliser le Framework recon-ng qui est un Framework de scanning et reconnaissance très intéressant.

Recon-ng est un Framework qui permet de réaliser efficacement et rapidement une reconnaissance publique de votre cible. Ce framework est diffusé sous licence GPL, codé en Python, et disponible sur le dépôt Git du créateur sur Bitbucket.

LBD :

LDB pour load balancing detector est un outil qui permet de detecter si un domaine utilise un DNS et/ou un HTTP Load-Balanceur.

pour lancer lbd il suffit de taper dans un terminal :

root@kali:~# lbd 

lbd - load balancing detector 0.4 - Checks if a given domain uses load-balancing.
                                Written by Stefan Behte (http://ge.mine.nu)
                                Proof-of-concept! Might give false positives.
usage: /usr/bin/lbd domain [port] {https}

root@kali:~# lbd www.google.com
Checking for DNS-Loadbalancing: NOT FOUND
Checking for HTTP-Loadbalancing [Server]: 

 NOT FOUND

Checking for HTTP-Loadbalancing [Date]: 19:09:21, 19:09:21, 19:09:21, 19:09:21, 19:09:21, 19:09:21, 19:09:21, 19:09:21, 19:09:22, 19:09:22, 19:09:22, 19:09:22, 19:09:22, 19:09:22, 19:09:22, 19:09:22, 19:09:22, 19:09:22, 19:09:22, 19:09:23, 19:09:23, 19:09:23, 19:09:23, 19:09:23, 19:09:23, 19:09:23, 19:09:23, 19:09:23, 19:09:23, 19:09:23, 19:09:23, 19:09:23, 19:09:24, 19:09:24, 19:09:24, 19:09:24, 19:09:24, 19:09:24, 19:09:24, 19:09:24, 19:09:24, 19:09:24, 19:09:24, 19:09:24, 19:09:25, 19:09:25, 19:09:25, 19:09:25, 19:09:25, 19:09:25, NOT FOUND

Checking for HTTP-Loadbalancing [Diff]: FOUND
< Location: http://www.google.fr/?gfe_rd=cr&ei=5RijWZeCI-KE8QfkxYiwDg
> Location: http://www.google.fr/?gfe_rd=cr&ei=5RijWazSJ_KE8QeazobYBA

www.google.com does Load-balancing. Found via Methods: HTTP[Diff]

On voit que google dispose d'un grand nombre de load balanceur au niveau HTTP.

xprobe2 :

xprobe2 est un outil permettant de déterminer de façon plus fine (que NMAP par exemple) quel type d'OS tourne au sein d'une cible avec la possibilité de spécifier des options afin de préciser au mieux l'OS de la cible.

Pour mieux visualiser l'outil nous allons en premier faire le scan avec nmap afin de comparer sa sortie avec xprobe2.

root@kali:~#  nmap -sS -O 192.168.1.11
...
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6
OS details: Linux 2.6.9 - 2.6.33

Lançons maintenant le même test avec xprobe2 :

root@kali:~# xprobe2 192.168.1.11

Host 192.168.1.11 Running OS: "Linux Kernel 2.4.30" (Guess probability: 100%)
[+] Other guesses:
[+] Host 192.168.1.11 Running OS: "Linux Kernel 2.4.19" (Guess probability: 100%)
[+] Host 192.168.1.11 Running OS: "Linux Kernel 2.4.28" (Guess probability: 100%)
[+] Host 192.168.1.11 Running OS: "Linux Kernel 2.4.21" (Guess probability: 100%)
[+] Host 192.168.1.11 Running OS: "Linux Kernel 2.4.26" (Guess probability: 100%)
[+] Host 192.168.1.11 Running OS: "Linux Kernel 2.4.23" (Guess probability: 100%)
[+] Host 192.168.1.11 Running OS: "Linux Kernel 2.4.25" (Guess probability: 100%)
[+] Host 192.168.1.11 Running OS: "Linux Kernel 2.4.25" (Guess probability: 100%)
[+] Host 192.168.1.11 Running OS: "Linux Kernel 2.4.23" (Guess probability: 100%)
[+] Host 192.168.1.11 Running OS: "Linux Kernel 2.4.26" (Guess probability: 100%)
[+] Cleaning up scan engine
[+] Modules deinitialized
[+] Execution completed.

On remarque que xprobe2 donne des détails quant à la probabilité en pourcentage de l'OS utilisé.

Scan avec Mestasploit :

Metasploit un framework très riche en module. Il possède en autres de tout une panoplie de module auxiliare de scan qui permettent de faire des scan très élaboré et surtout assez rapide.

Un exemple vaux toujours mieux qu'un long discours :accept:

Comme d'habitude on lance Metasploit :

root@kali:~# msfconsole

Call trans opt: received. 2-19-98 13:24:18 REC:Loc

Trace program: running

Nous allons maintenant lancer une recherche et demander à metasploit de chercher pour nous tous les module de type scanner qu'il possède dans sa base de données.

msf > search scanner
[!] Module database cache not built yet, using slow search

Matching Modules
================

   Name                                                                     Disclosure Date  Rank    Description
   ----                                                                     ---------------  ----    -----------
   auxiliary/admin/appletv/appletv_display_image                                             normal  Apple TV Image Remote Control
   auxiliary/admin/appletv/appletv_display_video  

On choisis d'utiliser un scan de type SYN qui est assez simple et qui vérifie si un port et ouvert.

msf > use auxiliary/scanner/portscan/syn

On observe les options nécessaire pour ce module

msf auxiliary(syn) >show options

Module options (auxiliary/scanner/portscan/syn):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   BATCHSIZE  256              yes       The number of hosts to scan per set
   DELAY      0                yes       The delay between connections, per thread, in milliseconds
   INTERFACE                   no        The name of the interface
   JITTER     0                yes       The delay jitter factor (maximum value by which to +/- DELAY) in milliseconds.
   PORTS      1-10000          yes       Ports to scan (e.g. 22-25,80,110-900)
   RHOSTS                      yes       The target address range or CIDR identifier
   SNAPLEN    65535            yes       The number of bytes to capture
   THREADS    1                yes       The number of concurrent threads
   TIMEOUT    500              yes       The reply read timeout in milliseconds

Les options intérressant sont :

Options Description
INTERFACE interface réseau qu'il faudra utiliser lors du scan (eth0 ...)
RHOSTS @IP de la cible à scanner
PORTS Port que l'on souhaite scanner (ex : 80; 1-65535; 20,21 etc ...)
THREADS Gestion du nombre de paquet concurrent (optimisation vitesse)

On va donc commencer à renseigner nos option:

On choisi ldonc l'interface eth0

msf auxiliary(syn) > set interface eth0
interface => eth0

On renseigne l'adresse IP de notre cible :

msf auxiliary(syn) > set rhosts 192.168.1.11
rhosts => 192.168.1.11

On reseigne ensuite les threads à 50 threads

msf auxiliary(syn) > set THREADS 50
THREADS => 50

On renseigne le port que l'on souhaite scanner ici disons le port 80 on refera cela sur tous les ports :

msf auxiliary(syn) > set PORTS 80
PORTS => 80

On vérifie qu'on a oublié aucunes options importante :

msf auxiliary(syn) > show options

Module options (auxiliary/scanner/portscan/syn):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   BATCHSIZE  256              yes       The number of hosts to scan per set
   DELAY      0                yes       The delay between connections, per thread, in milliseconds
   INTERFACE  eth0             no        The name of the interface
   JITTER     0                yes       The delay jitter factor (maximum value by which to +/- DELAY) in milliseconds.
   PORTS      80               yes       Ports to scan (e.g. 22-25,80,110-900)
   RHOSTS     192.168.1.11     yes       The target address range or CIDR identifier
   SNAPLEN    65535            yes       The number of bytes to capture
   THREADS    50               yes       The number of concurrent threads
   TIMEOUT    500              yes       The reply read timeout in milliseconds

C'est ok let's go on démarre notre scan comme dirait l'autre OKLM :

msf auxiliary(syn) > run

[*]  TCP OPEN 192.168.1.11:80
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Notre scan a bien été réalisé et le port 80 est ouvert on peut apprécier la rapidité du scan :+1:

On peut balayer tous les port en changeant le port à scanner par un range de ports :

msf auxiliary(syn) > set PORTS 1-65535
PORTS => 1-65535
msf auxiliary(syn) > run

[*]  TCP OPEN 192.168.1.11:21
[*]  TCP OPEN 192.168.1.11:22
[*]  TCP OPEN 192.168.1.11:23
[*]  TCP OPEN 192.168.1.11:25
[*]  TCP OPEN 192.168.1.11:53
[*]  TCP OPEN 192.168.1.11:80
[*]  TCP OPEN 192.168.1.11:111
[*]  TCP OPEN 192.168.1.11:139
[*]  TCP OPEN 192.168.1.11:445
[*]  TCP OPEN 192.168.1.11:512
[*]  TCP OPEN 192.168.1.11:513
[*]  TCP OPEN 192.168.1.11:3306
[*]  TCP OPEN 192.168.1.11:3632
hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(syn) > 

Voilà voilà pour un scan basique avec Metasploit.

Maintenant nous allons voir comment faire du IDLE scanning avec Metasploit. Cette fois nous utilisons le module ip/ipidseq puis on vérifie les options :

msf auxiliary(syn) > use auxiliary/scanner/ip/ipidseq 

msf auxiliary(ipidseq) > show options

On choisis notre interface réseau :

msf auxiliary(ipidseq) > set interface eth0
interface => eth0

Ensuite l'adresse de la cible (Metasploit se charge lui même de trouver une machine zombie sur le réseau pour le IDLE scanning) :

msf auxiliary(ipidseq) > set rhosts 192.168.1.11
rhosts => 192.168.1.11

On démarre ensuite notre scan :

msf auxiliary(ipidseq) > run

[*] 192.168.1.11's IPID sequence class: All zeros
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Enjoy