Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Add Insecure Binary category

See original GitHub issue

Let’s consider adding a new category for the purpose of classifying binary oriented security issues. The entry names including the category as well as the structure are up for discussion. The baseline severity ratings are in line with our current policies.

Current “Lack of Binary Hardening” can be converted into “Insecure Binary”: Insecure Binary -> Runtime Instrumentation-Based P5 Insecure Binary -> Lack of Obfuscation P5 Insecure Binary -> Lack of Jailbreak Detection P5 Insecure Binary -> Lack of Exploit Mitigations P5

“Binary Planting” is currently under “Client-Side Injection” and could potentially be relocated like so: Insecure Binary -> Binary Planting -> No Privilege Escalation P5 Insecure Binary -> Binary Planting -> Non-Default Folder Privilege Escalation P5 Insecure Binary -> Binary Planting -> Default Folder Privilege Escalation P3

Considering adding these missing entries (alternatively we could expand on existing categories like RCE or DoS):

Option 1: Insecure Binary -> Local Attack Vector -> Denial-of-Service (DoS) P5 Insecure Binary -> Local Attack Vector -> No Privilege Escalation P5 Insecure Binary -> Local Attack Vector -> Privilege Escalation P3 Insecure Binary -> Limited Attack Vector -> Denial-of-Service (DoS) P4 Insecure Binary -> Limited Attack Vector -> Remote Code Execution (RCE) P2 Insecure Binary -> Unlimited Attack Vector -> Denial-of-Service (DoS) P3 Insecure Binary -> Unlimited Attack Vector -> Remote Code Execution (RCE) P1

Option 2 (alternative structure for the above): Insecure Binary -> Local Privilege Escalation P3 Insecure Binary -> Denial-of-Service (DoS) -> Local Attack Vector P5 Insecure Binary -> Denial-of-Service (DoS) -> Limited Attack Vector P4 Insecure Binary -> Denial-of-Service (DoS) -> Unlimited Attack Vector P3 Insecure Binary -> Remote Code Execution (RCE) -> Limited Attack Vector P2 Insecure Binary -> Remote Code Execution (RCE) -> Unlimited Attack Vector P1

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:9 (3 by maintainers)

github_iconTop GitHub Comments

truemongocommented, Jul 6, 2018

Couple things:

  1. What is a limited attack vector vs unlimited?
  2. Application-level DoS (easy/critical) is currently P2. How do these new DoS ratings fit in with that?
  3. For binaries, often a bug which can be used for RCE is shown in a proof-of-concept as a DoS (for example, for a stack overflow its usually enough to show a crash with PC=0x41414141 to reasonably demonstrate RCE would be achievable, without going through all the trouble of actually making a weaponized exploit). Will it be considered RCE or DoS for VRT purposes?

Finding binary bugs is considerably more work than web bugs. If they’re going to be further devalued or if the bar for proof-of-concepts is raised, I’m afraid they might stop being worth the time investment altogether.

theGmoneycommented, Jul 20, 2018

I’m inclined to agree with Justin here - not to say we don’t want the VRT to be exhaustive as possible, but in my experience of setting up programs, it’s almost always contextual in terms of what the client wants to reward when it comes to binaries. The real problem here, not to drag this off into a very deep and dark hole, is that we need to have more p-levels or weighting based on the target type. While we normally would have a post-auth RCE as a P2, the insanity begins when that same program has a web target that also has stored xss as a P2. We simply don’t have enough options to truly convey the real relative severity of a given finding.

That said, I do want to ensure that a couple points are covered that I’ve seen when running programs that target binaries:

  1. We need to ensure there’s a way to call out RCE that isn’t weaponized. This has been done on my side via offering a % of the total reward amount, downgrading to a P2, or even saying “we get it, that’s enough to prove RCE”. It’s a lot of additional work to weaponize something, despite the vulnerability being present, and it’s something that almost always comes up on these programs. It’s absolutely a P1, and I feel dirty marking something like that as a P2, but then what are we to do with a weaponized P1? Give it the same reward as the one that wasn’t weaponized? And so on. Again, this is why trying to build it into the VRT (at this time) may only hurt binary hunters. They’re rare enough as is - I prefer we not do that 😃

  2. The limited vector bit is, once again, extra contextual. If it’s just “post-auth” I get that (though, what if the app is also vulnerable to CSRF, what then? Does it become a P1?). And what about a limited vector that requires one to plug in a USB stick to a device? For clients where that’s possible, that’s absolutely a P1, and I don’t want to encourage anyone to call that a P2. Once more, putting it on the same page as something like stored XSS seems impractical and even insulting (not to denigrate stored XSS, but I think we’re all aware enough to know that it shouldn’t be on the same plane/priority as code execution). Again, it unfortunately comes back to context.

  3. This same concept applies to the attack scenario and threat model of any given client and what their application is used for - some don’t care about LPE, others do. For some (e.g. AV/endpoint apps), being able to DoS their service remotely is a critical issue - if you can stop their app from doing its job, that’s a big deal, and often a P1 to them, etc - but so is RCE, and so is LPE, and so on. Once more, it comes back to context - and as much as I really, really, really want to stop doing custom things on programs, I also recognize that it’s likely for the best that we not add these, at least for now, until we’re able to have a better way of distinguishing based on the target type, etc.

Happy to hear thoughts, etc. Thanks!

Read more comments on GitHub >

github_iconTop Results From Across the Web

M10: Lack of Binary Protections | OWASP Foundation
The mobile app must be able to detect at runtime that code has been added or changed from what it knows about its...
Read more >
Deserialization risks in use of BinaryFormatter and related types
BinaryFormatter is insecure and can't be made secure. Deserialization vulnerabilities. Deserialization vulnerabilities are a threat category ...
Read more >
Insecure Registry Permissions - Penetration Testing Lab
In Windows environments when a service is registered with the system a new key is created in the registry which contains the binary...
Read more >
Insecure Deserialization - InfoSec Institute
This module covers best practices for serialization - the process of turning data objects into binary streams of data. Categories.
Read more >
Bugcrowd's Vulnerability Rating Taxonomy
Technical severity ▽ VRT category Specific vulnerability name P1 Server Security Misconfiguration Using Default Credentials P1 Server‑Side Injection File Inclusion P1 Server‑Side Injection Remote Code Execution...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found