Twice The Pride, Double The Fall: Why 2FA Isn't The Cure We Thought It Was by Boglarka Ronto

right so um how's everyone you okay this is a stunning room I mean I'm really glad that we've got this room for this talk hope you like it as well hope you don't get distracted too much um basically what I'd like to talk to you about is multiactor authentication Solutions so it's not the Enterprises stuff it's what what you uh come across online what you come across when you access your Gmail your account and so how many of you have done any research on multiactor authentication cool couple of hands yeah there's some research out there there's not huge lot obviously and that's partly because in my view there's fewer services that offer to authentication than there should be but we'll get on to

that a bit later um the primary focus is on typical implementation flaws um let me know in the back if you can't hear me I'll try and speak a bit louder and um I'm also going to try and point out that it often takes a bit more than just sticking an SMS prompt in front of your web server or a Google authenticator on your website to actually come up with a real proper multifactor authentication solution um I'm uh a little bit about myself just very briefly um I'm bonto I work for commm I'm head of testing I've been do um working there for five years and that means I get to do some of the

more awkward stuff some of the the testings out of the the ordinary so I'm quite happy with that um a couple words on responsible disclosure this is because I had to anonymize a part of the um the um uh stuff that's in this talk um not because um the vendor didn't U fix the issues to my understanding they did and they've implemented counter measures but they still preferred not to be named so um um but this is still um sufficient for us to have a look at the um the the typical issues and also to Come Away with a couple of conclusions on on um what not to do and what to look out for um in the future if you want to

um advise someone on multifactor authentication or if you if you try to implement it yourself um so just very briefly you probably all know what Mula authentication is about so it's effectively um trying to um to um choose two or more factors and so that the user would have to know something like their passwords or PIN codes they would have to um possess something like a token or in the case of a bank card they have to get have the physical card itself and the third factor is inherence which means that they have to be something they have to to it's typically associated with biometric credentials and they have to have to um have to have some sort of

quality and to be able to get through the authentication process um You probably noticed that I'm switching between two Factor authentication and multiactor authentication that's um because multiactor authentication is a more proper way of of of talking about this topic two Factor assumes that you're only using two of these three multiactor um assumes that you're either using three or potentially more of these factors um to process your authentication um so there's not a huge load of information here you probably all um knew about this um already the the most common um way of implementing multiactor authentication is using tokens and we've got loads of soft tokens now we've got apps we've got um just um console stuff we've got radius

We've Got U so many solutions that support this and we've obviously we've got Hardware tokens as well they're a bit dated now and um obviously there's there's an issue associated with Hardware tokens that if if you collect a lot of them then you end up with big um thing to carry around in your pocket so most of the companies are actually transitioning to soft tokens and um I used to um always think that these soft tokens were like magic and you know 10 years ago when they introduced um RSA secure ID tokens they magically allowed me to log into my uh my to authenticate to my cerus server with with it being completely disconnected from every

Network and I thought that there's some brilliant engineering going around in the background and lots to algorithms but it turns out that's not really the case um there's um it's actually quite simple we just get on to in the next slide and the only standard that I'm aware of that actually requires users to u to do multiactor authentication is pcidss and but I suppose it's something uh so this is how it all works again very briefly if any of you is interested in the algorithms you'll probably look out there's um two main ways of Factor authentication one is um hn Bas which is the top one and also this yellow column here and that all that

uses is a counter an incenting counter and a shared secret which is then hashed and um combined with the counter to produce in a one time pass every time you press the button a counter is incremented and you get a new token so there's no time factor involved U as opposed to the second one which is um time based OTP where you um have again shared secret but instead of the counter you have a a time stamp that is always um synchronized so that's why sometimes if you travel um overseas your um tokens might get out of sync or you might not be able to use them especially if they're soft tokens because you then

switch time zones automatically um so the share secret is um when you're setting up two Factor authentication you normally get a QR code to read a QR code on your from your laptop screen and put it in your um in your app that's actually the shared secret so if you ever want to look at it it's typically um 10 12 digits combination of numbers and letters and that's all it is about um so um what I want to talk about next is a couple of couple of the most prominent examples of where multia authentication hasn't been implemented very well owing to a number of reasons so um we had the um the Apple incident in 2014 which was really about um not

having all of the areas covered with the multiactor authentication so they uh enabled it on a couple of um Services which we can which you can see there like for example typically the services that would be associated with credit card payment because that's the that's what they thought would be the most valuable Target for an attacker but at the same time they didn't enable it for things like sing your photos or bookmarks which is also sensitive and on top of this they didn't really tell the user that this is going to be the case so they automatically assumed that when they enabled this added level of security they just um they were protected but that wasn't entirely the

case because they could their um photos in book marks could still be sync and in addition to all of this they didn't email and users when a new untrusted computer was set up for this thing and so so that wasn't really a good example of of how you would go about this sort of thing um the next one um again from 2014 and this is associated with PayPal and and the linking of eBay accounts to PayPal accounts so what happened was you can see that integrated registration area there the ones that one that is highlighted unfortunately I don't have a laser pointer but it shouldn't be um too difficult to spot the area effectively that's just a token so it's part of the

URL it doesn't have a valuee it's just a flag um so when you were visiting PayPal transitioning from an eBay you got that um additional um flag in your url so that when you logged into PayPal you were impr prompted for a multifactor you just have to put in your username and password and this guy um discovered it it was I think um um 17 year old that uh that if you uh put this if you just insert this token even if you log in to PayPal without that um having anything to do with eBay Al together you would still not be pred for two Factory Authentication effective way of bypassing it um fortunately they've

they've moved on and and corrected that quite quickly um and then this is a bit more interesting last class um two Spaniards they did some research and they also presented their um their talk at black hat I think um in 2015 and they basically uh tried accessing the encrypted vot of last class it's a password manager um you're probably familiar with it effectively it um allows you to sync your um database password between um hosts and also to store it in the cloud but without them actually having access to the data so what they did was they were looking at ways of accessing that encrypted Vault um along with the the master password so that they could um look at the content

and they found that there there's this mechanism there's this um a c recovery mechanism that is U not entirely in line with what you would normally umum best practice so um once you initiate um an account recovery um you got a URL which you can see at the bottom and uh you didn't even have to um change your existing password you could just continue with whatever password you had as long as you had that link so and that allowed them to recover the encrypted Vault and um and five for authenication because even though that was enabled on the you had the URL you could just access it and on top of all of this they found out the algorith them

used to compile those um URLs so even if you didn't initiate an account recovery process you could still Forge a URL and um you could access someone else's encrypted VA so that was a big thing and fortunately they've also fixed this so um that shouldn't be the case and then now PayPal again um you would really think that if someone bur themselves they would try to to um make sure that it doesn't happen again well it did and the um the way they did it this time was paper actually had a preview portal and when you access the preview portal and you were in prompted to one more Factor but when you access the normal PayPal

you were so you open the normal PayPal site then in a different tab you open the preview um page logged in there and when you went back and refreshed the uh the normal PayPal page um you would just thrown into um a valid session because you already had a live session in the in the preview page for um so it's not even worth a screenshot because it's um it's so basic and our favorite Outlook how many Outlook users Yeah couple so um this one um other from from all aspects Microsoft authentication is amongst the the better ones but researchers discovered that um there is actually a an exchange web service that doesn't require multifactor authenication and it's enabled by

default so when a company uh installs an exchange server and they publish it online and you'll get this exchange web service in addition to your M which is the web access and if you don't disable it explicitly um someone's going to be able to access um U access email belong account without actually having to go through the multiactor authentication part and this is interesting when you're doing if you're if you're doing an internal pentest and you get hold of a couple of domain accounts and you then visit out web access but they use multifactor authentication um there's a um a script on GitHub that these guys made available that actually um helps you out and you can use it to retrieve

email and retrieve other information from this person's account so un in Microsoft U this is not a bug it's a feature so um the only way you can uh really protect yourself against it is to disable exchange web service and uh the so in to some some this up the the typical implementation flaws some of the features are not covered so you have a set of features or a set of ways to interact with the service like like in case of apple and not all of the not the entire scope of your or or your services provided is covered so that means that some some areas are going to be okay but um your users might be living in a a belief of

false censor security because their accounts could still be accessed potentially through different channels and um there's then there's the the matter of integration and Federation which we saw with PayPal in two um instances as well whenever you're you're implementing integration you need to really think about whether there's a Development Area or preview area that is isn't uh at the same level of security as your production environment and then there's obviously the lifetime uh of of these tokens like in the case of last class where um these URLs could be forged and they were not really and bound with any time barriers so you can access you could access it over an extensive period of time and um finally

you could have you could also mention poor poorly implemented um uh account recovery mechanisms and just features so so this is the actual stuff that that we've done um and this is the part where the disclaimer from from the U beginning of the talk comes in um all of this in is aized so unfortunately I can't disclose the the name of the uh the provider or the vendor but um we should still be able to um to look at the the the flaws and the uh in their mechanism this was a a custom implementation of um our custom approach to multifactor authentication and um there um um their aim was to um to create an

authentication mechanism whereby you have a username and you have a pre-registered in uh you your phone number is registered offline with the organization so you don't have any facilities to register yourself or to change your phone number and you'd be prompted uh for your username and then once You' put that in in the next stage you get an SMS um message with a code that you would need to also provide um after which you'd be um transferred to a secondary server and that secondary server would have the actual application um that that you wanted to access so in this case it was an instance of um of citric denap and they they opted in for this sort of

solution at least um I think um the reason why this happened was that they didn't want any form of interaction with that secondary server because normally you would have um uh buil-in capabilities in Citrix for um for um integrating it with multiactor providers but in this case you choose a very different path and um this is the initial um login screen um that's my user ID and um in the next step um you um actually we pred for the password so this the code and the first very very first thing that immediately occurs to you is this is this doesn't seem to be like a regular password from does it I mean it's not off thec in any way it's

just um a plain popup window with with where you can put in your details um so this was the first P tail sign but um but there were many more to come uh anyway once you've um gone through all of these steps uh you reach the um the Citrix Receiver and you supposed to log in with with your additional domain us part but um I'm not going to go into that because that's not really um in of this talk and um also really what we're interested in is is the mechanism beforehand um the um the the site also set um a cookie so I'm going to start going into the the um the technical details a bit I'm going to

try and keep a high level but still those of you who know JavaScript and um want to read this hopefully you can still see it from the back Clow so um all of that um going through the um the um the initial authentification process and we looked at the at the website the page that that was downloaded on our in our browsers obviously and there was a bit of Javas code JavaScript code in there which was this B so basically what it says is that if promps you for the username and password yes if if if you don't put in something or you cancel it it just automatically throws you on an access in web page um once uh once you

managed to um to put your um username in it sends you through to the next URL which is this python code here we didn't manage to get access to this file so we don't actually know what's in the script but we know that it's calling a a binary um a python function that would actually with your username that would actually trigger the um the SMS to be sent to your phone we didn't have control over over our phone number it was provided to the um provider before the testing started so we have to had to rely on on getting that text message and if uh if anything went wrong we just got to an access damic

page so this is the part this is the actual HTTP get that that was sent to the server all of the communication this is another potentially um unusual way of implementing this sort of thing every bit of communication sent to um the server using HTTP get requests there were no posts whatsoever so all of the information was always in the URL and um we I just highlighted this casie of information so that you can see the um the python code and the username being submitted um next is the response from the web server which is in this case a HTTP 200 which means okay the the request was received and we got back got um access to a

ID which is um going to um be used later on in the communication but at this stage it seemed that the um secondary server is Trix box couldn't be accessed without this unique transaction ID which was actually received from the server after the um username has been provided there was no pin so far so um that will be the um the next bit so then once we sent the um username and we back so effectively if if the username was wrong we would have gotten an access denied um next stage is that the script request this for a pin code um so we provided what we got in the text and then U what happened it was that it submitted that

transaction ID along with the pin back to the server to Second python script and then that um returned either a an okay or an an a depending code was validated correctly or not and then the next stage you can see that there's something very awkward going on here because and the in the next stage as you go along with the JavaScript it's actually the JavaScript code itself that validates this um this um transaction so we get a response back from the server and then the JavaScript checks that status and then tells us whether we're okay or not so who's the next the person that that is going to tell me what's wrong with this exactly so it's all validated on

the Cent end so we can pretty much do whatever we want with this yeah definitely so um but let's play along and we went then and submitted the transaction UE which is P1 and the P code which is B2 and then this is the um the um the get request that was sent to the server and um this is the um code that we got back and as you can see it's just an okay um so this is uh there was one additional bit that I haven't mentioned before and if we ever got an okay message back from the server and we actually um are um the the JavaScript put set a cook keie and

the um in our web browser so this was not um noted from the this was set by the by the JavaScript code and so you wouldn't normally get um you would you wouldn't see an set C directive as you would um if you're doing we application testing and capturing the traffic using a proxy because um because this would never um never be seen by the proxy it's just purely JavaScript doing its thing and and setting this cookie in the in the browser so um we do about this so we looked at ways of of how to bypass this because there's obviously something very wrong with this implementation first as you mentioned there's Cent side and code but then

there's also the validation mechanism that isn't really right there where it should be so um initially um we start started forging the cookie so um it seems like because we have the um the JavaScript code we have exact piece code that actually created the cookie we just for key and and check if we can access the um the U the secondary server the Citrix box we did it worked um so next we we U we tried to see if if it was possible to manipulate HTTP responses from the server because it's a relatively simple way of of telling JavaScript that of line to JavaScript and um this is the uh the part where it's validated so it's trivial to modify

this and of course it worked and uh next we just looked at whether um we could just always tell the JavaScript that whatever it got and whatever response it got from the server let's just say it wasn't okay yeah of course it worked and so finally if when we were really lazy about this we just said okay let's capture um let's capture the the response from the the web server not the request and just say it wasn't okay inad the 43 of course it worked so um at that stage um we effectively established that the secondary um web server which was the Citrix box um could be accessed just by either forging the cookie or letting the

JavaScript doing its work by modifying the response received from the server which also meant that neither the thein code that we initially used to verify ourselves nor the transaction ID were necessary to actually access and um the main um reason for for U for that the main reasons that made this attack possible where client side code it's really dangerous but if you look at um various other areas um where they they're using implementations of multiactor it's not actually that un common if you think about your bank card when you put it in an ATM it validates your PIN code but that PIN code is actually Car locally and the agent that validat it is the ATM machine itself so

it's not unusual to have client type and validation of some form of input it's just that in case of an ATM you're much less likely to be able to temper with that information as in the case of an a website where you have complete control over whatever happen with client so and the other problem was that the the server um server actually didn't um require a um a form of validation so it did validate our pin code but it didn't this wasn't enforced in any way so we could do whatever we wanted regardless of whether we got an okay or not okay from the server so that validation mechanism really should have been a lot

more robust to u to be able to handle um instances where where where we're trying to forge messages and finally the value of the cookie which really should have been something unique uh was quite predictable in fact it was just seconds um add it to the current time stamp which is a 5 minute interval and um it's trivial to forge it um it it's very very poor security practice to to use predictable cookies anywhere related in relation with um web applications so um we I then thought um why don't I um look at some of the um the other implementations of multifactor ones that are closer accessible to um to people and I looked at um Google's authenticator

which is one of the um the better ones so it's not all um Doom and Gloom there there's there's good examples of um of implementations of multiactor out there and um authentication authenticator is an open source piece of software so um hundreds of developers have validated already and it's reasonably well implemented in terms of um supporting Channel that don't otherwise support multiactor authentication so you can create um onetime passwords that you feed into your IRC client or binary email client or whatever and um and you can use it to sort of skip um OTP for for or multifactor authentication for that one particular um service but that's that's a code that you can only use once and then the next time you um

you disable that service or L out have to create another um one time password and um they also use this uh for file synchronization and some other areas and um this is actually a relatively good implementation so the next one is um Office 365 which is again quite good it's got very good integration with uh with lots of services provided by Microsoft and and you would expect that because it's their product um in some some regard they use this authenticator app uh and the the principle is the same you can either use top or HM based OTP and you're basically um you're basically um prompted for a key or an okay before you access a a service the the one weak

area of this implementation is as well as the Google one is that you can have you can bypass this if you choose to receive a text or a call and sometimes you can in within certain environments like where your um where your coverage isn't great you might be able to access someone someone else's voicemail because um you just um tried authenticating with their account and diverting their their call it's it's not very likely but there's ways of of trying to do this but that's not entirely in in the scope of of my talk so um Microsoft also have things like um especially in the in the enterpr version of Office 365 they have access to files through SharePoint and

webdav which is done through webdav and also one drive and that's got in another interesting weakness whereby the way of actually authenticating to that service is through a cookie but that cookie can only be um retrieved through an activx plugin which only works an Internet Explorer so it's sort of bit of from Microsoft part but they still call it a feature um next one is um Steam and this service they use and these um it's a very custom implementation of of multifactor authentication as you can see it's not um digits it's not numeric codes it's um It's a combination of um of numerics and and um characters and you you you're almost like have this

able to um from the very start that you register the service because you keep getting these emails with the codes and you're prompted to to enter these codes before you're allowed to log in now obviously and the uh the fact that that you're prompted for email as multiactor isn't ideal because typically as you can see on this that's a screenshot of my Android phone I am accessing the service from the same platform um where I'm receiving these tokens so it's not really multifactor because you access from the same platform to the same pieces of information so if someone's got your phone and someone knows your um your account details then that wouldn't help well if you um if you if it was a

true um two factor or multiactor authentication then you would use a different separate platform for authentication and a separate platform for your token code um it has got its own um authenticator app so it's completely different um from the one that I've showed you from Google or from Microsoft and then there's blizzard and these guys like to live dangerously so they use this again it's a custom implementation of of their app and you have to um use this to um to um log into your bleet account and those of you familiar with them into gaming will know this and um yes the codes expires so it's it's relatively from on the face of it it's relatively good when you start

into it then the interesting then you come across the interesting stuff and initially they also send um codes via your email but and this is the interesting stuff the authenticator app and which is with the um which is in the background now as long as you have it in the foreground on your phone and as long as it's displaying that code if you look at the uh the actual communication between your phone and their server you'll see that it's just sending these every um half a second and it just keeps sending them so it's almost like your code isn't really a secret anymore because it's submitting it to an API and uh and it's it's almost like

it's well it's not broadcast but it's it's um it's running through your homework and it continuously does this regardless of what you're doing and the uh even more interesting thing is that under certain circumstances you can actually trigger that to happen over PL Tex so normally it goes through https but sometimes it doesn't and there's the two instances there are highlighted so that means if someone is listening on listening on your network you're sitting on a in a coffee shop or maybe even at home and someone's listening um to traffic they'll get you know access to your code and that's not really what you would call best practice um so this is this is one of

the reasons why soft TOS can be problematic so you really have to that you've covered all around before you um You release a piece of software and that does this for you so um this isn't entirely my opinion um you may have a different view on it but I thought I'd share it with you in case you have something to add or discuss about it um as I mentioned in the in the um um first part of my talk there's some research on multifactor but there's not a huge a lot and that's because we don't use multifactor AU ation enough we don't use it we don't have it on our on our Council login Pages we don't have it

have have multifactor on our utilities providers or our um our um streaming providers or telecoms even though some of the Telecom organizations do encourage you to use uh the email accounts provided by them as your personal primary email account but they don't provide MFA and yes this solution isn't for everyone but but to have that as an option would enable certain users to um to to be more and be more secure and and reduce their own attack and protect their accounts and um the other reason why I don't think there's enough research done in this field is because um as you can see there are problems so there's there's there's stuff to research but people just tend

to trust Mula authentication because it's in addition to what you normally have as your username and password so if you if you if you're accessing the website that's got https on it it's got a big green certificate telling you that it's safe to proceed and you've even turned on multiactor authentication you think you're brilliantly safe but sometimes that's might not be the case and we should trust and fail a little bit less and do more more research to to uncover those those really problematic areas and um so it doesn't necessarily mean that if you've implemented multifactor you're all protected and that's the only thing that you you had to do and and you don't really have to

take care of the services anymore so it shouldn't be a tick in the box and um the um typical reasons why people don't do this is um well they say it's expensive and difficult to implement but you will definitely find expensive vendors and expensive providers for multif authentication but you'll also find um free software like the Google Authenticator um and you'll find open source Solutions and you'll find um not so expensive U but still third party solutions that will give you some level of assurance and um there there's also um a saying of um some people say that this is not for everyone and yes that's true but I don't think that the entire user base should

be um qualified by this because it isn't going to be confusing or or complicated for everyone and for example I've I've gone through a couple of large providers like um apple and Microsoft and Google how many of you have um Apple iCloud accounts yeah how many of you use Microsoft Xbox Hotmail outlook.com fewer and how many you use Android or Google yeah quite a bit so by this time probably most of you have put your hands up at least once and it's not only these providers there's the gaming providers and there's a lot a lot of other services out there that already use multiactor so the majority of the user base would have encountered this one way

or another so it really shouldn't be that confusing or complicated it's something that can be made easy and there's there's good examples of that being done so in my view again this is just my view these are excuses and I've mentioned Google and uh Microsoft and Apple as well so that really takes me to to the end of this and I'd like to um to um talk to you about this or I'd like to um hear if you've got any questions on this topic it's something that I think we should discuss so thank

you said that you triggered it to get HTTP yeah you do that you absolutely so the question was that um there was this example about battl net and there were um a couple of um queries that went through in plain text it was actually um I was actually trying to um to force HTTP transactions although if you go back maybe I should probably um go back to that slide there's um uh you can actually see that this cookie is both secure and HTTP only which normally means that secure um secure cookies wouldn't be um submitted through https and if you've got the HTTP only then you can't read the cooking value and from JavaScript but this um this

shouldn't be capitalized and as I was trying to HP traffic some of them have gone through this was a load balance solution the API there in and my guess is I couldn't verify this because it was a little bit unpredictable some of the load balancers might not be configured to the same standard as the others and some of them just let the the HTTP bounce back because there's alternating requests so some of them go to eu. b.net and some of them just go to battel net and the um sequence of the submission that send the token to B onet and then that um triggers response and you get another submission towards the the other URL and you don't really have control

over what happens there so when you try to forge it you forge this bit this request and then you may get a h response back because that's in the um in the that is triggered by the referral refer um which you can't see here unfortunately on this screenshot but it's um you second request to http it will just tell you to go away was this getting the code from them or is this submitting your code this is the what the authentication authenticator keeps submitting so it goes on and on and on so it's just happening in the background as you've got this and this counter and as the um as the code is this code is being

displayed on the screen the same code is being submitted at the back end um twice a second towards the API so you keep submitting this and then you trigger one of the transactions um to be HTTP you force it and then the next one would suddenly be HTTP so you saying that sometimes it just randomly send it HTTP well you have to try and Trigger it but yes sometimes work you no um they actually servers actually have both 443 and 80 open and what I'm doing was I'm using this tool called burp proxy I'm Sorry by the way so with burp you have the opportunity to transcrip the SSL layer so when you're capturing the traffic um you've got the

opportunity to like it's like a time time lapse and you press pause and whenever you press pause you can then edit and modify that package that query and then H submit it or forward it and then you change that piece of package the information in it from https to http redirect the port from 443 to yes to get um there are other SSL stripper Solutions as well and you would have to try and somehow actively interact with the traffic I think you could for example um try and write a script for um etheral or and you can try other types of men in the middle attacks but you would probably have to someh try and

stiner with the with the traffic flow any other questions you looked at the um Google changed it now so when I log in instead using Google Authenticator got notification you looked at that all no that wasn't I didn't have time for to to look at that unfortunately but it would be an interesting um thing to look at as well as some of the Enterprise imp implementations like swivel and Duo where you've got in like a a box sitting on premises that integrates with some of the services and I'm pretty sure that that there's there are going to be areas that that aren't going to be protected as well as they should be so there's always a risk of

that impedes and we would really bad

it well at least you've admitted to it which is the first [Music] okay else cof minutes i00 [Applause]