Yispecter and Hummingbad malwares were both distributed by the same Chinese company
Yispecter and Hummingbad malwares were both distributed by the same Chinese company
Mobile Malvertisement Yingmob, an advertising company based in Chongqing, China, is supposedly the group behind the YiSpecter iOS malware and the HummingBad Android malware. The two malwares infect devices to show ads and secretly install other applications, earning their creators money from pay-per-install programs. So much monthly income made from malvertising HummingBad alone delivers over 20…
I can give you FREE FULL Access to a FULL Featured Copy of AVG CloudCare antivirus and security software, NO STRINGS ATTACHED, for 30 days! You don’t have to bring your computer into a shop or have anyone come to your house, EVERYTHING IS DONE ONLINE OVER THE INTERNET! I send you an email with a link to click, it will install AVG CloudCare on your Computer or Windows Based Tablet. After the trial is over, and you decide it is not what you want, a few clicks of the mouse and it can be removed, no questions asked. If you decide you want to continue with AVG CloudCare, you can purchase AVG CloudCare Antivirus & Securtiy Software with a few clicks of the mouse, and your all set! This only takes a few mouse clicks, and is so convenient, all YOU have to do is make the decision to continue with AVG CloudCare. When your renewal time comes up, if you want to renew, a few more clicks and it is DONE! Nothing new to install, AVG CloudCare will automatically update with the new license information. No more lengthy key codes to type or decipher wheteher or not it a 0 or O or a 1 or I a 5 or a S ! There is also the option of buying a hard copy in any regular computer or software store. As AVG CloudCare releases updates, they will update automatically to keep up with the many new threats that appear each day. All updates are always included in the purchase price, and are taken care of in the background so all you got to do is surf the web, and know you are protected by the supreme protection of AVG CloudCare Antivirus and Security Software!
Angler exploit kit using tricks to avoid referrer chain leading back to malvertisement provider
For some time I’ve been seeing the Angler exploit kit pop up and infect clients without through malvertising campaigns without having a referer when visitng the landing page. The reason why this is interesting is that it makes it a lot harder to track down the malicious creative IDs which can be disabled by the advertisement operator. This is key in trying to fight active malvertising campaigns. In this short article I’ll go through the current setup the Angler exploit kit uses to avoid the referer chain by losing it in a 2 step system.
Initial infection chain for Angler
We see an advertiser 'hrd-marketing[.]com' being used and a JavaScript file being requested. A bit after the advertiser related request(s) there is a post to an odd looking HTML file:
This POST request does not contain any referer. In the response of the server we see a meta refresh snippet in a fake 404 page. There is a 200 OK response but a piece of text saying 'Page not found' in the body. If we look for this specific URL in the rest of the Fiddler session we a request going towards it:
Interestingly again no referer, it seems the Angler guys are pulling some tricks to break the referer chain, lets have a look.
Analysis
If you look at the actual referers you find there are none on either the redirector or landing. Let's first look at the advertiser, for this I already took the trouble to filter out the others and pinpointed this one serving the Angler redirect. The reason I did this was to spare 2/3 of a blog about tracking this one down in the insane amount of advertiser chains this one appeared in. For those wondering, the initial site was an adult content website for videos.
Lets start at the advertiser JavaScript, the advertiser gives the following blob back of which the second part (after the newline) is of interest to us. The top part is the real advertisement:
If we take it out and beautify it a bit we get the following:
The script is heavily obfuscated, especially the part of the target URL for the POST request. If you clean it up you end up with this (note: I removed the target URL from the pastebin post to not get it flagged):
So how does their trick work? its actually quite simple but a bug in modern web browser in my opinion.
On the page it first adds a new DIV. Inside this DIV it puts an iframe which does not have a 'src' attribute meaning it is not loading anything from a remote site. However most browsers see the context/body of the iframe (and normally the page it loads based on the 'src' attribute) as a seperate page with its own context; this is pretty much how the Angler referer-less request(s) trick works. In the next step they generate a form with a hidden input (with some unique tokens, not sure what they do but they might mean something for them on their backend). This form is put in the body of the iframe context after which they submit the form. When they submit the form they are sending it from within the iframe context which does not have an actual page loaded which causes the request coming from it to not have a referer; quite a nasty trick.
The small piece of script I created can be used to request pages without referers in the latest versions of Chrome, Firefox and Internet Explorer as of the 7th of May 2015. See it as a POC.
The next step is why is the landing being requests without a referer. Here's how the landing page request looks in Wireshark:
This one is slightly harder to explain and I don't have 100% certainty but I assume this is how browsers are processing it:
When a browser performs a POST request as seen here the response is (in most cases) some external resource being loaded in the page. In the case of the redirector we see the response is HTML which contains a meta refresh tag which changed the page location to the specified URL. My guess is that the browser follows the refresh but due to a bug doesn't follow it with a referer. The thing is however, I only got a POC of this to work on Internet Explorer but could not reproduce it on Chrome or Firefox.
And there we go, two tricks (of which one works on all browsers) to lose referers and frustrate automated systems and researchers like me. It is interesting knowing the Angler history that they come up with these kind of tricks; it certainly helps their malvertising campaign lifetime.
Following the RFC
If we look at the RFC it actually specifies that unless a user manually enters a URL it should always make a referer chain except when coming from an SSL connection:
The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained (the "referrer", although the header field is misspelled.) The Referer request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard.
You can read it here: http://tools.ietf.org/html/rfc2616#section-14.36
Following the RFC it would appear this referer trick is actually a bug in the browsers. In a discussion on this subject with the Google Chrome developers (read it [here] they linked me to the following RFC: W3C Referrer Policy in which the concept of 'Nested Browsing Contexts' is described:
Certain elements (for example, iframe elements) can instantiate further browsing contexts. These are called nested browsing contexts. If a browsing context P has a Document D with an element E that nests another browsing context C inside it, then C is said to be nested through D, and E is said to be the browsing context container of C. If the browsing context container element E is in the Document D, then P is said to be the parent browsing context of C and C is said to be a child browsing context of P. Otherwise, the nested browsing context C has no parent browsing context.
A browsing context A is said to be an ancestor of a browsing context B if there exists a browsing context A' that is a child browsing context of A and that is itself an ancestor of B, or if the browsing context A is the parent browsing context of B.
You can interpret the above text as follows:
You have a website in which you embed an iframe pointing to an HTTP website, call this iframe'd website example-iframe.com
From your initial website you embed a form in the body context of the iframe so in the example-iframe.com website context.
You submit this form which will happen inside the context of example-iframe.com
What you would expect is:
The iframe towards example-iframe.com will have your initial website in its referer
The form submitted from example-iframe.com will have example-iframe.com in its referer
The fact that an iframe without a "src" attribute doesn't have any website context is understandable, especially from a programmer side of view. The issue here is that I'd expect a src-less iframe to be a sort of 'local' frame (as it doesn't load external content). Any request coming from it would have the initial website creating the src-less iframe as the 'parent' and thus the referer.
I'm currently awaiting a reply from the developers, the same bug is also present in Firefox and Internet Explorer. I feel a small rewrite on this special case is in order; it currently works as intended but not as expected.
