HackTheBox Writeup: Optimum (Easy/Windows)

This page has been machine-translated from the original page.

I use the penetration-testing learning platform “Hack The Box” to study security. At the time of writing this article, my rank on “Hack The Box” is ProHacker.

This time, I am writing up the retired HackTheBox machine “Optimum”.

About This Article

The content of this article is not intended to encourage acts that are contrary to social order.

Please note in advance that attempting attacks against environments other than those you own or are authorized to use may violate the Act on the Prohibition of Unauthorized Computer Access (the Unauthorized Access Prohibition Act).

All statements here are my own and do not represent any organization I belong to.

Table of Contents

• Enumeration
• About the Vulnerability

• Local Enumeration

  • MS16-032
  • MS16-034
  • MS16-135
• PowerShell Session
• Summary

Enumeration

As usual, I started with an Nmap scan.

Starting Nmap 7.92 ( https://nmap.org ) at 2021-10-27 20:22 JST
Nmap scan report for 10.10.10.8
Host is up (0.30s latency).
Not shown: 999 filtered tcp ports (no-response)
PORT   STATE SERVICE VERSION
80/tcp open  http    HttpFileServer httpd 2.3
|_http-title: HFS /
|_http-server-header: HFS 2.3
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 42.09 seconds

It seems that an application called HttpFileServer httpd 2.3 is running.

A quick search immediately turned up exploit code.

Reference: HFS (HTTP File Server) 2.3.x - Remote Command Execution (3) - Windows remote Exploit

Using it as-is was enough to get a reverse shell.

About the Vulnerability

The vulnerability exploited by this exploit code was CVE-2014-6287.

The findMacroMarker function in parserLib.pas in Rejetto HTTP File Server (aks HFS or HttpFileServer) 2.3x before 2.3c allows remote attackers to execute arbitrary programs via a %00 sequence in a search action.

It appears that entering %00 into the search box allows arbitrary code execution.

In terms of vulnerability classification, it falls under CWE-158: Improper Neutralization of Null Byte or NUL Character.

In this case, the issue was that a regular expression in parserLib.pas did not properly handle NULL bytes, so if %00 was entered into the search box, the command that followed it would be executed.

By exploiting this vulnerability, I was able to obtain a reverse shell.

Local Enumeration

For the time being, I ran winPEAS.

Basic System Information
Check if the Windows versions is vulnerable to some known exploit https://book.hacktricks.xyz/windows/windows-local-privilege-escalation#kernel-exploits
    Hostname: optimum
    ProductName: Windows Server 2012 R2 Standard
    EditionID: ServerStandard
    ReleaseId: 
    BuildBranch: 
    CurrentMajorVersionNumber: 
    CurrentVersion: 6.3
    Architecture: AMD64
    ProcessorCount: 2
    SystemLang: en-US
    KeyboardLang: English (United States)
    TimeZone: (UTC+02:00) Athens, Bucharest
    IsVirtualMachine: True
    Current Time: 3/11/2021 1:02:07 ??
    HighIntegrity: False
    PartOfDomain: False
    Hotfixes: KB2959936, KB2896496, KB2919355, KB2920189, KB2928120, KB2931358, KB2931366, KB2933826, KB2938772, KB2949621, KB2954879, KB2958262, KB2958263, KB2961072, KB2965500, KB2966407, KB2967917, KB2971203, KB2971850, KB2973351, KB2973448, KB2975061, KB2976627, KB2977629, KB2981580, KB2987107, KB2989647, KB2998527, KB3000850, KB3003057, KB3014442, 

  [?] Windows vulns search powered by Watson(https://github.com/rasta-mouse/Watson)

I confirmed that it was a 64-bit Windows Server 2012 R2 system.

Because Watson’s vulnerability search only works on Windows Server 2016 and later, I used Sherlock for enumeration.

I confirmed that the system was affected by the following three vulnerabilities.

Title      : Secondary Logon Handle
MSBulletin : MS16-032
CVEID      : 2016-0099
Link       : https://www.exploit-db.com/exploits/39719/
VulnStatus : Appears Vulnerable

Title      : Windows Kernel-Mode Drivers EoP
MSBulletin : MS16-034
CVEID      : 2016-0093/94/95/96
Link       : https://github.com/SecWiki/windows-kernel-exploits/tree/master/MS16-034?
VulnStatus : Appears Vulnerable

Title      : Win32k Elevation of Privilege
MSBulletin : MS16-135
CVEID      : 2016-7255
Link       : https://github.com/FuzzySecurity/PSKernel-Primitives/tree/master/Sample-Exploits/MS16-135
VulnStatus : Appears Vulnerable

MS16-032

This is a vulnerability in which Secondary Logon does not properly manage request handles in memory, allowing arbitrary code execution with administrator privileges.

Reference: Microsoft Security Bulletin MS16-032 - Important | Microsoft Docs

Secondary Logon is a service that allows a process to be started with different credentials, and it is used by the “Run as different user” feature.

MS16-034

This is a vulnerability in the way Windows kernel-mode drivers manage objects in memory, and it appears to allow arbitrary code execution.

Reference: Microsoft Security Bulletin MS16-034 | Microsoft Docs

The exploit is here.

MS16-135

This appears to be a vulnerability that leaks information from the kernel, leading to an ASLR bypass.

Reference: Microsoft Security Bulletin MS16-135 | Microsoft Docs

PowerShell Session

Since MS16-032 and MS16-034 are vulnerabilities that allow RCE with administrator privileges, I decided to use one of them.

When I looked for exploit code, I found a script for MS16-032 that can be run from PowerShell, so I used that one.

First, MS16-032 can only be exploited from a 64-bit process.

Therefore, the process from which the reverse shell was obtained also needs to be 64-bit.

You can easily determine whether the currently running process is 64-bit by using the following .NET command.

[Environment]::Is64BitProcess

Reference: Environment.Is64BitProcess Property (System) | Microsoft Docs

The paths for 64-bit and 32-bit PowerShell are as follows, so it may be useful to remember them for later.

• 64-bit PowerShell : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
• 32-bit PowerShell : C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

The table below shows the combinations of CPU/OS/application bitness and the bitness of the resulting process.

In this case, the CPU and OS architecture are 64-bit, but if you run 32-bit PowerShell, the process also becomes 32-bit.

So, after obtaining a reverse shell in a 64-bit process and firing off the MS16-032 exploit, I was able to get root privileges.

Summary

I decided to study hacking seriously, so for now I will keep solving retired machines.