In this post, I'm going to give you an overview of how I approached the process of doing a live penetration test for a client. First though, a little back story is required to understand how this opportunity came along. Over the last few months myself and a friend from University have been working alongside a SME to help them understand the security landscape and threats thats businesses face, as well as helping them to apply some good baseline security measures using the government backed Cyber Essentials scheme.
Having walked the client through the Cyber Essentials scheme, we were able to identify risks and provide mitigation for these risks. Some of these risks included lack of user account management and the failure to apply basic access control and administrative privilege management. After completing the Cyber Essentials questionnaire and doing an internal scan of the network we found that the company, on the whole, had done a pretty good job at securing their IT infrastructure.
However....
During the questionnaire process, it was noted that the company was using a dedicated router with a fixed IP address. The internal network scan revealed no vulnerabilities and when questioned further, the client noted that they weren't entirely sure what version of firmware was installed on the router. At this point, alarm bells started ringing in my head and although we were concluding our time with them, I asked if the they would allow me to investigate further externally, to which they agreed. Before we left for the day we discussed the scope of an external test including the level to which I had permission to investigate.
Get Written Permission
This is a given when doing any sort of penetration testing. It is vital that you have this permission prior to commencing. As the client had never done a test before, I emailed them the following day with further information in regards to what we had previously discussed and clarified the scope. Once they were happy and ready to proceed, I received the written permission needed to commence with the test.
Working within the Scope
In this case, the scope was rather small, investigate the router with the dedicated IP address to check if any vulnerabilities existed, and if they did, determine the criticality and advise on the risk of further exploitation. No further exploitation required!! <-- Its Very important that you fully understand this part of the scope. For me, this meant that the client did not want any further exploitation to take place if a vulnerability was discovered, simply proving there was a vulnerability was enough.
The engagement
"Shit! My first real pentest where do I start ??" was the brief initial thought that went through my head, however within a few minutes of firing up my laptop I was methodically working through the process of enumeration and taking notes. After an hour or so my nmap scans completed and I began working through each of the discovered ports. Not long into this process, I found an interesting externally facing login page. Although this page was not actually for the router itself, I knew from my initial conversations with the client that the router was used by this particular service. So my first port of call was to search online for the default credentials associated with this service. After trying a few combinations and some light brute forcing, access was still denied. At this point, I had forgotten to check if any vulnerabilities or exploits existed for the router itself, the client had provided me with the manufacturer name and model, something I really should have checked first, however this also drew a blank.
Returning back to the login page I noted that it was using the CGI scripting language. Using this information in conjunction with the information gathered from the port scanning phase, it was determined that the router was susceptible to a flaw that allowed me to remotely execute commands on the routers underlying operating system. Using a variety of CURL commands, I was able to interact directly with the router, retrieving information on current user privileges, associated passwords and the configuration settings for the internal network. Noting that the router was running as root, I realized the full severity of the vulnerability. To ensure that the report of my findings would be as detailed as possible, I noted of all my commands and the resulting output.
At this point I was surprised with my discovery, from initially thinking that I wouldn't find anything, I was overwhelmed with excitement that I had completed my first live pentest and actually discovered a vulnerability. With this in mind, my thoughts turned to reporting my findings back to the client.
Reporting
I've heard of reporting being referred to as a 'necessary evil of pentesting'. However I actually found the process of writing up my findings rather enjoyable. Having no previous experience of reporting, I was unsure where to start but two resources immediately sprung out at me, one from OSCP and another from the Sans Institute. I also took the time to ask some seasoned professionals for some hints and tips.
Using a combination of both, I created a short six page report. This included an executive summary in which I reiterated the scope of the engagement, noted the vulnerabilities found and then presented my recommendations for mitigation. I also broke down the methodology used, this included techniques used for both service and port enumeration. I then detailed how I used this information to find the vulnerability before explaining the potential impact of the how this could affect the business. I then provided advice on how the vulnerability could be rectified and provided further information specific to the routers manufacturer setting to update the firmware. I concluded the report by providing a proof of concept section, this included an overview of tools used and the commands for each of these tools. I also included screen shots of the vulnerabilities and the responses received back from the router. Although this report was for a SME, I felt it important that the report cover all bases, ensuring that it could be read and understood by both non technical and technical users.
Final Thoughts
I can honestly say it was a fantastic experience. I was able to drawn upon information learned from my time talking and interacting with seasoned pentesters and also from the tricks and techniques gained during my continuing OSCP training. The reporting process was also an enjoyable experience, it allowed me to reflect on the processes used whilst also allowing me to better understand of the cause of vulnerability and how to protect against it in the future.
Shout outs
Thanks to the following guys for helping me out when I had questions about the reporting and mitigation side of my report - cheers guys.
Rab_Ray
cornerpirate
InfoSecPS
