In a penetration testing engagement this past year, VeraSafe identified three critical security vulnerabilities in a commercial healthcare product in Oracle’s product line. VeraSafe identified Remote Command Execution, SQL Injection, and XSS bugs. All of these vulnerabilities were confirmed by Oracle and were fixed as part of Oracle’s January 2018 Critical Patch Update. Note that VeraSafe’s publication of these results was delayed, consistent with Oracle’s responsible disclosure policy.
VeraSafe was credited with the discovery of the following vulnerabilities:
The Assignment
VeraSafe was tasked with testing a commercial product from Oracle, namely “Argus Safety”. Argus Safety is a drug safety application that allows pharmaceutical companies and regulators to record adverse events or reactions caused by post-marketed drugs. The product also has built-in regulatory reporting and periodic reporting abilities. Since it is used for collecting and reporting health-related data (a “special category of data” under Article 9 of the GDPR), it is particularly important that the product protects the security of the information processed therein.
A first-minute goal – CVE-2018-2642
As part of our testing methodology, VeraSafe meticulously follows our detailed penetration testing checklists throughout each engagement, regardless of the project size or complexity. However, in the course of the Oracle Argus test, the first interesting finding came earlier than expected: file type restrictions in the file upload module seemed to be implemented only on the client side. Although the same or a similar set of controls can sometimes be implemented both at the client side and the server side, this time no errors were raised from the server when we tried to upload disallowed file types.
Unfortunately, it is rather easy to circumvent most security controls implemented in the client browser. Using intercepting proxy applications such as Burp Suite, it was a simple task to bypass the application’s browser-based checks. We successfully uploaded a simple ASP file to the server and received no errors or warnings.
Such an upload could present a major risk to the security of the app, since the same file upload module is used across the entire application. However, this was not a home run – yet. Additional checks had to be performed at this stage, to demonstrate our ability to exploit this shortcoming.
Once an attacker uploads a malicious file, he or she may be able to call it with an HTTP request, thereby triggering the server to execute the uploaded file (i.e., server-side execution). Of course, this requires that the attacker know the exact location and the name of the file as stored on the server (uploaded files are often automatically renamed by the server). Furthermore, in order to exploit this vulnerability, the upload location would need to be somewhere under the web root, so that it can be called with a browser.
Upon inspecting the communication between the browser and the web server, we noticed that the application changed the name of the uploaded file (as expected) to a random value, before saving it to a folder on the server. This is an added security feature, which could significantly decrease the probability of the attacker locating the file. More surprisingly though, another server-side component revealed the randomly generated name to us, within the response it sent back to the client. We were getting close!
The last piece of information we needed – the file path of the uploaded file – was also revealed to us on a separate screen, which made an effective attack possible in this case. This simple chain of multiple control deficiencies gives the attacker the ability to upload arbitrary files to the server and execute the uploaded files with simple browser calls.
Although all of our tests were being conducted on a staging environment, successfully uploading a simple ASP file as a proof of concept called for us to pause, inform our client about the critical deficiency, and ask for their permission to test the vulnerability with a fully functional web shell, to demonstrate how far an attacker could go.
After a few email exchanges, we were cleared to continue testing. For these remote command execution tests, we use web shells with special security features, such as a randomized filename, password protection, and IP restrictions.
VeraSafe’s test involved the following commands:
- Whoami – To check the user account running the web application. This is usually a default unprivileged account but could also be a custom account with higher privileges.
- Net localgroup administrators – To list the admin accounts on the local system.
- Dir – To see the working directory and list the file contained therein.
- Ping google.com – To see if the server’s outgoing Internet connection is restricted or not. This is to clarify if the attacker can use a tool that establishes a reverse-TCP connection (e.g., Metasploit Framework) to another attacker-controlled external server.
- Powershell -Command “$PSVersionTable.PSVersion” – Since the target was a Windows system, and the web server was running with limited privileges, it would be wise for the attacker to figure out the PowerShell version: Powershell can be very handy while trying to escalate privileges.
At this point, we had successfully operated a web shell on the web server. Therefore, the risk was very real, and the overall security posture of the target system was in doubt. Having confirmed the situation, we contacted our client again. This time the purpose was to walk them through a forensic review to be carried out on their production servers, to determine if the bug had been exploited by an attacker in the wild. Although this was a zero-day vulnerability, the vulnerability was rather easy to detect, and potentially could have been identified by an attacker before us. Analysis of logs from server operating systems, network devices, firewalls, IPS, WAF, and anti-virus software, as well as file integrity checks at some critical locations, were proposed to the client as the bare minimum level of forensic review.
After this initial round of remote command execution was finalized, we carried on with the rest of our testing.
Multiple Cases of SQL Injection – CVE-2018-2643
While proceeding through our penetration testing checklist, we came across two separate cases of SQL injection vulnerabilities, as well as a case where the request sent from the browser embodied SQL statements. Since our payloads for both SQL injection cases were forcing the server to communicate with external servers, their validity was clearly verified.
In SQL injection attacks, the attacker takes advantage of a logic flaw in the way the web server constructs SQL statements at run-time. Instead of an ordinary, well-formatted input, the attacker supplies a specially-crafted, malformed input to the web application. This malicious input breaks out of the data context (where it was originally supposed to be used as the value of a parameter, for example), and the payload is instead embedded into the SQL code. Since the web server sends the SQL statement to the database server, the database server gets the added SQL statements and executes them as usual, while the added SQL statements were actually injected by the attacker.
In a nutshell, the attacker uses the web server as a stepping stone, to send custom queries to the database server, which in turn can be used for a myriad of evil purposes.
This kind of attack obviously requires no interaction with real end-users of the target system. Since the web server is authorized to access any end-user data, the attacker gains access to data in the same context as legitimate users, freely reading and writing to the database. A successful attack would lead to a total compromise of the data stored in the database.
Worse yet, based on how the database server was configured, SQL injection can also be used for reading and writing arbitrary files, and even sending commands to the operating system. Such functionality provides great leverage to an attacker, since it can be used to upload additional files, interact with the OS shell (that black text-based screen you sometimes see on a Windows PC), as well as its more powerful counterpart “PowerShell”. Once the attacker is capable of executing OS commands, it can be used to produce a similar result to our web-shell finding: The attacker could pull additional tricks to escalate his/her privileges, jump to adjacent systems, move in the internal network, access backup systems or mail servers, and maybe even become the Windows Domain Administrator. All of this, of course, relies on how skilled the attacker is.
Reflected XSS – CVE-2018-2644
The third finding, Reflected XSS, stems from a lack of sufficient input validation controls on the web server, much like the SQL Injection and the File Upload vulnerabilities before it. Where the former two vulnerabilities target the servers, XSS targets the end-users. As such, this vulnerability requires user interaction in order to be exploited successfully.
In this risk scenario, the attacker sends the victim (i.e., an end-user of the application) a link, pointing to a URL within the vulnerable application. This is usually done via email or an instant messaging application, impersonating someone that the victim knows. The attack is almost always reinforced with a plausible scenario: “Please check this report immediately. The boss demands an explanation right away!”. Since the link points to an application that the victim is familiar with and trusts, the message seems to have come from someone known to the victim, and the issue is allegedly urgent, there’s a fair chance that the victim may be tricked into clicking through, without giving it a second thought.
If the victim clicks the link while logged in to the targeted application, a custom JavaScript code that the attacker prepared will be executed on the victim’s browser.
This type of attack is usually used to steal a piece of information called a session cookie, which enables the attacker to access the application with the victim’s account. Alternatively, the attacker can read or write data, or perform any action that the victim is authorized to conduct in the target application. It all boils down to how privileged the victim’s account is, and how well the attacker knows the application. If XSS is performed against an administrator of the target application, the attacker could obtain access to the administrator’s account, which illustrates just how dangerous this type of attack can be.
Contacting Oracle
Although our client could implement some countermeasures at the infrastructure level (e.g., filtering the inbound traffic using their network security products to detect and block attack patterns, etc.), this could only be considered as an interim solution to what is indeed a serious security issue. Fixing the bugs must ultimately be done at the application layer, with a patch released by Oracle.
Oracle has a streamlined process for security researchers to report bugs that they have discovered. Oracle’s Security Alerts team is very professional, responsive, and swift in developing fixes for security issues. In disclosing these vulnerabilities, VeraSafe followed Oracle’s responsible disclosure practices, as described by Oracle here: https://www.oracle.com/support/assurance/vulnerability-remediation/reporting-security-vulnerabilities.html
An announcement about the vulnerabilities can be found in Oracle’s Critical Patch Update for January 2018. To find VeraSafe’s credit, search for ‘VeraSafe’ on the following page:
https://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html
As this test shows, web applications are inherently high risk, even for large companies with deep expertise in secure software development. Manual penetration testing is one of the best ways to help ensure the confidentiality, integrity, and availability of the data processed in such applications. With the GDPR and other privacy and cybersecurity laws imposing strict requirements for data security, and data breaches costing upwards of $3 million dollars on average, there is no better time to seek a professional review of the technical security in your application and infrastructure.
Contact VeraSafe today to discuss penetration testing for your environment.
