Examining Access Control Vulnerabilities in GraphQL - A Field Case Study - Bogdan Tiron

hi everyone can everyone hear me especially in the back do I speak loud enough perfect okay so we'll be talking about access control vulnerabilities in graphql and rest API as well and we'll take a specific example and in this case we'll be talking about the field day dating app and how multiple access controls vulnerabilities can lead to a huge impact when combined so we will see in a second multiple such issues and what was the impact uh first of all I'd like to see a quick show of hands how many of you are pentesters okay quite a few devops okay uh security managers cisos okay and [Music] students okay and other security roles okay okay so quite a mix of

everyone I'll try to give a lot of information from the areas okay who am I a senior fer at fordbridge uh I also co-founded it accreditations in pentesting Dev SE cops and gcp security and past history I've been pentesting uh especially in the gambling and banking industry uh for the last 10 years okay what is this talk about so it is about the importance of access controls my colleague nittin touched upon access controls in an earlier talk and we will uh go a little bit more on uh on this topic let's see how uh often we find this issue in the pentests that we do so on in O top 10 API security uh done in 2023 it was uh

number one and it was know it is known as Bola broken object level authorization and in O top 10 for web application done in 2021 it was also on number one known as broken access controls about fil the app the dating app that I'll be talking about today so what what is it about it's a dating app in 2014 it was launched and known as trender uh then in 2016 due to a naming conflict Tinder trender they had to changeed their name and they changed it to field d uh it started as trender just uh as an extra information for it was focused on trms just like like the name suggests and then in 2016 when it

renamed uh it got more open and it was used in dating so it's just a dating app like Tinder Bumble where you can filter by distance age genders more than 10 genders uh Couples location and then for premium users you have multiple functionalities extra functionalities you can search by type of Kink you're interested in group scenarios uh or the type of relationship you're interested in and on Android for example it has more than 1 million uh downloads so this is a a short uh description about the fil application so let's see how it looks like and what are the available functionalities that we can abuse and test for access controls so we have the Discover profiles menu

where you have uh pictures biography and uh what that person is interested in we have the who like to menu and as a basic user we just see the name and some blurred photos but we cannot interact with uh liking them back or rejecting them we also have the third menu messaging where you can message a person or a group and we have the fourth menu my profile menu which is where you up your photos and the description about yourself so this is the functionalities these are the functionalities that we have available to to test now what we found in this uh test for this application so just to clarify all the issues are fixed uh by by the

application there is nothing left uh vulnerable just wanted to clarify this uh at the beginning so the issue that we found was the first one uh in uh subcategory of Bola broken object property level authorization where it discloses information and then the rest of seven issues are part of the Bola category where the access controls were missing or were front end and could have been bypassable so let's take them one by one and see the exact access access controls that were missing one second I got nervous so I started testing this application and uh I entered the first uh actually the second menu as a basic user uh as you can see everything is blurred and

you just see the name so as a basic user you just have access to see the name of the person who liked you and the Blurred photos that you can see as a premium user you can see all these functionalities and access the profile uh because you have paid for it uh however if we use a tool such as burp which is very popular in the pen testing uh industry and we go to this menu who light us then we will uh uh the the mobile app will make a request to to the server which is called the operation name is called lik query sorry for the quality of the photo uh and this lik query will return the

response with all the people that liked us and in this case um it was a woman called Sam uh that liked us uh it tells us the distance uh how far she is from us the age so it literally tells us the whole information about this woman that liked us called Sam um her sexuality uh everything that a premium user gets and we don't even pay for this application so as a basic user you can get uh this information even though it is not shown in the uh in the mobile application in the front end in addition it shows us in the response an important parameter which is called here stream user ID and this stream user ID will use it

in the next uh vulnerability to read that person's message so instead of using uh read person message SL1 we will use this stream user ID which is unique per user so let's see how we can read other people's messages we go to um discover profiles we intercept a request uh and we choose the the victim that we read to that we want to to read uh that uh person's messages cuz we have each person has its own stream user ID so we pick one from our victim then we go to messages and we will have an endpoint uh SL channels and here is where we will add the stream user ID of that victim in

order to read their messages and in this case uh we added uh the stream user ID of the user Sam and we already see their messages in this case we see a message High CLA which comes from Sam and if we search in this response for text we will see that there are 92 messages belonging to user Sam and this is one of them so this is how we read the other people's messages using that unique stream user ID value which is un unique to each user now this is an interesting issue unauthenticated access to other people's attachments from their chats so we read other people's chat and we see at one point attachments in

that in in those uh between those messages so how can we get them preferably unauthenticated in this application you can upload photos and videos the photos can be uploaded either replayable or time limited 15 seconds maximum and the videos can be again replayable and play only once what we could have done as an attacker we could have gotten all of them all the versions on authenticated no matter if it's photo video time limited or play only once and I will show you in a second uh how so this is how the end result would look like so let's say we upload the photo it doesn't matter if it's time limited or not first it gets uploaded and it will

be available from an endpoint like this the first one and then we could have gotten authenticated from a similar end point but the sender and the receiver grid will be here all we need is the sender and the receiver grid and this is the unique attachment ID of the photo so let's uh let's try to reproduce it and see how it's possible uh to get them so in the end these three end points we will have chances to get them where the photo will be available and this one is the most important because we'll get it from here unauthenticated so let's try to reproduce this issue and first we will upload the normal replayable photo it will be a request to field D we

will get some uh values some credentials public ID then the actual upload will happen to to cloud.com and then we will get back an attachment ID which represents the ID the unique ID of the photo um and this unique ID will be uploaded in the attachments uh will be uploaded as an attachment in the messages so let's read the messages again as an attacker we put the stream user ID and we read that uh person's messages we will see an attachment section which contains the attachment the unique attachment ID specific to this photo so in order to access this photo now we will go to the end point SL CDN SL chat attachments SLX and Slash the attachment

ID that we are just reading as an attacker in this uh messages so we just paste it here and we have access to this photo as a different user so we are still authenticated but uh it doesn't matter it seems they do not check that we are authenticated as a different user we still have access to someone's private photo and now the question question is okay we have access to this photo can we get it unauthenticated and the question is yes there is an end point where actually it's the same Endo we just add V1 in front of it and this V1 it will return us the URL where the photo is stored on cloud diner.com and

from this we just copied the URL and we'll have access to it unauthenticated so this is how we uh can get the photo unauthenticated the replayable ones the ones which is time limited and theoretically the photo deletes itself there are two small differences uh in reproducing this uh attack compared to this earlier that I just mentioned first one we will send an extra parameter which will say that the photo will be available just 15 seconds afterwards it deletes itself and then uh we will need the profile ID of the sender the one who sent the photo and also the receiver the one who received it again we upload the photo uh we will receive a unique

attachment ID for this photo as well we read the messages of the victim in order to find this attachment ID because we don't know it and it's quite hard to guess and um then we will uh try to uh get the receiver ID and the sender uh ID in order to use it in the link uh together with the attachment ID and then um the this is how it looks for the sender when he sends the timed photo and this is how it looks like for the receiver uh that receives the photo and once the receiver sees the video the photo sorry which is time limited then it will say photo expired so once the

photo is expired you cannot access it anymore from the third link which would be this one but you can still access it from uh the second link which is this one so contains the sender Grid or you can access it unauthenticated so we again try to access it unauthenticated we add V1 in front of the endpoint it returns us the URL where the photo was um published un authenticated because what they did was deleted the photo but only in one instance out of the three instances available so this was another access control issue and then yes this was the URL so if we go to the URL without being authen ticated uh everyone will have access to

it uh okay now uploading uh uh video is similar uh with the same similar issue uh the the below request we so we go to the message we upload the video and the below request will be made um to the origin stream ii.com and it returns us the URL where the video is uh available from which is streami cdn.com we again um the the URL will be passed in the chat as well so will be published in the uh in the chat we try to this is how it looks like the ID the URL the duration and that is replayable replayable video so we again try to read the message of the victim and we see

this section attachment type video with the URL where the video is available we copy that URL and we will have to replace this uh section SL 0026 26 for the ampers S signed in order to be a valid URL and then uh in the browser we will have access unauthenticated to the video which was shared in the private chat and it is similar for the video that deletes itself again we enter the app we select that the video will be playable only once this request will be done again to streamio ai.com it will be put in the chat and this parameter replay mode will say that it will be view only once we read the victim's

chats uh we again get the URL replace the special character for erson here and we will get access to the video unauthenticated so we can see the video that should be playable only once on authenticated as well and this is how it looks from the application uh before and after the receiver sees the video so it says tap VI tap to view and then it says uh video expired so you cannot click it anymore from the mobile app to see it again but as an attacker you can see it unauthenticated and the victim or the sender will have no knowledge that uh his video is still public on the internet uh for everyone to see okay

what other issues did we discover regarding access controls we can delete recover and edit other people's messages um in order to do that we will need the unique message ID value of the message that we want to recover uh so we can read other people's messages and it's easy to get this message ID value from from those chats the this is the vulnerable endpoint messages message ID with the methods delete and put so to reproduce the issue we use again verp we intercept uh the request where we leave a message to to someone and we leave a valid message uh got any plans tomorrow uh we see that it was posted in the response and it has the message ID 8

a ending ending in 8 ad then we uh delete this message uh with this unique ID 8 ad and we receive a response to 200 okay uh showing the message and the the ID so now let's read the chat as an attacker we connect and we get a different authorization token uh we're trying to read the chat of the victim and we see that this message 8 ad uh the message was deleted so now let's try to apply this method delete again on it on this 8 message ID and as an attacker we get the original message back so how this is how we recover it we just apply a second time the delete method on that message ID and now to

edit it uh we post a message uh to someone my number is 123 uh it was posted and we see the id7 E2 as an attacker again we read the messages to that victim and we see that my phone number is 123 we memorize the message ID 782 uh the victim receives the notification my phone number is 123 this is how it looks like and then as an attacker we modif y the message to hey my phone number is 456 and we apply the same message ID 782 here and uh the response will be updated so now when the victim checks the mobile phone it will show my number is 456 and it shows that it is edited but it

doesn't say by who was edited so um the the victim will have no knowledge that this was modified by someone else by an attacker for [Applause] example okay uh number five issue number five update someone else profile information so we can update everyone's profile information including name sexuality age Etc the the end point is/ graphql and operation name is profile update uh for example we go and update our own profile ID we have an extra parameter profile ID and once I saw it uh the next question is why do you need my profile ID you already know who I'm authenticated as why is this extra parameter needed so I modified it to um the profile ID of my

Victim uh gave a testing uh value ABCD and I've got back a 200 okay uh saying that the profile ID of the victim was updated so this is another issue where access controls were not implemented and it worked issue number six get a like from any user profile so in this issue you could send likes from profile number two to profile number three while being logged in as profile number one so this was an interesting issue uh the operation name is profile like in/ graphql endpoint so let's see how it works so let's send a normal light uh I'm authenticated as user 29c as you can see here and I send the like from my own

profile to 9C to a profile 91f and it's sent so it's normal uh me liking uh another profile then I'm thinking hm how about if I reverse the values and I say that I want 91f to like me to 99c and I get an error message which says you cannot like a profile you own which makes sense that's kind of an okay validation but then you're thinking how about if I create a third profile and I uh Say Hey I want that profile to like me so from user account two to user account free and it worked so I was logged as user account one and I told I want user account to life user account

free and it worked I got back to 200 okay so let's see now who did just like me so let's uh query that profile that just like me and we can see that I've made a person of 26 years old which was active at that time and the name imaginary name was Annie to like me and because I have a premium account and I can see who like me I can see indeed it worked here is Annie 26 years old that like my profile so that was an interesting issue where again access controls were not implemented uh let's see vulnerabil another vulnerability with access controls missing and that is send messages in other people's chats so we discovered that we can send

messages to others people's chats even though we are not participant in that chat and this is the vulnerable uh endpoint SL Channel messaging Channel id/ message with the method post and here uh we use the previous vulnerability to read people's messages to find this unique Channel ID where you want to add your message and we find a channel ID here anding in zob BD and we send a message to this channel ID Z BD hello from the attacker we see it's 2011 okay created and the victim will receive a notification uh showing this uh this message hello from the attacker so this channel is Between Two users D and Bogdan here is D and this sender the

other participant was called Bogdan but it shows in the notification that this is the name of the attacker B so at least you get a notification that the name is that of attacker however in this app the names are imaginary so you can give yourself any name you want they are not unique so you can even give yourself the name of the victim it doesn't matter so you can uh send uh messages in other people's chats without any issue and the last is issue on access controls view other people's matches so we can check who did other people match with and their full profile information uh from name to age photos gender sexuality status date of birth

everything so the operation name is chat list query again in/ graphical endpoint [Music] we we make a request to to query the the victim profile ID uh for this chat list query operation and it will return us uh the all the matches that that profile has with in this example with uh user B so this was another example of access controls missing what are the remediation so for the developers to to implement aut ization checks this should be between users but also they uh they should be U implemented on the back and then not front end because in some of the cases here uh the security controls were on the front end and not showing you the

response uh but you are still getting the response in the in the burp tool just that not displayed in the mobile app then uh the authorization check should be implemented uh for each user level in this case we had basic user and premium user and as a basic user you could access premium level user functionality that is another Access Control uh missing and um um for for devops people you could integrate uh security tools in your C ICD pipeline but uh this will be challenging to find such security issues because you will have lots of grids and these security tools usually cannot test for uh access controls because all the grids were are kind of identical they

look the same how do you know which grid is valid and which grid should not be valid or belongs to a different user so in this case it's it's a bit tricky to to implement such a tool and then for ciso to do data mapping and identify all the personal data that is being collected uh because the otherwise you might risk a a hefty fine in uh uh in one example Uber was fined almost €300 million euros for transferring driving license U uh cards uh acts from Europe European drivers to to US headquarters and breaching gdpr so data mapping is important as well how did the remediation process work um users and and people users of

the app were not very happy with it it took more than five months almost six months for all these access controls to be implemented uh until uh after 6 months we published the blog post and uh uh things were were better uh all the issues have been remediated but users were not quite happy uh for the time it took for such uh issues uh to see the full article you can see it on our uh for bridge blog post there is also the the guardian article which talks about this and potential bigger U uh implications from a law uh stand point of view and then the slides uh I'll be I'll publish them if anyone is

interested on our GitHub and then a short 3 minute video uh to summarize for in case want to fell asleep I'm sorry for being uh uh so uh lacking in energy hopefully this guy will do a better explanation than me hello I put one foot in front of the other but stuff still Happ so what's up polyamory is all R these days but what if your data was polyamorous dating at field is trying to be something different they want to give you more options to like dial in exactly what you're looking for and they also exposed all of your information to everybody like all of you like like every SCH like w i practice this by saying that field

now claims they have already solved all these problems but let's talk about what happened Internet Security firm for bridge did a a test of field services and a leared field that hey dog anyone can basically do anything without even needing to hack your account these are the things they were able to do just like fking in prodct they were able to view photos that they w't be able to see they can read edit and delete other people's messages they can 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 do they hack into the main frame

did they like steal the CEO's Thum print to get past biometric security no they just kind of looked at the data buckle up boyos we're going to get nty with it it's time for an education when an app faes with a server it uses a thing called the API basically Field's API was hella put the researchers looked at the data that 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's picture they're blurred you're supposed to have to like match with them or subscribe or whatever

before you can actually see the photo but they sent the 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 then 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 a profile and the server was like yeah sure that

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 reference and like okay John wman you're your go here's your medical refence and then without breaking ipops back you're like I'm Lisa complet Lis also give me my medical records like absolutely here you go here's your medical okay cool neat he 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 hey hopefully he hopefully he did a better uh explanation than I did in a funnier way I don't know who this guy is

but he does an amazing job summarizing um yeah for other similar research on web Ops API and fishing you can check on our website at fordbridge and now a short quick session of Q&A in case there are

[Applause] any yeah sure uh in cases like this where let's say you are secur company you would have more idea about this if a b finds these findings where photos that is meant to be one view one views are being saved or server is that not a privacy law issue as well because like those pies were not supposed to be saved it was just a one view that is a good question and I would say yes you are right then like uh what I you uh a company as a b supposed to do like just reported to company and then just shut your out on it I guess that's what we did we we reported it to the company and

from that point it was on them to remediate the issue but yeah that's a very good topic to talk about the Privacy one and the law yes did you try cross side scripting no no in in this case we were focused only on access controls and how much damage can we do with just one category of

issues oh sorry I did see you yes um so when you provided your your findings back to the uh the company did the company in question retrospectively go back to their log to see if they could observe the interactions that you took on the uh API to then deter if a bad actor had done the same prior to youing finds that's a great question um I believe they have made a public statement on that maybe even in the guardian article I have to go back and check we did not ask that but they might have done it public in that article from the guardian and they might have said something like we do not have the

logs before a certain period of time so yes I do not know exactly very good question yes um I was just wondering like of all the apps t one percent of have this B so this is the access controls is number one in terms of uh popularity and it is probably the most often that we find so that's kind of it it's probably the most one that we find like out of say 10 apps how many might around that around that yes so I have a financial labs in my home and that's really worrying with this this talk in cont I was wondering for financial trade and things like that they have to go through any extra steps

to be made public on a store for example before um before be done by customers what I mean is any extra cautions take security checks before they're available so that sort thing doesn't happen that's a good question it depends on the company to have their own security testing Department usually the financial uh companies because they handle data they are obliged to have such uh tests per year done at least one because otherwise you get fined so it also depends on the compliance uh policy in your country for example if you're Singapore you might be obliged to do a specific number of times if you're in uh a different country you might not even be obliged but uh yes it depends on the

company yes n question

[Music] the question is so you have you're talking about security PR at Le with respect to generally people say of course Access Control access control operations at theable level but I think you can still over using um HT so I like the example show you can like have you come AC scenario you could potentially over these resers from a different perspective let's say not using to overwrite the same data to a different method not HTTP related instead H good question no but that's an interesting one you might make me look now a different ways to to check but usually we are focused on HTTP https spent testing so web applications mobile uh I'll have to think of different to

think of a different creative way how to override the data from a different uh service perspective oh yeah that's interesting yeah sure yeah can give us a level of effort I guess producing something like this would be the typical like normal pen test required of vord or was it something special in this case uh it was not something special in this case it was something special in terms of doing it outside the work so it took a little bit longer because I was working so this is kind of a side project you just do it when you have time uh so it takes a lot longer cuz today you're available 1 hour tomorrow you're not then in two days

you're available 3 hours then you're not for the whole week so uh it was slightly different and it takes a bit longer if this is what you're asking yes uh did somewh oh yeah yes sure first of all phenomenal thank you sure first of just your question not job it's not job to to stop people upload bad app because anybody can uplo

the biggest on are free antivirus so people an free dirty dirty dirty Google and do regular go through go through the list and take out as many but again it's not it's not their job they so it just be um and yeah I was just going to say like what's the evolution of you're

doing do in this case the the issues were fixed it took them six months um I do not know what's the status from this point onwards regarding security if they if they added or increased their security team I do not know how developed is their security team because I don't have visibility uh probably it was not that big uh taking into consideration took so long so what is the current status in terms of Futures and new features of the app being developed I do not know uh how much testing was adopted hopefully for the benefit of the users hopefully it was adopted than you scar sure did you did you find out were they in a rush together

Mark series overes and you know all I know is that it was a startup in 2014 when they started uh they grew but they might have not focused on security and they might have been focused on let's say growing yeah very interesting talk [Applause]