Critical Vulnerabilities We Had Found in 2019

Berezha Security is a rather small offensive security consultancy focused on high-quality results and long-term partnerships with every client. However, we find a lot of bugs, too, so we try to keep you up to date with what we find. Last year we listed Top-5 flaws that have let us into the clients’ infrastructure.

This year we have decided to publish all the bugs that made us stop all pentesting activities, report the findings, and work with the clients to fix them as soon as possible. We rate these kinds of bugs as Critical and deem them as all-stop events, the same way we treat finding an “incident in action” or obtaining access to large amounts of highly-sensitive data. So the bugs that made us freeze in 2019 are.

1. Authentication Bypass

Auth bypass means that it was possible to circumvent the authentication altogether.

Authentication is your application’s first line of defense that protects its functionality and data from basically anyone on the internet. And yes, it is often implemented inconsistently. As a result, attackers could find a way to avoid the burden of providing your app username and password and wreak havoc in an entirely unaccounted manner.

Fixing auth bypass usually narrows down to using a well-written, trustworthy third-party authentication component that has been reviewed and tested over time by many security-savvy professionals.

2. Default Password

Sysadmins love default or “standard” passwords. I was an admin once; I know what I’m talking about. Unfortunately, we’ve been through enough pentests to know them all.

Of course, I’m kidding; we don’t remember them all. However, we know the dark places of the internet that list them all. And once we found a password that looks like a “universal” one, we stuff it in each form we have already seen, and each form we find from now on.

Fixing this poor configuration practice is not an easy task since because these passwords are ubiquitous, you never know all the places where they are used.

3. Insecure Direct Object References (IDOR)

It may sound funny to the knowledgeable reader, but yes: id++ is still a thing.

IDOR happens in all sorts of places when you could tweak a request parameter and end up reading (or updating) other users’ data. However, we call an IDOR critical only when we can do it without any authorization. So you can imagine how many other authenticated IDORs did not make this list.

Fixing IDORs is pretty simple in theory: make sure your sessions are valid and mapped to the data and functionality requested by the client. In practice, it is much, much more complicated.

4. Insecure File Upload

Files are dangerous: they can be executable, they can be parsable by unsafe code, and they can contain malicious data. So once you design your app to accept files from the client-side, your attack surface implodes.

And hackers just love uploading files! Once the right data is in the right place, all that’s left to do is trigger its processing. Or – which is way more effective – manipulating an admin user to execute it.

Fixing unsafe file upload can be tricky, but isolating all file-processing functionality in an external garbage container that lives only for a few seconds is usually a good start.

5. Password Hash Disclosure

Password hashes are useful when done right. Passwords should not be stored in clear text anywhere in the system; that is why we have hashes around. 

Hashes, in turn, have to be well protected just because once the hackers get them, the only thing required to recover the clear text passwords is time. That is why weak hash disclosure is almost equivalent to password disclosure: a few bucks spent on a GPU instance on AWS do all the heavy lifting of password recovery.

Fixing this kind of issue can be tricky. Still, long before that, at the early stages of application engineering, all passwords should be hashed by so-called “slow” hashing algorithms that prevent fast recovery attacks against the hashed data.

6. Remote Code Execution

This one comes in many forms, and last year we saw like a dozen of those. 

Of course, the XML External Entity (XXE) as a first step is still around: reading the file with user credentials, and the rest is history. Certainly, ImageTragick is still a thing, and it is easy to find if you know where to look. Various OS-level and network service bugs were present, no surprise here. What was new, though, is the use of highly-sensitive functionality along with the server-side template parsing. So the Server-Side Template Injection bug that could allow smuggling a Remote Code Execution to the back-end server was an entertaining issue to observe.

Fixing RCEs depends on the root cause of them happening. It is often not apparent at first glance what is causing the vulnerability and where to find it in the code. However, the devastating impact of RCE gives developers enough incentive to do all the analysis and come up with patches.

7. Stored Cross-Site Scripting (XSS)

Well, no surprises here. We found many XSS bugs; some of them were critical.

It means attackers could get access to highly privileged user accounts by merely planting the XSS payloads in various locations in the web application. User-to-admin XSS bugs are a big deal, so we can’t avoid mentioning them here.

Fixing this kind of bug could depend on the actual web application functionality. But in general, everything is simple: avoid letting your regular users and your admins share the same application functionality.

8. Unauthenticated Password Change

There is no way to explain how it happens, but it does, and more than once a year. There were a couple of occasions when it was possible to abuse the app logic and reset the user password.

The ways to fix this depending on the context. However, it is always a good idea to follow strict transaction-based logic while implementing security features, such as login and password change, password reset or turning the two-factor authentication on and off.

These are the flaws that we considered critical, and that made us stop the security assessments and jump into helping to fix them. All of these are highly risky and required from attackers little or no specialized knowledge to find and exploit. How come we saw them before the bad guys did? The thing is, we often do not: some clients are learning the truth the hard way. But when we are lucky to do a security assessment before the malicious hackers target the client, the key is to know where to look and to apply the bug hunter’s mindset for the first few days of the project.

If you are interested in testing your application security against our skills, you know where to find us.

Leave a Comment