Software Supply Chain Vulnerabilities
powers-do-not-use! 270000NC1K Visits (999)
Symantec got hacked, possibly by a member of the hacker group Anonymous. Every IT News outlet on the planet is reporting on it. My favorite write up is "Symantec Tells Customers to Pull the Plug on pcAnywhere Following Code Theft" in Tech News World. That story does the best job describing the implications for businesses. But if you are interested in the nature of the vulnerability that the hack exposed it's best to go to this white paper published by Symantec. This seems to be the heart of the description of the vulnerability:
"pcAnywhere is a product that allows for direct PC to PC communication and this does expose some risk if the compromised code is actually released. As a result Symantec determined that the encoding and encryption elements within pcAnywhere are vulnerable. Therefore it is possible that successful man-in-the-middle attacks may occur depending on the configuration and use of the product. If a man-in-the-middle attack should occur, the malicious user could steal session data or credentials.
There are also secondary risks associated with this situation. If the malicious user obtains the cryptographic key they have the capability to launch unauthorized remote control sessions. This in turn allows them access to systems and sensitive data. If the cryptographic key itself is using Active Directory credentials, it is also possible for them to perpetrate other malicious activities on the network.
In an internal pcAnywhere environment, if a network sniffer was in place on a customer’s internal network and the attacker had access to the encryption details, the pcAnywhere traffic could be intercepted and decoded. This implies that a customer either has a malicious insider who planted the network sniffer or has an unknown Botnet operating in their environment. As always, security best practices are encouraged to mitigate this risk."
I've never used pcAnywhere, but I'm sure that as part of deployment you have to set up some sort of password at the machine being remotely controlled. Based on the description above, it sounds like someone who could sniff the network traffic could determine what that password is. This password could then be used to make unauthorized connections to the machine at a later time and perform all kinds of mischief. I have no knowledge of the this other than what's been reported in the press. But I'm guessing that the stolen source code would make it easier to pull that password out of the session traffic between the remote machine and the client software.
Embarrassing. I'm just speculating, but based on the above description, it sounds like the protocol between the pcAnywhere host and client components did not use a secure key exchange protocol like Diffie-Hellman to establish the session key used between the two endpoints. That's the core vulnerability here.
Or is it?
It's easy to piously point fingers and say how irresponsible it was not to use a secure key exchange protocol in this case. But I dunno. I can imagine the engineers making a trade-off decision that went something like "the amount of time it would take the attacker to reverse engineer the protocol between the endpoints in order to figure out where the key is located would take so long that it wouldn't be worth the effort."
After the hack, that line of reasoning is of course obviously flawed. But I can imagine the rationale for it.
In any case, I think a compelling argument can be made that the core vulnerability in this scenario is not in the object code of the product. The core vulnerability is the lack of security on the source code. Yes, the poorly designed key exchange is also a vulnerability. But it's the stolen source code that has made the exploit feasible.
I think we'll see more and more of these types of vulnerabilities being exploited in the future. Attackers will learn to take advantage of vulnerabilities in the process of building, distributing, and deploying software in addition to vulnerabilities in the software itself. Think of them as "software supply chain vulnerabilities," and that's the focus of IBM's Secure Engineering Framework.