Na het uitpluizen van de code van twee besturingssystemen die op de netwerk- en securityproducten van Juniper draaien, kondigt de leverancier van backbone-apparatuur aan dat het systeem nu gepatcht en veilig is. Maar ondanks dat gaat Juniper een stapje verder en wordt een deel van de code vervangen die is misbruikt door een onbekende partij.
Computerworld selecteert hier interessante artikelen uit het internationale netwerk van onze uitgever IDG.
Juniper revealed last month that it had found two flaws in its ScreenOS operating system and patched them, but now it plans to patch one of them again to make the security of the operating system stronger, according to a Juniper blog.
The problem that will be patched again arose with two random-number generators used in the dual elliptic curve cryptography used by ScreenOS. One is Dual_EC_DRBG, the other is ANSI X.9.31.
Juniper says it will replace both with the random-number generator it uses it its other operating system, Junos. "We intend to make these changes in a subsequent ScreenOS software release, which will be made available in the first half of 2016," says Bob Worrall, Junipers' CIO in the blog.
While he says the current patches fix the problems Juniper knows about, it's swapping out Dual_EC_DRBG and ANSI X.9.31 "to enhance the robustness of the ScreenOS random number generation subsystem."
The problems Juniper announced last month included unauthorized code in the operating system as well as flaws in the implementation of the random-number generators. These issues enabled attackers to decrypt VPN traffic between Netscreen VPN gear and between the VPN gear and client machines. Another let attackers gain administrative access to the machines.
In the blog, Juniper says it has performed a high-level analysis of key components of Junos looking for possible unauthorized code, which was another problem the company disclosed last month about ScreenOS. "After a detailed review, there is no evidence of any other unauthorized code in ScreenOS nor have we found any evidence of unauthorized code in Junos OS," Worrall says in the blog. "The investigation also confirmed that it would be much more difficult to insert the same type of unauthorized code in Junos OS."
The analysis was made with an outside "respected security organization" helping Juniper experts.
Meanwhile, Juniper isn't saying how the unauthorized code got into ScreenOS in the first place. "The investigation of the origin of the unauthorized code continues," the blog says. In an email, a Juniper spokesperson says, "We have nothing further to share past what is included within the blog."
The blog includes a few questions and answers about the situation:
Q: There are reports that the use of Dual_EC in the patched releases prevents the vulnerability from being fixed. Is this true?
No. We remain confident that the patched releases, which use Dual_EC, remediate both the unauthorized administrative access issue, as well as the VPN decryption issue. We strongly recommend that customers upgrade their impacted systems to the patched releases with high priority.
Q: Pending the planned replacement of the Dual_EC, do Screen OS devices have sufficient cryptology?
Yes. We believe that the existing code using Dual_EC with self-generated basis points provides sufficient cryptology notwithstanding issues with the second ANSI X.9.31 random number generator. We will replace both Dual_EC and ANSI X9.31 in ScreenOS 6.3.
Q: Can you please outline the process you used to check the Junos OS at a high level?
The process examined Junos OS source code in "hot spots" where one may expect to find code similar to the code found in ScreenOS. The hot spots include VPN code, encryption code, and authentication code. We also inspected our build environments for any evidence of tampering or unauthorized access.
Q: Why did we feel this was an important step to take?
Given the discovery of unauthorized code in one product, it was important to inspect our products running Junos OS for signs of unauthorized code as well as to carefully inspect the source code itself.