 Yr ystafell yn defcon. Gweithio gael, Kerri. Gweithio'r gweithfiliadau'r ffordd yw'r 80 yma yn y Dxrm a'r Srydydd y Llywodraeth, ac mae ydych yn y 4 yma yn ddigwyddol ar y cyflwyno. Mae'r dweud i'r gael yn ffoseg, ac mae'r dweud i'r penderfyniadau pentes i fathog iawn i gael yn dweud yn y tîm, ac mae'n dweud i'r ddweud. Roedd gallwch yn meddwl yn ysbryd, ac mae'r dweud i'r dweud i'r ddwyllion the community, including Botfnet, Sweet Potato and Sharp Block. I will more recently become a member of the Rubius Maintenity. What are we going to cover on this talk today? I'm going to give a very quick introduction to Kerberus. I'm going to go into some active director of specifics on authentication and authorisation. eu cyffin, o'r gwahoneg iawn i'n cyfrifio'r cinnyddol ar unzion dychydigiysteis ar hanferwyr, mae'na bod yna, Sam-le-Ad-Mynn, y Maegwyr Cv. A cyfweld eu ddefnyddio'r cwrs ymddangos, yn ei wisio'r cyfrifio. O broses bwysig, fel ddim yn ddefnyddio ein amser sy'n ei bwysig sy'n ei ddefnyddio e'r llaw o'r cyfrifio a new set of enumeration tools for this spoofing vector. Finally, what can be done to mitigate this new vector? What is Kerberos? It's an authentication protocol used by Windows and Unix Linux-based operating systems. The machines are joined to a common realm to facilitate mutual authentication of principles in the realm. A principle being a user or a computer that's within that realm. They're identified by both a name and a principle type. Kerberos doesn't actually deal with authorization, it only deals with authentication. The authorization is left to the implementer of that particular Kerberos stack. Windows and Unix Linux OS can be joined to the same realm. What does a principle name look like? It's made of your typical name string, so that would be the same account name, so John.do, or it could be a user principle name, which is typically in the form of an email address, or even an LDAP distinguished name is a valid principle name, and of course the service principle names for computer accounts or service accounts. There's also the name type. This name type is a hint to the Kerberos authentication scheme so that the KDC has an idea of what sort of name principle it is. As you can see from the table below at the bottom, there's a number of different principle types there, but the most common for users is the NT principle type. Active Directory actually uses a fairly complex search algorithm for when you're authenticating with the principle. It uses multiple attributes within LDAP to actually find the user that you're looking at. Then, as far as authorisation decisions are made, it's always made from what's called a privileged attribute certificate that's embedded inside the Kerberos ticket, collectively known as the PAC, I guess. Principle name collisions, Karnacur, and this has led to previous vulnerabilities and privilege escalations in the past. I've tried to simplify Active Directory's method of searching for a principle. The default, when you actually log into a Windows machine, it uses the name type of NT principle. Let's say, for this example, we've got to use the name of John Doe. By default, it will go to the right-hand side of that search. Because we're using the NT principle, Active Directory will actually search the SAM account name field first. If a user is not found, it will then actually append a dollar to the end of the name just in case that you're actually authenticating with a computer account, because computer accounts generally have a dollar at the end of the name. Finally, if it still hasn't been able to find a user, it will switch to the left-hand side of that flowchart where it will search the user principle name field instead. Then, if there's no username found at that stage, you get a user not found error. Of course, any time in between those stages, if a user is found, it then will try and authenticate the password. The actual ticket make-up within an Active Directory network, the green area is what you'd say is part of the actual Kerberus RFC. That contains the client name or the C name and the service that the ticket is destined for on a start and end date. Then, the Microsoft-specific sort of come into play, which is the red area of the ticket. You can actually have a ticket with the pack missing altogether. Now, when it comes to Windows-based authorisation, even though the out-of-green ticket is actually valid and it has a client name within Active Directory, you'll actually log on as an anonymous log on if the pack is missing. As far as Windows is concerned, you always need the pack really to validate the user within Active Directory. With that in mind, what actually happened with the Samly Admin group of CVs? Back before the patch for the Samly Admin CVs, you could actually request the TGT without the pack present. What the actual vulnerability was, you would do that, you'd actually request the TGT without the pack being embedded inside it. Now, the ticket is valid for eight hours, so in between that TGT that you've requested, so I'll rewind a little. First, you actually create a machine account using the Mac. That machine account would be named similar to a domain controller. The only difference is the Sam account name field won't have the dollar at the end, so it's exactly the same name, but it doesn't contain the dollar at the end. Then you request your packless TGT, which means that the only thing in the ticket is the C name itself, so there's no pack in there at all. Then you rename the account something else, nothing that exists within AD, but you do have at least a Kerberos ticket now that looks like the domain controller ticket. Now, because you've renamed the account, you then request a service ticket from the KDC, and the KDC will realise that there's no pack embedded inside that ticket. So it will use the same search criteria as I just covered on some of the previous slides, but it'll use the official Kerberos C name that's embedded in the green part of that ticket. Because you've renamed the account in between the point where you've got the TGT, it would have then actually found the real domain controller account and embed the pack for the real domain controller, and that resulted in a privileged escalation. So this is going back to the search algorithm again. This is the area within the Sam the Admin group of CVEs that were affected. So it's the right hand side there where the Sam account name is searched and then it would depend the dollar and so on and so forth. So what did they do to fix the Sam the Admin? Basically, you can't request a packless TGT anymore. Microsoft deemed it that it wasn't a reliable way to identify users within AD unless you had a pack embedded within it. There were some other hardening attempts, so the Sam account name feels also now must end with a dollar whenever an unprivileged user creates it and if you were the hardening of artifacts were made to the user account control settings. But you can actually still request a packless service ticket. So what's the new spoofing vector? So obviously, Sam account name had been looked at previously and it has been hardened quite considerably since that group of CVEs. So I decided to have a look at the user principal name attribute and see what we could do with that. So the user principal name or the UPN is made up of the username element, the app and a domain suffix. So it basically looks like an email address. Now to modify that particular attribute with an active directory, you're looking to have right permission on the public information attribute set or generic write over a computer or user account with an active directory. So these are the sort of the prerequisites needed to abuse it. But duplicated UPNs are not allowed in the same way the duplicate Sam account names are not allowed. So how exactly can we spoof if no duplicates are allowed? Well, as it turns out, you can actually set an invalid user principal name within active directory. It doesn't actually have to have the domain suffix. So for you can see from the screenshot there, we've got the John Do account where the Sam account name is set to John Do but you can actually still update the user principal name to mimic that of another account. So let's say the domain administrator in this case. But there's another difference to the search algorithm then is going back to the name type hint that I talked about earlier. If you specify the name type as NT Enterprise as opposed to principal, which is typically the default one used within Windows, the search algorithm changes and it actually searches the user principal name first before Sam account name. So as I'm sure you can gleamed on that, basically you can get your spoofed account name to be found first prior to the real account to sit in within active directory. So as part of this, I made some updates to Rubyist and they should be live on the current master branch on GitHub. And basically a new argument has been added to specify the principal type. So you can spell from the group that we've seen at the start of the slides, you can actually now specify the principal type that you're using. So as an example there on the left, that's how you would typically authenticate using Rubyist at the moment and by default that would use the NT principal type as opposed to the Enterprise type. So in a typical active directory network, the screen on the left there would actually be tempting to log on as the domain admin and since the domain admin password is not super secret, you get a pre-authentication failure because the password is wrong. But going back to the modified John Doe account that I just showed you earlier, once you add the principal type of Enterprise, the search algorithm changes and then it actually ends up finding your John Doe account. But the ticket that you actually get back contains administrator as the username. So from the outset the ticket actually does look like a domain admin, but it's not. The pack inside that ticket still identifies John Doe. It's only the outer green part of the ticket so that I showed you earlier that make it look like it's a domain admin. So what a boost factor do we have for this? So like I said, Windows is completely out. It purely relies on the pack for authorization. But when it comes to Kerberos authentication on your Linux and Unix machines, which leverages the GSS API, they tend to do things differently. Like I said, the pack is very specific to sort of Windows-based environments. So what tends to happen is the GSS API stack will actually rely on the green parts of the ticket for validating the username. And then the permissions for the user is done as a second stage. So it may do an LDAP search on that name that is extracted from the ticket and more often or not that ends up being the same account name that it's searching on. But of course we've authenticated using the user principle name. But other solutions also include mapping Kerberos principle names to local account names. So, for example, you can create a machine using RootDollar and that will actually log you in as Root on Linux. Andrew Bartlett actually discovered that who was the person that discovered the original Sami Admin group of CVs. And he basically realised that using the Mac permissions and having the ability to create a machine with a low privilege user, you could call the machine RootDollar, pass that ticket to SSH and then you'd be logged in as Root and that issue actually still exists today and it's a no fix. Now the issue with that though, you can't actually impersonate existing AD users because you wouldn't be able to create the machine in the first place because you'd get a collision with a Sami account name if you were trying to impersonate another user. So that's where this new technique comes into play where you can now actually impersonate valid Active Directory users. So these are the services that I've seen so far that implement all the Kerberos authentication via GSS API. So SSH I've confirmed is vulnerable to this as well as postgres database. I just haven't had the time to check all the others yet but essentially if any of these are claiming Kerberos authentication and GSS API support and they don't look at the Windows pack they're all going to be vulnerable to this sort of attack would be my guess. Okay, so on to the demo. So both of these are live already so I made them live just before the talk so Rubyus has the new argument so that you can specify the principle type and I've also created a new set of Python tools to allow you to enumerate potential vulnerable Linux or Unix hosts within an Active Directory network. So it's a little bit small but it works for it. So what I've set up here is again we're going back to the John Doe account and to be able to all the prerequisites to be able to actually abuse this issue is having sort of generic right over an account. Now you'd need to authenticate as that user so shadow credentials has worked for examples you don't necessarily need to do anything brutal like changing the user's password you can't still use shadow credentials with this sort of technique. So what we're going to do now is just change the properties of the user principle name to from what it was to administrator. Okay, and you'll see obviously in Active Directory that the user principle name is now set and ready to spoof but the the SAM account name is left as it is so we're using John Doe. So just going to show that without specifying the principle type you'd essentially be trying to log on to the domain admin which is incorrect in this case so when I authenticate you get a pre-authentication failure but then if we use the new principle type argument and specify enterprise the search algorithm changes and now we're authenticated as John Doe but with the user name of administrator and if you look at K-list you'll see that that has been imported and from the you know just looking at it it does look like an administrator of domain admin but the pack actually says differently. Now the GSS API tool what the way that works is it does a search with inside Active Directory looking at the operating system field of every computer object and any that don't have the word Windows in there it assumes it to be a Linux or basically non-windows based host and then once it compiles that list of machines it'll then try and connect to each one of them over SSH to determine what authentication schemes it supports and then if it does realise that that particular host supports a GSS API it flags that host as potentially vulnerable so you can see in the output here there are two machines found one is Ubuntu and one is CentOS now Ubuntu and I believe all other Debian based Linux operating systems don't have GSS API enabled by default but CentOS, Red Hat Enterprise Server they do so the minute you join a CentOS or Red Hat based Linux server to an Active Directory network you're going to be sort of vulnerable to this sort of attack and then the final stage is now that we've got our ticket imported and ready to use we can use SSH with a minus K argument to indicate that we want to use Kerberos authentication you have to fully qualify the username so you'll see administrator at adgeange.com and here we connect it but the big question is of course what group so we are a member of so by doing a quick ID we can actually see whether we are logged into the Ubuntu or at the CentOS host as the domain admin so I did contact MSRC about this and they basically said the issue I reported is as designed I was sort of questioning who's design they were talking about so I had a quick look at what the RFC says and the RFC says it you know quite clear as far as I'm concerned principle names that differ only in the name type should identify the same principle so they are not listening as far as I can see to what the Kerberos RFC spec says so what sort of mitigations? Well Microsoft themselves could harden the user principle name by ensuring they all have a domain suffix or additionally they could cross check the user principle name against the SAM account name to make sure that there are no collisions there but in the meantime defenders out there what sort of approaches can you take I guess disable anything that's GSS API based authentication that's joined to an active directory realm or the less drastic approach may be monitoring for sort of user principle name updates that don't conform to a valid UPN and then obviously investigate those sort of anomalies so I think I'm running out of time for actual questions so what I will do if anybody does want to ask a question I'll certainly hang around outside if needed I want to give a big shout out actually to Charlie Clark aka X-byte PH he's been sort of a great sounding board for some of the Cobra's shenanigans I'll say that we've discussed on this talk thanks for listening