Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security Hole in Sendgrid

chunkhost.com

Post reply on HN
Print view View original

81–90 of 97 posts

Re: Security Hole in Sendgrid

#81

Post by mikeg8 »

mantrax3 wrote: post #43
steven2012 wrote: post #38

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

Your logic is a bit weird. Sendgrid just experienced this major embarrassment and are currently re-training their staff to avoid it again at all costs. And you're going to move away from them now ?

The fact the Sendgrid even has to do re-training in the first place is the problem. They only need to do and handful of things well and keeping their users accounts secure is arguably the most important. If they are having issues like this this far along in their lifespan, it's a sign of more systemic issues in their company and does not instil much confidence to potential/current customers. Wanting to switch vendors doesn't seem weird at all to me.

Re: Security Hole in Sendgrid

#82

Post by cjbprime »

sillysaurus3 wrote: post #68
jyap wrote: post #49

Earlier quoted context omitted.

You should fault Sendgrid as they specifically have a policy NOT to perform this change of email request (from the article). Sendgrid can also change their systems so that phone support personnel can NOT perform this change or perform this change with approval from a supervisor. Sendgrid being in the business they are in should also know that they are susceptible to these types of attacks and what they can lead to (m…

I don't know... Mistakes happen. There seems to be little to gain from faulting SendGrid, but faulting SendGrid would force them to take some kind of action such as terminating the rep. I think I'd prefer the rep remain employed, because I trust they'd never make this mistake again. Also, now all the other reps know to avoid it. EDIT: May I ask what can be gained from faulting SendGrid in this case?

I agree with you that terminating the rep is not interesting, and I think you're mistaken if you feel like that's what anyone thinks will solve this problem.

Actions SendGrid could take:

* Make it impossible for their front-line support staff to change the email address on file. If you want that -- which should be extremely rare! -- you talk to a high-level manager who is competent at authenticating you.

* Send the email that says "hey, we're going to change your email address now" with a lead time to allow for the possibility that, even after your authentication, you've been conned.

* Make a phone call to the phone number on record, too.

You ask what's gained by faulting SendGrid, because you take it as a given that they will make these changes. But that's not how blame works. The blame serves a function of ensuring those changes by holding them accountable for their current problems.

Re: Security Hole in Sendgrid

#84

Post by [deleted] »

sillysaurus3 wrote: post #68
jyap wrote: post #49

Earlier quoted context omitted.

You should fault Sendgrid as they specifically have a policy NOT to perform this change of email request (from the article). Sendgrid can also change their systems so that phone support personnel can NOT perform this change or perform this change with approval from a supervisor. Sendgrid being in the business they are in should also know that they are susceptible to these types of attacks and what they can lead to (m…

I don't know... Mistakes happen. There seems to be little to gain from faulting SendGrid, but faulting SendGrid would force them to take some kind of action such as terminating the rep. I think I'd prefer the rep remain employed, because I trust they'd never make this mistake again. Also, now all the other reps know to avoid it. EDIT: May I ask what can be gained from faulting SendGrid in this case?

[deleted]

Re: Security Hole in Sendgrid

#85

Post by thrownaway2424 »

MasterScrat wrote: post #2

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

And people complain that Google has bad support! At least you can be certain that there's no way an attacker can get the Google support rep on the phone. There aren't any.

Re: Security Hole in Sendgrid

#86

Post by maxvu »

balls187 wrote: post #57
toomuchtodo wrote: post #3

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

Is AWS any less susceptible to Social Engineering attack of this type? Specifically--can AWS support staff grant access to AWS accounts, and if so: what are their criteria for doing so, and what are the policies in place to ensure those criteria are met, and how are those policies audited? As a TechStars alum, my company was granted $50k in AWS credits, which were tied to my AWS account[1]. When I left the Company, t…

It doesn't directly answer your question, but I don't think AWS has support staff -- just engineers that answer issue tickets.

Re: Security Hole in Sendgrid

#87

Post by chris_wot »

sillysaurus3 wrote: post #68
jyap wrote: post #49

Earlier quoted context omitted.

You should fault Sendgrid as they specifically have a policy NOT to perform this change of email request (from the article). Sendgrid can also change their systems so that phone support personnel can NOT perform this change or perform this change with approval from a supervisor. Sendgrid being in the business they are in should also know that they are susceptible to these types of attacks and what they can lead to (m…

I don't know... Mistakes happen. There seems to be little to gain from faulting SendGrid, but faulting SendGrid would force them to take some kind of action such as terminating the rep. I think I'd prefer the rep remain employed, because I trust they'd never make this mistake again. Also, now all the other reps know to avoid it. EDIT: May I ask what can be gained from faulting SendGrid in this case?

Given the contact email address is so important, perhaps SendGrid should have a way of confirming it before they allow it to be changed?

Or perhaps they should allow customers to require that they contact a secondary authority to confirm the change should be made?

Re: Security Hole in Sendgrid

#89

Post by vidarh »

danielweber wrote: post #67
vidarh wrote: post #66

Earlier quoted context omitted.

Frankly, with the amount of bullshit blacklists out there that real mail providers actually trust, I've come to detest blacklists more than spam.

Has anyone set up a blacklist full of random IPs as a joke to see how many people follow it?

Well, we have been put on blacklists that the operator wanted money to "expedite" removal from. I'm assuming that blacklist was pretty much random IPs... And it did impact deliverability.

Re: Security Hole in Sendgrid

#90

Post by icebraining »

hadoukenio wrote: post #29
d357r0y3r wrote: post #27

Earlier quoted context omitted.

Require that the company submit a legally binding/notarized document before changing the e-mail address.

Lol. So what you're saying is all I need is photoshop to get the keys to the kingdom?

Electronic notarization uses digital signatures, and SendGrid could just require them. Good luck breaking those with Photoshop.
Post reply on HN