Two years ago, we discovered an issue in a certain vendor’s software (that has since been fixed). For legal reasons, I cannot disclose the name of the vendor, so let’s just call them The Vendor. The Vendor provides an out of the box Back Office solution to telecom companies across the world, and are one of the “industry standards” in their space.
I was recently hired as our first security-focused test analyst, and was put to work on the company’s top priority project. Project-level security testing tends to flow a little different than pen tests, but the same basic theory and steps apply. After gathering some intel on the project, exploring some documentation, etc. I started with the centre-piece of the project: The Vendor’s BSS/OSS web application. After a bit of exploring, it was easy to see that this little chunk of intranet had a lot of power, whether it be provisioning of services, orchestration of billing, storing customer info, you name it. Now that I knew what I was dealing with, I had a fair idea of what I wanted to do.
I know that it is only #8 in the OWASP Top 10, but for some reason I always like to start with CSRF. CSRF, if you don’t know, is an attack where a malicious user causes another user’s browser to perform actions on a website, usually without that user’s knowledge or permission. Essentially, I send you an email, to a webpage, etc. that contains some evil code in it. This evil code tells your browser that you want to perform some action on another website, like create a user, change some settings, or send someone else funds. Anyways, this is where I started, and I am glad that I did.
We started with the administrator settings pages. Pop open a proxy and watch what happens… The Vendor’s web application was not submitting any tokens… Hmm maybe they use referrer checks? We replayed the request (sans referrer) in Fiddler and… Whoops! REST API security now set to anonymous. Confirmed CSRF. If we were going to report this, we wanted to know how widespread it was, so we decided to dig deeper. After running similar tests all over the website, it was clear to see that the entire site was vulnerable to CSRF. Billing tasks could be skipped, product prices could be changed, and the worst one: administer users (super users) could be created.
Now, I wouldn’t be so surprised as CSRF is a fairly common issue on the web today, but this is a fairly large software shop that has its software in over 175 telecom companies across the globe. They even boasted security testing as a service on their website! (Note: During the time since the discovery of this issue till today, The Vendor has removed this service offering from their website. I’m not claiming to have any effect or influence on that decision though…) I will follow that up by saying this was the first attack vector we tried, and that this was not the only issue found by the end of the project.
Next up, I reported this issue to our security team as well as The Vendor’s development team. Maybe I was overexcited, maybe they let their pride get the best of them, or maybe no one had their coffee yet, but the reaction was not a pleasant one. The first stage in bug-grief is denial, and they denied the issue hard. After several hours of debate, we came to the conclusion that the only way the vendor would understand the impacts of the issue was a full fledged demonstration. So, I left for a few minutes to write an actual exploit to demonstrate the issue to The Vendor’s onsite team.
Afterwards, we regrouped and I sent our Security Lead a link to a fun webpage containing many pictures of puppies! However, while he and The Vendor’s onsite team were enjoying a parade of images scoured from the deepest corners of Google Images, his browser was sending messages to The Vendor’s back office webpage. After everyone was finished “Awe”-ing at all the puppies, we decided it was time to take a visit to the back office web page. To the vendor’s surprise, all the products were now free! What a deal! From that moment on, they understood the issue, and they have generally not pushed back on issues since.
There are two morals to this story: 1) Don’t take a vendor’s word then they say their software is secure. Even if they are “liable” for any breaches, it is your name and brand on the line at the end of the day. As they say: “Get Tested!” 2) If you think you may have found an issue, do not take the first “No!” for an answer. Remember that not everyone learns the same way, and you may need to explain the issue and risk from another perspective. Step back and try and explain the risk from a business-impact lens, and then move on to the details when needed. If talking fails, insist that they allow you to demonstrate the issue.
I guess a third moral would be always patch. The vendor has released a version with patches to our finds, but it is up to the client (YOU!) to make sure you have applied the patch.
Note: I would like to suffix this article by saying that the vendor in question has since remediated all the issues found, and many of the challenges faced are paralleled across the entire software industry. If you have an idea of who the vendor is, please don’t let this article change your opinion of them, as once they understood the issues they actioned them. Also, keep any ideas of who you think they might be to yourself, not in my comments section.