Summary
Over the past few months, I’ve been monitoring the proliferation of exploits for some of my disclosed WordPress Plugin and Joomla Extension vulnerabilities against Akamai customers. I started this observation process which leads to an expected conclusion – severe vulnerabilities like SQL Injection, RFI and LFI would receive the most attention for any CMS platform. While less severe vulnerabilities such as XSS and path disclosure would likely receive less attention from the attackers.
The initial idea was to track three of my own disclosures after they had been published and see how much time elapsed until they were weaponized and attempts were made to exploit them in the wild. In total, I had released three previously unknown SQL injection vulnerabilities in three well known Joomla extensions. These aforementioned vulnerabilities had been remedied by the original authors prior to research being published, These disclosures appeared to go unnoticed by the black hat community.
This paper examines the time elapsed between a when a vulnerability is publicly disclosed until we begin to observe widespread exploitation attempts by adversaries.
What Happened
The three disclosed vulnerabilities were released last September listed in the following table. Each advisory details a SQL Injection vulnerability that does not require the attacker to have a login on the target’s website:
| Date | Description | CVE ID |
|---|---|---|
| 2016-09-16 | Huge-IT Portfolio Gallery Plugin v1.0.6 | CVE-2016-1000124 |
| 2016-09-15 | Huge-IT Video Gallery v1.0.9 | CVE-2016-1000123 |
| 2016-09-16 | Huge-IT Catalog v1.0.7 for Joomla | CVE-2016-1000125 |
After nearly a year, I decided to investigate what might be causing my disclosures to be ignored. I looked at other SQL injection vulnerabilities in Joomla extensions that were turning up in Akamai’s attack logs and found an obvious difference. While my advisories had permeated the usual exploit curator websites, like packetstormsecurity.org, they had not made it over to http://exploit-db.com, http://cxsecurity.org and http://0day.today. Two days after submitting all three exploits to exploit-db.com I found a hit in Akamai’s logs. The attack attempt originated from IP address belonging to a telecommunications company in North Africa. They were targeting a .mil website with the SQL injection in Huge IT portfolio v1.0.9 using SQLmap.
IP: 105.158.11.8
Path: ajax_url.php
Query: QmX=6156 AND 1=1 UNION ALL SELECT 1,NULL,'alert("XSS")',table_name FROM information_schema.tables WHERE 2>1--/**/; EXEC xp_cmdshell('cat ../../../etc/passwd')
User-Agent: sqlmap/1.0.9.6#dev (http://sqlmap.org)
A second attack occurred five days later. This time the attacker targeted a Russian e-commerce site, by attempting to redirect the malicious requests through a popular online auction house. The requests appear to be looking for other injection points, since each request placed a single quote, ‘ at a different query parameter.
IP: 104.154.86.249 Query: option=com_catalog&_sacat=&_ex_kw='A=0&_mPrRngCbx=1&_udlo=&_udhi=&_sop=12&_fpos=&_fspt=1&_sadis=&LH_CAds=&task=viewitem&secid=13&id=34&Itemid=10&rmvSB=true IP: 104.154.86.249 Query: option=com_catalog&_sacat='A=0&_ex_kw=&_mPrRngCbx=1&_udlo=&_udhi=&_sop=12&_fpos=&_fspt=1&_sadis=&LH_CAds=&task=viewitem&secid=13&id=34&Itemid=10&rmvSB=true
It seemed that the malicious actors would use exploit-db and CXsecurity websites specifically as their RSS feed of vetted working exploits. Conversely, while advisories published on packetstorm were quite relevant to the information security industry as a whole, they were not formatted into easily consumable exploits as curated by websites like exploit-db and their ilk. Not to leave the most popular CMS out of the fun I also publically disclosed a path traversal vulnerability in a WordPress plugin named Membership Simplified [CVE-2017-1002008]. I released the details on March 14th 2017 and began seeing entries in our logs on Saturday, March 18, 2017 at 9:00:00 PM just four days later. This response time was in stark contrast to my Joomla extension publications.
Why are newly disclosed WordPress plugin vulnerabilities so aggressively pursued? One possible theory is that there are multiple open source tools and frameworks available to scan for plugin vulnerabilities on WordPress websites. These freely available tools are lacking for the Joomla platform.
It is not just the severity of the vulnerability but the proliferation of the software platform that increases its target footprint. WordPress has an enormous market share of the content management software in production on the internet. There are entire frameworks, websites and even companies focused on WordPress core and plugin security.
What about a truly severe vulnerability? Something that doesn’t require authentication and allows the attacker to change content, possibly even execute code?
Earlier this year a researcher at Sucuri, Marc Montipas released a vulnerability affecting WordPress < 4 .7.2. The vulnerability abuses a type juggling bug where any non-integer input bypasses the authentication mechanism allowing a remote unauthenticated attacker to modify any blog post.
I started monitoring attack traffic, via Akamai log files, for this specific vulnerability immediately after it had been made public. The WordPress JSON API vulnerability was assigned CVE-ID CVE-2017-1001000. It first popped up in our attack logs on Wed, 01 Feb 2017 18:00:00 GMT or around 1PM EST just three hours after Sucuri made their blog post public on their site.
It only took three hours after the vulnerability went public to see exploit attempts against Akamai customers turning up in the logs. I’ve noticed the logs after a few months show only a few thousand attempts per day primarily targeting government and military websites. Also, most of the log entries were being generated by the customer themselves. In addition to this, large portions of these scans originate from security companies performing web application security assessments for said customers. The log entries that didn’t originate from a security company or the target’s own DMZ appeared to be POST requests rather than GET. This I assume to minimize noise and attempt to bypass WAF filters as there were many ways to deliver the JSON payload when exploiting this vulnerability.
Shortly after the disclosure by Marc and Securi an article was published stating that over 1.5 million websites had been compromised using this vulnerability. Why am I not seeing the same widespread exploitation attempts against Akamai customers? The answer was simple, the majority of Akamai customers aren’t running WordPress and the attackers were using google dorks to determine which sites were.
A google dork is an advanced search method used to increase Google’s search granularity. To get a quick idea on how many websites out there rely on WordPress I ran the following:
An example, searching google for urls that contain the string /wp-content:
inurl:/wp-content
Returns “About 280,000,000 results”.
In an attempt to further my examination of these attacks, I examined other exploits against Joomla, as it is the second most popular CMS employed by internet websites. I found that, again SQL injection and path traversal vulnerabilities were the most popular. the top of the Joomla examples are listed here, but I primarily focus on WordPress because of its deep penetration into the content management ecosystem.
I discovered with attacks focusing on Joomla extensions the majority of the traffic originated from Virtual Private Servers (VPS) and appeared to be legitimate attack attempts. The logs revealed the opposite for wordpress, the majority of attack attempts originated from the target’s DMZ and were self scans.
| Extension | Attempts |
|---|---|
| com_rpl | 465414 |
| com_content | 61078 |
| com_virtuemart | 17371 |
| com_gcalendar | 8718 |
| com_multicalendar | 8011 |
| com_ajax | 7867 |
| com_poll | 7166 |
| com_contenthistory | 6702 |
| com_remository | 6976 |
| com_pro_desk | 5768 |
| com_jgrid | 5443 |
| com_myblog | 5850 |
| com_hsconfig | 5372 |
| com_smartsite | 5356 |
| com_picsell | 5316 |
The com_rpl at the top of the above table is the result of an SQL injection via the pid parameter of a GET request in an extension called RealtyNA CRM (Client Relationship Management). This is designed to help Joomla based real estate websites manage inquiries on property for sale. The associated vulnerability was disclosed on December 15th 2016 and does not require the attacker to be authenticated to the site. It should be noted that the extension is no longer actively being maintained and has been pulled from Joomla’s code repository. The vendor RealtyNA has directed Joomla users towards its new WordPress plugin.
Most of the above Joomla extensions are vulnerable to SQL injection. When automated tools like SQLmap are used they iterate through various payload types in an attempt to build a working SQL injection exploit. This is why the numbers are much higher than the wordpress table below, SQLi attacks are much more noisier than XSS or RFI.
Besides software popularity, the type of exploit, for example, an “Unrestricted File Upload” vulnerability isn’t going to trigger a WAF alert unless a rule was specifically written for it. As an example, a file upload vulnerability can be more severe than an path traversal vulnerability but it is not likely to set off nearly as many alarms when it is being exploited as it’s harder to fingerprint being an error in the code logic itself. The exploit is a normal looking POST request void of any malicious content. Unless your file payload is something obvious like the notorious c99.php web shell.
With WordPress running on 28.7% of all websites and Joomla coming in at second place with 3.3% the availability of website security assessment applications also follows this trend. There are various utilities to assess the security of your WordPress and Joomla websites, a few are listed below that are popular.
| Application Name | CMS | Project Page |
|---|---|---|
| pyfiscan | multiple | https://github.com/fgeek/pyfiscan |
| WPScan | Wordpress | http://wpscan.org |
| sucuri-scanner | Wordpress | https://wordpress.org/plugins/sucuri-scanner/ |
| nmap | Wordpress | https://nmap.org/nsedoc/scripts/http-wordpress-enum.html |
| Joomla VS | Joomla | https://github.com/rastating/joomlavs |
| Acunetix | Joomla | https://www.acunetix.com/blog/case-studies/joomla/ |
The majority of utilities out there appear to run on the command line, while some are directly integrated into your CMS installation.
The logs which I collected retain attack data for 30 days, I examined recently released vulnerabilities and well-known vulnerabilities to study the most scanned for a 30 day period. I filtered out known penetration testing companies from the logs and removed logs where the connection originated from the targets own network. The Alerts field contains the number of actual payloads that were blocked by Akamai’s WAF, they do not contain benign probe requests from web application vulnerability scanners.
| Plugin | Alerts |
|---|---|
| akismet | 4588 |
| s3bubble-amazon-s3-html-5-video-with-adverts | 2227 |
| bwp-minify | 2050 |
| dni_minify | 1399 |
| wp-ecommerce-shop-styling | 161 |
| jetpack | 114 |
| ie-sitemode | 97 |
| google-mp3-audio-player | 93 |
| revslider | 80 |
| tinymce-thumbnail-gallery | 69 |
| wp-miniaudioplayer | 67 |
| db-backup | 67 |
| dukapress | 62 |
| dm-albums | 59 |
| simple-download-button-shortcode | 58 |
When examining the log entries for the Jetpack WordPress plugin I expected to see in most of the entries an attempt to exploit SQL injection or a local file inclusion vulnerability. Or perhaps even the latest vulnerability in jetpack to be disclosed by Sucuri, a stored XSS vulnerability. The majority of the scans appeared to just verify if jetpack had been installed. If it was installed further checks were made for the existence of specific files like class.jetpack-xmlrpc-server.php or example.html, this it seems was an attempt to exploit CVE-2014-0173 a bypass vulnerability allowing unrestricted access to some of the RPC calls packaged with WordPress.
The majority of plugins being scanned for have been public for many months, in some cases years. Why do scans continue for legacy vulnerable plugins? The reason is vulnerability assessment tools scan for the existence of all known vulnerable plugins, usually by testing for a known specific file that it is packaged with.
Plugin Security – Now
I started re-evaluating plugin security a year later by using the same previous methodology of downloading plugins and manually examining the PHP code for common vulnerabilities like SQLi, XSS, LFI, and RFI. I found plugins that have not been updated in several months pose the most risk. I also discovered plugins with less than 1000 downloads but more than 100 haven’t been updated in an average of 991 days, as of the time of writing, or almost three years. The average plugin from my sample data hasn’t been updated in 1050 days.
| # Plugin Downloads | Avg Days Since Last Update |
|---|---|
| +10,000,000 | 65 |
| 9,999,999 - 1,000,000 | 150 |
| 999,999 - 100,000 | 458 |
| 99,999 - 10,000 | 941 |
| 9,999 - 1,000 | 1296 |
| 999 - 100 | 991 |
| < 99 | 107* |
* This is because these are newly uploaded plugins actively being developed.
Conclusion
When I originally began my research into the aforementioned type of widespread exploitation of recently published vulnerabilities I had some expectations as to how it would turn out. I had expected the same categories of vulnerabilities across all platforms to receive equal amounts of attention. What I found was that specific vulnerabilities like LFI were favored over other vulnerabilities that I had expected to be more popular such as SQL injection.
What I did not expect is the amount of traffic generated by widespread deployment of scanning tools by enterprise IT staff. While it appears the multiple routine daily self scans appear excessive, at least they’re focused on their own site’s security. With the proliferation of new vulnerability scanning tools becoming readily available it’s important that software is audited and vulnerabilities are reported responsibly, fixed and publicly disclosed. This cycle of research, repair and publish is the current best way to keep systems safe and secure.
