OVERVIEW
The healthcare sector is working relentlessly to offer the best life-critical services to ease patient management with new technologies. However, Cyber attackers are coming up with ways to exploit the vulnerabilities that are associated with these changes. The healthcare industry is afflicted by a mass number of cybersecurity-related issues. The need for cyber security in healthcare industry is essential.
SCENARIO
We were asked to perform a web application penetration testing on their web application to verify if any vulnerability exists on their platform. Also, a Black box testing to test their initial security implementation.
MAJOR HEALTHCARE DIGITAL RISK
Data breach, Data theft, Malware, Exploitation of existing vulnerabilities in the applications. We helped mitigate them all.
WHAT WE FOUND
We classified the risks we found into three categories I.e., High, Medium, and Low:
- The High-level risks comprise Privilege Escalation Vulnerability, Forced browsing, and User Account takeover via Sensitive Data Exposure.
- The Medium-level risks include API documentation Expose, Password in HTTP Response, Verbose Error, and Server Version Disclosure Vulnerability.
- The Low-level risks contain User Enumeration, Full Path Disclosure, and Frameable Response (Clickjacking).
BRIEF ABOUT WHAT WE FOUND
In the application, we were given an admin role. By creating another user and intercepting the requests to view customer data, we discovered that the normal user can access the information that was meant to be accessed by the admin user only. This Vulnerability is known as Privilege Escalation Vulnerability. The entire application was highly affected by this vulnerability.
By conducting an observation, we spotted an end-point that could expose the user details if crafted properly. We also discovered that the .js file had a session cookie that led to the test account takeover. Upon conducting a few tests, we discovered that the API documentation is publicly available.
A known password was found in an HTTP response. As the password was not submitted in the HTTP request initiating the response, the password had likely been stored on the server, or a connected system, in an insecure manner. In this scenario, the application responds with the hashed password that an internal user can use to crack and get the plain text password to impersonate the existing user.
After creating a malformed request and creating numerous requests, we got a verbose error. The server also disclosed the version. The server disclosed the Full Path of the application too. The application was also prone to User enumeration and Frameable Response (Clickjacking) as well.
We helped mitigate the following risks
User Account Takeover via Sensitive Data Exposure:
User account takeover is a vulnerability where an attacker modifies the execution flow of the application resulting in unexpected behavior. Several factors might be responsible for User Account Takeover, including weak access controls, two-step auth bypass, etc. Such vulnerabilities may result in data theft and leakage of sensitive user details, leading to data disruption.
Recommendations we suggested:
- Implement proper access controls in the application.
- Implement strong session-based checks for an individual user.
API documentation Exposed:
The most valuable asset an organization owns is its data. Threats to that data have to be identified and, hopefully, eliminated so you don’t put that value at risk. However, with the rise of Application Programming Interfaces (APIs) comes the potential for more security holes, meaning developers need to understand the vulnerabilities to keep corporate and customer data safe. With such an accelerated shift to API-based architectures, it’s important to note that in many ways, APIs provide the easiest access point for a hacker who wants your data. The existing application reveals the API documentation that might be helpful for the attacker to conduct further attacks on the infrastructure.
Recommendations we suggested:
- Remove the API documentation.
Username Enumeration:
Web applications with password and login authentication typically include several components that interact with the user database such as the login window, the registration form, and the password reset page. If the web developers do not implement these features securely, an attacker may be able to use them to determine if a certain username exists in the database.
Recommendations we suggested:
It is advised to generate a generalized error message to avoid username enumeration. For instance: – “Incorrect Username or Password”.
Frameable Response (Clickjacking):
Clickjacking is a malicious technique of tricking a user into clicking on something different from what the user perceives, thus potentially revealing confidential information or allowing others to take control of their computer while clicking on seemingly innocuous objects, including web pages. The attacker tricks a user into performing undesired actions by clicking on concealed links.
Recommendations we suggested:
- Implement X-Frame-Options headers in the response.
- Implement Content Security Policy that implements frame-ancestors directive examples:
# Disallow embedding. All iframes etc. will be blank or contain a Browser-specific error page.
Content-Security-Policy: frame-ancestors 'none'
# Allow embedding of own content only.
Content-Security-Policy: frame-ancestors 'self'
# Allow specific origins to embed this content
Content-Security-Policy: frame-ancestors <host>
BUSINESS RISK WE PREVENTED
- PII (Personally identifiable information) exposure.
- Reputation loss.
- Data breach.
- Data theft.
- Possibility of the customer losing their test report.