4 ms·

Twitter says bug may have exposed some direct messages to third-party developers

56 points by uptown 8y ago

uptown 8y ago
Here's Twitter's official statement: https://help.twitter.com/en/account-activity-api https://help.twitter.com/en/account-activity-api
uptown 8y ago
"The company said that the bug affected less than 1 percent of users on Twitter. The company had 335 million users as of its latest earnings release." So the bug affected roughly 3.3 million Twitter accounts. And it also affected everyone who may be impacted by the contents of the messages which were not protected, whether you're a Twitter user or not, which could be many millions more.
- JCSato 8y ago
  "Less than 1" != 1. The bug affected roughly 3.3 million at most. It is annoying that they don't give more precise number, but I doubt most people would care.
mcdowell28 8y ago
Title should explicitly say "THIRD PARTY". I was thinking of Twitter employees. Also: >a “bug” sent user’s private direct messages to third-party developers “who were not authorized to receive them.” But: >it’s “highly unlikely” that any communication was sent to the incorrect developers at all Which one is it?
- sctb 8y ago
  We reverted the submitted title ”Twitter bug sent user direct messages to developers for over a year” to the original.
  - uptown 8y ago
    The article was submitted with a title matching the TechCrunch title at the time of submission. TechCrunch changed their title after it was submitted to Hacker News.
  - ccnafr 8y ago
    Maybe you could just link to the Twitter blog and get it over with. Stop giving TechCrunch a pass for blog spam while you replace links for all other sites.
sixhobbits 8y ago
"Twitter said in a notice that only messages sent to brand accounts — like airlines or delivery services — may be affected" I hope this is true. I got the message and only really use twitter DMs for communicating with banks and airlines. The message itself seems really poorly worded to me - I assumed that one of their APIs didn't check permissions and included all DMs and protected tweets in its output. "one or more" makes me assume "all" and "may" usually means "definitely has" in these kind of messages so it would have been great if they had included details about potential mitigating factors.
- sixhobbits 8y ago
  The technical details in the statement they released for developers makes this into a much smaller issue imo. https://blog.twitter.com/developer/en_us/topics/tools/2018/details-for-developers-on-Account-Activity-API-bug.html https://blog.twitter.com/developer/en_us/topics/tools/2018/d...
- mcdowell28 8y ago
  Very personal data is sent to brand accounts by some users (to get support, etc), so I don't think this is really good news.
  - QuinnyPig 8y ago
    Is it? I've sent support case numbers, and my email address, but never anything like credit card numbers, SSNs, etc. I'm not trying to downplay this, but I'm also not sending United Airlines my innermost secrets here...
    - Insanity 8y ago
      A lot of people whom are not tech savvy are also not so privacy aware perhaps. I'm going out on a limb here and say the average hackernews user is not the average twitter user :)
      - uptown 8y ago
CryoLogic 8y ago
The worst one was at the bottom, who cares about DM - "Twitter also said that earlier this year there was a bug where log files where created with user passwords in plaintext. Twitter urges users to change their passwords" I mean, what type of company with over a billion dollars in VC capital stores passwords in plaintext?
- cyrusaf 8y ago
  It's very unlikely they store their passwords in plaintext. They were probably logging during login requests and didn't realize the whole request body was being logged. Can happen if you have a proxy/load balancer with logging enabled.
- GhostVII 8y ago
  I don't think they were storing them in plain text, but on a login request it would log the request body without properly censoring the password. The password could still be hashed when it was actually put into the database.
- gizmo 8y ago
  That's almost certainly a case where POST parameters get logshipped to some server for debugging purposes, and it's easy to miss something like that in an audit when you're dealing with terabytes of logfiles. Even if the logfiles are rotated every day you don't know if a developer has seen somebody's password during that window, so all passwords are assumed to be compromised.
- guessmyname 8y ago
  They explained the bug here: > May 3, 2018 > Due to a bug, passwords were written to an internal log before completing > the hashing process. We found this error ourselves, removed the passwords, > and are implementing plans to prevent this bug from happening again. > — https://blog.twitter.com/official/en_us/topics/company/2018/keeping-your-account-secure.html https://blog.twitter.com/official/en_us/topics/company/2018/...
morpheuskafka 8y ago
If it's not end to end encrypted via a free software, audited client, you should be operating under the assumption that it is not being held in confidence. In this day and age, you shouldn't settle for anything less.
- deleted 8y ago
  [deleted]
- smt88 8y ago
  That means I should assume 100% of my emails are not confidential, which is an impossible situation for most people with jobs and non-technical relatives.
  - dredmorbius 8y ago
    Yes, it is an impossible situation. Which is why it needs to be remedied. Likely via regulation. Possibly by lawsuit.
  - inawarminister 8y ago
    Wasn't that why PGP got invented? Of course, it's much too onerous to the typical techie, nevermind non-technical relatives and friends...
shady-lady 8y ago
> Twitter said that a “bug” sent user’s private direct messages to third-party developers “who were not authorized to receive them.” user's -> users' __plural__
rnotaro 8y ago
From: https://blog.twitter.com/developer/en_us/topics/tools/2018/details-for-developers-on-Account-Activity-API-bug.html https://blog.twitter.com/developer/en_us/topics/tools/2018/d... We have validated that this bug might have occurred when all of the following technical circumstances were true during the relevant time period for this issue: 🞄 Two or more registered developers had active Account Activity API subscriptions configured for domains that resolved to the same public IP; 🞄 For active subscriptions, URL paths (after the domain) had to match exactly across those registered developers -- e.g. https://example.com/[webhooks/twitter] https://example.com/[webhooks/twitter] and https://anotherexample.com/[webhooks/ https://anotherexample.com/[webhooks/ twitter ]; 🞄 Those registered developers had activity relevant to their subscriptions occur in the same 6-minute time period (relevant because of a cache-like behavior); and 🞄 Those registered developers’ subscribers’ activities originated from the same backend server from within Twitter’s datacenter Under those circumstances, if the bug occurred, the issue (transmission of activities to the wrong webhook URL) could have persisted until one of the following conditions were met: 🞄 For up to two weeks, OR 🞄 Until no relevant activity occurred for 6 minutes, OR 🞄 Until the IP address of the developer whose data was being misdelivered changed

56 points by uptown 8y ago

Here's Twitter's official statement: https://help.twitter.com/en/account-activity-api https://help.twitter.com/en/account-activity-api

uptown 8y ago

"The company said that the bug affected less than 1 percent of users on Twitter. The company had 335 million users as of its latest earnings release." So the bug affected roughly 3.3 million Twitter accounts. And it also affected everyone who may be impacted by the contents of the messages which were not protected, whether you're a Twitter user or not, which could be many millions more.

JCSato 8y ago
"Less than 1" != 1. The bug affected roughly 3.3 million at most. It is annoying that they don't give more precise number, but I doubt most people would care.

mcdowell28 8y ago

Title should explicitly say "THIRD PARTY". I was thinking of Twitter employees. Also: >a “bug” sent user’s private direct messages to third-party developers “who were not authorized to receive them.” But: >it’s “highly unlikely” that any communication was sent to the incorrect developers at all Which one is it?

sctb 8y ago
We reverted the submitted title ”Twitter bug sent user direct messages to developers for over a year” to the original.
- uptown 8y ago
  The article was submitted with a title matching the TechCrunch title at the time of submission. TechCrunch changed their title after it was submitted to Hacker News.
- ccnafr 8y ago
  Maybe you could just link to the Twitter blog and get it over with. Stop giving TechCrunch a pass for blog spam while you replace links for all other sites.

sixhobbits 8y ago

"Twitter said in a notice that only messages sent to brand accounts — like airlines or delivery services — may be affected" I hope this is true. I got the message and only really use twitter DMs for communicating with banks and airlines. The message itself seems really poorly worded to me - I assumed that one of their APIs didn't check permissions and included all DMs and protected tweets in its output. "one or more" makes me assume "all" and "may" usually means "definitely has" in these kind of messages so it would have been great if they had included details about potential mitigating factors.

sixhobbits 8y ago
The technical details in the statement they released for developers makes this into a much smaller issue imo. https://blog.twitter.com/developer/en_us/topics/tools/2018/details-for-developers-on-Account-Activity-API-bug.html https://blog.twitter.com/developer/en_us/topics/tools/2018/d...
mcdowell28 8y ago
Very personal data is sent to brand accounts by some users (to get support, etc), so I don't think this is really good news.
- QuinnyPig 8y ago
  Is it? I've sent support case numbers, and my email address, but never anything like credit card numbers, SSNs, etc. I'm not trying to downplay this, but I'm also not sending United Airlines my innermost secrets here...
  - Insanity 8y ago
    A lot of people whom are not tech savvy are also not so privacy aware perhaps. I'm going out on a limb here and say the average hackernews user is not the average twitter user :)
    - uptown 8y ago

CryoLogic 8y ago

The worst one was at the bottom, who cares about DM - "Twitter also said that earlier this year there was a bug where log files where created with user passwords in plaintext. Twitter urges users to change their passwords" I mean, what type of company with over a billion dollars in VC capital stores passwords in plaintext?

cyrusaf 8y ago
It's very unlikely they store their passwords in plaintext. They were probably logging during login requests and didn't realize the whole request body was being logged. Can happen if you have a proxy/load balancer with logging enabled.
GhostVII 8y ago
I don't think they were storing them in plain text, but on a login request it would log the request body without properly censoring the password. The password could still be hashed when it was actually put into the database.
gizmo 8y ago
That's almost certainly a case where POST parameters get logshipped to some server for debugging purposes, and it's easy to miss something like that in an audit when you're dealing with terabytes of logfiles. Even if the logfiles are rotated every day you don't know if a developer has seen somebody's password during that window, so all passwords are assumed to be compromised.
guessmyname 8y ago
They explained the bug here: > May 3, 2018 > Due to a bug, passwords were written to an internal log before completing > the hashing process. We found this error ourselves, removed the passwords, > and are implementing plans to prevent this bug from happening again. > — https://blog.twitter.com/official/en_us/topics/company/2018/keeping-your-account-secure.html https://blog.twitter.com/official/en_us/topics/company/2018/...

morpheuskafka 8y ago

If it's not end to end encrypted via a free software, audited client, you should be operating under the assumption that it is not being held in confidence. In this day and age, you shouldn't settle for anything less.

deleted 8y ago
[deleted]
smt88 8y ago
That means I should assume 100% of my emails are not confidential, which is an impossible situation for most people with jobs and non-technical relatives.
- dredmorbius 8y ago
  Yes, it is an impossible situation. Which is why it needs to be remedied. Likely via regulation. Possibly by lawsuit.
- inawarminister 8y ago
  Wasn't that why PGP got invented? Of course, it's much too onerous to the typical techie, nevermind non-technical relatives and friends...

shady-lady 8y ago

> Twitter said that a “bug” sent user’s private direct messages to third-party developers “who were not authorized to receive them.” user's -> users' __plural__

rnotaro 8y ago

From: https://blog.twitter.com/developer/en_us/topics/tools/2018/details-for-developers-on-Account-Activity-API-bug.html https://blog.twitter.com/developer/en_us/topics/tools/2018/d... We have validated that this bug might have occurred when all of the following technical circumstances were true during the relevant time period for this issue: 🞄 Two or more registered developers had active Account Activity API subscriptions configured for domains that resolved to the same public IP; 🞄 For active subscriptions, URL paths (after the domain) had to match exactly across those registered developers -- e.g. https://example.com/[webhooks/twitter] https://example.com/[webhooks/twitter] and https://anotherexample.com/[webhooks/ https://anotherexample.com/[webhooks/ twitter ]; 🞄 Those registered developers had activity relevant to their subscriptions occur in the same 6-minute time period (relevant because of a cache-like behavior); and 🞄 Those registered developers’ subscribers’ activities originated from the same backend server from within Twitter’s datacenter Under those circumstances, if the bug occurred, the issue (transmission of activities to the wrong webhook URL) could have persisted until one of the following conditions were met: 🞄 For up to two weeks, OR 🞄 Until no relevant activity occurred for 6 minutes, OR 🞄 Until the IP address of the developer whose data was being misdelivered changed