Your PoC glosses over some mitigating measures

[arubislander]

Your PoC video to bruteforce the users pin code glosses over one important factor

1. A pin is not the only way to secure your device. Using a full blown password is also an option
2. Applications on Ubuntu Touch are confined by default. A confined application cannot use sudo.
3. Unconfined applications can use sudo, (unconfined apps can do anything) but they cannot be uploaded to the Open Store without being open source and passing manual review.

A user could always randomly download a malicious click package from somewhere, but even so, the user would need to purposefully install this package.

In closing, why did you not follow the path of responsible disclosure if you felt this was a serious issue warranting a CVE? Dumping the code on GitHub without giving the project time to correct the issue, or decide it is an acceptable risk, is not in accordance with responsible disclosure practices.

[filipkarc]

Thank you for your message. I answer below:

1. The system after installation on the Nexus 6P provides the option of securing the screen by PIN or password. If the system offers PIN - the user has the right to feel secure and think that it is not possible to break it in 2 minutes. This is not any security downgrade on my part.
2. If my PoC works it means that it is possible to create a situation in which the vulnerability is exploited. Even if there are restrictions on the exploitation of the vulnerability - you can still use it with ALL the consequences. Often real attacks involve combining vulnerabilities with each other. Threat actor will find use.
3. You are probably right, but let's focus on the words "passing manual review". All manual reviews are about probability. Software that successfully passes penetration testing, code review and lands in production further has quite often huge vulnerabilities that are reported later in bug bounty programs. So it is possible to exploit the vulnerability.

Regarding responisble disclosure: I published a PoC without reporting a CVE (4.09). I thought naively that it was some individual situation for the old Nexus. It was only when I got messages from users (also confirming on a different model) that I understood the seriousness of the situation and made a CVE request (6.09). I will be more vigilant in the future.

I think many people will share your point of view, but I am looking from the perspective of a penetration tester. The vulnerability exists and under certain conditions it is a hell of a threat.

I hope that in the next version the device PIN will have nothing to do with the password to get root privilege. Otherwise, a malicious actor will come along and write something much more interesting than my PoC.

[arubislander]

Thank you for your answers.

Regarding with your hope for the next version and responsible disclosure, surely the responsible thing to do would have been to contact the developer team even before publishing a PoC? Thinking it to be solely an old Nexus platform specific bug is not really a great excuse, since the thought should have occurred to you that you might be wrong. And in situations like these it is better to err on the side of caution, would you not agree? Now, not only has the CVE been issued, but it is also public, making it all the more likely that a bad actor will try to (though by no means is it obvious that they will succeed in) exploiting this perceived vulnerability, before the devs have had the opportunity to look into this to determine what the best course of action would be (removing the pin option? setting up retry limits? adding a warning when selecting the pin option?).

Have you by now attempted to contact the devs?

[maciek134]

from the perspective of a penetration tester

A pentester would lose his job and any future career prospects for disclosing something this way.

Regarding responisble disclosure: I published a PoC without reporting a CVE (4.09)

Publishing an exploit (or a basic brute-force password cracker, since nothing is actually being exploited here) without contacting the affected project is not even close to responsible disclosure.

[nitanmarcel]

If you're choosing your middle name as your Linux password, is that called a security issue if an app takes your user name and tries combinations based on that? I guess not. Or a better example would be a password of 4 letters, the amount of possible combinations is higher than a 4 PIN code one but it still could be easily bruteforced by your script (with some modifications) on any linux OS where the script can run.

You haven't found a security issue, you've found the obvious which applies anywhere else: A weak password is always insecure and can be bruteforced, phished. And based by your discovery, any OS, web service that allows for such an weak password is insecure. Maybe even banks which have a 4 password PIN and people usually use their birth year or date as the PIN. Great job you're a professional pentatester now 👏👏