Subject: Critical network vulnerability
From: phoebe <[email-masked]>
To: [email-masked]
Date: Sat, 15 Feb 2025 11:42:13 +0100

Dear Xiaohongshu team,

my name is Phoebe and I am a security researcher. For the past week I 
have been looking into the RedNote app and discovered severe issues in 
how the app interacts with the server API.

      Technical details

Part of the network communication in the RedNote app (com.xingin.xhs) is 
unencrypted allowing adversaries to listen to the network and capture 
information about the user. This information includes what actions the 
user performs on your service (following accounts, liking posts, sending 
direct messages, etc.), but also information about the device the user 
is logging into the app on. All of this happens in the libxhslonglink.so 
shared library, where it creates a connection to one of the server IPs 
over port 5333 and sends packets containing a 12 byte header and a 
protobuf-encoded payload.

Some of the payloads do not leak too much information, but even just in 
the first couple of packets a SessionAuth proto message is sent and an 
AuthResp message is returned by the server. If an adversary, who we will 
call Eve, captures the SessionAuth of a user Alice, Eve can then save 
Alice's authentication information and at a later point in time 
authenticate as Alice in the API and perform other API actions through 
Alice's account. Essentially giving Eve complete control over Alice's 
account.

In some cases the SessionAuth will have a cipherType field set to 1, 
causing chat proto messages to be encrypted using AES128-ECB, but the 
key used for the encryption is also sent in plaintext in the AuthResp, 
thus allowing Eve to capture the key and decrypt all such packets as well.

As an additional issue, the only information necessary to get 
authenticated with the server is a uid, an sid (token) and device 
information. Considering the uid is public information and the sid looks 
to be a nanosecond timestamp of account creation with some extra digits, 
this leaves about 6 digits (assuming the nanosecond precision is 
difficult to find) of security and device information keeping an account 
secure, which in itself is concerning and should be hardened.

      Solutions

The app is capable of using TLS for communicating with the CDNs, so I 
would suggest migrating the control API to using TLS. Using a 
proprietary protocol usually sounds like a nice idea, but ultimately 
fails in practice, so I cannot stress enough how important it is to 
migrate to protocols that have been scrutinized in the past.

Considering the severity of the vulnerability it would be responsible to 
introduce a breaking change and force users to update instead of 
gradually migrating the APIs, since a transition phase would allow 
adversaries to collect as much information about your users as they can 
while the migration happens.

As for the issue with only needing a timestamp-formed sid and device 
information to login to an account, it is necessary that you improve the 
security of accounts and introduce e.g. a password scheme using hashed 
password strings, or other similar schemes that use information only 
known by the account holder and that cannot be guessed based on 
observable information.

      Publication

The vulnerabilities I am bringing to your attention in this email will 
be publicized by the end of next week (the 23rd of February), even if 
not yet fixed. Although, I do understand updating code takes time and 
effort, so if you wish for me to delay bringing this issue to the 
public, feel free to reach out and we can discuss specifics.

In the end, my main priority is the security of your users, so I am open 
to any questions your team may have.

Kindest regards,

Phoebe