itm4n / PrivescCheck

Privilege Escalation Enumeration Script for Windows
BSD 3-Clause "New" or "Revised" License
2.91k stars 422 forks source link

Report Improvement Suggestion #46

Closed deeexcee-io closed 1 year ago

deeexcee-io commented 1 year ago

Hi,

First off, love this script. I use it multiple times during my Pen Tests. Also love your blogs and research.

The HTML Report - The DLL hijacking Section doesn't have a severity even when the DLLs are missing. I thought this might be due to the fact that maybe the SYSTEM %PATH% folder check came back as compliant = true hence what else are you going to do with some missing DLLs.

When re assessing my HTML reports I found that even though the script highlighted that I could write to a SYSTEM %PATH%, the DLL section was still marked as complaint = true with no severity. I feel it could be beneficial to have the DLL section highlighted with a severity if the first condition is met.

Thanks

itm4n commented 1 year ago

Hi,

Firs of all, thank you for your kind words, I appreciate. :)

I have to admit, there is lot of misunderstanding around the combo "Vulnerable PATH folders" / "Hijackable DLLs". I got a lot of different feedbacks about this, especially people thinking that "Hijackable DLLs" is a vulnerability.

Here is the thing. Whenever a vulnerable PATH folder is identified, I thought that giving a list of DLLs that can actually be hijacked was a smart thing to do. It would not have been possible to merge this with the "Vulnerable PATH folders" check without creating a mess though. So, I decided to create a separate "Info" check for this. However, because of the way the tool is designed, it is not possible to make any correlation between two (or more) checks without some dirty hacks, which I do not want to resort to to preserve overall maintainability.

The problem here is that, for "Info" checks, I assumed that the result was compliant by default and, only if a non-compliant result was found, I set the overall "compliance" to "false", which only makes sense if a check is supposed to yield a compliant / non-compliant result.

The "Hijackable DLLs" check is a perfect counter-example in this regard. It does not make sense to report a compliance level in this case. This check exists for the sole purpose of helping pentesters to quickly see how they can exploit a vulnerable PATH folder.

So now, I handle this differently. If no object is returned, or if the returned objects do not have a compliance level, I set the overall compliance to "N/A". To do this, I had to change the type of the "Compliance" attribute from a Boolean to a String in order to support 3 possible values: "True", "False", and "N/A".

What matters the most in this case, in regards to "compliance", is to know whether there are vulnerable PATH folders. Therefore, for "Hijackable" DLLs, the "compliance" status is now set to "N/A". This should improve the overall readability of the reports (not just the HTML one).

deeexcee-io commented 1 year ago

Hi,

Those changes sound great, appreciate your swift response and updates. Look forward to using this script again during the next engagement.

Thanks

πŸ’ͺπŸΌπŸ‘ŒπŸΌπŸ˜Ž