So I reverse engineered two apps that are dating.

So I reverse engineered two apps that are dating.

Photo and video clip drip through misconfigured S3 buckets

Typically for images or other asserts, some form of Access Control List (ACL) could be set up. For assets such as for example profile photos, a standard method of applying ACL could be:

The main element would act as a “password” to gain access to the file, additionally the password would simply be offered users who require use of the image. When it comes to an app that is dating it’s going to be whoever the profile is presented to.

We have identified several misconfigured S3 buckets on The League throughout the asian dating site research. All photos and videos are inadvertently made general general public, with metadata such as which user uploaded them so when. Usually the application would obtain the pictures through Cloudfront, a CDN on top regarding the S3 buckets. Unfortunately the s3 that is underlying are severely misconfigured.

Side note: in so far as i can inform, the profile UUID is arbitrarily produced server-side whenever profile is done. To ensure that right part is unlikely to be really easy to imagine. The filename is managed because of the customer; the host takes any filename. In your client app it’s hardcoded to upload.jpg .

The seller has since disabled general public ListObjects. But, we nevertheless think there must be some randomness when you look at the key. A timestamp cannot act as key.

internet protocol address doxing through website link previews

Link preview is something this is certainly difficult to get appropriate in a complete great deal of messaging apps. You can find typically three approaches for website link previews:

The League utilizes recipient-side website link previews. Whenever a note includes a hyperlink to a outside image, the hyperlink is fetched on user’s unit as soon as the message is viewed. This might effortlessly allow a deliverer that is harmful submit an external image URL pointing to an assailant managed host, obtaining recipient’s internet protocol address once the message is exposed.

A significantly better solution may be simply to connect the image within the message when it’s delivered (sender-side preview), or have actually the server fetch the image and place it when you look at the message (server-side preview). Server-side previews enables extra anti-abuse scanning. It may be an improved choice, but nonetheless maybe perhaps not bulletproof.

Zero-click session hijacking through talk

The application will attach the authorization sometimes header to demands that don’t need verification, such as for instance Cloudfront GET demands. It will likewise happily hand out the bearer token in requests to outside domain names in some situations.

Among those situations may be the image that is external in chat messages. We know already the software utilizes link that is recipient-side, and also the demand towards the outside resource is performed in recipient’s context. The authorization header is roofed within the GET demand towards the image that is external. Therefore the bearer token gets leaked towards the domain that is external. Each time a sender that is malicious a picture website website website website link pointing to an assailant managed host, not merely do they get recipient’s internet protocol address, however they additionally obtain victim’s session token. This is certainly a vulnerability that is critical it enables session hijacking.

Observe that unlike phishing, this assault doesn’t need the target to go through the website website link. As soon as the message containing the image website website link is seen, the application immediately leaks the session token towards the attacker.

It appears to be always a bug linked to the reuse of the okHttp client object that is global. It might be most useful if the designers make certain the software just attaches authorization bearer header in needs into the League API.


I didn’t find any specially interesting weaknesses in CMB, but that will not suggest CMB is much more protected compared to the League. (See Limitations and future research). Used to do look for a security that is few when you look at the League, none of that have been especially tough to learn or exploit. I suppose it is actually the mistakes that are common make over repeatedly. OWASP top anybody?

As customers we have to be careful with which companies we trust with your information.

Vendor’s reaction

Used to do be given a prompt reaction from The League after delivering them a message alerting them regarding the findings. The bucket that is s3 ended up being swiftly fixed. One other weaknesses were patched or at the very least mitigated within a couple weeks.

I believe startups could undoubtedly provide bug bounties. It’s a good motion, and much more notably, platforms like HackerOne offer scientists an appropriate road to the disclosure of weaknesses. Unfortunately neither regarding the two apps into the post has program that is such.

Restrictions and future research

This scientific studies are maybe perhaps maybe maybe not comprehensive, and may never be viewed as a safety review. All of the tests on this page had been done regarding the community IO degree, and hardly any from the customer it self. Notably, we did not test for remote rule execution or buffer type that is overflow. In the future research, we’re able to look more in to the protection associated with the customer applications.

This might be completed with powerful analysis, utilizing techniques such as for instance: