WiKID is a two-factor authentication solution, and the company’s blog is a valuable source of information on authentication, security, major industry news, and other information. You’ll find tips and tutorials, insights about risks, resources, security news about Google and social media, and other relevant information.
Since basically every computer is affected by these bugs, your WiKID server is too. You will need to run 'yum update' to get the latest kernel patches. (And it's a great idea to do this regularly.) Reboot and you should have the fix.
Apple announced that it will no longer support 32-bit libraries or apps. We developed our iPhone WiKID token before there even was a 64-bit encryption library available.
We couldn't just upgrade the iPhone token to 64-bit. It would have invalidated all the existing keys for iOS tokens. Instead, we created a new 64-bit compliant iPhone WiKID token.
With iOS 11, it appears that the iPhone token will launch fine (since most of the app is 64-bit), but you cannot successfully open the token because the encryption library won't open. If you get this error, please have the user remove the app and install the new version.
Deloitte Touche Tohmatsu Limited has 263,000 employees. That's an astounding number of people, computers, networks, access points etc, etc. Very hard to keep attackers out of such a vast network with so many needs and uses. It would cost a lot of money to provide 2FA for all those users. It would take a lot of effort to monitor the SIEM events for all those users.
However, if they are typical of organizations their size, they probably have a ratio of 1:50 IT to employees (maybe that's off big time, but you will get the drift). That means that they have about 5,260 IT staff. Let's call it 5,000 admins - really most IT workers aren't admins, so these numbers are high. That would cost $60,000 per year to add WiKID 2FA to those accounts. Now, think about how much easier the log management, SIEM events, etc etc will be versus 263,000 employees.
I am not saying you can forget about everyone else, but preventing attackers from escalating is cheaper and easier than preventing infiltration.
We won't say that you shouldn't deploy ATA to monitor your network for suspicious behavior, especially if your licensing already is covered. However, it does seem like an example of technology designed to protect something that you'd be better off not having at all: static admin credentials. As we proved in our last post on defeating pass-the-hash with two-factor authentication, tools like mimikatz will fail when using WiKID's native AD protocol for Admins. ATA seems like a great tool, but Nikhil has shown that defense-in-depth is the key as always.
Implementing two-factor authentication for remote access is a great way to keep attackers out of your network. Users' credentials are floating all around the internet. But attackers can still get in your network through malware and other tools. In the past, we described how two-factor authentication can be used at each stage of an attack to make detection easier and execution much harder:
Implementing two-factor authentication for remote access will make intrusion much more difficult.
Implementing two-factor authentication for privileged accounts will make escalation much more difficult.
Implementing two-factor authentication at your outbound proxy will make exfiltration much more difficult.
The PCI Council is now requiring two-factor authentication for non-console administrative access. To see how easy the pass-the-hash attack is and to show how WiKID can mitigate it, we present the tale of two domain administrators. One uses a static password, the other uses the WiKID Native Active Directory 2FA protocol.
In our lab we setup two boxes: a windows domain server using Server 2012 and a PC running windows 10. On the Win 10 box, download two tools: Mimikatz and PStools. We will use mimikatz to grab the hash and psexec to pass it to the AD server to get a console on it.
Note that you will need to turn off Windows Defender as it will remove and quarantine Mimikatz. Right click on the appropriate mimikatz.exe and choose Run as Administrator. You need to be a local admin for the tool to work.
Next, check that you have the appropropiate privileges by running:
Let's have our two domain admins login to the box to do a bit of work. The first domain admin logs in with their static AD password because, really, what's the point? The network is small and the users are pretty smart. Then our much more sophisticated domain admin logs in with a one-time passcode from their WiKID server, which has been setup to provide 2FA for AD logins, because he really likes to sleep well at night and knows that attackers are clever with many motivations. That these two admins on working on the same computer and network in very different ways is just an example of really bad script development.
Note a few things:
The AD protocol supports complex one-time passwords that meet AD complexity requirements.
The password lifetime can be configured in the domain settings too. This setting is key as it is an attack window.
This is the PC client pictured, in real life you would likely use a smart phone software token.
Next, we use this mimikatz command to grab the hashes of these two admins:
This is what we get:
Note the NTLM hashes - that's what we will use.
Now, we will use Mimikatz's pash-the-hash command to escalate our privilege to domain admin. First, we try the admin that used the static password.
We get our DOS prompt with our username once again:
Now, let's see if the hash will work. We run the same command:
psexec.exe \\192.168.56.129 cmd.exe
It fails! Of course it does. The password is changed after the expiration of the "one-time password" and the hash is no longer valid. Note that it's not really a one-time password. The WiKID server writes a random password to AD and sends it to the token as well. Once the password expires, the WiKID server over-writes the password in AD with another random complex string that no one knows. Thus, there is a window where an attacker can still use the hash - the lifetime of the password, which can be configured in the WiKID domain to whatever you want. It also means that you can setup an alert in your SIEM for both unsuccessful pass-the-hash attacks (a la "honey tokens") and multiple successful logins within the password expiration.
The WiKID server is free for up to 5 users. So, even if you don't use two-factor authentication for remote access, a company with 5 or fewer domain admins could use this for free. That's a lot of companies.
I think this tweet lamenting the state of two-factor authentication and online identity will be increasingly common:
I know it's an extreme case, clearly Scott is a techy, he embraces 2FA and he clearly uses a lot of web services. But imagine a non-technical person having to go through that, or just half of that. They simply wouldn't.
WiKID's capability for multiple tokens for a single username really helps out here. Many power users have multiple devices, phones and tablets or a PC token could be placed on an encrypted drive. A lost device might mean re-registering, but with less anxiety.
The benefits of two-factor authentication are clear. But it's also clear that we've got a ways to go.
Now that PCI-DSS 3.2 is live, we have been pondering how hard it will be to implement the new multi-factor authentication requirements. First some definitions from the PCI Glossary:
Non-Console Administrative Access: Refers to logical administrative access to a system component that occurs over a network interface rather than via a direct, physical connection to the system component. Non-console administrative access includes access from within local/internal networks as well as access from external, or remote, networks.
CDE: Acronym for “cardholder data environment.” The people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data.
It appears that not only will you have to use two-factor for your servers, but also your routers and VPNs. Luckily, this is not hard.
First, most enterprise-class routers and VPNs support radius for authentication of administrators. Previously, we have shown how to add two-factor authentication for non-console acces to both Cisco and Checkpoint devices. You really should do this for all of your networking infrastructure to avoid attacks like SYNful.
Linux servers are easy too. Disable root login via SSH and require two-factor authentication for sudo via pam-radius.
Windows servers are harder because Microsoft, after spending all that money winning the battle of directories against Novell, wants you to use Active Directory all the time for everything. Even their radius plugin, NPS, wouldn't allow proxying to third-party authentication servers until Server 2008. At WiKID, we have figured out an elegant way to use one-time passwords for AD users. It doesn't require any software on the Windows side, just an admin capable of changing passwords. Not even a group policy. It does require that you have certificate for SSL connections, so you need to set up AD Certificate Server if you haven't. We do recommend that you have admin users and not just users that are admins.
The best thing about implementing the new PCI requirements is that they should actually be very impactful. As noted in the 2016 Verizon DBIR, 63% of attacks use credentials to infiltrate or escalate their attacks. Preventing pass-the-hash attacks alone will make escalation much harder if not impossible. And it will make detection much easier.
The PCI Council has published another blog post on the upcoming changes for PCI-DSS 3.2 especially how they relate to multi-factor authentication.
The most important point is that the change to the requirement is intended for all administrative access into the cardholder data environment, even from within a company’s own network. This applies to any administrator, whether it be a third party or internal, that has the ability to change systems and other credentials within that network to potentially compromise the security of the environment.
The significant change in PCI DSS 3.2 adds multi-factor authentication as a requirement for any personnel with administrative access into the cardholder data environment, so that a password alone is not enough to verify the user’s identity and grant access to sensitive information, even if they are within a trusted network.
This must be a bit controversial. It's trivial to do this for a linux environment (using pam-radius for sudo), but it traditionally has been much harder to do this on Windows. Until WiKID's new AD 2FA protocol (as far as I know) this meant making an alteration to the GINA, the ctrl-alt-delete mechanism. The GINA had almost no documentation for the longest time, as if Microsoft really didn't want you working there and might change anything arbitrarily. The focus on 'protecting the perimeter' meant no one really cared, but now the Council is saying they do. And they should as every attack requires some form of escalation in privilege. Companies must harden the 'soft-chewy centers' of their M&M-like networks.
I think this also means a change for security pros that mock PCI as a 'floor'. If your environment is not doing two-factor authentication for administrators, then PCI-DSS is looking down on you.