https://worldofeuc.com logo
Join Slack
Powered by
This message was deleted.
# citrix-netscaler
s
This message was deleted.
m
Hi, since you are talking about n-factor flow I guess you are doing some kind of preauthentication for a Website. So the http.req.url is not really what you are looking for cause this will have the value of the authentication vserver what would be like something /logon/LogonPoint/index.html If netscaler redirects to an authentication vserver it normally places the original path in the NSC_TASS Cookie so this could be the right place where the path the user is acctually trying to access is located. http.req.cookie("NASC_TASS").contains("/abc") the NSC_TASS cookie contains also protocol and hostname so the starts with in your example would not exactly apply. cheers, Marion
m
Hi Marion! Thanks a lot! I will try that tomorrow! 🤩 But is it safe? I mean, could someone on the client side change the cookie to trick netscaler to use a different auth factor than intended ?
m
not really, the cookie can be altered before sent to the netscaler. I would only consider using it if the factor-1 and the factor-2 are strong 2nd factors ... If one of those eg bypasses a Multifactor authentication this is not really a good idea.
m
Hm, k, unfortunately this is exactly what I’m about to do. At least for now I need /abc with only one factor and everything else with the second factor. Then I'll have to find a different approach. But thanks anyways 😊
d
m
Hi Daniel, thanks for your reply! 🙂 As far as I can see, in the forum thread they're also talking about using the NSC_TASS cookie, are'nt they? As Marion pointed out, this is not a good idea as it can compromise security 😐
k
So the MFA is required based on the URL the user tries to access? Is this the destination application or an "universal" one? I usually require the MFA for all users and create a separate AD group for bypassing it (if needed) or then use another factor to bypass the MFA (source IP address, client certificate, etc...). Perhaps I don't understand the use-case here.
m
No actually this is for OWA and EAS – so the same users/groups access both. OWA should have 2FA, EAS only LDAP (at least for a while). Switching EAS to mobile iron is planned but not yet possible. The idea is that if a password gets “lost” the attackers EAS device would end up in quarantine and therefore EAS without 2FA is somewhat OK for at least for a little while. But OWA, EAS and the auth vserver are behind a content switch and use the same public IP So a decision based on http.req.url.startswith would have been nice. Or maybe there is a completely different way I haven't thought of ^^
k
EAS is likely accessed by Android and iOS devices? Could you just make the decision whether to require MFA based on the user-agent in the request? It's not rock-solid but should get you close enough
so if a user accesses the environment with a known-browser, they're required to do MFA, but if they use a supported Outlook client (for instance) on their iOS/droid device, they would bypass this requirement
combining both even
sth like !req.http.url.startswith("/eas..") && !http.req.header("User-Agent").EQ("AndroidOutlookthisismadeup") -> MFA
m
Hm, I think the user-agent is even easier to manipulate than the cookie. Nothing would stop me from changing the user-agent in my browser and access OWA without 2FA, I think? 🤔
k
there's a way to do responder redirects and insert your own custom cookies in the session... I'm planning on writing a blog post about this
ofc if there's a hacker and they want to circle around the MFA requirement, they can do it pretty easily by just setting their client to send a mobile device user-agent... but all of these methods are somewhat exploitable
m
hm... http.req.url would be safe I guess. I mean if I change that I would not get to the site I want to reach, wouldn't I? . But, that doesn't seem to work with auth policies 😐
d
Sorry Michael you are right about the cookie, I mis-read that in haste. I'd thought about trying to do something similar with Referer headers but the Citrix discussion I linked knocks that on the head.
k
Michael, there's just the thing that if the user first authenticates to eas and the switches to owa, they have the authentication cookie and there's a chance the nFactor doesn't kick in
I'd check that at least
j
I’d use content-switching for both URL and send them to different lb. On each lb a separate authentication profile (which name you can check in AAA to make your decision), and provide difference in authentication level to differentiate between LDAP and MFA.
m
Hi Jan, thanks for your reply! 😀 I already have a content switch with two lb vserver behind it. One for OWA and one for EAS. I decide by http.req.url.startswith And I thought about two different auth profiles but then I would have to point them to two different auth vservers with different nfactor flows (or auth pols) But AFAIK I can only put one auth vserver behind one content switch. Or I would have to use a seperate public IP only for the second auth vserver, I guess? Or do you see a way to handle this with two auth profiles but one auth vserver? Cheers Michael
j
You can point both to the same AAA. You’ll have to evaluate the contents of the cookie NSC_TMAP, which will hold the name of the authentication profile applied to the traffic. By using that value in your nFactor flow, you can differentiate traffic
m
Hm, is that also one of the cookies that could be altered on the client side? I mean if someone would change the content of the cookie would he be able to circumvent 2FA for OWA?
j
Technically, with a full MITM attack, yes. But they would have to intercept the traffic at the right time. However, due to changes in the authentication flow, where part of the process is validated against a NetScaler defined ID, NetScaler AAA gerief iets the content of your cookies against what it expects from the data stored for the ID. My guess is it should be pretty safe, as this is how we used to do it in the past already. But as others have mentioned, better to use this method for 1FA endpoints, and default to 2FA for everything not explicitly defined.
m
OK, so one auth vserver, two auth profiles with different names pointing to the same auth vserver. One nfactor flow attached to the auth vserver, a decision block that eveluates something like “http.req.cookie("NSC_TMAP ").contains("name-of-the-auth-profile") ?? 😆
j
Exactly
And make sure to put different authentication level values as well
For example: 10 for 1FA, 20 for 2FA. This will invalidate their cookie should they switch to an endpoint requiring higher authentication levels
m
🤩 Thanks a lot! I will try this out next week or so!
👍 1
Hi Jan! I finally found the time to give it a try and it seems to work 😄 In the end I did not need a decision block. I just duplicated my first factor (user+pw) auth policy, bound them to my first nfactor flow block and configured the expressions for each policy: http.REQ.COOKIE.VALUE("NSC_TMAP").CONTAINS("authprof_eas”) http.REQ.COOKIE.VALUE("NSC_TMAP").CONTAINS("authprof_eas”).not The not-eas one then points to my second factor the eas one doesn’t. First I noticed that I was able to bypass 2FA by authenticating to the /microsoft-server-activesync and then switching to /owa but after setting the auth levels as you suggested that didn’t work anymore :) cheers & thanks a lot! Michael
✅ 1
j
You’re welcome 🙂
k
Useful info here on the NSC_TMAP cookie, thank you @Jan Tytgat ✌️
✅ 1
Open in Slack
PreviousNext
Powered by