With the state of web security being in such bad shape there is a need for good reporting on security issues. Unfortunately what we have seen is that the news organizations that exist are not doing a good job.
One indication of the poor job they are doing is that they are failing to take basic security measures on their own websites. In a previous post we looked at three major tech news websites that were running really out of date versions of Drupal, including one that is now over five years out of date. As of today they are still running the same out of date versions as they were then. In another cases we look at a news website specifically focused on security that was and still is running on an outdated and unsupported version of Plesk.
Another area of concern is that these news organizations have a habit of running stories based on information that rather simple research would show is false and on conjecture. In many cases this is due to reporters just repeating claims of security companies, which are often highly faulty. In a post from a couple of years ago we looked a couple of cases of this involving false claims about hacks of a version of WordPress. Today we have another example of this involving TYPO3. Recent reporting by heise Security claimed that there was a hack that only affects TYPO3 4.5 based websites due to an unknown vulnerability (German). We first spotted mention of this from claim from post on the TYPO3 blog calling in to question the reporting. 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.5.32, for which there are no known security holes. 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. The first website in the search results was running Infopark CMS Fiona, so right there the claim that the hack only effects website is TYPO3 4.5 appears to be false. 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.5.
Here is what we found the website to be running:
Infopark CMS Fiona 1
IP.Board 1
Joomla 1
phpBB 1
TYPO3 4.1 1
TYPO3 4.2 2
TYPO3 4.4 3
TYPO3 4.5 16
TYPO3 4.6 1
Unidentified TYPO3 Version 1
Unknown 2
TYPO3 4.5 does make up the majority, 53%, of the websites in our sample, but that is far different from the hack only affecting websites running that specific software. The fact that 80% of the websites running TYPO3 might indicate that the issue is related to TYPO3 in some way or it might just be a coincidence. The fact that TYPO3 4.5 made up 67% of the TYPO3 websites doesn’t seem to important as data from W3Techs.com indicates 90.6% of TYPO3 based websites are using some 4.x version and that 4.5 makes up 54.9% of the websites running 4.x.
Normally the pages of a TYPO3 based website will include a meta generator tag like this:
<meta name=”generator” content=”TYPO3 4.1 CMS” />
that lists the version of TYPO3, so heise Security should have been able to see that the websites were not all running TYPO 4.5 as they claimed.
By checking for the existence of a directory that was added in TYPO3 4.5.32 it does appear that some of the website TYPO3 4.5 based websites were are probably running 4.5.32, so the claim to the contrary in the TYPO3 blog post appears to be false.
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. What we see on a regular basis is that companies are hired to clean up a hacked website, they don’t determine how it was hacked so that the vulnerability is fixed, and then the website gets hacked again. While we are sure that creating stories about the fact that a bunch of websites were hacked draws readers, it doesn’t do anything to prevent websites from being hacked in the future. It also can be misleading as this article emphasizes a TYPO3 connection despite a lack of evidence that this hack was due to something in TYPO3.
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.