Examining Access Control Vulnerabilities In GraphQL: A Feeld Case Study - Bogdan Tiron

Thank you. Hi everyone, my name is Bogdan Tyran and we'll be talking today about access control vulnerabilities in graph and rest APIs and this will be a case study on data exposure on the field dating app mobile dating app. So who am I? uh founder and senior pentester at Forbridge uh with more than 10 years of experience in security accredititation in pentesting psychops and GCP uh especially security and in the past history I've been working in the gambling and uh finance industry what is this talk about so this talk is about the importance of access controls in APIs and rest APIs so according to Wasp Let's see how important uh access controls are. According to top pen for

APIs in 2023 uh access controls were on first place and were known as bola category broken object level authorization and according to our top 10 for web applications uh access controls were again on the category and were known as broken access controls category. So very important for APIs and web apps. U couple of questions for you. First, uh how many uh students we have in the room? I'm curious. Okay. Couple of students, web developers. Okay. Very few. One. Uh how many pentesters? Okay. Couple uh desktops people architects. Okay. and then managers. Okay. Okay. I will try to bring a bit of knowledge for for everyone. Okay. And how are the levels after lunch? Okay. So, at the end there will be a

short summary to summarize everything in case anyone falls asleep. So, I understand you. I I got your back. Okay. About field D. So, we'll be talking about mobile data app field D. Let's see what field D. So in 2014 it launched under the name of trainer. As the name implies it was a dating a mobile dating app focused solely on the subs. So very niche thing. In 2016 because of the naming conflict in the trender they were forced to change their name to field and at the same time it became a more open dating app just like Tinder Bubble and all the others where you can filter by distance age gender there are more than 10 genders uh

couples and location for premium users you can also search by the type of kink you're interested in or the type of relationship you're interested in and on Android has more than 1 million downloads. So this is about the field dating app. Now let's get to uh see how it looks like. So we'll be uh I'll be discussing eight vulnerability access control issues. All of them have been remediated. So I cannot show them or reproduce them to you live but there will be uh screenshots to show you what happened. Oh I repeat the issues have been remediated. Okay. Uh so let's see the app how it looks like. First menu discover profile menu where you can see

photos of the person uh uh you're looking for uh her name uh or his name uh age location a short bio and what the person is interested in. So this is the first menu. The second menu who liked you menu where a basic user you only see the name and the blurred photos of the people who liked you. If you want to interact with these buttons to like them back, you have to pay premium subscription. Um, the third menu, messages, where you interact with the person you matched with or with the group of people you matched with. And the last menu, my prof my profile, where you update your uh profile, your profile name, a bio,

upload your photos, and you buy a premium membership. So, this is how this dating app looks like. Now what we will be discussing today? So there are eight vulnerabilities related to access controls and we will see how this impact the app. First uh issue is uh in the BLA category and the last seven are in the bola category. Does anyone know the uh subtle difference between bopla and bola categories? So bola category refers to having access to data of a different user that you should not have access to. And ba refers to having access to data of other users you should have access to but not to their to some of their subpropies such as admin or some secret data. So

some very a very small uh subtle difference. Okay, let's take them vulnerabilities one by one. See what they are, how to introduce them and the impact. So vulnerability number one, disclosure of profile information to nonp premium user. What is this about? So the the basic user will no longer need to pay premium subscription to get the premium benefit. As a basic user, all you have access to in the menu who liked you is to see the name of the people who liked you and their blurred photos and that's it. However, as a premium user, you will get all the information available about this person that liked you. However, if we use a proxy tool such as Burp

and we intercept this request, so we go to the lights menu, we will uh get this uh /l request with the operation name likes query and we see in the response that for example a person called Sam, imaginary name Sam, uh Sam likes, we didn't like Sam back yet. Um, and we see a photos array and the picture URL. So, if we copy this picture URL and we paste it in the browser, this is the first photo of user Sam and we see it corresponds in the mobile app to the first blurred photo. So, we just as a basic user, we just got premium benefits without paying for them. So, this is the first access

control issue. At the same time there is a parameter in the response called stream user ID which is unique to every user and we will use this uh parameter to read other people's messages. So going next to going to the next vulnerability with other people's messages we can read other people's messages u their chats and in order to do that we will need uh our victim stream user ID which is disclosed in different APIs just like we saw earlier. So let's reduce the issue. We go to the discover profiles menu. We intercept the /graph request with the operation name discover profiles and we pick our target. In this case there is a stream user ID ending in B4F which belongs to

user pro. So then afterwards we go to the messages menu. This is the request corresponding to the messages menu and in it we uh put our victim streamers ID here and the rest of it and once we issue this request to the server in the response we will get the messages of our victim. the first message saying hi grow and if we search by the text property the response we will see that there are a total of 22 messages sent and received by the user claw so that these were the first two issues as we can see uh here below hypo there is a section attachments uh you can also send attachments in the in the messages

And we will use this for getting to vulnerability number three. So this attachments with that we can send to our matches can be photos and videos and the photos can be replayable or time limited up to 15 seconds and the videos can be replayable or play once only in case there is a sensit I I discovered that we can get off them on authenticated. So let's uh see how we did that and reproduce the issue. So to give you the final uh to give you the high level overview when the repable photos are uploaded they will be uploaded first on third party and then made available on two other endpoints on the field co domain at the / photo ID uh photo ID

endpoint. Um and here will be the sender grid and receiver grid. But because the beacon doesn't even uh validate receiver and sender grid, we can just add x. All it matters is the photo ID to be valid in order to be returned. This is for replayable photos. And for the time limited photos the same uh first time um initially will be uploaded on a third party and then the photo will be made available to to other endpoints. U but in this case after the photo gets uh deleted after 15 seconds once the receiver sees it uh we will need the uh senders grid in order to see the photo ID because in this case the back end

will validate the sender's uh grid so it needs to be valid. So we will uh this is the load path from top to bottom and then to exploit it we will go from bottom up and then we will need to find a way to leak this URL to the third party in order to get it unauthenticated which uh there is a feature in the app and we can abuse it in order to get it unauthenticated. Okay. Now let's reproduce the issue. So let's upload a normal photo. There will be there will be a GraphQL request operation name cloudinary generate upload credentials. Then the photo will be uploaded to the third domain cloudinary.com and there will be a graphical request

upload chat attachment where we will get in the response the photo ID and I suspect this request is the one that it will make it available to the other two endpoints. And uh in the end this photo id will be passed in the chat. So u this is how it will look like in the chat. There will be an attachment section saying image and that will be label and this is the photo ID ending in FF4. Now as an attacker let's become the attacker. We read the we put the victim stream user ID. We read victim's messages and we see an attachment section here. We see the the attachment is of type image and this is the photo

ID ending in FF4 and the photo is playable. So we build the URL CD and chat attachments because the receiver sender ID is not validated and then SL photo ID and we get the photo ID of our victim. However, we are authenticated. So ne next step would be how to get it unauthenticated and we will need to prepend the URL with the V1 in front of it in order to leak the URL from the third party cloudinary.com. We copy this URL, paste it in the browser and we just got unauthenticated access to the photo from um uh from cloudinary.com. So this was the first case. Now the second case which is interesting how about if the photo deletes itself for

the receiver only what's the different what's the process uh how is it different from the first case so in in the second case we have an extra parameter visibility millisecond 15,000 which will say the back end to the back end that the photo will be available only 15 seconds and then to access it uh we will need the profile ID of the sender in order to get access to Okay, we repro the issue. We upload the photo. We uh get back the photo ID in a second request for this. Now we become the attacker. We read the uh victim's messages. We see an attachment section saying photo ID that it is an image and that it is playable duration 15 seconds

only. new ones. So, uh now we have to build the URL and in order to build the URL, we copy the photo ID. We paste the receiver or senders in this case was the uh receiver. But because the receiver already saw the photo, it will say attachment has expired. So, in this case, we have to paste the sender's profile ID in order to access this photo. Once we pasted the sender's profile ID, we want it now to be unauthenticated. So we prepare the URL with V1 in front of it as in here. V1 in front of it and we will get the URL to the third party which we can access unauthenticated. So then we just copy the in the browser and

we have access to the photo unauthenticated and the sender or the receiver will have a knowledge that we got access to that sensitive photo. So this were this were the two processes for getting the photos on authenticated. Now let's try a video. For video it's easier process. There will be one request to upload the video and we'll get the URL back uh from a third party domain and then this URL will be pasted in the chat saying uh it is an attachment of type video and it is replayable. So now to to get it as an attacker, we read our victim's messages. We see the attachment section video and the replayable. We copy this URL. Uh we

replace the special character back/000026 with the amperand sign. And then we paste it in the browser. And this is the beginning of a nude video uh from my office. I'm think it's a normal video. Okay. And the last case for videos that are view once only. We reproduce the issue. We upload the video. We get back the URL. The URL will be sent in the chat with a new property saying view once. As seen in the response view once duration zero. We read our victim's messages and we see the response saying video uh replay mode view once. We copy this URL replacing the back sl26 with the amperand sign and again we get access to the video view once only

unauthenticated. Now this is how it looks in the mobile app. Uh before uh the receiver sees the video it says tap to view and after the receiver tapped and viewed it uh in 15 seconds it will say video expired. So it will have uh no more access to this video. However, if you check those URLs, you will have unauthenticated access as long as you need uh to see. Okay, let's move to next. Access control is delete, recover, and edit other people's messages. Uh we discovered that we can recover other people's messages that were deleted in a chat. In addition, we can edit and delete other people's messages. the vulnerable endpoint messages SL message id and the

methods are delete and put so let's reproduce this issue as well we send the normal message to someone got any plans for tomorrow it will be reflected in the response saying 201 created so it worked and the me and we keep in mind the message ID which is unique to this one saying engine 88 ID so we build the URL/ messages/ me message ID with the method delete meaning we deleted and uh will be reflected in the response got any plans for tomorrow. Now as an attacker we read the messages of our victim and for this 88 message ID it will say this message was deleted. So so far everything worked okay the message was deleted. Now if we as an attacker we

apply the delete method again on this message ID in the response we just got back the original message which was got any plans for tomorrow. So all we had to do was to delete it one more time to get back the original. Now how to edit the message again we reproduce the issue send dummy message. My phone number is 1 2 3. And for this one, we get back a message ID ending in 72. We read our victim's messages. We see it is uh 72 as an attacker. The victim in the meantime received a notification saying my phone number is 123 from user D. So as an attacker we edit that message ID and we say my new

phone number is 456 and uh it will say 2001 created mean it worked. So now the victim and taps on that notification it will say my phone number is 456 and there will be a small edit the sign below it. U however the victim will have no knowledge regarding edited the message if it's an attacker or the original sender. So another access control issue um that u that was not checked for vulnerability number five update someone else's profile information. So you can update someone else's profile information including name, sexuality, age, etc. The endpoint is FQL operation name profile update. Let you produce the issue. We are logged in as user 91F uh as seen in this header and we update

our bio to ABCF. However, we change the ID from that of our ourselves to that of user 29C and we will see in the response that for your profile ID ending in 29C the bio has been updated to ABCDF. So this is another example of access control missing. Vulnerability number six. This is one I liked. Uh get the like from any user. Uh the point graphical operation name is profile like. So let's reproduce this issue. We're logged in as profile ID ending in 9 C and we liked a random user profile ID ending in 91 F and it will say sent. So it worked. Uh okay. Now let's reverse these two values and get like from 91 F to S and it will say

you not like a profile you own. Okay, then let's just use some random values here and see if we can control it. So from 63 to 9F while loging us to 9C it will say send. Okay, that's interesting. But the question now becomes who is this 63 profile? So let's query who we just control. If we apply the operation profile query on this 6d3 profile, we will see the imaginary name Annie and that Annie liked liked us but we didn't like Annie yet. So because we have a premium subscription on this mobile app, we will see that Annie uh 26 years old less than 1 month ago. She just liked us. So we know that this issue worked.

Okay. Next issue, next access control issue, vulnerability number seven. Send messages in other people's chats chat. So we discovered that we can send messages to other people's chats even though we are not a participant in that chat. The vulnerable endpoint is / channel/ messaging/ channel/ message and method is post. So using the previous vulnerability, we read our victim's messages and we discover a channel ID ending in 0 BD. Now to this channel ID, we send a message hello from the attacker which will say 2001 created meaning it whipped. The victim will receive a notification from user B and when victim oppos open opens it will see hello from the attacker. However this chat on the

right is between user D and Bogdan and on notification came from the attacker called B. So if the attacker wants he can imperson change his name because in this app the names are not unique and you can change your name to whatever you want. So you can impersonate everyone and then the last vulnerability view other people's matches. The last access control we can check did other people match with and therefore profile information such as imagine name page photos date of birth etc. The vulnerable endpoint is graphql and the operation name is chat list. So let's produce the issue. uh we are logging this profile n29c and we uh apply this square operation on our own profile we will see that if we

search in the response for imaginary name we have a total of three matches however if we change this profile ID to that of a different user and we search in the response for imaginary name uh we see they have 45 matches so this is another access control missing Okay, a remediation. What can developers do? They can implement authorization checks between users. Uh this must be on the back end, not front end. Implement user levels, basic user, pure user, admin user. And based on this user level to implement access controls and restrict the information returned to the user for dev sec ops, people integrate CI security CI/CD tools. However, it's challenging to find this category of

issues for CISO people to do data mapping and implement data protection measures uh such as encryption, access controls, regular testing. Um, and there were some huge fines for Uber for breaching GDPR uh law by transferring a sensitive driver data to its US headquarters. And Tik Tok was also recently fined for GDPR breaches for sending European data to China uh servers in China. Remediation all these issues as said have been remediated. However, it took uh 6 months and afterwards uh we we published our research. It took a little bit longer than expected. Uh full article is already available. There's also on the guardian article an article which mentioned this u and talk more about uh privacy in general and

what are the implications of such uh such a thing. The slide will be published on GitHub as well. And now a short summary about this in hopefully a funnier way than uh me talking. You put one foot in front of the other, but stuff still happen. So, what's up? Polyory is all the rage these days. But what if your data was polymerous? Dating ad field is trying to be something different. They want to give you more options to like dial in exactly what you're looking for. They also exposed all of your information to everybody like all of you. Like like every like whoa. I want to preface this by saying that field now claims they have already

solved all of these problems. Let's talk about what happened. Internet security firm Fort Brbridge did a a test of fields services and field that hey dog anyone can basically do anything without even needing to hack your account. These are things that they were able to do just by product. They were able to view photos that they weren't supposed to be able to see. They'd read, edit, and delete other people's messages. They'd send messages in other users chats. They can edit other people's profiles and they can also view other people's matches. And that's not the exhausted list. So, how do they do this? Did they hack into the main frame? Did they like steal the CEO's thumbrint

to get past biometric security? No. They just kind of looked at the data up. We're going to get nerdy with it. It's time for an education. When an app interfaces with a server, it uses a thing called an API. Basically, Fields API was hella The researchers looked at the data was being sent to their app and found that their app was loading data that they weren't supposed to have access to for the purposes of showing them that they don't have access to the data. Like here's a person picture, they're blurred. You're supposed to have to like match them or subscribe or whatever before you can actually see the photo, but they sent a photo to your phone and

then blurred it on your phone so you actually have that data. Now, the average user isn't going to just randomly stumble upon this, but a bad actor wouldn't have to do a whole lot to get that information. But what's worse is they started them pushing back on the API, saying, "Hey, API, I swear I'm this other user. What can you do for me?" The API was like, "Oh, baby. Oh, baby. I do it all." So, yeah, they were able to pretend that they were the app and say, "Hey, server, um, I'm that person. Let me edit their profile." And the server was like, "Yeah, sure. That makes sense to me." Yeah, you absolutely are them.

Consider this metaphor. You walk into a doctor's office and walk straight to the front desk and say, "I'm John Wman. I want my medical records." And they're, "Okay, John Wman, here. Here you go. Here's your medical records." And then without breaking eye contact, you're like, "I'm Lisa Lisman. Also, give me my medical records." And we're like, "Absolutely, Lisa. Lisa, here you go. Here's your medical record." Okay, cool. Neat. feel alerted of these vulnerabilities back in March and they didn't fully tackle all of them until August apparently. The blog post came out just last week. So, it's really easy to hear stories like this and be like, "Oh, well, it's the internet. My data is everywhere. It's

not worth even bothering." I really encourage you to push back on that sentiment. >> I don't know who this gentleman is, but I find it funny. So I

for similar research on web apps API and fishing feel free to check our blog post. And now a series of questions in case there are any. >> Sure. >> Did what? [Music] >> No. To the best of my knowledge nothing happened. I guess the app was American based or was it >> UK or American? I'm not sure. >> Last time I checked, I believe they have the headquarter in US.

[Music] >> No, just research. Very interesting research. >> How many bits of research does your company do and suddenly that's really broken. We've got to tell them about that. >> Can you be more specific? >> Um for this you stumbled across this site, started looking at it and found a load of broken authorization things that more or less gave you admin access. Yeah. >> How often do you find >> do we find such a thing? >> Is it common? Are there good systems or is this >> It's not that common. It's not that common. So there have been lots of other research projects which failed before coming to this one

or at least not as successful to have like eight vulnerabilities to make a presentation. You might find one or two but most of them compared to this one most of the others I would say fail. >> Yes. to the effects. Now, did you report on the paper to their effects? >> Yes, we reported to them and we were in a kind of permanent contact with them uh back and forth asking for status updates. Uh initially we were expecting something like 1 month for everything to be ready but in the end it took uh more than 6 months uh for everything to be done uh get the confirmation from them and then publish the blog post. So it took quite

a bit of time quite a bit. >> Yes. How many followup attempts have been testing against fixed issues to see if the issues actually are fully fixed? >> As far as I'm aware, I'm not aware of cuz I don't have visibility. So, we did an a check after six months checking. we saw uh that we cannot reproduce them as we did before. We told them that and they were like yeah yeah we we feed them and then we published the blog post they they allowed us but afterwards if they did more we had no knowledge regarding that. >> Yes. This is an example of complete security failure. This is not just watching mistakes. This is a

culture of complete one of these would be bad. This indicates almost entirely probably made it less securely tried. Was is is there a is there a clear um culture of thousands thousands of different particularly mobile apps where there are where this is happening because of a culture not just a couple of stakes the culture where effectively security is just not understood whatsoever. um saying because obviously there's always going to be mistakes out there like someone makes a type or something happened. >> That's a good question and I cannot quite answer your question because I do not know what happened on the client side. So I cannot tell you if it was let's say a startup or if it was a product that was

uh what's the English word externalized uh to a team of developers uh maybe somewhere cheap uh that can deliver pretty fast and they just completely skipped on the security thing uh because they were sted up they might have been constrained by budget as well. So there might have been multiple factors combined with culture maybe as well. So there might have been lots of factors including culture but I cannot point exactly which one determined. >> I guess another way is this scenario here that is extremely common to be that bad or have you seen other examples where completely >> I have seen a more recent example of a of an app called maybe can help me tree

or something. Uh tree does does ring a bell? No, where there were some um um documents like official documents leaked uh as well. Um so it can go even worse I would say having your official IDs uh leaked uh but usually it's not that often but when it happens it happens bad. >> Yes. So how long would you typically spend investigating researching that of that first part and then would you disclose a vulnerability as you found it or wait until you finish? >> Uh that's a good question. The first part it took me a little bit of time because I was doing it in my spare time. So after work and uh that's usually time

consuming today you have free time more you don't. So come back in two days. So it took me a couple of good weeks. Uh and then second question um um how do you report them one by one or multiple ones? Um I don't know to give an exact answer uh because along the way I've seen that some of my issues were getting fixed. So then I've rushed to start reporting them as fast as possible and to finish my uh my project in order to have something to report but they uh told me they have a bug bounce program which I was not aware of it and the link that they sent us was not working.

So at one point I just hurried up and started reporting all of them cuz obviously you are in a uh in a time race with others that might flag it as well. So I don't have a specific answer which way is better one by one or all of them. >> Did you get uh >> no I I was not personally looking for anything. Uh and I didn't even ask. >> I didn't give you anything at the time. >> I didn't even ask. For me it was more important to to publish research.

>> Yes.

uh the impact of my research. Um

>> uh I've I've watched the forums and the people were a little bit upset or a little more upset because of the time frame that took them to fix everything. So on forums people were quite very upset regarding that uh seeing what happened possibly to some of their photos because everything that was happening regarding sending and receiving photos and videos is or was I refra was available on the internet unauthenticated. So some people might have been real upset regarding that. Um and that's the reaction that I saw on forums but afterwards uh I don't think there was anything uh people just

[Music] yeah if there are no more questions thank you very much you