SonarQube Was Hacked?!?!

TLDR: According to an official FBI alert, SonarQube instances were breached, causing source code to end up in the hands of hackers. But what really happened?

You may have missed this news because of Covid, but the FBI issued an official alert (MU-000136-MW) that source code was leaked from SonarQube instances belonging to US government agencies and enterprise organizations since April. Throughout this blog, I will give an overview of SonarQube, go through the “hack”, and end with recommendations on securing SonarQube.

What is SonarQube?

SonarQube is a static code analysis tool used by many software companies. In common english, SonarQube looks at the code created by software companies and checks it for “bad code”, security flaws, and other metrics. Ironically, they are supposed to help eliminate the chances of your apps being hacked.

According to their website, officially stated, SonarQube® is an automatic code review tool to detect bugs, vulnerabilities, and code smells in your code. It can integrate with your existing workflow to enable continuous code inspection across your project branches and pull requests.

How Did the “Hack” Actually Happen?

Two words, Default Configurations. The agencies and organizations who’s source code were stolen had SonarQube configured with default configurations. The first question I asked when I found this out is “Why does GOVERNMENT agencies have default security configurations living in their production instance?”

In this case the default configurations, not all within 1 agency/organization, were:

• Default Login Credentials
• Default Port
• Default Force Authentication Option Disabled (Will discuss in a few)

What Should You Do?

If you have a SonarQube instance running:

CHANGE THE DEFAULT PASSWORD

• Every instance comes with the default admin credentials of Username: admin Password: admin. I shouldn’t even have to state this point, but I guess some don’t understand.

FORCE AUTHENTICATION

• With SonarQube, by default, anyone that has access to the application can see projects, vulnerabilities, source code, and so much more. With that being said, under Administration > General Settings > Security (at the bottom), there is a Force User Authentication tab. Enable that!

Whitelist the Application

• Only allow connections from inside traffic. No one not on the company network needs access to the data here. Even for audits, if they need to see the data, generate a report.

Use an Authentication Provider

• Throughout the available plugins, by default and via the marketplace, there should be a plug-in for the authentication provider your company uses.

My Take on the Entire Situation

So, was the hack really SonarQube’s fault? Absolutely not! The companies that installed the application with default security configurations are the ones at fault, not SonarQube. Without a doubt, I will continue using SonarQube and I don’t think anyone should shy away from this great tool. However, I do think SonarQube should fix a major default setting which is having Force Authentication enabled by default. With this feature enabled by default, only authenticated users will be able to see the data.

For more recommendations on security configurations and more information related to the “hack” check out SonarQube’s official release statement: https://blog.sonarsource.com/public-response-code-leaks. In addition, here’s the FBI Flash Alert: https://www.ic3.gov/Media/News/2020/201103-3.pdf

As always, thanks for taking time to read my blog. Feel free to leave a comment and/or Buy Me a Coffee below. Let’s stop hackers together!