 Hi, this is Yoosafim Bhartiya and welcome to your file. Let's talk it today. We have this once again Yannibal Maas, VP of research at Salt Security. Yannibal is great to have you back on the show. Great to be here. And today we are going to talk about of course, you know API security flaw that was you know discovered in Booking.com that kind of allows you know full account takeover. But when I look at this case, it looks you know Shows us it just kind of symptom of it is still a larger problem that is still there because we are talking about you know tech Cloud centric companies, you know who are still going through this. So before we deep dive into a larger problem Let's just quickly talk about Booking.com What was discovered how serious is that I think your definition was very right that this is not a booking.com problem But it's a bigger issue Specifically what we found in booking Booking uses as many other websites. They have functionality That's defined as social login. So probably you and you know anyone who browse to any sites recently knows this You have this button that allows you to login into your favorite service using your Google account Your Twitter account or anything like that. It kind of it's it's very convenient because you don't have to enter your own username and password And it's very easy to do this But the thing is that while the functionality the functionality is very easy for a user to operate under the hood Hides a lot of moving parts and a lot of technology and if you're the service that's trying to implement this kind of Functionality into your service. There's really so many points where you can go wrong And since you know, this is your Authentication endpoint. It's a very sensitive place and sometimes even the minor the most minor issues can lead to very very very Catastrophic impact and that's exactly what we found in booking basically a Flow that they had there with their Facebook logging functionality allowed us to basically take over Any account that's using this functionality or even accounts that are not using functionality But are just logged into Facebook while the attack undergoes So we're talking about millions of users for booking.com. It's a very serious issue and Yes, that was basically the issue when we look at these social logins and rely on technologies standards like what it's kind of double-edged sword Whenever possible, I do have separate rotating passwords for different services But I also use your social login Especially for things that I log in from different devices, especially mobile devices because that makes things easier But when we look at cases like that, then we're like, hey, you know what? It's easier, but is it really that secure? so What I want to ask you is that talk a bit about what went wrong there so that we can also learn some lessons from it I perfectly understand your approach here, and I think it's security wise It's really the best practice, but let's be frank about it. How many people can do this? And I can you know, I can say for myself that although I'm a You know, I'm a security researcher and I practice this. I love social login. I use it all the time. It prevents me from you know remembering a lot of passwords And it's a great thing under the hood this kind of functionality there is a industry standard protocol called OAuth or Some extension to it called OIDC and this is kind of the industry standard protocol that supports this kind of functionality of social login And it's a wonderful functionality But again as I mentioned the mechanics of it are pretty complex and To put it in simpler terms It's pretty easy for you as a service or a site administrator to put Auto-integrate social login into your site a walking social login into your site. It's very very hard to do it securely And and this combination of something that's very popular And the user experience that it provides is is is fantastic on one hand While on the other the technical difficulties of implementing it correctly security wise This can be sometimes, you know an explosive combination and that's in fact what we see in and booking.com is just one use case For this problem as you mentioned before The the issue is much much much larger. In fact, we already have several other targets which we didn't publish yet Which are we found that are vulnerable to Different flavors of the same of the same issue. I want to get a bit deeper into technical details of What went wrong here in the context of OAuth? How serious it was Was it limited just to bookings.com or it Goes beyond that. First of all, let's like to answer it step by step. First of all Where is the issue because basically when you're talking about social login, you have Three parties involved here. You have the user You have booking.com or the site that you are trying to log into And there is the entity that will you know, confirm that the user is the user which in this case is facebook Right, so that's the third party That should should be trusted now the thing with OAuth that the user never needs to send his username password To booking.com never at any stage It doesn't need to happen. All he needs to do is to tell booking.com. Hey I want to log in using facebook. So please booking.com go to facebook and verify that i'm really me That's really me and facebook will do that. I don't have to share anything with you If facebook will leave anything from me, they will ask me for my password And I I only want to work with facebook and facebook alone. That's the main concept behind behind this thing Now as you can as you can understand, there's a lot of moving parts here You need to test some kind of trust between the user Then booking.com and then this trust needs to be also shared with facebook.com So it's very complex to do that And it's it gets even more complex when you're talking about the fact that You don't have only one authenticating endpoint. You have several of them One is for your desktop clients and other is for your mobile clients and other is for maybe Some other services booking provides and you can see how deep this rabbit hole goes It starts being more and more and more and more complex and in terms of you know, the service providers booking.com This instance, it's very very very hard for them to you know Try and fine tune and pinpoint and find every security feature And that brings us to the second point. So Who is responsible for this? Is it the user? Is it booking or is it facebook? Where is the problem? And and and the problem, let me tell you is not on the user side It's also not on facebook side facebook and the user are doing everything as designed as they were supposed to do The problem in this specific case lies in booking.com. It's not that they did anything wrong It's the way that they implemented or was there was one very small minor glitch in there Which is very very hard to find. It's not it's not apparent You can see that but if you're an attacker and if you know the protocol well enough You may be able to pinpoint that just as we did And once you do the impact is dramatic because as we said million you can immediately take over Millions of users in booking.com. And by the way, it doesn't stop there Because the ecosystem is even more complex than that. I'll give you an example kayak.com, right? It's kind of a sister site or brother site for booking.com. They are both Under the same mother ship mother company Booking holdings and the thing is that kayak.com allows users to log into kayak Using your booking credentials. And so the same vulnerability that we found in booking immediately Kind of affects kayak as well And it keeps getting worse as this ecosystem, you know keeps getting bigger and bigger So the problem lies with booking. Obviously we reported everything to them booking acted wonderfully I must say they were very professional They dealt with everything and they fixed everything almost immediately once we reported it And obviously the vulnerability is not there anymore, but it was there once we found it This flaw was kind of specific to booking.com and of course associated website But can there be more vulnerabilities like these in the world? Yeah, I touched that point a bit before but I'll try to elaborate now Yeah, we found this thing in booking. Oh us as I said, it's an industry standard everywhere that you see social login functionality 99.9 percent that behind the scenes or what is is is taking place there. So it's it should be there It's what I'm trying to say that it's very very very common And yeah, this problem is definitely not specific to booking.com. In fact, we already have found additional vulnerabilities in other very popular sites Again with their odd functionality. It's not always the same problem But it's always a problem within all out There may be many flavors of these issues and there are many places where you can go wrong when implementing auth and Everyone should be considered as potentially vulnerable to this right? You need to I think the main takeaway for service owners and service providers is that if you use OAuth You better go and make sure and and and check and check and check again That all your implementation details are correct and that you don't expose your users to any unnecessary security flows You can do that in many ways. You can do that in internal or that external that you can use that part is To help you protect where you miss really there's dozens of solutions You can use one of them or many of them As long as you understand that this place Is a place that's probably crawling with vulnerabilities You will be in a much better place Of course, it's not that easy But if I ask you what advice you have for companies So that they can take some steps They can have some practices in place to ensure that things like these Won't happen as long as we're writing software these things will continue to happen But it's still we can take some steps to ensure that customer data remains safe That's a very generic question. I would say and I will give you a very generic answer so In my point of view when you're implementing technology The first thing that you need is to understand that this technology never never never implement something That you don't feel that you deeply understand And if you don't have this knowledge internally within your organization, that's perfectly fine. You can you know seek Other parties that have this knowledge and will be able to advise you on that And that's really true for any technology that you're using and specifically For technologies that support authentication or authorization because these are very very very critical points within any website or web service Flow that would be one thing One advice the other advice would say, you know, yeah, even if you Know the technology and even if you went through every line of code Still you might be able to miss things and these things happen and it's okay. It can happen to everyone I think it will also be wise for every organization to Have a second line of defense Which usually will come in the form of, you know, a third party Security products that you can implement that will help you You know, try to detect or prevent This kind of type of attacks or that kind of Of attacks and that's really the the best practice for every CISO I think I think most of the the best CISO in the world work exactly in this methodology and Again, there is no foolproof Even if you do everything you can still be vulnerable and that's perfectly okay But you need to try and minimize Your exposure as much as possible and once you find something you need to be reactive and And and and react to it as quickly and as efficient as you can that would be my my generated advice Yannip, thank you so much for taking time out today and talk about this topic and also share some of the insights that you know, these technologies how they actually Make us users more secure to be honest with you using a lot like things versus using Password one two three, you know, it's much more secure to use social login to the login to because then Once the problem is fixed you're safe and secure. So thank you for sharing all those insights And I would love to have you back on the show. I hope there will not be too many Breaches so that we talk every week, but I would still love to talk to you frequently. Thank you Thank you very much for inviting me. It was completely my pleasure