About one year ago, I spoke with some application developers about a recent penetration test. They told me they had received an internal memo with a list of vulnerabilities - just the names - categorized by severity. If you've never seen a penetration report yourself, you should know the report contains so much more than just a list of problems. The report provides evidence, context, descriptions, notes from the tester, and recommended solutions. Without those pieces, you just have a confusing list of words. These developers didn't understand the problems. Worse yet, those in charge didn't understand either, so no one was given time to actually resolve the issues. It may be more accurate to say, no one was given or had the time to research the vulnerabilities and then try to learn how to fix them.
I spoke with more developers to learn if this was their experience, and unfortunately it was. This inspired a talk I presented at CodeMash recently. CodeMash is a large, development-centric conference in Sandusky, OH, that discusses the basics of penetration testing and some of the tools available. The complete presentation can be viewed below:
What is a Penetration Test?
In the security field we often refer to “Red Team” (offense) and “Blue Team” (defense). Penetration tests are one form of “red-teaming.” At their best, penetration tests are attack simulations. The test may be limited by what the tester is explicitly allowed to do, but the tester will always do their best to work within those constraints to simulate what an attacker would do.
eSentire’s Red Team follows the same methodology used by most testers. The test begins with a 'Discovery' phase. This is like host hide-and-seek. The tester typically receives a list of IP addresses and URLs and then has to figure out what is alive at those addresses and which ports and services are open. Armed with that information, they move on to the 'Enumeration' phase. The ports and services are closely reviewed to determine what they are, the version numbers, and anything else that can be learned.
At this point, the testing becomes more active as the test enters the 'Scanning' phase. Tools like Burp, ZAP, Nessus, and others are used to scan and test the applications for known weaknesses. They will circle back to the beginning and pick a new path until everything they can think of to do has been exhausted.
A penetration test is like QA testing. However, it’s QA testing taken to an extreme. While a QA tester’s directive may be to make sure the application works as expected for a business use case, a penetration tester comes to the application not knowing what it is or what is meant to do. Their goal is to do things you may have never expected a reasonable person to try to see if they can get the application to do something it was never intended to do.
The Attacker’s Toolkit
To carry out this testing, testers have a wide range of tools available to them. A sort of toolbox starter kit comes in the form of Kali Linux. Kali is a version of Debian that is maintained by Offensive Security and comes with many of the popular testing tools pre-installed. If you want to try some of the tools discussed here and in the presentation video, Kali can help you get started. Offensive Security even provides ready-to-import VirtualBox and VMware machines.
There are also web-based tools, like Shodan.io and Google. Penetration tests frequently start with OSINT (Open Source INTelligence gathering). OSINT is a big reason why we cannot rely on obscurity for security. No matter how small or hidden a service or application might be, it can be found. Shodan and Google make it possible for penetration testers to perform reconnaissance on a network before attacking, but they also allow others to stumble upon opportunities for mischief.
Shodan is a self-described search engine for the internet of things. It’s like Google, but it returns services rather than webpages and files. It can be used to answer questions about specific companies or services. For example, Shodan tells us there are over 35,000 Mongo databases accessible without authentication.
Sometimes this leads to trouble.
Google can also be used in this way. Using Google’s keywords, like inurl and filetype, testers, and others, it can look for sensitive information. In this example, I found a router password by searching for intext:“password” filetype:xls.
If a tester finds a web application or website, they’ll use tools like Burp or OWASP ZAP to look for problems that can be exploited. These are web proxies that enable the tester to view GET requests and information that is often thought to be hidden. Burp and ZAP are both free to get started. For developers out there, these proxies are like Fiddler, but with a twist.
Here is an example of Burp being used to test an application that uses Node.js and MongoDB for Server Side JavaScript injection. We can see the request with the injected JavaScript and the response showing the JavaScript was executed. Burp can edit requests like this on the fly before they are sent to the application.
ZAP is a great tool for penetration testers, but also good for developers interested in getting started with application security. It’s maintained by OWASP as an open source project and designed to be easy for anyone to use. You can provide a URL and click the “Attack” button to get started finding low-hanging fruit.
Taking Action
You don’t have to wait for your next penetration test to see what tools like Shodan, Google, Burp, and ZAP can find. Try them for yourself to see what you can find about your organization. You will be finding problems proactively and reducing the workload on the organization’s development and security teams. Fixing problems a little at a time is much easier than trying to find time and resources to fix one big list once a year. Plus, it introduces more of the organization to security and helps promote more secure practices. It’s like the Boy Scout’s mantra about the woods, but with computers. Always leave your network better than how you found it. You don’t need to fix everything all at once, but do this consistently and the quality and security improves naturally.
