Usually I’m not the kind of guy who talks about such economic topics. Because I’m an engineer / security researcher who is exclusively concerned with understanding technical problems and if possible, solving them accordingly. My whole education is based on this and contains predominantly technical aspects of information security. This sometimes makes it difficult to understand what the market cares about (and why some products are being developed / exist on the market 😉 ). Nevertheless, a current engagement for one of our customers made me stumble upon such a product.
We were involved in a test where a security appliance (a black box 😉 ) played the core role. As you might know, the test procedure generally depends on the security question to be answered. In this case the question to be answered was, whether the black box provides the promised information security benefit. More specifically, we took a look at the environment / infrastructure, the protocols and the systems around it and checked if the black box does its magic. So the black box itself wasn’t in direct focus of the test. We were quite amazed about the blind trust the product received (but what else can one do, but trust the device they have already purchased ;-)? You can analyze it and that is what we did.
During our investigation, among other security problems, we met a quite old friend, before Windows NT 4.0 it was our good old friend the LAN Manager (LM) authentication protocol version 1.
Ok, let’s have a look at the packets.
In this scenario the black box tries to connect to a Windows 10 (our new friend 😉 ). Let’s have a look at the negotiated protocol request:
The best dialect that the black box can speak is NT LM 0.12 (this means NTLMv1 or NTLMv2 might be negotiated). Let’s take a look how the Windows 10 responded:
Ok, this looks good. Let’s have a look which version of NTLM is used by looking at the “Session setup andX request NTLMSSP_AUTH” packet:
It seems like they are using NTLMv2. That’s OK. But wait a second – what is that: there is also a LMv1 response. For those who do not know why this is a problem, a short refresher.
LMv1: The LM hash used during the generation of the LMv1 response converts a password longer than 7 characters into 7 character upper-case password chunks. This limits the effective password strength to 7 character chunks. The LM hash itself is then split into three pieces prior to calculating the LMv1 response.
So the black box is negotiating the NTLMv2 authentication protocol, but transmits additionally the LMv1 response. Perhaps for security reasons (sorry, I couldn´t resist 😉 )
Note: The use of well-known broken mathematical, or just simply no longer contemporary, authentication protocols should be avoided in all circumstances ;-).
I understand that you would like to be backwards compatible. However, sending it by default…I don’t know, but I don’t think that’s a good idea.
Often, such ‘security’ black boxes are able to intercept the traffic of every single device in an enterprise, or even worse, an agent of the black box executes code on every device in the enterprise (often with administrative/root privileges). So it seems, that well-defined policies and (security) guidelines, such as network segmentation, device /OS /application hardening etc. are suddenly somehow ‘overruled’.
Is this the right way? I don´t think so.
As already mentioned, we only looked around the black box and not into it (maybe there will be a follow up post 😉 ). We inevitably had to deal with the question “is obscurity a valid security layer”, because this is the security principle behind black boxes. I think, when added to a system which already has decent controls in place however, obscurity can be a strong addition to an overall security posture. But should the security rely on it? I would say NO. Obscurity only can’t be sufficient, because the adversary knows the system.
So how to deal with black boxes?
Research isn’t easy, because chances are good that you will find yourself in court after the research is done/made public. But just trusting the products does not work either. Like the example above and numerous research papers confirm:
- Playing With Fire: Attacking the FireEye MPS
- FireEye Exploitation: Project Zero’s Vulnerability of the Beast
- Analysis and Exploitation of an ESET Vulnerability
I think security researchers can only uncover the technical problems. The solution, in this particular case, can only be carried by the market which is affected. More specifically, if each customer becomes more skeptical in handling the black boxes, it would automatically have a positive affect on this topic.
So, do we really understand the risk vs. benefit trade-offs of these products?
Think on it!
Have a nice (and maybe even sunny) weekend!