Therefore I reverse engineered two apps that are dating.

Image and video clip drip through misconfigured S3 buckets

Typically for photos or other asserts, some sort of Access Control List (ACL) will be set up. For assets such as for example profile photos, a typical means of implementing ACL will be:

One of the keys would act as a “password” to get into the file, plus the password would simply be provided users whom require usage of the image. When it comes to an app that is dating it is whoever the profile is presented to.

I’ve identified several misconfigured S3 buckets on The League through the research. All images and videos are unintentionally made general public, with metadata such as which user uploaded them as soon as. Generally the software would have the pictures through Cloudfront, a CDN on top associated with the S3 buckets. Unfortunately the underlying S3 buckets are severely misconfigured.

Side note: as much as i can inform, the profile UUID is arbitrarily produced server-side if the profile is done. To make certain that right part is not likely to be very easy to imagine. The filename is managed by the customer; any filename is accepted by the server. In your client app its 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 website website link previews

Link preview is something that is difficult to get right in a complete great deal of messaging apps. You will find typically three approaches for website link previews:

The League utilizes recipient-side website link previews. When a note includes a hyperlink to an image that is external the web link is fetched on user’s device when the message is seen. This might effortlessly enable a sender that is harmful submit an external image URL pointing to an attacker managed host, obtaining recipient’s internet protocol address if the message is exposed.

An improved solution may be merely to connect the image within the message if it is delivered (sender-side preview), or have actually the server fetch the image and place it within the message (server-side preview). Server-side previews allows anti-abuse scanning that is additional. It may be an improved option, but nevertheless maybe perhaps not bulletproof.

Zero-click session hijacking through talk

The software will often connect the authorization header to needs which do not need verification, such as for instance Cloudfront GET requests. It will likewise happily hand out the bearer token in requests to domains that are external some instances.

One particular situations could be the outside image website link in chat messages. We know already the software makes use of recipient-side link previews, as well as the demand to your outside resource is performed in recipient’s context. The authorization header is roofed when you look at the GET demand towards the image that is external. And so the bearer token gets leaked towards the domain that is external. Whenever a harmful transmitter delivers a graphic website website website link pointing to an assailant managed host, not just do they get recipient’s internet protocol address, however they additionally obtain victim’s session token. This might be a vulnerability that is critical it enables session hijacking.

Keep in mind that unlike phishing, this assault will not need the target to click the website website website link. Once the message containing the image link is seen, the application immediately leaks the session token to your attacker.

It appears to become a bug associated with the reuse of a international OkHttp customer object. It might be most useful if the designers ensure the software just attaches authorization bearer header in needs towards the League API.


I didn’t find any vulnerabilities that are particularly interesting CMB, but that doesn’t suggest CMB is more protected compared to League. (See Limitations and future research). Used to do look for a few protection problems within the League, none of that have been particularly hard to learn or exploit. I suppose it is actually the typical errors individuals make over repeatedly. OWASP top anybody?

As customers we must be aware with which companies we trust with your information.

Vendor’s reaction

Used to do get a prompt reaction from The League after delivering them a message alerting them of this findings. The S3 bucket setup had been swiftly fixed. One other weaknesses were patched or at the least mitigated within a weeks that are few.

I do believe startups could offer bug bounties certainly. It really is a gesture that is nice and even more importantly, platforms like HackerOne offer scientists an appropriate road to the disclosure of weaknesses. Unfortuitously neither regarding the two apps within the post has such system.

Limits and research that is future

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

This might be completed with powerful analysis, making use of practices such as for example: