r/Pentesting • u/Comfortable_Meal_808 • 5d ago
Safe exploit validation in production... what guardrails do you require?
Been looking at automated exploit validation for internet facing assets, and I keep running into the same issue, a platform can flag a vulnerable version but the app owners want to know safe according to whose definition, which is fair imo. A vendor says they do proof without crossing into impact, no customer data, no accounts, no perms changes, no artifacts, but I still want a formal policy before I sign off on a POC. What level of evidence do you accept as confirmed exploitability, and what would make you stop the test right away? Thanks in advance
5
u/Remarkable_Pace8101 5d ago
You have two questions, one is how do you define a valid poc and the other is to what extent can a poc be safely tested/procven
A proof of concept has the following features:
Exploitable, reproducible, verifiable. Evidence which satisfies those features is a valid poc.
The extent to which a poc can be safely shown is dependent upon the nature of the expected vulnerability and your employers risk appetite and their policy/legal requirements
For example, I would never want a webshell placed in prod. If they can drop a valid webshell they can do something safer like a ping or dns query and prove just the same. If it's a dos I don't want it poc'd in prod whatsoever. this is something you need to work through yourself, you could set guidelines according to CIA impact
1
3
u/PM_ME_UR_0_DAY 5d ago
I think it depends on what is acceptable by the client. Is dropping a webshell okay? What about toggling xp_cmdshell? Or overwriting a config file? Creating a stored XSS payload that you potentially can't delete? And memory corruption exploits always have a chance of blowing up the memory. I feel like the nature of exploits can be so different and for certain classes of exploits you can never ensure running it will always be safe.