Doing some further research on the topic mentioned in my previous post I have found another way by why the attacker can mess up your website.
This has been pointed out on some websites already, however, I would like to go into detail and not just leave you uninformed about what the code I would be showing actually does.
The story behind the finding
On some recent analysis on an attack on the web presence of a company I reached a point in which an issue only occurred sporadically. Furthermore, I was not able to reproduce the offensive behavior in all of the browsers that are available. Only versions of Firefox-Browsers seemed to be effected by the malicious code.
The symptoms of the attack were that a javascript was injected into the website, again the trick of using a hidden IFrame were used, which on a first look did not make it easier to isolate the two different cases of attacks having happened.
A first code review did not show any specific presence of code that would explain the IFrame being placed in the source code.
In such a case I tend to compare the data being sent from the server to the browser on transport level, so in case of loading a website I look at a record of the TCP-Traffic between the server and my computer. My favorite tool for doing so is Wireshark.
To avoid an overload of data being transported I tend to call the sub-page on which I think the issue does occur directly. In this case there are still various options of the code being injected, but imagine you had to reload a webpage with a lot of content each time and then potentially go through the packets manually to find the specific item that you are looking for… quite a lot of work that could be done more efficiently.
In the specific case that I worked on the positive effect was, that the page containing the “payload” did not return any data other than the payload itself if being called directly rather than in case of being called through the content management system.
The following picture shows you the traffic that occurred when the page was called in the browser, please note that Firefox was used as my other browsers were invulnerable to the attack.
This might look all strange to you, a bunch of numbers with a few assignments to variables and javascript function calls, so what you need to know is that each of the numbers stands for an ASCII Character, but not directly. The attacker has attempted to crypt the code by modifying the numbers slightly, however, they were nice enough to leave the algorithm in there. By this I know how to convert the wrong numbers into good numbers and then turn the numbers into code… we will do this step by step.
1. Find the algorithm
The script iterates through the variable a, which is of the type array and contains all the numbers, each number is one item of the array. In the iteration some math is done, basically it converts the wrong number into a number that can be decoded to something that makes sense. This is the corresponding code:

Code used to convert numbers
Using exactly the same code I create a simple HTML page into which I then insert code to actually spit out the numbers. For reason of security I do NOT decode the numbers to proper code directly as this might be risky due to the fact that it is unknown what the code will do if executed on accident. The modified for-iteration through the array looks like this:

Modified for-iteration displays the correct numbers in the HTML
No worries, I will not bother you with all the numbers it did spit out…
2. Decode the functionality
Next step was check what the output looks like in code. For this step I used a Linux based VM and visited this website where I just entered all the numbers via copy&paste, the outlook looked this way:

Code retrieved from converting numbers based on malicious code algorithm and converting from Charcode into readable text.
Fine, this was the code I was looking for, by now I know that the code that I found does actually cause the issues observed by users of the website. However, this does not tell anything on HOW the code got there.
Isolating suspicious items…
Gladly I was able to isolate one specific file on the web-server to be responsible for the behavior, this also means that I would concentrate entirely on the functionality of that specific file.
A quick code review of the CSS files and other files accessed by the PHP-File in question was performed, non of the external files appeared to be trouble The file itself had 2 features that were catching my attention, one was a <div> that only had the class “clear” and contained now data, this <div> was at the location the code appeared at in the page. Another item was a “Bot Analysis” code, this code contained crypted items, curl requests and a few typos which did not make it very trustworthy.
Editing the files directly on the server, I commented out both suspicious items. Checking the page by refreshing it in the browser resulted in the malicious item not being loaded any more. Removing the comment to recreate the “clear”-div did not bring back the issue, however restoring the analytic code did create the same behavior as seen before. Malicious code was injected to the website.
The picture below shows you the code that is used for the attack, it is pretty wide-spread on vulnerable WordPress installs, so you might want to check if it is causing the trouble in your case.

Code used to inject the javascript which places the iframe on the target website.
As you noticed already, this code is using curl. Basically it is sending a request to a website, to obfuscate the activity the website URL is base64-encoded, however we can decode this quick and find out that the target of the request is:
http://mbrowserstats.com/statH/stat.php
If you use this link, you will be getting an error message by your browser. Basically you did not add the parameters it is trying to look for.. Feel free to look up the domain registrar information yourself, you will find out that the site is located in Russia.
Through the line:
echo $sResult; // Statistic code end
The malicious code is injected into your website.
Taking this code apart will be something to do for a new blog post. Plan is to run a server in a virtual machine and record the data that occurs when the curl request is executed. The reason why this does not work for all browsers strongly relates to the Agent checking in the code itself.
If you should see code like that on your website, do not hesitate to take a backup of the file and delete it from the version on your server. If this works then you can safely run without the code executing things that you do not know of. It also is a crucial item on keeping the data of your website visitors safe.
Pingback: JavaScript Obfuscation | Felix's Tech Blog