Today, I want to discuss how we do penetration tests of Content Management Systems (CMS) like Wordpress or more specialized CMS used for managing intranets and knowledge bases. Our approach to testing is quite familiar to our regular readers. Let's review the basics of the approach:
Create a Threat Profile for the CMS
Create the Test Plan
Perform the Tests
Prepare the Report
A "Threat" is the goal of an adversary, it's what the bad guys want to achieve. A "Threat Profile" is the list of all threats to an application. [For more about Threat Profiles, please read "Why We Love Threat Profiles"].
The Threat Profile is central to our testing methodology. For a Content Management System, the threat profile would include threats like:
... publishes content on a site he is not authorized to
... deletes published content from a site
... modifies templates without authorization
... adds editors and publishers without authorization
... modifies the scheduled publishing date for an article
... views the list of documents scheduled for publication
... steals the passwords of other users
Notice these are the things an adversary might be interested in. Logically, that's where we should start from.
It takes about half-a-day to two days to create the threat profile - that depends on the complexity of the CMS. We study the CMS, prepare a draft threat profile and then get your feedback. Our generic Threat Profile Repository helps accelerate this step. This repository is a collection of common threats we see many applications.
Once the Threat Profile is ready, we create the Test Plan for the CMS - the specific tests to perform for checking each threat. This is the intensely technical part of our test, when we visualize in the mind's eye the various possibilities for attack.
The Test Plan connects each threat in the Threat Profile to specific pages on the CMS. For example, consider the threat, "The adversary publishes content on a site he is not authorized to". The "Publish Content" page and the "Schedule for Future Date" page are the relevant pages for the threat. An adversary might try to exploit flaws in these pages to publish content without permissions.
Once we identify the right pages, then we identify all the attacks to try on those pages to realize that specific threat. For example, on the "Publish Content" page, we might decide to try a Variable Manipulation attack and a SQL Injection attack to publish content by escalating privileges. The Test Plan is thus prepared for all the Threats to the application. To assist our engineers, we have a master reference checklist of all attacks - they pick attacks for the Test Plan from that checklist.
Once the Test Plan is prepared, it's reviewed and approved by a senior. The actual testing begins only after that. The tests are a combination of manual and automated checks. The penetration tester adheres to the original Test Plan. The test plan is updated when he gets new ideas during the test.
When an attack succeeds, we capture the screenshots of the attack. Our final report explains the attack step-by-step using these screen shots.
Any large application penetration test involves hundreds of test cases, so it's important that we focus on the right set of test cases. We should, for instance, focus on whether a the terms of a plan can be modified than on generating error messages by tampering unimportant variables. The Threat Profile to Test Plan approach helps us focus our testing on the threats specific to CMS.