Closing (and bolting) the back door in ScreenOS - RedSeal
RedSeal
  • Platform
    • RedSeal Platform
    • Capabilities
      • Hybrid Environment Modeling
      • Attack Path Analysis
        addyi
      • Risk Prioritization
      • Continuous Compliance
    • Integrations
    • CTEM
  • Services
    • CTEM
    • Professional Services
    • Customer Support
    • RedSeal University
  • Solutions
    • Business Use Cases
      • Breach Impact Reduction
      • Mergers & Acquisitions
      • Cyber Insurance Optimization
    • Industries
    • CTEM
  • Partners
    • RedSeal Partners
    • Partner Portal
  • Company
    • About RedSeal
    • Leadership
    • Careers
  • Resources
    • Blog
    • Events
    • Resource Center
  • Contact Us
  • GET A DEMO
  • Click to open the search input field Click to open the search input field Search
  • Menu Menu

Closing (and bolting) the back door in ScreenOS

2016-01-4
/  byJane Paolucci, CMO

by Dr. Mike Lloyd, CTO RedSeal

The recently disclosed back door in Juniper’s ScreenOS software for NetScreen firewalls is an excellent reminder that in security, the first and foremost need is to do the basics well.  The details of the vulnerability are complex and interesting (who implanted this, how, and what exactly is involved?), but that is not what matters for defenders.  What matters is knowing whether or not you have basic network segmentation in place.  This may sound counterintuitive – how can something as routine as segmentation solve a sophisticated problem like this?  But this is a textbook example of the benefits of defense in layers – if you think too much about only one method of protection, then complex things at that layer have to be dealt with in complex ways, but if you have layers of defense, you can often solve very complex problems at one layer with very simple controls at another.

The vulnerability in this instance involves a burned-in “skeleton key” password – a password capable of giving anyone who can use it potentially catastrophic levels of control of the firewall.  To compromise your defenses when you have this particular version of software installed, an attacker needs only two things – 1) the magic password string itself, which is widely available, and 2) ability to talk to your firewall.  For point 1, the cat (saber-toothed in this instance) is long since out of the bag, but point 2 remains.  If someone can talk to your firewall and present a credential, they can present the magic one, and in they go, with full privilege to do whatever they want (for example, disabling all the protections you bought the firewall for in the first place).  No amount of configuration hardening can prevent this, since the issue is burned in to the OS itself.  But what if the attacker cannot talk to the firewall at all?  Then the magic password does no good – they cannot present a credential if they cannot talk to the firewall in the first place.

So note that someone who relies on strong password policies has a real problem here.  If you think “it’s OK to allow basic access to my firewalls, nobody can get in unless I give them a credential”, well, that’s clearly not true.  Unfortunately, many network defenses are set up in this way.  If you think about this problem at the password or credential layer, the situation is a disaster.  But if you think about multiple layers, something more obvious and more basic emerges – why do you need to allow anyone, coming from anywhere, to talk to you firewalls at all?  You should only ever need to administer your infrastructure from a well-defined command and control location (using “C&C” in the positive sense used by the military), and you can lock down access so that only people in this special zone can say anything AT ALL to your firewalls and the rest of your infrastructure – you can effectively reduce the attack surface for an attack, directly mitigating the huge risk of this kind of vulnerability.  Thinking in layers moves the question from “how do I prevent someone using the magic password?” (Answer: if you have the vulnerable software, you can’t), over to the easier and better question, “How do I limit access to the management plane of the firewall, to only the zone I run management from?”

  • Tags: Mike Lloyd, Network Defense, Thought Leadership

Share this entry

Get the latest news, invites to events, and threat alerts

Platform

  • RedSeal Platform
  • Capabilities
  • Integrations
  • CTEM

Services

  • CTEM
  • Professional Services
  • Customer Support
  • RedSeal University

Solutions

  • Business Use Cases
  • Industries
  • CTEM

Partners

  • RedSeal Partners
  • Partner Portal

Company

  • About RedSeal
  • Leadership
  • Careers

Resources

  • Blog
  • Events
  • Resource Center
CONTACT US
Distinguished Vendor badge 2025

© Copyright by RedSeal, Inc. All Rights Reserved.
  • Link to X
  • Link to LinkedIn
  • Link to Youtube
  • Link to Rss this site
  • Terms of Use
  • Privacy Policy
  • Section 508 Policy
Link to: Using Technology to Drive Diversity in Your Business Link to: Using Technology to Drive Diversity in Your Business Using Technology to Drive Diversity in Your Business Link to: For Enterprise Cyber Security, Think Modern Metropolis, not Fortress Link to: For Enterprise Cyber Security, Think Modern Metropolis, not Fortress For Enterprise Cyber Security, Think Modern Metropolis, not Fortress
Scroll to top Scroll to top Scroll to top

In order to provide you with the best experience possible we might sometimes track information about you. Sometimes this may involve writing a cookie. We use this information for things like experience enrichment, analytics and targeting advertising. We recommend allowing these functions to get the most out of your experience.

OK

Cookie and Privacy Settings



How we use cookies

We may request cookies to be set on your device. We use cookies to let us know when you visit our websites, how you interact with us, to enrich your user experience, and to customize your relationship with our website.

Click on the different category headings to find out more. You can also change some of your preferences. Note that blocking some types of cookies may impact your experience on our websites and the services we are able to offer.

Essential Website Cookies

These cookies are strictly necessary to provide you with services available through our website and to use some of its features.

Because these cookies are strictly necessary to deliver the website, refusing them will have impact how our site functions. You always can block or delete cookies by changing your browser settings and force blocking all cookies on this website. But this will always prompt you to accept/refuse cookies when revisiting our site.

We fully respect if you want to refuse cookies but to avoid asking you again and again kindly allow us to store a cookie for that. You are free to opt out any time or opt in for other cookies to get a better experience. If you refuse cookies we will remove all set cookies in our domain.

We provide you with a list of stored cookies on your computer in our domain so you can check what we stored. Due to security reasons we are not able to show or modify cookies from other domains. You can check these in your browser security settings.

Other external services

We also use different external services like Google Webfonts, Google Maps, and external Video providers. Since these providers may collect personal data like your IP address we allow you to block them here. Please be aware that this might heavily reduce the functionality and appearance of our site. Changes will take effect once you reload the page.

Google Webfont Settings:

Google Map Settings:

Google reCaptcha Settings:

Vimeo and Youtube video embeds:

Accept settingsHide notification only
NEW Gartner® Report, Emerging Tech: The Future of Exposure Management is Preemptive.Download Report.
Footer
Connect on LinkedIn