Slashdot Mirror


'Unauthorized Code' In Juniper Firewalls Could Decrypt VPN Traffic (arstechnica.com)

m2pc writes: Ars Technica reports that Juniper Networks firewalls have been discovered to include "unauthorized code" inserted into their ScreenOS software. Juniper has has published an advisory addressing the matter, with instructions to patch the affected devices.

From the Ars article: "NetScreen firewalls using ScreenOS 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20 are affected and require immediate patching. Release notes published by Juniper suggest the earliest vulnerable versions date back to at least 2012 and possibly earlier. ... The first flaw allows unauthorized remote administrative access to an affected device over SSH or telnet. Exploits can lead to complete compromise. 'The second issue may allow a knowledgeable attacker who can monitor VPN traffic to decrypt that traffic,' the advisory said." The rogue code was discovered during a recent internal source code review conducted by Juniper.

5 of 112 comments (clear)

  1. Welcome to the club by nehumanuscrede · · Score: 5, Interesting

    says Cisco . . . . .

    I'm not entirely certain why the government is bothering to raise such a fuss about strong crypto. ( Other than to make it look like they have no options ) While no evidence exists that Big Brother is responsible for it, they are the most likely suspects. Not much of a need to break the crypto itself when you can install a bypass of some sort into the mix.

    I wonder how much it costs to coerce a programmer type to insert a few bits of code into your project.

  2. Snowden by Anonymous Coward · · Score: 5, Informative

    This is EXACTLY a vulnerability that Snowden leak suggested. Juniper and ScreenOS by name.

  3. Trust? by Anonymous Coward · · Score: 5, Interesting

    Thanks for disclosing this, Juniper, but why didn't you know about it three years ago? What else is hiding in your products? This is quite different from a software flaw introduced by a mere human. This is indicative of a poorly managed, haphazard approach to managing software development.

    1. Re:Trust? by Anonymous Coward · · Score: 5, Interesting

      Sufficiently advanced malice is in distinguishable from incompetence.

  4. Re:"Unauthorized"? by rickb928 · · Score: 5, Insightful

    Don't overthink this, and don't bother to conflate naivete with malice.

    Despite multiple code reviews, it's probably insanely easy to slip in code that isn't reviewed for functionality or compliance. If they use Git or something similar, compromises there lead to the same thing.

    Demanding a line by line code review doubles the work, but for that level of network hardware is probably essential now. Bad actors will make every effort to inject their backdoors into production code, and I suspect this was an inside job.

    I also would not discount the possibility that this was someone's clever idea of some diagnostics to help them. Doubt they will take credit for this.

    At work I am seeing a change in our development to apply the Agile processes to not only coding and design, but also testing and deployment. This has led to a team relying on unit testing, and failing to do functional testing on the product - with predictably disastrous results. This Juniper problem has heightened my interest in application security, and this will only lead to more testing, longer sprints, and longer development cycles. None of which will get traction with management unless someone takes an interest in the security risk.

    But at work our security team defaults to assuming threats come from both within and without the corporate infrastructure. Rightly so. We see risks of data loss and unauthorized access equally inside and outside, and so we must also monitor all traffic, and they do identify and fingerprint all apps. Our most recent debacle involved an internal app. This data should never be sent outside the corporate network unless via VPN to an authorized device.

    Juniper deserves some credit for finding this, though the time interval for reviewing code will probably need to be shorter. Overall, if I were still in infrastructure management, I would be less than thrilled about a firmware patch - I never trust those.

    --
    deleting the extra space after periods so i can stay relevant, yeah.