Spirit Of Hack

SCTP (Stream Control Transmission Protocol) est un protocole de niveau 4 (transport), comme TCP ou UDP. Il travaille par paquets, séquences, ou encore "chunks".
Bien que ses caractéristiques en fassent un protocole adapté à pas mal d'applications (déploiement de données, transferts à hautes vitesses), il est en particulier impliqué dans le domaine de la téléphonie.

La séquence d'association et le flux suivent un schémas qui s'apparente de loin au handshake TCP mieux connu :
INIT - INIT_ACK -COOKIE_ECHO - COOKIE_ACK - DATA
(pour le détail, suivez le lien tout au début. Il y a en plus des notions de clés secrètes et de hashes qui vont plaire à certains )

Comme pour tous les autres, de nombreuses vulnérabilités existent autour de ce protocole. Pour être plus précis, c'est bien sûr ses différentes implémentations sur les systèmes d'exploitation qui sont faillibles plutot que le protocole en soi.
Pour la plupart il s'agit de dénis de service mais comme le montre un article interressant de Tenable Network Sec, tout 'x'-overflow dont on dit (trop) rapidement qu'il ne mène qu'au DoS peut potentiellement cacher un danger plus grand. Ceci, par exemple : [Linux Kernel 2.6.x SCTP FWD Memory COrruption Remote Exploit]

Ce qui est interressant en outre avec SCTP (comme le montre aussi l'article), c'est que la plupart des systèmes modernes en sont capables sans pour autant être de grosses boites VoIP. La votre, peut être, geek s'empressant de toujours disposer du dernier kernel sortis après demain qui sent encore le plastique chaud.

Ainsi donc SCTP se scanne, comme ses camarades TCP et UDP. C'est juste un peu plus compliqué ou plutot, différent.
Il y a eu des scanners SCTP comme le SCTPScan de Philippe Langlois qu'il présentait à la BlackHat 07 (eu). Je vous le cite parceque c'est une pointure.
A part ca il faut bien reconnaitre que le domaine est un peu laissé à l'abandon. Aujourd'hui le dev' Nmap le reprend avec les premières fonctionnalités de base d'un vrai scanner SCTP :

- scan furtif par demi-association (idée similaire au SYN scan en TCP)
  envois d'INIT chunks, un port ouvert répond par un INIT_ACK chunk, un port fermé par un ABORT
 
- scan 'déceptif' en faisant croire à une association déjà établie (idée similaire aux ACK, FIN, Xmas scans en TCP)
  envois de COOKIE_ECHO chunks. Un port fermé répond par un ABORT et un port ouvert par un...silence. C'est pourquoi le résultat de ce scan                    particulier est forcément soit fermé, soit "ouvert OU filtré" : comme il ne répond rien, ca peut aussi bien venir d'un dispositif de filtrage.
 
- découverte d'hotes en remplacant le 'ping' classique (contournement du filtrage ICMP) par envois d'INIT chunks (idée similaire aux TCP SYN pings)
- traceroute adapté basé uniquement sur le protocole SCTP

En outre le protocole 132 (SCTP pour ceux qui suivent) a été rajouté à la détection de protocoles supportés (scan -sO). Utile si vous hesitez entre un système Win XP (ne supporte pas normalement SCTP) ou Vista (lui, si)
Pour la suite comme pas moins de 42 services associés à SCTP ont déjà été prévus dans les fichiers d'empreintes de Nmap, c'est sur cette voie que le travail va se poursuivre : le fingerprinting, qui mène à la fois à la détection de versions de services et aussi à la détermination des systèmes d'exploitation (il y a là aussi des numéros de séquences à surveiller, comme c'était déjà suspecté à la BH07)

7/sctp  echo            
9/sctp  discard         
20/sctp     ftp-data        
21/sctp     ftp             
22/sctp     ssh             
80/sctp http            
179/sctp    bgp             
443/sctp    https           
1167/sctp   cisco-ipsla     
1812/sctp   radius          
1813/sctp   radacct         
2225/sctp   rcip-itu        
2427/sctp   mgcp-gateway    
2904/sctp   m2ua            
2905/sctp   m3ua            
2944/sctp   megaco-h248     
2945/sctp   h248-binary     
3097/sctp   itu-bicc-stc    
3565/sctp   m2pa            
3863/sctp   asap-sctp       
3864/sctp   asap-sctp-tls   
3868/sctp   diameter        
4739/sctp   ipfix           
4740/sctp   ipfixs          
5060/sctp   sip             
5061/sctp   sip-tls         
5090/sctp   car             
5091/sctp   cxtp            
5672/sctp   amqp            
5675/sctp   v5ua            
7626/sctp   simco           
8471/sctp   pim-port        
9084/sctp   aurora          
9899/sctp   sctp-tunneling  
9900/sctp   iua             
9901/sctp   enrp-sctp       
9902/sctp   enrp-sctp-tls   
11997/sctp  wmereceiving    
11998/sctp  wmedistribution 
11999/sctp  wmereporting    
14001/sctp  sua             
20049/sctp  nfsrdma

Celà dit, entrons un peu dans le vif du sujet. La cible présentée ici est un serveur à scanme.csnc.ch spécialement mis en place pour le developpement chez Nmap qui dispose de toutes les autorisations nécessaires.
Le scan basic habituel TCP SYN ne montre pas grand chose, c'est le moins qu'on puisse dire :


Un scan de protocoles supportés nous en dit plus :

Notre protocole 132 apparait, SCTP.

Dès lors il est pertinent de lancer l'un ou l'autre des scan SCTP dédiés :

scan SCTP INIT chunk


scan SCTP COOKIE-ECHO

Comme décrit plus haut il est aussi possible d'obtenir un traceroute adapté SCTP en utilisant un port dont on prévoit l'inexistance (16) :


Une limitation au scan SCTP est le fait qu'habituellement il ne devrait pas passer un réseau NATé : la plupart des boxes ne savent pas comment traduire les paquets SCTP.

Vous pouvez découvrir les techniques de scan SCTP avec la dernière Béta Nmap : 4.85BETA10
...en attendant la prochaine stable d'ici quelques semaines dans toutes les bonnes distros.

Scanning is not a crime.