Cisco Patches Three-Year-Old Telnet Remote Code Execution Bug in Security Appliances

There is a severe remote code execution vulnerability in a number of Cisco’s security appliances, a bug that was first disclosed nearly three years ago.

There is a severe remote code execution vulnerability in a number of Cisco’s security appliances, a bug that was first disclosed nearly three years ago. The vulnerability is in Telnet and there has been a Metasploit module available to exploit it for years.

The FreeBSD Project first disclosed the vulnerability in telnet in December 2011 and it was widely publicized at the time. Recently, Glafkos Charalambous, a security researcher, discovered that the bug was still present in several of Cisco’s security boxes, including the Web Security Appliance, Email Security Appliance and Content Security Management Appliance. The vulnerability is in the AsyncOS software in those appliances and affects all versions of the products.

If the Telnet service is enabled on a vulnerable appliance, a remote attacker can execute arbitrary code.

“A vulnerability in telnet code of Cisco AsyncOS could allow an unauthenticated, remote attacker to to execute arbitrary code on the affected system,” the Cisco advisory says.

“The vulnerability is due to insufficient boundary checks when processing telnet encryption keys.  An unauthenticated, remote attacker could exploit this vulnerability by sending malicious requests to a targeted system.  If successful, the attacker could execute arbitrary code on the system with elevated privileges.”

Cisco has released a patched version of the AsyncOS software to address the vulnerability and also has recommended some workarounds for customers.

“For some versions of Cisco AsyncOS Software for Cisco ESA and Cisco SMA, Telnet is configured on the Management port. Telnet services can be disabled to mitigate this vulnerability. Administrators can disable Telnet by using the administration graphical user interface (GUI) or by using the interfaceconfig command in the command-line interface (CLI). As a security best practice, customers should use Secure Shell (SSH) instead of Telnet,” the advisory says.

Suggested articles


  • Paul on

    If you read the Cisco KB it looks like this WAS fixed years ago in the ESA & SMA. We use both at work, our ESAs have been on 7.6.3 for some time, well over a year, this was fixed in 7.6.1 which was released in early 2012. See the revision history on the article too, it's mostly in 2012, the one update in 2014 is for the WSA it also says that the telnet daemon is running ONLY to allow initial setup, once you've completed the wizard it's disabled, which doesn't seem that unreasonable i.e. it's there with a default IP to allow you to give it a real IP in the wizard, after which point it's disabled long before you use it for anything of note.
    • Peter on

      When you install WSA you can configure everything without running the Wizard. As long as you never run the Wizard and configure everything manually the Telnet daemon stays active. I had already test that in my company lab and telnet remains active.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.