Security Appliances, Pandora’s Boxes?

Security AppliancesNo breaking news, nothing fancy in this quick blog post but it is worth to remember that security appliances can be a potential threat when deployed on your network. For years, security appliances are the “in” thing. On the paper, they are sexy: you just plug a power cable, a network cable, 4 screws if you install them in a 19″ rach (under a table isn’t the best place) and you are ready to play with them. At first boot time, some wizards guide you to perform the basic configuration. They require zero administration tasks, vendors have juicy RMA contracts, … What else?

Of course, they are different levels of maturity on the security applicance market. Some of them are very performant and hardened but others are just a repository of old CVE‘s! Why? Back to the roots: When a vendor decides to develop a new appliance, what does it need? Basic components like:

  • an OS (Linux or [Free|Open]BSD)
  • a web server (Apache, Tomcat)
  • a database (MySQL)
  • management tools (SNMP, SSH)
  • remote administration tools (OpenVPN, VNC)

On top of these, we found some kind of interconnection layer where all the components are connected and talk to each other. All the components are packed in a white-label box with enough CPU/memory/storage. A first problem arise: some specific features of an application can be used by the developers and prevent upgrades to a newer release “because this feature has been deprecated and the code must be rewritten“. As an example, the dl() function in PHP has been removed since the version 5.3. Bad news, PHP before this version suffers of many vulnerabilities! Appliances have sexy web interfaces but behind we can have badly written shell/perl scripts which access core components with full privileges.

Engineers working for vendors have usually a virtualized version of their appliance that can be executed on their laptop for demos or labs but those VM’s remain private, it’s very frustrating! Often appliances are delivered as black boxes. Being a hacker, I hate this and I like to understand “what’s under the hood“! A few days ago, I spent some time to create a virtualized version of an old appliance used for network management / monitoring. During the migration, here are some findings:

  • Full development environment available (gcc, gdb & co)
  • OpenVPN keys
  • Database passwords
  • Outdate versions of the OS / software components
  • Access to API’s
  • Plenty of tools not required in such environment
  • Licenses for intergrated commercial products (libraries)

Dear Vendors, keep in mind that once people have physical access to your appliances, consider them as compromized! System admins, take care when you deploy new appliances in your network. Here are some recommendations:

  • Perforrm a penetration test against the appliance or at least a deep port-scan
  • Ask the vendor what’s the upgrade lifecycle
  • How are critical patches released (when?)
  • Put the appliance in a separate VLAN and restrict the network flows as described in the documentation (Don’t accept vendor’s answer like “any to any“)
  • Don’t give full Internet access to the appliance
  • Ask “what’s inside”, be curious!
  • Check for backdoors, API’s or any dormant accounts
  • Inspect network flows to understand the in & out flows
  • Logs! (Do I have to mention this?)

My message is not to get rid of appliances (some of them are strongly hardened) and we need them for multiple tasks. Just keep in mind that they could introduce some new threats on your network. Just be careful!

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.