Vulnerabilities in the Feeld dating app

https://fortbridge.co.uk/research/feeld-dating-app-nudes-data-publicly-available/

by notmine1337 • 2 years ago

285 140 2 years ago

fortbridge.co.uk

throwuxiytayq• 2 years ago

Criminal negligence levels of failure, especially given the category of app.

ghostpepper• 2 years ago

Wow you weren't kidding. These are vulns that would have been embarrassing a decade ago.

Incipient• 2 years ago

I think the timeline is the more damaging part too. Not only was their design woefully inadequate, they don't seem to care.

aitchnyu• 2 years ago

I was that cheap contractor. My bosses were oblivious to anything but schedule and bugs surfacing to the client's reviewer. Guess threats of imprisonment in US and EU and data and insurance for data (if photos are not suitable for LinkedIn, you pay eye-watering prices) will be only deterrent.

Of course, the incentives shouldn't promote coverups.

a091• 2 years ago

interesting read - anyone have pointers to other app pentesting walk throughs like this?

mjg592• 2 years ago

I wrote up finding some of these issues entirely independently: https://mjg59.dreamwidth.org/70061.html

qingcharles2• 2 years ago

So the question is -- how many others knew about this and were exploiting it without discussing it? :(

bawolff• 2 years ago

For pentesting, often the company hires people to test under an NDA, and keep everything secret because they dont want to be embarassed.

There are sone public pentests out there. For example https://www.opentech.fund/impact/security-safety-audits/

If you want to read some really hard core security vuln hunting, see https://googleprojectzero.blogspot.com/

ramimac• 2 years ago

https://github.com/juliocesarfort/public-pentesting-reports is a substantial collection of public reports

Off the top of my head, DoyenSec has some good reports in there targeting web apps

Cu3PO422• 2 years ago

It seems like they implemented permission checks purely in the frontend, and not just on one endpoint, but almost everywhere.

While it is conceptually easy to avoid this, I have seen similar mistakes much more frequently than I would like to admit.

Edit: the solution "check all permissions on the backend" reminds me of the solution to buffer overflows: "just add bounds checks everywhere". It's clear to the community at large what needs to be done, but getting everyone to apply this consistently is... not so easy.

dfedbeef4• 2 years ago

You shouldn't be touching the server-side code if you find this hard to keep straight.

Cu3PO422• 2 years ago

Ultimately, I don't disagree.

However, I also try to make it a habit to not blame people for not knowing something. This presents as a structural problem in that company: they needed to hire people who do know how to secure server code and put them into a position to do so. Blame the company and those who decided to save every last penny in personnel cost.

devnullbrain• 2 years ago

Yet after decades of this messaging, we still have these people touching the server-side code. Is it likely another few years of the same messaging will fix it?

jfoutz2• 2 years ago

Eternal September. Everyone starts somewhere, it’s just all the time now. In ten years, the dev will explain to a junior how bad they messed up, and why they have to validate this way. Well, I don’t know, but that’s what I hope.

benoau3• 2 years ago

Junior developer probably opened a Jira ticket, saw a UI of a permission dialog, and did exactly that task with nobody senior enough to know better. That's how you reproduce the bugs that were in-fashion 15 - 20 years ago in my experience!

FragrantRiver• 2 years ago

They didn't ;)

poincaredisk• 2 years ago

I work in security and I don't trust myself to tie my shoes correctly every day.

OPs comparison is great. Bounds checks are easy. There are many overconfident C++ programmers that say they would never introduce a vulnerability like that. But it still happens, because in this class if vulnerabilities it's often enough to forget one check.

dfedbeef4• 2 years ago

I feel bad now I'm sorry to the person I replied to lol. I didn't mean 'you' I meant a generalized third party person.

doix• 2 years ago

Edit: the solution "check all permissions on the backend" reminds me of the solution to buffer overflows: "just add bounds checks everywhere". It's clear to the community at large what needs to be done, but getting everyone to apply this consistently is... not so easy.

I don't see those as the same. Buffer overflow checks are a very specific implementation (and language) detail and can happen absolutely anywhere in a codebase. Permission checks happen at a specific boundary and are related to how you design your application.

Whenever I had any say on how a project was developed, I'd always insist on a clear separation between the development of the backend API and the frontend client code. In my experience, it makes things like this much easier to avoid (and test for). You also get a developer API for "free" (which to be honest, is the main reason I prefer to do it that way).

liampulles• 2 years ago

This can happen very easily I think if one uses "automatic db APIs" on the backend. I'm thinking of some automatic graphql setups for example.

I flag it whenever I see it, but it is very worrying how little thought is sometimes put into the scope of client APIs.

lynx23• 2 years ago

I once caught a webdev doing frontend authentification with a plain javascript dialog. Yes, simple! Put the password in the JS, and do a simple comparison. Why did I notice? Because the owner of the lamp account contacted me that all their data was suddenly gone. Checked the logs, and yep, Google Bot clicked all the "Delete" links in their internal management view. Simply because JavaScript is opt-in :-) Called the developer and educated him on what he just did. I lost a lot of trust in web people that day.

rnts08• 2 years ago

This is unfortunately quite common in mobile apps, because "why would a user look closer in a mobile app".

I want to blame juniors, the no-code and ai-code crowd, but I'm as lazy as they are and will just shake my head and move on.

egamirorrim• 2 years ago

Wow. Remarkably responsible, and compassionate, disclosure.

hackernewds2• 2 years ago

Actions don't match words.

leg100• 2 years ago

What? They did hold off. Their actions matched their words.

arraypad• 2 years ago

Have they included real profiles in the screenshots of the "Discover profiles" menu and the list of likes? If so that's pretty irresponsible even with the faces obscured.

fire_lake3• 2 years ago

God damn it. People deserve better than this. Almost inclined to take a pay cut to go and fix this mess.

tdeck• 2 years ago

However little you're willing to take they can hire a less competent person cheaper.

fire_lake3• 2 years ago

You would hope that a mission driven company like them would care.

Or at least, a profit driven company would care about scaring away users.

greybox3• 2 years ago

They don't need your charity, they need to be fined

jrm4• 2 years ago

And the fact that this, the literal only solution that has any chance of succeeding, is this far buried down in the comments, says so much about this industry.

0xbadcafebee• 2 years ago

I am honestly amazed that these researchers held off for as long as they did on publishing. If crappy startups are given 6 months to close egregiously bad privacy holes like this, they will continue to abuse the privilege they have in collecting this information to begin with. I say give them 2 months and then release. Fuckers need to learn not to play dice with people's private information.

qingcharles2• 2 years ago

The question is -- did others know about it?

e.g. https://news.ycombinator.com/item?id=41517747

tgv3• 2 years ago

And that’s a very good reason never to fill in exact personal data, e.g. date of birth. Especially dating apps seem to need them, but don’t do it. Fill in something within a year or so from your real birthday.

And while this dating app isn’t well known, it caters to people with different tastes (such as bdsm and group sex) and queer people. Needless to say that this is very sensitive in many parts of the world.

marcus_holmes• 2 years ago

Hot take: this is a problem with GraphQL.

GraphQL allows your front-end to query your data. Which is cool. But from the backend this is all really opaque (and usually implemented by a 3rd party library that has no idea about your access control).

Unless you're going to implement your access control in the database itself (not the worst idea, certainly better than doing it in the front end), then it's very hard to unwrap the GraphQL query in backend code to work out exactly what records should be returned/restricted.

Implementing decent access control in the backend means understanding the query and implementing a whole set of models/classes/functions/whatever that grok the database schema and can make decisions about "if the user_id is XXX then it can/cannot see this image in this context" [0]. They obviously implemented this in the front end because that's a lot easier with GraphQL.

I'm not saying this is a good implementation of GraphQL and that therefore the problem lies with GraphQL exclusively. I'm saying that GraphQL makes this mistake easier to make because it explicitly tries to remove the need for the backend to understand the query and so makes this kind of complex security situation harder.

[0] e.g. a specific image may be publicly accessible from the user's profile, or only available to matches, or only in a chat context (but not group chats), and inaccessible at any time from blocked users, etc. You can easily come up with a bunch of complex edge cases for just this one case.

strken6• 2 years ago

It's pretty easy. Treat each resolver that retrieves data like it's a REST endpoint and secure it, and add a query allowlist that you append items to during your CI builds.

You don't need to touch the AST or understand the context of the rest of the query. Just answer the question "can user ABC see the photos of user XYZ?" in the resolver that fetches the photos. If this is inefficient then prefetch some data or use a dataloader.

Now, if you're using some magic library that turns GraphQL into SQL, that's going to be different.

mewpmewp23• 2 years ago

Still I think this type of thing is much more likely to happen with GraphQL including various N + 1 and even worse performance issues.

Like if you imagine having junior engs they will be much more likely to make the mistake with GraphQL than otherwise and it is harder to review as well.

The permissions checking becomes a real spaghetti and difficult to understand in practice compared to just one by one checks.

pistoleer4• 2 years ago

How do you guys bridge the abstraction gap/wall between resolvers to prevent N+1 queries? I have the suspicion that GraphQL is great for exposing a really generic API, useful when you have no idea what shape the front end will take (how often is that?). But it comes at a heavy price; genericity is always the opposite of specialization. And optimization can only occur during specialization.

Having worked with it for a bit over a year now, it really feels like GraphQL is just a different protocol for writing the same old REST CRUD, while introducing a huge framework with lots of annoying magic and language level reflection that isn't amendable to extension or modification according to the needs of the developers.

Is that all worth it, just to reduce the amount of HTTP requests? Is it that much of a sacrilege to add specialized REST HTTP endpoints to remedy that otherwise?

rahkiin• 2 years ago

I did not have this issue when using HotChocolate. You can easily give authorization rules to entities or properties of entities which will automatically be handled. Also to mutations

luxcem• 2 years ago

Any third party GraphQL library worth its salt should implement some kind of ACL. It seems to be the case with the most popular ones [1] [2]. One simple idea is to implement authorization in the data models. GraphQL delegate ~get~ and ~list~ to ressource model that could implement authorization based on the context of the request.

[1] https://www.apollographql.com/docs/apollo-server/security/au...

[2] https://docs.graphene-python.org/projects/django/en/latest/a...

knallfrosch• 2 years ago

GraphQL requires you to either define per-property access, or precompile queries and put them into a whitelist. Everything else leaks data.

https://hasura.io/docs/2.0/security/allow-list/

intothemild• 2 years ago

They were in the press a lot this week, but for earning money.

https://www.theguardian.com/technology/article/2024/sep/08/t...

advael3• 2 years ago

It's been observed by many that making bad things seems to be a lot more profitable these days than making good things

dotps1• 2 years ago

It's always been like that.

The costs involved with maintaining garbage are infinitely more than maintaining something well built.

This is why software is so lucrative.. because the true cost of the software isn't how much you pay for it .. it's "how much is it going to cost you to change to something else?"

gregoriol• 2 years ago

It's not making bad, it's making cheaper/faster. They probably hired less experimented developers or didn't give them proper time to implement the features they wanted.

sureglymop• 2 years ago

Its been a long running joke between me and some friends that if you want to get rich, you should make a dating app.

1. Desperate men come in hordes. 2. You will probably get bought out by match group for millions.

Of course there are moral qualms and also it may not be actually just as easy as that.

greybox3• 2 years ago

Someone should make sure that The Guardian sees this

zx8080• 2 years ago

It's hard to expect any improvement while the personal data insecurity is tolerated without any penalty or fines.

Coolbeanstoo• 2 years ago

I'm not terribly surprised. I use it but would describe it as incompetently put together as my bank app? maybe worse, it barley functions at all. I dont know how they managed it.

forgotacc2404195• 2 years ago

It was so bad when I used it, if it wasn't bizarre memory leak or privacy issues it was extremely poorly executed UX.

Between it and Fetlife there's some huge issues with those communities just sticking with the first app that emerges regardless of quality

fire_lake3• 2 years ago

Given the overlap between those communities and OSS people I’m amazed no one has created a B Corp that does this stuff right.

NoGravitas• 2 years ago

When I used it, I enjoyed the community, but the app was never competently written. Then a while back they had a flag day where they rolled out a new app and a new server to everyone all at once, and most people were not able to log in; those that were lost their premium perks if they were paying customers, likes and chats got lost, etc. I was never actually able to log in, and just dropped the app at that point.

wasma• 2 years ago

Who do you trust? Would tinder and bumble have the same mindset?

INTPenis• 2 years ago

The for-profit dating scene is a quagmire. Sure it can work, I've seen it work, but at what cost?

We desperately need a new platform owned and operated by the people, for the people.

rollcat3• 2 years ago

Hey, sign me up. Outside the "necessary evil" trade-offs inherent to facilitating one-on-one meetups, I would really love a platform that treats people like people, not cattle to be milked for money.

energy123• 2 years ago

The Tokyo government is trying that: https://www.cnbc.com/2024/06/07/japan-pushes-citizens-toward...

rollcat3• 2 years ago

Applies to all dating apps, really: just treat any info you put in your profile as 100% public, for anyone, worldwide. Location is easily faked, other filtering options are about as effective as a lone "do not enter" sign with no fence - I can put any info I like into my profile to fit your criteria and have you show up in my feed.

Chats? The only IM apps with functional E2EE are: Signal, iMessage, WhatsApp; and even those have trade-offs. Treat everything else as readable by some third party, and dating apps by design need to be able to look into people's chats to be able to handle harassment cases.

That of course is no excuse for having gaping security/privacy holes, but you're trading off quite a bit of privacy by design; it's like meeting in a public space where you can feel a little bit safer with someone you don't know yet.

I'd say if you're concerned with any of that, go meet new people IRL, but there are 100% legitimate cases where this is not the most effective strategy (e.g. Feeld's primary target audience).

throwaway20372• 2 years ago

Lots of great points in your post.

Real question: Has WhatsApp ever had a security leak that we know about? Example: Someone can break into accounts, or chats were leaked?

mikkelam• 2 years ago

This is pretty funny. I've been abusing this shitty API for a while to see who likes me in this dating app.

I didn't realise the problems were this bad. They've had massive issues with their tech stack from a user POV. I've multiple times had my phone running incredibly hot while using it.

throwaway-xdfef2• 2 years ago

It gets worse. As of this moment it's impossible to delete your account data due to errors.

(Ask me how I know)

Throwaway123129• 2 years ago

Useful context is that they completely redid the app from scratch in 2023 using a contractor instead of in house developers and the launch was not very smooth

https://mashable.com/article/feeld-app-down

Ekaros• 2 years ago

Saddest part is that this sort of stuff or at least not proper authorization checks is very common. I do not really know what is the solution at this point. Clearly not enough developers care. Or can stop it...

Is it education problem? If so if there was training budget a day or two running against some simple capture the flag exercise might do a lot...

Klonoar• 2 years ago

Anybody who's ever used this app is probably not surprised to hear this. It's been a shitshow since day one, one of the buggiest apps I think I've ever used.

Even with a full redesign/rebuild over the past year it still is nothing but glitchy software.

elric2• 2 years ago

The online dating space (I use the term liberally) is a huge fucking mess. There's only 2 or 3 companies with an offering that is anywhere near useful, and they're either evil, incompetent, or both.

Maybe it's time for an open source federated dating service or something. Or at least something that doesn't sell your data, doesn't leak your nudes, or doesn't get you beaten up/raped/murdered. Probably easier said than done.

ChiperSoft2• 2 years ago

I’ve been conceptualizing one for a few years, but just don’t have the free dopamine to build it alongside my day job.

ActivityPub even has the mechanics to facilitate it through publishing Person records. There is MASSIVE space for innovation, especially if you prioritize on non-monogamy, non-heterosexual, non-gender-conforming needs.

Dating apps are a REALLY hard space to get into, however. You need a cumulative mass of users in a given area before they’re useful, and monetizing it inevitably means making the app less useful. There’s a reason okcupid went to shit after it stopped being a non-profit.

And then there’s the moderation problem…

diggan2• 2 years ago

Now you've piqued my interest, especially if it could be done in a safe but distributed way, without a focus on profits.

How you'd envision it to work, considering the open nature of ActivityPub but the need/want from the users to remain private when using dating applications/protocols?

mikrotikker• 2 years ago

I feel like ones nudity is something that should stay in analog form, where you have almost complete and absolute control over the distribution of it. If people want to make digital copies of their analog form that's their right to do, but they need to realize that no system is nor ever will be secure enough to prevent their inevitable release and distribution.

This is something that young people especially don't take into account; the potential and probable long term ramifications and embarrassment. Providing such a facility is merely inviting such negative effects.

elric2• 2 years ago

I see where you're coming from, but I don't agree. It should be possible for people to share stuff (nudity or anything else, really) with the people they want, without worrying that $incompentCompany will leak it for all to see.

That, and a bit of embarrassment isn't really all that bad. The problem is that the leaked stuff keeps on circulating :-(

I have a pet theory that seeing more "real" people in the nude is good for your body image. There's a lot less nudity than there was 30 years ago (from movies to locker rooms and everything in between), there's a lot more shame, and everyone is wistfully staring at Instagram garbage.

greybox3• 2 years ago

This is utterly horrifying, clearly absolutely zero thought was put into security at all.

I'm a game developer and we put more effort into keeping our game fair than this company does in keeping it's users safe. They should be sued into oblivion.

forgotacc2404195• 2 years ago

Zero thought was put into anything.

Before I realised the app was a buggy mess I was very surprised to see it had an interests section that provided no context for the interests. For example: virtually everyone had Domination or Submission as one of their interests but no context whatsoever of which role they wanted. To not realise how fundamentally wrong this is for that scene implies they're clueless across the board.

tgv3• 2 years ago

Do note that profiles in a dating app are in principle accessible to everyone. You open the app, profiles appear. There's no ACL or anything like that.

Messages and private pictures is another matter.

stef252• 2 years ago

View other people’s matches

"BRB going to slaughter everyone my wife has chatted to"

Hard to believe the levels of incompetence here

They have investor funding ... how come no due diligence was done ?

throwaway-xdfef2• 2 years ago

(This is a throwaway account but I've been on HN for a decade)

I just read this and attempted to delete mine and my partners profile data. The process is currently totally broken in-app. There is no way to proceed past a certain point. There's nothing self-identifying about us in the app but still.... I'm furious.

spiffytech• 2 years ago

With an article like this, it wouldn't surprise me if there's still a way to delete your data if you intercept the network traffic!

bogdan_t• 2 years ago

Easy to understand explanation: https://www.instagram.com/p/C_-8CdRpo86/

The Guardian article: https://www.theguardian.com/business/2024/sep/17/dating-app-...

Vulnerabilities in the Feeld dating app

Related Stories