Security Hole in Sendgrid

Social engineering will almost always work. I don&#x27;t really fault Sendgrid for this (though I could see this not working as well if you were using Amazon SES...no support to even talk to!). It sucks that they got caught with their pants down but I bet a good social engineering attempt on ChunkHost might have yielded similar results.<p>The lesson here is to have multiple defenses. 2 factor auth is a great start and it worked in this case.

Another title for this submission could have been:<p>&quot;Massive Security Hole in ChunkHost. Non-2FA accounts can be owned.&quot;<p>Because it turns out anyone with a Sendgrid Support account also effectively had <i>potential</i> access to any account at ChunkHost not using two-factor authentication. Which is also true of thousands of other companies that are relaying their password reset emails through third party SMTP services.<p>SendGrid seems lame, for allowing this and for their response promising to yell more loudly at their support people, but they&#x27;re an SMTP relay service not an authentication service.

The problem is that it was technically possible, for a representative, to make this change without the proper verification. You just can&#x27;t rely on humans for that.

Looks like a deeply unsatisfactory response from SendGrid. They don&#x27;t even know for sure (&quot;it appears .. pretty much confirms&quot;) that their own support staff changed the email address?

So what&#x27;s the answer? Here&#x27;s two very legitimate scenarios:<p>1) You sign up, enable two-factor auth, then lock yourself out (lost password and your second-factor). How do you prove to the service provider that you are you?<p>2) You sign up, enable two-factor auth, then Mallory claims that they locked themselves out. How does the service provider prove that Mallory is not you?

Use Amazon SES to generate your outbound emails; ensure proper IAM policies, and that you&#x27;re using 2 factor auth to login to your AWS account.

What I found most interesting was they were targeted due to Bitcoin. Today <i>most</i> services would never store credit cards themselves but rather have them stored at a secure payment gateway. So they&#x27;re unlikely to be attacked to get to those cards. T<p>Trust me I know that CC&#x27;s are getting sniffed in transit too often so I&#x27;m not saying they&#x27;re &#x27;safe&#x27;. I&#x27;m just wondering if there is something unique to Bitcoin that suddenly makes you a target as though you were known to be storing CC&#x27;s data at rest onsite.

Email accounts are the weak link for many things... DNS registrations, web hosting, etc. Get the email account and you have it all.

We use Sendgrid and have hundreds of thousands of customers that might be phished by this social engineering trick. It&#x27;s absolutely unacceptable that such a crucial piece of infrastructure is vulnerable to such a simple trick.<p>I&#x27;m going to bring this up with our team and see if there&#x27;s another vendor that can more reliably protect our customers.

It&#x27;s an important lesson for all of us. I&#x27;ve seen a lot of privacy ignorance when it comes to support (e.g. folks handing over sensitive data after an anonymous request on Olark). We should all go an extra mile and verify the identity of the requestor.<p>1) If your support chat doesn&#x27;t enforce authorization, always ask the requestor to send you an email. 2) Make sure the domain is correct (that&#x27;s where Sendgrid screwed up). 3) Never agree on replying to a different email address than the one of the sender.

BCC every message is evil, as it can be misused as in this case. SendGrid should never allow that, or at least should flag such behavior. At the minimum, they should notified account owners of this change.

It&#x27;s not a security hole, misleading title.<p>Should read &quot;social engineering resulted in security breach&quot; and guess what, this happens all the time whether sendGrid or not.

My first thought was to whois chunkhost.info, which returns a clear name, email address and phone number.<p>Or is it that easy to register a domain with a fictitious persona?

So what they are saying is that SendGrid should have had two-factor auth and this would have never happened.

<a href="http://twofactorauth.org/" rel="nofollow">http:&#x2F;&#x2F;twofactorauth.org&#x2F;</a>

SMS verifications should be sent out to allow over the phone changes.

Alas, the weakest part of the system is...

Sendgrid seems to be its own worst enemy (Adria Richards debacle, now this).<p>I suggest we dub the act or state of being one&#x27;s own worst enemy, being &quot;sendgriddled.&quot;

Send your emails yourself.<p>It&#x27;s not like it is hard. At least not harder than integrating to a third party email sender.