API Security Hole

[#1]

I’m hoping this reaches the platform developers at Hubspot. This morning we identified a fairly significant security problem.

TLDR: If a user authenticates/authorizes access using OAuth and that user is later removed from the Hubspot account, the authentication credentials continue working (read-only).

Here’s the scenario:

One of our customers had an employee authenticate using Hubspot to allow data sync between our product and their Hubspot portal. A month later, that person left their company and was replaced by a new person. Per normal security protocol, the old user was deleted from our customer’s Hubspot account.

Our customer noticed their data sync seemed to be broken. However, we were still able to read from the API (fields, lists, contacts, etc.). Because of this, our monitoring system assumed things were still working. So, while write access stopped working we can still read all the data using the deleted user’s API authentication credentials.

Further testing identified other interesting issues. Another example: if you authenticate with a user who has read/write access to contacts and later revoke write access, the API credentials still allow write access.

I assume the expectation is deleting a user would revoke API access. It’s easy to imagine a scenario where someone uses a 3rd-party tool like Zapier to create a sync between Hubspot and Google Docs. That person is then terminated, their user account is removed from Hubspot, yet they are still able to sync data (contacts!) from the Hubspot portal to their Google spreadsheet.

[#2]

Hi Ryan,

I guessed this might be by design. The one thing that doesn’t make sense in this context is write access being revoked. This would leave many integrations in a partially working state (can still read data, but can no longer write).

Best practice for Hubspot users should then be to create a special API user to avoid ex-employees having full read access to the entire database.

I realize the integration can be disabled - but I doubt many users are savvy enough to track that down. The integrations page doesn’t really tell you who authenticated. If I were managing a Hubspot account I wouldn’t delete a “working” integration without more knowledge about it. But that same working integration is potentially giving someone outside the org full access to my contact database

[rstinson]

Hey Chris! Thanks for your comment. The behavior that you identified is working as designed, but we’re using your input to evaluate ways to improve it.

Overall, we want to make sure our customers have a positive experience, in this case with the apps that they’ve authorized to their portal. When the integrations function that you referenced was designed, we wanted to be sensitive to breaking integrations that a former user had authorized (e.g., Salesforce, Wistia, etc.) without providing a resolution that was intuitive to current portal users.

Currently, it is possible to deauthorize integrations with your portal. When you go into the HubSpot Integrations app (click your avatar in the upper right and select “Integrations”), a portal administrator can uninstall existing applications. This solution was put in place to ensure that portal admins could choose either to leave an existing integration in place or to deactivate and reauthorize. We are evaluating the best ways to build on the existing model to improve the experience for administrators in the situation you described. Stay tuned!

Thanks again for pointing this out. If you have other observations about security-relevant behaviors, you can also get in touch with HubSpot’s Security team directly through our bug bounty program. Information about the bug bounty program is available at https://bugcrowd.com/hubspot.