Network World recently published an article entitled Cisco says FTP feature in IOS is a hacker backdoor. The opening paragraph reads as follows:

Cisco says a flaw in the FTP server utility in its IOS router/switch software could be used as a backdoor by attackers.

Do you see the discrepancy? The opening statement is inconsistent with the title of the article. Are they saying that the flaw could be used as a backdoor, or that the flaw itself is a backdoor?

Any vulnerability that is remote, pre-authentication, and trivial to exploit could be used as a backdoor of sorts, once details emerge and somebody publishes an exploit script that the kiddies can use. This would clearly be a big story, considering the sheer number of Cisco routers that will require patching. However, if the flaw itself is a backdoor, that implies that the vulnerability was introduced maliciously, either by an insider or by someone who broke into Cisco's network and modified the IOS codebase. This would be a HUGE story, because now you have to wonder about the extent to which the IOS codebase has been compromised.

First let's break down the Cisco advisory. Like most vendor advisories, you don't get many technical details. However, here is what we do know:

    • A remote attacker can bypass the IOS FTP server authentication mechanism
    • Having bypassed authentication, the attacker can read or write any file on the router's filesystem, including the startup-config file
    • The vulnerability gets the maximum possible CVSS rating of 10.0 because it is remote, pre-authentication, and trivially exploitable, with full confidentiality, integrity, and availability impact


But wait, what's this? There's also a Denial of Service vulnerability? Apparently, you can make IOS reload through the FTP interface, and repeatedly triggering this reload (think reboot) could effectively create an outage. The important part is that there's a way to force a reload.

The advisory also says that a remote attacker could "cause the affected device to reload, or execute arbitrary code" but I'm not so sure about the arbitrary code part. Maybe they just mean arbitrary IOS commands.

Basically, an attacker could take control of the router a couple different ways. Network security guys, correct me if I am off base here or omitting any good attack vectors:

    • Fast but clumsy: Retrieve the startup-config, alter the commands used to set the line password and enable password, upload the modified startup-config, force a reload, and login using the new passwords
    • Slower but less obvious: Retrieve the startup-config, crack the passwords (difficulty dependent on whether they are configured as "passwords" or "secrets"), and login using the cracked passwords


Again, the vulnerability is undoubtedly a big deal, in and of itself. But what I really want to know is whether this was an intentional backdoor planted in the codebase or just a horribly dumb implementation error. The ability to not only bypass authentication but also force a reload seems a little suspicious, but we won't know for sure unless Cisco discloses more information. More importantly, if it does turn out to be a bonafide backdoor, what does this say about Cisco's SDLC?

About Chris Eng

Chris Eng, vice president of research, is responsible for integrating security expertise into Veracode’s technology. In addition to helping define and prioritize the security feature set of the Veracode service, he consults frequently with customers to discuss and advance their application security initiatives. With over 15 years of experience in application security, Chris brings a wealth of practical expertise to Veracode.

Comments (3)

dre | May 14, 2007 11:37 am

highly unlikely that this was planted by an insider. I have no idea about the details, only passingly heard about the vuln before you posted.

cvss is borken, and I mean BORKEN. this doesn't even apply to people who do not have ftp configured... and it's not a default. most people I know use scp, or possibly tftp over ipsec. sure, many enterprises still do unencrypted tftp - yet somehow this ftp vuln is worse than cleartext defaults that everyone has been doing for years.

as for remote code execution - yes, that means IOS, but if you've read Hacking Exposed Cisco Networks, you'll know that it's possible to run an IRC server or whatever you can dream up under IOS.

as for the denial-of-service, I am truly disappointed to hear veracode "lack of clue"... I mean, if remote code execution is possible then of course service could be taken down and resources could be used in any manner the attacker desires.

CEng | May 14, 2007 1:34 pm


Regarding your comment on our "lack of clue", the way Cisco described the DoS attack scenario is not dependent on the ability to execute arbitrary commands/code.

Of course you can take down service if you have arbitrary command execution. I think you're missing the point. What they describe is an alternative method of disrupting service, namely "Repeated exploitation of the vulnerabilities could lead to an extended Denial of Service (DoS)." You have to ask, why would one need to repeatedly exploit the vulnerability in order to disrupt service? The answer, I presume, is that during the IOS reload, the service is unavailable. So if you repeatedly and indefinitely force IOS to reload, you're causing a DoS without ever actually executing arbitrary code.

dre | May 14, 2007 3:21 pm

ok. sorry. I blame cisco for their thickly veiled advisories. cisco circa 2007 advisories look like cert advisories in 1997. where's the info?

notice how their external customer-facing bug-tracking system usually removes all information, if visable/viewable at all. we should consider ourselves lucky that cisco even talks about what protocol this affects.

cisco sdlc surely needs work, but i'd rather that they "make nicer" with vulnerability reporting and information. cvss is a marketing checkbox for cisco, oracle, etc. what operators need is real information, and one normally only gets that in passing via the nanog, cisco-nsp, or nsp-sec mailing-lists. or through rigorous personal verification, which either involves reverse engineering against the IOS EULA or purchasing from ebay/graymarket.

cisco really works from the grotesquely outdated mainframe cathedral model of computing: load new code; reload; pray.

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.