This topic contains 1 reply, has 2 voices, and was last updated by IUsedToBeACave 1 month, 4 weeks ago.
- April 8, 2020 at 6:13 pm #232260
Imagine doing a pentest, finding a vulnerability, exploitation and accidentally break the company’s stuff, like deleting an internal file, or dropping a table
What do you do to avoid this type of stuff?
- April 8, 2020 at 6:13 pm #232261
You just don’t break stuff. There are no magic tricks, you either know what you are doing or you don’t.
Normally if you find an actual exploit, you don’t exploit it. You log that it could be a problem. If you need to do some type of proof of concept, you create an analog system you control that is configured in the same way as the vulnerable system. If the client asks you to actually attempt to exploit the system, then make sure you warn them of the consequences of doing so and then go for it. Eternal Blue is a good example, if you find a server that is vulnerable just let the client know. If the client asks you to exploit it anyway explain that the exploit is unstable it in some cases using it will cause the system to crash. As long as they are OK with that then you can go ahead.
- April 8, 2020 at 6:13 pm #232262
You avoid breaking things by knowing what you’re doing. You’re a professional for a reason, not a skid
- April 8, 2020 at 6:13 pm #232263
People who are good in this job don’t just break stuff, and those who are junior or are just starting are not just set loose in the clients environment to wreak havoc as they please. It’s not like you just try out different exploits without understanding what the possible risks are. It’s you job to evaluate what your impact could be.
If you ever find a vulnerability in a pentest, and are not sure if exploitation could cause harm, you can still report the vulnerability without actually demo’ing it in a real world environment.
You can still obviously setup a test environment that is as close to the real world scenario as possible and record a demo there for the client to see. In general you are not paid to just mindlessly break stuff because it can be broken, you are paid to consult the client and improve their Security.
- April 8, 2020 at 6:13 pm #232264
Simply put, you need to know what your doing before doing it.. Research the vulnerability, know how it impacts the system, maybe even test it in a lab first of your not sure..
Nothing is ever guaranteed. Be cautious.
- April 8, 2020 at 6:13 pm #232265
In general you have to know what you are doing and test things in none destructive ways. You don’t need to drop a table to test SQL injection. Be careful, usually with clients you have terms written out in advance that says what you can and can’t do. Although it is rare accidents do happen, maybe you touch some piece of data you shouldn’t have or you knock something down. In that case you need to contact your client immediately and be honest.
- April 8, 2020 at 6:13 pm #232266
You usually have a certain expectation of the effects that a weakness has and you would approach cautiously. But it is always a possibility that things break in an unexpected manner. That’s why you prepare your client, ask them if they have recent backups.
Better yet, don’t test productive instances. It’s far less problematic if you break the development instance. Encourage your client to provide access to some testing environment where you can wreak havoc without second thoughts.
- April 8, 2020 at 6:13 pm #232267
It’s pretty hard to accidentally drop a table
- April 8, 2020 at 6:13 pm #232268
While doing a Penetration Test on the Companies software you are looking for actual Bugs that you can then write down on your notes with a POC (Proof of Concept) without Exploiting t in a way that could cause harm after finishing Pentesting the rest of the Application you report back to whoever hired you and if they tell you to actually exploit it that’s when you do it. You do not just break stuff you need to know what you are doing! You can not just go in and break everything that’s not the Professional way of Penetration Testing
- April 8, 2020 at 6:13 pm #232269
Use a sandbox
You must be logged in to reply to this topic.