6 ms·

Documents and testimony show that this “man-in-the-middle” approach—which relied on technology known as a server-side SSL bump performed on Facebook’s Onavo ser

Documents and testimony show that this “man-in-the-middle” approach—which relied on technology known as a server-side SSL bump performed on Facebook’s Onavo servers—was in fact implemented, at scale, between June 2016 and early 2019. Facebook’s SSL bump technology was deployed against Snapchat starting in 2016, then against YouTube in 2017-2018, and eventually against Amazon in 2018. The goal of Facebook’s SSL bump technology was the company’s acquisition, decryption, transfer, and use in competitive decision making of private, encrypted in-app analytics from the Snapchat, YouTube, and Amazon apps, which were supposed to be transmitted over a secure connection between those respective apps and secure servers (sc-analytics.appspot.com for Snapchat, s.youtube.com and youtubei.googleapis.com for YouTube, and *.amazon.com for Amazon). This code, which included a client-side “kit” that installed a “root” certificate on Snapchat users’ (and later, YouTube and Amazon users’) mobile devices, see PX 414 at 6, PX 26 (PALM-011683732)(“we install a root CA on the device and MITM all SSL traffic”), also included custom server-side code based on “squid” (an open-source web proxy) through which Facebook’s servers created fake digital certificates to impersonate trusted Snapchat, YouTube, and Amazon analytics servers to redirect and decrypt secure traffic from those apps for Facebook’s strategic analysis, see PX 26 at 3-4 (Sep. 12, 2018: “Today we are using the Onavo vpn-proxy stack to deploy squid with ssl bump the stack runs in edge on our own hosts (onavopp and onavolb) with a really old version of squid (3.1).”); see generally http://wiki.squid-cache.org/Features/SslBump http://wiki.squid-cache.org/Features/SslBump Malware Bytes Article: https://www.malwarebytes.com/blog/news/2024/03/facebook-spied-on-snapchat-users-to-get-analytics-about-the-competition https://www.malwarebytes.com/blog/news/2024/03/facebook-spie...

deleted 2y ago
[deleted]
liuliu 2y ago
That's appalling to say at least. But Snapchat implemented certificate-pinning since 2015. Does that mean either the analytics endpoint was not covered or somehow the certificate-pinning is circumvented in this case?
- KomoD 2y ago
  > analytics endpoint was not covered This sounds most likely
leononame 2y ago
That is insane and I would be inclined to not believe it if someone had told me this. This is such an immense breach of trust that even for me, who has a very low opinion of Meta, it is unexpected. I hope this will blow up as much as it should
- RowanH 2y ago
  So this one time, I had a bug report at a client site. The business was largely a member of _______ religion. Our images wouldn't load in the app, but did on the website. How odd I thought, that doesn't make sense! Luckily I was able to be physically present, so I hopped down with laptop in tow, ssh'd into the server and started tailing logs.... Sure enough all the API requests for data were coming through, but whenever a request for image happened - nothing would hit the servers. What the heck I thought to myself? I said to the client 'that can't be, that's almost impossible....the only way that's possible is if the SSL traffic is decrypted, inspected, and images blocked from being requested, which, is a MITM attack". He redirected me to his IT provider. I phoned them up, and explained the situation. "Ahh so they're _____" Me: "So what does that have to do with the price of fish?" Them : "Content filtering..., you need to talk to ____" Sure as the day is long, the content filter was a VPN all members of ____ had to have on their mobile devices (I don't know how widespread this is, whether it was just this business, or the entire ____ ) I applied to have our system approved, it was, and just like magic the next day photos started coming through. I'm guessing basically it detected any .jpg/.mp4 etc URL's in https requests and flagged it up and blocked them from being requested. You can be sure on those devices the VPN would have been somehow locked in with device management, and there's no way on gods green earth they were getting at Facebook/insta etc. So, it's not just meta. That really hammered home how seamless it can be to end users that they really can't trust what's actually happening on their devices.
  - leononame 2y ago
    Not that I'm a fan of it, but in corps it's pretty standard praxis to have a custom root cert installed on all devices and enforce VPN connections on devices outside the network to be able to MITM all requests and do stuff like content filtering (e.g. NSFW, swearwords and obviously malware). It's the company's device and they give it to you for work specific purpose, you shouldn't use it for personal stuff. I don't think it compares to an app that shadily installs its own root cert on an end user's device to spy on them.
bcye 2y ago
Can someone explain how exactly they were able to decrypt the SSL traffic, is it possible to install a root CA without huge warnings from the OS?
- _joel 2y ago
  By using mitm, basically "pretending" you're the site the victim wants to connect to and trasparently connecting to the actual upstream site. Basically decrypting the traffic locally for inspection before sending it back out. https://en.wikipedia.org/wiki/Man-in-the-middle_attack https://en.wikipedia.org/wiki/Man-in-the-middle_attack. You don't need a root CA, you just need to poison the DNS to point to the mitm server and just present any old valid cert for the domain so it doesn't trigger a self-signed warning or whatever.
  - bcye 2y ago
    How can you take any old valid cert though? I presume they have some sort of private key you don't have access to and it would still trigger an expired cert warning?

deleted 2y ago

[deleted]

liuliu 2y ago

That's appalling to say at least. But Snapchat implemented certificate-pinning since 2015. Does that mean either the analytics endpoint was not covered or somehow the certificate-pinning is circumvented in this case?

KomoD 2y ago
> analytics endpoint was not covered This sounds most likely

leononame 2y ago

That is insane and I would be inclined to not believe it if someone had told me this. This is such an immense breach of trust that even for me, who has a very low opinion of Meta, it is unexpected. I hope this will blow up as much as it should

RowanH 2y ago
So this one time, I had a bug report at a client site. The business was largely a member of _______ religion. Our images wouldn't load in the app, but did on the website. How odd I thought, that doesn't make sense! Luckily I was able to be physically present, so I hopped down with laptop in tow, ssh'd into the server and started tailing logs.... Sure enough all the API requests for data were coming through, but whenever a request for image happened - nothing would hit the servers. What the heck I thought to myself? I said to the client 'that can't be, that's almost impossible....the only way that's possible is if the SSL traffic is decrypted, inspected, and images blocked from being requested, which, is a MITM attack". He redirected me to his IT provider. I phoned them up, and explained the situation. "Ahh so they're _____" Me: "So what does that have to do with the price of fish?" Them : "Content filtering..., you need to talk to ____" Sure as the day is long, the content filter was a VPN all members of ____ had to have on their mobile devices (I don't know how widespread this is, whether it was just this business, or the entire ____ ) I applied to have our system approved, it was, and just like magic the next day photos started coming through. I'm guessing basically it detected any .jpg/.mp4 etc URL's in https requests and flagged it up and blocked them from being requested. You can be sure on those devices the VPN would have been somehow locked in with device management, and there's no way on gods green earth they were getting at Facebook/insta etc. So, it's not just meta. That really hammered home how seamless it can be to end users that they really can't trust what's actually happening on their devices.
- leononame 2y ago
  Not that I'm a fan of it, but in corps it's pretty standard praxis to have a custom root cert installed on all devices and enforce VPN connections on devices outside the network to be able to MITM all requests and do stuff like content filtering (e.g. NSFW, swearwords and obviously malware). It's the company's device and they give it to you for work specific purpose, you shouldn't use it for personal stuff. I don't think it compares to an app that shadily installs its own root cert on an end user's device to spy on them.

bcye 2y ago

Can someone explain how exactly they were able to decrypt the SSL traffic, is it possible to install a root CA without huge warnings from the OS?

_joel 2y ago
By using mitm, basically "pretending" you're the site the victim wants to connect to and trasparently connecting to the actual upstream site. Basically decrypting the traffic locally for inspection before sending it back out. https://en.wikipedia.org/wiki/Man-in-the-middle_attack https://en.wikipedia.org/wiki/Man-in-the-middle_attack. You don't need a root CA, you just need to poison the DNS to point to the mitm server and just present any old valid cert for the domain so it doesn't trigger a self-signed warning or whatever.
- bcye 2y ago
  How can you take any old valid cert though? I presume they have some sort of private key you don't have access to and it would still trigger an expired cert warning?