Sweet Chat, an Android based chatting and photo sharing application with over 10 million users, has been exposing its users chat content, and photos on an unsecured server.  By using common MQTT related tools anyone can view real-time, the chats and private photos of all online Sweet Chat users.  

Review of the exposed data, has made it evident that there is extensive "Bot" traffic being generated, and that it was used to lure users into spending credits (purchased under paid monthly subscriptions) or to send various gift cards for financial gain.

An analysis of the Sweet Chat service has identified  several poor design, and security practices used in the development of the application.

TLDR; Highlights for the impatient

• Beta System misconfiguration leads to major production exposure
• Bot, Bots, and more Bots
• Users Private Image Exposure
• Fake "Phantom" chat messages between any users

What is Sweet Chat

Sweet Chat, is a "Tinder" like Android chatting application which, according to it's description on the developers site:

"[an] LBS and big data based overseas social application, [that] was launched to help users connect with new friends globally. Up to Jan. 2019, Sweet Chat ranked Top 10 social apps in Latin America, the Middle East, etc., and has become one of the most popular stranger chat apps in many countries and regions around the world."

With over over 800 Million users world wide, uFotoSoft, has a large potential Sweet Chat user base of between 1 Million+ (reported by Google Play) and 10 Million Play (reported on the uFotoSoft website) of impacted users.

Sweet Chat uses MQTT as network transport to provide standard publish/subscribe features within it's application.  Several MQTT vendors are known to have issues with insecure use / installation.

Will the real uFotoSoft please stand up

On a side note, when attempting to locate the company involved with the Sweet Chat application I noticed a discrepancy between the Google Play Store, and the ufotosoft.com website:

Google Play:
1 Stars Avenue, Singapore

uFotoSoft.com:
No.18 Tangmiao Road, Xihu District Hangzhou, China

Is uFotoSoft a Chinese or South Korena company?  Who knows?

Exposure Summary

During a routine scan and data profiling of unsecured MQTT servers, I came across a beta server which was allowing unsecured subscriptions to various wildcard topics.  The analysis identified several records listed below to be of concern:

{
  "chatType": 0,
  "createTime": 1563433768,
  "fUId": 358214950956564500,
  "isRead": 1,
  "msg": "http://social.ufotosoft.com/chat/img/190718/358214950956564481_1563433767855_UF190718983983e8-0281-44b2-9270-498cf36654db.jpg",
  "msgId": "00-P5Lo-1563433768504",
  "msgType": 4,
  "tUId": 5519285
},
{
  "chatType": 0,
  "createTime": 1563354394,
  "fUId": 5519285,
  "isRead": 1,
  "msg": "Do+you+wanna+make+friends+with+me?",
  "msgId": "00-B8GV-1563354393202",
  "msgType": 1,
  "tUId": 348706451478282240
}

After the initial scoring of the data, it became clear that there was a potential for exposure of real-time chat information between users of a "sweetchat" system.

Beta System misconfiguration leads to major production exposure

During the initial analysis it became clear that the rate, and the repeatability of the data exposed was indicative of a beta system, however, it did identify that a full investigation of a potential production system was warranted. As with most applications which use an Android client, the best place to start was with an install, decompilation, and analysis of the production software.

Mobile Android Client

Using the Sweet Chat application link in the Google Play store,  the application apk files were analyzed and decompiled by using the usual tools.

Packet Capture Analysis

Packet Capture is a great MiTM tool for initial application analysis on Android, and while a bit dated, it can identify major problems with network communication security between an Android app, and its backend server.  With a quick analysis, the following issues were identified with Sweet Chat:

1. Use of unencrypted HTTP network communications
2. Use of unencrypted / unauthenticated MQTT traffic
3. Identification of production MQTT servers to target for future detailed analysis

APK decompilation

Other than confirming a few of the API endpoints and  hostnames, the only item of note is the code which is used to sign each api call which can be used to create a 3rd party bot to emulate user responses.

Production MQTT Server Analysis

When analyzing the production Sweet Chat MQTT server, is was evident that there was an initial attempt to prevent some "wildcard" topic subscriptions (E.G. the "#" Topic) , however not all wildcard patterns where prevented, which effectively bypassed all attempted protections.

MQTT Misconfiguration Issues

The following misconfiguration issues were identified:

• Topic Wildcard Subscriptions

  • While some attempt was made to restrict the use of the multi-level wildcard '#', the use of single level wildcard '+' was not restricted.
  • Since all the the topics are at a single "/" level, then by using the '+' wildcard, you can subscribe to all MQTT messages being sent and received on the server.

• Encrypted MQTT Traffic

  • MQTT traffic between the Android client and the MQTT server, are sent unencrypted on port 1883.
  • All MQTT Traffic should be using TLS on port 8883

• Non-Authenticated publishing of MQTT messages

  • Any 3rd party can publish an MQTT message without any username/password/topic enforcement
  • Phantom Messages can be faked to/from any user which disappear after the app is restarted and leave no trace on the SweetChat servers.

MQTT Design Issues

• UserId and Password Authentication
  • Each client should be using a userid/key which is uniquely assigned at signup time, this will allow for per user filters to be applied to MQTT topics
• Per user Topic filtering
  • Each user should get a unique topic which is filtered to allow only that user to see MQTT messages for that topic(subscriber). This will prevent anyone from bypassing / reverse engineering the Android client and connecting to the MQTT server manually and seeing other users messages.
• Use of Non encrypted data
  • if non-entrypted MQTT network communications are used, then the data should be encrypted in transit by a unique per user key.

Application Design Issues

• Use of HTTP
  • The Android application uses http to communicate with the Sweet Chat server, allowing for network sniffing to see all traffic between the client and the server. This allows for API reverse engineering to build 3rd party bots.
  • TLS on port 443 should be used
• Access to private image files without authentication or token expiry
  • All access to private images should be done via an expiring token to prevent access to images by 3rd parties, or after a set duration. Since all images are being stored on an Amazon S3 this ability exists within the AWS S3 Server infrastructure.
  • Better still, all image access should be done via the application API endpoints which can enforce userid access to any images.

Bot Traffic Analysis

After several days of using the Sweet Chat Android client there are several aspects which become obvious fairly quickly.

Bot, Bots and more Bots

There appears to be 2 types of bots which initiate chats with users, and send  scripted exchanges and pictures. They are  easily identified by both the received message content, and by the traffic which can be seen for that particular user in the exposed MQTT messages to many users in the system.

Scripted Bot Responses

By using several trigger keywords, or by responding in a non-typical fashion (Eg nonsense phrases), you can get the bots to respond with the exact same lengthy responses that were previously received.  A clear indication that you are communicating with a Bot.

Bot #1 - System Actor Bots

The "System Actor" Bots are so named, as it's evident by their exposed MQTT messages, that these Bots are run by uFotoSoft.   Typical users, when creating an account will get a userid in the ranges of  4000000 - 7000000  or an 18 digit number starting with 3569xxxxxxxxxxxxxx.

There are however about a dozen  users with the userid in the 22 - 158 range which generate about 40% of the chats on the system (by # of messages sent by userid ). The word / phrase variation of the chat text within those users is also very low.  There are similar phrases used, word for word, across those System Actor Bots.

• Bot 120: I+am+20+,+come+from+MX
• Bot 134: I+am+20+,+come+from+MX
• Bot 137: I+am+24+,+come+from+MX
• Bot 22: I+am+24+,+come+from+MX
• Bot 27: I+came+from+MX
• Bot 137: I+came+from+MX
• Bot 132: I+came+from+MX
• Bot 133: I+came+from+MX
• Bot 127: I+came+from+MX
• Bot 137: I+came+from+MX

By Analyzing the timestamp of messages from these same Bots, you can observe it sending the exact same message about a dozen times within 2-3 seconds to different users on the system. A clear indication of an automated Bot.

You can see many users on the system attempt to converse with these System Actor Bots, and send them "gifts" which you pay for with a monthly subscription.

Bot #2 - Financial Gain Scammer Bots

There are also some Bots which have userids in the "normal" range, but are easily identified as bots, due to the similar nature of the "scam" and response patterns.

After the first day, you will get someone contacting you, and sending you a picture. After an initial awkward chat,  if they send any "Sexually" related response, they will respond with some situation they are in, and need some various Gift Card.  

Eg. "My babe I need a favour from you please dear my data is out I need your help please help me with Amazon card please"

When reviewing the mobile application API calls, and the implementation of unique signatures for each endpoint + post data combinations,  a bit of reverse engineering would be needed to generate the same signatures for each API call.  While not impossible, it would take a bit of effort for someone to build their own external bot client.  If the goal of the bot was to obtain Amazon cards it could be feasible that the creators of the  Financial Gain Bots could be an external entity.

Naked Security has recently published an article on the FBI's warning about increased fraud and money mules on dating sites.  

Image Analysis: the tell tale sign of a System Actor Bot

After looking at chat content patterns and userids, there is still one remaining single pattern which clearly identifies System Actor Bots on Sweet Chat.  When a user sends an image to another user, there is a distinct file name format which is generated by the system.

File Format: (sender_userid)_(epoch)_UF(guid).jpg

Even if you send the same image to 2 different people, there is a unique file name generated for each image.  For example, the following is the same image sent to 3 different people (from my test account)

However if you look at the MQTT messages over a period of time,  you will see the same specific images file names which are repeatedly sent to various users. This should not be happening in regular user use.  An example of such is:

If you look at the epoch date encoded in the dates of the files you will see that these images / Bots have been around for a while.

• Wednesday, March 20, 2019 6:03:37.143 AM
• Sunday, February 3, 2019 6:03:21.559 PM
• Monday, July 30, 2018 12:01:17.918 AM
• Sunday, February 3, 2019 2:21:10.529 PM
• Monday, March 4, 2019 1:23:28.459 AM

Fake "Phantom" chat messages can be created between any users

Due to the nature of Sweet Chat's use of unsecure MQTT as a communications mechanism, chat messages can be forged and published to any user on the system.  This creates a message which only exists within MQTT and not the main Sweet Chat server.

The following messages can be sent:

• "Phantom" message that will only appear on the mobile client.
• Send abusive images to any user
• Impersonate users within an existing chat session,and send a message only the receiver will see.

Private Image Exposure

These files often include images of:

• Minors ( Potential Child Pornography )
• Sexually explicit images
• Pictures of Credit cards, and Gift Cards

Wrapup

As with most modern mobile /SaaS applications the typical design aspects should be followed

1. Design in security aspects from day one, all connections should the Authenticated and Authorized
2. All network traffic should be encrypted
3. ANY application which deals with "sensitive" data or situations should include an 3rd party security consultant.
4. You have to assume that any code on a mobile application can and will be decoded for security vulnerabilities.