SecureState Blog

Read SecureState's award winning blog.

Have you ever had a penetration tester ask permission to execute an attack or perform some other action?  You should have, because we would prefer to do that rather than just try that “risky” exploit or make the configuration change.  To be clear, most penetration testers don’t go rogue.  If the company that does your assessments is doing these types of actions without checking with you first, it’s time to reconsider who you are contracting for your assessments.

 

That being said, there is great importance in allowing the penetration tester to conduct the assessment to the fullest of their abilities.  As an example, during a recent External Penetration Test, I was able to gain administrative access to a web server through default credentials.  Part of the functionality of the application was to upload files. These files were intended to be documents, but I was easily able to upload a file that contained java code that would run on the server. When browsing to this Java Server Page (JSP), system commands could be executed much like if you were logged in to the server and had a command prompt.  Much to my chagrin though, when I browsed to my JSP shell it would not load.  While I continued to examine the application I discovered an administrative option to enable JSP execution. I quickly enabled this option and was notified that the web server would need to be restarted before the changes would take effect; I was then presented with the option to restart the server.

I’d be lying if I said I wasn’t tempted.  However, as a responsible consultant I asked for a call to be organized with the client to discuss the situation.  During the call I explained to the client how I had arrived at this point. I also explained that this restart was something I was capable of doing from the outside given that the application used default credentials, and that a malicious attacker would be able to perform the same actions.  Finally, I explained that only the web server needed to be restarted and not the entire system.  In this situation the client was eager to help and they contacted the person who was in charge of the system in question and discussed the potential business impacts of a web server restart.  It was decided that the few seconds of downtime would not have an adverse impact on the business, and I was given the green light to continue my assessment.

While this outcome was favorable for me, it could have gone the opposite way.  The client could have easily decided that they couldn’t afford the downtime, that demonstrating administrative control of the web server was enough, or that the IP address was not within the scope of the engagement any longer.  All of these scenarios have played out before and each time the client is cheating themselves out of a quality assessment.  In a situation where the server is absolutely “mission critical” and a reboot is out of the question, another option would be for the client to run an executable on the server which would create a reverse connection back to the consultant’s system.  This would provide the same level of access as if the reboot had occurred and the web shell had been deployed, without impacting the uptime of the server.  Obviously, an attacker is not going to call you before compromising a server to ask for permission.  The takeaway here is this: It is important that the penetration tester be allowed to take the actions necessary to provide the most value possible. 

One of the main reasons to conduct a penetration test is to “know what you don’t know”.  In the case of my assessment everyone involved learned something.  I learned the actions necessary to compromise this particular web server, and the client learned that their egress filtering and network segmentation were configured properly and had protected additional systems from being compromised.   Ultimately, if you don’t let the penetration tester do their job, you’ll walk away not “knowing what you don’t know”, and you’ll be no better off than when you started.