The market often confuses the difference between manual penetration testing and automated vulnerability scanning and assessments. While they can have similar objectives, the process and outcome are often very different.
Before buying a security service, the first thing any organisation should understand is the type of testing service they are purchasing. Often immature security services use terms interchangeably without fully understanding the product they are offering.
At Blackfoot, we define the following key service types:
Vulnerability Scan (VS):
A purely automated scan utilising industry leading products which have been configured to meet the requirements of best practice. Reporting is limited to the ability of the software/appliance conducting the scan. No manual testing or confirmation of false positives or negatives, and no chaining of vulnerabilities.
Vulnerability Assessment (VA):
Mostly automated testing utilising industry leading products which have been configured to meet the requirements of best practice. Reporting is often bespoke. Some manual testing activities are performed to confirm legitimacy of automating tooling and eradication of false positives. No exploitation of vulnerabilities other than confirmation of tool output. No chaining of vulnerabilities.
Penetration Testing (PT):
Building on and incorporating a vulnerability assessment, penetration testing is a heavily manual testing process and cannot be automated by definition. Penetration testing involves the chaining and exploitation of vulnerabilities identified in order to compromise and elevate privileges to a system.
Here is what we got up to during one of our Penetration tests:
Blackfoot’s technical assurance team discovered a zero-day vulnerability as part of a penetration test for one of our clients who relies on charitable donations. The team came across a donator plugin by the name of ‘GiveWP’ and identified an information disclosure vulnerability.
Background
GiveWP is a donation plugin for WordPress that allows users to donate to the site’s organisation with over 100,000 active installations (Affected Versions: <= 2.20.2). Once the plugin was identified, Blackfoot took the approach of installing a copy of the plugin and setup a local test environment to have a deeper look at things.
Exploitation
While conducting a review of the code, Blackfoot came across the following API endpoint:
The screenshot above shows there is an API endpoint of ‘/donor-wall’ which is accessible via ‘/wp-json/give-api/v2/donor-wall’. This issue alone allows an attacker to view all the donations to the website and the information of the donors including full name, how much they donated, time of the donation etc without the need for authentication. Furthermore, GiveWP has a feature for anonymous donations. It was identified in some cases, that it was possible to fetch the donation details even when the anonymous donation feature was set.
When visiting the endpoint, Blackfoot also noticed another interesting parameter (data-donor_email).
Highlighted in the above screenshot, the parameter named ‘data-donor_email’ had a value which looked to be a hash. Entering the hash in hash-identifier returned MD5 as a potential match.
If the hash is entered in a common hash database site, the hash of the email returns the following:
Exploiting these two security issues and to bring this to life, an attacker could use both for a targeted phishing attack:
- Attacker gathers a list of millions of email addresses from past security breaches (LinkedIn, Myspace, Dropbox etc).
- Attacker then visits the unauthenticated endpoint and scrapes all entries
- With the scraped MD5 hashed email addresses the attacker runs a dictionary attack against the hashes
- In total, the attacker now has the full name, email address, amount donated, when the donation was made and the organisation they donated to. This data is enough for a convincing phishing email.
Blackfoot immediately reported this vulnerability to GiveWP who, despite facing challenges as a result of the pandemic, were able to respond by releasing a fix on the 11th of May 2022. It was later established that the hashed email leak occurred due to Gravatar’s implementation of identifying an identity by a users’ MD5 email hash.
Recommendation
Update to version 2.21.0, or newer.
Reference
Wordfence – https://www.wordfence.com/vulnerability-advisories/#CVE-2022-2117
Timeline:
- 14/12/2021 – Blackfoot identified the vulnerability and reported it to GiveWP.
- 14/12/2021 – GiveWP did not quite understand the issue at first, however, they acknowledged the donor wall endpoint should not have been accessible from an unauthenticated perspective.
- 24/01/2022 – Blackfoot took the opportunity to explain the concerns further and substantiate the issue further.
- 03/02/2022 – GiveWP acknowledged the issue and gave an estimated date of when the vulnerability would be fixed.
- 11/05/2022 – GiveWP fixed the issue
- 23/05/2022 – Reported to Wordfence
- 17/06/2022 – Wordfence assigned CVE-2022-2117 and published the advisory (https://www.wordfence.com/vulnerability-advisories/#CVE-2022-2117)
Conclusion:
If there was one thing that stands out during this engagement, that is the difference between the depths of testing. If something is half the price, then there is quite possibly a very good reason as to why. While you might think you are buying a penetration test, the use of automated tools might be all you are getting, resulting in a false sense of security of your environment. Blackfoot will always be transparent about the service you are buying and as demonstrated here, the cost of penetration testing delivers the value.
