Case Study: Cybersecurity
Vulnerability Assessment and OWASP Top 10
Secured™ recently completed a vulnerability assessment for an amazing client that we will refer to as Client A. The assessment highlighted the efficacy of adopting the Open Web Application Security Project (OWASP) Top 10.
Vulnerability assessments aim to provide a list of vulnerabilities present on a client system. These vulnerabilities can either be fixed or further tested for exploitation by a penetration tester. Locating vulnerabilities manually or through automated processes can be time-intensive but a proactive approach by companies can quickly minimize their risk to exploitation. Regularly scheduled vulnerability assessments are essential to securing enterprise environments against new threat actors and vulnerabilities.
Low Hanging Fruit: The Three P’s
Malicious threat actors often prioritize their exploitation efforts by focusing on “low hanging fruit”- vulnerabilities that can be easily exploited with little effort. Penetration testers and malicious actors aim to save time and effort by prioritizing these “easy wins”. Common “low hanging fruit” typically focus on three areas that we like to call “The Three P’s”:
- Patch Management
- Policies and Procedures
- Passwords
Poor patch management can lead to vulnerabilities with public exploits. Improper policies and procedures encompass a wide range of issues like misconfigured servers, poorly implemented ACLs, and open SMB shares. Password vulnerabilities are wide ranging, and can include default or weak passwords, which can expose a variety of remote access services like SMB, RDP, FTP, SQL, and SSH. The variety of “easy wins” may seem like a lot for security teams and developers to check. Our latest security assessment provides a small-scale example of how the OWASP Top 10 can help increase awareness of the most critical web application security risks.
OWASP’s aim is to improve development culture so that organizations are more secure. In 2021 OWASP updated its list of its top 10 web application security risks. Ten findings by Secured’s™ security assessment team for Client A are listed not just in the OWASP Top 10, but in the top five categories.
Below are three categories from the OWASP Top 10 and how to minimize exposure.
A01:2021 – Broken Access Control
At the top of the OWASP list, Broken Access Control’s prevalence in web applications is higher than any other category.
- OWASP’s Broken Access Control Description:
- Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user’s limits.
OWASP describes various Broken Access Control vulnerabilities, including the ability to view or edit someone’s account through insecure directory object references.
As an example, Secured™ found that our client listed its member profiles and private web directories on sitemap.xml and that these pages were accessible. This effectively exposed the company and their client’s information.
Another Broken Access Control vulnerability that OWASP describes is accessing API with missing access controls for POST, PUT and DELETE. These methods can be misused by malicious actors. Secured also noticed these HTTP methods were allowed by its client. The curl command with the OPTIONS method often can list which HTTP methods are available:
- curl -v -X OPTIONS
Burp Suite can also be used to check:
A02:2021 – Cryptographic Failures
Cryptographic Failures, number two on the OWASP Top Ten, was previously known as Sensitive Data Exposure and aims to focus on the protection needs of data in transit and at rest.
OWASP provides questions to help pinpoint Cryptographic Failures, some examples are:
- Is any data transmitted in clear text? This concerns protocols such as HTTP, SMTP, FTP also using TLS upgrades like STARTTLS.
The Secured™ team found that our client was using older TLS versions, running sites over HTTP, and had expired SSL certificates.
- Are any old or weak cryptographic algorithms or protocols used either by default or in older code?
Secured™ found that our client supported medium strength ciphers, making it vulnerable to a SWEET32 attack. Ciphers can be manually checked through Linux Command Line with the nmap script ssl-enum-ciphers:
- Is encryption not enforced, e.g., are any HTTP headers (browser) security directives or headers missing?
Secured™ found that on certain domains our client did not have the following HTTP Headers: HSTS, Content Security Policy, X-Content-Type-Options, and X-Frame-Options. These missing headers are not necessarily vulnerabilities in and of themselves, but could indicate the client’s environment is not hardened. HTTP headers can be checked using Linux Command Line using the curl command: curl -ski
They can also be checked using: https://securityheaders.com/
- Is the received server certificate and the trust chain properly validated?
Client A also had an expired SSL certificate, which allows attackers to create identical phishing sites and conduct on-path attacks. Linux users can use nmap’s ssl-cert script to see ssl certificate information.
A quick check for many of the OWASP Cryptographic Failures can often be done without using an expensive vulnerability scanner or using a Linux terminal. Google browser’s Developer Tools and Mozilla’s Web Developer Tools both show HTTP response headers. Cryptographic checks can also be checked using websites like Test TLS and Qualys’ SSL Lab.
A05:2021 – Security Misconfiguration
Security Misconfiguration is a broader OWASP category that covers a host of potential issues, from vulnerable software to improper security settings in application servers and application frameworks. The first three examples are notable due to their prevalence and highlight the range of potential vulnerabilities included in this OWASP category:
- Missing appropriate security hardening across any part of the application stack or improperly configured permissions on cloud services.
- Unnecessary features are enabled or installed (e.g., unnecessary ports, services, pages, accounts, or privileges).
- Default accounts and their passwords are still enabled and unchanged
“Default accounts and their passwords are still enabled and unchanged” is a common “low hanging fruit” for malicious actors and penetration testers.
Our client’s assessment showed that their SSH server was on the default port 22, with a root-enabled account that was password accessible. These default settings are not inherently a high-risk vulnerability but do open up their environment to brute-force attacks. SSH services should be configured to minimize brute-force attacks. By keeping the SSH server on its default settings, malicious actors already know the administrative username is “root” and the port location is 22 to brute-force.
Attackers can use nmap scripts to quickly check for default settings:
- nmap –p 22 -Pn — script ssh-auth-methods –script-args=”ssh.user=root”
Due to the variety of possible security misconfigurations, Secured recommends referring to each vendor’s security best practices along with guidance from OWASP.
Implementing Security Best Practices
The above sample findings from our recent client security assessment illustrate how the OWASP Top 10 can be used to instruct development teams about prevalent web application security threats. OWASP categories describe the possible vulnerabilities related to each threat and ways for developers and security teams to mitigate these vulnerabilities. Security policies and development procedures should be updated to reflect current security best practices and can often be quickly identified with regular vulnerability assessments.
A list of OWASP Top 10 can be found at: https://owasp.org/Top10/
Sample Resources: