Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Leveraging LFI To Get Full Compromise On WordPress Sites

In this post I will discuss how a serious but mostly ignored vulnerability can lead to a full compromise of a WordPress site. The key in this attack is how WordPress handles authentication allowing a brute force attack if the secret salt and key values stored in wp-config.php are exposed. IF an innocuous LFI (local file inclusion) or accidental leak of this data by a backup or copy of wp-config.php is successful, then an attacker could generate their own valid auth tokens and gain full access to the site's admin pages without being detected.

This is a followup to a previous blog post (Jamming with WordPress Sessions) where I discussed an attack against WordPress authentication tokens. At that time I only wrote about a post-compromise scenario where an attacker could generate undetectable authentication tokens that effectively never expire. I restrained myself then from divulging how this flaw could chain with other attacks to allow attackers to compromise WordPress sites. With the release of WordPress 4.0, the vulnerability that this attack exploits (CVE-2012-5868) has finally been patched (yes, after 2 years).

To summarize and get you up to speed, up until WordPress 4.0 the way the site handled creating and validating authentication tokens was by making a hash of three values: 1. the site's secret key/salt pair, 2. four characters of the user's hashed password, and 3. the expiration time stamp.


On a valid login, the three values are passed through a series of hashing algorithms (HMACs) and the resulting md5 hash is given to the user's browser as a cookie. Verification of the authentication cookie is handled by the website running the hashing algorithm again using the expiration time stamp and its known secret values to validate that the cookie's stored authentication token is valid.

This flaw was patched in the 4.0 release by tying the authentication tokens sent to the user to session identifiers managed in the database. I encourage everyone to upgrade to WordPress version 4.0 as soon as possible because it addresses this flaw. Doubly so because there is evidence that shows an increase in LFI (Local File Inclusion) attacks against WordPress sites our Web Server Security team posted about recently.

Getting back to the attack. The three values are key. The timestamp is arbitrary and supplied by the user. The secret salt is by far the least likely to be guessed or brute forced. The four characters of a user's password hash can be brute-forced over a period of time. So, how would we get the unknown and impossible-to-guess secret salt? That's where LFI or information leakage attacks come in.

The attack would play out like this:

1) Use an existing attack to get access to the wp-config.php file's secret key values:


Or, alternatively, use one of the many Local File Inclusion attacks, which target common themes and plugins.

2) Pull out the secret keys and plug their values into the proof of concept code:


Here is the Proof of Concept attack code in full:


3) The PoC will use the key values to generate brute force auth tokens on the fly:


4) Then it uses the generated auth tokens to hit the site looking for a valid authentication cookie (in this case, looking for http header response code that denotes we sent a valid authentication cookie):


This step may take a while as there are 64^4 possible iterations of the four character combination we're bruting. However, from the web server perspective it will not look like a brute force in the access logs, the authentication takes place based via the sending of the cookie to the server. So, the attack could appear in the site's logs like regular traffic to the site.

5) When a valid auth token is found, the code will output the value of the cookie:


6) You can then automate the attack to use the authentication cookie to take immediate actions (such as adding users via the WordPress admin page, upload a backdoor, etc..) or if you prefer the hands on approach, copy the cookie's value into your browser and get access as the brute-forced user's admin pages. The PoC above uses an expiration timestamp that expires in about 100 years, so you have plenty of time on your hands to take action after forging the authentication cookie.

There we have it, anyone who leaks the secret key and salt values of their site is a stone's throw away from a site being seriously compromised.

This post has shown how dangerous leaking secret key values can be and clarified what additional risks have been associated with CVE-2012-5868. Furthermore, using this vulnerability as a example, we see how long a publicly reported vulnerability might take to be patched even by a major vendor. Two years is a surprising length of time to "push back" a vulnerability's public patch, but should serve as a striking example on why implementing a web application firewall (WAF) and using it for virtual patching can help protect against vulnerabilities when a vendor can not be relied upon for timely patches.

Read more about Trustwave WAF or Trustwave ModSecurity rules and services.

Latest SpiderLabs Blogs

Welcome to Adventures in Cybersecurity: The Defender Series

I’m happy to say I’m done chasing Microsoft certifications (AZ104/AZ500/SC100), and as a result, I’ve had the time to put some effort into a blog series that hopefully will entertain and inform you...

Read More

Trustwave SpiderLabs: Insights and Solutions to Defend Educational Institutions Against Cyber Threats

Security teams responsible for defending educational institutions at higher education and primary school levels often find themselves facing harsh lessons from threat actors who exploit the numerous...

Read More

Breakdown of Tycoon Phishing-as-a-Service System

Just weeks after Trustwave SpiderLabs reported on the Greatness phishing-as-a-service (PaaS) framework, SpiderLabs’ Email Security team is tracking another PaaS called Tycoon Group.

Read More