More and more companies are relying on SaaS solutions to store sensitive data and support critical business operations. While using SaaS offers considerable benefits, it's easy to succumb to groupthink and neglect the principle of 'trust but verify'.

I've often heard justifications like this:

This software is popular in our industry, so if it’s good enough for them, it must have been thoroughly assessed and should be alright for us as well.

For larger SaaS providers, this assumption might hold true, the average organisation is likely less capable of securing a self-hosted Exchange server compared to using Exchange Online. Furthermore, with larger providers, you can often access evidence of security certifications or even request penetration test reports.

However, these assumptions quickly fall apart when applied to more niche providers.

The Finding

During a routine black-box test, we assessed the entire internet-facing attack surface of a school, including their SaaS solutions (with permission).

One SaaS solution we looked at didn't present a large unauthenticated attack surface, but our methodology dictates that we fuzz whatever we can access. You can imagine our surprise when the username field on the login page appeared to be vulnerable to OS command injection...

Quick Explanation of OS Command Injection

For those who are unfamiliar with the vulnerability class, here’s a brief explanation of OS command injection and why it's such a significant concern.

Imagine an amazing web app that lets you ping a host by typing its IP address into a form field. A naive implementation might simply append this user input to the ping command in a shell.

This situation can escalate quickly with a bit of creativity.

Without proper sanitisation, it's possible to append additional commands to the input, allowing us to execute virtually any command we want on the server. That's what happened in this case.

Exploring Further

At this stage, we had only confirmed the OS command injection because the request returned after 30 seconds - the original payload told the server to ping itself 30 times before exiting. With some adjustments, it's now possible to view the output of our commands by redirecting the output to Burp Collaborator.

We can now view the output from the command 'dir C:\Users', as well as from any other command that might be of interest.

This finding made me curious about the code running behind the scenes. There are very few reasons why your application should need to call out to external binaries, and even fewer justifications for this during user sign-in processes.

Could it be something like this? 😂

[Route("api/[controller]")]
[ApiController]
public class LoginController : ApiController
{
    [HttpPost]
    public IHttpActionResult UserLogin(string username, string password)
    {
        // Check security
        CheckSecurity();

        // Call the login binary, fix later - Jeff
        string cmdString = $"login.exe --user {username} --pass {password}";
        return ExecuteCommand(cmdString);
    }

    private void CheckSecurity()
    {
        // TODO implement security
        Console.WriteLine("don't ship this to production - Jeff");
    }
}

Conclusion

This vulnerability finding highlights a few things:

1. No one has ever properly assessed this provider's code base.
2. No other customer in the industry prior to our customer has ever questioned the provider's security posture.
3. The SaaS provider in question is in some definite need of some secure software development education!

Overall, it serves as a stark reminder to organisations relying on third-party SaaS to not take security for granted. The S in SaaS does not stand for security.

At a minimum:

Request Recent Security Assessments: Ask potential suppliers for their most recent penetration test report or other security assessments. This can serve as evidence that they are actively managing their security risks.

Understand Your Risk Exposure: Identify what information you will be providing to the SaaS provider and understand at least at a high level how it is being stored, processed, and protected. Evaluate what the implications would be if the information provided to the SaaS provider were breached.