This is very exciting news!
The DNS poisoning via Port Exhaustion whitepaper has been selected 3rd on the annual WhiteHat Security’s Top Ten Web Hacking Techniques list.
The list and details on how it has been selected can be find found here.
-Roee
DNS poisoning via Port Exhaustion
We have just released a very interesting whitepaper which describes a DNS poisoning attack against stub resolvers.
It discloses two vulnerabilities:
- A vulnerability in Java (CVE-2011-3552, CVE-2010-4448) which enables remote DNS poisoning using Java applets. This vulnerability can be triggered when opening a malicious webpage. A successful exploitation of this vulnerability may lead to disclosure and manipulation of cookies and web pages, disclosure of NTLM credentials and clipboard data of the logged-on user, and even firewall bypass.
- A vulnerability in multiuser Windows environments which enables local DNS cache poisoning of arbitrary domains. This vulnerability can be triggered by a normal user (i.e. one with non-administrative rights) in order to attack other users of the system. A successful exploitation of this vulnerability may lead to information disclosure, privilege escalation, universal XSS and more.
The whitepaper can be found here.
A few video demos of our Proof-of-Concept:
- Attack: Remote DNS poisoning via Java Applets: Cookie theft.
Environment: Ubuntu 11.04, Firefox 7.0.1.
- Attack: Remote DNS poisoning via Java Apples: NTLM credentials and Clipboard theft.
Environment: Windows 2008, Internet Explorer 9.
- Attack: Remote DNS poisoning via Java Applets: Firewall bypass.
Environment: Windows 2008, Firefox 7.0.1.
- Attack: Local DNS poisoning via port exhaustion.
Environment: Windows 2008.
We would like to thank Oracle and Microsoft for their cooperation.
-Roee Hay and Yair Amit
Android Browser Cross-Application Scripting (CVE-2011-2357)
Recently Yair Amit and I have discovered a Cross-Application Scripting vulnerability in Android’s Browser, which allows malicious applications to bypass Android’s sandboxing model, in order to inject JavaScript code into an arbitrary domain.
Full details can be obtained from the following sources:
1. Blog post
2. Advisory
3. Demo of PoC:
Full details can be obtained from the following sources:
1. Blog post
2. Advisory
3. Demo of PoC:
Android Browser CAS (CVE-2011-2357)
Babylon Cross-Application Scripting Code Execution
Recently Yair Amit and I have discovered a Cross-Application Scripting vulnerability in Babylon which could lead to code execution.
Full details can be obtained from the following references:
1. Blog post
2. Advisory
3. Proof of concept:
-Roee
Full details can be obtained from the following references:
1. Blog post
2. Advisory
3. Proof of concept:
-Roee
Exploitation of CVE-2009-1869
During the research of the Flash vulnerability I’ve managed to create a functional PoC.
The process of the exploit is the following:
- Spray the heap in order to achieve the following:
- The aforementioned path conditions would pass.
- A DWORD memory overwrite with user controlled target and value would take place when the vulnerability is triggered.
- Allocate a placeholder for the shellcode. The target of the memory overwrite would be some function pointer, the value would be the location of the shellcode’s placeholder.
- Trigger the vulnerability.
- Free the placeholder of the shellcode.
- Allocate the shellcode by spraying the heap.
- Trigger some function which calls the function pointer.
The reason that there are 2 passes for allocating the shellcode is the fact that after the arbitrary overwrite occurs, some random chunks are also written to the location of the shellcode, hence the block has to be freed and re-allocated.
The exploit contains the following components:
- Exploit.fla/as – main code
- HeapLib.as – ActionScript3 Heap Spraying library
The Heap Spraying library bypasses the ActionScript’s maximum execution time limitation by using a Timer that allocates small chunks at each iteration.
It provides two basics functions:
1) alloc(value, size)
2) free() - TriggerVuln.swf - malformed SWF which triggers the vulnerability (i.e: intf_count=0)
- TriggerFunc.fla – ActionScript2 code which triggers a call to the function pointer by invoking LoadVars.sendAndLoad
- Exploit.htm – HTML wrapper for the Exploit.as
The exploit has been tested against Windows XP SP3 with IE7. Flash is assumed to be loaded at VA 0x10000000. However, since the vulnerable code is wrapped by a permissive SEH handler, brute-force is possible (not covered by the PoC).
The binaries and source code of the PoC can be found here.
Advisory: Adobe Flash Player and AIR AVM2 intf_count Integer Overflow
Background
ActionScript code is compiled into ActionScript Byte Code segments, loaded by AVM2 (ActionScript Virtual Machine 2).
These segments are described by the abcFile structure:
abcFile
{
u16 minor_version
u16 major_version
cpool_info constant_pool
u30 method_count
method_info method[method_count]
u30 metadata_count
metadata_info metadata[metadata_count]
u30 class_count
instance_info instance[class_count]
class_info class[class_count]
u30 script_count
script_info script[script_count]
u30 method_body_count
method_body_info method_body[method_body_count]
}
The value of class_count element is the number of entries in the instance and class arrays. Each instance entry is a variable length instance_info structure which specifies the characteristics of object instances created by a particular class:
instance_info
{
u30 name
u30 super_name
u8 flags
u30 protectedNs
u30 intrf_count
u30 interface[intrf_count]
u30 iinit
u30 trait_count
traits_info trait[trait_count]
}
The value of the intrf_count field is the number of entries in the interface array. The interface array contains indices into the multiname array of the constant pool; the referenced names specify the interfaces implemented by this class.
Vulnerability
An integer overflow exists in the AVM2 abcFile parser code which handles the intrf_count value of the instance_info structure.
When intrf_count is larger than 0x10000000, it is nullified due to an integer overflow. This results in an out of bounds pointer dereference. The out of bounds object contains arbitrary values (in the context of the code which handles the interfaces count element) which are manipulated in a way so that an arbitrary memory overwrite with an attacker supplied destination and value is possible.
The following is a detailed run trace which explains the vulnerability. Irrelevant instructions are omitted. Flash10b.ocx is assumed to be loaded at VA 10000000h.
let <intrf_count> be 0x10000000
.text:10206B03 mov edi, [esp+50h+var_2C]
; EDI=<intrf_count>=0x10000000
.text:10206B14 lea edx, [edi+edi]
; EDX=<intrf_count*2>=0x20000000, may not overflow (verified elsewhere)
.text:10206B1B call sub_101EAC30
.text:101EAC45 call sub_101EAB90
.text:101EAB98 call sub_101D1FF0
; this method calculates the nearest power of 2 for <intrf_count*2> (i.e: stays 0x20000000)
.text:101EABA0 add eax, eax
; doubles that value (i.e: EAX=0x40000000)
.text:101EABCC lea ecx, ds:0[eax*4]
; multiplies it by 4 (i.e: ECX=0x00000000) =>OVERFLOW<=
.text:101EABDA call sub_10224C62
.text:10224C62 jmp sub_10224363
.text:10224363 mov edx, [esp+arg_0]
; arg_0 is the overflown value (i.e: EDX=00000000)
.text:10224367 lea eax, [edx+7]
.text:10224376 and eax, 0FFFFFFF8h ; EAX=00000000
.text:1022437A mov esi, eax ; ESI=00000000
.text:102243A4 mov ecx, esi ; ECX=00000000
.text:102243A9 mov eax, [eax+ecx*4-4]
; the overflown value is used as an index into pointer table, starting at EAX.
; since we can cause ECX to become 0x0000000, we may select an out of bounds
; pointer (eax-4). Tests show that it always contains a valid pointer to some
; object, with arbitrary values. i.e: EAX=&OutOfBoundsObject
.text:102243AD mov ecx, eax ; ECX=&OutOfBoundsObject
.text:102243C8 call sub_10226D4D
.text:10226D53 mov ebx, ecx ; EBX=&OutOfBoundsObject
.text:10226D6C mov esi, [ebx+8]
; ESI=&ArbitraryObjectA (usually: 0x55555555)
.text:10226D76 test byte ptr [esi+2Ah], 1
; <PathConditionA >- must pass this in order to continue
.text:10226D7A jz short loc_10226DA5
.text:10226D7C mov eax, [ebx+38h]
; EAX=&ArbitraryObjectB, (usually 0x55555557)
.text:10226D7F cmp byte ptr [eax+33Ch], 0
; <PathConditionB> - must pass this in order to continue
.text:10226D86 mov ecx, ebx ; ECX=&OutOfBoundsObject
.text:10226D88 jnz short loc_10226D9D
.text:10226D8A push esi
.text:10226D8B call sub_10226CAF
.text:10226CB0 mov esi, [esp+4+arg_0]
; ESI=&ArbitraryObjectA, (usually 0x55555555)
.text:10226CB5 push esi
.text:10226CB6 mov edi, ecx ; EDI=&OutOfBoundsObject
.text:10226CB8 call sub_102266CA
.text:102266CA mov eax, [esp+arg_0]
; EAX=ESI=&ArbitraryObjectA (usually 0x55555555)
.text:102266DB mov ecx, [eax+1Ch]
; ECX=arbitrary value - usually *(0x55555571)
.text:102266CE mov edx, [eax+20h]
; EDX=arbitrary value - usually *(0x55555575)
.text:102266DE mov [ecx+20h], edx;
; jackpot - a write of an arbitrary DWORD to an arbitrary VA
The following is an illustration of the pointer table and the out of bounds pointer which may be dereferenced:
addr val
0017487C 00E82000 <- EAX-4 (ECX=0)
00174880 001681C8 <- EAX (ECX=1)
00174884 00174AC8
00174888 00174BD0
0017488C 00174CD8
00174890 00174DE0
00174894 00174EE8
00174898 00174FF0
0017489C 001750F8
001748A0 00175200
001748A4 00175308
001748A8 00175410
001748AC 00175518
001748B0 00175620
001748B4 00175728
001748B8 00175830
001748BC 00175938
001748C0 00175A40
001748C4 00175B48
001748C8 00175C50
001748CC 00175D58
The following is a memory dump of the out of bounds object:
00E82000 44 51 55 55 55 45 55 75 55 55 55 55 55 55 55 55
00E82010 55 55 55 55 55 55 55 54 55 55 55 55 01 00 00 00
00E82020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50
00E82030 55 55 55 55 D5 55 55 55 57 55 55 55 55 55 55 55
00E82040 D5 5A 55 55 54 55 55 55 55 55 55 55 75 B5 56 55
00E82050 55 55 55 55 15 55 55 D5 55 55 AD 55 77 D5 55 55
00E82060 55 55 55 55 D5 D5 BA 56 55 55 55 55 55 55 6B 55
00E82070 B5 56 55 55 57 55 55 01 00 00 00 00 00 00 00 00
00E82080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00E82090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00E820A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00E820B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00E820C0 00 00 00 00 00 00 00 00 00 00
To make things more clear:
Let 'ArbitraryObjectA' be pointed by (&OutOfBoundsObject+0x8)
Let 'ArbitraryObjectB' be pointed by (&OutOfBoundsObject+0x38)
In order to reach the arbitrary overwrite, there are three conditions
1) intrf_count >= 0x10000000 // in order to overflow
2) PathConditionA: ((char *)ArbitraryObjectA)[0x2e] == 1 // .text:10226D76
3) PathConditionB: ((char *)ArbitraryObjectB)[0x33c] == 0 // .text:10226D7F
Given the conditions are passed, a memory DWORD overwrite of arbitrary target and value occurs:
*(DWORD *)((*(DWORD *)(ArbitraryObjectA+0x1c))+0x20) = *(DWORD *)(ArbitraryObjectA+0x20)
Exploitation
Since the out of bounds object contains arbitrary values, the attacker may spray the heap so he/she would have control over ArbitraryObjectA and ArbitraryObjectB (they would be located at addresses which contain data controlled by the attacker). This may allow him/her to pass all aforementioned conditions and also control the value which is written in the arbitrary memory MOV and the target of it. Achieving this may allow him the execute arbitrary code.
During the research of this vulnerability I’ve managed to create a functional exploit (demo: http://www.youtube.com/watch?v=wJb6a-J3i4c).
Attack vector
Lure the victim to open a malicious SWF file
Impact
Remote Code Execution
Test Environment
- Adobe Flash Player 10.0.22.87
- Windows XP SP3.
Identifiers
1. CVE-ID: CVE-2009-1869
2. BID: 35907
Remediation
New versions of Adobe Flash Player (10.0.32.18) and AIR (1.5.2) have been released in order to address this vulnerability.
References
- "ActionScript Virtual Machine 2 (AVM2) Overview", Adobe Systems, Inc.
- Adobe’s advisory
Adobe Flash Player Integer Overflow Remote Code Execution
Adobe has just released a new version of Flash Player (10.0.32.18).
This update addresses a Remote Code Execution vulnerability (CVE-2009-1869) I reported to Adobe a month ago.
I would like to thank Adobe for the efficient way in which they handled this security issue.
A full advisory will be posted on Sunday. In the meanwhile, I’ve uploaded a video which demonstrates a successful exploitation of this vulnerability:
