Mittwoch, 30. Oktober 2019
10:00
In the past couple of days we took a detailed look at how windows hello for business works. We wanted to see how it can be implemented in a domain infrastructure, it’s usability, but most importantly, if it is the hot new security feature you should have implemented already yesterday.
From a pentester perspective, this whole adventure could be summarized with the words „a hash is a hash….“ but hold your horses, there is more to that. Let’s start from the beginning:
# infrastructure Setup
WH4B comes in four flavours, you can either go hybrid or stay on-premise, and there is the technical decision to either utilise an existing certificate authority infrastructure or go without. We opted for variant 4: on-premise with certificates, which also allows to initiate RDP connections with WH4B – and that seemed like a nice feature. Also the decision was made to do face recognition instead of fingerprint.
The documentation https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-deployment-guide is a little sharp around the edges, and i made some suggestions for improvement in the comment sections. But with a little dedication and a couple of sleepless nights it was possible to get the infrastructure up and running, which in our case consists of:
- server 2016 domain controller
- 2-tier PKI, with modified kerberos templates for the DC and two new templates for WH4B
- federation services server, freshly set up from scratch
- A windows 10 1903 laptop with an infrared camera
This is for a small 4-5 guy office. If WH4B is to be implemented in a real enterprise, a minimum of 2 federation servers plus loadbalancer, as well as two proxies should be installed. Just keep that in mind.
# the road to passwordless is quite bumpy
The first major issue i ran into was that the device you want use for WH4B has to be registered with the device enrollment service on the AD FS server. It took me a while to figure out that the DSREGCMD.exe which handles the registration (and also can be used for debugging tasks) can be called by a normal user account, but will produce wrong results because it has to be execute in a SYSTEM context (yes, we’re talking about psexec -i -s cmd.exe here). Additionally, the documentation was lacking an instruction for device auto enrollment GPO settings.
Anywho, the takeway here is: before you even try to register your face for WH4B, the device needs to be enrolled and this entire process has to work automatically in the background without user intervention.
The second issue that crept up was that once the device is enrolled, and the user is prompted to enroll for WH4B the system asks for a „second factor“ to verify that the person smiling into the laptop camera is actually me. Since this was a demo setup, and we didn’t want to implement an additional real MFA provider i chose to utilise the „certificate“ option to verify that „me is me“. What i didn’t get right at this time was that i needed an actual, already existing certificate for this step, in my user certificates store. I thought that WH4B would create this for me in the enrollment process, because there is a similarly named certificate template that you have to create during the PKI setup phase.
After understanding the semantics it worked fine. The takeway is that you need some kind of MFA to register for WH4B and if you chose „certificate“, it has to be an already existing one.
Finally, and this is the one that kept me awake a full night (because … who needs to sleep when there is an error message to depuzzle?!), was an actual error message in the last step of the enrollment process: once you made your fake smile to the camera and it would register your biometrics data, a new screen pops up asking for an emergency pin. This has to be defined by the user so if, for example, i had an accident and the camera would no longer recognize me, i could still use the pin to login. Or maybe i was out for a night with the boys, and drank too much, and couldn’t look straight…. Well, you get the idea.
For some reason, registering the PIN created an error message and the process had to be reset and started from the beginning.
I made it work eventually with a powershell command (Set-ADFSProperties -IgnoreTokenBinding:$true). Please don’t ask what this does. It just made the magic happen and let me register my backup pin. (clarification with MS pending…)
# Usability
In summary, it is working as advertised and is highly convenient. After the rather painful setup process, everything was working well. I smile into the camera and the system logs me in. Done. This is both fast and convenient, and so far i was not able to fake it (e.g. different person looking into the cam, printed photos, etc…). I had one unintended login, where i was too close to the cam but looked somewhere else entirely, and the system would still log me in. I did not yet have a failed login.
RDP is also interesting, because if i chose to terminal server the hell out of my infrastructure, a straight look into the cam instead of typing my highly complex 14-character-password is quite a timesaver. In reality we do have a 3-tier-segmentation in place so i’m actually not really able to RDP around a lot with my normal user account. But more on that in a second.
# BUT, IS IT SECURE?
The most interesting question obviously. And i don’t mean „is WH4B itself secure“. It boasts to be the highest level of security with all kinds of buzzwords like „asymetric tpm backed key encryption voodoo“. This is all fine, and i trust the technology. The biometric data doesn’t leave and is bound to your device.
What we were really wondering before doing this implementation: is there anything different in the domain environment, especially in terms of lateral movement? Are there still NTLM hashes and kerberos tickets, and can they be stolen and re-used? After all, just because you implement WH4B, the rest of your infrastructure doesn’t change: you still have your legacy, NTLM dependent software, the product that doesn’t support SSO, or the server where you intentionally turn it off on purpose, and the login that doesn’t know about kerberos but asks for your password in a web browser popup.
Does WH4B magically do away with all that, and allow face logon through the cam in a new, highly secure way?
Of course not. The painful reality is that NOTHING in your domain has changed. We mimikatzed the hell out of my account and laterally moved like there was no tomorrow.
# MISTAKEN IDEA OR the way to go?
On stackexchange i posted a question to verify this situation, and „kind of“ got it confirmed by a guy from the WH4B team. He argues a bit differently, and i would like to explain his viewpoint here:
If you want to implement WH4B in the most secure way, then you need to make sure the user doesn’t even know the account password any longer. He/she will login with biometrics, and all the systems in the enterprise have to support SSO, so there will never ever be a popup window asking for credentials. And when the bad guy comes along sending a phish mail, the user will not be able to lose his/her credentials to the attacker, because he/she just doesn’t know the password.
Pass-the-hash and pass-the-ticket are still possible, but should anyway already be mitigated with other technologies (like credential guard). This is not WH4B‘ responsibility.
In reality, i can see how this might work for your average employee. But it will definitely not work in IT. If you take your IT seriously, you will have 3-tier-admin-segmentation in place, like i mentioned above. This alone makes it impossible to utilize WH4B – how should the computer decide if i want to login my server admin account or my normal user acccount, just by looking into the cam? Do i raise the left eyebrow for „server admin“ and the right one for „domain admin“ ? just kidding.
This is what microsoft more or less describes in their „passwordless strategy“ document: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/passwordless-strategy
So: WH4B should be understood as both a technology, and a concept requiring a multitude of changes in an enterprise. The final result is „not knowing a password means it cannot be stolen„. If the attacker is already in the system, then „a hash is a hash„, and nothing has changed.
Happy face unlocking!