Bugs Without Borders

2:00 PM -- Last week, an SQL injection vulnerability was made public along with the release of an official patch for Cisco's CallManager, or Unified Communications Manager. For those of you who don't know what an SQL injection attack is, it occurs when user input -- typically on a Web page -- is not properly filtered and gets executed by the back-end database. SQL injection not only has the potential to let attackers access and manipulate data in the database, but it can also lead to running commands on the local database server's operating system. (See the Errata Security Blog: SQL injection is surprisingly easy.)

This particular vulnerability in CallManager resulted from lack of sanitization on one of the variables, specifically the language variable "lang" on the login page, which allowed an attacker to insert her own SQL statements with no authentication whatsoever. Cisco stated that the SQL injection flaw could lead to information disclosure, where one value from the database could be read and "several successful attacks could disclose information about the database, information such as user names and passwords, and information from call records such as the time calls are placed and the numbers dialed."

I discussed the issue with a VOIP engineer who said it was just information disclosure and didn't cause service disruption or affect data integrity, so there was little risk. But thinking about it further, I thought, sure, it may not pose much of a threat to his VOIP systems, but what if you use the same passwords on multiple systems? What about your users? If an attacker can ferret out passwords from the CallManager SQL injection flaw, don't you think that same attacker is smart enough to use that information to attack other systems?

Thankfully, Cisco has released a "patch" for the vulnerability, preventing the information disclosure, but oddly enough, it does not fix the SQL injection flaw itself. Instead, the patch neuters the attack by limiting the amount of input that can be injected into the "lang" variable. A single quote (') -- when included as the value for "lang" both before and after the patch -- results in an SQL server error message being displayed in the logon page. The only difference is that after the patch, the "lang" variable is limited to ten characters -- preventing useful SQL queries from getting injected.

Keep in mind that the impact of a vulnerability in something like this goes beyond the system that is directly affected. Many enterprises have compartmentalized IT departments for functional or geographical reasons, and they sometimes forget that what they do in their small fiefdoms can affect the kingdom as a whole. Vulnerabilities in their systems, such as this SQL injection bug, can easily spread to the entire enterprise.

— John H. Sawyer is a security geek on the IT Security Team at the University of Florida. He enjoys taking long war walks on the beach and riding pwnies. When he's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading