This week, Ivanti published a security warning regarding CVE-2024-22024, a high-severity vulnerability in Invanti Connect Secure, Ivanti Policy Secure, and ZTA Gateways devices. This vulnerability is an XXE bug that allows attackers to bypass authentication and access sensitive aspects of the device. This is not the first major bug in Invanti devices. It is not even the first major bug this year. Enterprise devices like these are prime targets for attackers, and as a result, are prime targets for vulnerability research.
What is Vulnerability Research?
Vulnerability research in an enterprise tool is when an ethical hacker breaks apart the tool and focuses dedicated research on finding 0-day bugs, vulnerabilities that have not been publicly discovered yet. This is all done to find the bugs before criminals find them. As ethical hackers do this research, malicious hackers often do the same thing. This is especially common for devices that are commonly used and exposed to the open internet, such as VPN gateways, such as the affected Ivanti devices mentioned above.
Of course, these are not the only devices that are targeted. Another example of a major flaw recently discovered is CVE-2024-23897, a remote file read vulnerability in Jenkins that can potentially lead to remote command execution. Products such as these are often under high levels of scrutiny for very good reasons. Compromise of an external facing device can lead an attacker into the internal network and open up the organization to further attacks, such as ransomware.
Researchers trying to find bugs in these applications will work to tear apart every part of the application through various methods to find vulnerabilities and report them as fast as possible. Researchers reporting these vulnerabilities will often have an in-depth understanding of the way that the bug operates to the point where they can guide the vendor on some remediation steps. Similar to other types of testing, this can be broken down into Black Box and White Box testing.
Black Box testing is done from the perspective of an external attacker. It is also the same method of testing that criminals will use unless they can get a legitimate copy of the software to perform testing on. This testing will try to identify bugs from the outside without having any advanced knowledge of how the application works. While this seems like it would be far less effective than White Box testing, it can turn up some very hard-to-detect vulnerabilities. This is often due to the way that certain components interact with each other that may not be initially apparent through the source code.
White Box testing is much more open. It looks at the internal mechanisms in place and breaks apart the source code to find vulnerabilities. Source code repositories for applications like this can be massive, so it will often take a skilled tester to break apart the application and know which areas are worth the time investment to investigate further. The tester will typically look for insecure functions and coding practices that they know are prone to vulnerabilities, and then attempt to exploit it from the outside with a tailored proof-of-concept.
Customer Responsibilities from Vulnerability Research
Once these bugs have been identified, ethical hackers will immediately go to the vendor and show them exactly what they found. This can start the steps towards fixing the vulnerability and getting a secured version of the product pushed out to the customers. The problem comes up when not enough good guys are doing this research. Malicious hackers are not going to want to disclose 0-day vulnerabilities that they find, as these are some prime sources of access for them into sensitive networks.
Even after the remediation process is complete and a new version of the software is released, it is then up to the customers to make sure that they apply patches and any needed fixes. The longer that these applications are left insecure, the longer the exposure window and the easier it is for hackers to find them. Systems administrators need to be diligent about monitoring their software for any new versions and getting fixes pushed out as quickly as possible to avoid costly disasters.
If a fix is slow to be released, vendors may release guidelines and temporary solutions to problems for customers to apply while a more permanent solution is crafted. In cases like these, customers need to work with their vendors to understand those solutions and ensure that they are properly implemented. It can prove to be extremely dangerous when a customer releases a fix that they believe to be sufficient while still leaving their organization wide open to attack.
If organizations are not sure about their security posture, it can be a good idea to seek the assistance of an external security consultant. Penetration testers will be able to go in and find vulnerable devices and demonstrate the risk in a safe, controlled manner. They can then bring these findings to the client and work with them to properly remediate the vulnerabilities. Blue Goat’s testers are highly experienced in assisting clients with security in both enterprise and custom systems. Contact us to schedule a discovery session.
