We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

SSO Wars: The Token Menace

00:00
subtitles
off
playback rate
1
subtitles
off
English (auto-generated)
playback rate
0.25
0.5
0.75
1
1.25
1.5
1.75
2
quality
576p
1
 Cite
 Share
 Related Material
 Download Purchase
No logo availableDEF CON
 Muñoz, Alvaro Mirosh, Oleksandr

Formal Metadata

Title
SSO Wars: The Token Menace
Title of Series
Number of Parts
335
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
It is the year 2019. Humanity has almost won its long-standing war against Single-Sign On (SSO) bugs. The last of them were discovered and eradicated some time ago and the world is now living in an era of prosperity while the Auth Federation enjoys peaceful CVE-free times. However, while things seem to be running smoothly, new bugs are brewing at the core of major implementation libraries. This is probably the last chance for the evil empire to launch a world scale attack against the Auth Federation. In this talk, we will present two new techniques: 1) A new breed of SAML implementation flaws that break XML signature validation and enable arbitrary modification of the SAML assertion, which enables attackers to authenticate as arbitrary users or grant themselves arbitrary authorization claims. Although any implementation may be affected by this flaw, we will show how it affects Microsoft Windows Identity Framework (WIF) applications, Windows Communication Foundation (WCF) web services, and flagship products such as SharePoint and Exchange Servers. 2) A bug in the .NET crypto library, which may allow attackers to gain Remote Code Execution (RCE) or Denial of Service (DoS) depending on the availability of code gadgets in the target server. A new tool to detect this type of vulnerability will also be discussed and released. Alvaro Muñoz Alvaro Muñoz (@pwntester) is Principal Security Researcher at Micro Focus Fortify where he researches new software vulnerabilities and implement systems to detect them. His research focuses on web application frameworks where he looks for vulnerabilities or unsafe uses of APIs. Before joining the research team, he worked as an Application Security Consultant helping enterprises to deploy application security programs. Muñoz has presented at many Security conferences including BlackHat, DEF CON, RSA, OWASP AppSec US & EU, JavaOne, etc and holds several infosec certifications, including OSCP, GWAPT and CISSP. He plays CTFs with Spanish int3pids team. Oleksandr Mirosh Oleksandr Mirosh has over 11 years of computer security experience, including vulnerability research, penetration testing, reverse engineering, fuzzing, developing exploits and consulting. He is working for Fortify Software Security Research team in Micro Focus investigating and analyzing new threats, vulnerabilities, security weaknesses, new techniques of exploiting security issues and development vulnerability detection, protection and remediation rules. In the past, he has performed a wide variety of security assessments, including design and code reviews, threat modelling, testing and fuzzing in order to identify and remove any existing or potentially emerging security defects in the software of various customers
00:00
Single sign-onToken ringWindows Communication FoundationConstructor (object-oriented programming)AuthenticationVector graphicsMultiplication signToken ringAnalytic continuation.NET FrameworkVulnerability (computing)AuthenticationConstructor (object-oriented programming)Identity managementContext awarenessInformation and communications technologyElectronic signatureInformation securityWindowPresentation of a groupInjektivitätSoftware frameworkComputer animation
01:06
AuthenticationLoginAuthorizationToken ringElectronic signatureFormal verificationVector graphicsProxy serverParsingProcess (computing)Electronic signatureToken ringAuthenticationWeb serviceInternet service providerProcess (computing)Decision theoryFormal verificationParsingForm (programming)Attribute grammarInjektivitätVector spaceOrder (biology)Vector potentialProxy serverIdentity managementWorld Wide Web ConsortiumVulnerability (computing)AuthorizationTap (transformer)CASE <Informatik>AlgorithmComputer programmingComputer animation
03:24
Constructor (object-oriented programming)Codierung <Programmierung>Token ringFluid staticsAlgorithmString (computer science)Token ringParsingVulnerability (computing)World Wide Web ConsortiumCASE <Informatik>Goodness of fitLibrary (computing)Field (computer science)Configuration spaceProduct (business)Electronic signatureType theoryStandard deviationEmailTouchscreenPhysical systemCryptographyAlgorithmFormal verificationInternetworkingProcess (computing)Public key certificateMereologyIdentity managementComputer animation
04:21
Run time (program lifecycle phase)Type theoryInstance (computer science)Physical systemInformation securityFlagFormal verificationMachine codeSimilarity (geometry)String (computer science)Electronic signatureHash functionConstructor (object-oriented programming)Type theoryParameter (computer programming)Token ringAlgorithmParsingElement (mathematics)Electronic signatureAttribute grammarComputer animation
04:54
Constructor (object-oriented programming)HTTP cookieEmailParameter (computer programming)Category of beingString (computer science)Electric currentAuthenticationForm (programming)EncryptionConstructor (object-oriented programming)Parameter (computer programming).NET FrameworkBitContext awarenessType theoryOcean currentCategory of beingFluid staticsTouchscreenComputer animation
05:35
Vector potentialVector graphicsInformationServer (computing)Type theoryImage resolutionProduct (business)Exception handlingFrequencyResultantObject (grammar)Dependent and independent variablesInformationParameter (computer programming)Exploit (computer security)Denial-of-service attackServer (computing)EmailProduct (business)Exception handlingDifferent (Kate Ryan album)Computer animation
06:12
Vector potentialVector graphicsMachine codeAssembly languageConstructor (object-oriented programming)Physical systemServer (computing)Computer fileSpline (mathematics)Fluid staticsLengthString (computer science)Structural loadComputer wormResultantAssembly languageGame controllerDot productParsingStructural loadType theoryResolvent formalismOcean currentInformationConstructor (object-oriented programming)Validity (statistics)Digital electronicsMereologyTrigonometryServer (computing)Software developer2 (number).NET FrameworkMachine codeComputer animation
07:38
Demo (music)Computer fileCASE <Informatik>Real numberServer (computing)WindowLibrary (computing)Constructor (object-oriented programming)Demo (music)Parameter (computer programming)Computer animation
08:36
View (database)Digital mediaPhysical systemSpacetimeString (computer science)VideoconferencingExtension (kinesiology)WindowComputer fileBuildingSoftware testingComputer programLengthContent (media)DemonEmailWindowProcess (computing)Computer fileParameter (computer programming)Library (computing)Query languageCalculationType theoryAssembly languageAttribute grammarToken ringTrigonometryComputer wormComputer animation
09:28
Digital mediaView (database)Type theoryUniform resource locatorEmailIdentity managementCodierung <Programmierung>Content (media)LengthInformation securityInstance (computer science)Revision controlProcess (computing)BefehlsprozessorSuite (music)WindowParity (mathematics)Computer configurationComputer fileVideoconferencingDemo (music)Process (computing)CalculationStress (mechanics)AuthenticationProduct (business)Cartesian coordinate systemAttribute grammarToken ringServer (computing).NET FrameworkComputer animationSource codeXML
10:27
ElectronvoltMarkup languageInformation securityStandard deviationToken ringAuthenticationComputer wormSystem programmingFile formatElectronic signatureSystem identificationMarkup languageInformation securitySingle sign-onElectronic signatureFile formatIdentity managementAuthenticationToken ringConnectivity (graph theory)Data integritySign (mathematics)Computer animation
11:08
Electronic signatureInformationFormal verificationData integrityToken ringCalculationReflektor <Informatik>Key (cryptography)Electronic signatureFormal verificationElement (mathematics)Sign (mathematics)Information.NET FrameworkToken ringMereologyComputer animation
11:38
AuthenticationElectronic signatureWeightFormal verificationInformation securityToken ringKey (cryptography)InformationToken ringType theoryImplementationElement (mathematics)Statistical hypothesis testingElectronic signatureData storage deviceLoginFormal verificationDifferent (Kate Ryan album)ResultantSign (mathematics)Information securityMereologyAdditionProper mapComputer animation
12:47
Sheaf (mathematics)Key (cryptography)Element (mathematics)Formal verificationElectronic signatureToken ringInformation securityServer (computing)CalculationImplementationKey (cryptography)LoginAuthenticationResultantElectronic signatureCASE <Informatik>DiagramComputer animation
13:21
Type theorySheaf (mathematics)SubsetImage resolutionKey (cryptography)Active DirectoryConfiguration spaceSoftware frameworkPublic key certificateService (economics)Exchange ServerWindows Communication FoundationServer (computing)Machine codeWindowType theoryConfiguration spaceElement (mathematics)Order (biology)Software frameworkResultantCASE <Informatik>Key (cryptography)ImplementationIntegrated development environmentDifferent (Kate Ryan album)Process (computing)Token ringCartesian coordinate systemInformation securityIdentity managementBuildingWeb serviceIdentifiabilityAuthentication2 (number)InformationSubsetComputer fileSoftware developerComputer animation
15:14
TelecommunicationWindows Communication FoundationBuildingSoftware frameworkClient (computing)Electronic signatureProof theorySoftware frameworkClient (computing)Type theoryProof theoryWorld Wide Web ConsortiumElectronic signatureAuthenticationMachine codeWeb servicePasswordToken ringComputer animation
15:46
Token ringImage resolutionBlock (periodic table)Parameter (computer programming)InformationSystem identificationSign (mathematics)Key (cryptography)Type theorySheaf (mathematics)Identity managementElectronic signatureInformation securityElement (mathematics)Resolvent formalismInternet service providerIdentifiabilityToken ringFormal verificationComputer animation
16:23
Element (mathematics)Utility softwareException handlingInformation securityImage resolutionToken ringFluid staticsKey (cryptography)Information securityKey (cryptography)Element (mathematics)InformationSheaf (mathematics)Resolvent formalismMereologyLengthNumberInheritance (object-oriented programming)Token ringComputer animation
16:56
Image resolutionLengthToken ringKey (cryptography)Element (mathematics)Physical systemInformation securityElement (mathematics)Order (biology)Key (cryptography)Information securityDifferent (Kate Ryan album)Combinational logicResolvent formalismSign (mathematics)Token ringComputer animation
17:30
Inclusion mapPublic key certificateElement (mathematics)RSA (algorithm)Sign (mathematics)AuthenticationExpected valueElectronic signatureFormal verificationPublic-key cryptographyFormal verificationProcess (computing)Sheaf (mathematics)Element (mathematics)Public key certificateInternet service providerAuthenticationKey (cryptography)Order (biology)RSA (algorithm)Information securityIdentity managementToken ringElectronic signatureIdentifiabilityInformationResolvent formalismImage resolutionSystem identificationProxy server
19:09
Graph (mathematics)MetadataPublic key certificateSymmetric-key algorithmKey (cryptography)Element (mathematics)Identity managementElliptic curveInternet service providerToken ringPublic-key cryptographyCASE <Informatik>Group actionSymmetric matrixEllipseComputer animation
19:40
Demo (music)AuthenticationQuery languageInformationEmailGroup actionReal numberTap (transformer)Demo (music)DampingClient (computing)Process (computing)Token ringWorld Wide Web ConsortiumWeb serviceComputer animation
20:35
Identity managementDigital mediaSummierbarkeitHill differential equationNormed vector spaceThumbnailRevision controlEmailAddress spaceGroup actionClient (computing)EmailComputer animation
21:16
Lie groupDigital mediaEmailMenu (computing)Key (cryptography)Normed vector spaceAttribute grammarDisk read-and-write headContent (media)Order (biology)Revision controlSystem administratorElectronic signatureToken ringInstance (computer science)Computer animation
21:49
HTTP cookieError messageServer (computing)Content (media)Type theoryRevision controlDependent and independent variablesEmailDigital mediaRSA (algorithm)Disk read-and-write headGroup actionVideo game consoleSign (mathematics)Menu (computing)Application service providerInstance (computer science)Service (economics)Message passingEmailSystem administratorKey (cryptography)RSA (algorithm)Internet service providerPublic key certificateIdentity managementServer (computing)Error message.NET FrameworkPublic-key cryptographyDependent and independent variablesWindowToken ringSheaf (mathematics)InformationCASE <Informatik>Plug-in (computing)Computer animation
22:59
Identity managementInternet service providerSoftware frameworkBuildingProcess (computing)Token ringDecision theoryImage resolutionInformation securityElectronic signaturePublic key certificateSymmetric matrixData storage deviceDefault (computer science)Server (computing)Formal verificationSign (mathematics)EncryptionInclusion mapElement (mathematics)Software frameworkIdentity managementWindow.NET FrameworkBuildingEncryptionCASE <Informatik>Information securityElectronic signatureDifferent (Kate Ryan album)CalculationResolvent formalismServer (computing)Public key certificateVirtual machineData storage devicePublic-key cryptographyToken ringWeb serviceSymmetric-key algorithmConfiguration spaceCartesian coordinate systemParsingDefault (computer science)Element (mathematics)Sheaf (mathematics)Key (cryptography)System identificationFormal verificationInformationIdentifiabilityDirectory serviceGame controllerMachine codeSymmetric matrixContext awarenessLocal ringComputer animation
25:45
Symmetric matrixAuthenticationFormal verificationElectronic signatureSign (mathematics)EncryptionServer (computing)Public key certificateInclusion mapElement (mathematics)Symmetric-key algorithmResolvent formalismInformation securityParsingLoginKey (cryptography)Element (mathematics)Formal verificationElectronic signatureMessage passingInformationPublic key certificateXMLComputer animation
26:21
Public key certificateSheaf (mathematics)Key (cryptography)Default (computer science)InformationEncryptionPublic-key cryptographySimilarity (geometry)Computer animation
27:08
Server (computing)Information securityToken ringProcess (computing)Identity managementImage resolutionKey (cryptography)RSA (algorithm)Binary fileAuthenticationElectronic signatureFormal verificationSymmetric matrixElement (mathematics)Inclusion mapSign (mathematics)Public key certificateExpected valueIdentity managementWindowDifferent (Kate Ryan album)Server (computing)Public-key cryptographyPublic key certificateSheaf (mathematics)Electronic signatureAuthenticationData storage deviceElement (mathematics)Resolvent formalismSign (mathematics)Formal verificationRegular graphSymmetric-key algorithmToken ringLimit (category theory)Symmetric matrixImage resolutionInternet service providerGreen's functionProxy serverKey (cryptography)Office suiteEncryptionProcess (computing)CASE <Informatik>Queue (abstract data type)Row (database)Default (computer science)Diagram
28:51
Token ringDataflowAuthenticationHTTP cookieCache (computing)Identity managementInternet service providerFinite element methodToken ringInformation securityInformationElectronic signatureOffice suiteResolvent formalismFormal verificationMachine codeRemote procedure callKey (cryptography)Process (computing)Public key certificateAuthenticationValidity (statistics)Complex (psychology)Internet service providerDataflowSheaf (mathematics)Default (computer science)Web serviceVulnerability (computing)Identity managementCache (computing)NumberGraph (mathematics)Control flowWorld Wide Web ConsortiumComputer animation
30:37
Token ringAuthenticationDataflowHTTP cookieCache (computing)Identity managementInternet service providerPoint (geometry)DataflowKey (cryptography)Cache (computing)Token ringAttribute grammarIdentifiabilityInformation securityIdentity managementInternet service providerPrincipal idealWeb serviceWeb browserResolvent formalismComputer animation
32:09
Electronic mailing listWebsiteInformation privacyGoogolDigital mediaTerm (mathematics)Sign (mathematics)DreizehnCASE <Informatik>Group actionInternet service providerDirectory serviceIdentity managementStructural loadComputer animation
32:38
View (database)Digital mediaWebsiteWeb pageElectronic mailing listMachine codeRemote procedure callSystem administratorUniform resource locatorElectronic mailing listInformationToken ringScripting languageSimilarity (geometry)Computer animationSource code
33:32
Video game consoleToken ringParameter (computer programming)Identity managementInternet service providerDigital mediaCore dumpSinguläres IntegralMessage passingInformation securityExponentiationAttribute grammarStatement (computer science)EmailKey (cryptography)CASE <Informatik>Address spaceCache (computing)Cartesian coordinate systemToken ringIdentity managementInternet service providerInformationSheaf (mathematics)Computer animation
34:35
Digital mediaVideoconferencingView (database)RankingComputer networkCommunications protocolProcess (computing)Machine codeConsistencySimilarity (geometry)WeightElectronic signatureSystem callRemote procedure callMachine codePoint cloudRevision controlDataflowImplementationInformation securityVulnerability (computing)Parsing.NET FrameworkSimilarity (geometry)Formal languageKey (cryptography)Library (computing)Electronic signatureCommunications protocolCASE <Informatik>Game controllerConsistencyBulletin board systemCartesian coordinate systemDifferent (Kate Ryan album)Computer animationXMLProgram flowchartMeeting/Interview
36:45
Plug-in (computing)Demo (music)Plug-in (computing)Public-key cryptographyRSA (algorithm)Key (cryptography)Public key certificateServer (computing)Computer animation
Transcript: English(auto-generated)
00:00
let's welcome these gentlemen to the stage. Come on. It's been a wonderful time. So thank you all for attending. Um, this is the token menace. My name is Alvaro Mignot. He is Alexander Miros. We are both security researchers with Micro Focus Fortify team. And
00:21
today we are going to, uh, present some of the vulnerabilities that we found in .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 constructor invocation. And we will see what we can do with, with that. It's a
00:42
parameterless constructor. And the second one is what we call dupe key confusion. Uh, which is a way of bypassing XML signature in, not just in SAML assertion, in SAML tokens but, uh, we will apply it in, for SAML tokens. So we will review them in the context of the, of these Windows frameworks. Uh, Microsoft, uh, frameworks, Windows
01:03
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
01:23
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, um, 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, JWT token, uh, maybe a simple web token.
01:44
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, but if you go to a bank, uh, the audience, if this is a token that is valid for service A, it should not be accepted by service, uh, service B. Expiration date,
02:02
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
02:25
become anyone for the service provider. So, uh, we found that for us the most interesting, um, 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,
02:42
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
03:03
vulnerabilities there. And the second, uh, the second vector is if we can go a step farther, maybe we can go and, and get, uh, the signature, the whole signature, uh, verification process bypassed. If we can do that, we can, uh, basically just become
03:20
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
03:43
can see example of such token on the screen. Uh, it contains three main parts, uh, payload, header and signature. ILG field from header defines what algorithm should be used for signature verification. So, it will be used before signature verification
04:00
itself. Uh, in .NET, there are a couple of, uh, libraries that, uh, can parse GWT tokens. Uh, we find out the system in the model token GWT library passes ILG field to the crypto config create for name method. This method doesn't restrict type
04:25
names. So, we can call arbitrary, uh, no argument public constructor. By the way, uh, GWT is not only one way to, to, to, to this method. Uh, it can be reached during some token
04:43
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
05:04
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 is stored in static
05:23
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 looks not very realistic. So, we took
05:44
two servers from Microsoft, SharePoint and Exchange server and tried to exploit this, uh, problem there. And here is our results. SharePoint return us different, uh, response if, uh, object was created or not. Using this, we can get information of installed
06:03
products and even their versions. Also, we could rise a header exception that leads to a denial 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,
06:23
but assembly qualified name with a 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 custom assembly resolvers that may be vulnerable to different attacks. Uh,
06:46
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,
07:09
uh, gadget from, uh, uh, Exchange server. On first code snippet, we can see that how it is installed by static constructor. On the second snippet is, uh, assembly resolver itself.
07:25
Assembly name doesn't have any validation and used as part of path for daily loading. We can use dot dot trick and can change, uh, current folder to any what we want. Uh, let's put all this together. As un-certificated user, we can invoke, uh, no,
07:47
no argument public constructor from any DLL file on the Exchange server from, uh, arbitrary local folder. Of course, attackers still need to find way how upload this malicious DLL file to the server. And for un-certificated users, we think it can be very
08:04
tough task. But if, uh, attacker has any account in target Exchange server, it may be significantly easier. So, for our demo, we have assumption that attacker is already put this DLL file to the Windows temp folder. This folder is used for temporary files, for
08:22
example, during, uh, unzipping archives or others, uh, other such cases. Uh, so let's look how, how it will be in the real Exchange server. So, first of all, it's our malicious
08:46
library. Here is our gadget with two lines, uh, very helpful. We will take CMD query parameter and use it, this is valid for starting new process. Uh, as we told earlier, we
09:00
already have this DLL 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
09:23
and assembly name is dot dot 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 exposure, there are no calculator yet. And we can send this request without any
09:44
notification. And we can see calculator. We would like to stress here a couple things. First of all, it is pre-uncertified attacks. Also, despite that this attack very
10:07
depends on available gadgets on the target system, this problem is not in product on application like Exchange server or SharePoint. And this problem in dot net framework, how it works with some attributes from autotifica, autotification
10:23
tokens like SAM and GWT. Uh, let's switch to our Holy Grail and let's see how it can bypass the whole autotification. Security Assertion, Assertion Markup Language or just SAML is critical component for many, uh, delegated notification and single sign-on
10:45
autotifica, autotification scenarios. It has XML based format and uses XML signature for integrity protection. By the way, this problem, uh, is not, is
11:00
not in dot net where, uh, XML signature is used like, uh, sign it SOAP or WS security. Here we can see simplified SAM token. Along with autotification information, it has signature element. It's, that should, uh, protect it from tampering. And this element
11:20
contains three main parts. Signature value, uh, this signature itself, uh, sign it in FOA with information how this value should be ver- verified and the most interesting element for our attack, it's key info. It represents key that should be used for this signature verification. Uh, let's review how dot net will verify signature, uh, signature for
11:44
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 verification. But
12:01
please note that, uh, positive results of 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 signing part. So, we are taking key info, key info element again and try to identify who was signing this token. And of course, the last step,
12:27
we will check it is trusted sign in party or not. On the first glance, it may look 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.
12:44
Security key and security token. So, two different methods will be called. A 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 a way that mentioned methods will
13:02
produce different results. One will be used for signature verification, another 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 sign in, uh, trusted sign in party. Uh, in general, uh, this attack depends on implementation of result security key
13:27
and 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
13:43
examples of differences between these two methods that can be abused. Uh, first method may support some type of key in the file that is not supported by the second. Or both method can, uh, can process element in, in different order. Or even they can use
14:02
different subset of elements from key info. Uh, now let's review how this problem looks in real applications and frameworks. So, we will, uh, review now, uh, the main Microsoft frameworks that actually accept SAML tokens or treat SAML tokens in some way. So the,
14:25
the first one is, uh, WCF, Windows Communication Foundation that is used to build web services. Uh, for example, exchange server, 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,
14:45
if you're a developer and you're already in an application that want to integrate with an identity provider, instead of, um, reinventing the wheel and, uh, write the whole code to process 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
15:02
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
15:24
matters to us, what is important to us is that, uh, WCF web services accept SAML tokens for authentication of the client. So if you are a client, you can present a SAML token instead of your user and password credentials, for example. So XML signature is also used for other things, other purposes, such as proof tokens, but, uh, this is out of the
15:43
scope of this talk. So, uh, this is the, uh, main code in the SAML assertion type that, uh, handles the, um, well, the processes, the, 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
16:04
basically the whole text within the key info section in, 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, or the identity provider. So, the first one, uh,
16:25
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, try
16:43
create key from intrinsic key clause. 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, uh, depth first. So, when resolving the security or, or the signing token, uh, the approach is slightly different. So, it will
17:04
iterate first through all the resolvers, and then for each resolver, it will, it will try all the different key elements or the key's identifiers. So, the difference is very small. Basically, the order in which all the possible combinations between keys and, and
17:21
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, 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
17:42
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 key pair, 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 key pair and also the, uh, identity provider certificate or key identifier. So, that's what
18:02
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
18:22
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
18:40
one, it will fail because it does not know how to resolve 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, uh,
19:00
whole verification process will be successful. So, this is how it looks in, in the XML section of the, uh, XML signature. The first element in yellow is, uh, 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 the, with the public one, uh, but we can also use, for example,
19:21
a symmetric key, or even, uh, other asymmetric keys such as elliptic curve, and so on. And then in green, we have what, whatever the identity provider is using. Normally, it's a 509 certificate. This is a public certificate that we can grab from, 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
19:45
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
20:02
send that token for authentication of, in the, um, exchange web services, and then it can, uh, send 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
20:24
our 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 Burp. We will be using Burp
20:59
to intercept the client request. And as a client, we are using basically our own client
21:04
that is sending or requesting the mail tips for the user one. So, the attacker is, 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 Burp. Then, we will send this request to the
21:21
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 SAML token that identifies the user and then the, the body of the sub request. So, we are going to replace any, every instances of user
21:40
one with administrator. So, 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, um, 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, you should not be able to tamper any
22:05
existing token. Now, we can use our, uh, dupe key injector, uh, Burp 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
22:25
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 used to resign the token. Now, if we send that, we will get a 200 successful response. In this
22:43
case, we are, uh, requesting the mail tips for the administrator but this is just an example we can ask, uh, for any, uh, mailing items, uh, sending, sending mails or whatever. Now, let's, now let's review another, uh, dot net framework. Windows
23:12
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 your,
23:24
for your, uh, application and support identification token from, uh, different, uh, security, security token services like, uh, Active Directory, Directory Federation services, uh, Azure Active Directory or Windows Azure, uh, Access Control Services or
23:44
others. WIF uses SAML security token handler for, uh, SAML token parsing and it, uh,
24:01
uh, to work with key info section that we just saw in, in, in, in, uh, the previous section. Uh, during token parsing, when he tries to get security key for, uh, signature value verification, it takes only the first element from key info. But for security token, it will process all elements, uh, from this key info section. Also, by
24:26
default, it uses issue, issue token resolver that seems to be secure because, uh, code in both methods are very similar. But, if they, this method cannot resolve some key in
24:40
the file, they, it will be passed to the next resolver. X509 certificate store token resolver and this one has differences in, in, in these two methods. Resolve security key, uh, can work with encrypted symmetric keys. But resolve, resolve security token doesn't support it. Uh, definitely this can be exploited but there are a couple
25:05
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, uh, local machine trusted people. Also, uh, attacker
25:25
would need to use public key of this certificate for encryption. Um, but note, it's 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,
25:42
signature calculation. After that, we will encrypt it by public key from server certificate and we'll put encrypted, uh, key in, on the first place. After that, we append expected certificate. So, on the server, resolve security key will return our
26:00
symmetric key and we will pass signature verification. But resolve 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 untut, untutificated sign-in party. Here, we can see example of key info for such attack. Uh, our encrypted key
26:28
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
26:41
previous, uh, uh, our example. In green section, we have, uh, certificate, uh, of trusted sign-in party. Uh, we were reviewing default configuration of WIF, but it, uh, allows a lot of customization. So, let's look on, uh, one of example of customized, uh, WIF. So, one
27:07
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, uh,
27:22
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 SPE user, user token resolver and is, uh, regular token resolver but
27:44
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 this scenario of, uh, WCF where we don't need, we don't have any limitations about getting access to public, public keys and certificates from the server side and we can just basically use
28:04
our own symmetric key to resign the, 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 and the other one will be used for authentication of the signing party. So, in this case, we are using asymmetric key. We
28:25
can also use the RSA one that we saw before but in this case, we are using binary secret that is, uh, basically the way of specifying asymmetric 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 to, for, uh, for encryption and it's just sent in the room. Uh, in green
28:45
section we have expected identity provider, um, certificate. So, we were like, wait, we can bypass Serpoint authentication both on premises and on Office 365 which is pretty cool but then when we tried to actually, uh, break into Serpoint, we realized that we
29:02
were not able because the Serpoint authentication flow is a little bit special. So, the user will get an authentication token from the identity provider and will present this authentication token to Serpoint. Serpoint will validate this token by using the Serpoint issue resolver that we just saw which is vulnerable. So, so far so good. We
29:21
can bypass the signature, uh, verification of this process but then Serpoint doesn't know what to do with a SAML token. So, it will exchange this SAML token, uh, in the Serpoint, uh, security token services that which is an internal web service of Serpoint and then it will try to get a session token in, in exchange. So, this, uh, Serpoint, uh,
29:42
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 this, uh, this certificate. So, this whole, whole process was getting a little bit complicated
30:02
because also the attacker needs to graph the key info section in such a way that it bypasses the signature verification for both, um, token, uh, validations. So, it was kind of complex. So, we found, uh, a different way of attacking Serpoint by abusing the, uh, step number 6 which is where, uh, the session token gets into the
30:21
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, uh, maybe a low privilege account. So, this is a privileged escalation, maybe a remote code execution vulnerability. So, we get authenticated as the attacker account, uh, following the default, um, authentication
30:41
flow. There is no attack here, no, no deep key 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
31:01
Serpoint instead of the identity provider. Second, we will be using the victim or the user that we can, 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, Serpoint will receive
31:24
our token, will validate using the Serpoint token resolver, which is vulnerable, we can bypass that. But since the token is issued by Serpoint, 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
31:42
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, 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
32:02
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
32:22
going to login into SharePoint. Uh, in this case we are using ADFS to, for, as the identity provider, but could be Azure Active Directory or any identity provider. And we are login as the attacker. So, maybe a low privileged account, uh, maybe we want to impersonate another user or maybe we want to become administrator to get remote code
32:43
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
33:01
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.
33:21
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
33:42
victim, uh, email address. But for the application token cache key, that is a special claim, we will be using the, 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
34:04
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
34:25
to reference the cache entry that is going to be, um, poisoned 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 the
34:44
administrator, this is basically remote call execution and SharePoint on premise and, and so with that, and just to wrap up, uh, so, first of all, we are not saying that SAML or
35:03
WS Federation are insecure protocol. The, the devil is in the implementation in the details. In this case, .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, uh,
35:22
scenario where you have two methods, two different parsers processing the same user control, uh, control data. Also, we focus our research in .NET, um, we don't expect this very same flow to exist in other languages or, or libraries because it's very specific to .NET because of the way that they, uh, extract the key in one process, in one step and
35:43
then they talk 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, uh, where .NET framework was using XML
36:04
signature that we reported to Microsoft and are patched now, but there may be other cases where XML signature is used maybe in app- 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 patched, but, uh, on premises, uh, like
36:22
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, uh, patching SharePoint, you have to update SharePoint
36:41
version, but also update some library version. It's not, not easy. So, with that, we are releasing a BERT plugin, um, the one that I showed you in the first demo. Uh, it's basically a plugin that allows you to intercept some old tokens, uh, some old requests and then resign them either using an RSA key or using, uh, the public key from a certificate
37:01
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.