This post summarizes critical security vulnerabilities that we found in the 2021 projects. To preserve the sensitivity of our client’s information, we provide only high-level descriptions of the vulnerabilities and share some context to support risk evaluation. We hope it helps you better understand the threat landscape of a modern software application and IT infrastructure.
We also share recommendations that may help prevent these application security vulnerabilities in your systems and software. Of course, our security vulnerability assessment reports contain more detailed remediation advice. But we hope these recommendations will prove helpful to everyone.
Sensitive Information Disclosure
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
CWE-22: Improper Limitation of a Pathname to a Restricted Directory
CWE-548: Exposure of Information Through Directory Listing
Sometimes we just find our customers’ secrets lying around. S3 buckets, indexed webserver directories, public software code repositories, and file shares in classic computer networks are just a few examples of such risky locations. We may need to try a few tricks to find such issues, such as directory traversal attempts. But usually, our standard reconnaissance procedures produce impressive results with little effort.
It is not enough to rely on system design and preventive security controls to deter sensitive information disclosure. Information wants to be free, which in the case of cybersecurity usually means that it will be uncontrollably copied and left unattended in all kinds of places.
To ensure that sensitive data exposure is not happening to you, regularly run asset discovery routines and try to find as much information about yourself as possible. Deploying reconnaissance frameworks like SpiderFoot and Osmedeus may be a starting point.
Broken Access Control
CWE-269: Improper Privilege Management
CWE-284: Improper Access Control
In this edition of the annual report, we decided to group two access control weakness categories into one. These two types of security issues step out as the most common. Insecure Direct Object Reference (IDOR) allows unauthorized attackers or users with insufficient permissions to access sensitive data or features. And overly permissive Access Control Lists (ACL) on sensitive resources enable malicious users to read from or write to risky areas, such as other users’ profiles or software update locations.
Unfortunately, there is no easy way for a non-expert to test for this kind of security vulnerability. Robust access controls may have exceptions made for various reasons along the software development lifecycle and then forgotten. Finding them in modern software applications requires skill, custom automation, and intuition.
To lower these risks, have authorization and access control test cases designed manually and then built into your DevSecOps pipeline, or ensure your QA engineers perform comprehensive permissions testing on all objects and functions under all user roles.
CWE-78: Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’);
CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)
The Holy Grail of application security bugs – OS command and SQL injections – may be possible when the developers do not treat user input from untrusted sources as hostile until proven otherwise. As a result, hackers can disguise their malicious code as data and trick the application into taking an execution path that is not in its owner’s best interest.
The riskiest parts of any application are the intersections of different technologies. It is simply impossible to glue different stuff together seamlessly, and the greater the difference, the higher the chances of something going wrong.
Proper input data validation is one possible way to reduce the risk. But generally, in every area where different application components interface with each other, apply threat modeling for the secure design and point code review of implementation.
CWE-287: Improper Authentication
As authentication and session management is the first line of defense of every application or system, it is the area that attracts the most of hackers’ attention. Last year, we circumvented Multi-Factor Authentication using a mobile device, changed unsuspecting users’ passwords, and performed user account takeover by challenging the assumptions programmers made during software development.
Broken authentication is a vast topic, so we could not fit it into one post. It is wrong to assume it is implemented correctly until a team of experts has thoroughly validated it. Even if the developers could implement secure authentication, they still trade-off its strength and usability. As a result, many web applications, enterprise software, and VPN servers leave room for successful authentication bypass, even if two-factor authentication is in place.
Implementing secure authentication is hard and protecting it with a second factor is not a panacea. Dealing with these risks may vary based on your threat model and user base. For high-privileged accounts, enforce the use of hardware tokens. And pay careful attention to the Single-Sign-On (SSO) implementation.
CWE-326: Inadequate Encryption Strength
CWE-347: Improper Verification of Cryptographic Signature
Weak crypto can mean many things, but in appsec, it is usually not the implementation of crypto algorithms but the way they are integrated into the application software. Last year, we could downgrade or completely circumvent the encryption a few times, but more often, we could decrypt or spoof sensitive data by guessing or brute-forcing encryption and signing keys.
We still encounter incorrect validation of JSON Web Token (JWT) signatures or the lack thereof. It enables token manipulation that may lead to privilege escalation.
Use reputable cryptographic libraries and frameworks reviewed by top industry experts to prevent crypto bugs. Fortunately, unlike software in general, cryptography has a robust peer review and security certification culture. Choose good crypto and follow guidance for its safe use.
Malicious File Upload
CWE-434: Unrestricted Upload of File with Dangerous Type
Hackers love file uploads. But rather not the file upload functionality itself, but the back-end functionality that processes the data. Server-side software does a lot of background work with uploaded files, and sometimes it involves vulnerable third-party components. But more often, we can upload an executable file to a location, where it then can be requested to trigger remote code execution.
Avoiding risks of insecure file upload may be challenging. There is certainly no silver bullet to this problem, as applications use and store files differently. However, few recommendations may prove helpful.
Start with identifying what software pieces process uploaded files. Everything that touches user-supplied data must be up to date and free of known vulnerabilities. Also, think about sandboxing the file processing functionality or delegating it to specialized web services.
Server-Side Request Forgery
CWE-918: Server-Side Request Forgery (SSRF)
SSRF is arguably the most prominent hacking technique because it is a shining example of making the software do the things it was not built to do. Most of the time, manipulating the server to issue a request or establish an internal network connection is not a big deal. But when it turns out that we can read a sensitive configuration, it is usually a game over.
SSRF is a common and exotic bug at the same time. On the one hand, it is trendy to the extent that it has a separate category in the Open Web Application Security Project (OWASP) Top 10 2021 – top 10 vulnerabilities in application security. (E.g., insecure deserialization out, SSRF in.) On the other hand, finding it may require sophisticated infrastructure and tooling.
To find SSRF vulnerabilities in your software, extend the dynamic analysis from straightforward fuzzing techniques to using “canary” payloads that may trick the server into initiating out-of-band backdoor connections. Several tools exist that help you monitor these callbacks via standard network protocols or unique hostname resolutions in a DNS zone under your control. A standalone Burp Collaborator or an Interectsh server might be the two best options.
OWASP Top10 A5:2021 – Security Misconfiguration
Weak or default configuration of security features often leads to successful cyber attacks. Appliances and applications may come with well-known default credentials or without credentials at all.
Misconfiguration is not technically a security bug. Thus it does not have a corresponding Common Weaknesses Enumeration category. On the other hand, OWASP Top10 reserves a separate class for it as insecure settings are pretty common in the wild.
While regulators and even parliaments struggle to enforce secure defaults in IT products, you have to set a unique admin password in your new router during the initial setup. Hardening the device or software is an excellent next step, and the Center for Internet Security provides brilliant benchmarks that help you do so.
Components with Known Vulnerabilities
OWASP Top10 A6:2021 – Vulnerable and Outdated Components
Old and forgotten systems may cause much trouble if the organization does not continuously monitor its environment. Without regular exhaustive scans and inventory checkups, outdated software and firmware start attracting malware and malicious hackers. At the same time, known vulnerabilities in open-source software libraries and other software supply-chain risks may have caused devastating cybersecurity incidents in the past and most probably will cause more in the future.
Automating software updates and integrating dependency security checks into the SDLC might be the best you can do. To ensure your network does not host any systems with known vulnerabilities, perform regular network vulnerability assessments using a general-purpose vulnerability scanner. To protect your applications from vulnerable dependencies, you may go as far as deploy a commercial software composition analysis solution. But we recommend you start with a free tool like OWASP Dependency-Check.
This post is a part of the BSG Business Outcomes and Security Vulnerabilities Report 2021. Get your free copy.