Typo3 hack 2012

Here what they said about the claim:. From our point of view this news coverage is not only incomplete — and therefore confusing to users — but also factually incorrect: According to our own analysis by the TYPO3 Security Team, none of the websites named by heise Security use the the current TYPO3 Version 4.

In addition, several of the named websites do not use TYPO3 at all. Because we clean up hacked TYPO3 websites we need to know what potential threats are out there, so that we can identify the source of hack in instances when we lack all of the evidence of how the hack occurred, we decided to do our own check into this to see if what TYPO3 was saying is accurate.

To do this we looked what software the websites in the Google search result that heise Security reported showed the hacked websites were running.

We then checked the rest of the websites listed on the first three pages of search results and found more that were not running TYPO3 4.

TYPO3 4. The fact that TYPO3 4. By checking for the existence of a directory that was added in TYPO3 4. Where heise Security reporting really fails, and too often other similar reporting does as well, is there is not even a mention of any attempt to determine how the websites were hacked.

Determining how a website is hacked, to the extent possible, is a critical component of cleaning up a hacked website. If this hack was due to a vulnerability in TYPO3 it would show up in the logs of HTTP activity, so reviewing that would be one of the first steps in determining how a website with this hack was hacked. You can see an example of how that is done in a previous post where we looked at a website that had been hacked by exploiting a vulnerability in outdated versions of Joomla.

This idea seems to be good in general, but when you administer just more than one TYPO3 installation, the installation and configuration process of the extension can be very time consuming.

I finally ended up with the solution, that once again ModSecurity seems to be the best way to handle this kind of attacks to TYPO3. During research I found an article about brute force protection using ModSecurity.

Sadly the rules did'nt fit out of the box into my setup, so I had to create my own ruleset. Please note, that the ruleset only was tested with ModSecurity 2. I don't check for the occourence of the string " Your login attempt did not succeed ", since some TYPO3 installations may have a e. I've decided not to log each failed login attempt, since it fills up the ModSecurity audit log with the complete response from the TYPO3 backend login.

If the counter is greater than 5, the counter is unset and a new variable IP. Depending on this counter, the IP address gets blocked with a error. If you have blocked your own IP address during to too many failed login attempts, you have to unset the counter variable by modifying your ruleset.