 Let's welcome these gentlemen to the stage. So thank you all for attending. Um, this is the token menace. My name is Alvaro Munoz. He is Alexander Miros. We are both security researchers with micro focus 45 team. And today we are going to, uh, present some of the vulnerabilities that we found in the net framework. Um, they are related with authentication tokens so we will introduce them and see how they work in the context of delegated authentication. And then we will present these two vulnerabilities. The first one is an injection vulnerability leading to arbitrary constructed invocation and we will see what we can do with, with that. It's a parameter less constructor. And the second one is what we call the up key confusion, uh, which is a way of bypassing XML signature in, not just in a, in some more session, in some more tokens, but, uh, we will apply it in for some more tokens. So we will review them in the context of the, of these Windows frameworks, uh, Microsoft, uh, framework, Windows Communication Foundation and Windows Identity Foundation. So, um, delegated authentication is nothing else that when you have a user accessing a resource, um, that is protected, but the service provider that is hosting this resource is not handling, uh, the authentication itself. It will basically redirect you to a third party entity or the identity provider, which will, uh, take care of the delegation. So the user will go there, present the, um, credentials and then, um, the service pro, the identity provider will issue an authentication token. It can be in the form of a SAML token. It can be in the form of, um, I don't know, JW token, uh, maybe, um, simple web token, but most of them have some attributes in common, right? Things like the, the issuer who issued the token. It's not the same thing if I give you a coin issued by myself that if you go to a bank, uh, the audience, if this is a token that is valid for service aid, I should not be accepted by service, uh, service fee, expiration date, things like the claims, right? So all the knowledge that the identity provider has about the user, um, that will dump into the authentication token and it will be used by the service provider in order to take, uh, both authentication and authorization, um, decisions. But the most important thing is the signature. If we don't sign the token, uh, anyone can change anything, can basically tamper with the token and just become anyone for the service provider. So, uh, we found that for us, the most interesting, um, a step in this process was when the service provider is accepting the authentication token. And the reason for that is that, uh, we thought about these two, uh, potential attack vectors, right? The first one is that there is a bunch of attributes in this token that, um, are going to be parsed and processed before the signature is, um, verified. Like for example, what is the, uh, signature algorithm, uh, that is going to be parsed before the signature is verified. So maybe we can, uh, have some injection vulnerabilities there. And the second, uh, the second vector is if we can go a step further, maybe we can go and, and get, um, the signature, the whole signature, uh, verification process bypassed. If we can do that, we can, uh, basically just become anyone for the service provider. So we will start with the token parsing one. This case can be good illustration for token parsing vulnerabilities. Uh, JSON web token or just GWT token, uh, is internet standard for creation, uh, JSON based access tokens. We can see example of such token on the screen. Uh, it contains three main parts, uh, payload, header, and signature. ILJ field from header defines what algorithm should be used for signature verification. So it will be used before signature verification itself. Uh, in .NET, there are couple of, uh, libraries that, uh, can parse GWT tokens. Uh, we find out the system indenting model token GWT library passes ILJ field to the crypto config create for name method. This method doesn't restrict type names. So we can call arbitrary, uh, no argument public constructor. By the way, GWT is not only one way to, to, to, to this method, uh, it can be reached during some token parsing as well. For example, algorithm attribute in signature method, uh, element from some token will go without any restriction to that method as well. But you can ask what we can do with this because we cannot control any data. But actually we can control some data. First of all, it's type name itself. And we will show a bit later how we can use it. Uh, also please look on the screen. It is example of, uh, no argument constructor from .NET framework. In .NET, uh, current HTTP context, it starts in static property and access to, uh, request parameters is done through it. If, uh, no argument constructor use this approach, it will be very interesting for, for an attacker. But all these ideas about abusing no argument methods may look not very realistic. So we took two servers from Microsoft, Sharia point and exchange server and tried to exploit this, uh, problem there. And here is our results. Sharia point returned us different, uh, response if, uh, object was created or not. Using this, we can get informational installed products and even their versions. Also, we could rise and had an exception that leads to, uh, Daniel of service. Exchange server gave us even more interesting results. Uh, as we already mentioned, we can control type name. And it, it can be not just simple type name, but assembly qualified name with name of assembly from which we would like to, uh, load this, uh, type. Uh, .NET allows, uh, developers to control assembly loading by implementing own, uh, custom assembly resolvers that may be vulnerable to different attacks. Uh, also, often this, uh, custom assembly resolvers are installed by static constructors. And usually it's not big problem to invoke them by instantiation of some specific type. But actually this problem allows us to do this, uh, so it's not problem. Uh, here we can see an example of such, uh, gadget from, uh, exchange server. On first, code snippet, we can see that how it is installed by static constructor. On the second snippet is assembly resolver itself. Assembly name, it doesn't have any validation and used as part of path for daily loading. We can use ..trick and can change, uh, current folder to any what we want. Uh, let's put all this together. As un-tatificated user, we can invoke, uh, no, no argument public constructor from any . . . file on the exchange server from arbitrary local folder. Of course, uh, attackers still need to find way how upload this malicious . . . file to the server. And for un-tatificated users, we think it can be very tough task. But if, uh, attacker has any account in target exchange server, it may be significantly easier. So for our demo, we have an assumption that attacker is already put this . . . file to the windows temp folder. This folder used for temporary files. For example, during, uh, un- zipping archives or others, uh, other such cases. Uh, so let's look how, how it will be in real exchange server. So first of all, it's our, uh, malicious library. Here is our gadget with two lines, uh, very helpful. We will take CMD query parameter and we'll use it as its value for starting new process. Uh, as we told you earlier, we already have this . . . file in windows temp folder. Now we can start crafting our payload. Uh, we will use, uh, some token. Here is our vulnerable attribute. Type name. And assembly name is . . trick that points to our library in windows temp folder. Uh, we will start calculator. And here is the same calculator. Uh, let's check in process explorer that there are no calculator yet. And we can send this request without any notification. And we can see calculator. We would like to stress here a couple things. First of all, it is pre un-tatificated attacks. Also, despite that this attack vary depends on available gadgets on the target system. This problem is not in product on application like exchange server or share point. This problem in .net framework, how it works with some attributes from un-tatificat- un-tatification tokens like SAML and GWT. Uh, let's switch to our holy grail and let's look how we can bypass the whole un-tatification. Security assertion markup language or just SAML is critical component for many delegated un-tatification and single sign on un-tat- un-tatification scenarios. It has XML based format and uses XML signature for integrity protection. By the way, this problem is not, is relevant not only in SAML but in any other places in .net where XML signatures use like, uh, sign it SOAP or WS security. Here we can see simplified SAML token. Along with un-tatification information, it has signature element that should, uh, protected from tampering. Uh, this element contain three main parts. Signature value, uh, this signature itself, uh, sign it in for with information how this value should be ver- verified and the most interesting element for our attack is key info. Represents key that should be used for this signature verification. Uh, let's review how .net will verify signature, signature for such tokens. First of all we need to obtain the key. Using key info we will extract, we may extract key from itself or using key reference and fetch key from some specific storage. On the second step, we will use this key for signature value verification. But please note that, uh, positive results after this step only means that, uh, this token was signed by this specific key and was not changed. In addition to this, we need to be sure that it was done by proper sign in party. So we are taking key info element again and try to identify who was signing this token. And of course the last step, we will check it as trusted sign in party or not. On the first glance it may looks like quite good implementation, but let's pay attention on these two steps. We are processing key info element twice. And we need different type of results on these steps. Security key and security token. So two different methods will be called. Result security key and result security token. Uh, on this diagram we can see general idea of our attack. We need to craft key info in such way that mentioned methods will produce different results. One will be used for signature verification and other for authentication of sign in party. In this case we will be able to use own key for signature calculation but server will still identify us as signed, um, trusted sign in party. Uh, in general, uh, this attack depends on implementation of a result security key and the result security token. But all cases what we checked we were able to achieve these results. Uh, some cases had additional requirements to the server or environment, uh, target server or environment. Uh, other were vulnerable by default. Uh, here are a couple examples of differences between these two methods that can be abused. Uh, first method may support some type of key identifier that is not supported by the second. Or both method can, uh, can process element in a different order. Or even they can use different subset of elements from key info. Uh, now let's review how this problem looks in real applications and frameworks. So, um, we will review now, uh, the main Microsoft frameworks that actually accept some of the tokens or treat some of the tokens in some way. So the, the first one is, uh, WCF, Windows Communication Foundation that is used to build web services. Uh, for example, Exchange Server, uh, or Exchange Web, uh, web services are built using WCF. And then the other one that is, uh, probably the, the two principal frameworks is Windows Identity Foundation, which is used by any application. Um, I mean, if you are a developer and you're writing an application that want to integrate with an identity provider, instead of, um, reinventing the wheel and, uh, write the whole code to process the authentication tokens and then extract claims and process the claims and so on, you will use, uh, Windows Identity Foundation to do that for you, right? So the third case is when you use, uh, WC, WIF with a custom, uh, configuration that is also normal in some, uh, development environment and we will, uh, use the SharePoint as an example. So we will start with, uh, Windows Communication Foundation that as, as I said, is a Microsoft framework to build, um, basically web services, right? So what matters to us, what is important to us is that, uh, WCF web services accept some of the tokens for authentication of the client. So if you're a client, you can present a some of the tokens instead of your user and password credentials, for example. So XML Signature is also used for other things or their purposes, such as proof tokens, but, uh, this is out of the scope of this talk. So, uh, this is the, uh, main code in the SAML assertion type that, uh, handles the, um, processes the SAML token, right? As you can see we have two methods. One is resolve security key and the other one is resolve security token. Both of them are taking the key identifier parameter, which is basically the whole text within the key info section in the XML Signature. The first one is returning a verification key, which will be used for signature verification. And the other one is returning a signing token that is basically representing the, um, signing party or the identity provider. So, the first one, uh, will first iterate through all the elements in the key info section. And for each of these elements, I will call the try resolve security key that will basically try a number of, uh, token resolvers. Like try resolve security key from the token resolver, then the, the parent class and then if everything fails, it will try to try create key from intrinsic key close. So, it's first iterating through all the key elements in the key info section and then for each, uh, key element is iterating through all the resolvers. That's what we call a depth first. So, when resolving the security or, or the signing token, um, the approach is slightly different. So, it will iterate first through all the resolvers and then for each resolver, it will, it will try all the different key elements or the keys identifiers. So, the difference is very small. Basically, the order in which all the possible combinations between keys and, and resolves, and resolvers are visited is different. But since we depend on one of them to be successful and return from these methods, uh, the order is critical. So, what we, uh, are going to do to attack or to bypass, um, SAML token, uh, uh, signature verification is that we are going to take an existing token or we can even create one token from scratch and then we are going to sign it. But in order to sign it, we are going to use our own private RSA key. So, we are going to generate, uh, an RSA keeper and we are going to use the private one to sign the token. Then, uh, we are going to send both the public key for this RSA keeper and also the, uh, identity provider certificate or key identifier. So, that's what you can see in the key info section. Now, remember the, uh, resolve security key will iterate first through all the keys in the key info section. So, it will take the attacker RSA key first and then it will try all the different resolvers. So, for the two first resolvers, it will fail. But the third one will succeed and will return the public RSA key. Since we signed the token with our private RSA key, the signature verification will bypass and it will be successful. Now, uh, for the resolution of the security token, it will start iterating through all the resolvers. So, it will take the first resolver and this resolver will try all the different keys. So, for the first one, it will fail because it does not know how to resolve at the attacker RSA key. But the second one is the expected identity provider certificate. So, that will succeed and then it will return the expected 509 certificate or whatever the identity provider is sending. So, with that we will bypass the authentication of the assigning party and then the whole verification process will be successful. So, this is how it looks in the XML section of the XML signature. The first element in yellow is the key that we injected and the key that we used to sign or resign the token. In this case, we are using an RSA key value with a, well the public one. Uh, but we can also use for example, symmetric key or even other asymmetric keys such as elliptic curve and so on. And then in green, we have whatever the identity provider is using. Normally it's a 509 certificate. This is a public certificate that we can grab from the, uh, federated, uh, metadata endpoint for example or from any existing token. So, let's see that in action. What we are going to do is we are going to, um, access exchange web services as any arbitrary user. So, we are going to impersonate any user. So, um, please bear in mind that the attacker doesn't need to intercept anything. He can craft the token from scratch because all the information he needs is public. Then he will send that token for authentication in the, um, exchange web services and then it can query the web services for retrieving emails, uh, sending emails or doing basically whatever anything you can do from, from outlook. But for this, uh, for this, um, demo, we are going to use, uh, valid, a real client. Well, we are developing our own client, but a real, um, token and then the attacker will be intercepting his own token so you can see the process of, uh, how the token looks like and, and what happens if we modify it. Okay, so, um, this is not what I'm looking for. So this is verb. We will be using verb to intercept the client request. And as a client we are using basically our own client that is sending or requesting the mail tips for the user one. So the attacker has this user one account and, uh, is trying to access its mail tips. Now if we send this request, um, we will intercept that with verb. Then we will send it to repeater to modify it more, more easily. And if we switch to the XML version, you will see that, well, we have first the, the sample token that identifies the user and then the, the body of the SOP request. So we are going to replace any, every instances of user one with administrator. In order to try to impersonate the administrator. Now if we send this, um, this request because the content has changed and the signature is no longer matching, uh, the server should reject this request. It's no longer valid because it's not signed and we are not supposed to have the private key for the identity provider. So we get an error and this is expected, right? You should, you should not be able to tamper any existing token. Now we can use our, uh, Jup key injector, uh, verb plugin, uh, that is going to resign the token using an RSA key. So as you can see here, uh, the original token has this, um, identity provider certificate. Now if we click on resign with RSA key, it will basically generate an RSA key pair, use the private one to resign the token and use the public one in the key info section. So in the key info section now we have the expected identity provider certificate, prepended by the key that we use to resign the token. Now if we send that, we will get a 200 successful response. In this case we are, uh, requesting the mail tips for the administrator but this is just an example. We can ask, uh, for any, uh, mail items, uh, sending, sending emails or whatever. Now let's, now let's review another, uh, .NET framework, Windows Identity Foundation or just, uh, WIF is software framework for building identity aware applications and it's very easy to add, uh, delegated identification for you, for your, uh, application and support identification token from, uh, different, uh, secret, uh, security token services like, uh, Active Directory Federation services, uh, Azure Active Directory or Windows, Azure, uh, access control services or others. WIF uses SAML security token handler for, uh, SAML token parsing and it, uh, uses a bit different, uh, way, uh, to work with key info section that we just saw in, in, in, in the previous section. Uh, during token parsing, when he tries to get security key for, uh, signature verification, it takes only the first element from key info. But for security token, it will process all elements, um, from this key info section. Also by default, uh, it uses issure token resolve that seems to be secure because, uh, code in both methods are very similar. But if they, this method cannot resolve some key in the defile, they, it will be passed to the next resolver. X509 certificate stored token resolver and this one has differences in, in, in these two methods. Result security key, uh, uh, can work with encrypted symmetric keys, but results, results security token doesn't support it. Uh, definitely this can be exploited, but there are couple problems with this scenario. Uh, server needs to decrypt our symmetric key. To do this, it should have, uh, certificate with private key in some specific, uh, certificate storage. By default configuration, it's a local machine trusted people. Also, um, attacker would need to use public key of this certificate for encryption. Um, but note, it just public key. In many cases, it's not problem. And if these two requirements are met, we are still able to, uh, perform our attack. We can use our symmetric key for, uh, signature calculation. After that, we will encrypt it by public key from server certificate and we'll put encrypted key in, on the first place. After that, we append expected certificate. So, on the server, result security key will return our symmetric key and we will pass signature verification. But result security token will skip this, uh, this element because it cannot work with it. And we'll take the second one that represents expected sign in party. So, we will be on, uh, on certificate uh, sign in party. Here we can see example of key info for such attack. Uh, our encrypted key in, uh, cipher data. Uh, internal key info in yellow section represents, uh, uh, server certificate which public key was used for encryption. And the similar as, uh, in previous, uh, uh, our example. In green section, we have, uh, certificate of trusted sign in party. Uh, we were reviewing default configuration of WIF. But it allows a lot of customization. So, let's look on one of example of customized, uh, WIF. So, one of the most interesting targets for us was SharePoint. And it's actually using, um, WIF, um, Windows Identity Foundation. But it's customizing this process, right? Um, so you can customize it in multiple ways. Like for example, changing the default certificate store as Alex mentioned before. Or a different way of customizing WIF is using a custom resolver. Um, so maybe you have some special needs and you have to, uh, process authentication tokens in a different way. So, that's exactly what SharePoint does. And it uses this SP user token resolver. And it's, uh, regular token resolver but the key resolution, uh, supports intrinsic keys such as symmetric or asymmetric keys. And token, token resolution does not support them. So we are back in the scenario of, uh, WCF where we don't need, we don't have any limitations about getting access to public keys and certificates from the server side. And we can just basically use our own symmetric key to resign the, um, the token and then include both the symmetric key and the expected identity provider certificate. Because of this difference in the resolution, uh, each method will return a different element. And the first one will be used for signature verification. The other one will be used for authentication of the signing party. So in this case, we are using a symmetric key. We can also use the RSA one that we saw before. But in this case, we're using binary secret that is, uh, basically the way of specifying a symmetric key in a token. As you can see here, there is no encryption. So there is no need to send the public key for, that was used for, uh, for encryption. And it's just sent in the room. Uh, in green section we have the expected identity provider, um, certificate. So we were like, wait, uh, we can bypass SharePoint authentication both on premises and on Office 365, which is pretty cool. But then when we tried to actually, uh, break into SharePoint, we realized that we were not able because the SharePoint authentication flow is a little bit special. So the user will get an authentication token from the identity provider. And we'll present this authentication token to SharePoint. SharePoint will validate this token by using the SharePoint user resolver that we just saw, which is vulnerable. So, so far so good. We can bypass the signature, uh, verification of this process. But then SharePoint doesn't know what to do with a SAML token. So it will exchange this SAML token, uh, in the SharePoint, uh, security token services that, which is an internal web service of SharePoint. And then it will try to get a session token in, in exchange. So this, uh, SharePoint, uh, security token service, it's using a different, it's a web service, uh, using WCF, but using WIF for processing the authentication token. So it's using the default, um, WIF token resolver, which, uh, depends on the attacker being able to get access to the, uh, this certificate. So this whole, whole process was getting a little bit complicated because also the attacker needs to craft the key info section in such way that it bypasses the signature verification for both, um, token, uh, validations. So it was kind of complex. So we found a different way of attacking SharePoint by abusing the step number six, which is where the session token gets into the cache. So, um, we are going to, what we are going to do is basically we are going to authenticate as, um, as the attacker as a, maybe a low privilege account. So this is a privileged escalation, maybe a remote execution vulnerability. So we get authenticated as the attacker account, uh, following the default, um, authentication flow. There is no attack here, no, no Jupyter confusion, nothing. But the attacker session token will get cached, right? Now, uh, what we are going to do is we are going to craft a special token. And it's special because it contains some special, um, claims and attributes in the SAML token. So first of all, the issuer will be SharePoint instead of the identity provider. Second, we will be using the victim or the user that we want to impersonate, uh, attributes as for example, the UPN, the user principal name claims. But we will still use the attacker identifier for the, uh, cache key, right? For the, the cache, um, reference. So SharePoint will receive our token, will validate using the SharePoint token resolver, which is vulnerable, we can bypass that. But since the token is issued by SharePoint, it will not try to exchange with the local, uh, security token services. It will just generate a session token from the data in our token. So it's going to create a session token for the victim, right? But it's, uh, going to try to, uh, cache the token and it's going to use the key for the cache that we send. So that's the attacker cache key. So with that, we will be able to poison the cache and replace the attacker session token with the victim session token. So now, now the attacker only has to login to, not login, but refresh the browser and then we are going to cut to, uh, retrieve the victim token from the cache, from the attacker cache. So let's see that in action, maybe it's more clear. So we are going to login into SharePoint. Uh, in this case we're using ADFS to, for, as the identity provider, but could be Azure Active Directory or any identity provider. And we are logging as the attacker. So maybe a low privilege account, uh, maybe we want to impersonate another user or maybe we want to become administrator to get remote code execution. So we are the attacker so far, so good, no attack yet. So now we are going to use, uh, we are going to visit this API URL that will get us a list of existing users in SharePoint. So, um, the purpose here is to collect information to craft this malicious token, right? So, we will search for the attacker internal ID in this XML. And this is, um, the attacker internal ID. We will need that to craft the, the malicious token. But this is public information, you can just query the, the write API. Now we will search for the victim internal ID. Very similar. And now we will use, um, some script basically to craft our malicious token. So for the malicious token we are going to use all the claims that represents the, the victim. So the victim internal ID, the victim email address, but for the application token cache key that is a special claim, we will be using the attacker one. So now if we generate the token, first of all we will have, uh, our key info section with the dupe key confusion. So first of all the RSA key that we use to sign the token and then whatever the key, the SharePoint identity provider or ADFS in this case was using. And then if we scroll up, we will see the, the claims in the SAML token. So for example we have, uh, the user ID that is pointing to the victim. So it's the internal victim ID. But this special application token cache key will be the attacker one. And this is the one that will be used to reference the cache entry that is going to be, um, poison or replaced. So we send that, uh, all we have to do now is go back to the browser, refresh the session and basically get authenticated as the victim. So remember if we impersonate administrator, this is basically remote code execution and SharePoint on premise and, and cloud versions. Thank you. So with that, and just to wrap up, uh, so first of all we are not saying that SAML or WS federation are insecure protocol. The, the devil is in the implementation in the details. In this case dot net was vulnerable because it's actually processing the same user control data with two different methods, uh, that has some small inconsistency. So if you are a code reviewer, you may always want to, um, review this kind of scenarios where you have two methods, two different parsers processing the same user control, uh, control data. Also we focus our research in dot net, um, we don't expect this very same flow to exist in other languages or, or libraries because it's very specific to dot net because of the way that they extract the key in one process in one step and then the token in a different step. But there may be similar vulnerabilities in other languages and libraries. Um, also, um, XML signature is not only used for SAML assertion. Uh, remember this is a vulnerability in XML signature. It's not a vulnerability in SAML. So we found different cases where dot net framework was using XML signature that we reported to Microsoft and are patched now. But there may be other cases where XML signature is used maybe in, in customer, in, um, people applications that are still vulnerable. And last but not least, patch as soon as possible because the cloud version have been passed but on premises like SharePoint Exchange or any WIF application are still vulnerable. And if, um, so, uh, go on to the, uh, Microsoft security bulletin because there are some specific instructions on how to upgrade for example on how to patch SharePoint, right? So it's not straightforward. And if you are a patching SharePoint, you have to update SharePoint version but also update some library version is not, not easy. So with that, uh, we are releasing a bird plugin, um, the one that I showed you in the first demo. Uh, it's basically a plugin that allows you to intercept SAML tokens, uh, SAML request and then resign them either using another key or using, uh, the public key from a certificate if you can get access to that for the WIF, um, scenario. So with that, if you have any questions or you can take them now or maybe later. Ah, we published a white paper with all the details. It's hosted in the Black Hat server. So just go and, and take it from there. So, no questions. Thank you.