Therefore I reverse engineered two apps that are dating.

Video and picture drip through misconfigured S3 buckets

Typically for photos or other asserts, some form of Access Control List (ACL) could be in position. A common way of implementing ACL would be for assets such as profile pictures

The main element would act as a “password” to gain access to the file, additionally the password would simply be provided users whom require usage of the image. When it comes to a dating application, it’s going to be whoever the profile is presented to.

I’ve identified several misconfigured S3 buckets on The League through the research. All photos and videos are unintentionally made general general general public, with metadata such as which user uploaded them as soon as. Ordinarily the software would obtain the pictures through Cloudfront, a CDN on top for the buckets that are s3. Unfortunately the s3 that is underlying are severely misconfigured.

Side note: as much as i can inform, the profile UUID is arbitrarily created server-side if the profile is established. To ensure 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 it’s hardcoded to upload.jpg .

The seller has since disabled listObjects that are public. But, we nevertheless think there must be some randomness within the key. A timestamp cannot act as key.

internet protocol address doxing through link previews

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

The League makes use of link that is recipient-side. Whenever a note includes a web link to an image that is external the hyperlink is fetched on user’s unit as soon as the message is seen. This could efficiently beautiful asian wife enable a sender that is harmful submit an external image URL pointing to an assailant managed host, obtaining recipient’s internet protocol address if the message is exposed.

A much better solution could be merely to attach the image into 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 enables anti-abuse scanning that is additional. It may be an improved choice, but nonetheless maybe maybe not bulletproof.

Zero-click session hijacking through talk

The software will attach the authorization sometimes header to demands that don’t need verification, such as for instance Cloudfront GET demands. It will happily give fully out the bearer token in requests to domains that are external some situations.

One particular instances may be the image that is external in chat messages. We already know just the application makes use of link that is recipient-side, as well as the request to your outside resource is performed in recipient’s context. The authorization header is roofed when you look at the GET demand to your outside image Address. And so the bearer token gets leaked to your domain that is external. Whenever a harmful transmitter delivers a graphic website website website link pointing to an attacker controlled host, not merely do they get recipient’s internet protocol address, nevertheless they additionally get their victim’s session token. This will be a critical vulnerability as it enables session hijacking.

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

It appears to be a bug linked to the reuse of a okHttp client object that is global. It might be most readily useful if the designers ensure that the software just attaches authorization bearer header in demands towards the League API.


I didn’t find any especially interesting weaknesses in CMB, but that doesn’t suggest CMB is more protected compared to the League. (See Limitations and future research). Used to do find a few protection dilemmas within the League, none of that have been especially tough to find out or exploit. I suppose it truly is the mistakes that are common make again and again. OWASP top anybody?

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

Vendor’s reaction

I did so get a prompt reaction from The League after giving them a contact alerting them associated with findings. The bucket that is s3 ended up being swiftly fixed. One other weaknesses had been patched or at the least mitigated within a couple weeks.

I believe startups could offer bug bounties certainly. It really is a good motion, and much more significantly, platforms like HackerOne offer scientists a appropriate road to the disclosure of weaknesses. Unfortuitously neither regarding the two apps into the post has program that is such.

Limits and future research

This scientific studies are maybe perhaps not comprehensive, and really should never be regarded as a protection review. The majority of the tests on this page had been done regarding the community IO degree, and almost no on the customer it self. Particularly, we did not test for remote rule execution or buffer overflow kind weaknesses. In the future research, we’re able to look more in to the security associated with customer applications.

This may be through with powerful analysis, utilizing techniques such as for instance: