About a week ago we got an interesting Zencart case. Being that we don’t often write about Zencart we figured it’d be good time to share the case and details on what we found.
The Scenario
The site was redirecting to “www .promgirl .de” – I know, not very unique.
Additionally, it was only affecting “www” instances. All “non-www” instances were working correctly with no redirects. We also noticed that it would only trigger with specific user Agents and Referrers. This shouldn’t be new as we’ve talked at length about conditional malware.
The Analysis
Initially we thought that only a specific user agent could trigger it and only on “www” version of the site. Then our theory was blown out of the water when another researcher was able to get it to trigger on “non-www” versions too. I would be lying if I said this was all relevant, but at least you get an idea of our thought process.
Here is a step-by-step to better understand our processes:
- Initiate our cleanup processes – nothing was detected.
- Initiate databases cleanup processes – nothing was detected.
- Manual inspections of key files and locations – nothing was detected.
At this point, we have to start thinking outside of the box; think like the end-user, attacker or administrator:
- Leverage search engines to get more information on the target site – this proved unfruitful, save a few redirections to it, but nothing else – no solution or insight.
- Dive a little deeper and start analyzing the requests and packets – finally a ray of light!
I noticed this line:Set-Cookie: USERID=shine-check; path=/
It looked very suspicious: shine-check? How is it that after I make my first anonymous request it assigns you such a strange user ID?
A little research rendered some useful information on this USERID=shine-check. We started to notice that there were various forums talking about this specific issue. The one common denominator in the equation was Zencart. While this doesn’t address the issue, it definitely gets us intrigued and as a researcher it starts to paint a better picture.
Digging a little deeper and leveraging the insights from the various posts we were able to decipher the following:
Yes, it’s a Zencart infection and has been around for a while, shame on us. It turns out that it doesn’t leverage the database or .htaccess files, instead can be inserted across in any one PHP file. The two important indicators (signatures) for this infection can be found in the shine-check and twotime cookies in the HTTP header information.
One very specific post shared the exact payload, and it’s dated back to the summer of 2012. They payload was outlined here: http://pastebin.com/jFY5LF1h. While it gave us a tremendous amount of insight into what we were working with, it was apparent something had changed as none of the existing patterns it outlined were returning anything.
- Even with that information in hand, it wasn’t enough to tell us where it was, just that it was legitimate and would require some digging. We set about additional reviews.
Apparently, something has changed in the malware since summer of 2012. But what?
- After several hours I began to get a little frantic and that led me to line by line reviews, never a pleasant experience. Sparing you all the details, I finally got it. By it, I mean a very benign piece of code that would never set off any alarms, it was just setting some variables. Interestingly enough, disabling it made the cookies disappear. That’s strange, right? I just had to know, so I went about setting some of my own variables that would echo out the results.
Like magic, my new variables spit out warnings filled with clues. The function couldn’t write the output because the headers were already sent, and in those warnings was the prize! Two files were disclosed in the warning message, one benign and the other contained the infection. Bingo.
The payload was here:
includes/modules/extra_functions.php
It contained:
Using our free online Decoder we extracted the following:
Removing the payload did the trick! Buh-bye redirects. 🙂
That’s it.
A Little Icing On the Cake
I do want to mention something about the redirect code as it was unusual, at least to me.
On the first visit, it checks if user is not Chinese (no zh in browser languages) and not coming from websites in Hong Kong. At the same time, the user should also be coming from Bing, Google, Facebook or Yahoo.
For such “eligible” visitors they set the USERID=shine-check cookie and redirect them to “hxxp://www .promgirl .de/” For “non-eligible” users they only set the USERID=twotime cookie. After that every returning user who has the USERID=shine-check cookie gets redirected without further checks, and users with the USERID=twotime cookie never get redirected.
There is one more interesting “eligibility” condition and it’s based on chance. The code creates an array with 40 items that contain the hxxp://www .promgirl .de/ URL and 60 items that contain the mailto:hackseo@post.com email. For eligible visitors they randomly choose one of the items, and if the item is the URL then that visitor gets the shine-check cookie and gets redirected, and if the item is the email, then the visitor gets the twotime cookie and never gets redirected.
As you can see, user agent and “www” don’t affect the conditions for the redirects. What really affects them is the referrer: non-Chinese origin plus some luck (or lack of it). So much for the scenario we first had in mind.
Good luck!
If you find yourself with a similar issue and need help, please let us know. Via our services we’ll do everything necessary to ensure that infections like this are addressed in a timely manner. We find great joy in little scavenger hunts!
Matt Morrow
John Castro
Cesar Anjos
Krasimir Konov
Moe O
Justin Channell
Ben Martin
Allison Bondi
4 comments
It can’t be stressed enough how important it is to keep an eye on HTTP headers. I learned this very quickly after reading The Tangled Web, by Michal Zalewski. Good digging again, Denis. Interesting to note that noscript wouldn’t save you from this since it’s based in the php and headers. Another reason to be vigilant in the tools you use — unconventional/unpredictable browsers and unconventional search engines (e.g., using DuckDuckGo probably wouldn’t have triggered this apparently).
I’m guessing that files were infected because of insufficient file permissions or something similar? Something like Tripwire should have picked up that change to includes/modules/extra_functions.php when it happened, I would think.
Yep, NoScript wouldn’t prevent the redirect but it would save you when you are already redirected to that third-party site. In this case, the goal of the redirect seems to be promotion of that site (not typical malware), but in other cases that third-party site could be malicious and you would definitely want to have NoScript working when you unexpectedly end up on such a site.
Unconventional search engines and browsers can also help. Malicious code regularly check such things. If you are on Windows, you might even want to change your browser User Agent to something like “Chrome on Linux” – this will save you from quite a few attacks. I also saw a browser extension that deliberately removed Google from the “Referrer” header to prevent attacks that only work for visitors from Google and other major search engines.
While this may decrease the attack surface, it can’t completely protect you. And be aware that changing the User-Agent and the Referrer header may result in a worse browsing experience as sites will serve you pages optimized for a different browser that may be not fully compatible with yours.
Update: New variation of this malware
http://pastebin.com/wGZK3Bek
http://pastebin.com/AVcXCRmu
Was found in includes/modules/extra_definitions.php
we go almost the same code but in wordpress: it was a
require( dirname( __FILE__ ) . ‘/wp-includes/wp-blog-header.php’ );
inside wordpress index.php
code was almost the same.
Comments are closed.