#ikdoeict pentest: the conclusions
Our IT students tested 60 websites for security issues. A look back at what they found, guided by the OWASP top ten.
This article originally appeared in December 2020 on rlvs.eu.
Our IT students have submitted their pentest in the meantime, and the evaluation is behind us. The clients received a report with the results a while back, so it’s time for a quick look back…
Although we didn’t provide specific guidelines, a large portion of the sites belong to SMEs and non-profits. This translates into a relatively large number of sites built on the WordPress platform.
Finding 1: forewarned is forearmed for a sysadmin..
.. who often suddenly becomes a very alert sysadmin.
On some sites it was striking that everything was patched so neatly, leading to at least a suspicion that this happened in response to the announced pentest rather than from a thought-out strategy or automated workflow.
There is absolutely nothing wrong with that: it only makes the world a safer place. Of course, it remains a ‘recipe for disaster’ if it only happens because of a one-off & announced pentest.
Finding 2: a good year for CMSs
When we had the pentest performed for the first time a few years ago, there were almost always vulnerabilities to be found in CMS installations. That is noticeably better this year.
Our sample size is far too small to speak of a trend, but it at least seems that attention to security across various CMSs has increased significantly, resulting in a much lower number of vulnerabilities.
Figures (source: www.cvedetails.com) seem to confirm this for WordPress, for example:
Finding 3: self-hosting a site is usually not a good idea
Servers hosted in-house by (non-specialized) companies turned out to be a rewarding target more often. Outdated server versions, unnecessarily opened ports, ..
Look before you leap when it comes to running your own servers…
Finding 4: the OWASP top 10 remains a good guide
It cannot be stressed enough that the students had no prior pentesting experience. After a brief introduction, they were sent on their way. Undoubtedly, there were also issues that escaped their attention, but the lowest-hanging fruit was likely picked. The students were given the OWASP top ten as a guide for their search, and that framework works well for searching for vulnerabilities in a structured way.
In the table below, you’ll find an estimate of the number of found vulnerabilities per category. An estimate, because some issues fall into the gray area between two categories, or because we couldn’t or weren’t allowed to validate the results ourselves. Sometimes there was also a cascade of issues, where only one ‘main’ issue was flagged each time.
| Vulnerability | vulnerable |
|---|---|
| Injection | 5% |
| broken authentication | >8% |
| sensitive data exposure | 5% |
| XXE | 0 |
| Broken access control | >8% |
| security misconfig | >7% |
| XSS | >7% |
| insecure deserialization | 0 |
| using components with known vulnerabitites | >10% |
| insufficient logging | N/A |
SQL injection fortunately occurs less and less in our results. Frequently used frameworks already largely protect developers against these blunders.
File uploads remain a sensitive point, just like in previous years. Input validation there is often not sufficient to stop our motivated pentesters.
In terms of authentication, passwords remain problematic. All too often, passwords were found in password dumps in the deepest corners of the web, were far too easy to guess based on public information (like N@@m123), or were listed in a ‘specialized’ dictionary.
More and more sites discourage brute-force attacks by deliberately building in delays or placing blocks after multiple failed logins. The Wordfence plugin is gaining serious ground in that regard, and we can only welcome that… Discouraging brute force belongs on every web developer’s to-do list anyway: we learned once again that you simply cannot trust users when it comes to their choice of password…
Carelessness also remains a persistent problem. Code left in debug mode, overly detailed error messages, visible installation files, … they keep popping up.
It’s hard to turn that into a concrete tip, but enabling debugging on a production server is obviously a big no-no…
It led to less explosive results than in previous years, but once again heavily outdated components were found. Especially on self-hosted sites, this remains a classic.. The percentage of sites where this was noted is quite high, but that figure holds little value for this category because it (fortunately) mostly concerns vulnerabilities with very low CVSS scores.. Additionally, this category was difficult to verify: the outdated version number could be wrong, or a local patch might have been applied instead of a version upgrade to resolve an issue…
The number of sites that are only accessible via the inherently insecure HTTP is thankfully facing extinction.
However, many HTTPS sites are not yet secured with HSTS (even though it’s not rocket science), which gives hackers the opportunity to perform man-in-the-middle attacks.
The XSS spectre also continues to haunt the tests, and just like with HSTS, a few HTTP headers can offer some help here too. One specific finding deserves an extra mention: one student found an XSS vulnerability in a piece of code used on dozens of e-commerce sites, which could be used to steal sessions…
…And so, with this exercise, we take another big step towards an ideal world.. ;-)