CyberWire Daily - Code comments cause SAML conundrum. [Research Saturday]

Episode Date: March 24, 2018

Researchers at Duo Security recently unearthed a new vulnerability class that affects SAML-based single sign-on (SSO) systems. This vulnerability can allow an attacker with authenticated access to trick SAML systems into authenticating as a different user without knowledge of the victim user’s password. Kelby Ludwig is a Senior Application Security Engineer at Duo security, and he takes us through his discoveries.  Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. data products platform comes in. With Domo, you can channel AI and data into innovative uses that deliver measurable impact. Secure AI agents connect, prepare, and automate your data workflows, helping you gain insights, receive alerts, and act with ease through guided apps tailored to your role. Data is hard. Domo is easy. Learn more at ai.domo.com. That's ai.domo.com. Hello, everyone, and welcome to the CyberWire's Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down threats and vulnerabilities and solving some of the hard problems of

protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. And now, a message from our sponsor, Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security.

Zscaler Zero Trust Plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context, simplifying security management with AI-powered automation, and detecting threats using AI to analyze over 500 billion daily transactions. Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI.

Learn more at zscaler.com slash security. The vulnerability first came on my radar as part of an internal review for a potential dependency. That's Kelby Ludwig. He's a senior application security engineer at Duo Security. The research he's discussing today is called Duo Finds SAML Vulnerabilities Affecting Multiple Implementations. During that process, I identified a somewhat unintuitive behavior when I inserted comments which are valid in the SAML world to these messages. issue, it turned out that this unintuitive behavior that we were noticing actually seemed like it could be a bit more common than just this one specific instance. So once we realized that, we determined that it would be an interesting idea to look at other SAML service providers and libraries and see if it was a widespread issue. And it turns out that there were a number of vendors and libraries

that were affected by this type of issue. So let's back up just a little bit. For folks who may not be familiar with it, can you describe to us what is SAML, what does it stand for, and what's it used for? Yeah, so SAML is the Security Assertion Markup Language, which is why people say SAML, because that's a bit more of a mouthful to say. And so what you'll see SAML used in is it's a common language that's used for most often in a single sign-on system. So single sign-on is frequently used within organizations to give employees an easier authentication experience. So with single sign-on, you log into one application and that grants you access to, in turn, multiple different applications. So this is great for users

because it requires them to remember less passwords. They're entering passwords less frequently because they sign in once and then they are granted access to multiple applications. and then they are granted access to multiple applications. So that's what it is. What's going on under the hood that sort of exposed this vulnerability that you discovered? The way that SAML works is these SAML itself, this common language that multiple people speak, these messages are passed between a user's browser. So if you are logging into one service and then you then want to log into all these other services, this message is passed through your browser. So ultimately,

as the attacker, you can touch this, like effectively hold on to these messages and edit them as you please. Now, generally speaking, you shouldn't be able to do that because there's cryptographic signatures on these messages as they're passed through your browser. So what we identified was a way to edit these messages and change their meaning without invalidating these signatures. when these messages are passed through your browser during the normal authentication experience, you end up possibly authenticating as different users than what the service intended you to log in as. So take, for example, say you're the user John Doe and you log into your service as normal. Say it's your email provider is who you log into every day when you start your day at work. Once you log in as John Doe and you want to then access, say,

your financial information for payroll, the SAML message is passed through your browser. But if you were malicious and you want to maybe access the financial information of someone with a slightly different username like John, you can edit these messages and authenticate and see John's financial information. So let's dig into some of what's going on under the hood here, why you're able to make this work. So take us through some of the details. Yeah, so the way this ends up working is these SAML implementations have made a false assumption about what the DOM would look like once they're processing this data. And so the DOM is basically, you can think of it like a tree. What these implementations expect is that your username in this tree should only have just one branch.

only have just one branch. And so what it ends up doing in some cases is taking the first bit of information from this branch and using that as your username. But in reality, these comments, when you add them, it actually splits the tree out into multiple branches. And so you end up only taking out part of the username that you're using to authenticate these users. And this is all within XML, correct? This is all within XML, yeah. This is not technically wrong, it's just kind of unintuitive. You have to, basically you would have to know that a comment won't invalidate a SAML assertion signature, but it will split this tree into multiple branches. So what's also interesting about this vulnerability is it's not exclusive to truncating towards the end of the text. So earlier I gave the example of John Doe being truncated to John. So there are possible variants,

and someone has self-reported a variant to us of something like not a truncation, but actually extracting the end of the comment. So in the case of John Doe becoming John, you could also have a variant of this vulnerability where instead of adding a comment and getting John, you could add a comment and get Doe. I see. So it's one of those situations where it's not necessarily a bug, it's more a behavior, albeit an unexpected one. Exactly. It would be like saying SQL injection is a bug class, and you could have SQL injection affect a different service in a completely different way. So everyone has their own instance of SQL injection if they're

affected, but the general idea is the same. So help me understand how this concept of the tree works and what the real world effects would be of being able to get, I guess, essentially two different answers depending on how the question was asked. Is that a good way to say it? Yeah, that's a great way to say it. So for SAML to work, you need to have a shared understanding of what a user identifier is. So this could be something like an email. This could be something like a username. It could be a set of information. But ultimately, what you want is that the two parties that are sending these SAML messages should have a shared understanding of what a user is identified by. And so when you're inserting these comments and changing

the tree and then certain things are getting extracted in weird ways, you're ultimately changing what the understanding of the tree is to both parties, which gives you some leeway in who you authenticate as. Now, is there a non-bad guy reason to insert comments like this? You know, possibly. In practice, I haven't seen this. So I assume that there is a valid reason because, you know, it is something that is standardized. So there could be a very practical reason why someone does want to include comments as part of these messages. But in practice, I've never seen it done. Yeah. So just again, for my clarification, can you really lay it out basically for us here,

how in the real world, how someone would exploit this? Yeah, so that's where it gets really interesting is this shared language. So SAML being the shared language allows all the other parties participating to kind of have some flexibility in how they handle things. Because ultimately, what they're doing is relying on the shared language to convey something like a username. The way that someone might exploit this is by gaining access to someone's identity provider. So in this single sign-on context, you log into one application, which grants you access to multiple applications. As an attacker who has access to the identity provider, this could be, say, someone who has legitimate access,

like an insider threat, or this could be someone that has phish valid credentials for a user. So once you have that level of access, you now have some leeway in what applications you can access and what username you can use to log into those applications. So say you log into your identity provider and that grants you access to an internal chat application. So now you can take these SAML messages and tamper with them under the context of that user and possibly gain access to a different user that has a similar username. Now, has there been any reports of anyone using this out in the wild? No, we've seen no evidence of this being discussed before or exploited before. And how about protecting yourself against this?

What are your recommendations there? So I think our recommendation here would be contacting SAML service providers that you may use within your organization and just asking them if they're familiar with the vulnerability, what they've done to protect against this, or if they've already confirmed if they're not affected, just kind of getting that information from them. Because it's fairly difficult to tell, unless you're like a penetration tester or something like that. It may be difficult to tell if you're affected from a black box perspective.

So we just think it's best to just contact the people that have engineered these systems and see if they have a response for what they've done about this vulnerability class. And is there anything to be done sort of on the other side of it, the way that things are parsed? Are there updates or corrections to be done from that end? Or is it, again, like we said at the beginning, just more a way that something functions rather than a true bug? Yeah, so I think there's clearly some level of unintuitiveness to what has happened here, because this isn't a mistake that one person made. This is a mistake that multiple people made independent of one another. So there's definitely some level of unintuitiveness or lack of clarity around what should be done in this scenario. So there's definitely like some level of unintuitiveness or lack of clarity around

what should be done in this scenario. So this could be something that say like a SAML specification update could address to where maybe people that are implementing these specifications have a consideration for how to handle this particular situation. Yeah, it's an interesting one. It's sort of. It's almost like a translation sort of thing. You know, I imagine if two people are speaking a different language, you really need to depend on your interpreter, and two different interpreters might have subtle nuances in the way they interpret things. And this seems to me to be one of those situations where nuanced interpretation can make all the difference. Yeah, absolutely. What's kind of interesting about what started a big part of this research was

the reason or one of the things that made it click for us on like, hey, multiple people could be affected was once I found this initial bug, I started writing up possible examples that I could find in other XML libraries that exhibited this behavior. And one of the ones I wrote was not technically affected. I just wrote the code wrong. And so in writing a proof of concept to describe to other people, ended up making the same exact mistake, which really made it click for us. Like, oh, this person made this mistake. I just made this mistake knowing it's for us. Like, oh, this is like this person made this mistake. I just made this mistake

knowing it's a thing like this. This could be much larger than this single instance. Yeah. Yeah. It's an easy mistake to make. I think the most important thing is contacting your SAML service provider is probably the best option that an organization can take in the face of, you know, looking to remediate this vulnerability. Unless you have built a SAML service provider yourself, it's kind of hard to get to that level of intimate detail from, say, a black box perspective. So we strongly suggest just contacting SAML service providers that you may use in your organization or maybe in a different context and just asking if they

have been affected by this vulnerability or if they've patched. Now, just from a community point of view, you discover this sort of thing. Is this the sort of thing where you go out to the other SAML service providers and spread the word and say, hey, everybody, heads up, we found something here? Our disclosure process, we went through CertCC. So once we identified that this vulnerability may affect other implementations, one of the things that we did was look at open source sample libraries that we could find

on say GitHub and see if we could replicate this across those libraries. And so once we did, that was all local to my computer. So once we had some like local results that suggested that this may be more widespread than just a single instance, that's when we went to search BCT to actually contact other SAML service providers, like maybe that have cloud services, to disclose the general concept and to determine if they were affected before we published our results. It's interesting how nuanced it is. And it must have been fun for

you to kind of have those aha moments when you when you go, wait a minute, what is this? Is what's happening what I really think is happening? You know, that those this I think if you're like me, those kinds of moments can be really kind of fun. I think the best ideas and experiences always start with, hmm, that's a little weird. Right, yes, exactly. I wonder what would happen if I did this. Yep. Our thanks to Kelby Ludwig for joining us. You can find the complete report on these SAML vulnerabilities on the Duo website.

It's in their blog section. And now, a message from Black Cloak. Did you know the easiest way for cybercriminals to bypass your company's defenses is by targeting your executives and their families at home? Black Cloak's award-winning digital executive protection platform secures their personal devices, home networks, and connected lives. Because when executives are compromised at home, your company is at risk.

In fact, over one-third of new members discover they've already been breached. Protect your executives and their families 24-7, 365 with Black Cloak. Learn more at blackcloak.io. The CyberWire Research Saturday is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing CyberWire team is Elliot Peltzman, Puru Prakash, Stefan Vaziri, Kelsey Bond,

Tim Nodar, Joe Kerrigan, Carol Terrio, Ben Yellen, Nick Valecki, Gina Johnson, Bennett Moe, Chris Russell,

John Petrick, Jennifer Iben, Rick Howard, Peter Kilpie, and I'm Dave Bittner. Thanks for listening. Thank you.