Forum Discussion
Andy_Herrman_22
Nimbostratus
NimbostratusXTrustProvider security hole
This is specific to the XTrustProvider class used in Java, though it could apply to other languages as well (I just don't know how trust is implemented in those languages).
Up till this point I've just been using the XTrustProvider class provided in the SDK as it was the only way I knew of to get the connections to work. I never really figured out what it was doing, so I started poking around at it. I think I have an OK understanding of what it's doing now, and I'm a bit worried that it's a security hole.
From what I can tell the XTrustProvider class simply bypasses all the certificate checks, essentially giving trust to everything. This seems pretty dangerous, as it's basically nullifying one of the purposes of the certificates. Man-in-the-middle attacks would be fairly easy to do in this case, as there is no actual validation of the certificate. Such an attack could use a self-signed certificate of its own and proxy the iControl requests, which would both give it the ability to monitor whatever's being done through iControl, and, more worryingly, could get the username and password used to authenticate. After that they would have full access to iControl and could wreak havoc.
The chances of such an attack are probably minimal as long as the management interface isn't publicly accessible. However, even when contained within a private network the idea of giving global trust is worrisome. Unrelated breaches in the network could potentially be used to compromise the BIG-IP system simply because those systems utilizing iControl are too trusting.
There are a couple options which I think would be significantly better security-wise than using the simple XTrustProvider class from the SDK.
The first, and probably best solution, would be to install the server's certificate in the local keystore. When installing the certificate you have full control over the cert, so you can verify that it's correct before installing it. Any time a different certificate is seen the connection would fail. The only real problem with this solution is that you have to manually install the certificate everywhere iControl will be running. If you're creating some kind of user application for server management this could be annoying for the users, (and also annoying when the cert expires and you have to create a new one and push it out) but it would be much safer.
The other option would be to have a much more sophisticated implementation of the trust provider. The first time you connect it would add the certificate it gets into the keystore (probably using logic similar to that found in the installCert application found in the SDK). If a certificate already exists in the keystore then that one is used. At a later time if a different certificate is seen it is rejected. As long as you know everything is correct the first time you run the application then this will work simply as an automated version of the first option. If you're writing a user application you could even show a prompt when the certificate has changed instead of just rejecting it, and allow the user to pick whether or not they want to allow it (with the option to save the new cert to the keystore for future use).
I believe either of these options would be significantly more secure than using the provided XTrustProvider class. Can anyone think of other solutions that would be more secure (and possibly easier for administrators or users to deal with)? Anyone see any problems with the solutions I provided? Am I completely misunderstanding XTrustProvider?
Andy_Herrman_22You're right that even when using the XTrustProvider class the likelihood of a breach is pretty slim. Someone would have to have a pretty specific idea of what they're attacking and would need to compromise the network before being able to attack, which would hopefully be difficult itself (again, assuming the management interface isn't made public, though generally that's a safe assumption).
However, there are vectors of attack that wouldn't require the attacker to gain control of part of the network. If they were able to get a payload onto the machine of whoever is running the iControl stuff then they could attack that way. Consider the (pretty useful) application Fiddler (http://fiddlertool.com/fiddler/). It's an application that you can run on the client which shows a log of all HTTP/HTTPS traffic. The newest version is even able to decrypt the SSL traffic, and I believe it's doing a form of man-in-the-middle "attack". Fiddler itself is just a debugging tool and isn't malicious, though something similar could probably be created and used as a payload in some kind of virus attack (which, unfortunately, do make it into corporate networks every once in a while). Granted, if you're able to drop a payload on someone's machine there are probably worse things that could be done (keyloggers, etc), but it is a possible attack vector.
Both of these situations are incredibly unlikely, to the point that 99.9...% of the time you can probably ignore them. However, as BIG-IP solutions become more widespread and as iControl is utilized in more situations, the miniscule chance of an attack grows (as does the chance of someone putting the management interface on a public network, purposefully or otherwise). I think it would be best to remove vulnerabilities before the chance of it being exploited becomes too high.
It's also possible that there are other types of attacks that could exploit this vulnerability that I/we can't think of. The way I see it, just because I can't think of a more feasible way to exploit this doesn't mean someone else couldn't. As such, I'd rather plug the hole and remove the possibility of some clever attacker finding a way to exploit it.
I agree the best solution would be to purchase real certs. With fully valid certs I don't think you'd have to add the cert to the store either, as I would expect most packages to already have some trust stuff implemented to be able to handle certs from globally trusted sources. If security is of highest priority then this is probably the solution that should be used.
As for the solution we both suggested (number 2 in your list), it wouldn't necessarily prevent an attack but it would reduce the possibility and help to detect one. True, if the system is already compromised when you run the first time you will get the compromised cert. This solution won't protect against that scenario. However, it will protect against someone compromising the system at a later date. The chances of a compromise increases over time, and this solution is a way to mitigate that. As long as things are fine at the very beginning when you install the cert you can then use that valid cert to detect/prevent compromise in the future.
In the end this discussion may simply be academic but I do believe it's an important one to have. Especially if BIG-IP/iControl will be used in environments where security is of utmost importance (like government networks, etc).