Breaking the Guest List: Hacking Invitation Systems for Fun and Profit

Hello everyone. It's uh it's a pleasure to be with you all here. It has been an action-packed 3 days. A lot of talks, a lot of communication, a lot of networking. So, it was super amazing and I can't really believe that we are getting to the end of it. It has been an amazing event. So, I would like to start by thanking all of you here. Also, for the people watching the stream, thank you very much. Um, I would like to thank Besides Las Vegas for hosting me here today. But more importantly, I would like to thank Besides Las Vegas for uh the proving ground because the first time I ever spoke publicly was in 2020

uh remotely in the proving ground of besides Las Vegas and since then it has been great speaking. So thank you for having this. So uh for our talk today we will be having breaking the guest list hacking invitation systems for fun and profit. So without further ado let's go right in. So a bit of who am I? Uh I'm Ali. I am originally from Cairo Egypt uh on some platforms. I'm also known as logic breaker. So you can find me there. Uh I am a security and privacy engineering lead at bending spoons. I have been bug hunting for almost 10 years now. uh and I'm very security enthusiastic about everything related to security in general.

Uh I have been a speaker at besides several besides conference across many countries spoke at black hat before. I really love the community sharing with the community. So here we are. Uh one thing that I also really love is business security and the intersection between them. And this is actually the topic of today. It's how business and security interplay together. It's not about process scripting. It's not about SQL injection. It's about understanding the business model, bisecting it and breaking it more or less. So let's go. So for those of you who don't know, quick introduction about business logic vulnerabilities. So business logic vulnerabilities are basically uh a type of vulnerability that appear due to the

discrepancy between how developers and uh maintainers develop stuff versus how attackers perceive the application more or less. So the peculiar thing about business logic and actually it's why AI still needs us more or less is it's really dependent on two things. First of all the mindset of the person developing the application but also the mindset of the attacker looking into the application. So everybody had their own methodology but we are trying here to extrapolate some common themes um when it comes to invitation systems. So just to give you an example before we dive into invitation systems regarding business logic vulnerabilities. Let's assume let's take for example two applications. The first is a data inensive application like for example um

a data processing environment data bricks for instance the most important thing in data bricks is come on the data I mean this is their uh core value so as an attacker probably if I would like to compromise data bricks what I would like to do if that I would like to do this to get the data right I mean this is uh the actual value of the application now let's take a look at another application which is basically AI based It stores no data. It just for example generate images based on some image that you provided. So you provide an image, it provide you an avatar for you for example and it does it firmly. So no

data storage. As an attacker when I approach such an application, what I would think of is okay, how can I abuse the GPUs behind this very nice AI application to generate stuff for free? Maybe for example to use it and resell the service at a reduced price. So you can see two applications. most of them are software web applications or mobile applications doesn't really matter and yet the threat model is substantially different and having a one-sizefits all for everything unfortunately doesn't work out so invitation systems what are we basically talking about we are talking about any kind of invitation system and we will see here that it really doesn't matter it can be an invitation system to a

Facebook group it can be an invitation system to a B2B application. So any application that operates in the B2B uh business, you'll probably have a team or an enterprise subscription where you can add seats uh so that you collaborate with people because I mean you don't operate alone and you need to send them guess what invitation. So this is invitation systems here as well and the core purpose of the token that we will see that regardless of the type of the invitation system the mistakes are the same. The way to secure them is more or less the same. of course taking into account some peculiarities of applications but again it boils down to basically the same thing.

So why invitation systems? On the left you can see the invitation uh template basically from Facebook to invite people to uh Facebook groups. Uh on the other side you see inviting members to Snapchat business accounts. And the question is why invitation system? Like I mean why do should we care? because it's very ubiquitous like nowadays social media strives on people sharing with each other inviting each other either to groups to the social media application or whatever. So this is how they grow. Uh again if you are in a B2B company or you use any B2B uh software you probably know that you have seats and you invite people to join your um application. So the ubiquity of this

makes this flow very common and yet the same mistakes happen over and over again. So why why is it I mean why it interesting an invitation system because it is what we call it's very easy to use but also trivially to abuse in this case. So why this it's due to the discrepancy between how the developers uh perceive stuff versus how the hackers perceive uh the same stuff or the application itself. So just to take an example email tokens are secure enough. I'm a developer. I'm developing an invitation system. I I have invitations via email. I add a token and I say, "Okay, I mean this is a very long token. Nobody can guess it." Guess what? They

probably can. It really depends. So, for example, if you generate a hash of the user email and this is the invite, I mean, come on. They can still generate it. It doesn't mean that because it looks random, it's actually random. Maybe you have a token which is very short like I mean a four character uh token or a serial number like basically invitation is invitation one invite two invite three so just because something looks that random it doesn't mean that it's actually random in this case uh onetime links so you as a developer I develop for example an invitation to a Facebook group I assume that it's intended for X only X will be able to

use it and only X should be actually using Right? This is not how it works as well. Like I will try to take the invitation, load it into many accounts as much as I can, see if this allows me to gain access to basically more stuff. So gain access to adding people to the the group more than a single person as we will see in one of the attacks. So just because you have an assumption, if you don't do the technical realization, if you don't do the technical um controls that support this, it will actually uh not work for you. The biggest sin in uh development is assuming that UI controls protect you. It doesn't, believe me. No. So UI does

not enforce security controls. You can't rely on it just because you think that the application is designed in a specific way externally people will not follow it. If the API still allow them to do something they will do it because I mean the APIs come on they are public that you can look into the developers portal you will see them and it's end game. So there is no point. Uh the final thing about this assumption and I mean we can go to hundreds of assumption but uh for the sake of time which is invitations are isolated per user like I invite X the invitation will not work in Y unless you do something about it guess

what it will as we will see. So the difference in perception causes a huge gap as we will see in the attacks ahead. So before we go into the actual exploits, let's do a quick exercise together and try to look into this uh invite. So the invite goes as follows. We have an httpsac example.com. Okay, nice. They use https. Nobody can intercept their traffic. I mean assuming they use it correctly. But then the interesting part starts. We have four uh query parameters. We have group ID, sender ID, member type, and token. and how I would actually approach such uh an invite that first of all I will ask myself the following questions so group ID nice first of all it's a numeric ID

so probably the groups are sequential that's nice because I don't need to do effort to guess the group ID nice it's not an issue on its own but the next thing I will try what happen if I change the group ID from 1 to three to say 1 to four am I able to join another group if so this is actually a big problem because I I'm joining groups that I was never invited to. I have no access to. But guess what? If there is no validation, I can the sender ID. So, uh, back in the day, there was a social media platform. I don't recall exactly which one, but when you joined, it tells

on your profile that you were invited by X. So, let's assume that X is the CEO of a very important company. And the sender ID is not checked. So instead of 345 I just add the ID of this very important person. It will appear on my profile that I was invited to the platform by this person. Maybe they have um a valid uh account meaning that it's very wellnown and I can take it from there to tell them okay I know this very important person. He is my friend and then maybe I can use it for spam for fishing for whatever. In fact I mean it's an integrity problem by itself. It's just how you want to exploit it.

And then we go to member type. Okay. Nice member type two. That's super interesting. What happen if we put member type zero or four? Do I get an admin privilege? Do I get a super admin privilege? Maybe. Again, if this is not checked, we are back at it. And then the last and the actually the most interesting uh one is the token. The token here it can have all sorts of problems. So first of all, it can be guessable like you are hashing the email or the time stamp for example. Um it can be very short for example a numeric token which is six digits I can just enumerate it it's not a problem uh it

can be that the token can be replayed so it does not expire so all sorts of problems will happen can happen with the token so I mean there's quite a lot of thing that can happen here so I know what you have been thinking I mean I have been talking for 10 15 minutes no exploits yet it's pretty boring uh we will get into the the interesting stuff. Now, uh by the way, uh by the at the end you will have all the slides. So, I mean you don't need to take pictures. You just can focus here and you will be able to download them if you want. So, let's start. And the first exploit for today is once

friends always friends and actually the name uh more or less leaks what we will be talking about. Maybe something about uh friendships on Facebook. We will see. So back in the days before uh so when meta was Facebook and uh alphabet was Google in this case. So around 2015 uh Facebook was still in the growing phase. So it had a feature in which you can basically invite people to join the platform. So uh my friend is not on Facebook. So I sent them an invite to join uh facebook.com. uh and with the invite once actually they accept the invite not only do they join the platform uh but they also become my friend so they also become my

friend which is very sensible when you think about it like I mean I am inviting you to a platform probably because I want you to be my friend so two for one everybody's happy so very interesting so until now everybody's happy somebody invite someone to Facebook they join Facebook and they become friends voila no worries the problem starts later. What if my friend does not become my friend anymore? Like I mean they turn to be malicious. I want to unfriend them. I mean come on, life happens. So in this case, I mean I unfriended them. Done, right? I mean should be as easy as this. However, the invitation that you sent maybe a few years ago will still haunt you. I mean

uh past mistakes does not uh go unnoticed. So, what the attacker or basically the uh bad friend who was invited years ago can do, they can go to their email, click on the same invite, and guess what? They can return to be friends again because the invite still works. It will return them to be your friend and that's it. So, you don't need to do anything. Just go to your email, add them as a friend, and no matter how many times they unfriend you, you can go to the invitation, read them as a friend, and that's it. I mean, it's that simple really. But now I I mean I see some of you you're talking okay but

maybe I can block them right I mean why don't I just block them if they are this malicious uh it's not that easy so the idea is as follows first of all as I told you uh the malicious friend can do this trick as many times as they want you and friend they return back but think about another part of the story they also can unfriend you so the flow can go as follows I as a malicious friend I will add myself to your friend list, maybe send you a message or see your friends only post or whatever and then I will unfriend you and later I want to be returning to your friend. I'll just click on the invite and do it

again and again. But then to answer the people thinking about okay but they can block me. Back in the days Facebook didn't have any uh abuse prevention against the block feature meaning that you can block and unblock the same person as much as you want. So there is no limit. Now there is a limit I think of 24 or 48 hours something like that. So what you can do is that you can take the first step as a malicious friend. You can block the uh person so that they can block you. So I am the malicious friend. What I will do is that I will block you. I want to see your friends only post. I will unblock you. Add you

as a friend using the invite. See your friends only post or send you a message and then block you again. And guess what? If I block you, you can't block me. This is life. So that's it. Basically, even the block feature was not able to prevent this and the invite as far as I know never expires. So a very bad situation I would say. So uh this is what the one that we discussing. Sorry, this is about the block feature. Okay. So let's do uh some reflections like I mean what did Meta did done wrong here that caused this problem. So we can attribute this to at least three elements. First of all the invites never

expire. So it's it doesn't really matter if it is few weeks or a year the invite uh as far as I recall didn't expire at least for a sufficiently long period that uh it's problematic. uh the invite actually should have expired even earlier meaning that the invite should have expired once I accepted it back in the past but this also didn't happen so it's not a one-time use invitation and invitations by nature should be one-time use unless I mean there is a reason why not to do so but generally they should be a single time use and the last thing is that there was actually no mechanism to revoke the invitation so I can't block you I can't unfriend you because

you will return again and the invitation I sent years ago I have no control over it. So I mean uh it's end game basically. There's nothing that I can do. So let's jump to the second uh exploit for today and it's called the now you see me and we will see why because I mean we will play some magic tricks uh in a second. It's also targeting meta by the way. So in this one we are targeting another invitation flow uh which is the groups uh invitation flow and I mean groups invitation flow have actually two ways. You can first invite your friend to join a Facebook group using their Facebook account and this is not the uh

flow we are interested in. We are more interested in the flow which invites people via email. So you send uh people an invitation by email and then they can join uh your Facebook group. Um it should be simple right? I mean you send somebody an invitation. The invitation appear I mean let's assume that you are the admin. The invitation will appear here. Okay you invited invitedgmail.com. There are very nice three buttons here that you can sorry three dots here that you can press on and delete the invite which is also an upgrade from the previous attack where there was no way to revoke the invitation. So it's actually a good upgrade. Uh not so good.

I can make the invite vanish. So here's the thing. This is the invite that I receive. And just to make sure that we are following up in this case uh we have one of two cases. First of all, I might be invited to the group and I am the malicious person or I'm the malicious actor. Or it can be that both I mean I'm the admin and I am malicious and I'm exploiting this to gain um basically persistent access to the group. We will see how in a second. So this is the shape of the invite. Uh you get an invite telling you okay hey uh X would like you to join them on Facebook.

Join the besides Las Vegas group. Very nice. Uh you click join group. You would be prompt with uh a thing telling you, okay, hey, do you want to join um this group or not if you would like to join, you press yes or you decline. And as we see in this slide, the invited there in the admin panel. But here's the trick. We would like to make this invitation disappear. And once we make this invitation disappear, the admin loses control over the invite. It's super easy. You navigate to your email. uh you get the invitation link uh which is basically the link behind the join group uh part you get this URL you copy it and you paste it in the browser while

you are logged in so you don't accept the invite you just load the invitation URL nothing more and the invitation vanish and that's it so I mean there is nothing fancy for some reason when you load the invite and you didn't accept it yet so you are not part of the group yet the invitation will vanish from the admin panel. So basically nobody can uh see it. So if you go to the admin panel, you will see that nobody's invited although somebody is uh and you haven't joined the group. So nobody can remove you because I mean you're not a member yet. So this provides us with an invitation which does not expire and nobody can revoke

it. So what is the use case like? I mean why should you care? So imagine this. Imagine this is a work group or a group which is secret or where confidential information is shared and I'm the admin of the group now. I work in this group and I'm getting laid off and I'm very malicious. I would like to persist access after my access is revoked. What I would do is that I will send the invite to one email that I own. I will play this trick so that the invitation is not visible. And now I have a back door in the group that I can join whenever I want. So whenever I click the invitation, loaded it, it's now there. I

mean, nobody can remove it. And even after I got laid off or my access gets uh revoked, I can still go there and do this. Of course, this is malicious. It's illegal, but it's technically feasible. So this is how to play this one. And as we will see this attack, we will go into rounds. Meaning that we will go into the first exploit. Meta will solve it. We will bypass. And we keep doing this. It actually went up for 3 to four years if I recall correctly. So actually what I told you is not enough. Like I mean I'm not satisfied. Meaning that uh yes I can use the invitation yet the invitation is hidden but inviting

one person is lame. What if we take the invitation URL loaded in 10 accounts 100 accounts? Can they all join? They shouldn't but actually they do. Whenever you load the invitation URL before accepting it, you grant this account an invitation itself. So what you need to do very simply, you copy the invitation URL from the email. You paste it in as many accounts as you want. And now all those accounts are actually invited. Nobody see this invitation. It's a ghost invitation and they can all join the group at any given point. So I don't need many invitation. I just need an invitation to a single email and I can distribute it as much as I want and

then all of them can accept whenever they want. So maybe account A will accept now and then they will remove it. I will use B, I will use C, I will use F, whatever. I mean I can have as many as I want. So this is actually very bad and they solved it. So actually Meta solved it by tying the uh invitation to an email. So now the invitation is directed to uh a single person uh and they check in the email meaning that if the invitation is directed to x@gmail.com only xgmail.com can join. It's a good uh a good approach it appears but and here is the discrepancy between how the developers and how the

attacker think in a okay it's tight for the email. So what happen if I move the email around accounts? So as you know in Facebook you can have more than one email. So what happened is I create I have an email for example aliyiamail.com. I load the invite in alimail.com and then I remove alimail.com from the Facebook account. The Facebook account still exists. I add it to another account. I load the invite and I do the same over and over again. Guess what? It actually works. It actually works. Uh they Yes. Uh they will allow me to do this. So basically I can reproduce exactly the same uh effect by having a single mail moving it between different

accounts loading the invite without accepting and then all those accounts have the invitation active and I can accept from whichever one whenever I want and I can repeat this for as long as I want as well. They fixed this as well. But then I discovered something which is very interesting because it's very trivial actually. What if you block all the admins of a specific group? Theoretically, it should be that they can send you messages, they can see your posts, but uh the cherry on top of that, they can also not see your invite. So, if I create an account, sorry, if I create an invite directed to xgmail.com and then the account of xgmail.com blocked every admin in the group, the

invite becomes invisible to everybody. That's it. super easy, but I was not satisfied. I mean, uh, this was not enough. So, let's play the end game. At some point, probably they get bored and they removed the wall feature. Now, it's back, by the way. Like, I mean, this was around uh 2015, 2016, they removed the feature all together. Like, I mean, there is no email invitation. If you want to invite somebody, you invite them using their account, but they didn't remove the API. So, I mean, guess what? We are back in the game. You just use the API, you send the invitation and life goes on. So again, I mean, you're just back in the

game because removing the UI is not enough to remove the wall feature and we can reexploit again and uh have fun. So what went wrong in this attack? Actually quite a lot of things went wrong. So first of all, there is an over complication here where loading the invite have a very weird effect of making it invisible. I don't know really why it happens like so but it seems that uh the invitation is the invitation system is rather complex because when I think about it the invitation should be either accepted pending or rejected loading the invite should not have an effect on how it appears or anything basically so this is the problem over complication is a big problem here uh

invitations were not bound to a user attribute in the first round of this attack meaning that uh any email can accept any invite sent to any other email which allowed us to scale the attack easily as you said as you saw in round two it was not enough to bound to an attribute like email it doesn't work but it is something that you need to do so it's necessary but insufficient as they say uh invitations were not uh one time use so I can use it in many accounts which is actually the major problem with uh how I can invite many many users to uh the same group. By the way, this also when you think about it,

if there is group moderation uh it mean that me as a normal user who should not be able to invite people and they get automatically accepted. If the invitation I got was auto approved by an admin, I now have admin privileges by sending out invitations and having people join it because I'm auto approved. like not full admin privileges but yet I can exploit something that only admins should be able to have. Uh the other thing which is actually I mean I think that there have been many exploits uh in meta and also several social media platforms regarding this moderation should not uh be blocked by user action meaning that if you block me I can't message you I can't see your

content that's fine but as a group moderator I need to be able to see your invites I need to be able to see your posts even just in this context otherwise I can't moderate it and the uh block becomes a weapon uh more or less And finally, uh, stale APIs. Uh, removing the UI is not sufficient to duplicate a feature. Uh, by the way, uh, if you go to the API top 10, the mismanagement of inventory is on the top 10 list. Like I mean this is very common that you either don't deprecate APIs or you still leave older version which are vulnerable for a specific VPI. So it's pretty common actually. And now with the uh last exploit which

is in uh Snapchat in this case and uh just to be clear here we are targeting uh Snapchat business manager and this is an example of uh a B2B product meaning that business manager is not intended for normal users. It's intended so that you can create ads for example. So usually it's used by companies. You create an account, you invite your colleagues and everybody's happy. And the title of this attack is one invite to block them all. Uh we will see why this in a second. So this is how the invitation look like. Very simple. You have an email, you have a role and invite member. So you just need to enter an uh email of the person

you would like to uh invite. You add them a role. Uh back in the days it was just member or admin. So pretty simple. And you invite them. And that's it. Uh by the way before we go further I would like to tell you that here just to be following up the person being invited is the victim while the inviteee basically the person who invites is the malicious person. This is opposite uh to what we saw in the uh mas exploits. So here what happened is this invitation uh that I just saw you it actually triggers two HTTP requests. The first one is a request that invites the user uh to join the organization like we will see in

this request in a second and then there is a second request which add the role. So there are two HTTP requests. The first you just send the invit invitation email. The second assign them to a role which is member admin or whatever. So this is how the uh first invitation uh looked like. Uh it's a very normal post request. you add their name u and then you add their email and the organization ID and this actually sends uh the invite but then there is another request which is triggered which okay now you are a member so there's a member ID uh and then I assign you a role maybe it's a member maybe it's an admin uh really

doesn't matter at this point the question is what happen if I don't send the second request like I mean I invite you to join my organization but I don't set you a role and I mean this from the UI it's not possible because a single click will actually have two um requests being sent but again I mean there is burpuite there is APIs I will just intercept it make the first request pass and drop the second one uh what will happen is this Whenever the user who is invited uh join their uh sorry log into their account they will see this uh well it's awkward access denied and you might say okay but what why this is a problem because

actually in Snapchat business manager you can have more than um one account meaning that you can be for example from a totally different company but just because I invited you and you joined or you clicked on the link that uh the invitation link in this case now you are not able not just to access uh my organization it doesn't really matter but also your organization so you are blocked completely because the API will see okay you are not in uh a right state uh you have a member in a specific organization with no role I don't know how to act uh I'm denying you access I'm sorry but this is not it some stuff made this attack even

slightly more scalable first of classic. Now, invitations were not bound to an email. So, any invitation from any account can be used to add anybody to anywhere. Uh there was no confirmation before you join the organization. Meaning that when you load the invitation link sent to your uh email, there is nothing that tells you hey um please confirm this uh invite or you want to join this organization. Once you click on the button on your email, you're automatically joined. We combine those two elements and we get a cross-sight request forgery. Meaning that I will send an invitation to a very random email. I will get the invitation URL, put it on my blog. Whenever you visit my

blog, this invitation is loaded because it's a very simple get request and you are added to my account. Basically, you are removed from everything because now you denied access to everything. But this also allow me to scale the attack. I'm not just relying on you clicking the invitation sent to your email. Maybe you don't click on emails you don't know but it can even be distributed on website so that once you visit the website this request will be sent and you will be denied access and Snapchat fixed the issue but it was not enough. So basically what they did is that now you can't create uh a member without an associated role. You will not be

allowed. So this will not be allowed anymore. So what we can do is as follows we can invite a user and add the role because this is now mandatory but we can delete the role after the that so it's it's really easy like I mean we can create we as we will see there was an end point which can delete your role and there is no API check that you can delete this role if is maybe the only role remaining. So what I will do is that I will invite the user. I will add them a role and then I will delete the role and now the invitation is poisoned just like the first invitation. There is

no difference like I mean there is no problem. And this can be exploited basically by any admin. Uh by the way admin is very simple. You create an account and then you are admin of the account. So it's a free uh thing. You don't need to pay a penny for it. Uh and it can be exploited against all members. And members here don't think that I mean it's actual members. What we mean here by members is that anybody who clicks on the link which you poisoned the invitation link in this case. Um and this is basically the uh delete request which deletes the role using the role ID very simple. Um and now finally we come to some

reflections about this case. I mean what made this case possible? First of all there is no validation before executing the invite. meaning that once you load the link you are in the organization there is nothing that tells you hey do you want to join the organization are you sure you want to take this action and this is problematic I mean usually it's a very best practice that you confirm the user actions before you actually execute them the second thing is uh and this is actually common not just for invitation systems but for other things as well uh atom having associated functionality is atomic meaning that as you saw In the first uh round there's two requests one to send

an invitation and another one to add the role but those things from the developer point of view they should never be splitted like I mean they are one they are just atomic so what you should do is that you should have them in a single request and the request should fail if you didn't provide a role or you didn't uh you provide an invalid role or whatever so in essence uh it shouldn't be that you split requests that you want to make atomic otherwise you cannot guarantee it. I will use Burpuite or any other proxy, drop the part of the request that I don't uh like and that's it. Just to give you an example about

how this can be exploited in other things. Uh think about uh story views on multiple social media. Usually what happened is that there is a request to fetch the data like I mean the story content and then there is another request to set you as viewed. I have seen this multiple times and the main problem here is you can just submit the request to fetch the data get this story content and drop the request that say that you viewed their story and that's it. So it's not a problem. Those things should be atomic but for some reason they are developed mistakenly to be uh separated more or less. The first thing is starting and ending in allowed

states. Uh what happened here is that we started in the first round of this attack we started by an invalid state meaning that it was possible for me to create a state in which there is a user invited it doesn't have a role in the second round it was possible for me to have a user without a role altogether it should be that the user starts with a role and then there is no possibility to remove the role unless I remove the user and that's it. So you should start in a specific known state and end in a specific known state. Otherwise uh if you do by the way this actually pretty good from Snapchat point of view they uh

are doing a deny by default strategy like I mean whenever they see that this is an allowed state they do a deny by default but deny by default can be weaponized if you don't do it right. Uh, and I can't say this enough, invitation should be bound to a user attribute again because without binding the invitation to an email or the user ID, I was able to cause an invitation CSRF and force people to join my organization uh, in this case. So that's it. Questions?

Nobody have any curiosities?

Doesn't seem to be the case. Okay. Thank you everyone. Thank you for coming.