nOAuth-ing to see here.
[ Music ]
Dave Bittner: 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 the threats and vulnerabilities, solving some of the hard problems, and protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. [ Music ]
Eric Woodruff: If an application is vulnerable to this abuse, basically if I know like a legitimate user's email address that uses that SaaS application, there's a way I can set that email address in my own sort of attacker Entra tenant and then authenticate essentially into the SaaS application, you know, as the legitimate user. So, you know, whether you want to call it spoofing or impersonation, right, the end result is I'm in that SaaS application as that user and have access to, you know, whatever they would have access to in that application.
Dave Bittner: That's Eric Woodruff, Chief Identity Architect, Semperis. The research we're discussing today is titled "nOAuth Abuse Alert: Full Account Takeover of Entra Cross-Tenant SaaS Applications. [ Music ] Can you walk us through how you went through this testing to see if your suspicions were correct?
Eric Woodruff: Yeah. So it actually kind of there was a confluence of some other research that we're doing in the Entra app gallery, which is kind of like a catalog of application integrations. So I had read the research that Descope had performed, you know, back in 2023 and like what they published and some of the other stuff. MSRC published at the time as well. The Entra application gallery sort of made a nice way to find, you know, applications that use OpenID Connect, right. And so this is another sort of core requirement is that they're OpenID Connect applications. Yeah, I just started poking at a few, kind of going down the list, as boring as maybe that sounds, and I happened to find one that was susceptible. So I kind of just kept chugging away through the rest of the list that are in the Entra app gallery.
Dave Bittner: Can you walk us through how that works? I mean, how do you go about doing that and also making sure that what you're doing is ethical and also, you know, you're putting guardrails on yourself?
Eric Woodruff: Yeah. So I mean, in the testing that we're performing, right, to make sure I'm staying within, you know, like the boundaries of ethics, the only applications we tested were ones that I could sign up for, like, you know, a service as myself, right. At the time we were testing, there was like 1,017 OpenID Connect applications. And I found like about 104 of them, right, I could go sign up for like a trial or, you know, sign in as myself, right. So I'm the legitimate user, right, so to speak in that application. And then, you know, I would try to create some sort of like bit of data, right, to sort of make sure I could act as like a legitimate customer of the app. And then I had a separate Entra tenant where I was the attacker, right. But in this whole scenario, you know, I'm only going after myself, so to speak, right. So I'm not actually trying to get access to something like I shouldn't have.
Dave Bittner: Sure. So what kinds of applications did you find were most vulnerable here?
Eric Woodruff: So I mean, it's, you know, a small smattering of applications that were vulnerable. There was a few systems that had PII, right. So there was an HR, you know, platform, if you think of something like Workday. Now, Workday wasn't one, to be clear. But we're talking a platform like that. There's a few like collaboration platforms, think of platforms where you might do mind mapping and, you know, diagram sharing and other sort of like business collaboration. There's a few that also still actually are vulnerable, so we've been sensitive to not actually really talk about what they are. I'd say mid-June when I last checked, that was still vulnerable, also contained PII. That would be similar to like stuff you'd find in like an HR application. Out of the nine, there wasn't anything that was necessarily I'd say consistent, you know, across like the vertical or type of software it is or whatnot.
Dave Bittner: Right. And you rated this vulnerability as being severe. What led you to that category?
Eric Woodruff: Well, I think because the attack itself, right, it's already essentially documented, right, by Descope when they published. And then obviously like when we published, right. If you're technical, right, you'd be able to read our findings and also, right, sort of figure out how it works. If you're a technical person and you know of a vulnerable application, right, it's a relatively easy attack to pull off. It's easy to get access to an Entra tenant. It's easy to basically follow the steps to replicate it. You know, obviously you need to know of an application that is vulnerable, right. So that is the sort of wild card here. But if you did happen to have an app that was vulnerable, not only is it easy to pull off, but it's, you know, as we say, near impossible to sort of detect. And, you know, the customer really can't do anything to mitigate it.
Dave Bittner: And is that because -- well, explain to me why that is.
Eric Woodruff: So, you know, from the mitigation perspective, right, all the traditional stuff one might use to try to protect applications in their Entra tenant, like conditional access and maybe, you know, asking for multifactor or phishing resistant, all these common things, or maybe they're using a cloud app security broker, you know -- CASB solution -- that's looking at the traffic, but the attacker is coming in essentially out of band, right. So the attacker is in a completely different Entra tenant. So nothing that you can do within your own Entra tenant, from a traditional perspective, is going to help really mitigate things. The only thing you're really left then from a detection perspective is log correlation, right. So the theory would be, well, I can take all my Entra sign-in logs and I can take all my SaaS application sign-in logs and kind of cross-correlate them, right, and basically look for SaaS application sign-ins where there isn't a matching Entra sign-in. But that theory is great. In reality, that is difficult to impossible with SaaS apps. Primarily because a lot of SaaS applications offer very poor logging capabilities, right, for sign-in events. And even ones that do, they don't really have a way to easily integrate that stuff into like a SIM like Sentinel or Splunk or something, right. So again, the organization that's kind of stuck in the middle between, you know, Microsoft and the vulnerable SaaS app, that's our only detection. And it's nothing I've ever seen anyone actually doing out in the real world. So that's why we say it's like, you know, almost next to impossible to detect.
Dave Bittner: Well, you mentioned in the research that the true mitigations lie with the app vendors themselves. Can you explain that for us?
Eric Woodruff: Yeah. Right. Microsoft's response, right, is that this is developers following anti-patterns in how they implement OpenID Connect in their application. So not to get too like in the nerdy weeds here, but within OpenID Connect, there is like a unique string that's generated that the identity provider -- so Entra -- can like guarantee that that string is, you know, Dave, right. So the application can say, hey, as long as I'm always getting this string in the ID token that's sent from Entra, I can guarantee that this is Dave and it's not anyone else. The problem comes in where app vendors might not implement OpenID Connect that way. And instead they may say, oh, I'm just going to look at Dave's email address, right. And as long as I'm getting Dave's email, then I know this is Dave, right. But the problem becomes, in the Entra world, you can't guarantee that the actual email address being sent is, you know, verified by the person who's saying they own it so to speak. So that's where, right, like the app vendor is not following OpenID Connect specifications. I mean, this isn't just a Microsoft thing, right, this is actually in the spec where they say to use that unique string, which is called a subject, right. So you kind of have this architected scenario so to speak, where because Microsoft allows email to not have to be necessarily, you know, verified, that these two things come together to sort of create the vulnerability in the SaaS app. [ Music ]
Dave Bittner: We'll be right back. [ Music ] And is there no way for the user to know whether or not the provider is properly configuring things?
Eric Woodruff: Yeah. So unfortunately, right, the user is stuck in the middle. Unless you were to say, go test the application for the vulnerability, there's no way as a user or an enterprise with users to know that the app is vulnerable. Now, again, Microsoft argues there might be legitimate reasons that they want the email address, right. And kind of is like that's why we're not going to stop sending it as an option if SaaS applications want it, right. Because, say, right, I go sign into a SaaS app and they, say, want to actually send me an email, right. Well, this makes it easier because we already know the person's, you know, email address. You know, I'd counter some of those arguments with -- I think Microsoft could do more to potentially put something on the app integration so that customers could be aware that the app is asking for email, right. This would be something more like that an enterprise IT could use to, you know, determine, hey, if there's maybe some risk here. But, you know, unfortunately Microsoft hasn't really said much about these, I guess, ideas that we had when we opened the case with them, right. Again, it's not an absolute. It's not going to say, yes, definitively, this application is vulnerable. Because ultimately, you don't know what the application is doing with the email address until you actually authenticate to it. But it can at least sort of surface to organizations, right, hey, these applications are asking for this, you know, maybe we should talk to the application vendor and make sure, you know, that they're implementing OpenID Connect correctly.
Dave Bittner: Right.
Eric Woodruff: Sorry, I'm getting a bit soap boxy there.
Dave Bittner: That's okay. You've earned it [laughing]. So you mentioned in the research that you did responsible disclosure to Microsoft, but also some of these SaaS vendors.
Eric Woodruff: Yeah.
Dave Bittner: What sort of reaction did you get from them? >>Eric Woodruff: Yeah, so the vendors, it was a bit of a mixed bag, which I think is interesting and maybe sad in itself. You know, as a positive, we had one vendor who we contacted, and within a week they resolved it, and it was a great experience, I'd say. So I don't want to sound completely negative in that. This vendor, you know, we got a hold of their data protection officer, explained the problem, had some back and forth emails. They implemented a fix. They asked us to test again. We found there was still a vulnerability. And then they said, yeah, like our application is, you know, sort of geographically deployed. So they fixed it in another region, and then, you know, everything was buttoned up there. And I would love to use them, and I've been talking with them. I hope we can maybe sort of disclose at some point who they are so it can kind of be like a good case of, right, working through this in a positive way. But other vendors, yeah, you know, it was difficult to find who to contact, right. And so the mix would be like, well, you know, either going on their website and looking at, you know, security or privacy or data protection policies, and/or, you know, just opening support cases and/or just trying to spam, you know, security at, you know, company domain.com. And some of them, you know, like we'd open a support case, and it was open for like months, and then we'd get a little more -- well, I don't want to say aggressive, right. But like, hey, like you know this is a pretty critical problem in your app, right. Like in theory, if I know who any of your customers are, I could get into their data. And yeah, some of the vendors, you know, there's no response from them, right, back to that. There's two of the ones that we found that are still vulnerable again last that I checked. Do you suppose that a vendor who's been alerted to this, is there a way for them behind the scenes to see if it's under active exploitation?
Eric Woodruff: I guess it probably depends on their app and how it's built and what they log and what they don't log, right. So again, it's such a mixed bag, right. You don't know how they're capturing the ID token or what attribute data they're pulling out of it, right. They may or may not be able to. I mean, ultimately, right, if they went into some sort of, right, debug process looking for this problem, yes, they should know it's potentially being exploited. However, ultimately, I think their focus should be more on just fixing the problem, right? Because they could say, oh, well, it's not actively being exploited, but unless they actually change their code, right. Say they're not following OpenID Connect spec, there's nothing that would prevent someone from theoretically exploiting it, you know, at some point down the road.
Dave Bittner: Right. Looking at the big picture here, I mean, what does this say about the potential gap between these identity standards and their real world implementations?
Eric Woodruff: Yeah. No, I mean, I think that's a great question, right. And it's probably filled with a lot of opinions that are subjective. I mean, like I will say, right, like authentication is tough. And I'm an identity nerd. And if I'm doing Auth0 or OpenID Connect stuff, I mean, I still have to go look at the diagrams and be like, how is this supposed to work again, right? And again, like the modern authentication is tough, and you can't expect like every developer, right, to be like an expert in authentication. You know, but at the same time, I sort of have a personal grudge I'd say against the cybersecurity industry in the way we educate, you know, folks around authentication and identity. Like if you go look at a lot of the education and, you know, the focus on cybersecurity these days, there isn't a lot that tries to get into to, you know, identity and authentication and, you know, things like OpenID Connect. And again, it's very, you know, dry and boring on one hand, and if you just let me start talking about it, probably everyone listening would fall asleep. It is so important, obviously, that people understand how this stuff works. And yeah, I mean, it definitely says something about the industry, right, that there's this disconnect with the standards and how they're implemented. But also, I think there's a big educational gap and a gap in the focus, right, on how we're building up, you know, people's knowledge around this.
Dave Bittner: Yeah. I mean, ultimately, whose responsibility do you suppose this is? I mean, does this come down to the standards groups or folks like Microsoft who are implementing? It doesn't seem like the users are to blame here. > >Eric Woodruff: Yeah, right. I mean, in this one, absolutely not. The user's just kind of caught in the middle. I mean, this thing in particular I will say is, well, unfortunately unique because it's kind of like Microsoft has architected themselves into a bit of a predicament with it, right. And I'm not in their mind, right, when they wrote OpenID Connect, I mean, you know, going on over a decade now. Microsoft sort of took the spec and they've implemented some unique qualities that allow you to have multi-tenant apps, right. So, you know, Microsoft and Google, right, they're kind of the only two big authentication providers, right, where you can go to some website and there's, you know, sign-in with Microsoft, sign-in with Google. I mean, I know on consumer apps, there might also be like a sign-in with Facebook. But if we're really just focused on enterprise, right, they're the two where you can have that, you know, sign with Office 365, and it doesn't matter, you know, kind of where your Entra ID that's underlying that stuff lives, right. In Google, similar. And I'm not a Google expert, so I don't know how they implement things. But it's kind of like again this confluence of the standard plus Microsoft building this multi-tenant architecture thing, and then you sprinkle in, right, this ability to, right, have unverified email addresses creates like the perfect storm essentially for the nOAuth attack. You know, that's why like if you went and looked at something like Octa or whatnot that doesn't have this sort of concept of multi-tendency, right, it wouldn't be, you know, vulnerable to this, again, just because of the way it's architected. Yeah. So what are your recommendations then? What do you hope folks take away from the research?
Eric Woodruff: Well, I mean, big picture, right, like I hope that it's created some noise potentially so that developers, right, go look at their code. And again, if an app vendor is not properly implementing OpenID Connect, that they think about it again twice, right. End of the day, they don't, I would think, want their customers to be a target, right. Because the sort of resolution for customers, right, if the vendor doesn't fix it is to, you know, dump that SaaS application. I mean, I would hope that Microsoft maybe thinks about adding some sort of attribute on these applications again so that customers will at least know that, right, this email claim is being used. And/or I do think that there's a place where Microsoft could eventually sunset this, right. There are ways that application developers could get email addresses if they really want them, right, that don't have to come in this way. And if Microsoft sunset that, it would absolutely resolve this problem within Entra ID, right. And you know how things go. They could say, 2028 or something, right, we're going to sunset it. And people plenty of time, right, between now and then to sort of change how their apps are implementing things.
Dave Bittner: Right. And then extend it and then extend it [laughing]. Meanwhile, back in the real world. [ Music ] Our thanks to Eric Woodruff from Semperis for joining us. The research is titled "nOAuth Abuse Alert: Full Account Takeover of Entra Cross-Tenant SaaS Applications." We'll have a link in the show notes. That is Research Saturday brought to you by N2K CyberWire. We'd love to hear from you. We're conducting our annual audience survey to learn more about our listeners. We're collecting your insights through the end of this summer. There's a link in the show notes. Please do check it out. This episode was produced by Liz Stokes. We're mixed by Elliott Peltzman and Tre Hester. Our executive producer is Jennifer Iben. Peter Kilpe is our publisher. And I'm Dave Bittner. Thanks for listening. We'll see you back here next time. [ Music ]
