This time, bad guys still use a not-new-script, which is spreading poisonous links though social networking site Facebook to cheat users into accessing phishing, malicious websites.

The new trick of this campaign is the faking of YouTube plugin for Firefox and Chrome browsers. This shows hackers’ investment, close following-up and continuous changes.

Hackers convince users that they have to install the plugin to be able to watch the video.

Once users agree to install the fake plugin, their Facebook accounts will become poisonous spam link resources with their friend’s walls. Of course, the culprit is definitely the plugin they have just installed.

Back to history, if you have read our older blog entries about the spreading of poisonous code though Facebook, it’s easy for you to picture out the development in hackers’ methods. First, hackers registered domain name similar to Facebook’s and “waited” for users’ mistyping. Then, they changed to entice users into running javacript in the address bar of their browsers. And this time they make users install fake YouTube plugin for Firefox or Chrome. Hackers always invent new methods once users have been aware of and got to be watchful towards the old methods. Therefore, the best way to avoid falling into hackers’ traps is to enhance our own vigilance of shared or received links. At the same time, it’s advisory that users install strong antivirus software to make their computers comprehensively protected.

Nguyen Cong Cuong

Senior Malware Researcher

Firstly, I would like to say thank to Dan Rosenberg for his interesting information on the mechanism of ROP mitigation on Windows 8. Also, I highly appreciate Nguyen Hong Son, my young fellow, for his effort in specifying Dan’s method into a generic ROP chain. However, it is easy to find out that there are two issues in the ROP chain:

• For the first issue, it requires EAX to point to a valid stack value before entering ROP chain; else, ROP chain cannot be used. In fact, there are many cases we have no register to store ESP value (e.g. in cases “pivoting stack” by MOV ESP, R32 instruction instead of XCHG). Even when there is any register other than EAX to store the valid ESP value, transferring it to EAX by “ROP gadgets” is not always easy. So, to have a “generic ROP chain” which can be widely used on Windows 8, this issue must be solved.

• Other issue lies on the length of ROP chain. While generic ROP chains on Windows 7 are rather short (18 dwords with new Corelanc0d3r’s ROP chain, and 22 dwords with Sayonara’s ROP chain), this ROP chain has about 100 dwords. My fellow or anyone else following Dan’s method may make “the ROP chain” shorter if he focuses on optimizing the use of “ROP gadgets”, but the chain is still rather long in comparison with ROP chains on Windows 7. I believe so. Since our exploit code sometimes may face strict conditions regarding size, the length of a ROP chain is also a concerning matter, like the matter of shellcode’s length. Moreover, I still think that a short and tidy ROP chain will have more beauty and perfection.

Focusing on the protection mechanism of Windows 8, I have made a new generic ROP chain based on my own method. And more importantly, it solves the above issues.

My Rop chain, also built on the same library msvcr71.dll as the mentioned ROP chains, has 3 stages:

Stage 1: Determine the valid stack range

This stage will make EAX point to a valid stack range with current check method of Windows 8. Thereby, the first issue I mentioned above can be solved.

Back to Dan Rosenberg’s idea in his sample, he will restore old stack (which before “pivot the stack”) to bypass the check mechanism. This is the stack range previously used normally, thus it is obviously valid. This is a good solution if we have some registers to backup old stack in order to restore it. However, here I am discussing the case no register can meet our requirements.

Now have a look at Windows’s check mechanism: ESP value will be valid if it is in range between “stack min” (FS:[8] ) and “stack max” (FS:[4]). So, why don’t use “stack min”? It will obviously bypass the check method. If I can get the value, I will have a huge valid stack range for use. So, I will look for this value.

The searching on msvcr71.dll for ROP gadgets which directly interact with FS:[8] does not bring about results. It is easy to understand since StackBase and StackTop values are often accessed from TEB structure. Thus, I look for gadgets referring to &(TEB) ( FS:[18] ), and get only one result at 0x7c34d38f :

At first glance, this sequence of instructions seems inappropriate to become a “ROP gadget” due to too many calculations and jump instructions before RETN. However, this is the only result found on msvcr71.dll which has reference to FS:[18], so I analyze it carefully. This piece of code seems to be also verifying wshether EBX is between StackBase and StackTop. Luckily, I found out that if the registers are arranged in an appropriate way, I can store FS:[18] value (or StackBase pointed by ecx) into where I want ( [EBP+8] or [EBP-4] ), and nicely return to ROP chain. Follow is Stage 1 with 13 dwords:

Stage 2: Copy a Win7 ROP chain to the valid stack range, then return to it.

Here, I will solve the length issue of ROP chain. The gap of length between Dan’s ROP chain and other ROP chains on Windows 7 is rather high because it has more calculations, data movements between registers and data writing on memory. The limits of ROP gadgets often make things complicated. While ROP chains on Windows 7 have simple calculations, reasonably utilize PUSHAD to push data onto stack, and then perform function call.

Shortly after Microsoft’s release of Windows 8 Developer Preview, I read an article mentioning the mechanism to prevent ROP (Return Oriented Programming) on Windows 8 and the way to bypass it.  Accordingly, I have experimented and provided a ROP chain which could be used for any ROP exploit codes on Windows 8.

Let’s talk about the mechanism to prevent ROP exploitation of Windows 8. As what we have known, when writing ROP exploit code, it is common to sort out a series of commands to execute some functions such as Virtual Protect, Virtual Alloc or other ones which operate with Virtual Memory. Therefore, Windows 8 carries on testing stack by comparing ESP register before calling these functions. If ESP is between StackBase (FS:[8]) and StackTop (FS:[4]), the stack address is valid and functions will continue to be executed. Otherwise, stack is invalid and the program will be terminated. However, apart from the fact that this mechanism does not work with “stack buffer overflow” errors, it is not really difficult to be bypassed in case of other flaws. The solution here is to save the stack address (ESP register) and restore it before calling functions.

I have tested the above method with CVE-2011-0065 of Firefox. This error has already had exploit code on Windows 7, in which Corelan’s ROP chain for Windows 7 was used. Since new protection mechanism is added to Windows 8 (as mentioned above), this ROP chain (as well as other ROP chains previously written and popularly used on Windows 7) does not work on Windows 8.

As said at the beginning, I have built a new ROP chain which can bypass the protection mechanism on Windows 8 and will be convenient for use in later exploitations.

The piece of ROP chain is built:

-         Using msvcr71.dll – v7.10.3052.4 module

-         Integrated with: JRE (Java) 1.6

-         Loading with browser

-         Able to work on Windows XP/Vista/Win7/Win8/2003/2008

-         ASLR-free

-         Using kernel32.VirtualProtect function

-         Base: 0x7c340000.

-         Size 0×56000.

Of course, you just need to use this ROP chain instead of the old one when changing stack address is required for your ROP exploit code. My ROP chain starts with the condition that EAX is pointing to a valid stack area (i.e. between FS:[4] and FS:[8]). Therefore, to be able to use it, you should have a register or memory area that holds a valid stack address (usually the old stack address before the change) before entering ROP chain; then convert it into EAX and start ROP chain.

When being tested, the ROP chain runs smoothly on Windows 7, Windows 8 and some other operating systems.

Here is the demo code.

Nguyen Hong Son

Security Researcher

Spreading malware via email has always been so effective, that it is still widely used by bad guys. As you may know, there were times when email worms like MyDoom, Brontok, etc. infected millions of computers worldwide. Nevertheless, due to efforts of security agencies and antivirus vendors to warn users, the attachment of virus onto emails is becoming less effective than it used to be. Users are now more watchful towards emails with attachments from unknown origins, pay more attention to files’ extensions despite how similar their icons may be. This has forced bad guys to change their methods.

One of the considerable new methods is to exploit RLO (Right to Left Override) to hide the files’ extensions so that users will think they are safe files.

What is the nature of this issue? With right to left languages such as Arabic or Hebrew, Microsoft supports the reserve display of a character set through the insertion of a code (U+202E) onto the beginning of that set. Let’s see the example of a file named XXXcod.exe. After U+202E is inserted before the character “c”, the file will be displayed as XXXexe.doc. In this case, if the bad guy cloaks his file with a .doc file’s icon, will you have a fleeting doubt or immediately open the file?

This is indeed a virus’ executable file.

It can be seen that this is quite a sophisticated technique, even experts might be cheated if they do not pay proper attention. To protect your computer, you should examine the files’ attributes before running them. If a file is specified to be an executable one (.exe, .scr, .pif, etc.) but displayed with another extension, it is a virus.

In a simpler way, you can run the files in Sandbox to ensure the safety for your computer. The best is to use a licensed antivirus program to have a comprehensive protection against viruses.

Phạm Tuấn Vũ – Bkav R&D

Recently, users in many businesses’ networks find they suddenly cannot access any websites. Instead, they see a request to update their browsers.

On clicking “Bowser update”, a “program” is supposed to be downloaded to “update” users’ browsers.

This is indeed a virus.

LANs with such problems all have at least 1 computer infected with W32. Gatpaz.Worm. This virus imitates DHCP server, sends configuration information to clients to replace their DNS addresses with hacker’s server. Then, when the infected computers attempt to connect to the Internet, users will be redirected to phishing websites crafted by hacker.
Only LANs using DHCP Server for dynamic IP address assignment are affected.

In this IP address assignment model, each LAN is equipped with one DHCP server which is in charge of managing and assigning IPs to its clients. When a certain client needs an IP address to connect to the Internet, it broadcasts a message saying DHCPDISCOVER across the network. Upon receiving the message, DHCP server will process and allocate the client an IP address. The broadcasting process is where hacker exploits to build a fake DHCP server, provided Gatpaz has been successfully installed on any client of the network. Besides allocating IP address to the client, the fake DHCP Server changes the client’s DNS Server into hacker’s one. The hacker then gets the total control of users’ accessing websites.

To completely solve such phenomenon that viruses destroy businesses’ networks, Bkav recommends that a comprehensive enterprise antivirus solution be employed.

Analyst: Ngo Anh Huy – Bkav R&D