Skip to main content
The interior of a power station turbine hall, steel stairs and gantry walkways stacked through several levels.
Photo by Wolfgang Weiser on Unsplash
  1. Archive/

SQL injection to root on a 2013 lab box

Patrik Grobshäuser
Author
Patrik Grobshäuser
Security researcher at Assetnote / Searchlight Cyber. Before that, seven years triaging other people’s reports at HackerOne and Shopify. Hunting bugs since 2012, published as Patrik Fehrenbach until 2025.
Table of Contents

A walkthrough of a SQL injection that ended in full control of the server.

Finding the bug
#

The target was a login form with a SQL injection in the password parameter. Guessing the username Admin and submitting a single quote (') as the password:

Web login form with the username set to Admin and a single quote entered as the password

The familiar SQL error came back:

The application returning a MySQL syntax error after the single quote was submitted, confirming SQL injection

Proof of concept
#

From this point I knew that there is potential on this server ;-). The next step was to point sqlmap (a SQL injection takeover tool) at 192.168.179.2/login.html with the --forms flag, telling it to look for injectable parameters in the form fields (username and password).

Terminal output of sqlmap run with –forms against the login page, reporting the password parameter as injectable

sqlmap found the injectable parameter and was ready to exploit the database. Apart from dumping the database, sqlmap can also be run with --os-shell, which gives a command prompt on the target system. It also offers file upload to the target system, so a PHP shell would have been an option, but I wanted to go further.

sqlmap’s –os-shell option dropping into an interactive OS command prompt on the compromised server

Escalating to root
#

The first step after getting a shell was to check what privileges I had on the system. The output was disappointing: I was running as the user nobody, which could do very little. Next I checked the kernel version of the underlying system: Ubuntu i686 (32-bit) running kernel 2.6.32-21-generic.

Shell output showing the process running as the unprivileged nobody user on Ubuntu i686 with kernel 2.6.32-21-generic

After some digging I found there was a public local root exploit for this kernel version.

A ‘local exploit’ requires prior access to the vulnerable system and usually increases the privileges of the person running the exploit past those granted by the system administrator.

That was exactly the plan: raise my privilege level on this machine. So I copied the exploit code over and compiled it from the shell.

Compiling the local privilege escalation exploit source with gcc from the limited shell on the target

It compiled without errors, so I ran it.

Running the compiled exploit and landing in a root shell, confirmed by the id command

Yay! I am root!