The statistics for my WordPress photo blog show over 51,000 visits. The blog presents part of my unconventional journey through a collection of pictures of my work during two years of sabbatical. It includes images relating to the Printemps Érable in 2012, the election of Pauline Marois as the first female Prime Minister of Quebec, the work of several French Canadian artists, etc. It captures my transition from an amateur photographer to working as a professional photographer for the prestigious La Presse, the largest French-language newspaper in North America.
Recently, I discovered that anyone visiting my blog was redirected, unavoidably, to a wheel of fortune web site. To avoid any consequences related to a potential security flaw, I temporarily withdrew my blog from the Internet.
The first step in correcting the problem was to put my blog in maintenance mode, so that it was not available publicly. Then I changed my password and also checked to see if the WordPress dashboard showed that new accounts had been created without my knowledge. Luckily, there were no new accounts so I could begin investigating what had happened. I asked myself three questions:
- How did my blog become infected?
- How can I do to fix it?
- What can I do to prevent this problem happening again?
How did my blog become infected?
One of the best practices followed in the cybersecurity industry is to keep applications current by applying patches. I logged onto my WordPress dashboard to see how serious my failure to check for updates had been. The truth was embarrassing: my blog had been outdated for over a year.
WordPress consists of the core of the platform, plugins, and themes. The core of WordPress is managed by the CMS platform team while the plugins and themes are managed by the community – which can be anyone, and security may be the last thing he or she is thinking about.
An attacker needs only one flaw to make his first advances; the owner of the application must block all doors, all windows, and any cracks in the floor.
How can I do to fix it?
In an attempt to locate the problem quickly, I got the results of three online scans:
I must admit that I was pleased to see the elegant red of the Quttera scan, which indicated that a malicious file had been detected. However, the malicious domain was listed as “fpjq.org” and ‘fpjq’ stands for « Fédération Professionnelle des Journalistes du Québec ». In 2012, I won the award for up-and-coming press photographer of the year presented by FPJQ for the best journalism and press photography in Quebec… So isn’t actually a malicious file; it’s the reason for my work at La Presse.
The last time I updated my blog was in 2016. Several vulnerabilities in WordPress had been reported since then so the question was which one had been used to infect my blog. I began searching for leads to help target where I should look in the code to fix it. (When I say “look,” I’m using the word in the looking for a needle in the haystack sense.)
The security vulnerabilities for WordPress in 2016 – those that have a CVE name starting with “CVE-2016-“ – are documented here.
The following chart shows the number of CVEs by vulnerability type for WordPress in 2016.
Number of CVEs by vulnerability type for WordPress, 2016
There were a total of 21 CVEs in 2016. XSS were the most popular, followed by bypasses. The severity level based on the CVSS score is between 3.5 (low) to 6.8 (critical). The affected versions are before 4.4.1; 4.4.2; 4.5; 4.5.2; 4.5.3; 4.6; 4.6.1. These CVEs are vulnerabilities in the core WordPress program, not in the plugins.
Where was the vulnerability? There were multiple possibilities. My WordPress core program was now up to date, but the problem was still occurring. I use several plugins in my blog. It was therefore likely that the vulnerability was in a plugin and not in the WordPress core. I looked for an effective way to narrow the scope of my research rather than having to look at all the possibilities one by one.
First, I made a backup of the source code as well as a copy of the database and conducted my analysis on these copies in order to keep any infection contained. I then asked Google: « WordPress hacked redirect ». The first two results came from Sucuri, who are well known for their expertise in dealing with security involving WordPress; see articles [1] and [2]. The publication dates of these articles correspond with my situation, since they are from 2016 and 2017 respectively. Article 1 discusses a malware that is injected into header.php or footer.php files. I opened these files and everything seemed legit. Article 2 proposes other avenues. I continued to delve into the ocean of possibilities.
I then went into a dynamic mode to analyze the sequence of requests. The Portswigger Burp tool allowed me to see the operation that was redirecting users after every click on my blog. Burp provides a proxy, which operates as a man-in-the-middle between the browser and the application and makes it possible for testers to intercept all the requests and responses. I analyzed numerous details that seemed suspicious and finally found the problem.
In the image below, the green rectangle shows an extract of queries from my blog. The purple rectangle shows the response to the selected query #103. The GET request to blog.annegauthier.ca is my starting point and the request to inclr.com is the redirection. What called inclk.com from my site?
Query #105 calls sweetCAPTCHA just before the redirection point with the following URL:
sweetCAPTCHA is a plugin that I use on my blog at the authentication page to avoid brute force attacks.
When a request is launched from my blog, the server « Cowboy » answers me as follows:
sweetCAPTCHA is called at parameter 18068. In response, TID = SWTMPOP triggers an alert because it is part of the redirect point of my blog:
According to my initial understanding, sweetCAPTCHA was present only on my authentication page. To my surprise, the plugin was actually present on all pages of my blog, as shown in the following example:
The problem came from sweetCAPTCHA version 3.1.0. I immediately removed the plugin from my blog. Result: no more redirection.
I then queried Google again, using the keywords « WordPress hacked sweetcaptcha. » Another surprise: the articles date from 2015.
Sucuri is still at the top of the results with the article « SweetCAPTCHA Plugin Used to Distribute Adware » published on June 9, 2015, followed by « SweetCAPTCHA Returns, Hijacking New Plugin » on July 23, 2015. The introduction says:
“In June we reported that SweetCAPTCHA injected third-party ad code to their scripts, which led to malvertising problems on the sites that used this CAPTCHA service. After that incident, the sweetCAPTCHA WordPress plugin had been removed from the official plugin repository.”
According to the research conducted by Sucuri, the result is not an infection, but was included by design and the designers of sweetCAPTCHA had written it into the Terms of Use: « There may be included 3rd party content which will be displayed for the purpose of user interaction. This content might include but not limited to ads, banners, links, search engine input fields and etc. »
It is our duty to read the Terms of Use, before clicking on « Yes, I accept the terms ». But I know, I know: no one reads the Terms of Use.
Finally, I saw a further source of the problem: the sweetCAPTCHA plugin was no longer supported, so I had not received notification that updates were available. I had been using this problematic plugin since 2015 …
What can I do to prevent this problem happening again?
Always keep an eye on my WordPress sites. They are like human beings and need care. The amount of time they’ve been in use is important and the core program as well as its plugins and the theme should be checked regularly to keep them up to date. Even if the site dashboard does not display a notification that a plugin or theme needs to be updated, it is important to ensure that they are not vulnerable to malicious attacks or to unintended behavior.
Conclusion
This analysis did not reveal a new vulnerability; on the contrary, the problem had been recognized in 2015. Starting from a personal experience, I have presented a concrete example of use of a site that had an attack surface so wide that it was difficult to find the flaw in order to fix it. However, the lessons learned here can be applied to prevention in all business contexts.
Keep WordPress up to date and check whether plugins need to be updated,
even those without notifications.
For the curious, my WordPress photo blog can be found here: http://blog.annegauthier.ca/
OWASP WordPress Security Implementation Guideline
https://www.owasp.org/index.php/OWASP_Wordpress_Security_Implementation_Guideline
