Network Security Issues in RedNote | The Citizen Lab

Privacy News
1

RedNote has been caught not using TLS in the app. This is a basic network security practice that should be a no-brainer for any developer.

  • We analyzed RedNote on Android and iOS for network security issues and found that all versions of RedNote fetch viewed images and videos over HTTP, which enables network eavesdroppers to learn exactly what content users are browsing.

  • Some versions of RedNote contain a vulnerability that enables network attackers to learn the contents of any files that RedNote has permission to read on the users’ devices. This issue was introduced by an upstream software development kit (SDK) used by RedNote, NEXTDATA, but is not present in Android versions downloaded from the Google Play Store nor in the iOS version.

  • All versions of RedNote that we analyzed also transmitted insufficiently encrypted device metadata, sometimes over TLS without certificate validation, enabling network attackers to learn device and network metadata, such as device screen size and the mobile network carrier. This issue was introduced by an upstream SDK, MobTech.

  • We responsibly disclosed the relevant issues to NEXTDATA on November 13, 2024, to MobTech on November 26, 2024, and to RedNote on January 16, 2025. At the time of publication, no party had responded to our disclosures.

  • All the issues we discovered could be mitigated through the use of TLS. Yet again, this work highlights the importance of using well-supported encryption implementations.

2 Likes
2

Anyone expecting privacy or security from an app named for propaganda made by a man responsible for millions of deaths….just has a cranial processing deficiency.

1 Like
3

Not gonna lie, I didn’t even know it was still possible for iOS or Android apps to fetch content via HTTP these days :eyes:

As it turns out, there are massive possible exceptions to the App Transport Security rules :man_facepalming:

Some examples of justifications eligible for consideration are:

  • The app must connect to a server managed by another entity that doesn’t support secure connections.
  • The app must support connecting to devices that cannot be upgraded to use secure connections, and that must be accessed using public host names.
  • The app must display embedded web content from a variety of sources, but can’t use a class supported by the web content exception.
  • The app loads media content that is encrypted and that contains no personalized information.

Still though, pretty sure they would’ve had to go out of their way for their security to be so bad.

1 Like
4

The blog notes that the CDN was delivering thumbnails and other media over HTTP cleartext. Unclear why, but CDNs will deliver content over both HTTPS & HTTP (downgrade attacks, notwithstanding).

The other stuff has custom encryption (but no auth) even if the underlying transport is HTTP. Doing so is not uncommon. Ideally, you implement your custom protocol over raw TCP/UDP but it is safe to assume, if you’re a very popular app, that middleboxes and firewalls will allow HTTP through, but block your custom TCP/UDP protocol.

You’d find some VPN apps implement some variant of this (ie, custom encryption scheme over cleartext HTTP) to connect to their control plane. In fact, firewall-busting proxy protocols (like X2Ray, Trojan, V2Ray, Hysteria, VLESS) rely on such a setup (HTTP) for data plane.

It is bad sure, but not as bad as the title would imply.

1 Like