'Nothing Chats' is Not Secure.
Tags: cybersecurity, programming, typescript, startup
Published: 2023-11-18 08:30:42

## Contributors

These findings were discovered in a joint effort between [Batuhan İçöz](https://twitter.com/batuhan), [1Conan](https://twitter.com/1ConanEdogawa), and I. Follow them on Twitter, they are both extremely talented.

## Background

On November 16th, 2023, alongside an announcement by MKBHD, Nothing announced ‘Nothing Chats,’ an application exclusive to their hardware which brings iMessage to Android in a partnership with Sunbird. ‘Nothing Chats’ is a reskinned version of the existing Sunbird application, currently available on the Google Play Store.

After seeing conflicting statements related to the security of their application, members of the Texts.com reverse engineering team decided to take a look into the Sunbird application and their security practices.

‘Sunbird’ and consequently the ‘Nothing Chats’ application require sending your Apple ID credentials to their servers, where they authenticate on your behalf using a virtual machine running MacOS. If you’re an Apple user, this is the same Apple ID which you use to access your notes, photos, iCloud storage, email, and more. Preliminary findings were tested against the ‘Sunbird’ application, but we used the official ‘Nothing Chats’ application to confirm these vulnerabilities affected Nothing’s version as well.

## Notification

Immediately, the Texts.com reverse engineering team noticed a few vulnerabilities and implementation issues which Kishan briefly outlined on Twitter / X. The main issue outlined being a vital request containing important credentials happening over an unencrypted channel (HTTP)

{% embed https://twitter.com/KishanBagaria/status/1725586252630540555 %}

## Sunbird’s Response

Sunbird responded by denying any vulnerabilities, and justifying their implementation, doubling down on it being secure.


![tweets from sunbird justifying their implementation](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/furxx6p74dten906n54s.png)

In short, they made a few claims.

1. Sunbird has ISO27001 certification, which testifies to their commitment towards security.
2. The HTTP request which as subject of concern is only a one-off request to notify of an iMessage connection, which then takes place on a secure channel.
3. The data is encrypted before being sent over HTTP with a key provided over HTTPS.

Whether or not they are using another service behind the scenes is impossible to tell, and they may be telling the truth that this is just a naming conflict between the pre-existing BlueBubbles service and their own internal service.

ISO27001 in this case is irrelevant. While its good to be committed to privacy and security, execution matters.

Other points of the response simply display a misunderstanding of the functionality of the technologies they’re leveraging, the primary one being JWT (JSON Web Tokens). JWTs are signed, not encrypted. Their payloads are accessible, and they themselves act as an access token.

In this case, the JWT is used to authenticate a user into the realtime Firebase database. It allows them to access storage which includes their account information, messages, accounts / connections, attachments, and more.

## Vulnerabilities

### Data in Transit Vulnerability

While Sunbird’s claim that they generate and send the JWT over a secured channel are true, the application immediately turns around and sends the JWT back to another Sunbird service hosted on a load-balanced Express server which does not implement SSL, so requests can be easily intercepted by an attacker.

The endpoint in question can be found at `http://monarch.sunbirdapp.com:8888/register` and accepts two fields in a JSON body. `name` which contains our Apple ID, and `token` which contains our JWT.

Transmitting our JWT over an insecure channel is very dangerous, because it acts as an API token which we can use to access all our data. By nature, JWTs cannot be easily invalidated on the server side. If an attacker gets their hands on it, they have unfettered access to the resource it grants until token expiry. In this case, all our account details, messages, attachments, etc., all in realtime.

By not implementing SSL, we’ve compromised level 7 of our OSI model. If an attacker compromises any point along our network pipeline between the application and the aforementioned Express server, our JWT can become compromised and an attacker will gain access to the information we’ve entrusted to Sunbird / Nothing Chats.

Attacks can be user-targeted, if you’re on a non-WPA network, a WPA network with a cracked PSK, or a compromised network hosted by an attacker, they can easily steal our packets, and your JWT.

The real danger begins as we walk down the network pipeline. Depending on the implementation of the load balancer, Express server, or encompassing network, an attacker targeting the server-end could gain access to any and all users who authenticate into iMessage once their attack begins.

You can see a screenshot of us intercepting a JWT sent over HTTP in the next section as part of a greater attack demonstration.

### Data at Rest Vulnerability

Sunbird does try to implement E2EE, although their implementation is overshadowed by decrypting, and then storing the unencrypted payloads in their database.

When a message or an attachment is received by a user, they are unencrypted on the server side until the client sends a request acknowledging, and deleting them from the database. This means that an attacker subscribed to the Firebase realtime database will always be able to access the messages before or at the moment they are read by the user.

In the following screenshot, we’ve intercepted the JWT. 


![screenshot of reverse engineering process](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t2r6jy2w3zxxw7tj397r.png)

We then take it, and authenticate into our Firebase realtime database. This subscribes us to changes that occur in this 
![screenshot of reverse engineering process](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uvhxa81cua36etjkbq48.png)

At this point, with nothing but the JWT, we could easily create a script which could download all information regarding the user and all their conversations with just 23 lines of code.

{% embed https://gist.github.com/ridafkih/5edb185841ed980d15504beedb0472ce %}

To demonstrate this, I sent myself the following message from my real iPhone to an account linked with ‘Nothing Chats’, and then requested the relevant data from Sunbird by running the script. You can see it is visible in plaintext, sans-encryption.


![screenshot of reverse engineering process](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ns9s1qp1fzc3k6ui2zn2.png)

### Insider Threat / Data Exposure

When you send a message using Sunbird or Nothing Chats, the data relating to your message including the contact information, message contents, and attachment URLs are sent to the Sunbird’s Sentry (a debugging platform), which can then be viewed by authorised parties within the company. This contradicts the FAQ item sourced directly from the Nothing website as of November 17th, 2023.

> Are my messages secure?

Yes, Nothing Chats is built on Sunbird’s platform and all Chats messages are end-to-end encrypted, meaning neither we nor Sunbird can access the messages you’re sending and receiving.
> 

By sending unencrypted outgoing messages to Sentry, authorised individuals at Sunbird would be able to view them from their Sentry dashboard. This makes them susceptible to insider threats. Here is the text content of a request sent to Sentry from the official ‘Nothing Chats’ application. The entire payload includes more messages, and information about the sender and recipient including their contact information.


![screenshot of reverse engineering process](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1iqznn4r1alhne8hwoxf.png)

## Is It Real?

If you’re a ‘Nothing Chats’ user and are viewing this around November 17th, 2023, you may be able to see it with your own eyes. Within a matter of minutes, Batuhan İçöz created an open-source proof of concept which allows you to observe the lack of E2EE in your own browser. 

Simply go to [batuhan/sunbird-poc](https://github.com/batuhan/sunbird-poc/tree/main), and once you have a good understanding of the code, visit the URL listed on the repository sidebar. Authenticate into your ‘Nothing Chats’ account. Send yourself some texts, and observe your account details. It’s important to note this repository contains no decryption methods, so if E2EE was implemented, you wouldn’t be able to see your account and text information.

## Conclusion

Sending your credentials to third-party services always presents a significant risk. It’s always important to stay vigilant with your information, and consider the security implications of sharing any. By sending our Apple ID to a third-party service, we are not only trusting the third-party with our texts, but should they become compromised, our photos, videos, contacts, notes, keychain, and more.