Our potential clients often ask us: What can we expect from you? How many security vulnerabilities will be in your report? What will be their risk levels? This post sheds the light on these questions.
We share more information about our team’s productivity in the upcoming BSG Business Outcomes and Security Vulnerabilities Report 2021. Here, we briefly highlight the most valuable points.
This post summarizes the metadata of all our 2021’s security vulnerability assessment reports and highlights the two most notorious attack scenarios. The following post will delve deeper into the specifics of security vulnerabilities we report and our recommendations. Our customers can use this data to benchmark their pentest results against other companies. But first, the figures.
Summary of Findings
In 2021, the BSG team found 515 security vulnerabilities in our customers’ applications, networks, systems, and organizational processes. In 2020 we discovered 322 vulnerabilities.
28 vulnerabilities were critical and demanded immediate attention. We reported them to our clients immediately, so they did not have to wait until the project ended, could fix the critical vulnerabilities, and get the remediation tested right away.
For the rest of the findings: 63 were high-risk, 112 were medium-risk, 312 were low-risk.
Average Findings per Report
Note to existing clients: take your latest BSG pentest report and use this data to compare your results with other customers.
The average number of security vulnerabilities we report in a cyber security vulnerability assessment or a penetration test increased to 8.31 in 2021 compared to 7.66 in 2020.
The number of Critical security vulnerabilities has surprisingly remained the same as last year: 0.45 per project on average. The number of High-risk issues grew to 1.02 in 2021 from 0.76 in 2020. These figures are only logical because the maturity of our team has grown significantly during 2021.
On the other hand, the number of Medium-risk findings decreased more than twice from 4.10 in 2020 to 1.81 in 2021. Similarly, the number of Low-risk issues increased to 5.03 in 2021 compared to 2.36 in 2020.
Notorious Attack Scenarios
BSG conducts tens of application and infrastructure pentests throughout the year. Every project is challenging and educational for our clients and us in its own way.
The BSG team learns new techniques that land in our Standard Operational Procedures for the projects to come. Our clients realize that no cyber defenses are impenetrable and what they can do to raise the bar.
Here, we share two successful attack narratives from our projects in 2021. Although these are not the most sophisticated attacks we successfully modeled last year, they give a lot of information about how we operate and what the issues we find may look like.
Circumventing 2FA via Social Engineering
Many IT and cyber security professionals genuinely believe that Multi-Factor Authentication is a panacea against phishing attacks. Unfortunately, that is not the case. Partly because not all second factors are created equal.
In our social engineering activities, we usually hit the target right on the spot. 2FA is a general practice nowadays, as implementing a One-Time Password (OTP) requires little effort. It is strongly recommended to enable it on all accounts and enforce it for privileged users and remote access services, such as critical SaaS applications and corporate VPN servers.
Enabling an OTP makes it harder to carry out a successful phishing attack. However, it is still practical with a little more preparation.
One reason is that OTP is not truly a second authentication factor. Technically, it is still “something you know.” And the fact that you use two different passwords does not fully count.
But wait, isn’t an OTP generated by a software token app, such as Google Authenticator, a natural second factor? After all, the app sits on my smartphone, and the smartphone is “something I have.”
Well, not exactly. As with any convenient security tool, its design has a usability trade-off. The one-time passwords it generates are not really one-time. They remain valid for a tolerance window of 20 seconds to a minute, and in many authentication mechanisms, they can be used a few times during that period.
Using this nuance to circumvent two-factor authentication is not easy but feasible with modern tools and well-prepared infrastructure. With an average 4% success rate of users entering their login, password, and OTP, we could successfully use the credentials to automatically enroll a device for VPN access and penetrate the corporate network. With SaaS applications, it was even easier.
Taking Over a Web Application User Account
User account takeover is one of the most severe application security vulnerabilities. Usually caused by poor session management, broken authentication, or broken access control, it allows attackers to hijack another user’s account. Sometimes, though, user account takeover results from the insecure implementation of OAuth.
Very similar to cryptography, OAuth is hard to implement securely, which is why you must not even try. Instead, you must use existing OAuth implementations proven trustworthy by numerous credible security researchers.
Unfortunately, few developers follow this rule to the letter. They modify authentication and authorization mechanisms in search of more optimal app productivity. In this way, unexpected security flaws arise that could cause severe vulnerabilities.
In one engagement, where developers made such an amendment to the OAuth workflow, we could completely circumvent the authentication mechanism and steal any user account. Most surprisingly, we did not even have to create an account of our own to mount this attack.
The vulnerability was in how the application identified users before the authentication started. The application used mobile phone numbers as primary user identifiers. Aside from this design decision’s inherent security flaws, the usual authentication via phone number + password or phone number + OTP via SMS worked fine.
The trouble started when users logged in using an external OAuth provider, such as an email service or social network. The problem was that the users still provided a phone number as a primary ID during the external OAuth authentication flow.
As a result, we could achieve successful authentication as virtually any user by providing their phone number and then authenticating under an arbitrary social media account.
This post is a part of the BSG Business Outcomes and Security Vulnerabilities Report 2021. Get your free copy.