Establishing a Beachhead

Establishing a beachhead is an important objective during many of our security assessments. To gain further access into an environment we need to get access to an Internet facing system, which can then be used to pivot into the network. The walkthrough below is a real life example, taken from one of our projects.

Target OS: Windows 2012 R2

Applications: XAMPP, phpMyAdmin

Rules of engagement: No denial of service, no brute force attacks.

During the initial recon phase we found a HTTP service active on a non-standard port.

What’s on that port? a phpMyAdmin page. Is the default “pma” account active?

Yes it is.

The root application path presents a OTP authentication page. Users can either login, or process a forgotten password.

We used Burp proxy to analyze  the traffic between the browser and the host….what if we append a SQL statement to a “forgot password” request?

This produced an error which indicated a possible SQL injection vulnerability.

Combining the SQL injection issue and the knowledge that the backend was MySQL, the objective was now to gain access to the root user account. The XAMPP server default configuration had been  changed, and the root MySQL user has a password associated to it.

To recover the root user password hash we used SQLMap.

The password was then processed through a cracking utility and successfully found (it helped it was not complex).

This was then used to log in to the phpMyAdmin page as root. From there more knowledge can be gained. The databases associated with the OTP authentication mechanism were reviewed and focus shifted to the db_otpgentool user table.

The user table contained a list of accounts, password hashes, and other data. PhpMyadmin has a built in export function which was used to pull the data. 20 passwords were subsequently recovered.

A number of these were tested with the OTP page, however none were able to successfully authenticate despite being valid accounts.

From here the other databases on the server were investigated, there were two other application specific databases. These databases were used for various business operations. Both applications were configured to restrict remote access. An alternative approach was needed to gain remote access.

The first attempt was to use the SQL injection to create a remote session. The assessment team attempted to upload a remote access package, however this was not successful as the restrictions in place prevented this.

The ability to illicit information as the root user within the MySQL and XAMPP application space was complete, but these permissions were not completely mirrored at the host level.

To bypass these permissions a custom attack plan had to be developed. By leveraging the root access and understanding the application locations the OSec team began the next attack by creating a database on the server.

This database was created with root permissions. Leveraging these permissions, two tables were created within the database, userform and user_upload. These tables would then be leveraged for uploading the initial exploit and remote access code.

Within the userform table, HTML code was written to the first column within the database table. Within the user_upload table, the PHP code to be used by the userform code was precoded and configured. Leveraging the mySQL root “write to file” function the tables were exported to local files within the c:xampphtdocs folder. This folder is the publicly available folder located on the server. Once both files were written to the server folder the ability to upload files directly was added to the host.

Write permissions allowed the OSec team to then continue the attack to gain more control of the system. This included creating a custom php webshell. The php webshell was used to gain host level access, control, and was used as the channel for further internal access.

Leveraging the full read and write service level access, the OSec team was able to upload and connect to the host and the internal environment via a custom remote access package. The custom package was written to the c:xampphtdocs page as a php file. The package was then executed by browsing to the file location within the tester’s browser. The connection was then established and validated on the remote command and control host.

At this point the beachhead was established and the next task was to move into the network.

How to prevent this?

All the ‘standard’ stuff:

1) Make sure you change those default passwords.

2) Santize input for your apps (stop SQL statements being password with an email account) OWASP has a good write up here  https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

3) Use complex passwords

The key is consistency, if you leave one system unsecured you may have a problem (depending on what that system connects to).