Week 9 SQL Injection (SEC 335) - Chromosom3/TechNotes GitHub Wiki

Gloin.shire.org Penetration Test Report

Target IP Address: 10.0.5.31

For this engagement the client provided the hostname of the system: gloin.shire.org. Using nslookup against the client’s Domain Name System (DNS) server we are able to see that the hostname gloin.shire.org resolves to the IP address 10.0.5.31. The full command used was nslookup gloin.shire.org 10.0.5.22.

Service Enumeration

Once the target’s IP address was determined the next step was to enumerate services on the target system. To do this the utility nmap was used. Specifically, the command nmap 10.0.5.31 -A was used to initiate a scan against the target. That scan included OS detection, version scanning, script scanning, and traceroute. The results of the scan can be seen in the figure below.

From the scan results, we are able to get a lot of information about the target. First, we see there are three ports open on the system: 22, 443, and 3389. The first port 22 is the default port for SSH. As we can see from the figure, nmap believes the target is running OpenSSH for Windows. This start pointing us in the direction that the system is running some sort of Windows operating system.

Moving on we can see that port 443 is open on the system. This port is the default port for HTTPS. This indicates that there is some sort of web server running on the target. Looking closer at the service information we can see that Apache 2.4.51 (Win64) is apparently running on this port. This supports the claim that the target is a Windows system.

The third and final open port on the system is 3389. This port is associated with Remote Desktop. Remote Desktop, formerly Terminal Services, is Microsoft’s remote access program for connecting to Windows systems remotely. This combined with all the other information gathered so far leads to a high probability that the system is in fact running a Windows operating system.

Vulnerability Detection

OpenSSH 7.7 -

As mentioned earlier, the target system is running OpenSSH version 7.7. This version of OpenSSH is vulnerable to user enumeration. This vulnerability was assigned CVE-2018-15473.

Resources:

• Mitre: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15473
• Tenable: https://www.tenable.com/cve/CVE-2018-15473

Apache 2.4.51 -

The Apache service running on the system was also vulnerable. Specifically, Apache version 2.4.51 and earlier are vulnerable to a buffer overflow in the mod_lua module. That being said the Apache httpd team is not aware of an exploit for the vulnerability though it might be possible to craft one. This vulnerability was assigned CVE-2021-44790.

Resources:

• Mitre: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44790
• Tenable: https://www.tenable.com/cve/CVE-2021-44790

Simple Online College Entrance Exam System 1.0 -

The Simple Online College Entrance Exam System web application that was being hosted by Apache on the system is vulnerable to SQL injection. This was determined by performing Open Source Intelligence (OSINT) on the application. There is no CVE for this but proof of concept code can be seen in the resources below.

Resources:

• Account Takeover: https://www.exploit-db.com/exploits/50397
• Unauthenticated Admin Creation: https://www.exploit-db.com/exploits/50396
• 'Multiple' SQL injection: https://www.exploit-db.com/exploits/50398

Initial Foothold

After the initial service enumeration was conducted I accessed the web server running on port 443 (HTTPS). This presented me with a page for an online entrance exam system. Additionally, it can be seen that the favicon for the site is the XAMPP logo.

From here some additional OSINT was conducted to try and determine what web application is running on the target system. This resulted in the location of the web applications source code (https://www.sourcecodester.com/php/14976/simple-online-college-entrance-exam-system-php-and-sqlite-free-source-code.html), as well as multiple results relating to SQL injection. Armed with this knowledge a simple SQL injection was attempted against the target system.

As seen from the image above inserting a single quote (’) into the reference code field creates an error. This error is different than an incorrect code being entered. An example of the message displayed when an invalid account is entered can be seen below.

Reviewing the source code of the website via Chrome’s inspect element view we can see that the data entered into this reference code field is sent to “/Actions.php?a=e_login” as a post request. Reviewing the code found on the source codes for the application we can see the function “e_login”. This is shown below.

function e_login(){
        extract($_POST);
        $sql = "SELECT *,(lastname || ', ' || firstname || ' ' || middlename) as `name` FROM enrollee_list where reference_code = '{$reference_code}'";
        @$qry = $this->query($sql)->fetchArray();
        if(!$qry){
            $resp['status'] = "failed";
            $resp['msg'] = "Invalid username or password.";
        }else{
            $resp['status'] = "success";
            $resp['msg'] = "Login successfully.";
            foreach($qry as $k => $v){
                if(!is_numeric($k))
                $_SESSION[$k] = $v;
            }
        }
        return json_encode($resp);
    }

We can see the SQL query on line three. Additionally, we can see there is no input validation. This is why an error was created when a single quote (’) was entered. Visiting the “Actions.php” file directly we receive a new error message.

This new error message presents us with the full path of the web application’s files on the system as well as confirms this is a Windows target. From here we can return to the initial login screen and attempt to bypass it with SQL injection. Specifically, we can enter ' OR 1=1 -- to bypass the prompt.

At this point, we were able to enter the web application.

At this point, we can use the resources found online to gain more information about the users of the web app. Using the 'Multiple' SQL injection Exploit DB entry we can enumerate the administrator account. The query used for this engagement was https://10.0.5.31/entrance_exam/take_exam.php?id='+UNION+SELECT+1,username||';'||password,3,4,5,6,7+FROM+admin_list;. This presents us with the result seen below.

From that, we are able to see that the username for the web app is “admin” and the password hash is “4214db3884e9cd913b49b5b44e49ae96”. We can now use Crackstation (crackstation.net) to attempt to crack the hash. Doing so presents us with the password for the user account: “Moria2Featon6”.

Using these credentials allows us to log into the web application as an administrator.

Privilege Escalation

Once the web application was compromised focus shifted to the Windows operating system. Since the system had Remote Desktop enabled Remmina was used to attempt a connection to the system via RDP. Using the password obtained from the web application I attempted to sign into the default Windows user account “Administrator”. It seemed that this account was not only enabled but was using the same credentials as the web application admin account.

Once on the system, I proceeded to gain additional information about the user accounts that have been created on the system. It was determined that this system is not a member of a domain and only had one other user account, “gloin”. The gloin account was a standard user and their password must be changed at the next logon.

From here additional examination of the operating system was conducted and two flags were found on the system. These flags are shown below.

Mitigations

To prevent exploitation of the target system in the future multiple controls should be put in place. First, there should be an updated policy in place for the operating system as well as the applications and services running on the system. Keeping the system up to date would make it harder to compromise any services that are running. Additionally, the web application should be reviewed and proper input validation should be configured to prevent SQL injections. The reuse of passwords from the web application to the operating system allowed me to gain full administrator access to the target. In the future, each account should be using unique credentials. The web application also did not salt any of the hashes making them easier to crack.

Reflection

This week’s assignment was very fun and just the right amount of challenging. I enjoyed that the lab didn’t directly spell out what needed to be done. We had to figure out the steps and do privilege escalation on our own. I enjoyed this very much. That being said it was not all smooth sailing. I was able to easily compromise the web application however there was a bit of time when I didn’t know how to pivot to the operating system. I thought I would have to try more difficult techniques to compromise the host and get root. This lead me to research a lot of different techniques that didn’t work and weren’t applicable. Finally, I slowed down and thought it through. I realized that I had a password hash and decided to crack that. Then I thought back to previous labs. That is when I decided to use the credentials with the default account. This is what lead to the root account compromise. The lesson learned here is that sometimes it's the simplest solution that will work.