Posted on 2022-06-22 by Alexei Doudkine in Volkis News
Well, it finally happened! We received the first submission to our Vulnerability Disclosure Program with actual possible impact. And, although it didn’t actually affect us or our clients in any way, it could have. So we awarded it a P3! But how could this happen? We’re security experts ourselves, so shouldn’t we have picked up on it? Well, as we always tell our clients, “security is hard” and no one is perfect.
In the interest of transparency (one of our core values), let’s dig deeper to see how this tale unfolded so that others may learn.
The background
If you’ve been to our website recently, (which I now realise is a silly thing to write because you’re reading this right now) you would have noticed we recently implemented Intercom into our website; it’s the little chat bubble in the bottom-right corner. We wanted to add this so that visitors could ask as anything right away! No more contact form; they are like so 2010s.
The implementation seemed to go well and functioned as expected for visitors of the website. Now might also be a good time to make some clarifications that are important for later:
- We do not have a login functionality.
- We do not authenticate people using the email address alone.
- Existing clients don’t use this channel to communicate with us.
For a visitor, the flow we go something like this:
- Type a question into the chat.
- A bot asks for email, name and company name.
- Optionally give the above details and wait for a response.
The Vuln
The hypothetical attack sequence would go like this…
- A visitor starts a chat with us and enters their email address, [email protected].
- A discussion takes place over chat where some sensitive data is shared.
- The attacker somehow discovers that a chat took place and the email address given was [email protected].
- The attacker then interacts with the User (an Intercom term) API, rather than the default Lead (another Intercom term) API, giving the above email address.
- This reinstantiates the chat window and shows past conversations, including any sensitive data, to the attacker.
Not good! What’s happening on the Intercom side is that they see a new User and assume that it’s the same Lead as before, since the email address matches. The Lead is effectively converted into a User with no authentication.
In reality, this was never actually maliciously exploited and very unlikely it would have ever been exploited. This is because the attacker would need to know email addresses of past conversations and there would have to be sensitive information in the conversation, which we never ask for in that channel. Nevertheless, we deemed it unacceptable that there was even a small chance of this happening, so we fixed it right away.
Credit for finding this vuln goes to Soman Verma. We’ve sent him a bunch of swag as a reward. :grin:
If you want more details on Intercom misconfigurations, Douglas Day has a great post.
How it happened
Like many other vulns, it came down to a combination of assumptions, misleading documentation, and insecure defaults.
I mentioned above that Intercom separate interactions into Users (people who have logged in) and Leads (people who are logged out). Intercom do mention that Users should be verified using their HMAC-based identify verification APIs. But since we don’t have a login mechanism, I ignored the Users part and focused on the Leads (visitors). I assumed that the Users API would be disabled by default since I had not specifically set it up during implementation. I was wrong.
What’s more, Intercom’s own documentation says
“If you only chat to visitors, identity verification is not essential.”
But as we’ve now seen, it is very essential!
Intercom’s Identity Verification setting is turned off by default; an insecure state. One would need to manually recognise this as a potential issue and turn the appropriate setting on.
Of course, I need to also acknowledge my own mistake. I should have verified my assumptions and done more thorough testing. I actually knew about this type of attack and had it front of mind during implementation. But, again, assumed it didn’t affect us because we only have visitors. Feels silly to not check it, in hindsight.
Learn from our mistakes and wins
We know what happened and what mistake were made. But this vulnerability didn’t actually impact us negatively at all. So what went right to prevent some horrible leakage of sensitive information?
Firstly, the Vulnerability Disclosure (Bug Bounty) Program itself. We have a clear policy giving good faith researchers and bug hunters permission to hack us. They disclose security vulnerabilities to us and we pay them for their trouble. Because of this, the Intercom vulnerability was found within 1 week of implementation and before there was a chance of any sensitive info making it onto the platform.
Then, there’s different types of data and how we handle them. We’ve thought about what data is just a little bit sensitive and what data is so sensitive that it would cause irreparable damage to our reputation. The kind of data we would ask for through Intercom is somewhat sensitive (like functionality of a possible client’s website or the number of external IPs); data that wouldn’t cause any real damage if it was disclosed, but certainly not something we would wilfully publish. We would never ask for anything like passwords or credentials or configuration files through Intercom. We have other, more secure communication channels for that. Putting up boundaries like this would have also saved us in the event of a real attack.
What came out of this?
Overall, this wasn’t a huge worry for us since we had taken the time to thing about security in layers. I encourage you to do the same and constantly play out hypotheticals like, “What would happen, realistically, if this system/process was compromised?”. Find those single points of failure and close as many as you can.
If you are using Intercom, I strongly encourage you to enable Identity Verification right now!
Intercom was very responsive as well and wanted to hear suggestions for how to improve. They organised a call for us to discuss potential solutions and share what they were already doing to combat this type of misconfiguration. They shared that they have or are considering multiple things:
- Changes to documentation to make the risks clearer to their customers are already done;
- An additional step to their onboarding flows to get all customers to turn on Identity Verification is also done;
- All customers who have not yet turned on Identity Verification have already been contacted with a suggestion that they do so;
- A Security Best Practices post is being written for their blog to increase awareness and adoption of product security features;
- Evaluate the option of enabling Identity Verification by default without impacting user experience.
A big shout-out to the Intercom security team for their efforts!
Stay safe and contact me if you need help or have any follow up questions about this.
About the author
Alexei Doudkine is Co-Founder and Offensive Director at Volkis. Hacker, tinkerer, car modder and dog person, Alexei has been in the infosec game for over 10 years focusing on the “attack” side of security. You can catch him on Twitter and LinkedIn.
Photo by Sarah Kilian on Unsplash.
If you need help with your security,
get in touch with Volkis.
Follow us on Twitter and
LinkedIn