 Hi, I'm going to introduce the weakest link to you today that is a collection of cross-site request forgery weaknesses that web applications by mobile phone providers have. The weakest link is what I chose for the name because in 2020 mobile phone providers have always shown to be the weakest link in a security chain and what is dramatic about these weaknesses or security leaks gaps is that they are very easy to exploit compared to other weaknesses that have been shown at mobile phone providers. So for these seven gaps we don't need to have access to any particular gate why you don't need any specific know-how about the network of the provider. It's a very simple security exploit that you can run. All starts in principle a lot starts with a very boring newsletter that you receive and as you see here I have 26 times received a newsletter in 2020. That is just an example. This newsletter did not try to hack me. It's just an example for a very boring newsletter and the first two times you receive a thing like this you would ignore it presumably but if you receive it 26 times I guess every one of you or most of you will just lower your defenses and click on the thing and scroll all the way down and then find the redeeming link to unsubscribe from that unwanted mailing. And if you click on that the unsubscribe link you will get something like this a web page often from a newsletter tool provider which will simply tell you that you successfully unsubscribed and in this case you would think well I will never hear from these people again but then it might happen that a short time later if you perhaps try to use your Google account somehow the password manager can no longer find a usable password and you are logged out of your Google account. If you then can relate this to the unsubscribe link that you clicked earlier because maybe you were then logged out of your Google account immediately after you may take a closer look at the page that you were using to click that unsubscribe link to to have let's have a look at a page like this and you see that there is a form an invisible invisible form with two invisible fields or inputs and as you can see this involves a mobile phone provider it's about a call forwarding extended URL which forwards this phone number which is an Austrian phone number so this apparently installs a call diversion which is happening completely hidden in the background it's an invisible eye frame that loads this and this form as soon as you open that page will be automatically executed and sent and the case with Google is but with many others as well that they urge you to protect your account as they put it that your phone number should be used entered as a security feature in case you forget your password because you can then use that phone number to regain access to your account now let's go back one step and see what this is actually about this is about CSRF weaknesses as they are called that is not anything new in the 1980s already we had someone calling the same phenomenon the confused deputy this is about a program with lesser privileges causing a program with higher privileges to do a certain thing something unwanted and since that was discovered this kind of weakness in case the confused deputy is a web browser the name then used is cross-site request forgery and abbreviated as CSRF and the pronunciation is often CSRF and in most cases this is about from the point of view of the attacker it's about session writing as it's called because this is about sessions that use cookies but it does have it doesn't have to be the case you can also simply authenticate using an IP address maybe but in most cases CSRF is what is going on and let's look at it in a more schematic way at the lower left you see an hacker male or female you don't know because they are wearing a mask as you do if you're a hacker and in the first step this person this attacker sense the target person a link which doesn't always have to be a link but this is only about getting the person to visit a compromised page and our website and in the best case it's the attackers own or anything else that has HTML content that the attacker can control somehow and that will then cause the target person to send a get request to the service and receives a payload perhaps in the form of a form as we've just seen and that form is then as soon as the page is opened that form is sent to a different website and this is about mobile phone providers or the target person somewhere where the target person has already authenticated and that the server the server where the last request is sent to believes that the target person has sent that request and then that site will execute the request and when I was telling people about this for the first time many were kind of surprised asking well there is this same origin policy isn't there which supposedly protects you from cross site requests like this how then can it happen in the year 2020 that such a thing can actually be executed and that is a very common misunderstanding it's not as if same origin policies are asserted in the web browser it well if they are content that is set across sites cannot be read but a request will still be executed so CSRF is only about so-called state changing requests and not requests that involve simply the sending of some information we see two examples here of state-changing requests well one for a non state-changing request that's the first one action is info and the response would be an email address so an answer is given but no state is changed so this does not change state and that is not protected by CSRF it's not it's not vulnerable to CSRF because the answer cannot be read that is what same origin policy would protect the second state-changing request that we see in the second example you have something that says email equals attacker at evil.com so a new email address is set the state is changed not just being read from the database but something is written into that database and the response may be success or something simple like that and the attacking person will they not be able to read that response because the damage has already been done the email address in this case was already changed in the database in the example com database so this is very important CSRF does only affects state changing requests these attacks and we can now look at a first demo which is about ventocom that is a so-called virtual mobile virtual network enablers so this company makes it possible for supermarkets for example a football club or a cable provider to establish their own mobile phone brand and the brands here listed are hot dot 80 this is actually a subsidiary of Aldi Süd the well-known German supermarket chain and this affects Austrian and other providers rapid mobile rapid is a football club in Vienna and Leverst is a cable provider so the number of accounts affected we don't exactly know how many people were affected how many people have these SIM cards but the number of SIM cards is over 1 million in Austria and more than several thousand in Slovenia these are the latest figures that we have that were publicized so now let's look at this demo and I'm now going to open the browser I think I'd better show you how I log in log in is actually not done that badly you have a password free log in and people may forget this they forget their passwords or if they don't forget their passwords their passwords tend to be very simple they may have been leaked they may be subject to password recycling so this is not possible this has been prevented by the fact that log in requires a P UK code or a one-time code that is sent by email so we are going to use the email way so the target person five two three is going to receive an email that's the address that was provided and that gets us to the Gmail account of the target person and email has arrived with a link and simply by clicking on that link you log in and in this account manager the hot customer functions include various changes changing the customer password has been done intelligently because you have to provide the old password and then set a new one so that is fairly standard but if you would like to change your email address as you've just seen the email address is enough to get you logged in then you only need to change that address and not enter anything else no password simply change the address that is very customer oriented very convenient but at the same time very insecure and this year's F token there are no tokens of any kind involved I'm now going to have to change the email address back to the old one because I don't want to spoil anything preempt anything and if we now look at other functions you can see that among others a call diversion can be set and that in principle is what we are going to look at in particular in principle we can now close this and I will show you boring newsletter number one and if the target person clicks on click here to unsubscribe as we've seen before you will see a list manage dot email slash something address simply telling you that you successfully and subscribed you will no longer receive email marketing so what has current what has changed by this maybe we can look at this from the point of view of the attacker so let's open this private window so from the point of view of the attacker if we enter the old email address it should no longer be found and yes there is an error message this email is not known to us that's good if I now use the email address of the attacker proton mail then you find you have received an email with access data it can take a few minutes to arrive and it could take a while but here it is and if we open that we see that we are back in the old account we can use the new email rest of login and what we also can see is that the call diversion has been activated so before there was no call diversion here and now we have a call diversion no the attacker only has to log into Gmail with that account we do not know the password oh wrong password but we can go to password for garden other option and here we can select how we want to get the code and because we've called a version of this email address ending on 66 to the other phone number we can just request this call and now the phone should ring perfect that's an US number from Washington and and yes the standard code response and is now transmitting this code entering it into Google password reset form and thank you and we can now set not the new password and the Google account save the password and thank you very much no we have as a taking person not only the telephone number phone number of the account but also the associated Gmail account and therefore we have access to a lot of different things so that's the first demo and I'll go back to the sites no the basic setup is the target visits a compliment complimented page we need to have an valid session cookie beforehand and the session is not too late too old and that's quite specific this attack where in the background post request is sent within an eye frame and you don't notice anything that only works currently only with safari iOS and macOS Firefox both mobile and desktop Samsung Internet and Opera mobile and Internet Explorer now but here's this Internet Explorer we will see later on why mobile browsers are specifically vulnerable and if you want to take over a different account you need a different account and you need a mobile number for the account resumption here otherwise without you can only use the call forwarding to catch a call but you can also because you get persistence you have taken over the complete account you can also turn off the call forwarding and that enabled somebody to cut complete calls to record calls once a record call reacted us we can turn off the call forwarding and then call the number and forward the connection and once we have the call forwarding you can also hear all the conversations so you don't necessarily need it for a Google account, otherwise it is possible to address a damage that's enough to have a lot of damage this specification was created in 2016 and in the form that is used by chrome in the middle of 2019 this when it was imported if you have a cookie in the head a set of cookies in the headers of a request and the set cookie command you can also give it a same side attribute and there are three different forms same side non same side like and same side is strict and in this case with strict no cookie is forwarded or sent in a cross-site situation but that also means that if you send a link for example Facebook or other social networks where you have a link to an area that only specific persons that are already locked in are allowed to go to this strict attribute would be too strict because everybody would have to re-log in to get this content with same side as blacks only post requests are blocked the cookies are only sent along with the request cross-site post requests and iframes and so on yeah if you have same site equals none you can also define that earlier that same side none was also valid for everybody who has no same side request and here we have different browsers chrome some others here through that edge and opera desktop and are also using that same side equals likes is the standard value that means if we look here once same side is not defined at all nearly all pages use that because it's not well it's not that we are well known the standard value is same side like and cookies are not forwarded that way and it's a great security advancement that chrome and chrome and so on use developer about to user and user for this is a f and griffon to protect browser manufacturers developers as well as these users from cross-site request for re-attacks it's not the same with all browsers and so it would be good if safari firefox and so on would also implement this change because it creates quite high protection and yeah disables most request side fordries but just because this is said that does not disable all request fordries because if state-changing requests are using get you really should not do that as a developer but many people still do so there are strange state-changing get requests for example the second demo here with the mobile provider 3 it's not a virtual mobile provider but in Austria operating in three countries in Austria there are 3.9 million accounts how many can't persons there are we don't know because perhaps there are some people with multiple sim cards let's look at the second demo so from the perspective of the target person we have to look in again using that new password that was just said and let's look at the boring newsletter number two so just before we click on that I'll briefly show you how newsletter two works and you see here simply by being logged in on the three network using that mobile phone providers network 3 3 is the name of the provider they authenticate me say hello your number is and so on they recognize that would you like to be recognized automatically with that by that number and be logged in automatically in our network and if we see what is happening here let's say yes let's always log in automatically there is no password to be entered there is no link received through an email to be clicked on the provider 3 simply notices that I intend to log in using my phone number and that makes it possible to log in without password and the only thing that's happened that happens in this instance is a post request to an endpoint called auto log in and the request payload is simply submit yes and nothing else no password just say yes please auto log in which of course makes the whole thing much simpler if we just if we take a brief look look at the settings there should be no call diversion activated this has is not an artifact of the last test right so you see the divert or call settings is off and if I close this and switch back to the other browser where the target person clicks on that second boring unsubscribe link things look a bit different because there are two commands that are executed as we've seen for one thing we had to click on a another question that asks do you really want to unsubscribe and by clicking on the yes answer to that the auto log in command was sent or the request was sent and in the background a get requests was executed that sets the call diversion sets up the call diversion now looking at the source code which will again set up the call diversion ok ok the problem now is unfortunately this won't work thus that is due to the diversion but you see what has happened by going back to the settings where we see that all calls are now being diverted to that number that we've seen before so that means that it's extremely simple to set up such a call diversion and the prerequisites just to summarize are a target person visiting a compromise page or site there was a very similar in German and because the target person has person has previously logged in to that site or an auto log in is being used through that second click on that page that asks you to confirm the unsubs the unsubscription so in the second case the target person does never has to have registered or locked into the target service you still can set up a call diversion and then as before I didn't show it now as before again of course you can then take over a Gmail account what is not working with these dry firm provider is to keep logging in and change all kinds of things this would only work by clicking on that confirmation question once so visiting that compromise page is necessary for every change tapping into phone conversations for example it's not possible this way the only end point that is affected is the one that sets up the call diversion the reliability is much higher just think that you do this on the smartphone that would make it clear that the home network if that runs if that is provided by dry is if that's what you use to log in it would involve everyone that uses this auto log in and hasn't explicitly deactivated it and conveniently this auto log in is set by default so I haven't run any statistics but it will be quite likely that this works but what we can see is that the dry phone provider could not be used to do this in the background as soon as the person clicked the person was forwarded to a page by dry that could actually be conspicuous but if you send a newsletter that looks very authentic as coming from dry then probably nobody would really worry about changing their newsletter settings that would make a lot of sense to them so the reason why this is is that there are headers that dry uses and I use the X frame options which you can set to deny or same origin and that makes it impossible in the general case to not just send cookies but even to embed anything into that into a page by the embedded dry form into any other page so this is no mostly used for video sites that's one example where the this this kind of prohibition prohibition is completely useless because you do want to embed videos but other things I assume that the dry web application was set up at a time when the deny value for the X frame options header did exist and the same origin wasn't defined yet otherwise they may have used that one and we have a third provider another mobile mobile virtual network enabler part of the a1 corporation an Austrian company again and since I am a yes customer I discovered this I discovered several CSRF weaknesses and the problem with yes is that there are about ten phone providers that are affected for example brands such as two large daily papers Korea and Krone large Austrian papers power utilities and other brands as well so overall ten brands were affected and the special issue here is that using CSRF web based text messages could be sent and the problem here can be that it is a special feature that could involve a feedback channel so if the success message could be delivered to the attacker via web text messaging that is interesting and the dramatic thing was that the customer password could be changed this way and that password is not just for the web application but it is the password that you use to access the whole phone number port it to a different mobile phone provider and read text messages obviously so much more is possible here so Twitter accounts could be compromised or reset by sending messages like that so I practiced responsible disclosure with yes and the whole was fixed I can't demonstrate it to you but I was affected and just to give you an overview only in Austria this was only tested in Austria once Slovenian provider was involved or simply was kind of brought in but in Austria there are four point five point four million people affected and at least 15 companies or brands in the Austrian mobile phone industry alone were affected I didn't test them all but most of them some are safe actually it has to be said T-Mobile Austria for example Magenta as they call themselves now but this only affects their main brand not the virtual providers that you get these days such as hot they do use the T-Mobile network but they are affected so the big question I have to you to what is the situation in other countries Austria isn't the largest developing country when it comes to tech but if about 40% of Austrian citizens are affected then probably in other European countries the situation won't be very different so I believe that in the largest countries where the budgets are higher platforms will be better secured but on average you can assume that several dozens of millions of Europeans are affected so take a look if you're in another country or if you have a SIM card from a non-Austrian provider and maybe send information and send some information to the mobile phone providers as well so that they fix their leaks for a solution how can this be prevented in the future first the first one I would like to talk about our political solutions or administrative solutions because we do actually have a so-called NIS regulation about information security and that regulation stipulates that laws have to be enacted in member states that would provide for critical infrastructure which phone networks are a part of have to adhere to security techniques technologies or security levels that are state-of-the-art so grave weaknesses in web applications that can be very quickly found definitely are not state-of-the-art so the next question then is there is a legal framework for this it's actually not legal to have such weaknesses so how can it be that over years apparently many many providers in Austria had these weaknesses that can only be the case because there are no penalties no sanctions no liability and I'm pretty sure that the daily papers for example that I mentioned Corona and Korea would be advertising their mobile phone offerings to the readers without knowing that security holes would exist or had existed so they advertise products that have massive security holes and they will probably never know unless they would see this talk for example so that is the case and there has to be stricter sanctions penalties and liability rules should exist to prevent this from happening and also the conditions for responsible disclosure should be improved I cannot imagine that with 5.4 million account holders I could be the only one that notices this it's not that difficult to discover and they must have existed for years but if you have tried to practice responsible disclosure yourself you will know you're not actually showered with gratitude the companies normally have no policies at all for this they don't know how to handle this and if they do then the policy often looks like well if you stick to these rules and those rules then you are allowed to report and as a gesture of thanks we will not sue you so that is not a great incentive to have issues reported and I've seen cases where people have noticed something and preferred not to do anything if there was a bad bounty program where people that find security holes were rewarded then the existing bug bounty programs from traditional companies are a role model here then surely these leaks will not exist for much more than a few weeks so bug bounty schemes are a legal hell currently and I understand the company is why they are reticent label law for example how it's someone affected is in a contractual relationship and in terms of developer solutions we are talking about standard solutions the state of the art has been for years that anti-csrf token should be used so clearly as always don't build your own use what is proven and use what exists and for all programming languages you have libraries available what is new in my opinion this is just as good as anti-csrf tokens is the same side equals strict or maybe even lax attribute to set this yourself it's much simpler because you only have to configure that at the server one line in a configuration file in HD access or whatever so that is very very simple to do and maybe this is the better solution so I would like your feedback on that too if you agree with me on that but the best of all solution and the one that affects these important state changing requests and should be standard there is to ask for the password before making important changes like changing the password the old password has to be supplied if I can change my email address with which I could reset my password then of course the old password should be asked before changing that address and it is standard to enter the password if you change your password but if it's not asked for changing the email address then that is completely illogical and clearly with mobile phone providers the same thing should apply to call their version and the solution on browser side on the client side is something we discussed it's high time that all browsers should use same side equals lax as the default and this has been implemented for about six months in chrome and it hasn't broken apart fallen apart and browsers that have a share of 50 or 60 percent in some countries use this now because they use the chrome base edge I think is one that was mentioned so the other browsers should follow suit firefox I think is planning to do it at least you can actively use that setting safari which has a large share I think it's high time that they would do it too but also there is a solution for the people affected you don't have to rely on others finding or closing these gaps you can protect yourselves simply by whether first thing do not use phone number for account recovery as I said this is the weakest link in a security chain the weakest link are the mobile phone providers so for email addresses use a second email address it's it makes sense in terms of web security and in terms of remembering passwords but this is a massive security hole as far as CSRF is concerned so using the phone number for account recovery we've heard this there are leaks the Congress has had talks about it so it's very simple to circumvent if you do not use a standard to your standard browser to log into important accounts that's the one that opens everything automatically when you click on link for important accounts use a different browser or at least which used to be the case you would normally be asked about this these days because everyone wants to collect data you are encouraged not to log out but the protectionists do log out actively that's it from me thank you and I'm looking forward to your questions yes thank you for this interesting talk some of the questions that were asked you already answered in the last couple of minutes one question is already forwarded to the respective companies you said one question issue was not we couldn't reproduce because it's already closed how did the others respond so far I only reported the issue with the yes because they have a responsible disclosure policy so I had a contact there and the other two have security contact because of that I they still don't know it with yes they I told them on the 12th of October and on the searchings of November it was fixed that was done quite professionally within 24 hours the security vulnerability was a report confirmed and it took a month because it's an external service provider for software development and that meant that the implementation was a bit slower yes different question are those vulnerabilities vulnerabilities in the web applications or is the other brothers also had fought to a certain point is that a browser issue or is it a website issue yes it is an issue in the website applications but on the other hand it's the browser should all use the same policy as chrome and in the recent month we noticed that there were no disadvantages for existing applications and we can say that it is a browser issue to a certain point where in the background the yeah everything is done in the background and the question is would instead of a different browser a different multi-account plugin might be a solution yes that might also be a solution that is not the simplest most simply simple solution for all users but if it would be a solution how difficult it would it was it to find these vulnerabilities those vulnerabilities can be found within less than an hour most of the time you are needed to look for the vulnerable endpoints and you quickly notice that there are serious SRF security issues and there's not rocket science to find these