Every pentest is different, each one brings new challenges and new opportunities to find interesting bugs and vulnerabilities.
Last month, during a pentest I discovered an error page. Not that unusual as we are actively trying to break things and cause errors and issues as part of the test. This time, however, it was different to me because it looked like a standard error page rather than one that the developers had made. The trouble is that even after almost 3 decades of ethical hacking, I cannot know everything about everything.
I took a screenshot and carried on with testing. The wording and look of the error page hinted it was a default error page from a framework but which one? I am not a developer and so I don't have intimate knowledge of defaults of a lot of frameworks. I would normally ask the client, but in this case there was a 3rd party developer who was not in the loop for the test.
What to do?
I turned to Twitter, crowdsourcing and asking for help is the most efficient thing to do and yet I see inexperienced hackers not doing this in case they are ridiculed. I finally worked out it was either a Ruby or a Rails error page but not more than that.
Whilst I waited on the replies I carried on testing. It shouldn't matter if the error page is a default framework or custom one, as it is part of the web application it has to be tested. Another thing I often see inexperienced hackers doing is assuming that large or well known applications and frameworks have been tested throughly, after all they are well known, so surely thousands of hackers are looking at them? This is almost never the case. Think of every piece of software you didn't look at because of that reason, now imagine that everyone else is thinking the same. The result is that no one looks!
So after a few minutes of testing I was able to find a XSS (cross site scripting) error on the page.
Here is a POC screenshot that I captured:
The test payload was rather simple:
<svg><animate onend=alert(document.domain) attributeName=x dur=1s>To celebrate this I checked twitter and the replies were very helpful, it was a Ruby on Rails default error page. So now all I had to do was report this bug directly to the Ruby on Rails team.
To their credit they were incredible with their response. They checked the POC I sent them and the issue was found, fixed and a solution was pushed out all within 3 days of being reported.
Some of you may have spotted something in this. It looks like it's a self-reflected XSS, that means that only the consumer can trigger it, kinda pointless right? So why did I bother to highlight this to the team and why did MITRE assign me a CVE for it?
There is a tendency to assume that some vulnerabilities are not a risk because they do not have an impact right now. However, we need to take a bigger picture view of vulnerabilities.
Let's take this one as a wonderful example of this. XSS is a way to attack an end consumer of the web application, so an XSS that must be triggered by the consumer is a self own and so not a problem. 100% of bug bounties would reject this, most clients might question it too. But why, no one is going to hack themselves right?
This is where you need to think about how that vulnerability came about. There is a coder that has built a form input and then the input is reflected back to the consumer. Now that coder has not been educated in secure coding methods or has not considered the security issue this will bring, and that means they are likely to make the same mistake again elsewhere. But also consider that maybe another coder in the project will copy and paste that vulnerable code somewhere else assuming it's been tested, or maybe someone looking at the open source project uses that bad code on their project.
You can see how easily this error can propagate into other areas of the application or framework and even end up in other projects. So now that piece of bad code can be in a place that might be triggered by an outside attacker.
Fixing bad code is imperative because this type of future proofing is so important.
Because MITRE is aware of this type of code migration I was awarded CVE-2022-3704. Ruby on Rails pushed out the fix from commit #46269
Rails 5.2 Stable should be updated by the time you read this blog post.
To follow along you can see the git issue here
You can find out more about our pentesting services here
And don't forget to sign up to our mailing list