Links sent privately through Facebook Messenger can be read by anyone(medium.com)
medium.com
Links sent privately through Facebook Messenger can be read by anyone
https://medium.com/@intideceukelaire/why-you-shouldnt-share-links-on-facebook-f317ba4aa58b#.mwoeohl1b
69 comments
Couldn't an attacker simply run a script (from multiple source IPs) to get a large number of FB Messenger URLs - then parse the results for specific things - dropbox links, google docs links and other services that are secured through a long URL? I would guess there are examples of services that would be high value to attackers and are secured through the URL... although I can't think of any in particular.
[deleted]
> For example, plenty of websites (google docs, dropbox etc) offer an 'anyone with this link can view document' option. Which is generally safe, given these randomly generated links usually contain > 100 bits of entropy. Access to the link is access to the document, and so the link is a PW.
This isn't really particular safe even if its unguessable, its more the internet equivalent of a casual privacy lock.
This isn't really particular safe even if its unguessable, its more the internet equivalent of a casual privacy lock.
According to the article, you need the resource ID of the link to query it in the API. The resource ID seems difficult to get; you basically need to be viewing the conversation (and thus the link) to get the ID. While I agree it's _possible_ to stumble onto sensitive information by downloading resource IDs, that seems too unwieldy to present a serious risk to any particular user. (It's the same amount of risk as, for example, trying to guess the URL of someone's hypothetical photo on the CDN.) Unless there's a way to get a list of resource IDs given someone's username, I'm inclined to think that this is a pretty minor security risk in the larger scheme of things, though it is scary to type a resource ID into their API tester and see a sensitive link come out.
So near the end of the article, author actually shows that it's easy to write a scraper that finds other URLs by enumerating their IDs.
This is one of the reasons many corporations have rules about only using internal messaging applications. Or, block external messaging apps. In environments I've managed, I've always enforced the rule: Anything confidential sent via a messaging app is no longer confidential.
Skype, Facebook & G+/GTalk have all "followed" URLs sent via their applications for at least a few years (that I have noticed). Anti-virus applications installed on computers have done it with URLs in email applications and such too.
One of the large A/V vendors (Trend or McAfee, I don't recall which) had a browser plugin that would follow all of your browsing activity. I used to be amused tailing logfiles to see a hit from a browser, then one of their corporate IPs with a "crawler"-like UA come along a few seconds later.
EDIT last line for clarity.
Skype, Facebook & G+/GTalk have all "followed" URLs sent via their applications for at least a few years (that I have noticed). Anti-virus applications installed on computers have done it with URLs in email applications and such too.
One of the large A/V vendors (Trend or McAfee, I don't recall which) had a browser plugin that would follow all of your browsing activity. I used to be amused tailing logfiles to see a hit from a browser, then one of their corporate IPs with a "crawler"-like UA come along a few seconds later.
EDIT last line for clarity.
While that in itself is not necessarily desire behavior, the fact that this link is accessible to parties not part of the chat is by far the bigger problem.
Definitely. But, it wouldn't be a problem if people understood the implications of using external services in the first place (or were unable to do so via technical means).
That is true. However, lots of internal messaging app is not 'convenient' per say, especially for senior managers. And I see no fix for that problem.
I don't disagree with the lack of convenience, but that doesn't mean choosing convenience over what's right for the company is a good decision.
From a legal and HR standpoint, those types of policies need to be documented for all employees. Senior managers may also have fiduciary responsibility and the reminder is generally a good idea.
From a legal and HR standpoint, those types of policies need to be documented for all employees. Senior managers may also have fiduciary responsibility and the reminder is generally a good idea.
After hearing about people arrested for the content of their private chats on Facebook I basically act under the assumption that everything I do on Facebook is public.
Source? I'd really like to know more about this.
While catching child predators and murderers is a good thing, I can't help but consider that if facebook operated in china, they'd be catching political dissidents, or if facebook operated in uganda, they'd be catching homosexual users.
Exactly. Ideally the communication should be encrypted in a way such that Facebook couldn't decrypt it if they wanted to.
Doesn't that make them liable for anything they miss?
Eg: they're scanning chats for discussions about criminal activities, and reporting what they find to the police. If some people plan a murder in Facebook chat, it goes unnoticed, and they commit the murder, the victim's family could potentially sue Facebook for providing a forum for the planning to take place. Facebook can no longer claim that they're not responsible for the actions of their users, because they're actively monitoring those actions and reporting to the police.
Eg: they're scanning chats for discussions about criminal activities, and reporting what they find to the police. If some people plan a murder in Facebook chat, it goes unnoticed, and they commit the murder, the victim's family could potentially sue Facebook for providing a forum for the planning to take place. Facebook can no longer claim that they're not responsible for the actions of their users, because they're actively monitoring those actions and reporting to the police.
The victim's family could potentially sue Facebook for providing a forum for the planning to take place, but is any judge going to rule in favour of the family? I think you'd have to establish that if Facebook Chat hadn't existed, then the murder never would have been planned (as opposed to the criminals simply using some other channel of communication such as email or talking on the phone).
Just because Facebook is monitoring chat sessions, I don't think it's been established that that makes them liable for any activities which are planned over those chat sessions. They're augmenting the police, not replacing them.
Just because Facebook is monitoring chat sessions, I don't think it's been established that that makes them liable for any activities which are planned over those chat sessions. They're augmenting the police, not replacing them.
I guess I was thinking of Common Carrier status [0]:
The FCC classified Internet Service Providers as common carriers, effective June 12, 2015, for the purpose of enforcing net neutrality. Before that time, the Good Samaritan provision of the Communications Decency Act established immunity from liability for third party content on grounds of libel or slander, and the DMCA established that ISPs that comply with the DMCA would not be liable for the copyright violations of third parties on their network.
My understanding (which may be flawed) is that "ISP" covers things like discussion forums, public chatrooms, and private(ish) chat like Skype and Facebook Messenger, and that the liability immunity goes beyond libel and slander. But, ISPs that filter third-party content are not protected because they're exerting control over the content, and implicitly approve of anything that is not filtered.
[0] https://en.wikipedia.org/wiki/Common_carrier#Telecommunicati...
The FCC classified Internet Service Providers as common carriers, effective June 12, 2015, for the purpose of enforcing net neutrality. Before that time, the Good Samaritan provision of the Communications Decency Act established immunity from liability for third party content on grounds of libel or slander, and the DMCA established that ISPs that comply with the DMCA would not be liable for the copyright violations of third parties on their network.
My understanding (which may be flawed) is that "ISP" covers things like discussion forums, public chatrooms, and private(ish) chat like Skype and Facebook Messenger, and that the liability immunity goes beyond libel and slander. But, ISPs that filter third-party content are not protected because they're exerting control over the content, and implicitly approve of anything that is not filtered.
[0] https://en.wikipedia.org/wiki/Common_carrier#Telecommunicati...
FB also considers "won't fix" a bug I found a while ago that allows anyone to send anyone else on FB a spoofed email that comes from @facebook.com, without knowing their email address ¯\_(ツ)_/¯.
I'm not following how that's different than any other platform that receives email, From: addresses aren't verified. I can send you a message From: [email protected] to your gmail address, what difference does it make if I can send a message from any @facebook.com address, real or imagined, to you at your @facebook.com address?
Ok, if I send you an email from [email protected] with a link saying "Your Facebook account has been compromised" that takes to a phising page, you probably won't click.
If I try to spoof my email to make it look like I'm sending it from @facebook.com, your webmail provider will tell you this email might be fraudulent (and likely place it straight in the spam folder)
With this method, you get a legit email from @facebook.com, but I can edit the content of the email to point to a url under my control
If I try to spoof my email to make it look like I'm sending it from @facebook.com, your webmail provider will tell you this email might be fraudulent (and likely place it straight in the spam folder)
With this method, you get a legit email from @facebook.com, but I can edit the content of the email to point to a url under my control
> If I try to spoof my email to make it look like I'm sending it from @facebook.com, your webmail provider will tell you this email might be fraudulent (and likely place it straight in the spam folder)
I'm looking at the headers of an automated message sent by Facebook (so-and-so shared a post), received by Gmail:
Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) [email protected]; spf=fail (google.com: domain of [email protected] does not designate ### as permitted sender)
This suggests to me DKIM and SPF are not weighted heavily to determine the legitimacy of a message from Facebook (or "Facebook") and filtering would be based more on the body of the message, as it often is, including the URL you specify. I don't see how Facebook email is less secure than email in general, email in general is not secure.
I'm looking at the headers of an automated message sent by Facebook (so-and-so shared a post), received by Gmail:
Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) [email protected]; spf=fail (google.com: domain of [email protected] does not designate ### as permitted sender)
This suggests to me DKIM and SPF are not weighted heavily to determine the legitimacy of a message from Facebook (or "Facebook") and filtering would be based more on the body of the message, as it often is, including the URL you specify. I don't see how Facebook email is less secure than email in general, email in general is not secure.
This is a special case which passes dkim, spf and dmarc.
That's pretty severe surely. Any more information?
Not sure I'm comfortable with full disclosure as I still consider it potentially harmful (phishing mostly, or sending unsolicited emails without knowing the fb login email of a user)
Maybe I should try to report it again on Hackerone, as this was reported through the old whitehat program and the guy who answered never fully addressed the issue or replied to my follow up
Maybe I should try to report it again on Hackerone, as this was reported through the old whitehat program and the guy who answered never fully addressed the issue or replied to my follow up
Sunlight it, if they won't change it. Bad publicity and bad behavior from other actors will only increase the likelihood that the bug gets fixed.
If a company won't listen you've done your moral duty. The last step of responsible disclosure is publication. As a bonus, you'll probably even frontpage HN.
If a company won't listen you've done your moral duty. The last step of responsible disclosure is publication. As a bonus, you'll probably even frontpage HN.
Agree.
Plus he has given lot of pointers so it's a matter of time someone find the comment and start trial-and-error to discover how to exploit the bug.
Plus he has given lot of pointers so it's a matter of time someone find the comment and start trial-and-error to discover how to exploit the bug.
This is a well-known issue with email. The "From" address is not validated. This is all email providers and all email clients.
Can't you just send someone an email to their [email protected] since most people have a facebook email address and don't know about it? And then just use a fake from address of [email protected]?
This sends the email to the login email address, not to the @facebook.com address, you could fake the email headers but that'd get caught by most webmail filters as a spoof.
I think theoretically the @facebook.com email address is now supposed to redirect to primary email too, even though that doesn't really work for me (bounces back)
I think theoretically the @facebook.com email address is now supposed to redirect to primary email too, even though that doesn't really work for me (bounces back)
This probably isn't a popular opinion, but I fail to see how this is a problem with Facebook.
The Google Docs URL is public whether or not you send it through Facebook. It's only secret until someone guesses the link (Edit: maybe not mathematically in the case of Google Docs, but many other services use 'unlisted' URLs without having a long token to guess) - something they can do without the URL even going through Messenger.
If you're sharing passwords or confidential information via a public URL with no authentication and hoping nobody finds the address, you're asking for trouble. I don't blame Facebook for not doing anything about it.
The Google Docs URL is public whether or not you send it through Facebook. It's only secret until someone guesses the link (Edit: maybe not mathematically in the case of Google Docs, but many other services use 'unlisted' URLs without having a long token to guess) - something they can do without the URL even going through Messenger.
If you're sharing passwords or confidential information via a public URL with no authentication and hoping nobody finds the address, you're asking for trouble. I don't blame Facebook for not doing anything about it.
> It's only secret until someone guesses the link - something they can do without the URL even going through Messenger.
Not really - a sufficiently large random number is effectively unguessable in your lifetime. This is no different than sharing a password with your partner in a private Facebook chat and discovering that outsiders can stumble on it.
Not really - a sufficiently large random number is effectively unguessable in your lifetime. This is no different than sharing a password with your partner in a private Facebook chat and discovering that outsiders can stumble on it.
Your one particular file is effectively unguessable, but that does not mean that guessing at files is a fruitless endeavor.
No, actually. It really doesn't take that many bits of entropy for you to be unable to find any documents in a haystack of entries. My file ID is 45 characters of base-64 encoded string. This is a total entropy of 225 bytes. If there are a quintillion files in google drive (a hundred million files per person who has ever lived), you were loading a million possible files per second, you'd still take several times the expected time to the heat death of the universe to randomly stumble upon one.
I would say it's quite different to sharing a password as text in Facebook chat - the URL is certainly in your browser history as well as any other place that has logged your GET request.
Since it's an HTTPS request the GET request won't have the secret bits available for anyone else to see.
It's pretty much mathematically impossible to "guess a link" for a google docs or dropbox URL.
Google Docs maybe - but not every service that uses a similar mechanism.
A URL with a long random token is unguessable, same as your login token/session token is unguessable.
https://m.facebook.com/composer/mbasic/?csid=2d645076-9e83-4...
I was sent this link but upon opening it I'm redirected to a page that says I am not permitted to view such. Can anyone explain to me why I was sent this and what it could potentially mean?
It's infuriating to me as a user that certain aspects of a private 1-1 conversation are made public for a "feature" as trivial as a link preview, especially when it seems the fix would be as simple as having a larger, random identifier.
Does anyone know what will happen when Facebook Messenger is encrypted end to end?
Does anyone know what will happen when Facebook Messenger is encrypted end to end?
This is only a lapse in security if you're relying upon URL obfuscation for security to begin with. It is only actionable if you can MITM or otherwise easedrop and find the graph ID.
Title rating: unreasonably alarmist
Title rating: unreasonably alarmist
> This is only a lapse in security if you're relying upon URL obfuscation for security to begin with.
Which is perfectly reasonable to do: a URL containing a cryptographically-secure identifier is itself a cryptographically-secure identifier. An example would be http://foo.invalid/ed2e898ff0b132202cb0bd0dea0d389a7b6439160....
Another example would be OAuth2 bearer tokens, which may be encoded in the URL as a parameter.
> It is only actionable if you can MITM or otherwise easedrop and find the graph ID.
It looks like the graph IDs are enumerable, rather than being high-entropy, so it looks like you can trawl through the graph looking for interesting objects.
Which is perfectly reasonable to do: a URL containing a cryptographically-secure identifier is itself a cryptographically-secure identifier. An example would be http://foo.invalid/ed2e898ff0b132202cb0bd0dea0d389a7b6439160....
Another example would be OAuth2 bearer tokens, which may be encoded in the URL as a parameter.
> It is only actionable if you can MITM or otherwise easedrop and find the graph ID.
It looks like the graph IDs are enumerable, rather than being high-entropy, so it looks like you can trawl through the graph looking for interesting objects.
I'd say the lapse is using guessable numeric id's, rather than sparse guids.
We've changed the title to (what appears to be) a representative sentence from the article.
Were they using 256-bit random identifiers then this wouldn't be a problem. In that case, the IDs would serve as capabilities to the resources.
Anyone know why they would choose to use incremented integers and not 256-bit identifiers? This seems like a gaping hole to me that makes me uncomfortable sharing links in the tool.
I would much, much, much rather not have link previews than be open to this sort of simple exploit.
Seems like someone could just write a script to pull down a few thousand links, and then search for links from specific sites, private Google Docs documents, etc.
I would much, much, much rather not have link previews than be open to this sort of simple exploit.
Seems like someone could just write a script to pull down a few thousand links, and then search for links from specific sites, private Google Docs documents, etc.
In an earlier thread about this I wrote [1] that the contributing factors FB does aren't egregious by themselves. Specifically, in their view all of their link previews are public, as they were originally intended to catalogue the web.
Having predictable, incrementing integers as IDs for public resources isn't a problem. The problem is most people perceive Messenger as a private chat, and don't expect their privately-shared links to be catalogued in a publically accessible, trivially crawlable object store.
[1] https://news.ycombinator.com/item?id=11873258
Having predictable, incrementing integers as IDs for public resources isn't a problem. The problem is most people perceive Messenger as a private chat, and don't expect their privately-shared links to be catalogued in a publically accessible, trivially crawlable object store.
[1] https://news.ycombinator.com/item?id=11873258
I've been using the destructible.io for temp links. It was posted here not too long ago, useful and if anyone else tries to access it, it deletes itself https://destructible.io
This reminds me of the similar thing in Microsoft Office recently: it automatically shortened all links in documents, even private ones, with a URL shortener service. URL shortener services are, by design, easy to brute force enumerate. Cue popcorn...
The relevant blog post:
https://freedom-to-tinker.com/blog/vitaly/gone-in-six-charac...
https://freedom-to-tinker.com/blog/vitaly/gone-in-six-charac...
Related to this, the W3C maintains a best-practices document about private ("capability") URLs:
https://www.w3.org/TR/capability-urls/
https://www.w3.org/TR/capability-urls/
Also see previous for more discussion: https://news.ycombinator.com/item?id=11868077
The first thing I did was share this particular link on Facebook :)
Precisely because of what the article says.
Precisely because of what the article says.
Please. Delete. Your. Accounts.
What are you waiting for?
Challenge:
Start a decentralized FB clone. Evangelize.
Is it bad that the thing I most want to do with this story is share a link to it on Facebook?
Why asking friend to share a link? Isn't it easier to log in using secondary account...
How would you know the Graph ID number if someone doesn't explicitly tell it to you?
> I wrote a quick script that would take any identification number and increment it gradually to discover other links. It worked
Apparently the numbers, while non-sequential, are not sufficiently large and random to be 'unguessable'. Take a known point and look around it, see if you get something good.
Apparently the numbers, while non-sequential, are not sufficiently large and random to be 'unguessable'. Take a known point and look around it, see if you get something good.
1) There are obvious security concerns thinkable. For example, plenty of websites (google docs, dropbox etc) offer an 'anyone with this link can view document' option. Which is generally safe, given these randomly generated links usually contain > 100 bits of entropy. Access to the link is access to the document, and so the link is a PW.
2) This link can be publicly accessed, despite having only been published in an ostensibly private FB conversation. Facebook has now admitted that the contents of a private conversation can partially be public. That's ridiculous. Not just because it's not safe, there are more things that aren't safe (e.g. sending risque images on Snapchat). But mainly because it's against expectations. Snapchat told me on my first day of usage, in the app, that my friends can save my snaps and that I should keep this in mind, and while many users of Snapchat use it recklessly, I would guess that most are aware of the risks. Users carry much of the burden of responsibility now. But there's no such awareness of the risks of partial contents of a private facebook conversation not being publicly accessible, nobody is aware of this.
3) The response seems wholly unnecessary. It seems to me relatively trivial to require a security token to see this data, much like the rest of the chat itself.
Now I'm not particularly alarmed by the issue itself, it's one of those 'safety in numbers' kinds of things. A hacker would likely be more effective setting up a phishing website and buying an email database, than to collect links and then review them for sensitive data. But the response of FB feels inadequate and unnecessary to me.