3

more of a philosophical question, suppose there is one behavior which allows an attacker to do something with high impact but by itself cannot be used to cause that impact. For example, internet accessible admin portal which even though still requires authentication, it doesn't have IP whitelist nor 2FA.

Suppose that using the admin portal, an attacker can upload a shell and compromise the whole server.

Would you classify just having relaxed controls on the admin portal authentication as vulnerability?

If yes, what would you say just would you say is the CVSS score?

The risk? I guess here, the impact is high but the likelihood would be in relation to how easy is for someone to acquire valid credentials, which in most cases should be very low)

I would say it's not vulnerability since one needs valid credentials to actually be able to use the portal. But i hear people having a lot of different opinions so i would like to see some other people's thoughts.

It's similar to having a gun (admin portal) without bullets (credentials). It's only dangerous if you somehow manage to get bullets.

1

It's an interesting question, and I'm not sure I can answer correctly. But here are my thoughts anyway.

It can't be a vulnerability. A vulnerability is something that can be exploited, and if it can't be exploited it can't be a vulnerability. The lack of an IP whitelist isn't something that can be exploited, if authentication requires a strong password.

It is probably a weakness. A weakness is something that is technically wrong or imperfect, and that in some cases might lead to a vulnerability (but not necessarily). So why should you let random IPs connect to the admin panel, if you are sure that only a few specific IPs will ever need to access it? The best, perfect, ideal thing to do would be to use an IP whitelist. So the lack of an IP whitelist would be a kind of weakness. It won't necessarily lead to a vulnerability, but it might. Example: imagine that an attacker steals the admin's password by shoulder-surfing. The attacker goes back to his basement and tries to connect... and if you have an IP whitelist the attacker will fail. But if you don't have the IP whitelist, what was only a weakness then becomes a vulnerability.

Note that CWE (Common Weakness Enumeration) actually includes "use of single-factor authentication" in the list of weaknesses: CWE-308.

So in my opinion, implementing an IP whitelist in this case can be defined as defense in depth, because you are actually protecting from weaknesses, and preventing them from becoming vulnerabilities if something were to go wrong.

| improve this answer | |
0

If the admin portal requires authentication then it is, by definition, not "exposed".

IP filtering or 2FA are additional layers of security and, while they can be helpful, are not always possible or worthwhile. As a result this certainly isn't a vulnerability and a CVSS score is simply not applicable.

Of course it always depends on the use-case. The admin portal for an anonymous cat-picture-voting site is probably perfectly fine without IP filtering or 2FA. The web portal for launching nuclear missles, however, is not (in fact, why does that even have a web portal in the first place!!!).

| improve this answer | |
0

The Risk, Vulnerability, Impact are calculated bit differently.

Usually, weak authentication mechanism is not a vulnerability, but a risk. In the scenario that you've described, the Impact of someone gaining access (qualitative analysis) is critical (catastrophic, severe, etc.). But the occurence is low (obscurity, no known vulnerabilities in the authentication mechanisms (exploits), etc.). The last approach would be a quantitative risk analysis - what in materials and resources you will lose if someone would breach it? Are there card numbers? Accounts access? Cryptocurrency wallets? Business will go down due to reputation loss? If yes, then your risk would be high, if no then medium (however, that depends on what you value most).

| improve this answer | |
0

There are a few flaws with your reasoning.

or example, internet accessible admin portal which even though still requires authentication, it doesn't have IP whitelist nor 2FA.

Consider for a moment why IP whitelisting was ever recommended or why 2FA is being pushed so heavily these days (despite some flaws) if plain authentication is "good enough" to not be a threat. The alternative to plain authentication is nothing, which is not a vulnerability, it's absolute negligence.

I would say it's not vulnerability since one needs valid credentials to actually be able to use the portal.

It's similar to having a gun (admin portal) without bullets (credentials). It's only dangerous if you somehow manage to get bullets.

A gun is only dangerous if it has bullets? That sort of thinking does not instill me with confidence that you should ever own one.

  • An unloaded firearm can still be used to rob the liquor store.
  • Children wielding toy replicas have been killed by police.
  • Many actors have been killed by prop guns loaded with blanks.

Bullets were absent in each of those scenarios. The presence of the gun itself is the threat-- bullets are just an amplifying factor, which is why the courts don't care whether or not you possessed bullets when you commit armed robbery or evasion. All that matters is that a gun--or something that looked like one--was involved in the commission of the crime.

(Possession of bullets becomes more of a consideration in manslaughter/murder cases when assessing intent. Hard to claim someone intended to kill when they were caught with an unloaded firearm. But most computer crimes are about some form of theft.)

Same goes for things like chlorine, ammonia, solvents or gasoline. Just because they only become an immediate danger when combined with each other or a source of ignition does not mean they are "not threats" in isolation.

Nuclear waste is a better analogy. If you're going to produce it, you'd better figure out how to safely handle it-- because the only way it is not a threat is if you don't create it in the first place.

I guess here, the impact is high but the likelihood would be in relation to how easy is for someone to acquire valid credentials, which in most cases should be very low)

This is also naive. Your scenario here is abstract, but in my professional experience--at an enterprise level, where people should know better--I've seen service accounts with passwords in the common 1000 list or are derived from the company name. User accounts are seldom better.

Can you unerringly account for the fact that your sysadmin is not using the same password for his Grindr account as he is for your production systems?

Besides, knowing the credentials themselves isn't always necessary. You said this is a web portal-- hijacking the session(s) of a user with valid credentials would work just as well and be much easier to pull off.

You can't just assume the risk of credential compromise is low because your users are presumed to be intelligent and do everything right. Even when they are, sometimes things happen that are beyond even their knowledge or control.

An admin portal should be accessible only to administrative users from within the network of the administrating entity. How those controls are implemented is an exercise for that entity but in exposing such an endpoint to the public internet, you are inviting a very different user demographic. It is still a threat in both cases, less so in the former, but in the end splitting hairs over whether this is or is not a threat is arguing semantics and distracts from the real issue.

Your admin portal is an endpoint that can be traversed any number of ways to allow god-tier access to your application. Repeat that to yourself a few times until the implications of it sink in. The fact that it exists at all is a threat. The best you can do is lessen how much of a threat it is by putting up as many roadblocks to unauthorized access as you are willing to support.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.