阿斯提亚神殿——梦幻天子's sky

Something about virus loading limitation

============================

1.      This virus will check the VM by using some unique instructions for VMWare or VPC. So this virus could not be run in VMWare or VPC unless Hardware-level virtualization has been enabled. 

2.      The victim computer will use “Rundll32.exe <virus dll>, <random parameter>, or “rundll32.exe <virus rename>” .

1)      For the first kind, the random parameter is calculated by hashing the Computer Name of the victim machine, so if the hash is incorrect. The virus failed to load.

2)      For the second kind, although it does not use the random parameter is not needed, the virus name SHOULD not be the dll extension, otherwise the virus failed to load.

 

Something about Hiding Tricks for Conficker.B

=======================================

Conficker is far away from the professional Rootkits:

1.      For Register Entry Hiding, the virus just modifies the permission of the specific service.

2.      The virus uses undocumented method to create the service(Do not call CreateService API), instead it create the service entry by modifying the registry.

In this case, the service could run properly, but we could not see this service in “Services.msc” before a reboot for creating this service.

       After the reboot, we could see this virus in “Services.msc”.

3.      For file hiding, it just sets the virus file attribute to “RHSA”.

4.       In the “Services.msc”, we could see this service, but the status of it is not running:

       

And for Windows 2k, the status is always “Starting”, this is because the virus is running in the DLLMain Function, and Windows Service Manager will treat it as initializing status.

5.      If the virus is running, we could still see the handle in Process Explorer:

      

This virus is running unstable and sometimes itself will crash. In this case, you may not find the handle in Process Explorer, but this not means it is hidden.

6.      This virus will continuously sending mal-formed packets to the LAN network by enumerate all the local IP addresses:

      

      

       After finishing sending the packets, the virus will wait for a long time, and during this period, you will not see any suspicious packets.

7.      The driver’s file name is always 0*.tmp(01.tmp,02.tmp, etc). It is extracted from the dll file when the dll virus loaded for the first time of each reboot. This .tmp driver will loaded to memory just to modify the memory of the tcpip.sys module to add the limitation of TCP Maximum Half-connection attempts number. And the dll will delete this file, unload the driver, and delete the service entry immediately.

       

That is all about Conficker. Hope we could kill it soonerJ

If you read Dan Kaminsky's researchs over the past few years, you'd probably
that Dan know many DNS tricks. One of these is the CNAME trick that Dan
mentioned in the Wired
interview<http://blog.wired.com/27bstroke6/2008/07/kaminsky-on-how.html>.
He has talked about this trick back to
2007<http://www.doxpara.com/slides/DMK_BO2K7_Web.ppt>as below:

1. CNAME Records: DNS Aliases

- Instead of returning an address, return what the "Canonical", or Official
Name was, and then the address of that Canonical Name

- If you are allowed to be the resolver for that canonical name, your
additional record overrides whatever's already in the cache, even if the TTL
hasn't expired yet

* It's not a bug.

* Works against most, but not actually all name servers

2. Demo

$ dig 1.foo.notmallory.com
;; ANSWER SECTION:
1.foo.notmallory.com. 120 IN CNAME bar.foo.notmallory.com
bar.foo.notmallory.com. 120 IN A 10.0.0.0

$ dig bar.foo.notmallory.com
bar.foo.notmallory.com. 111 IN A 10.0.0.0

$ dig 2.foo.notmallory.com
2.foo.notmallory.com. 120 IN CNAME bar.foo.notmallory.com.
bar.foo.notmallory.com. 120 IN A 10.0.0.1

$ dig bar.foo.notmallory.com
bar.foo.notmallory.com. 118 IN A 10.0.0.1

As you can see, this trick, Dan called it "CNiping", can be used to
overwrite whatever is www.yourwebsite.com. I guess when Dan talked to Paul
Vixie, Paul told him that not only CNAME can be used to overwrite cached
data but also NS, and probably other type of RRs as well. This is not new.
RFC3833 has told us about this DNS *feature* for years.

Okie so now, we have some ways to overwrite cached data in a DNS resolver,
the remained problem is how to force it to accept our packet. And you
probably know this already, so I don't repeat here.

The rest of this post to to emphasize on how easy to guess the QID if we
have a fast Internet connection. Much of the following part is derived from
this study (
http://www.faqs.org/ftp/internet-drafts/draft-hubert-dns-anti-spoofing-00.txt
).

Assume the following symbols are used:

I: Number distinct IDs available (maximum 65536)

P: Number of ports used (maximum around 64000, but often 1)

N: Number of authoritative nameservers for a domain (averages
around 2.5)

F: Number of 'fake' packets sent by the attacker

R: Number of packets sent per second by the attacker

W: Window of opportunity, in seconds. Bounded by the response
time of the authoritative servers (often 0.1s)

D: Average number of identical outstanding questions of a resolver
(typically 1, see Section 5)

A: Number of attempts, one for each window of opportunity

The probability of spoofing a resolver is equal to amount of fake packets
that arrive within the window of opportunity, divided by the size of the
problem space.

When the resolver has 'D' multiple identical outstanding questions, each
fake packet has a proportionally higher chance of matching any of these
questions. This assumption only holds for small values of 'D'.

In symbols, if the probability of being spoofed is denoted as P_s:

P_s = D*F/N*P*I

It is more useful to reason not in terms of aggregate packets but to convert
to packet rate, which can easily be converted to bandwidth if needed.

If the Window of opportunity length is 'W' and the attacker can send 'R'
packets per second, the number of fake packets 'F' that are candidates to be
accepted is:

F= R * W ---> P_s = D*R*W/N*P*I

To calculate the combined chance of at least one success, the following
formula holds:

P_cs = 1 - (1 - P_s)^A = 1 - (1 - D*R*W/N*P*I)^A

When common numbers (as listed above) for D, W, N, P and I are inserted,
this formula reduces to:

P_cs = 1 - (1 -R/1638400)^A

The different between this attack and the one described in the original
study (
http://www.faqs.org/ftp/internet-drafts/draft-hubert-dns-anti-spoofing-00.txt)
is in the number A.

In the original study, A = T/TTL, where T is the time taken to successful
poison target resolvers, and TTL is the number of seconds when the target
hostname expires. In other words, each time we fail to poison, we must have
to wait for TTL second before trying again.

In this case, A = N, which is the number of queries we send to target
resolvers. This is because we don't have to wait any second even if we fail
to poison in all previous attempts. Remember the CNAME trick above?

So all you must do now is to increase R and A. Suppose for each query, you
send F = 30 fake responses to target resolvers in W = 0.1, hence your
bandwidth should be R = F/W = 300 packet/s. If A = 4000, then you stand a
51% chance to be sucessful! It's that easy.

If you use Metasploit, you can use the following formula to calculate your
probability:

P_cs = 1 - (1 - xids/2^16)^A

where xids is the number of fake responses you want to send for each query.
Remember to consider your bandwidth capacity when choosing xids. If you
choose the default value, i.e. xids=10, then you can expect to poison
successful after A>4000.

One final note: this attack is not a birthday attack. because we only have
one opening query to guess its QID.

It's a famous IIS vulnerability whose Exploit code is called "the red code".  Due to its great reputation, I did a simple analysis with the bug code(between the lines):

idq!CVariableSet::AddExtensionControlBlock:
6e90065c mov eax,0x6e906af8
6e900661 call idq!_EH_prolog (6e905c30)
6e900666 sub esp,0x1d0
6e90066c push ebx
6e90066d xor eax,eax
6e90066f push esi
6e900670 push edi
6e900671 mov [ebp-0x24],ecx
6e900674 mov [ebp-0x2c],eax
6e900677 mov [ebp-0x28],eax
6e90067a mov [ebp-0x4],eax
6e90067d mov eax,[ebp+0x8]; the parameter "EXTENSION_CONTROL_BLOCK"
.
.
.
6e9006b7 mov esi,[eax+0x64];offset "lpszQueryString"
6e9006ba or ecx,0xffffffff
6e9006bd mov edi,esi
.
.
.
6e9007b7 push 0x3d;ascii '='
6e9007b9 push edi
6e9007ba mov [ebp-0x18],edi
6e9007bd call dword ptr [idq!_imp__strchr (6e8f111c)]
6e9007c3 mov esi,eax
6e9007c5 pop ecx
6e9007c6 test esi,esi
6e9007c8 pop ecx
6e9007c9 je 6e9008d2
6e9007cf sub eax,edi
6e9007d1 push 0x26
6e9007d3 push edi
6e9007d4 mov [ebp-0x20],eax ;store the address of '='
6e9007d7 inc esi
6e9007d8 call dword ptr [idq!_imp__strchr (6e8f111c)]
6e9007de mov edi,eax
6e9007e0 pop ecx
6e9007e1 test edi,edi
6e9007e3 pop ecx
6e9007e4 jz 6e9007fa
6e9007e6 cmp edi,esi
6e9007e8 jnb 6e9007f0
6e9007ea inc edi
6e9007eb jmp 6e9008e4
6e9007f0 mov eax,edi
6e9007f2 sub eax,esi
6e9007f4 inc edi
6e9007f5 mov [ebp-0x14],eax
6e9007f8 jmp 6e900804
6e9007fa mov eax,[ebp-0x10]
6e9007fd sub eax,esi
6e9007ff add eax,ebx
6e900801 mov [ebp-0x14],eax
6e900804 cmp dword ptr [ebp-0x20],0x190 ; key comparison
//it shows that the distance between the beginning of lpszQueryString and the address of '=' must not greater than 0x190(400)
6e90080b jb 6e900828
/* case greater than 0x190, throw the exception
6e90080d mov eax,0x80040e14
6e900812 xor ecx,ecx
6e900814 mov [ebp-0x3c],eax
6e900817 lea eax,[ebp-0x3c]
6e90081a push 0x6e9071b8
6e90081f push eax
6e900820 mov [ebp-0x38],ecx
6e900823 call idq!_CxxThrowException (6e905c36)
*/
/* case lower than 0x190
6e900828 mov eax,[ebp+0x8]
6e90082b push dword ptr [eax+0x8]
6e90082e lea eax,[ebp-0x1dc];about 476-bytes long from the returning address
6e900834 push eax
6e900835 lea eax,[ebp-0x20]
6e900838 push eax
6e900839 push dword ptr [ebp-0x18]
6e90083c call idq!DecodeURLEscapes (6e9060be); this function convert the original ANSI string to the Unicode version and stored in [ebp-0x1dc]
{
query!DecodeURLEscapes:
68cc697e mov eax,0x68d667cc
68cc6983 call query!_EH_prolog (68d4b250)
68cc6988 sub esp,0x30
68cc698b push ebx
68cc698c push esi
68cc698d xor eax,eax
68cc698f push edi
68cc6990 mov edi,[ebp+0x10]
68cc6993 mov [ebp-0x3c],eax
68cc6996 mov [ebp-0x38],eax
68cc6999 mov ecx,[ebp+0xc]
68cc699c mov [ebp-0x4],eax
68cc699f mov [ebp-0x18],eax
68cc69a2 mov ecx,[ecx];distance
68cc69a4 cmp ecx,eax
68cc69a6 mov [ebp-0x10],ecx; store the "distance" varible to the local stack
68cc69a9 jz query!DecodeURLEscapes+0x99 (68cc6a17)
68cc69ab mov esi,[ebp+0x8]; the address of lpszQueryString
68cc69ae mov eax,ecx
68cc69b0 inc eax
68cc69b1 mov [ebp-0x14],eax ;distance+1
68cc69b4 movzx bx,byte ptr [esi]
68cc69b8 and dword ptr [ebp-0x34],0x0; set 4 bytes of the local stack to 0
68cc69bc cmp bx,0x2b
68cc69c0 jne query!DecodeURLEscapes+0xdf (68cc6a5d)
68cc69c6 push 0x20
68cc69c8 pop ebx
68cc69c9 inc esi
68cc69ca xor eax,eax
68cc69cc cmp [ebp-0x34],eax
68cc69cf jnz query!DecodeURLEscapes+0x79 (68cc69f7)
68cc69d1 cmp bx,0x80
68cc69d6 jb query!DecodeURLEscapes+0x79 (68cc69f7)
68cc69d8 cmp [ebp-0x18],eax
68cc69db jnz query!DecodeURLEscapes+0x79 (68cc69f7)
68cc69dd cmp [ebp-0x3c],eax
68cc69e0 jnz query!DecodeURLEscapes+0x73 (68cc69f1)
68cc69e2 mov eax,[ebp-0x14]
68cc69e5 push eax
68cc69e6 mov [ebp-0x38],eax
68cc69e9 call query!ciNew (68d4a977)
68cc69ee mov [ebp-0x3c],eax
68cc69f1 mov eax,[ebp-0x3c]
68cc69f4 mov [ebp-0x18],eax
68cc69f7 mov eax,[ebp-0x18]
68cc69fa test eax,eax
68cc69fc jz query!DecodeURLEscapes+0x88 (68cc6a06)
68cc69fe mov [eax],bl
68cc6a00 inc eax
68cc6a01 mov [ebp-0x18],eax
68cc6a04 jmp query!DecodeURLEscapes+0x8d (68cc6a0b)
68cc6a06 mov [edi],bx
68cc6a09 inc edi
68cc6a0a inc edi
68cc6a0b dec dword ptr [ebp-0x10] ; decrease the length(400 bytes in maximum)
68cc6a0e dec dword ptr [ebp-0x14]
68cc6a11 cmp dword ptr [ebp-0x10],0x0 ; loop until [ebp-0x10] is 0
68cc6a15 jnz query!DecodeURLEscapes+0x36 (68cc69b4)
68cc6a17 test eax,eax
68cc6a19 jz query!DecodeURLEscapes+0xb4 (68cc6a32)
68cc6a1b sub eax,[ebp-0x3c]
68cc6a1e push eax
68cc6a1f push edi
68cc6a20 push eax
68cc6a21 push dword ptr [ebp-0x3c]
68cc6a24 push 0x1
68cc6a26 push dword ptr [ebp+0x14]
68cc6a29 call dword ptr [query!_imp__MultiByteToWideChar (68c61264)]
68cc6a2f lea edi,[edi+eax*2]
68cc6a32 and word ptr [edi],0x0
68cc6a36 sub edi,[ebp+0x10]
68cc6a39 mov eax,[ebp+0xc]
68cc6a3c push dword ptr [ebp-0x3c]
68cc6a3f or dword ptr [ebp-0x4],0xffffffff
68cc6a43 sar edi,1
68cc6a45 mov [eax],edi
68cc6a47 call query!ciDelete (68d4a9ae)
68cc6a4c mov ecx,[ebp-0xc]
68cc6a4f pop edi
68cc6a50 pop esi
68cc6a51 mov fs:[00000000],ecx
68cc6a58 pop ebx
68cc6a59 leave
68cc6a5a ret 0x10
}
Now, the whole thing comes to light: We could see that DecodeURLEscapes function calculates  the source buffer from the ANSI version string to Unicode version string(also do some filtering work), and then copy the Unicode version to the local stack in AddExtensionControlBlock function, which is 476 bytes faraway from ebp. Unfortunately, in this case DecodeURLEscapes converts at most 400 bytes ANSI chars to Unicode version, which means the output buffer should be as big as 800 bytes, otherwise a buffer overflow attacking could happen.

An attack could sent an HTTP request in which contains a crafted URL to the IIS Server, the flawed module of IIS then parses it and results in buffer overflow.

One key problem is: How to build a special shellcode which could be executed successfully after it is converted to unicode version?

Did you see a shellcode look like this "XX 00 YY 00 ZZ 00", or every byte in it is greate than 0x80?  I have never seen. :(

However, the man called "yuange" realized this. See his article "widechar的字符串缓冲溢出攻击技术" for reference.

 

   

为了毕设的需要，今天写了一个VS2008下编写WDM驱动的template，主要通过VS提供的custom wizard工程，编辑一个wizard的htm以及相关的js文件来实现。

目前还存在以下缺陷：第一，不支持c++，强大的面向对象设计思想暂时还不能应用。第二，必须事先手动设置一个环境变量，指定DDK的路径。

现在终于可以在VS中新建驱动工程了。相比以前在记事本里写驱动代码，VS下看起来还是很舒服的。

有兴趣的朋友可以私下交流具体细节。

 

下一阶段打算研究一下毕设的细节。毕竟这样的机会不多，很可能一生就这一次，今后可能就不会再碰研究领域了，所以呢，要珍惜啦。本次毕设的Code Name暂时命名为：Zion，软件开发部分与MSRA实习生——老BOSS合作完成，目前的计划是：首先合作完成Rootkit底层功能模块，然后我做攻击工具，他做检测工具。

最后，祝愿我一切顺利。