Many engagements, which start out as a typical application penetration test, quickly present themselves as interesting opportunities to do some more in-depth research into the underlying product and its processes. It is often the case that the application under assessment will be an off-the-shelf solution from a vendor, or an open-source project, that is further configured by the client to suit their business requirements. The time invested diving into underlying products and processes adds value to clients as the testing performed is more in-depth and tailored. Over time this builds up a repertoire of consultant knowledge on these systems, which are often deployed in multiple corporate environments.
Identifying the application’s underlying software and architecture allows testers to determine the availability of source code, or the ability to deploy our own ‘testing’ instance of the solution. This allows testers to pull apart and observe some of the technological nuances which may not be easily observable with ‘unauthenticated’ or ‘low privileged’ access that many engagements begin with. This is one element which is typically not available when testing a custom built or closed-source application in a black box assessment.
Where to search for research targets
The following list describes a few places you can easily find target applications to conduct additional research:
- Open-source code repositories, e.g. Github/Gitlab.
- Cloud hosted implementations, for ‘one-click’ deployments, e.g. AWS Lightsail for WordPress.
- Vendor released solutions available on cloud hosting platforms, e.g. prebuilt AMIs available in the AWS marketplace.
- Vendor released demo appliances and evaluation instances. Note: you may need to be mindful of any licensing or customer agreement terms before conducting any testing against these.
In other instances, you might be able to easily replicate some of the design solution elements in play, such as deploying an instance of the Azure APIM platform and spinning up a demo application. This affords the opportunity to explore the functionality available within a solution and map out potential avenues for attack.
Benefits of additional research
As a tester, there is great benefit in configuring a test instance of the solution yourself, as working through the build may also reveal areas where solution design choices must be made. It can also give you some insight into the assumptions or compromises a development team might make in order to configure the solution to their needs.
In the best case, if you have access to the open-source code which is running the underlying technology of your target application, you can do a full code review of the platform. This allows you the opportunity to identify any bugs present that may not be so easy to identify from a black box testing perspective. It also gives you the opportunity to run static and dynamic code analysis tools over the codebase. This helps leverage the power of automation in order to help steer your efforts towards areas of interest where a more manual investigation is required.
One thing to note is that while it is great to be able to deploy your own copy of the solution and get a glimpse into the way the underlying technology works, you still need to be mindful that your actual target application is likely to be configured differently to an out-of-the-box solution. Additional plugins or custom features may have been added by the client’s development team in order to meet a business case. Some elements of security that are not present within the base framework may be added by the client to mitigate any inherent risks present. Overall, performing some research and testing of off-the-shelf solutions and open-source projects is a great way to learn more about these products and identify points of interest within them, while providing direction as to where more focused investigation is needed.