Attacking Zero Trust Designs in 2021

hi my name is mike and welcome to my talk on attacking xero trust designs in 2021 i spend a lot of time thinking about zero trust designs i'm really passionate about i am conditional access and secure analytics some fun facts about me is that i'm growing out my hair to donate for cancer wigs i'm into ham radio i have two call signs and i volunteer at the saanich radio program here in victoria i'm into home labbing i like pioneering commuter systems like the deet the deck pdp 11 and pp8 and i have type 1 diabetes i have a automated type 1 diabetic system where my blood glucose is automatically regulated with a pump system and i also have it tied into my home

automation where my lights turn red if my blood glucose goes too low or it goes a different color if it starts going too high if you ever have any questions about that for a family member feel free to reach out to me on linkedin as a summary of the talk today we're going to do a brief introduction into zertrust design we're gonna talk about some of the problems with those design concepts in 2021. we're gonna talk about some andy patterns to watch out for i'm gonna talk about some offensive slash defensive test cases that you know you can bring to your day-to-day work at a high level zero trust design principles are the following as the name implies you're

never trusting you're always continually verifying the context is constantly being evaluated the access is continually being verified you're using least privileged design principles for all your system design aspects you're using strong authentication including attack resistant mfa and conditional access concepts and you're following a data centric security approach oh and all those points are great at a high level i think nobody can argue that we all need those and concept it's uh one of the greatest things to happen to security for those at google and microsoft who have been doing this for the over the last decade they've seen payoff in spades the problem comes down to when you're doing it in your own enterprise when things don't always work

perfect when you're having to integrate a ton of different systems that you're not all in control of when you start getting down to weeds it's actually quite hard and it's not always going to work the same way and it's not always going to be perfect that context is actually quite difficult to continually evaluate and to continually verify you're going to find that not all of your applications are going to be able to do that for you're not always going to be able to put a proxy in front of an application in all scenarios if you're using a sas application least privileged design you're going to find that not all system aspects are going to be able to do that you're not

always going to be able to use attack resistance mfa everywhere and conditional access is still has a couple key system engineering concepts you're gonna have to think about your im system your proxy and your security signals all need to be working closely together as your zero trust subsystems they can't do the job alone there's certain things that only your proxy can defend against that your im system is just forwarding signals onto and your eye system is acting on telemetry that it got from your edr system it can't be understood these systems are complicated and implementations are not perfect in 2021 you really need all three of them working together and you're going to find cases where you

can't use all of them to their full potential there are certain sas applications that can't take advantage of all the attributes your im system could pass on for example if you're it's a trust device or if it's a high risk situation you can't always put your proxy in front of a sas application if it doesn't allow ip allow lists and you might not be able to get all the signals back from that sas application where if it was an on-prem application you may be able to collect a lot more we're going to dive into these a lot deeper but for those who are on the red side or the blue side or on the purple side

you'll see then hopefully you can take something away from the points as we talk through these if this was a perfect world you'd be able to take your security signals like your edr your mobile device management your security analytics signals your mfa type and feed them all to your im system you'd be able to ask questions like was this using strong mfa was this coming from a new location is it from a risky country was these are exhibiting strange behavior were they traveling impossibly was that a bot or not that was just trying to sign in uh was it a managed device a personal device an infected device was it up to date were there any

vulnerabilities on that system that hadn't been remediated then you could build a value to make a decision it'll say if it's uh if it's trust and secure maybe you don't prompt the user for their password that often for untrust devices you really want to think about how to get your guards up so in ideal world you wouldn't allow to have full access to all the sensitive data you'd also maybe collect more telemetry or force an mdm agent to be installed you would use that mdm mdm agent to restrict access only if they're running a up-to-date version of ios or windows 10 or android you would use a strong form of mfa and you would collect more telemetry to see

if the behavior was unusual and if this is an attacker trying to probe from a non-corporate device you can think of how this affected large corporations like twitter where they've had administrative functions accessible from a non-corporate device the attackers used their own personal devices to perform administrative functions within the twitter admin system it was restricted only to admin systems and there was no access allowed for or read-only access allowed only from an untrusted system the damage would have been a lot less severe in the outdoor world you would take the strong stance against a compromised device you would never allow a compromise device to connect in the first place if a user did become compromised

say you started noticing strange behavior because they had just opened a macro enabled word document you would cut those sessions off immediately you would isolate the device you would not allow them to start anymore sessions um all the existing sessions to those sas applications would be cut off and any existing ones would also be invalidated as great as those three use cases were on the ideal world it's very rare you actually are able to implement them fully you're always going to have caveats things aren't going to ever work perfect some sas application prevalence checklist here that you know from experience have come across and it's pretty comical when you map it against what those design principles

were you're very rarely going to find a sas application that lets you pass that device trust status or risk level during authentication very few support that changing device trust or risk level after authentication is even rarer very few applications out there on the market support changing that risk status after the application rather after the authentication has occurred revoking a session via skim or an api is also very rare some might allow you to revoke that user or disable that user via scammer but on the flip side the session might actually still be live so those from the red team or red perspective test this you're gonna find that very few applications actually revoke the session in a timely

manner the user still has a page up they're still able to do something dangerous having a different role based on that trust level is also very rare usually it's all or nothing it's read only or it's full access there are some exceptions but again it's very rare in an enterprise to find all applications able to do this you're going to find only a few you can send that trust level across or it's going to be something vertically integrated like the azure stack or something you've done custom outside of that it's not something that developers are putting a ton of time into another thing that i find surprising in the enterprise world is session lifespan depending on risk

or you know just being able to customize that at all is quite where usually it's again it's all or nothing and in some cases you don't even have the ability to change it at all and finally the last kind of anti-pen you're going to find is that the signals getting those signals out of those sas applications is very rare again you're not often able to get what the user is doing with an application in a timely manner to be able to prevent some data leakage or something bad from happening you're going to have to grab that from the proxy or somewhere else after the fact now i said rare a whole bunch of times on purpose what you're kind of seeing is

these key kind of design aspects you expect to have are all rare rare and when you kind of think back to the design principles of what we're trying to do with zero trust these all go exactly against that it kind of becomes only if you're developing something you're on your own or you're in complete control of it you're not going to be able to fully influence zero trust that's not to say that these zero trust isn't something worth doing it's definitely way better to have this at authentication than nothing at all but this is just help hopefully builds a picture from both the red and blue team that there's a lot of things you have to test

and you're not always going to be able to implement things the way you want now that we've taken the talk for a little bit of a darker turn and we've gone a little bit closer to reality let's start breaking apart these subsystems further attack resistance is a big passion of mine you can't always use webauthn everywhere there's going to be cases where you need to be able to use mfa within an rdp session or a citrix session or a user doesn't have a phone or a user you know has that super cheap amazon phone that doesn't even have the google play store on it i like to think of mfa as a spectrum and it's really something you need to threat

model and become comfortable with we all know the attacks against ss7 and why sms voice call mfa is not really mfa in 2021 we know that totp is easily fished but when implemented with a pre-programmed seed like say a ubicos otp protocol it has an interesting characteristic where you can't fish it at the time of pairing you cannot have an attacker pair their own web authent key or own yubikey in place of a pre-programmed and seated ubq otp key which is something that you really want to think about where these really strong protocols that go off then or to a lesser extent push-based mfa although they're much more fishing resistant they can be fished when it comes time to pairing

so just because the protocol might be in infishable that's a word be wary of the service desk factor where the human element is still fishable and the pairing fact setup of it is still visible you also want to think about how you set up your accounts in a way that when they're ready for pairing or when you have a new user coming on board that they are not in a visible state so for example they have to be set up first with an otp protocol mfa token where that is seated by the organization and can't just be set up by an off-the-shelf web authent key or push mfa app for attackers out there ask to test a brand new account that's

not been prepared for you ask to have that account repaired or put into pairing mode or try to put into pairing mode test all those things because they're very rarely tested and the logic conditions around that are often skipped or not thought about people are just trying to get this thing in get mfa in and you know and cross it off their list and and take advantage of that step up in security they don't think about the engineering or the um threat modeling behind that mfa implementation proxies are another thing that take different approaches the main thing you're going to find if you're a blue teamer or a red teamer is that they're not all created

equally the main differentiating factors you're going to find that either created from a vpn replacement perspective or they're created from a content publishing perspective or web app publishing perspective you're going to find that some have features that the others don't and you're very rarely going to be able to get everything out of one offering some include features that the others don't like web application firewalls or dlp whereas others only include that on their web publishing reverse proxy offering some examples are z-scaler azure auto proxy cloud for access and if you're interested in getting more exposure to these types of products check out either reddit system or reddit homelab because they and their wikis have links

to awesome lists on github that keep them up-to-date repository of free zero trust proxy offerings that maybe have say a 20 user or a 50 user limit one that i've experimented with is cloudflare access in my home lab and also opswat's offering in my home lab from an enterprise side i've used a lot more of the commercial offerings but it's definitely fun to practice what you preach in your home lab versus only using them at the workplace some proxy problems you're likely to run into are the fact that not all enterprise sas applications and prosumer sas applications let you control ipl lists what are allowed to access that application so you're not always going to be able to

enforce a proxy in front of that sas application some proxies have partner support with large sas applications where you can just literally check a box saying yes i use this enterprise proxy service or this casbi or what have you and it will enforce it to always be there but you're not always going to see that as an attacker look out for those types of systems you're able to find them on their support pages if they support ipl list or not and you'll be surprised a lot of them are ones that let you host documents or other material so you can use this as a place to get an initial foothold and then conduct further spearfishing

campaigns after you've got a access to a non-proxy protected sas application that has a really long session time for example i've seen a surprising number of products do this and couple of some of the other anti-patterns we've seen and talked about during this talk you're it's a recipe for a bad situation the ones that stand out the most to me that are dangerous in combination are when you can't put a proxy in front of it you have a long session time that you don't control you can't add factors like device trust or device risk during authentication they don't have an api integration that lets you revoke a session and when you couple those with the fact you can't put a proxy in

front of it to mitigate it you've really reduced the zero trust implementation and zero trust defenses for that system you're really not doing zero trust at that point there are some proxy solutions for being bring your own devices those are often virtual desktops or virtual browsers or browser passthroughs take a look at that if you're if you really need something for bring your own device that's a good layer if you're able to enforce the proxy but again in 2021 it's it's not all one size fits all take it case by case if you're an attacker read the material it's all open what these applications support defenders pay extra close attention to those systems that don't

have those zero trust capabilities you're not going to have this problem for your on-prem apps or apps that you're in control of you're going to be able to take you know do a full trust zero trust implementation but for those sas apps that don't do these things you really need to pay extra attention because those are probably going to become the new attacked entry points into your environment another difficulty with zero trust in 2021 is user sessions sas apps and on-prem apps take different approaches to user sessions and really you have to test all your implementations does attacker really check to see if a user session is actually revoked if you trigger conditional controls skim and apis are great but not all of

them work equal you'll find that some apis do allow you to end user sessions although rare as mentioned earlier but they don't always take effect immediately some apps you'll find you can revoke the user session or disable the user but the existing sessions remain active for a period of time this is why we can talk about the proxies first you really need that proxy and the ability to immediately cut off all network traffic if you want that immediate ideal world zero trust implementation some good tests you can do is see if what happens if you disable account you know using the standard user management interface or skim and have a couple sessions open that have been live for various lengths of

time you'll often find that they actually don't even end until the internal session timer um built into the application ends it um there's like i mentioned before there's often little customizability in those session timelines when using sso which is strange because you'll find that a lot of sas apps give you the ability to set the user session time if you weren't using sso so really you got to test because it's not consistent at least in 2021 if you're developing applications give your end customer the ability to change that user session timeout to work with their iem system give them the ability to revoke sessions via an api make sure those skim capabilities and api cabilities

work immediately that'll do a huge service to the community as they try and adopt zero trust with sas applications something else that needs to be done in the industry is scoping pen tests right in red team engagements to test sas apps as well we've seen a shift that some of the most sensitive data in organization isn't on a file server anymore isn't behind the corporate network it's in some sas app you need to really see and change the kind of tactics that you maybe traditionally used and your definitions of success when you're working in a zero trust environment you're not maybe going to see that same persistence that you maybe did before that account might be locked out or the

mfa phishing attempt you use might only work for a short period of time so you have a limited amount of time to generate an app password or you know gain initial foothold to launch your next spearfishing campaign you also need to watch out for apps that aren't sso um just because you know there's flaws in how zero trust is implemented in 2021 doesn't mean that it's also a flaw that you can't implement zero trust on all applications there still are sas applications and internal applications that don't support sso that maybe are using password vaulting or some other legacy mechanism to you know handle authentication and authorization it's tricky to scope sas applications due to how the clauses of sas apps works

in external pen tests if you're on the blue team make sure you're you're allowed and during the time of acquiring your new sas product that you have the ability to launch a pen test against it and you have the ability to you know do further engage in the future without having to wait in a long period of time or or seek extensive approval from the vendor usually you should be able to just let them know you're going to launch a pen test they might be seeing some scanning activity and they shouldn't really ask much more about it um if you're not allowed to launch a pen test against an external sas product that you purchased

that's a red flag because you're really not being able to test where you're keeping some of your most sensitive data um in today's world definition of actually gaining access to a sas application you're also gonna have to change with your traditional you know getting domain admin of the normal pen test i would say success would be evading compensating control or a conditional access control and being able to access the data for that you know that session the rest of that session timeout um maybe able to upload some malicious documents um generate an app password those are all things you want to look for also on the blue team if you're suspect if you're suspecting somebody

you know did have an account compromise and you know you're thinking oh it's it's all fine they you know they had mfa maybe they got through the mfa but um they didn't get through a second time look for what an attacker could have done within the scope of conditional access because just because they were able to get into it and and then your controls kicked in doesn't mean that damage could have been done um really have your sim and your security systems watching for app passwords being generated because that's where the attacker is trying to bypass your im system and you know bypass those conditional controls this is a good segue into our next section which is talking about

how we monitor for those types of sso bypasses and how we can secure our data against those edge cases of zero trust in the ideal world in xero trust you would magically be able to collect all of your security telemetry into one spot and then take actions universally from that one spot so your soar your uba your sim all will be centralized and you'll all be able to take actions from that one spot in reality that's not often the case in 2021 things still look a little bit more like this or some data is integratable with other systems but it's not always the case some system some data still can remain siloed or it's still going to be advantageous

to implement certain controls within say your proxy and it might not feed that data back to your im system or your im system will be the more central hub for conditional access but we're not quite at the utopian state where everything can talk to everything we're getting there there's some promising developments but understand that you still might be reliant on your edr system to do the fastest way of being i mean the fastest way of cutting off an infected user given what we've talked about how you're not always not always able to put that proxy in front of those sas applications or you're not always able to pass on that heightened risk state to that downstream sas application

eventually we'll get there the industry is working and knows it needs to get here but this is we still are kind of looking at this old approach we still kind of have these disconnected systems i think everybody can think about what in their environment that or as an attacker a system they've attacked that why didn't that alert cause more things to happen or as a defender you can think of like i wish that this red flag would instantly raise red flags and all these other systems we're getting there but really keep an eye out for this and don't be lulled into a sense of security and safety just because you're doing some advanced conditional access in one of your

systems but you're not doing it somewhere else and as attackers again you can read up on when you're doing that recon and you're doing that that's scouting uh you know what sas applications or what on-prem applications a vendor or your customer has you can read the vendor documentation and see just what they're able to implement or what they're able to use from that security telemetry in terms of what it's able to take in or what it's able to export out to other security systems in the environment the last thing i want to talk about today on xero trust that's often overlooked is covering the edge cases you want to make sure you have sufficient logging

and enough testing done from an offensive perspective on your non-sso applications your applications that can create local accounts and your applications that can create app specific passwords those three use cases can bypass a lot of the strength of xero trust and often aren't logged enough or monitored enough you'll be surprised just how few applications today out of the box generate alerts when an app specific password is generated or an api token is generated on behalf of a user that doesn't create any user notification so from a red teaming or offensive perspective you might be able to quickly get in there before conditional controls lock out your access and generate one of those and due to how

logging works for a lot of sas applications in 2021 they might not notice that you maintain persistence from a defensive perspective test test test all those types of use cases i just described make sure that there is some sort of alert and logging from those local accounts or api tokens or app specific passwords are generated because you'd be surprised how few by default generate alerts when those are created or they're generated on behalf of the user and they're not sent back to central logging where you can see um on behalf of your users what activity is going on so in summary for logging test to see what's working today um we're not quite at that utopian state

where we have that central repository and you're going to find that at least in 2021 if you're not completely using a vertically integrated solution there's some systems which are still advantageous to do certain controls in versus doing it centrally in one spot we're getting there there's products out there that are helping solve that problem we're still not there yet in summary we've talked about a lot of the common anti-patterns and i want to leave them to you if there's anything that you've seen or if you've wanted to know more details on feel free to post in discord we can discuss it further you might have some questions on what other one of the hardest parts to

implement correctly we've kind of highlighted how mfa has its challenges the proxy how this challenges the im system has its challenges um telemetry has its challenges but make it relevant to you what are some things you've seen that are difficult or you have more questions on or something maybe we could expand on more detail and finally for those from the the red side of the house maybe you're more curious on what are those more like how can those initial footholds be used more in this sas centric world where um you know some of your customers might not even have on-prem infrastructure or they might not even have active directory so if we want to talk more about how we

could use those deficiencies in those sas systems to maintain that persistence we can expand on that more in the discussion so i really thank everybody for their time today hope somebody got different things with this talk depending if you're a blue team or a red team or a purple teamer something i'm really passionate about and you know excited to share with everybody and uh let's continue the conversation on discord uh we'll open it now to questions thanks

you