Therefore I reverse engineered two dating apps.

Therefore I reverse engineered two dating apps.

Image and movie drip through misconfigured S3 buckets

Typically for photos or any other asserts, some sort of Access Control List (ACL) could be in position. For assets such as for example profile photos, a typical method of applying ACL will be:

The main element would act as a “password” to gain access to the file, and also the password would simply be provided users who require use of the image. When it comes to a dating application, it is whoever the profile is presented to.

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

Side note: as much as i can inform, the profile UUID is randomly produced server-side as soon as the profile is made. Making sure that 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. Nevertheless, we nevertheless think there ought to be some randomness within the key. A timestamp cannot act as key.

internet protocol address doxing through website website link previews

Link preview is something that is difficult to get appropriate in a complete large amount of messaging apps. You can find typically three approaches for website website link previews:

The League utilizes link that is recipient-side. Whenever an email includes a web link to an image that is external the hyperlink is fetched on user’s unit once the message is seen. This might effortlessly enable a malicious transmitter to submit an external image URL pointing to an assailant managed host, obtaining recipient’s internet protocol address once the message is exposed.

An improved solution could be merely to connect the image when you look at 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 allows anti-abuse scanning that is additional. It might be an improved choice, but nonetheless perhaps perhaps perhaps perhaps not bulletproof.

Zero-click session hijacking through talk

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

Among those instances could be the outside image website link in chat messages. We know already the application makes use of recipient-side link previews, while the demand to your outside resource is performed in recipient’s context. The authorization header is included when you look at the GET demand into the outside image Address. Therefore the bearer token gets leaked to your domain that is external. Whenever a harmful transmitter delivers a graphic website website website website link pointing to an assailant managed host, not just do they get recipient’s internet protocol address, nonetheless they additionally obtain victim’s session token. This might be a critical vulnerability as it enables session hijacking.

Observe that unlike phishing, this assault will not need the target to go through the website website website link. If the message containing the image website website website link is seen, the application automatically leaks the session token towards the attacker.

It appears to be always a bug pertaining to the reuse of a international OkHttp customer object. It might be most readily useful if the designers ensure that the software only attaches authorization bearer header in demands to your League API.


I didn’t find any specially interesting weaknesses in CMB, but that doesn’t suggest CMB is much more safe as compared to League. (See Limitations and future research). I did so find a security that is few within the League, none of that have been specially hard to find out or exploit. I suppose it truly is the mistakes that are common make over and over repeatedly. OWASP top anybody?

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

Vendor’s reaction

Used to do get a response that is prompt The League after delivering them a message 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 of weeks.

I believe startups could undoubtedly offer bug bounties. 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. Regrettably neither regarding the two apps in the post has such system.

Restrictions and future research

This scientific studies are maybe maybe not comprehensive, and may never be viewed as a protection review. Most of the tests in this article had been done regarding the community IO degree, and hardly any on the customer it self. Particularly, 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 customer applications.

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

Leave a Reply

Your email address will not be published. Required fields are marked *