Horizon3.ai Breaks Down Fortinet Vulnerability
Zach Hanley, Horizon3.ai Chief Attack Engineer, and James Horseman, Exploit Developer, join John Furrier of theCUBE to discuss Fortinet CVE 2022 40864.
The post Horizon3.ai Breaks Down Fortinet Vulnerability appeared first on Horizon3.ai.
Early in 2023, soon after reproducing a remote code execution vulnerability for the Fortinet FortiNAC, I was on the hunt for a set of new research targets. Fortinet seemed like a decent place to start given the variety of lesser-known security appliances I had noticed while searching for the FortiNAC firmware. The first target I landed on was the Fortinet Wireless LAN Manager (WLM). The security audit of this appliance began what became the successful, but failed journey of what I dubbed the “Forti Forty” – a goal to find 40 CVE’s in Fortinet appliances. The journey ended in 16 mostly critical and high security issues identified across the FortiWLM, FortiSIEM, and another appliance before it was cut short when Fortinet’s download portal no longer provided access to download their appliances.
This blog details several of the issues discovered in the FortiWLM that have since been patched:
Additionally two vulnerabilities that have not received patches leading to appliance compromise:
Fortinet’s Wireless LAN Manager allows for ease of management of wireless devices throughout an enterprise. It remotely monitors the devices health, performance, and any RF interference all in a single pane of glass. It’s commonly deployed in large campus settings like universities, hospitals, and other large office footprints – making it a valuable target of interest in today’s threat landscape.
Figure 1. FortiWLM Dashboard
The FortiWLM web services are built atop the Apache2 and Django frameworks. The Apache configuration has defined several rewrite rules from the frontend on tcp/443 and passes them back to the Django framework middleware which listens on localhost tcp/8000.
The core of the Django middleware logic lies within the /opt/meru/etc/ws/wlmweb directory. Inspecting the file /opt/meru/etc/ws/wlmweb/wlmweb/wlmrbac.py, within the process_view() function, we see that several endpoints depending on the request path are validated against the current requests session authentication information.
On line 86, the two endpoints are explicitly allowed for any request without any authentication checks:
Figure 2. wlmrbac.py authentication checks
CVE-2023-34993: Fortinet FortiWLM Unauthenticated Command Injection Vulnerability
This vulnerability allows remote, unauthenticated attackers to inject a crafted malicious string in a request to the /ems/cgi-bin/ezrf_upgrade_images.cgi endpoint that will be executed in the context of root. The issue results from the lack of proper validation of results and calls to the potentially dangerous function system().
The first endpoint explicitly allowed without authentication, /ems/cgi-bin/ezrf_upgrade_images.cgi, can be found at /opt/meru/etc/ws/cgi-bin/ezrf_upgrade_images.cgi. All CGI endpoints are Perl scripts which, depending on the endpoint, parse different request parameters which are sometimes validated, but sometimes not.
This ezrf_upgrade_image.cgi endpoint parses the op_type request parameter, and depending on the value, passes control to different defined functions within the script.
Figure 3. ezrf_upgrade_images.cgi operation types
The deleteprogressfile() function extracts the progressfile request parameter and then directly passes it to a call to system() without any input validation.
Figure 4. ezrf_upgrade_images.cgi’s vulnerable deleteprogressfile()
Sending a request to this unauthenticated endpoint with op_type=deleteprogressfile and a malicious string in the progressfile parameter results in remote code execution in the context of the root user.
Figure 5. Unauthenticated RCE as root via ezrf_ugprade_image.cgi endpoint
CVE-2024-???? (0-day): Fortinet FortiWLM Unauthenticated Limited File Read Vulnerability
This vulnerability allows remote, unauthenticated attackers to access and abuse builtin functionality meant to read specific log files on the system via a crafted request to the /ems/cgi-bin/ezrf_lighttpd.cgi endpoint. This issue results from the lack of input validation on request parameters allowing an attacker to traverse directories and read any log file on the system.
The second endpoint explicitly allowed without authentication, /ems/cgi-bin/ezrf_lighttpd.cgi, can be found at /opt/meru/etc/ws/cgi-bin/ezrf_lighttpd.cgi. Again, this CGI endpoint is a Perl script in which different request parameters are not always validated.
When the op_type is upgradelogs, control is passed to the upgradelogs() function. This function will read the specific log file from the system and return its content in the response.
Figure 6. ezrf_lighttpd.cgi upgradelogs() function
Inspecting how the $filename variable is constructed we see that it is partially controlled by the imagename request parameter.
Figure 7. ezrf_lighttpd.cgi attacker controlled input unvalidated
Abusing the lack of input validation, an attacker can construct a request where the imagename parameter contains a path traversal, allowing the attacker to read any log file on the system.
Luckily for an attacker, the FortiWLM has very verbose logs – and logs the session ID of all authenticated users. Abusing the above arbitrary log file read, an attacker can now obtain the session ID of a user and login and also abuse authenticated endpoints.
Figure 8. Leak Session ID with Unauthenticated Arbitrary Log File Read
CVE-2023-48782: Fortinet FortiWLM Authenticated Command Injection Vulnerability
This vulnerability allows remote, authenticated attackers to inject a crafted malicious string in a request to the /ems/cgi-bin/ezrf_switches.cgi endpoint that will be executed in the context of root. The issue results from the lack of proper validation of results and insecure use of the dangerous system calls. This endpoint is accessible for both low privilege users and admins.
The ezrf_switches.cgi endpoint supports several op_type subfunctions related to adding a LAN switch for monitoring. This CGI script can be found at /opt/meru/etc/ws/cgi-bin/ezrf_switches.cgi.
The updateStatus() helper function, called in two different op_type functions, is vulnerable to command injection of both the $switche_table_k_Hostname and $switche_table_k_CommunityString variables which are derived from user input.
Figure 9. ezrf_switches.cgi vulnerable updateStatus()
Both addSwitche() and editSwitche() functions call the vulnerable updateStatus() helper function without validating any input.
Figure 10. ezrf_switches.cgi addSwitche() calls updateStatus()
Tracing those variables to where they are declared, they are derived straight from the request parameters Hostname and CommunityString, and are never validated along the way.
Figure 11. ezrf_switches.cgi request parameters unvalidated
Combining both the unauthenticated arbitrary log file read and this authenticated command injection, an unauthenticated attacker can obtain remote code execution in the context of root.
Figure 12. Abusing Unauth Log Read and Auth Command Injection to obtain root RCE
The initial report to Fortinet contained a total of 9 specific security issues, largely concentrated on the unauthenticated endpoints discovered in the Django middleware. The authenticated attack surface is large, and at the time contained numerous issues that were similar in nature to the ones detailed here stemming from a lack of input validation. Two additional security issues of note reported and patched, but unused in the attack paths were:
CVE-2023-42783: Fortinet FortiWLM Unauthenticated Arbitrary File Read Vulnerability
This vulnerability allows remote, unauthenticated attackers to access and abuse builtin functionality meant to read specific log files on the system via a crafted request to the /ems/cgi-bin/ezrf_upgrade_images.cgi endpoint in the uploadstatus function with the progressfile parameter. This issue results from the lack of input validation on request parameters allowing an attacker to traverse directories and read any file on the system.
CVE-2023-34991: Fortinet FortiWLM Unauthenticated SQL Injection Vulnerability
This vulnerability allows remote, unauthenticated attackers to access and abuse builtin functionality meant to list images on the system via a crafted request to the /ems/cgi-bin/ezrf_upgrade_images.cgi endpoint in the editimage function with the imageName and description parameters. This issue results from the lack of input validation on request parameters allowing an attacker to modify a SQL query string.
CVE-2024-???? (0-day): Fortinet FortiWLM Static Session ID Vulnerability
The web session ID token of authenticated users remains static, and unchanged, for users between sessions. Each time a user logs in, they receive the exact same session ID token. This token remains static for each boot of the device. An attacker that can obtain this token can abuse this behavior to hijack sessions and perform administrative actions. This session ID is retrievable with the unpatch limited log file read vulnerability above and can be user to gain administrative permissions to the appliance.
While we found it to be popular with State, Local, and Education (SLED) and healthcare focused customers, luckily the internet exposure is fairly limited to around 15 instances.
Figure 13. Shodan Exposure
The FortiWLM logs the majority of its application activities in the /data/apps/nms/logs directory. Specifically activity related to the exploitation these issues can be observed in the /data/apps/nms/logs/httpd_error_log.log file. Example entries of the log file included below show the exploitation of the unauthenticated remote code execution vulnerability, CVE-2023-34993. If defenders suspect that an appliance has been compromised, the logged request parameters should be analyzed to determine if they appear malicious.
Figure 14. httpd_error_log.log example entry
12 May 2023 – Submitted report to Fortinet PSIRT
15 May 2023 – PSIRT acknowledges receipt
10 July 2023 – PSIRT reproduces issues and indicates fix is in-progress
10 August 2023 – Ask for update, PSIRT responds fix is awaiting release
11 October 2023 – PSIRT releases fixes for 2 reported issues
14 November 2023 – PSIRT releases fixes for 2 more reported issues
21 November 2023 – Indicate to PSIRT of intent to publicly disclose all issues
22 November 2023 – PSIRT indicates remaining 3 vulnerabilities will be patched soon
7 December 2023 – PSIRT releases 1 fix for more reported issues
23 February 2024 – RingZer0 conference talk discussing some of these vulnerabilities
14 March 2024 – This public disclosure after 307 days with two unpatched vulnerabilities
The post Fortinet FortiWLM Deep-Dive, IOCs, and the Almost Story of the “Forti Forty” appeared first on Horizon3.ai.
On February 27, 2024, Progress released a security advisory for OpenEdge, their application development and deployment platform suite. The advisory details that there exists an authentication bypass vulnerability which effects certain components of the OpenEdge platform. Our proof of concept can be found here.
When the OpenEdge Authentication Gateway (OEAG) is configured with an OpenEdge Domain that uses the OS local authentication provider to grant user-id and password logins on operating platforms supported by active releases of OpenEdge, a vulnerability in the authentication routines may lead to unauthorized access on attempted logins.
Similarly, when an AdminServer connection is made by OpenEdge Explorer (OEE) and OpenEdge Management (OEM), it also utilizes the OS local authentication provider on supported platforms to grant user-id and password logins that may also lead to unauthorized login access.
The OpenEdge platform has several different components that can be deployed across an environment:
Typically the OpenEdge Management, OpenEdge Enterprise RDBMS, and PAS roles are deployed on a system and act as the backend, central source of information for developers using PDS as clients to develop applications. If an the Authentication Gateway is in use, it centrally manages authentication across the OpenEdge ecosystem.
Figure 1. Example OpenEdge Deployment
In this case, we were unable to obtain a patched system to perform patch diffing, but there are quite a few interesting details that can be picked from the advisory. The advisory states: “The AdminServer logins are always potentially vulnerable because they only support OS local logins”. Additionally the temporary mitigations specify:
The following mitigation options are intended for short-term use until you can apply the provided OpenEdge Update to your deployments. The revised “auth.dll” library associated with the OS you’re using should be copied into $DLC/bin to replace the vulnerable version of the “auth.dll” library that existed in LTS Updates 11.7.18, 12.2.13 or 12.8.0.
Given this information, we install OpenEdge Manager, RDBMS, and PAS on a single Windows server and inspect the installed services with TaskManager and find that these roles will start the vulnerable “AdminServer” service referenced in the advisory.
Figure 2. AdminServer service running
Now that we have the vulnerable component running – an often overlooked part of reversing is spending hours reading documentation, we find documentation on the AdminServer service and what its used for. The documentation states that its a Java RMI service listening by default on tcp/20931 and references several command line utilities to communicate with the service:
- This is the RMI port used by command line utilities: proadsv, asbman, wtbman, nsman, restman, and pre OpenEdge 12.0 fathom cmd line tooling
- The default listening port for the AdminServer (-port) remains 20931 for all versions.
Inspecting our listening connections on the Windows server, we find that the AdminServer is indeed listening on tcp/20931.
Figure 3. AdminServer service listening
Inspecting the command use to kick off the Java process we find it’s loading several Progress JARs and calling com.progress.chimera.adminserver.AdminServerStarter.
Figure 4. AdminServer command line
We find that the com.progress.chimera.adminserver.AdminServerStarter class is defined in C:\Progress\OpenEdge\java\progress.jar. Inspecting the class, we find that when a remote connection is made the connect() method is called and expects a user supplied username and password.
Figure 5. AdminServer connect()
The connect() method interestingly loads a native system library, auth.dll, and eventually calls the authorizeUser() method defined in it. Replacing auth.dll was mentioned in the temporary mitigations so we’re likely on the right track.
Opening up auth.dll in Ghidra, we find that it exports several functions to be available as Java interfaces, one of which is our authorizeUser() function.
Figure 7. Java Interfaces from auth.dll
The authorizeUser() function performs some basic input validation, ensures the supplied credentials meet certain criteria, and passes control to a function we named vulnerable_checks() (defined at 0x1800051a0). This function does further validation, but getting right into the meat of the vulnerability we see that on line 262 the user supplied AccountName (username) is compared the NT AUTHORITY/SYSTEM. If it matches, you are authenticated.
Figure 8. If username == “NT AUTHORITY/SYSTEM”: you may pass
Thats the vulnerability.
While we’ve bypassed authentication, finding attack surface to abuse to drive some impact like remote code execution was the next goal.
Java Remote Method Invocation (RMI) interfaces typically suffer from deserialization vulnerabilities, but in this case there were no classic libraries in the class path of the service to easily abuse with a ysoserial gadget. We did confirm that deserialization is possible with a simple out-of-band DNS request payload, but did not spend the time to develop a custom gadget with the in scope libraries. Remote code execution is likely possible with this avenue.
We spent the better part of a day looking for easily abusable functionality within the available RMI interfaces. Easily reachable functionality allows a user to start, stop, and list performance metrics of applications. Deeper attacker surface looks like it may allow a user to deploy new applications via remote WAR file references, but the complexity increased dramatically in order to reach this attack surface because of the use of internal service message brokers and custom messages. We believe there is again likely an avenue to remote code execution via built in functionality given enough research effort.
We continue our investigation by re-examining the AdminServer class and dbman.bat which makes use of the AdminServer. We find that we can connect to the AdminServer over RMI at rmi://<target_ip>:29031/Chimera. We get back an IAdminServerConnection which exposes two connect methods that require a username and password. With our knowledge from dbman.bat we know we need to encode the username and password using an Encoder from oeauth-12.8.0.jar.
Now that we are connected to the AdminServer, what can we do? We can use the following code to display all interfaces available to us from the AdminServer‘s getPlugins method:
We get the following output:
com.progress.system.SystemPlugIn
com.progress.chimera.common.IChimeraRemoteObject
com.progress.system.ISystemPlugIncom.progress.agent.database.AgentPlugIn
com.progress.chimera.common.IChimeraRemoteObject
com.progress.agent.database.IAgentPlugIn
com.progress.ubroker.tools.NSRemoteObject
com.progress.chimera.common.IChimeraHierarchy
com.progress.ubroker.tools.IYodaRMI
com.progress.ubroker.tools.IYodaSharedResources
com.progress.ubroker.tools.UBRemoteCommand
com.progress.chimera.common.IChimeraRemoteCommand
com.progress.juniper.admin.JAPlugIn
com.progress.chimera.common.IChimeraRemoteObject
com.progress.juniper.admin.IJAPlugIn
com.progress.agent.smdatabase.SMPlugIn
com.progress.chimera.common.IChimeraRemoteObject
From here, we leave it as an exercise to the reader to figure out what you can do with the above interfaces. Our proof of concept can be found here.
NOTE: We will not be distributing the Progress JARs given we do not own that code. These JARs can be obtained from an OpenEdge installation and are required to run the proof of concept.
When a connection is made to the AdminServer service, logs are generated at C:\OpenEdge\WRK\admserv. An example log entry can be seen below where it records the user authenticating as well as the Java interfaces that user is accessing, the UBRemoteCommand class in our case. While it seems that accessing this service via the NT AUTHORITY/SERVICE account was intended, we did not observe log entries associated to this account outside of service startup. We also were not running a production server where more service traffic may be generated and observed.
The post CVE-2024-1403: Progress OpenEdge Authentication Bypass Deep-Dive appeared first on Horizon3.ai.
Memory safety issues have plagued the software industry for decades. The Cybersecurity & Infrastructure Security Agency (CISA) has been leading a charge for secure-by-design and encouraging developers and vendors to utilize memory safe languages like Rust to eradicate this vulnerability class.
Google Chromium, the engine used by the majority of browsers around the world, reports that approximately 70% of their high severity issues are memory safety issues. Microsoft reports the same percent of issues affecting it’s Windows OS are also memory safety. But, what vulnerabilities are being exploited by threat actors today? CISA maintains and publishes its Known Exploited Vulnerability (KEV) catalog of all vulnerabilities that they have insight into having been exploited by threat actors.
We have analyzed all critical vulnerabilities from the CISA KEV catalog starting from January 2023 through January 2024, categorized the vulnerability root causes, and attempted to analyze if the current efforts in the information security industry match with the current threat vectors being abused.
Nearly half of vulnerabilities are enabled by insecure exposed functions. At a strategic level we’ve seen recent pushes for security improvements by pursuing memory safe languages and software bill of materials (SBOM), but a seemingly asymmetric amount of effort or strategy around addressing this vulnerability category.
Figure 1. Vulnerabilities by Root Cause
Vulnerabilities fall into this category when:
Memory safety issues were the second (tied) leading cause of vulnerabilities in the data set, coming in at 20%. Interestingly, 75% of the analyzed memory safety vulnerabilities have been exploited as 0-days by threat actors. Additionally, 25% were discovered by security researchers and retroactively discovered to have been exploited as 0-days. When vulnerabilities are exploited as 0-days they typically have a much more widespread effect on the world given that patches often lag by weeks once they are discovered.
Figure 2. Vulnerabilities due to Memory Corruption
Nearly 20% of vulnerabilities in Figure 1 are the result of routing and path abuse in web applications. These vulnerabilities typically manifest in the “glue” between web frameworks when a developer attempts to route application traffic from one service to another.
Vulnerabilities fall into this category when:
This isn’t a new trend, but its clear from the analysis that they are the target of choice coming in at 49%. They’re commonly found on network boundaries and exposed to the internet. They also have low defender visibility – no PSP’s installed and sparse logging.
Figure 3. Vulnerability by Software Type
For the purpose of this analysis, appliances are any product or software that is commonly deployed as a hardware appliance or as a virtual appliance.
There are 212 vulnerabilities that have been added to the CISA KEV catalog since the start of 2023. Of that, only 41 vulnerabilities are rated critical. Below is a snapshot of those 41 vulnerabilities and the root cause leading to the vulnerability being exploitable.
Category: Routing / Path Abuse
Reference: Horizon3.ai
The application exposed an endpoint, /moveitisapi/moveitisapi?action=m2, that attempted to limit functionality to just localhost, but had a header parsing bug leading to any function being reachable.
Figure 4. Header Bypass to Invoke Arbitrary Function
Category: Routing / Path Abuse
Reference: @SinSinology
A lax rewrite rule in the appliance’s Nginx configuration allowed an attacker to reach services which were meant to be unexposed. The request /saas./resttosaasservlet will route to /resttosaasservlet.
Figure 5. nginx Routing Bypass
Category: Routing / Path Abuse
Reference: Horizon3.ai
The appliance’s routing rules for which requests required authentication did not account for double URL encoded paths.
Figure 6. Double URL Encoded Path Authentication Bypass
Category: Insecure Exposed Function
Reference: Rapid7
The application insecurely exposed an endpoint that calls Java’s getRuntime().exec() with an attacker controlled variable.
Figure 7. FilterServerUtil getRuntime().exec()
Category: Insecure Exposed Function
Reference: Rapid7
The application insecurely exposed an endpoint, /server-info.action?bootstrapStatusProvider.applicationConfig.setupComplete=false, that allows modification to the server’s configuration state. Setting this state to false allows an attacker to re-enter application setup and add an administrative user.
Figure 8. Exposed Configuration Endpoint
Category: Insecure Exposed Function
Reference: Huntress
The application exposed an endpoint, /userentry?accountId=/../../../tomcat/webapps/<webshell_dir>, which wrote attacker controlled data to a filepath also influenced by the attacker, but vulnerable to path traversal in the parameter.
Category: Insecure Exposed Function
Reference: VulnCheck
The application insecurely exposed an endpoint, /index.php?c=blocked&action=continue, which did not sufficiently sanitize user input which results in second-order command injection.
Figure 10. Sanitization Bypass to Command Injection
Category: Insecure Exposed Function
Reference: Horizon3.ai
The application insecurely exposed an endpoint, /app?service=page/SetupComplete, used for first time administrator login during the install process.
Figure 11. Exposed SetupComplete formSubmit()
Category: Request Smuggling
Reference: Praetorian
The appliance used a custom Apache library which contained a known request-smuggling vulnerability: CVE-2022-26377. By abusing this vulnerability, with specific considerations for the F5 application stack, authentication bypass was achieved.
Figure 12. Request Smuggling Payload
Category: Default Secret
Reference: Horizon3.ai
The application sets the underly Flask SECRET_KEY to a default value. This secret key is used to create session tokens, which can be forged when the secret key is known.
Category: Insecure Exposed Function
Reference: Project Discovery
The application exposed an insecure function at the endpoint, /CFIDE/adminapi/accessmanager.cfc?method=foo&_cfclient=true, which called a dangerous Java sink with attacker controlled input leading to deserialization.
Figure 14. Call to WDDXDeserialize() with Attacker Controlled Input
The lions share of vulnerabilities that are being exploited in the last year are trivial to exploit. While memory safe languages like Rust may help eliminate some of portion of breaches, there is much work to do to address the risk that comes with building complex software systems.
Looking at 2024 and beyond my advice would be:
We’re already seeing similar trends in 2024 with the recently exploited Ivanti Connect Secure vulnerabilities back-to-back – more path abuse and SSRF to “RCE-as-a-feature” code. An interesting attack surface surrounding application re-initialization vulnerabilities has sprung up this last year and I think we’ll continue to see similar vulnerabilities discovered.
This analysis is made possible by the collective information security community publishing their analysis and research to the world. The following organizations or people were referenced while performing this research:
Rapid7, Mandiant, Project Discovery, Praetorian, VulnCheck, Huntress, SonarSource, AssetNote, BishopFox, Lexfo, Palo Alto Networks, and many more.
This is an analysis based on my observations as both a software engineer and a vulnerability researcher. The analysis likely has bias and shortcoming stemming from:
The full spreadsheet of all 41 vulnerabilities and their analysis can be found here.
This research was done in preparation for a talk I’ll be giving at RingZer0’s BOOTSTRAP conference on Friday, February 23. I’ll briefly touch on this research along with vulnerability research I’ve conducted against Fortinet appliances over the last year that fall directly in line with the trends highlighted here.
The post Rust Won’t Save Us: An Analysis of 2023’s Known Exploited Vulnerabilities appeared first on Horizon3.ai.
On January 22, 2024 Fortra posted a security advisory for their GoAnywhere MFT product. This advisory details an authentication bypass vulnerability, CVE-2024-0204, that allows an unauthenticated attacker to create an administrative user for the application. Customers were made aware of the issue by an internal security advisory post and patch made available on December 4, 2023, in which researchers malcolm0x and Islam Elrfai were originally credited with the discovery. In 2023, file transfer applications were a top target by threat actors. Our POC can be found here.
The advisory mentions that the endpoint /InitialAccountSetup.xhtml can be deleted and the service restarted to mitigate the issue. Looking through the application directories, we find that this endpoint is mapped to the com.linoma.ga.ui.admin.users.InitialAccountSetupForm class by inspecting the file GoAnywhere/adminroot/WEB-INF/forms-faces.xml.
Figure 1. Endpoint to Class Mapping
Using advanced tooling, we find that the GoAnywhere/lib/gamft-7.4.0.jar project defines that class.
Figure 2. Finding the InitialAccountSetupForm class
Comparing the jar’s for gamft between 7.4.0 and 7.4.1 reveals that several additional checks were added to the initializer for the InitialAccountSetupForm class.
InitialAccountSetupForm.java
When installing GoAnywhere, the application will first direct users to this endpoint to set up a new administrative user.
Figure 3. Add Administrative User During Install
After install, requesting the supposed vulnerable endpoint directly did not allow us access to the same page and instead redirects the user to the /Dashboard.xhtml endpoint and finally to /auth/Login.xhtml because the user is not authenticated.
Finding this behavior in the application leads us to the com.linoma.dpa.security.SecurityFilter class. This class is called on all requests and performs the doFilter() function, which performs checks for which endpoints are requested and based on the endpoints, user context, and application settings will allow the request to be routed to the correct endpoint.
Figure 4. SecurityFilter class
Inspecting the SecurityFilter class more closely, we find that there are a couple explicit areas that deal with requesting the /InitialAccountSetup.xhtml endpoint mentioned in the advisory.
Login
Figure 6. Loading auth.dll
Figure 9. Its a feature
Figure 9. Insecure File Write
Figure 13. Default SECRET_KEY
/wizard/InitialAccountSetup.xhtml then it will properly route you to this setup page./wizard/InitialAccountSetup.xhtml then redirect to /Dashboard.xhtml.
Figure 5. InitialAccountSetup logic
We considered the patches we observed and this logic, and without a way to pass the isAdminUserCreated check we were unsure exactly how this bypass could occur. Instead of using logic, and instead using our spidey senses, we considered if possibly there was a path normalization issue. Classically for Tomcat based applications, there exist path traversal issues when the request contains /..;/. Trying to request the supposed vulnerable endpoint now with a request that looks like https://192.168.1.1:8001/goanywhere/images/..;/wizard/InitialAccountSetup.xhtml leads to the application now routing us to the setup page again!
Figure 6. Bypassing doFilter() with /..;/
Submitting this form again, while also being careful to re-write the form submission request to include the path traversal, we find that a new administrative user has been created.
Figure 7. Administrative User Added
Our proof-of-concept exploit that adds an administrative user can be found on our GitHub.
The easiest indicator of compromise that can be analyzed is for any new additions to the Admin Users group in the GoAnywhere administrator portal Users -> Admin Users section. If the attacker has left this user here you may be able to observe its last logon activity here to gauge an approximate date of compromise.
Additionally, logs for the database are stored at \GoAnywhere\userdata\database\goanywhere\log\*.log. These files contain transactional history of the database, for which adding users will create entries.
Figure 8. Indicator of User Additions in Database Logs
The post CVE-2024-0204: Fortra GoAnywhere MFT Authentication Bypass Deep-Dive appeared first on Horizon3.ai.
