Who Are You & What Can You Do? Auth Security

For those of you that don't know me, my name is John Ziola. This is Steel City InfoSec. Thanks everyone for coming out. I wanted to start off by giving a big shout out to our sponsor for this quarter. So our sponsor is actually B-Sides Pittsburgh. They had a great year last year, a great event. They had a little bit of extra money in the coffers, so they were able to sponsor a couple events and support groups like me. The event is going to be on June 8th and June 9th of this year. So there's going to be a training day on Thursday, June 8th, and then there's the conference on Friday, June 9th. Is that

right? Did I get that right? Yeah, I think I got that right. So feel free to show up if you have an interesting talk. Technically, the CFP and the CFT whatever is closed, but I hear from a little birdie that if you submit to CFP at bsidespgh.com, you may still have a chance. So feel free to do that if you're interested. If not, we should be opening tickets up, some free registration tickets on the 15th and I think it's $5 a ticket this year or free at the door first come first serve. So you can reserve a ticket for yourself. We're selling 225, 250 of those and then there will be more free at the door if you can't afford the $5. So that is a thing.

So that's it. If you have any questions about it you can talk to me, you can talk to George back there, you can talk to Brian. and help out with organizing the event. And you can also email info at bsfpgh.com. So big thanks to them and their fancy new logo. I think it's pretty cool. Yeah, I spent a fair amount of time on it. So that's pretty much it for that. Again, like I said, this is Steel City InfoSec. We have monthly meetings here. If you're not aware, second Thursday of the month is the general cadence of these events. We try to do hands-on presentations and social events. Tonight is obviously a presentation. Next month we're going to try to do a hands-on lab, which I

think Kevin will talk a little bit about. And then the month over that we'll just have a social. So we'll pick a location, time, place, some local bar, and hang out and talk maybe about some of the information stuff. That's pretty much all I've got. So I'm going to turn it over to Kevin Cody. Kevin Cody is an extremely smart guy, consulting for Invisium. I have a lot of respect for him, and I'm really excited to see this guy. Let's give him a round of applause.

So to John, I don't know how many of these types of events the folks in the room here go to. I know that a couple of us have OAuths, but there's ISSA, ISAC, InfraGard, really, really awesome community in the security space here in Pittsburgh. None hold a candle to the kind of stuff that John gets in as far as just the cadence of meetings that he's putting out the content, as well as the fact that he's put in effort to have and labs and get-togethers. So, round of applause for John. Alright so tonight's a topic of discussion, who are you and what can you do? I'm gonna do my best to go through authentication and authorization topic in

regard to federated identity services. So, just to say it up front, folks the option if you do want to head to the door, you can. I have a little bit of everything, a little bit of everything for everyone in this talk. So I'm going to talk to some high level about federated ID services, lay some groundwork. Hopefully you can stick with me through that if that's a little bit elementary. Then we're going to go into some problems and kind of security related stuff as far as some of the pitfalls people fall into when we're working with identity services in effect And then I want to talk about some very specific technical attacks of these services. So if that's more of your flavor, try to hang

in there towards the end and we'll get to it. At the end of the day, I'm not an expert as much as John has kind of led me into that. That's not it at all. I am a security consultant. I do this stuff, live and breathe this stuff. I've done application security for the better part of the decade now. But at the end of the day, I do these types of presentations for myself to learn and to give back to the community And I learned just as much from the conversation in the room and preparing for this stuff as I do from my client engagements and apps that I test. So at the end of

the day, if you have a thought, you want to pine on something, raise your hand, shout out, happy to make sure this is an open dialogue in the room here tonight. A little bit about me. My name is Kevin Cody. I'm a senior application security consultant with Invisium, an application security consulting

of honor, folks in this room who may have worked with me before or know my ADD ways know that I kind of just fall in as first in some of this stuff, but I really enjoy it. I'm inquisitive. I like to dig in and that's kind of my flow. I'm a bit of a mainframe enthusiast and that's thanks to Josh as well as a couple of places that I've worked previously. If you are against mainframes or feel like the mainframes are going away the dead of the bird, I would love to have a drink with you after this and chat about it a little bit because it's not. And quite frankly, mainframes are awesome. They're doing huge amounts of transactions. And if you have a mainframe in your

environment or you're doing consulting and you need to test a mainframe, definitely don't stray away from it. Definitely do some research. on by the horns because it's awesome. And it's really the birthplace of a lot of the same types of things we see in the distributed world, or the IoT world, or the mobile world. And how we get that. How many decades have mainframes been going away? Yeah, that's a big one. How many people have retired on the fact that mainframes are going away because they're getting paid lucrative sums to support a legacy system that's not so easy. So I'm a husband, dad, hacker, lockpicker, blah, blah, blah, and a student in life. Thank you, John. All right. So just a field

room here. Who in your day-to-day work or maybe in a side project has actually implemented federated authentication in some manner? A couple folks, a few folks? All right. This is already better than the last time I gave this thought. How about you use federated authentication services in the workplace? So when you are at work or maybe school, you use some type of federated auth services. Less people than before. How about you're working toward implementing federated services in your workplace? What exactly do you use federated services? I don't want to tease the entire. We'll get into that in one slide. Good question.

Anyone know? Yeah, I use it at home. services in my home life. OK, we're going down here. You can pry basic authentication from my cold, dead hands, anyone? Love that basic auth, yeah? Anyone like Richard Stallman, like, I don't want passwords on anything, this might not be the talk for you. But we'll keep going. All right, so we're going to talk about authentication authn and authz. If you haven't heard of these terms, hopefully we can get to the bottom of those terms here today. the winds and shortfalls, explore the protocols and standards of some of these services. We're going to talk about some real world security concerns when it comes to authentication and authorization services in the federated world.

And this whole profit thing is silly, as well as my silly art at the bottom here. These are like the 2016 worst hacker stock art images. kind of like BuzzFeed but not really BuzzFeed list. So I didn't really create these, these were kind of tongue in cheek, but feel free to laugh. So the point of this talk is really just to give people thinking about the threats and the concerns involved with federated authorization authentication services. This isn't for me to give you the ability to go hack your neighbor, your friend, your significant other. And honestly, I wouldn't go after the federated auth service if I was anyway so all right so authentication and authorization authentication is the question who are you are

you Bob who works for evil core are you Alice who works for evil core are you Mallory just plain evil that's who you are all right that's off then we talk about off n versus off z if the hint there is off n authentication versus Z authorization. So authentication is asking the question, who are you? I'm Bob, I'm Alice, et cetera, et cetera. Authorization asks, what can Bob or Alice do? So Bob works for EvilCore, but he's just a plain user. So that's his authorization. If Alice works for EvilCore, she's an admin. She can do whatever she wants. Valerie is not a user at all. She's just plain evil and works and waits for her. Keep these

concepts in mind. Authorization is off Z. Authentication is

off M. So we have the question, what is federated? I'm spouting this word federated, federated, federated. What does that mean? So the actual term for federated in modern information technology, which is derived from the word federation elsewhere, basically just means linking of a person's electronic identity and attributes stored across distinct and multiple identity management systems. So we're talking about a system that can correlate data through distinct systems and then tie that back to a person's identity attributes. When we're talking about federated identity in terms of SSO, we're talking about something like a ticket, a token,

Something that's basically trusted on behalf of a user. You can even think of, if you're familiar with the Active Directory world and the silver, gold, Kerberos tickets, all that stuff. Kind of the same concept, except for in the SSO world, a ticket is transversing multiple different systems. And we'll dive more into that. So along with this term federated, we're also going to talk about assertions. Assertions is quite literally someone is asserting something on behalf of someone or another system, right? So allows identity and security information to be shared across security domains, contains information about a subject or principle, so on and so forth. And there's a real RFC that talks about assertions and what an assertion technically is. But the idea of federation

really relies on the fact that someone has to be able to assert something on behalf of someone else or a larger party. So as we're going through this information, the one thing that I like to keep in the back of my mind is the old adage that three may keep a secret if two of them are dead. So that's really important in the federated space, right? Anytime you're utilizing a federated service or system, you're inherently trusting a third party. That third party might be an internal federated service to your organization. You may have a little bit more trust in that. That federated service may be Google or AOL or who have you. You may have a little bit less trust in that. But at the end of the

day, if you're using a federated service, you're not using some type of integrated authentication or authorization service, you're putting trust in someone. So at the end of the day, if you're comfortable with that threat model of, trusting another party or the need to trust another party, federated services may be the way to go. If you are not comfortable with that, you take the old TNO, trust no one type attitude, you're probably not gonna wanna go with a federated service. That's a rat's tax.

This is a little tongue in cheek, but everyone's favorite punching bag right now is Yahoo, right? So if you don't trust Yahoo,

to keeping your secrets safe or even your metadata safe or being safe against warrants and lawful interception, then at the end of the day, that's the weakest link. The attackers are going to go after the weakest link. So if you use a service such as Yahoo or Google or whatever else to work as your federation service for your

operation needs, then you have to know that the weakest link is going to be the target. And that weakest link may be someone like Yahoo, who happens to have been hacked every which way of Tuesday. And that includes logs. Don't forget about logs. Just because you feel comfortable with someone's security state, right? So we feel comfortable with Google because of their openness. I'm not advocating for them. But we feel comfortable with Google because of their security. and Project Zero, and they're doing all this good stuff, and we feel, yeah, I think Google's where it's at. At the end of the day, there's still logs. There's still metadata associated with that, and it's traversing their servers. That's a place that a

law enforcement agent can get any warrants to retrieve that information. So again, . Okay, so now I'm gonna go through rapid fire here a little bit on some well-known different federated services. So these are buzzwords that you may have heard before. These are different federated services. So OpenID. Anyone here? OpenID? Know of OpenID? Use OpenID? Yeah, OK, great. So OpenID allows users to create accounts by selecting an OpenID provider and then using those accounts to sign to any website which accepts OpenID authentication. So here's the deal with OpenID. OpenID is not an authorization service. It's strictly authentication. So if you're using OpenID, you can say, OK, this is the username and password that I'm associating

with this account and allowing this federated service to let me log in. What OpenID cannot account for is once I'm logged in, this is what I can do. OK? So which there is an option for that more in a second. But just OpenID in its purest form specifically allows for authentication and the use of shared authentication mechanisms across different sites that are utilizing OpenID. So then there's OAuth or OAuth2. OAuth is kind of the opposite of OpenID. It's strictly authorization. It's an open standard. There's good things about it. There's bad things about it. I'm not here to debate the qualifications of OAuth. I've heard a lot of people say that OAuth 1 was good, OAuth 2 was worse, that the standard's a little too

open and it has been ripe for some different attacks. But at the end of the day, OAuth is for authorization. And if you can think of maybe a flow that you're used to in your normal world, if you're using OAuth, think of when you use maybe Facebook or

to authorize someone to get some information about yourself. So say, I allow this game to use my profile picture avatar from this service. That's authorization. That's usually going to be OAuth. That's kind of the player in that game. More, again, on the collision of OpenID and OAuth here.

There's also ADFS, if there's any Microsoft fans in the house, that's Active Directory Federated Services. It's kind of a pretty cool combo of authorization and authentication. It's in the Microsoft world, but it allows the combination of both AD and LDAP and a couple other stores. And it actually, if you a pulse check in the industry. ADFS has some limitations, but overall if it's designed appropriately and to spec, I've heard some really, really good things about ADFS. And again, I'm not here to pick up one specific federated service, but yeah, ADFS is used very highly used in the enterprise world where we have a lot of Windows users and AD users that are

stations or LDAP. All right, so I've kind of hinted at this. So we had this OpenID, and we had this OAuth services for authentication and authorization respectively. So OpenID Connect was kind of the collision of those two services into one world. So basically, it uses a layer on top of OAuth 2. which allows for both the authentication as well as the authorization component of OAuth to be in one service, OpenID Connect framework. There's a lot of, again,

there's specifics as far as how you can configure and make it secureable. It is secureable. But at the end of the day, OpenID Connect is actually the service that if you any of these federated services out there like your LinkedIn, your Facebooks, your Googles, most likely it's backed with OpenID Connect. There's a lot of information out there if you're interested in OpenID Connect and how the plumbing actually works. I highly suggest you dig into it. So there's more. So we talked about OpenID. We talked about OAuth, OAuth 2, ADFS, OpenID Connect. There's these other players in the game. OATH is one that's not to be confused with what is now Yahoo is being called, AOL, Yahoo, Combo. That's not the same thing. OATH is a federated service.

There's SiteMinder. If any of you are in the enterprise world, you may have heard of SiteMinder. It does some of the same stuff here. There's a lot of COTS integrations that you can buy off the shelf that will do some type of federated service. And at the end of the day, I don't recommend you roll your own. There's a lot of players out there. Pick one. learn the intricacies of those, and go to town. So we talked about this idea of federated services and the wins. The wins specifically here reiterated are it reduces the count of usernames or passwords or facilitates the sharing of data. So at the end of the day, if I can go to a throwaway blog

for my hometown newspaper, and I want to make a comment, If I don't have to create an account on their site to make a comment, that's a usability win at the end of the day. It's one less password or username that I have to remember, or maybe they can throw my picture avatar or get my email address from the authorization that I've given them to connect at the back end with another service that I have. So those are wins. We talked about actually sign up for a service. So let's say you are a Pokemon user and you sign up for the Pokemon Go app. And that whole flow of, OK, sign in with your Facebook account, sign in with your LinkedIn account. Do you

grant authorization for Pokemon Go to get this type of data from this third party service? And that process flow, that's a win at the end of the day for the users. The users are used to seeing that. They're used to knowing what to look for. As security practitioners, we're always constantly saying, look for this, don't do that, don't put your passwords in here. Well, these process flows that are very familiar and have a unique flow and look to them, if we can get those adopted more and more, which obviously they are, people start to see that and they kind of know, hey, this thing's asking me to give access to my contact list. I don't want to give this sketchy, calculator,

application, access to my contact list. This seems a little off. I've had friends and family who are not technical at all reach out to me for that exact thing. And I said, at the end of the day, that's a win. Our friends, our family members who don't care about security are asking us why XYZ app is asking for this type of access. That's because the process flow is being more and more ingrained into our computing world, and they're used to looking for it.

just kind of hinted into this, but permissions and revocations are becoming more and more standardized, right? So not only can I see that Sketchy calculator application has access to my contact list or to make phone calls on behalf of me, I can now go in, check back at a later time and see exactly what has access to do these permissions. Who have I given access on my behalf to access this stuff? And I can revoke that access from a centralized site like Facebook or LinkedIn or whatnot. So those are all wins. At the end of the day, it doesn't matter if you are trust no one, if you are basic author or cry from my

dead hands sort of mentality, you're probably in the .0001% of those opportunities in computers. This stuff here are the wins, and that's why federated identities

for non-technical. And when it comes to the enterprise view of this, excuse me, you're also getting some risk mitigation and technical debt controls for certain federated partnerships, right? So if I am all of a sudden partnering with the payroll processor down the street and they need access to my internal employee list, If I can make a federated service partnership with their federated identity provider and only offer them XYZ or I can integrate and not have to stand up a whole new service, then that's obviously a technical debt win because I'm not standing up more and more and more services that maybe are just throw away or aren't needed in how many years. as well as

I can control the risk of the data that I'm giving if I properly implement that federated service. So those, again, are two big risk mitigations. Of course, that's implementation dependent. If you open up your federated service to everybody and anybody, it's not going to probably work out the best for you.

OK, so when we're talking about a lot of different federated services and we're talking about threats and wins and losses and gains at the end of the day it all brings us back to properly threat modeling all right if we can't talk about where our threats reside in the systems and services that we're supporting if we can't articulate that then we're not doing anyone justice by standing up and integrating more and more services and you know we really are just inheriting debt whether that be technical or service debt or So at the end of the day, if federated services is something that you are looking to implement on your blog, it's something that you're looking to implement at your organization or enterprise, it doesn't matter how big

or small you are, it comes back to threat modeling and understanding if I'm trusting XYZ organization as a federated service or I'm trusting XYZ organization to assert people on my behalf or on their behalf, then let's talk about where those threats come from. Let's talk about if I'm giving XYZ organization access to XYZ data, what are the threats involved with that? What systems have to talk to each other? What ports and different things do I have to expose? Am I properly encapsulating that in some type of encryption, et cetera, et cetera? So it all comes back to properly threat modeling. And that's really the first place that if you're doing this on a small scale or a large scale, where you get

everybody together you lay everything out on the table, you wipe more, you break down those silos, and you talk about where the actual risk is when the runner meets the road. Alright, so I've kind of talked about federated services where we have this system that we're relying on to assert different either authentication or authorization type services. And then I've talked about some wins. So now I'm going to get into a little

So when we talk about federated services, there's this kind of plumbing that makes the whole federated service industry work when it comes to the web. And that plumbing is redirects and forwarding. If you've ever used any type of federated services, basically you're being bounced around from different domains to go through this data flow process, which is fine. There may or may not be risk with that as long as everything how you got through the bow. But that handoff process, that is a little bit concerning, especially from an attacker's perspective. So if I start on John's website, and John says, hey, log in with this service, Facebook 2. Click here. So I click there, and now John's site redirects me to Facebook site,

or frames Facebook site. I put in my information there. Then Facebook says, all right, you're good. John's site and then it redirects me back there. All of those redirecting and forwarding comes with a cost and the way that the web works is it has to carry along that data, whatever that may be, whether it's a token or hopefully not a plain text password, but who knows. It has to carry that stuff along with it and depending on how that's configured, if it's configured poorly, it could lead to a pretty dangerous situation in which an attacker can basically utilize that trust, that forwarding process, to their advantage. So some of the parameters, if you actually look at your traffic

or you look at your web browsing history, that you might see that tip you off at this whole redirecting and forwarding thing are things like target equals, blah, blah, blah, continue equals, here's your site, redirect to, redirect URI, et cetera, et cetera. And just a note as far as OWASP, the 2003 version of the top 10, which is still my favorite version of the top 10, sorry, 2013, excuse me, states that are ranked unvalued redirecting forwards as A10. So it was prevalent enough at the time that it was considered in the top 10. It didn't make the 2017 release candidate. I'm not too happy about that. I think it's still important. I think it's something that's concerning. And I'll talk more about why. So this is a real

story. I won't say names or specific organizations that I saw this in, but you can fill in the blanks with your imagination. So I'm a security consultant. I do penetration tests, code reviews, dynamic and static web application type tests. And this organization was using Google's OpenID Connect federated authentication service for a time card app. And within that time card application, they said, hey, this is XYZ company. Log in with your Google account. So they click on the button. You see this picture over here on the left. I think most of us in this room are familiar with that picture over there, right? It's saying, put in your Gmail address, put in your password. And when

you have an organization that is using federated services, of course, it's on your Gmail address. It's your federated service address. So it could be xyzcorp.com. So I'm looking at this and watching the traffic flows. And I see, OK, this sends me over here. Put in my username or my email address. Okay, it redirects me back over here. And I'm looking at the parameters and when you do web application assessments or mobile application assessments, you just kind of dig and dig and look at different parameters and kind of contextually say, okay, I think this is how this process flow goes. This parameter looks interesting. I'll save that for later. As I was doing that, I saw one of the parameters that kind of looked like one of these

up here, right? Like redirect to or had a URL

on a domain of the site of the company that had procured me to do the test. So I was like, OK, that looks interesting. So I'm on Google's site, and there's this parameter that says, when I'm done signing in, send me back to this site. So that's a redirect. Well, what happens if I put kkody.com? Well, all of a sudden, I authenticate. Once I successfully authenticate, that's the big thing here. So it didn't just give me this page and then redirect me to arbitrary website before I authenticated. It waited until the authentication process was through. So it's like, all right. And then I authenticated, put in my username, put in my password. Everything's validated on the

Google side. And all of a sudden, I'm looking at kthod.com. This is interesting. unvalidated redirect for forward. That in itself is not horrible. Google, actually I'll pause on that thought, but it's not horrible. But unfortunately, the way that this site had chosen to integrate with the federated service, they were passing back the token, the authentication token in the URL back to the site. So what I saw was basically URI rewriting back to kkody.com with the authenticated users token in the URI. So what I could do is just set up another redirect back to the original site, whoever I wanted to phish, encode or somehow, you know, obfuscate my kkody.com site on the end of the URL and

send in a phishing campaign that said, hey, Click on this to submit your time card or whatever the app happened to do. They would look at the URL. They'd say, yeah, it looks right to me. This is xyzcorp.com. They click on it. They'd be redirected to Google to sign in. Real Google site, real sign in page. This is fake. This isn't a social engineering toolkit or anything throwing up a fake site. They log in. They even get the two-factor authentication. They get, oh, OK, yep.

is the code let me put in my code in Google authentication goes through everything's great they see maybe a blip probably not even noticeable of a redirect to my site and I redirect them right back to where I originally knew they were coming from and now I have a valid token or ticket from Google for that user session and now I can craft their session this is a real story this isn't something made up or something At the end of the day, it's something in the federated services world in the plumbing these unvalidated forwards and redirects that you have to be cognizant of. The way that these services work is it's not usually something that's integrated locally into your site. You're being bounced around. That's how this federation

works. And during that bounce-around process, information can be leaked. If it's not configured properly, you could run into a situation like that.

mock up a demo. I don't know if I can find, I can, uh, here's what I'll promise. In our lab, I'll take that as a takeaway and I'll at least show you how that redirect works. I don't know if I can mock up something that improperly puts the token in the URL, but I can at least walk you through, like, here's the link to my site or your site, click on it, here's Google site, log in, and here's the redirect back to arbitrary site that is the bad guy's site. So come to the lab in a month and I'll do that for you might be thinking to yourself this is bad this is this is not the way it works this is not

how federated services work this is garbage Google doesn't think so Google says unvalidated redirects as far as their or they call open redirectors that's another term you might see for this but Google says open redirectors as per their bug bounty something that's just necessary evil. They need to be able to arbitrarily send someone somewhere for the plumbing to work. Now Google certainly doesn't advocate for putting your token in the URL and sending that and what have you, but that wasn't Google's fault. That was a misconfiguration on the federated linkage. But I just want to make it known that at the end of the day Google doesn't think open redirectors are as big of a concern. Actually if

OWASP top 10 is any concern? OWASP doesn't think it is either. They're taking it out of their top 10 and replacing it with something else. I still think they're really juicy. I still think they're a really good way to leverage, basically compile different attacks into one nice tidy link. But that's me. We can talk about that more over the Griggs. And there's more instances. So I gave you a very personal story, very specific details about But some of these things may look familiar to you. Tesla was hit with something similar to this in their mobile app at the end of last year. I think it was a Chinese firm. Did some reverse engineering and dug into the Tesla code and

realized in their OAuth handoff, they had a similar type of leakage of the token. And I think the, it's tough to see here, but the actual Android malware used to hack and steal a Tesla car. a little bit of fun I don't know if I would go that far but basically what they were saying is that they could use hooks in the Tesla app on an Android device to basically do what I just told you basically shim the open redirect and instead of using you know basically phishing attacks they would actually hook your Android app on the phone itself and do sort of the same thing and basically send your token elsewhere everything is looking it on your phone, but someone basically has cloned your

car fob, but it's actually on their phone now, and can do all the same commands you can do on your fob or your phone. So that was interesting. There was a big article around the same time, end of last year, that came out, signing into one billion mobile app accounts effortlessly with OAuth 2.0. Again, that's a little bit of hyperbole, I think.

Basically, they did a big scan. This company did a huge scan of all the different apps that they could suck up into their scanning engine. And they figured out that a large portion, not 1 billion, oh, it's 1 billion accounts. So out of all of the apps they found, the whole sum of the user base could possibly be 1 billion. I don't know. You'll have to fact check them. But at the end of the day, they configured OAuth incorrectly. sort of like that story that I told you. And basically, they utilized those flaws in the mobile app in the same way that I did and could bypass different incorrectly configured instances of OAuth 2 for nefarious purposes. Not

all of them were open redirects. There's definitely more than one way to mess up OAuth 2. And that's the biggest complaint about OAuth 2. They kind of opened up the spec from OAuth 1 to OAuth 2. They said, hey, let's make this thing more of a Swiss Army knife. Let's allow people to do more with it. But what it really did was open up more attack surfaces or misconfiguration options. And I'll leave it at that. And then lastly, this is, I think, more recently, PayPal was hit with a similar bug where they were leaking tokens. I think it was something with local host that basically if you able to phish someone or send something, they weren't properly checking leakage for local

host address. So there was somehow that you could basically use local host in combination with same origin policy or JavaScript to basically bypass using a JavaScript hook. You could basically bypass the same origin policy by faking that you were coming from local host. It was something like their testers created this for their own testing purposes, and they pushed it out to fraud. And it wasn't really usable, except for they forgot that same origin of policy didn't apply to local host, and it kind of spun off in there. We can talk about that more and then dig into that again. And then lastly, in this whole redirect craziness, phishing is a big one in the federated

services world. talked earlier about the fact that all of our moms and dads and grandmas and sisters and nieces and nephews they are all familiar with that process flow they all see okay i clicked on this link it's sending me to google to log in that's how it should be i log in and then we're good to go well there is one kind of caveat or downside to that and that's that in that process flow if everything's being aggregated through these services it's a lot easier to kind of take out one site that it's aggregating a sign in and make it look legitimate, make it look real, make it look like you're wanting to be there, than it is to do that across a

ton of different, millions of different websites. So we inherently trust the screen when we see it. And when we are prompted with putting in our credentials, that looks real to me. This is all over the news, so probably a lot of you have already seen this. But basically the trick that this used was it used the data URI lead in and then use a bunch of white space and then use some JavaScript on the end of that to basically fake out. This wasn't a real login page at all. It was all done locally via JavaScript. And basically when you clicked on this phishing link and you plugged it in, it didn't go anywhere. It went to some C2 server somewhere. That was it. All right, so enough with redirects

and and all that stuff. You guys are probably getting bored with that. So we'll get on to some of the actual plumbing of these services. So we have these authentication and authorization services. But that's just what they can do. That's just the overarching protocol of, OK, we are going to provide this service. At the end of the day, they need some plumbing to actually communicate and actually hand off these types of data. And so we're going to talk about some SAML is a big one. Anyone here familiar with SAML? Heard of SAML? Used SAML? Great. So SAML, Security Assertion Markup Language, it's XML based. A lot of people here have seen it before, are familiar with it. It provides, it gives parameters

for identity provider and service provider and the principal user. So this is the data flow of a SAML assertion. So basically, the end user goes to a service provider, a site they want to utilize. And then that site says, OK, great. I'm going to redirect you through the browser, of course, back to the identity provider, in which that identity provider is going to take something from the user and validate as, yes, the credentials are correct, yes, the smart card's correct, what have you. and then send the identity provider, then sends that back through the user. The user is kind of the middle man, the telephone guy, because without any type of out-of-band communication, which some of

the protocols do have for different purposes, a lot of these federated services are all done via the browser, via those redirects. takes in a request, a redirects you to here. You put that in. It's passed back through the browser, back to the original site. Everything is kind of coming through the user. So that's exactly what happens here. The user goes to the original site. They're redirected to an identity provider. The identity provider takes that information and authenticates the user via password or what have you. The identity provider then sends back an assertion saying, yes, this is who they say they are. This is the data that we've agreed upon that you want to get back from me. They send that through the end user back to the

original service provider, the site you originally wanted to go to. That site takes that information and says, great, here's a cookie, here's some token, here's something that says you can now utilize my service. Then from that point forward, the end user uses that token or that cookie or header or whatever. And that's the session value. That's what tells the end service that you are who you say you are. This is the process flow. I stole this picture from somewhere. I have credits at the end, so I'm gonna give that credit out there. This is what a SAML assertion looks like. I'm sure all of you can decipher that. That's awesome. That's a big giant blob of base64

encoded junk that basically what you see here is a post request to the SAML2 gateway for kcody.com. And it's basically saying that the target is kcody.com foo, and the response is this big giant base64 encoded blob. So this is after you decode that giant blob, what's actually in it. I'm sure all of you think that that's even better.

is but that giant block contains a bunch of information in it some of that information includes the version of sample that we've agreed to utilize it includes the format entity it includes the assertion UUID the GUID of the assertion it's got signatures and digests and Not on, not before, not after dates, and all kinds of good stuff. I'll give the slides to John so that he can put it on Meetup or I can give them to you. And you can actually go through field by field and look at all of this quality insertion data. Ironically enough, when I was creating this, this is a side story, I was like, I want a real assertion. I want to take an assertion

that I actually utilize on a day-to-day basis, parse that out, I'll sanitize it so that I can reuse it. And we'll go from there. So I went to some site. I'm not going to rat them out. And I parsed this assertion. And it was for a personal site that I use. And it was handing off my identity, because this is federated service, right? It's handing off my identity from one site to another for, I don't know, accounting purposes. I was on their site. And they're like, hey, if you want to use our accounting service, you need to go to this site. So they handed off my identity. When I decoded the payload, this one

The user identifier was my social security number. I'll end

with that. I wasn't too happy.

It was HTTPS. It's not much better, but it wasn't in the clear. Anyway, so let's talk about SAML. SAML is this cool protocol that is the plumbing of our federated services, right? SAML has utilized a lot for this handover of data and assertion. How can we attack SAML at the protocol level? What can we do to actually kind of not attack the actual federated service itself, but attack the underlying protocol, the plumbing, that's handing this information around? So I had mentioned that there are signatures in SAML.

the most dead simple actually just saw a big security company kind of like one that I work for but a lot bigger come up this blog and it was being passed around on a slack channel like all of this blog we're talking about how to attack sample this is really cool all he was talking about was signature exclusion right just take the stinking signature off and see if the identity provider I'm sorry the consumer of the sample request even if

check, right? If they don't care to check that the signature is valid, they haven't agreed upon assigning a cert and they don't have a process to verify that it's there, try to leave it off. It might work. And if the signature isn't there, then you can start editing some of those parameters in that request to now say, I'm not Kevin Cody, I'm Josh and I have access to his millions of dollars that he has in the bank. And what happened? So that's the easiest one. Keep it simple, stupid, right? Signature exclusion. There's also this kind of interesting attack that I saw at USENIX a few years ago, which was XML signature wrapping. I have the link in the notes for anyone who's interested in really digging down

into it. But basically, based on whether the parser is checking ID signature or they're utilizing XPath, basically, you can wrap the signature around and add a secondary signature. in which depending on how the XML is parsed, basically you can add a pseudo signature in which it throws off the original signature or you can add a secondary signature. And what I'm saying is if you have two signatures, you need one of those signatures to be validated if they're properly validating, but you might be able to use the other signature to then forge the parameters in which you want to take over. So basically, depending on whether the parser is using XPAD or looking at the ID of the signature, you might be able to basically

have your cake and eat it too. Use a valid signature, but also create a signature that isn't valid to forge and get what you want. There's advanced extension attribute of use. So there's these attributes of different extensions in which basically a lot of them aren't normally used by these

SAML and these XML parsers. So depending on the attributes, you can basically utilize those attributes to the parser's disadvantage and basically fake it out again. Those two attacks are specifically in the references that I have at the end. So definitely take a look at that video. It's really cool. At the end of the day, SAML is XML, and there's something parsing XML on the server side. So let's attack the XML parser, right? Those are prone for all kinds of fun attacks, like XML entity injection or what have you. XML is fun. So yeah, just because it's SAML and it's some type of assertion, at the end of the day, it's XML. Something's parsing that XML, so

let's try to attack that. And of course, there's the underlying protocol, like HTTP, that's being ordered.

underneath the actual body of the content. So of course we can attack the underlying service protocols.

Okay, so we talked a lot about SAML, kind of the new, I hate the new hotness, that sounds awful, but the new thing everyone's kind of gravitating to are JSON web tokens. Anyone use JSON web tokens?

I promise they're the thing now. Everyone's using them. All the kids love JSON Web Tokens. Basically, and I'll probably use JSON Web Token, JWT and JWT, J-O-T, interchangeably. JWT is shorthand for JWT, so a JWT is a JSON Web Token.

JWT is an open standard RFC 7519. for creating assertions that have some type of number of claims. They're signed by a server key, and the client is able to verify. You'll be assuming, so you have the identity provider and the service provider. The service provider can verify that the identity provider is legitimate using the key. I don't know about you, but I had that big, giant XML blog in SAML request. This is a real JOP token. That looks a hell of a lot better than SAML. So this is the actual dot. It starts here and ends here. So much smaller, much more compact. It's still Base64 encoded. It's delimited with dots. So you see here, there's one here and there's one here. And when you

decode that, when Base64 decode that, the first portion is the header. It's the algorithm that you use, HS256. There's the type, which is always JWT, I think. I don't know. Maybe someday that will be something else. And then there's the body, so it's saying that I'm logged in as admin. OK, cool. This is a valid act, I think. I'll confirm that. And it's just your epic time in milliseconds. This is, I think, not valid before sort of thing. And that's it. So now that's not asserting as much data that was in that SAML. I'm not saying it's one for one, but it's much more concise and it's in JSON and it's easily consumable by everything under the sun. So that's cool. And the flow is pretty

kind of similar to what we saw. Now I did take the federated portion out of this. You'll have to kind of use your imagination for the federated part, but just simply validating a JOC token for a one-to-one client server type activity here.

The browser posts the user's username and password to the server. The server creates a JOT token with a secret, returns that to the browser. Now the browser utilizes that in an authorization header. So you'll see like in a XOF header or whatever you want to use, and returns that JOT with every subsequent request. And that's it, it's basically like your old off cookie, but it's a JWT header. Seriously, it's everywhere. 90% of the assessments I've done in the past six months have had some type of JWT integration in some port. The very last assessment that I did actually was like everything was JWT. Your session was a JWT, your client record was a JWT, they shoved everything into this and then signed it. So

yeah, it's interesting. So when we talk about the validation of a data VAT token, this is an example of Google's OpenID Connect reference manual that says, hey, if you want to use Google for an OpenID Connect these are the things that your jot must contain the things that your server must be able to validate verified to be successful so you have basically so I should get a little one this is a real world one you have your hash you have a confirmation that the email is verified you have email address your

and service providers you're authenticating to, not valid before, expiration date, et cetera. So if you go to the Google reference guide, which I have linked in the references here, you can actually see they have code for validating each one of these fields to be successful in utilizing JOT as your authorization mechanism. So one interesting thing about JOT, like I said, I just had this assessment. week and my coworker and I were seeing all of these JWT tokens being passed back and forth and taking these and decoding them and looking at the value and seeing if we can mess with them and possibly check to see if they're checking signatures and then resend them. It's kind of getting to be a

pain. So my coworker actually just used anyone in here familiar with Burp Suite? Web Proxy. So Burp Suite has an extension called Python Scripter in which you can utilize Python to make your own scripts. They have extensions in every language that you can think of. But Python script was a cool one, and everyone else Python. So he created this little Python script that basically takes that JWT token and decodes out in basically the fourth header, payload and the signature. And then basically you could expand that. He told me to let you know this isn't the most pretty code out there, since I'm going to use it in my slide. But it works.

So basically you could take this and then wrap it in the extender API for sending it to Intruder or Repeater or some of the other functions that are in the Burp Suite proxy. And now you take that whole base64 decoding, look at the content, modifying the content, re-encoding it and sending it to the server. You're taking that whole process and automating that, which I thought was awesome, so I threw it in there. So we talked about some attacks on SAML. Let's talk about some JWT. There's less because it's not utilizing a format that brings along baggage of its own, like XML. There is an information leakage and disclosure. So if we go back to this slide here where I said, OK,

so the algorithm is using HMAC-256. If you modify that to an algorithm that the server isn't expecting you to agree upon, And then you re-encode that and you send that back. You can usually get some pretty juicy stack traces or error messages, or like, hey, that's not what we agreed upon. This isn't what we were expecting. So there's definitely some information leakage. You can protect that, of course, but since this is a newer type of authorization standard, folks aren't quite there as far as buttoning up all the I's and crossing the T's. There's also this horribly thought out idea of the none or null algorithm in which you can basically, if supported, and most of all of the common

frameworks for JWT don't support this as default by now, but basically you can agree to have a null algorithm and then basically there's no signature verification at the end, so then you can utilize without any type of fallback vulnerability to modify and possibly attack the underlying system with forged JWT tokens.

And then there's also a concern with symmetric keys versus asymmetric keys and the idea that you have to keep that if you're using a symmetric algorithm, you have to keep that key somewhere and is it possibly going to be leaked out depending on what you do, so on and so forth. All right. So I've gone all over the spectrum tonight. I started off with, hey, this is what federated services are. This is what you might use them for. This is authN and authZ. I dove into some actual real-world vulnerabilities and some stories of some things that I've attacked and you probably have seen in the real world. And then I kind of got into the plumbing, attacking SAML, attacking DWT, and what these things are comprised of.

So again, I try to keep a little bit of something out there for everyone, depending on your technical level. But this next portion, I hope, is for everybody. And it's a little bit of a teaser towards the lab So along with federated services, you can still utilize your other types of multi-factor authentication services that we're used to seeing today. So if we harken back to the slide that we saw earlier with Google and using the two-factor auth even if you're using a federated service as long as a federated service provider has some mechanism for second factor auth we're not losing something out by going that route so FIDO is specifically FIDO U2F which is universal second factor can be plugged right in with an

existing federated identity service which is really cool FIDO if you haven't heard about it stands for fast identity online an up-and-coming protocol it's used by a number of different players and basically there are two different flavors of phyla so there's UAF which is the universal authentication framework that is the ability to allow a user to along with something maybe they know or something that they are like a

also utilize a feature trusted platform module basically a silicon can be trusted like a secure enclave in your iPhone to sign a challenge response request that is a PKI type exchange And it will basically utilize this framework of sending a challenge, signing a challenge with the attestation key that's in that Trusted Platform module, returning the response, and using a PKI-type system, you can utilize that for authentication. There's also this universal second factor auth, U2F, which is what we're going to go into more here in a month, which is basically what I just said, but utilizing it for a second factor authentication. So instead of using it as a primary authentication, first signing into your computer or

something using your iPhone for an app, this is purely second factor. And so you may be familiar with this from a commodity product that's out there, which is YubiKey. Anyone used YubiKey before? Many people? OK, great. So YubiKey's, well, they do a lot, especially

before is thinking to do one-time passwords and PKCS11 and all kinds of fun stuff. But a minimum, the blue ones and some other manufacturers make allow you to do this universal second factor authentication.

Basically, the data flow of this universal second factor, how this works is the browser in which the user goes to Okay, give me your username and password. I'll give you your username and password. The server verifies that username and password and generates a challenge code. The challenge code is then sent back to the browser, which is then passed to your device, which is plugged into your USB or uses NFC on your Android phone. And that utilizes the HID protocol, the human interface protocol, like a keyboard. It basically sees the input, uses the trusted attestation cert that's burned into this device, signs that challenge, sends the response back to the browser, the browser then takes that and sends it onto the service provider. So

really cool stuff. There is basically a few concerns with FIDO, since we're talking about attacks, I want to get tipsy to keep going with this. There's the supply chain concern. have to be able to trust that whoever is providing you this did everything they were supposed to do right if you don't trust the people who make this thing they might be tracking you there might be some type of side loaded attestation key there might be everyone might you know who knows so there's obviously supply chain concern you've got to trust you've got to put a lot of faith in the person who's making this as well as there's there's always the chance of side channel attacks with any type of

hardware specifically we're talking about side channel attacks are a concern. The cool thing about the whole supply chain concept is that, and this is something that we were hoping to include in the lab, at least an overview of the hardware next month. There's these things called U2F0, it's a project by the guy's name's Connor. He basically took commodity hardware and source out all the parts necessary to basically make one of these U2F dongles on his own. He had the PCBs printed and all that fun stuff. Basically, that's what it looks like. It's not as fancy as the Yubico keys. It doesn't have the plastic around it or whatnot. It is supposed to be waterproof and drop-proof and all that for what it's worth. But

I'm gonna save all the specifics for next month but the cool thing is you know basically if you are concerned with like hey I want to get to the lowest level of who is making these things what the firmware is running sourcing my own trusted platform module the idea is that there is something out there that you can get that does that like I said a little teaser for next time we'll be at minimum taking you through all the components of this and the flows and actually mapping that out and going through

We've done a ton of talking and it certainly wasn't as open as I had said it was going to be as part of the dialogue, but questions out there on anything? Yep. What's a typical side channel attack? Oh, geez. On these things? Yeah. Yeah, so I was actually reading about it. So on Connor's GitHub project, there's actually someone who was like, hey, what about side channel attacks? And he actually draws it out in his GitHub project as far as some of the things Off the top of my head, I can't remember specifically side channel attack for U2F. But of course, side channel attacks in general are basically abusing a functionality or an environmental thing that you weren't aware of that could be

utilized to basically attack that. And it's specifically relevant in the hardware world, which plays into the little basket here. But I'll definitely look at that if you come out next time. I'll talk about that a little bit. Other questions? Paul Gannon. Yeah. So if I have federated identity built into the same app I made, I'd be completely at the mercy of the identity providers or whoever is actually doing the authentication, I'd be completely at the mercy of their password policies and everything. So even if I allow users to register on my own, their passwords could So that's a great question. So the question is, if you're using a federated identity service, whether that be for authentication or authorization,

are you at the mercy of the identity provider's policies or what have you? And the question is yes and no. So depending on the underlying federated service, there are ways in which you can still utilize a federated authorization service and have your own Basically, you're just pulling in information from a public profile. You're not actually utilizing their specific authentication for your app data. However, if you are using login with Facebook, and that's your be all end all, then yes, you are very reliant on the underlying security and controls of the federated service provider. And if you went to Facebook and said, yeah, I like NIST. I'm going to go with 14.0. character password policy. I'm not really

big on your six character password policy, or whatever the heck they may feel. You're probably not going to get a lot of traction there. So yeah, you're definitely at the mercy of it if that's the direction that you go for authentication, like an OpenID Connect type integration. Any answer your question? Yep. Thank you. Hold on one second. Yep. And the federated identity services

That's a great question. I honestly would have to look into that. I'm not sure. So the question is, I think everyone heard, but can a federated entity service utilize LDAP-3 as a transportation mechanism? And honestly, that's a little bit deep into the weeds. I'm sure I can get an answer for you, but I don't know off the top of my head. Any other questions? So where I see...

I want to make a product that can integrate as much as possible so that everybody can use it. But then you have people that just write these absurd applications and you see some really wonky stuff, kind of like one of the things that the example that you mentioned. And so it seems like they can't tighten down as much what they accept because they have to accept so much. Have you seen anything in the space of good guidelines

So from the application perspective, I'm sure there is definitely guidance and hardening guidelines. It's framework and language specific. But I think, and I'm sorry, everyone heard the question. The question, I'm going to try to summarize this, is basically from an application perspective, Are there hardening guidelines and best practices out there? So if you're utilizing and integrating with federated identity services, you can kind of go at it from a clean start and utilize hardened guidelines. I'm sure there's probably some type of mention in some of the organizing bodies. But I think what probably gets to the crux of your question the most is there's a lot of concern and turmoil underlying protocol like OAuth 2 and how it is so wide

open and how it is prone to abuse and misuse, that even if you did everything the best way you possibly could at the app level, there's still possibly, depending on implementation, some general concerns with the protocol. But specifically, I would have to imagine there are specific guidelines for best practice, white papers for implementing federated services, depending on the framework and language For instance, Google obviously has. If you're going to use OpenID Connect, these are some of the things. They have reference code in just about every language you can make. So from your consulting role, I asked this question. So do you often see organizations that have things like XML gateways, like XML firewalls that actually enforce things like

XML schemas and enforce signing on the applications and mobile apps, whatever?

So I don't want to get product specific, although I think to answer this question, I may have to. But there is a product out there, which I don't have any stake in. But I don't know what the name of it is now. But at one point in time, it was IBM's Data Power Appliance. It does some of that. It makes it a little easier to check signatures as well as schemas and different things. So I definitely have seen that in place. both standing up appliances. There's maybe even a CA product that does similar things, like an API gateway that does similar enforcement checks and whatnot. So I've definitely seen it. Definitely done front models around that. I just am blanking specifically on the

implementation specifics. And I would like to be a consultant. I don't advocate for any specific brand or anything like that. To answer your question specifically, yes. So you do run into them?

And they do work. They work pretty well. The case is anytime you have something that's in between your app and appliance, of course you're at the mercy of the rigmarole of tuning it and making sure that it's not getting in the way and then making sure that it works with your other authorization or authentication internal schemes and all that fun stuff, which I'm sure you're more than aware of. But yes, I see that. I can think of at least two different brands off the top of my head where I've seen that very recently. So you started out by saying why this is all worthwhile. And what I took away from that is that it's a lot easier for people to use. You mentioned user experience, and you mentioned

just managing your passwords is easier and stuff like that. But I didn't hear you say that it is more secure. And then after you talked about that, you went through all of the ways why this is not really secure. So considering that most of the high-profile attacks that we hear about Any of them are because of password reviews. And the social security number example that you did was another one that really exemplifies it. Are you really going to argue that this is more secure? That this is a security number? So

I'm not going to repeat everything. I haven't been consistent with repeating everything. But the crux of the question is, of cherry-picked areas that I wanted to focus on because I wanted to make sure that I gave a little bit of meat to everyone depending on your skill level and familiarity with federated services but something that I think gloss over a bit was true wins for federated services and I focused on the bad stuff at the end of the day I gloss over this slide a little bit but there are definitely wins he talked about process flows and familiarity We talked about password. One thing specifically is reducing the total number of logins. So sort of like the idea of having

a password manager that you have one really good login. If you don't have to remember a million passwords, maybe you can make a stronger one for your original. However, there's obviously a caveat with that where it's not like a password manager. It is one password that's controlling a lot of different services. So you have some give and take with that. But at the end of the day, I think it really comes back to this very last bullet point on this slide, which talks to technical debt controls and process controls and kind of the peering relationship with the service provider, especially at the enterprise level, where you can actually meaningfully reduce risk by peering, if both ends are doing it

appropriately, by only handing over certain data sets Rather than having to create a flat file customer record and FTP it over somewhere else, you can actually really limit the amount of data that's shared and have a really good robust system of data sharing utilizing federation services for employee A wants to sign on to organization B's network. ship over just the information that they need. And you can do it in a way that you can revoke access on either side. So there are definitely wins. And I'm sorry if I didn't get into a lot of those wins, but that's a great follow-up question.

of the big players utilize OpenID Connect, just off the top of my head. I find people feel more comfortable with a certain organization as an identity provider simply because of their security posture. But I think at least if you take the top three, which would be your LinkedIn, which is now backed by Microsoft, your Google, and your Facebook, and Twitter as well is out there.

I think at least like. . Yeah. . So think of them as the clients. . So is there any one of those systems that can reach out to all of these different providers? So the ones that you mentioned, the plumbing is OpenID Connect. So that would be your underlying protocol that you would use, and you could integrate them as far as being able to utilize or, you know, I think you do see, right, you have the option of signing in with a multitude of different providers. So that's definitely something that's out there to let the user pick and choose which identity provider they feel most comfortable with, or maybe they don't have an account on XYZ provider. So again, I

think logistically, the underlying protocol would be OpenID Connect. you do have the ability to integrate with more than one IP to then utilize their source of clients. Does that answer your question? I don't have to develop it. Feel free to tweet me or email me or whatnot. And we can certainly get to the meat of . Any other questions out there? Everyone's lost yet?

I think that's it. So I will put up my slides on the meetup or send them out. I'll be however John wants to take care of that. But I did mention several times that I had sources here. They are there.

These data references. There's some really good material. I can only throw in so much material. And I'm a security consultant, gray hat type guy. I can look things from both sides. Some of this stuff will be good for people who are building. and certainly we'll get down into some of the technical weeds. I did just want to come back to that LDAP 3.0 question as I'm kind of thinking it over my head. At the end of the day, I think that the underlying protocol would be specific for the support of LDAP 3 would be dependent on the protocol in which you want to use. So I think the adoption of LDAP 3 by the big players is probably on the roadmap, but specifically, I'm not sure off

the top of my head, to say, an XYZ provider offers the ability to integrate with LMAP3. That's it. Thanks.