Satisfaction have spammed me

Actually, it looks like we did have a hole in our system. I've solved it and will be deploying momentarily. I'll describe the exploit after it is closed.

Alright, so here's how it happened.

As you know, we have an email confirmation mechanism in Satisfaction. A url is given in the confirmation email messages that has a secured token that is used to confirm that you are able to receive mail at a certain address. When you navigate to that url with a valid token, you get a message to the effect of "Thanks, you have verified [EMAIL]". On the other hand, if you went to that url without a valid token it would say "I'm sorry, but the confirmation token for [EMAIL] is invalid", which is where the hole is.

For example, in your Shermozle, navigating to /people/5db0bdd0bd51f781d56fcd4ad10e25721b5cd52c/email_confirmation would give me an HTTP request with your email encoded in the response cookies. This was exposed when we switched from storing Rails flash state in our DB to using cookies (which is now the default in Rails).

I'm currently downloading the access logs from our servers to see if I can glean how many emails were compromised, and am running another sweep to find everywhere email is used in the system to make sure things are secure.

What a shitty day.

That's just the thing, I wouldn't have thought so either. But, there isn't very many places a user's email is used or displayed in the system.

1. Email address is transferred into the system at signup, login, and password reset
2. The Email and Notifications page has a list of every address you've entered into the system
3. The company admin pages shows email addresses of the other company employees/admins
4. An email is sent to company administrators when a topic is posted to their companies. That email uses regular To: headers in the message rather than BCCs as an additional means to allow inter-admin communication. They should all have each others email address, and using normal To: headers lets a private conversation form between admins around a topic.
5. Your email is used as parts of several cryptographic hashes used for authorization in the system. Don't worry, these hashes aren't easily vulnerable to Rainbow table attacks, we salt hashes on a per user basis :-).
6. Used as a BCC field for email messages sent tp notify users of new posts.

And that's it.

1 doesn't result in the display of email addresses besides user-entered data, so it is vulnerable to man in the middle attacks, but nothing else that i'm familiar with.

I'm confident 2 and 3 are secure, but I am by no means a security expert. Apart from hijacking someones session cookies, I can't get into a profile page unless I'm signed in as that user.

4 is by design and only applies amongst company administrators.

5 is as secure as SHA1 with user-specific salting.

6: If this has been exploited, I believe that means each of our mail server have been compromised! Doubtful.

While decoding the session cookie for sensitive information is Rails-wide, This exploit is still pretty satisfaction specific. I would normally think that something outside of satisfaction was exploited, but since I have no control over anything outside I have to assume that it was our system that was exploited. Given that, the hole I fixed today is the most likely cause, until more holes are uncovered.

Our sincere apologies. We are working through it, and I promise you we will update you with information -- and that we'll work diligently to make sure it doesn't happen again.