4

I am the webmaster of some websites running Typo3, 2 of which are getting infected constantly. These 2 sites are being owned by the same client.

Something happens on those 2 sites that causes literally all *.php files to be infected by some code. It gets inserted at the bottom. Luckily the infection doesn't do much because I have php short-tags disabled and the infection depends on it (it uses short tags to execute it's code).

Now my question is: How is it possible that those sites are getting infected the whole time? I have made sure the client's computer is clean (he eventually did a full format 'n reinstall) and my own computer is clean too (absolutely).

What steps can I take to see how the script acted, how it came in, etc. Keep in mind: I am not the hoster. The 2 sites are on 2 different hosters. The script infects all *.php files, then leaves no further traces (no executables, no scripts, nothing out of the ordinary. The only thing I noticed is that a ._htaccess file (not the .htaccess file) contains code to redirect the user based on referrer. This also won't work since the ._htaccess file never get's executed and is a demo .htaccess file for typo3).

Greetings John

Improve this question
2
  • 5
    One thing to check is that these sites don't have 3rd party extensions with known vulnerabilities installed. A quick Google on "typo3 vulnerability" returns among the results this page: typo3.org/teams/security/security-bulletins/typo3-sa-2010-012 which at first glance appears to be fairly appalling.
    – Xander
    Mar 4, 2013 at 19:29
  • Thank you for that link, I haven't seen that page before. Two of my extensions are on that page. Unfortunately (or should I say fortunately) both extensions were already on the version where the exploit is claimed to be fixed. I always keep my Typo3 and Typo3 extensions up-to-date as much as possible (I have automated warnings for updates).
    – John Smith
    Mar 4, 2013 at 21:21

4 Answers 4

Reset to default
5

You need to perform an incident response, you can hire a firm like Trustwave, but my guess if you don't have the funds for such a large investment.

Since you are using a popular open CMS system, its going to be a target of attack. It is also built upon other open source components, so those may be affected. Of course, there are a number of other vulnerabilities that are possible given any number of third party, built-in, or home brew components. You can find a list of recent exploits and bugs at the NIST CVE database listing of Typo3 Vulns.

There are a few things that could be resulting in a massive infection that seems indiscriminate. If the permissions of the files and directories are not set correctly, or if the file and directory ownership is misconfigured this could be the first problem. There may also be some script or piece of software which is vulnerable and has the ability to execute arbitrary code, and thus can write and append any files it finds. If it has the ability to arbitrarily execute shell commands, then its easy to search for all php file and inject the code with a few lines of code.

Another possibility might be a flaw in another tool you are using, maybe a web-based management console for hosting or a helper application like phpMyAdmin or some other random code is vulnerable.

At any rate, the first place to start your investigation is by reviewing the activity logs. I'd start with your ssh access logs to determine if anyone logged in directly when you do not think you did. Next, you should look at your server access logs. If there is a flaw in some web application, they probably had to issue a command against your page. They may have googled for a certain common HTML source string in google and the target all sites they found broadly. Is so, they are probably re-running their attack every so often to reinfect you if you didn't find the hole. Look for log entries that seem to have SQL injection or XSS. This could be labor intensive process, but if you think you know the timeframe of when you got hit, that should help limit your search.

Another check is that you have removed any installation or other files they recommend you remove that could allow an attacker to reset defaults, etc. Also, be sure you are using strong, unique passwords. After an attack, I would always recommend changing your passwords as a precaution.

Lastly, there are often clues in the exploit code itself. Did they infect it to redirect to a certain site, do they have "greetz", or anything else that you may be able to google and find someone else talking about on a forum? Unless the attack is against your custom code, its likely someone else got hit in a similar way as well.

Improve this answer
4
  • 1
    Off the top of my head, I would recommend checking your editors, like TinyMCE if its installed. Those are becoming a popular target since they are often used on various different CMS systems.
    – Eric G
    Mar 5, 2013 at 1:07
  • Thanks, I checked the logs. It seems like a request to a non-existing image was made (it was a random name gif). I think some local file inclosure exploit was used. I believe it was caused by my client's computer being infected by a virus that added this file inclosure exploit to the page editor right before it was submitted.
    – John Smith
    Mar 5, 2013 at 10:58
  • That's possible too, unique vector that the user's PC was infected and was then running the exploit on pages he/she visited. Did you determine this from the logs and tracing to the user's IP?
    – Eric G
    Mar 5, 2013 at 15:49
  • Well, I can not confirm this for the full 100% but in the access_logs I saw an image getting loaded which existed (but when I checked it didn't, so it probably got removed after the virus was done) and the client found the virus "Blacole" on his PC which is known of doing this exact thing.
    – John Smith
    Mar 6, 2013 at 13:18
5

I am the webmaster of some websites running Typo3, 2 of which are getting infected constantly. These 2 sites are being owned by the same client.

I am not the hoster. The 2 sites are on 2 different hosters.

And that's the answer right there, I think. What do those two sites have in common that your other Typo3 sites haven't? The client.

You are probably looking at an automatic attack that uses compromised FTP passwords, and probably a variant (it developed several payloads) of the PHP.Kriptik infection. You can verify this by checking the FTP logs.

It could also be that those sites have specific extensions unique to them (I find it unlikely that both hosters are vulnerable). There are some recently discovered Typo3 extension vulnerabilities, even if the ones I checked don't seem capable of arbitrary code execution or file overwriting (maybe Fluid Extbase Development Framework's, but I have been unable to find details). If that's so, maybe you can investigate whether there's a pattern to the file modifications (e.g. first those in one specific extension's directory, or something like that).

Improve this answer
6
  • That wouldn't do any good. I didn't give him an FTP account. He only has an account on the CMS which password is RSA encrypted. I do agree on the theory that it's an automated attack though!
    – John Smith
    Mar 6, 2013 at 13:16
  • 1
    Hm. And probably you can't modify the very content of a PHP file from an account, however powerful. Adding another possibility...
    – LSerni
    Mar 6, 2013 at 19:35
  • Well, I still think what happened was what I commented on the correct answer's post. Let's stick with that for now. If it comes back, then I know it was caused by something else. The client formatted his PC anyway, so the virus is a gonner there. I also advised him about a virus-scanner.
    – John Smith
    Mar 6, 2013 at 20:18
  • Sorry, I had not seen the comment at the time. However, this only "moves" the problem - the virus on the PC, to be able to infect the server, still needs an exploit and the server to be vulnerable...
    – LSerni
    Mar 7, 2013 at 23:26
  • Is that true? Can't the virus which is running on the client just be scanning the HTTP posts being made and when it detects known objects with names like "content" or "whatever" being posted intercept the post, insert custom content and then it get's executed once someone visits the page? (I haven't found any modified content in the database though which is where the posted data goes...).
    – John Smith
    Mar 8, 2013 at 20:52
2

A system can have every OS and software update yet still be highly vulnerable if the software was written using bad coding practice. PHP and many other languages have little security built in, it's up to the developer to make sure that code is written well. So it is most likely a lack of input validation or some other bad coding practice that has led to the infections.

Improve this answer
6
  • 2
    Also, check every workstation used to access the site for keyloggers and other malware. Once they're shown to be infection free, change ALL login credentials. DO NOT use telnet or ftp for access, their credential exchange is plaintext. Then start thinking about whether your hosting provider is actually secure. Shared hosting = shared filesystem = shared vulnerabilities. Once these bases are covered, go to Typo3 and update to the latest software, then check their forums for known security bypasses.
    – Fiasco Labs
    Mar 4, 2013 at 18:10
  • Thanks for this, however I would like to state: * The 2 sites are on 2 different hosters, but have shown the exact same symptoms indicating it was the same "virus", so I don't think it's with the hosting provider (webhostinghub). * I do not have shell access to the site, but I will keep FTP in mind. I never share FTP details with my clients anyway. I am using approved extensions for Typo3 and some I made my own. Neither are vulnerable since they don't get user input or anything else the user could exploit remotely. Thanks for your input though!
    – John Smith
    Mar 4, 2013 at 21:08
  • So the items shared in common between the two websites are the workstations used to manage them and the software platform they run on.
    – Fiasco Labs
    Mar 4, 2013 at 22:36
  • 1
    That sounds about right. Personally, I believe that before the client reinstalled his PC he was infected with a virus that would simply add something as soon as it detected a POST being made (so adding stuff to the editor) which was then executed when visiting the page and infected all other pages.
    – John Smith
    Mar 5, 2013 at 10:56
  • Great point John reminds me of nist guidelines on incident handling its never to bring the system back online unless the root cause of problem has been identified.
    – Saladin
    Mar 5, 2013 at 18:00
0

I cannot tell you exactly what causing it ; but I can certainly tell you how to block it? Use some kind of application layer proxy ; or better an application layer firewall to parse the packets going to the infected web servers. There has to be some input that goes on fly in post / get commands you need to see that. Otherwise its just a normal *.php crawler scan. Or you can either upgrade the php-version use an open web-application scanner and see if it brings any vulnerability. I don't think he (attacker) has a backdoor as then he won't be relying on this method of infection. Its probably some kind of unprotected part of web-server / listing / directories or bad input where he is getting through. You can use a crawler to see what interesting links it finds.

Improve this answer
5
  • 1
    That may suffice as a layer of protection, but I wouldn't rely on it. We pay through the nose for a high-end Web Application Firewall, and we are increasingly seeing attacks getting past it and (thankfully) getting caught and blocked by our code. No single tool is enough, and there is no substitute for a securely written website. A properly written website (defending against known attacks, following OWASP guidelines at a minimum) is only one layer of defense, but it's a critical one. The same must be said about an Application Firewall.
    – David Stratton
    Mar 4, 2013 at 19:36
  • Its the use that matter i see organization using multiple controls for no one specific purpose;WAF / proxies are good in opening the visibility part. What you cannot see ; you cannot protect; and defend. Otherwise a good secure website which follows OWASP sounds perfect but for me its just getting down the basics like the SLDC part and threat modelling part most organization ignores while developing these apps.
    – Saladin
    Mar 4, 2013 at 19:39
  • 1
    Ahhh.. Good point. You're thinking of forensics and finding the culprit. I wasn't thinking that route... I was just thinking of defenses to have in place. Good thinking!
    – David Stratton
    Mar 4, 2013 at 19:41
  • As said by the man himself (bruce schiner) You can’t defend. You can't prevent. The only thing you can do is detect and respond
    – Saladin
    Mar 4, 2013 at 19:45
  • 1
    Thanks, but I am not "completely" looking how to block it. I know how to "fix" it, but I want to know how it happened. Once I know how this happened I also know how to stop it from happening again, you see?
    – John Smith
    Mar 4, 2013 at 21:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .