G1234! - SSO Wars: The Token Menace - Alvaro Munoz & Oleksandr Mirosh

all right good morning and welcome to besides Las Vegas the ground one two three four track we are have a few announcements before we start we have the ssoa Wars the token minused be Alexander and Alvaro I was joking with him that I didn't cannot roll my arms my wife speaks Spanish and makes fun of me before we get started though we'd like to thank our sponsors especially that inner circle sponsors critical stack and Val mail and our stellar sponsors Amazon blackberry and the National Security Agency it's their support along with our other sponsors which allows us to make this whole thing go on since these talks are being streamed to YouTube we ask that you please silence your cellphone's

before we begin and that you use a mic if we have time for questions we should at the end please raise your hand and I'll run the mic to you so the people listening on YouTube will be able to hear it if you have feedback about this talk over for the speaker and there's a link on the sked entry for this talk you know with that let's get started please welcome Alexander and Oboro [Applause] okay can you hear me more or less okay so thank you all for attending our talk this is the token - my name is Hobart on earth this is Alexander meters we are both security receptors with microfocus fortify teen he specialized in dynamic

and runtime I specialize in static analysis so it'll give different fields so this is the agenda for today we will start with a brief introduction to what authentication tokens are especially in the context of delegated authentication and then we will be presenting a couple of vulnerabilities that we found related with authentication tokens both of them in dotnet frameworks and under net libraries so the first one is an injection vulnerability there are leads to arbitrary constructor invocation this doesn't seem like very dangerous but we will see what's the potential impact of this vulnerability and then we will present an XML signature verification bypass that allow us to basically sign any sam'l token and and get the server to

accept our sam'l tokens as valid so we will see how that us effect several of the Microsoft frameworks such as w CF and w if' windows identity foundation and some made your Microsoft flexi products such as Exchange and SharePoint so this brief introduction this is a diagram representing delegated authentication it's not supposed to represent anything specific like WS Federation or sam'l protocol is just a very genetic diagram right so basically we have three different entities the first one is the user that will try to access protected resource that is served by the service provider and the service provider is actually not handling authentication itself is actually delegating authentication to a third party entity those are the delegated

authentication name so it will redirect the user to this identity provider and the user will basically present the credentials to the identity provider it will verify the credentials and if the video if the credentials are valid it will handle token to the user that it needs to present at the service provider in order to access the resource this is basically as some a summary of a dedicated investigation so these tokens that are returned by the identity provider can be in multiple formats right like salmon or JWT JSON web tokens or simple web tokens or any other are really any any other format most of them have some similarities and they have these major or important attributes

right so these are the attributes that really are important to make a token functional the first one is the issuer so that's who you should the token is not the same if I give you a coin that I should myself that if a bank gives you a coin that they issued right so we also have the audience that is who this token is for so again it's not the same if we are create our token for therapy a this token is not valid for service be any service be accept our token for service a then there's a vulnerability and something that we can exploit we also have the expire date obviously we can't use a token after that date and

then we have a set of claims the claims are basically a set of attributes that we prescribe the user right so this will be used by the service provider for our taking authentication and authorization decisions but the most important attribute here is the signature right if we don't sign the token anyone can change any of the claims any of the issuer the audience anything in token and then get the service provider to accept that token as a valid token and then the attacker will be able to basically become anyone who wants to be in the service provider so there are multiple steps that an attacker can think about attacking but the most important one is for us or the one that

we focused on is a step number six when the user presents the authentication token to the service provider the user or the attacker obviously so yeah the service provider meets to parse and process the the token and basically it needs to verify all the attributes and also verify the signature if the signature is not valid then the authentication token should be discarded so we will be focusing in this step because we found two different interesting attack vectors in this step the first one is what if we can inject any malicious string in any of these attributes that case gets parsed before the signature purification so maybe that can lead us to some kind of injection

before the signature is verified itself and the second vector is well maybe we can go one step further and actually bypass the whole signature verification process so if we can do that it's like the Holy Grail because yeah we can basically modify any claims in the token modify the user ID that you say the email address and just authenticate as any arbitrary user so now we will see this tubular burner abilities that we found in dotnet framework and we will stop with a token passing vulnerability this case includes the station for talking plastic vulnerabilities okay so they're talking about just GW all together or GWT is internet standard for creation Jason based access dollars we

can see such doesn't on the screen it contains three main parts hitter by load and signature biology field from the hitter defines what outdoor image should be used for signature verification so it will be used before we know it's valid signature are not called signature dot Knapp has a couple library that can be used for GW deep token parsing and we found out the system indentity model talkin GWT library but this LG field - Krypto Alto to click the config create for name matter we noted that this method doesn't restrict type next so we are able to invoke arbitrary no argument public from start by the way this method can reach not only just GWT tokens the

similar problem is in some token as well for example algorithm attribute is secretion method element or some token will go to this method without any restriction as well but you can ask what we can do with this because we are not controlling can you tighten but actually we can't control some data first of all it's a its type name itself I'm going to show you a bit later how we can use it also please pay attention humpin guarded on the screen it is from dotnet framework and in.net current identity contacts is stored in starting the property and access to request probe parameters it is done through it so if no argument constructor using this approach it can

be very interesting for than a packet but this ideas the opposing no argument methods main not very realistic so we decide to take two servers from Microsoft is shuriken server and Exchange server and try to explore this problem there and here is our result SharePoint return it asks different results if object was created or not you can use it for getting information about the style product and even diversions also we were able to price a kind of exception that leads to deliver services exchange server gave us even more interesting results as we already mentioned we are controlling type name and it may be not just simple type name but not the qualified name this assembly

that we would like to like to load this time from this assembly third net allows to custom to control developers assemble loading by implementing own custom assembly observers and they might contain also often this custom assembly resolvers are installed by static constructor and usually it is not big problem to involve them by instant ination specific type and we actually can do this by this problem but this attack is not simple and sometimes even if you are able to add our assembly resolver and this assembly resolve has some vulnerability we may still not be able to perform attack for example if server has some assembly assembly is over before they before the attack and this assembly arises exception for our

malicious assembly name our new assembly resolve will not be called also the most of our gadget what we found allows us to 'lord libraries from local disk so attacker still need to find way how to upload malicious file to the server here we can see examples of such assemblies already gadget from exchange server on the first snippet it is installed by static instructor on the second one we can see assembly reserve itself a it use a sample name for thoughtful assembly loading but no validation at all so we can use dot the trick and change current folder to any desired what we want let's put all this together a certificate to user we can invoke arbiter in public no

argument constructor for any dll file from any folder on the server of course attacker still need to upload this file on the server and for an a certificated user it may be very tough task but it can be significantly easier if attacker has some account on the target exchange server so for our demo we as we have assumption that attacker is already put this developer in Windows temp folder and let's look how it will be in real exchange server first of all it's our malicious library with our gadget it is our type name and two lines of code we will take CMD query parameter and video will use its value for starting new process as we told you

earlier and this the file is already on windows temp folder so we can start crafting our request as you can see we are using some token here is our vulnerable attribute type name and assembly name is the trick that will change current folder to video stock and the final that we would like to start calculator here is the same first of all let's check in process Explorer that no calculator yet and we can send this request without any notification and we can see calculator and the process is for

now let's switch to our Holy Grail and we'll look how the entire signature verification can be bypassed security our search assertion markup language or just sam'l is critical component for many delegate identification and single sign-on scenarios it has xml-based format and here this XML signature for integrity protection by the way this problem is relevant not only for some but for other protocols and application that uses XML signature standard for example sign it soap or ws-security on this slide we can see simplified some token a long quiz in for a certification information it has signature element that should protect it from tampering this element contains three main parts signature itself in signature value sign it and for this

information how this signature should be verified and the most interesting element for our tacit key info represents key that should be used for signature verification sam'l protocol is quite old protocol and of course we are not the first ones who were decided to look on it security so we would like to highlight a couple examples of interesting finding from the past for example XML signature wrapping discovered in 2012 and tell us attacker to change original talkin but signature remains valid and the second our example was presented last year by Calvin Ludwig and he uses XML comments to change meaning of some token attributes but signature remains the same both examples require valid token and will not change

signature our attacks is different we are able to recalculate own signature and create some token is any information what you would like so we do not need and to have all it some token at all for understanding how is possible we should know how the net implements signature verification so first of all the need to obtain key using we can extract key itself from it or use key reference to fetch key from some storage on the second step using this key we will verify signature value but please note after this step if you have a positive result it only means that this token was silent by this key and to his it was not changed in addition to this it should be

sure that it was done by proper signing party so we are taking key in for element again try to identify who has signed this talker and of course on the last step we will check it is expected sudden party trusted or not on the first glance it may looks like secure implementation but please pay attention on this two steps we are taking key in for twice and we need difference type of results on these steps security key on the first and security token on the second so we need to use different methods for it results security key and resource security token on this type we can see description from Microsoft documentation because proposals of these

methods are different we can expect inconsistent results program and the finally we can see the general idea of our talk we should craft keen for in such a way that both method will produce different results one will be used for signature verification and another for notification of silent party in this case we will be able to use own sign in our own ki-46 signature calculation but Sutter still identify us as expected sign in packet in general such a type the track

so in general such a type the present employment ation of dimensional matters but all cases would what we checked we were able to get this results some cases had additional requirements to the server or environment it will show a bit later other were vulnerable by default so let's see examples of differences between this matter that can be used for attack first method can support some type of kin data file that is not supported by the second one both method can process elements in different order or even take can use different subsets of this elements now let's see how this attack looks on real-world application and frameworks so yeah we will be reviewing some of the most important

frameworks in Microsoft that actually take or accept sam'l tokens so the first one will be WCF we will see that in a few seconds that is basically used to build web services like for example exchange server and we will show you an example of how we can take any account or compromising account using this technique the second one will be windows identity foundation that is basically used for any application that wants to integrate with an identity provider so if you want to process authentication tokens and extract the claims you don't want to do that from your own like reinvent the wheel to we'll be using Windows identity Foundation to take care of that process and last but not least

we will see how some applications like sharepoint actually customize the configuration of wif and can make it even more vulnerable that in the default operation so the first framework is a windows communication foundation as I said it's used to build web services as a Microsoft framework but it's used to build service-oriented applications which basically interoperate with other web services and clients I developed in other languages and and frameworks it will basically exchange XML documents that are in the form of soap messages but the most important part for us is that it will accept sam'l tokens to authenticate the client so if you are a client to come present your your credentials either with maybe user and

password but you can also submit an event a sam'l token in order to authenticate yourself so depending on the version it will it may use Windows identity foundation to take care of the process of handling the authentication token or not we will start by focusing on when it's not using wif and then we will review when it's using a wif because it's different resolvers and different attack so the class that is responsible for handling the token the authentication token in this case the sam'l token is this sam'l assertion token sam'l assertion class here and it will basically contain this piece of code so as we can see we have a two methods that Alex mentioned the first

one is the resource security key that will take the whole key info section so this key identifier variable is the whole key info section and the other method is resource security token that takes the same data and this is user control data but both of them return different elements different objects the first one will be returning the verification key that is the one that it will be used to verify the signature of the sam'l token and the second one will be returning the signing token that is used to verify that it was signed by the identity provider the identity provider that the service trusts not any one so the first one when resolving the security key this is how the code it

basically takes what we call depth-first approach so it will basically iterate through all the different keys in the key info section there may be multiple normally it's only one but the standard allows multiple of them so many of them so it will iterate through all of them and for each of them it will call this try resolve security team down here so this method will basically try a number of different resolvers we have at least three of them in order to try to extract and resolve the key so the important thing here is that we are first iterating through the keys and then through there were soldiers now if we check how the token is resolved that's

what we call breadth-first and is to coin a slightly different approach is first iterating through the resolvers and for each resolver it will pass the whole key info section and will basically exam iterate through all the keys individual key elements so basically it's like having two nested loops in the first one we will be iterating first for the keys and then resolvers and in the other one first resolvers and the second one or the second level will be iterating through the keys so we will be basically iterating through the same elements but in different order and when changing the order we can actually abuse that in order to bypass the signature process so now let's imagine we have a token or we

can even create one token from scratch and we will sign it with our own symmetric key we generate a symmetric key or even a symmetric key but for this example just keep with have the symmetric key and we'll sign our own talking with our own key it should not be trusted right and now we're going to send both the symmetric key but also the expected and trusted certificate from the identity provider we are going to send two elements in this key info section now the resolved security key will iterate through our first through the keys and we'll take our Malizia symmetric key then it will try all the resolvers for this key and the two first

resolvers will fail but the third one will succeed and it will return our symmetric key that will be used to verify the signature since we control it we can bypass it now they resolve security token down here will basically do a different approach and will first iterate through the resolver so it will take the first resolver and with that resolver it will try to resolve the two key elements here so the first one will fail because it will not trust a symmetric key that it doesn't know but for the second one it will succeed because it's actually the certificate from the identity provider so it will return that certificate and that certificate will be used to

authenticate the signing party that is the identity provider so now we are able to bypass the signature am just basically craft any arbitrary tokens so this is how it looks in in the XML token we have this first element that is in this case a symmetric key but it could be an a symmetric one and that's the injector key the one that we will use to resign the document and the one that the server will use to verify the signature and the second one in green is actually the original trusted certificate from the identity provider and this one will be the one that the server will use to verify the trust in the identity provider so let's see how we can have

used that for example to take over some account in exchange web services so we thought about doing this demo using a real client such as Outlook or link but the demo was kind of complex and longer so we developed our own client for the xnw s but you can even craft your talking without intercepting any real tokens you can just craft it and sign it and it's still valid but for this demo would prefer to to intercept a real token and modify it so this is burp basically we will be using birth to intercept this client request and this is the client that we developed it's very simple we are just sending our request for user 1 in the name of user 1

and we are basically requesting the mail tips we could have asked for the mail items themself but this is more simple so we send that and we intercept the request and if we send that to repeater in order to modify it like more Muricy we can switch to XML view and we will see the whole sam'l assertion first in in the header in the sub header and then the body of the soap request so we will be replacing all the instances of a user one with administrator if we don't refine this with we just basically intercept our request and we just modify it we will break the signature and this will not be valid right so if we send the request

like this we will get an internal server error because it's not able to verify the signature we just break it prove it however we developed these our plugin for burp that we will be releasing and it will allow us to resign it with our own keys so in the original assertion you can see that there is only one element in the key info that is the expected identity provider certificate now if we click on resign with RSA key it will basically create a new RSA key pair and then use the private one to resign the whole token and then in the King four section we will find the one from the identity provider but also our

own RSA key that remember this one will be used for verifying the signature so now if we send that we'll get a 200 response which is successful and we can see that we are able to get in this case the mail tips for the administrator and we get no errors and the response was successful so with that we are able to basically impersonate any user in exchange web services

do you mean like transport protocol at that for security doesn't matter because you're crafting your token from one from the client and in this case we are intercepting it but if you don't want to intercept it you can craft the same token yourself and just sign it so interception is just one out there at one version of the attack also if you control the client you can use birth to intercept the traffic further for that client even if it's using SSL okay so Windows identity foundation it is another Windows Internet affiliation or just W wif is a software framework for building indentity aware applications it is very easy to add a delegate identification to application or and

support identification tokens from difference security tokens services like Active Directory Federation services Azure Active Directory Windows Azure access control services and others alright for parsing some tokens dub wif uses sam'l security token handler and it uses a bit different approach to the key info element that we just saw in previous section for security key to verify signature value it will take only the first element of our key info but for security token for our identification of signing party it will work with all key into the fires from key info also WI F by default configuration uses is sure token resolve this result seems to be secure because it has very similar corded for both mentioned metals but in

case if this method cannot resolve some key into the fire it it will be passed to the next resolver x.509 certificate store token Azure and here we have difference in dimensional method that can be a burst a result security key can work with encrypted key editor fire Klaus but result security token doesn't support it definitely this difference can be exploited but here we have a couple problems to decrypt our symmetric key server needs to have certificate with private key in some specific certificate storage by default it's local machine trusted people also attacker would need to use public key from this certificate to encrypt this key and it is just public key so in many cases it is not big problem but if this

requirements are met we can perform our attack so we can use symmetric key for signature calculation after that we can encrypt this key using public's public key from server certificate and put encrypted key into the five cloves in the first place after that we will put our expected certificate so a result security key whether turn our symmetric key and we will pass signature value verification but resolve security token doesn't work with encrypted key in data file Clause so it just skip it and we'll take the second element from key info element painful and it is represents expected expected silent partners so we will pass uncertificated of sign apart as well on this slide we can see examples of key

info for this attack encrypt a symmetric key in cipher data internal key info in yellow section represents certificate which public key was used for encryption and the similar to previous case in green section it's expected certificate be very viewing default configure a configuration of wif but it allows a lot of customization so let's review some example of customized wif so if you are using wif to build your application you can customize it and one of the major products for Microsoft products that customize wif is sur point server so it's very interesting target for us and we analyzed how sir point customize wif for their own purposes so it basically use a standard default configuration but it uses a

default issuer token resolver the SP you are token resolver and remember this is using WAF so for security keys we only process the first element in the key info section and for security token resolution we use all of the elements in the token in the key info section apart from that the Curie solution supports symmetric and a symmetric keys they are called internally like intrinsic case but for token resolution it doesn't support them right so we can abuse that in a very similar way to what we did with exchange by resigning our token or crafting a token from scratch and then signing it and use our own private RSA key to sign it and then send the public key of this

RSA keeper along with their original and trusted certificate to the server again the server will take one for signature modification and take the other one for authentication of the signing party and we will be able to abuse that in order to make the server use our own RSA key for very final signature so this how it looks in XML it's very similar to what we saw in the exchange demo it's using an RSA key as you can see here we are sending the models and the exponent for the public key this is what is an intrinsic it's something that can be recreated out of this data and then obviously the original and trusted certificate for the signing party so we

thought like J now we cannot use an attack cell point but we found another problem so this is how the authentication flow works for SharePoint more or less if there is any Microsoft engineer in the room please correct us if we are wrong but basically what the user is doing is requesting an authentication token from the AVP for the identity provider it may be IDF s or a s your Active Directory or any identity provider and with the authentication token it will present it to SharePoint so sir point will validate that using their token resolver that I just saw you the SPS we're talking through solver which is vulnerable and we can abuse that and make it trust our

signature and then bypass the signature verification okay so far so good but now cell phone doesn't want our sam'l token it will exchange that token with internal sir point STS that is a security token service in order to get an internal local session token and this other service that is implemented as a WCF web service that is using wif is using the wif default resolver which alex is playing that in order to attack these configurations we need to get access to the public certificate that is stored in the Third Point server this is somehow Stremme limitation and we didn't want to go this way because it's not that that funny so what we did we found

a different flow basically it's not a flow but a different way but we can abused to to exploit it so in step number 6 you can see that the session token is cached right and then out of this session token it generates a session cookie that is returned to the user now in order to attack start point using this technique what we can do is authenticate as valid user as the attacker maybe with a low privilege account and then get our session our session cookie in this process the session token for the attacker will be cache and the cache key will be an internal identifier for the attacker right just remember that now what we will be doing is basically

crafting a malicious token from scratch that will have some very specific claims so first of all the issuer will be a SharePoint it will not be the identity provider and then we will use the victim data of the victim attributes as the for example user principal name user ID so the token will be representing the victim but we will send the attacker internal ID for as the cache key so now cell phone will receive that it will verify the signature we will bypass that and then because the issuer is cell point it will not try to exchange the token with the STS the security token service and will basically create a session token out of this data so we are

basically creating a session token for the victim but when storing it in the cache we will use the attacker cache key and therefore we will be poison in the cast I'm basically replacing the session token for the attacker with the victim one so now all that the attacker needs to do is refresh the the browser browse again to SharePoint and then it will get authenticated as they as the victim now if you do that for a Minister account that's basically our remote code execution so last demo um so here we are as the attacker is browsing to SharePoint and is basically going to authenticate with valid credentials as I said maybe low privilege or maybe he

wants to escalate privileges to get remote code execution now we will just get authenticated as the attacker as you can see here so far nothing special no no attacks just basically logging in as as a user in serpent now we can go to this in point that is an API endpoint to get information about the users insert when it's public and you can access that if you have an account any account so that returns a piece of XML that I'm sorry for the font size but I will zoom in very quickly so basically if we search for the attacker we want to get the attacker internal ID so you can see that the attacker internal ID is this long

string with some information about the amira email address and the identity provided and so on and now if we search this document for the victim we will get the big team internal ID so this is the information we need to craft our malicious token and then because we can't resign it using our key confusion attack then it will be accepted so this is the code to craft this malicious token we will be using the victim internal ID but for the application talking - key we'll be using the attacker one and this is what will allow us to replace and poison the the attackers session token so this is the the token that it generates as you can

see here in the key info section we have two key identifiers the first one is the RSA key value that is the one that we use to resign it the one that we control and then the kid went afire that's our point trust now if we scroll up a little bit for the sum all claims or attributes we can see that we have the user ID and everything points to the victim right the a user ID also the user email address the UPN but the application token cash key that is a special claim will point to the attacker internal ID so now if we send this this request serpent will basically replace the attacker session token in the cache with

the victim one and now we just have to go to the browser refresh the session and then we will get authenticated as as the victim and remember if you do that for administrator that will lead to remote code execution so oh yeah we are releasing this burp plugin is not ready yet will be probably released tomorrow at after black hat talk it will be released in this repo that's for sure and it will basically allow you to intercept sam'l assertions and more tokens and just modify them and use either an RSA key to resign it or if you get access to the public certificate in the case of a wif application then you can import it down here and then

resign it so there will be instruction and more information in the repo probably tomorrow so with that some few conclusions basically we are not saying that sam'l protocol or WS Federation protocols are insecure is basically that some implementation has some flaws in this case the flow in the dotnet implementation is that they are processing the same user control data with different methods and they are a slightly differently processing this data right and we can abuse that in order to make one of the methods process one key and the other one process a different key also we focus on researching dotnet libraries and framework because basically it was not vulnerable to any other attacks before any of the other attacks that Alex

presented and we didn't review any other languages or frameworks we don't expect this very same flow to be present in other languages because somehow specific to.net and how it handles keys and tokens in a different way but there may be similar flows from there are out there in in other languages libraries also even in dotnet XML signature remember this is a vulnerability that effects sam'l token verification but the vulnerabilities in the way that XML signature is processed and basically XML signature is used in a lot of other places we found other cases that we reported to Microsoft and they patch them but there may be other cases where XML signature is still insecure main takeaway but as soon as possible if

you have any sir points or ten servers on-premise because obviously the cloud ones are already patched and with that if you have any question I think we have a still some minutes or you can reach us in Twitter with our our Twitter handles so thank you very much

we have a little more than five minutes and let me remind you please raise your hand and I'll run the mic to you to ask questions so people watching online are able to see it or hear it I mean so I'm that's just fascinating that's really excellent work I'm wondering whether you see the problem in the sam'l specifications are they vague about how this about how multiple key information is supposed to be processed or are the standards clear and the implementations where the problem is yeah so normally you will always find that key info section contains only one key that's like 99% of the cases but actually the standard allows multiple keys but it doesn't define how they should be

treated and probably one of the use cases is because you made the key rotation and then you may send the act there for one but send the next one to be a store buy by the client or something like that but I don't think that that is documented it's the legal case I sending multiple keys actually Microsoft support them but because it's not very normal I think that it's not handled like or is not tested very thoughtfully that's our assumption thank you either what version and build exchange was that demo done in okay so it was do you want to answer this one yes it's Exchange Server 2019 and it was before last Tuesday patch because the last

Thursday part solve this problem I think it's think like in India in the spring I can I cannot tell you exactly building number but it's quite fresh it was done in the spring in the spring there's another question by the way problem is not an exchange server we just want to highlight again problem in dotnet framework libraries so it's we don't do not see any string dependency on the built of exchange server what are the best practices to be able to shut down this type of attack I mean if you apparently if you use different you know if you can't get the public key for that particular machine as far as using a different a different public key for the

internal trusted store versus what the web server presents what's the best way to shut down other than patching you be honest with a shocked to see that this key info is passed it's it's it's processes twice why we need to do this twice secure secure by just take 1 times take what what you need talk and key and other stuff or at least verify that they are connected somehow here there are no verification that they are connected the keys from from token are talking from key and teacher we believe that proper implementation should they should choose this way to check connection between the results or use only one method one approach for both results so other than that for for

patch in other than patching the other thing that you can do just said that not make public or not expose the public certificate of those certificates store in that particular certificate storage but that's only for windows identity foundation for WCF for sharepoint add that doesn't matter so the only way of real putts in the issue is by applying the latest security patches also for sharepoint for example you need to upgrade to the latest version of SharePoint but also and get the latest version of the identity mobile library through nougat so do better go to the Microsoft page for this CV because in for example in sir point is not a straightforward it's not just as simple as I pray thee

sir point person to the latest version I'm just curious it sounds to me like this is all our Prem this is this a pop-up or the 365 platform and it used to be it used to be until the Tuesday but you light used a pad so the good thing is that because it's Microsoft infrastructure they already patched that so online version 12 version is but now it remains the on-premise leftovers you know if you're enter companies are using on-premise services don't those need to be bad now along with that though was it defeated by a tow 365 by MFA or not say that again sorry was that actually preventable by MFA multi-factor authentication or ah that's a good

question so if sam'l token requires a second factor then yeah it will be prevented by by that because the sam'l token will be just one of the factors good question thank you we have time for one last question if somebody wants it

been exploited in the wild - if it's been around for several months I mean that's especially this on though 365 no I don't mean no of I mean we don't have access to Microsoft monitoring systems for for example all 365 so there's no reports of it being exploited or even any on Prem stations and any solutions that detect this sort of attack now that has been implemented it guys it was not publicly available this information we will be just to knows about this and report it to Microsoft Microsoft knew about this for a couple month and we can understand Microsoft because if you can see description for CBE they're huge of product that should be punched including

dotnet framework and other stuff so it was not publicly available information its first time when we presented so we were not exploiting nothing and hope nobody problems were from yep so it was known for Microsoft for couple months but it was known just Microsoft into us is there a way to find out if someone has been exploited but this is tool with the beginning so block or any kind of reference it and he ought to sing on any home frame system we have an idea I mean we can't be a hundred percent sure that I don't know someone in China or in Russia knew about this mobility and was exploiting it we as soon as we found it will report it

to Microsoft and as far as I know in the CBO report they say that it's not exploited in the while so I don't think that they have evidence says that it's been exploited in the while all right so this is the the CB number for the U key confusion you will find a lot of information in Microsoft bulletins about how to patch it if it's spreaded in the wild or not thank you all for coming out please thank Alexander and overall and support our sponsors [Applause]