RSS Security 
The post Top 12 hacker tips to secure your SPA from Crowdsource appeared first on Detectify Labs.
Login
The post Modern PHP Security Part 1: bug classes appeared first on Detectify Labs.
The post How-to Tutorial: PHP Webshell De-Obfuscation appeared first on Detectify Labs.
Just to make it very clear from the start: you should use a password manager. There are not always foolproof, and this blog post will try to discuss some of its flaws, but they are way better than not having one.
This blog post will not cover any technical vulnerability that someone has assigned a CVE. Instead, it is more of a design discussion and some food for thought. With that said, ‘real’ vulnerabilities have been found while writing this, and chances are someone might find some on their own while reading this.
A lot of password managers have an Autofill feature enabled by default, which is a requirement for most of the problems that follow. Some even have Autosubmit, meaning the password manager will even submit the form so the user never has to see it.
Some have it enabled by default, and others who do not likely have it as an option in Settings.
As a general rule, password managers do not seem to discriminate whether it is a subdomain or not. If it is going to autofill your password on `facebook.com` it will do so on `www.facebook.com` or `bob.www.facebook.com` as well.
This is convenient, but potentially leads to a few potential security issues.
There are websites out there where you can put user-generated content on a subdomain. One example is when user-uploaded files end up at cdn.domain.com. Another common example are blog platforms where each user has their own subdomain, such as bob.blogplatform.com. If anyone can register a blog and edit their HTML-theme, they could put up a form harvesting passwords intended for blogplatform.com/dashboard.
How password managers have protected against this varies greatly. Some disabled autofill for subdomains that never have been autofilled before, other use a blacklist of paths/domains that should not be autofilled (this approach obviously does not take into consideration every site), but multiple do not do anything to prevent it.
This attack vector becomes increasingly important when password managers grow in usage, especially if you are building a service that targets people within the tech industry. In most solutions it is possible to disable either subdomains or Autofill in general on a case-by-case basis. Something like this might be worth recommending if you believe a great part of your audience use this.
It is very common for website owners to misconfigure their DNS-records and that can result in an attacker being able to host their own content on your subdomains. Given that password managers will autofill your password, it will also execute this on the attacker controlled page as well.
More information about this attack type can be found here.
Shameless plug, but we also offer a service called Domain Monitoring Service to detect and prevent such attacks.
Even if you users are not supposed to be able to modify the content of subdomains, the same effect would occur if you would have a XSS vulnerability on any subdomain. Is it reasonable that an XSS on bob.whatever.domain.com leaks the password of domain.com?
An interesting thing about this is how some password managers in their bug bounty programs or Responsible Disclosure Policy have set their own subdomains as out-of-scope, meaning they are not interesting in vulnerabilities being reported there. If the password manager provides a web-ui, the user could save their master-password in the password manager, and a XSS on their subdomain would then be able to leak it.
Given that password managers do accept subdomains, it is clear that they do not follow the strict origin check as a web browser would do. Many password managers do not use the browser’s built-in APIs for this but instead write their own checks as well. This opens up for a security issue when the browser and the password manager has not reached consensus regarding origin.
For proof of this being a issue we do not have to go further than our own blog.
Even when it is not as obviously broken as in those blog posts, there are additional minor differences that can be discussed. One of those being the trailing period, `google.com` and `google.com.` is treated as different origin by web browsers but the same for a few password managers. As we have seen before, it can be problematic when variation without the dot but not the one with the dot has been claimed at third-party vendors. Talking with smaller vendors, I have also experienced this not being taken serious, given that the browser actually sees it as different origins (meaning cookies are not shared etc).
Given that you want to share passwords regardless of subdomains, you somehow need to decide what is a subdomain. You must somehow understand that `a.example.com` and `b.example.com` can share passwords, but `not a.co.uk and b.co.uk. In browsers this is done by a list called the Public Suffix List. However, this same list is not implemented by all password managers.
That means that in some cases, you can look in the list if you want an example, anyone using the same public registrator would also share these password. Security aside this seems like a inconvenient bug, so a bit surprising it has not been fixed.
Bitwarden is one of the password managers to offer the ability to write your own regexes to ensure it matches what you want. There does not seem to be any warnings in the actual settings, but the risks of this feature are made clear in the documentation.
The first hit I got when searching for this online was this Reddit-thread on URI Regex Matching Help. If you look at the regex someone suggested, or the initial one provided by the one starting the thread, it is obvious that it would also match https://bob.com/.google.com breaking the whole check. It is easy to imagine such mistake being very common, as we have seen similar issues with regex in other scenarios.
Man in the middle attacks are quite interesting in this context. More and more websites use HTTPS, including the ones that you visit the next time you connect to a malicious WiFi-network at the local coffee shop. So how do password managers affect this all?
The first interesting thing to note is if the password manager autofills your password, it is enough to connect for just a few seconds. Even if you plan to actually browse around the internet with a VPN, in public places you often need to first connect without one to go to some kind of portal and then turn on the VPN. This would be enough time for an attacker to redirect your browser to the interesting website, let the password manager do its job and then steal your login details.
Setting the secure-flag to cookies does not really do much if the victim is using a password manager. Why would we want to steal the session cookie if we could directly steal the password?
HSTS is what normally protects against such attack. However, considering how most password managers treat subdomains we quickly realize that for HSTS to have the desired effect we must also use the includeSubdomains-flag in the HSTS-policy. If that is not set, a malicious part can redirect you to thissubdomaindoesnotexist.example.com and host a website there which steals your password.
To make it worse, several of the popular password managers maintain something called Equivalent Domain list or similar.
If you save a password for `facebook.com` you want it to be available for `messenger.com` as well without having to make another entry for it. These password managers therefore provide a list (often found deep down in settings) on domains that are considered to be equal. Lacking HSTS on your equal domain is as bad as lacking it on your real one here. An XSS on your equivalent domain could also steal passwords from the main website.
Far from a suprise, these lists are not always maintained and the ones on it probably do not even know about it.
We often write about Bug bounties. The password managers that we have found security issues and blogged about (and those not blogged about) happened because they have bug bounty programs in place. Logically, those password managers without bug bounty programs have just as many flaws, but they are not getting reported in the same extent.
I do not have any data to back that up, but personally it is something I take into consideration when picking a password manager. There are other public reports if you want to look on what others have found: https://hackerone.com/reports/435618
I am not saying a bug bounty program would be a guarantee but it would be handled very well for that matter, stories like those are not unique either: https://twitter.com/klikkioy/status/981126623155154944
Similar reasoning goes for password managers that have not had a security audit done. For some interesting discussion around this, I would recommend the Git-issue created before Bitwarden had theirs done: https://github.com/bitwarden/server/issues/27
The actual report from the security audit a few months ago is also very interesting to read: https://cure53.de/pentest-report_bitwarden.pdf
(If this blog post gave you any idea you want to try out, here are a few of the password manager’s public bug bounty programs which will pay you for reporting those issues: Dashlane 1password Lastpass Kaspersky F-secure)
As a user
As a website owner
As a password manager developer
The post Thinking outside of the password manager box appeared first on Detectify Labs.
The post Abuse MITM possible regardless of HTTPS appeared first on Detectify Labs.
The post XSS using quirky implementations of ACME http-01 appeared first on Detectify Labs.
The post The danger of recycled phone numbers appeared first on Detectify Labs.
The post Scratching the surface of host headers in Safari appeared first on Detectify Labs.
