Are security flaws acceptable if not much harm can derive from them?

Question

Recently, I have discovered a security flaw in a business website. This website has a password-protected "Partners Area", and like many websites it provides a form to reset the user's password.

When a user asks for a password reset for his nickname, a new password is sent to their email address and that password becomes immediately effective. The problem is (if this wasn't already a problem) that the new password is a fixed one, for all users. So an attacker can easily get access to any account.

Now, the only operations a user can do within their Partners Area are:

• View/change email address
• Change password
• Download some manuals and utilities (it's definitely not classified stuff)
• Fill out a repair form (then the process will continue by email)
• Download logos and images for marketing purposes

The only things I see for a malicious attacker to exploit are:

• Prevent future access to a legitimate user (which will probably be able to reobtain right after a phone call)
• Discover information about who the company customers are (guessing random nicknames and looking at their email address). Anyway, it's not something someone would keep as a secret.

Even if I am always very disturbed by things like this, in this case I must admit that it might not be a big deal. Are flaws like this acceptable compromises, in a context where not much harm can be caused?

---

Since I think someone misunderstood a detail: that website belongs to an external company. I have no role in the development of that website, and no control over any decision about it.

Answer 1

Your question is: Are security flaws acceptable if no much harm can derive from them?

The answer is yes, if decided by business while understanding the consequences.

What you are doing is called a risk assessment. For each risk you must highlight the consequences for your company when it is instantiated. Based on that assessment you (you = someone who has the power to make the business decision) have three choices:

• you can accept it - by assuming that the costs of fixing it are not worth the consequences
• you can mitigate it: fix it to the point where you can accept the consequences
• you can insure against it - effectively offloading the risk to someone else.

As you can imagine, there are several hot areas in a risk assessment.

The first one is the assessment of the consequences and the probability. There are numerous books and articles about how to do that, at the end of the day this is based on vigorous hand waving and experience. The output is never like the one in the books

we have a 76% probability of this happening, which will cost us 126,653 €

but rather

well, I feel that this is a risk we should take care of

Note that the "consequences" part may sometimes be quantifiable (loss of profit for online commerce for instance) but usually are not (loss of image for your company for instance).

Beside the dubious theoretical aspects of risk assessments there is one huge advantage you should always take advantage of: you put a risk on the table and it must be dealt with somehow.

This is not only a place-where-the-back-loses-its-noble-name--coverer, it is the right tool to highlight where information security efforts should go to. It also raises your visibility (there are not so many proactive cases where you can raise your visibility) and forces you to take a hard, deep, pragmatic look on what is important and what is not.

Answer 2

Yes. This is a problem - a big problem. Lately I found a design flaw in a business' webshop that allowed me to insert innocent notes in other visitors' charts.

Seems innocent, and only annoying, until I looked further and found that I was also able to insert Javascript code (XSS) into those notes. So in other words, I could exploit XSS on every visitor's chart. I made a quick PoC showing them how I could easily hack the computer of any visitor (in this case myself, it was a PoC) using that design flaw, XSS, BeEF, and Metasploit.

So even the smallest flaw may result in a big risk after all.

Besides that, who says that the error you found is the only one the developer of that website made? Maybe he also made tons of other mistakes.

Reporting would be the best you could do - even if it looks unnecessary.

Answer 3

The problem that I see with such a simple password reset scheme is that it suggests further vulnerabilities in the platform. A flawed concept of security is rarely so isolated as to only happen once, since such flaws are usually related to a developer's practices regarding security. At minimum, I'd suspect that their internal login procedures might also be susceptible to the same flaw, potentially allowing attackers to access databases, code, and processes they shouldn't normally have access to.

From there, it might be possible to modify the server's code to report cleartext passwords, or glean additional private information, and possibly allow attacks on further systems. After all, even though this is 2016, there are still many people out there that still use the same password for their bank accounts as they Facebook, despite the obvious risks associated with doing so. Even if not, being able to associate a nickname with an email address might put other accounts the user has at risk as well; the more information an attacker knows about a user account, the more they can leverage trying to subvert other accounts owned by the same person.

At minimum, I'd suggest you contact the site owner and see if they'll fix the problem, and if not, consider not using their application unless absolutely vital. I'd also recommend changing your email on the user account to a throw-away account that's not connected to an email address that you care about. We're no longer in an age where we can assume apparently minor flaws won't come back to haunt us later.

Answer 4

If I see this scenario right, they can change E-Mail address and password of any account, then start a repair-form and continue the repair-process via mail.

The support team will probably assume that the E-Mail address is legit and sensitive information can be exchanged with the recipient - and if it is a know customer, you might even start working on an order received via the website/mail.

Another problem could be if you can access a contact history or history of your repair orders? Maybe a customer has written confidential information into his repair orders, or even the number and type of order is something which could reveal problems in his business?

Another problem could be a massive spamming of customer-mail addresses. If I invoke your password reset a million times, it will send a million Mails to your users, not only filling their inbox, but also landing you on several spam-filter lists... where it can be quite a hassle to get your server removed from these lists afterwards.

DoS is of course very easy, if I just have to enumerate nicknames and can reset all account passwords.

But the biggest problem is a false sense of security

It could be we are overlooking some angle or problem which exists right now. But even if there isn't any problem now - What if someone decides to implement a new functionality into this page next year? Maybe for customers to order/pay online. - You provide a context which is only accessible with username and password and people and developers will rely on that. Everyone will think "this is a secure part of the application which can only be accessed by customers so I can do X and rely on Y"

If an application is practically public accessible, it should look like it is. If the application looks secure, it should be secure!

Answer 5

There's two perspectives here:

• As a user, yeah, I'd be concerned, I'd let the owner know, and I'd refrain from sharing any sensitive information on that site.
• As the site owner/developer, it's your responsibility to evaluate whether any potential security risk is serious enough to warrant effort. Not every risk is going to be severe enough to justify action, judged by likelihood of occurrence, impact of a breach, and effort required to control the risk.

In this case, you've got (at a guess):

• severity: low
• likelihood: moderate
• effort: low

and so they probably should do something about it; there's a very good chance that they're just unaware of the problem.

In the general case, in response to your question "Are security flaws acceptable if no much harm can derive from them?" - yes, they can be. You need to determine if the severity/likelihood/effort tradeoff makes it worthwhile to fix a problem. 'Accept the risk' is a perfectly reasonable response in many cases.

---

As an extreme example, "aliens who can break strong crypto visit Earth" is a risk that my business faces. I choose not to control that risk as the likelihood of it occurring is so low that it's not worthwhile.

Answer 6

This is a good question and not easy to answer.

Every security risk is just that, a risk. And addressing that risk needs to weigh cost, confusion, and dangers of the risk, against the proposed fix.

Looking at your specific question, you have a "private" part of the site, that has some information on it, but no real harm can come from someone accessing that part of the site. Your security hole also requires that the hacker would have to know that every password is reset to the same thing, and what that thing is.

So right now, today, your largest Risk is nothing or at least low.

Tomorrow your largest risk is that the private section may have confidential information.

The cost to "fix" seems pretty small. Specially if your already mailing out the new "fixed" password. Essentially, just change the password assignment to a random one and the issue is "fixed" for now. It may not be the best but it is better.

So, you have a low cost to fix, but a low danger security risk. You need to weigh that against business needs and determine if it's worth it.

Keep in mind that the business may count on that fixed password. For example the support staff may have been trained to reset the password then tell the user on the phone the new password, and stay with them till they can get in, then help them change it. You need to account for this when figuring out costs.

What I do:

When I find a bug or security issue I document it, and estimate a development cost to fix. Then I add it to a list, and let the right people know. It may never be taken off that list, but once a year (or every 6 months) I review that list with the site owners, and address the issues that I can.

With this risk, it would likely not be fixed very quickly. I could see a lot of business needs coming first, and that's ok. But at least it's documented, and when someone tells me they want to put "secret" information in that part of the site, I can tell them about the risk.

It's also important to note that this type of risk is likely to lead to other types of risks. When this was coded a bad security decision was made. The site should be checked for other bad decisions.

Answer 7

Remember that as the developer, you might have a better idea of the actual security risks than a user might. If a user discovers their account is hijacked, they might assume that the unauthorized user might have accessed more information than what they are actually able to. Even if no sensitive information is actually exposed, your company may still take a reputation hit.

Also consider the fact that you might not know what information is harmless to be leaked. For example, what if the user has a new revolutionary manufacturing process that a competing company is trying to figure out? If a special piece of equipment used in the new process needs to be repaired and their email is changed, the repair order might give the other company an idea of what their new process is.

Its sounds like a simple fix, and ultimately you are going to have to make that assessment to see if the risk is worth the cost of fixing it.

Answer 8

Impersonating a legitimate user from a customer (who is treated as trusted to some extent) is a good way to start a social-engineering-based attack.

A repair form -> email process is ideal for this given that you control the email address. Perhaps you could buy a similar domain and change the email address "[email protected]"->"[email protected]", which fits nicely with "I've just transferred to our Canadian subsididary so I don't have my records, could you remind me...?"

If you can gain a little information on the customer/supplier history you can further impersonate the supplier to the customer. Often this is as simple as asking "What was the name of the service engineer who visited a few months ago? They were apparently very helpful on a specific issue but I was out and my colleague dealt with them"

Answer 9

Nope, if user get access to that site, he will be able to access the email of someone by using his nickname wich is confidential data, in some countries this is enough to force you to NOTIFY ALL USERS that someone was able to penetrate the DB and that there was a information leak. This damage both credibility and open to lawsuits.

So in general, security flaws are acceptable, but this might not be an acceptable security flaw. Also this open to all kind of spam your users wich could suddendly start to receive malware and spam via email.

Hackers are always creative to put to good (for them) use the flaws they found. You assume the users identity is not a crucial information, but it could be if it is in example a cheating website. Also, what if one user was actively promoting against a sect/cult and suddendly cults member can find out his identity? What if someone victim of stalking is disclosed and thanks to that the stalker is able to find him again?

Leaking identity without warning users is privacy violation, so be carefull. Flaws should be fixed and risk-analyzed as soon as they are found.

In example I would prefer all my forum posts got deleted than allowing someone access to my email address.

Answer 10

It depends, I'll point to the extreme scenarios.

Scenario A - don't worry! From what you're saying, there's not much true concern about the data available. If it may have just as well been public and the whole security setup is just a marketing/loyalty scheme, then there's not too much to care about. It may explain the sloppy procedure as well, if it was done by someone who didn't have the expertise, just for the sake of it. As long as that person does their usual jobs well it should be fine.

Scenario B - worry! If this is just a hint about how things go in some parts of the organisation, then it's possible that you may find a helluva even worse security holes. If the server is vital for the business, first consider checking that proper backups are in place and then start a thorough audit.

Then of course there's the rest of the alphabet.