Thursday 8 August 2013

Remotely Exploitable Bug Affects Wide Range of Cisco TelePresence Systems


        There’s a serious vulnerability Cisco’s popular TelePresence system that could give an attacker complete control of the affected system. The vulnerability affects a broad range of TelePresence models, although there are workarounds available.
The vulnerability results from the fact that there are default credentials set up in the TelePresence systems. If a user account is created with the default credentials, an attacker would be able to exploit the bug and gain complete control of the Web server on which the system is running. Cisco has not yet made available patched versions of the TelePresence software.
“The vulnerability is due to a default user account being created at installation time. An attacker could exploit this vulnerability by remotely accessing the web server and using the default account credentials. An exploit could allow the attacker to log in with the default credentials, which gives them full administrative rights to the system,” Cisco said in its advisory.
“Cisco TelePresence System Software includes a password recovery administrator account that is enabled by default. Successful exploitation of this vulnerability could allow a remote attacker to use these default credentials to modify the system configuration and settings and take full control of the affected system. An attacker could use this account to modify the system configuration and settings via an HTTPS session.”
TelePresence is Cisco’s video and audio conferencing system that is designed to mimic the experience of being in the same room with the other participants. Cisco TelePresence System Series 500, 13X0, 1X00, 3X00, and 30X0 running CiscoTelePresence System Software Releases 1.10.1 and prior; and Cisco TelePresence TX 9X00 Series running Cisco TelePresence System Software Releases 6.0.3 and prior are affected by this flaw.
In addition to the patch, there are some workarounds that can mitigate the effects of this vulnerability. Here’s the guidance for products that are registered with Cisco Unified Communications Manager:
1. Proceed to Cisco Unified CM Administration and select Device > Phone, search and select the configured Cisco TelePresence unit.
2. Under the Secure Shell Information (ssh), change the ssh helpdesk user name from the default helpdesk to pwrecovery, and then choose an alternate password.
This will overwrite the pwrecovery account stored on the Cisco TelePresence unit, and permit changing the password from the default to one created by the Cisco Unfied CM administrator.
3. Reboot the Cisco TelePresence codec to download the updated Cisco Unified CM configuration.
Cisco has not said when the patch will be available.

Carna Botnet Analysis Renders Scary Numbers on Vulnerable Devices - 470 million users are affected

internetreport
           The Carna botnet, more formally known as the Internet Census 2012, stirred up a hornet’s nest of controversy when it was unveiled in March to a number of popular security mailing lists. An unidentified researcher had found more than 420,000 embedded devices that were accessible online with default credentials, uploaded a small binary to those devices and used them to conduct an Internet scan of the IPv4 address space.
Questions about the ethics and legality of the project quickly surfaced, as did the realization that there was a massive amount of data waiting to be analyzed, and potentially millions of vulnerable enterprise network devices, industrial control systems and home networking gear that needed patching.

Parth Shukla, a relatively new member of Australia’s AusCERT, was one of the first to pore through the data collected by Carna. He received an uncompressed 910 MB  file from the researcher that held approximately 1.2 million rows of information, and after restructuring the data in order to properly analyze it, he quickly realized that there was immediate need to share his findings publicly.
“Public awareness; it was my duty to get this information out there and make people aware that it’s pretty bad,” Shukla said.
Shukla presented his research last week at an AusCERT event in Australia last week and told Threatpost today that he has begun sharing country- and region-specific data with local CERTs that have made requests.
“I heard about the project about a week after it was published and my first thought was that this was a historic moment because we had captured the state of the Internet at the end of IPv4,” Shukla said. “That was my first reaction, that it was awesome. The information is out there; the bad guys know it and are using it, let’s do something with it.”
Several things immediately stood out as Shukla’s research progressed, most eye-popping was the speed and ease at which one could find vulnerable devices, not to mention the number of ownable machines that are sitting online.  For example, finding a vulnerable device worldwide scanning at a rate of 10 IPs per second would take just under five minutes. Narrowing the scope to China, for example—which had the largest number of IPs in the Carna data—a vulnerable device would pop up every 46 seconds scanning at the same rate of 10 IPs per second. Shukla found on average one vulnerable device for every 456 IP addresses and 1.79 subnets in China. And China may not be the worst offender, he said basing that theory on the fact that other countries have a worse infected-to-allocated-IP ratio.
“Of the 1.2 million devices, more than half are in China (57 percent),” Shukla said, adding that he understands his analysis could make China a target. But with tools such as the Shodan search engine that accomplish the same thing coupled with the realization that most of the devices in the Carna report are likely owned that it was imperative to share the analysis. “That’s an important figure to pitch at people. Fifty seconds and we have a device with a default credential over Telnet; admin/admin and you’re in.”
The creator of Internet Census 2012 developed a binary that was uploaded to the insecure devices found during the scan to look for other devices. The binary included a Telnet scanner that would fire different default login combinations at the devices such as root/root or admin/admin, or would attempt to access devices without a password. The binary also included a manager that would provide the scanner with IP address ranges and then upload them to an IP address.
“We deployed our binary on IP addresses we had gathered from our sample data and started scanning on port 23 (Telnet) on every IPv4 address. Our telnet scanner was also started on every newly found device, so the complete scan took only roughly one night. We stopped the automatic deployment after our binary was started on approximately thirty thousand devices,” the researcher said in his paper. “The completed scan proved our assumption was true. There were in fact several hundred thousand unprotected devices on the Internet making it possible to build a super-fast distributed port scanner.”
Shukla hopes that manufacturers of networking gear who send products to market with default credentials will be among the first to heed his call to change the current state of affairs. While he is sharing his data with other CERTs and ISPs/telcos, he’s finding some pushback because the data does not come with timestamp information restricting the means in which providers that use DHCP, for example, can address the issue.
“I’ve spent days giving people data and pointers on how to use it,” Shukla said, adding that he hopes manufacturers will be among the first to act. “Hopefully CERTs in those countries can go to manufacturers with this data and tell them that, for example, ‘50 percent of the devices in our country are yours, what are you going to do about it?’ ”
Shukla said his next step would be to analyze the traceroutes of the vulnerable devices, as well as some anomalous data such as some of the same IP records appearing in more than one country. He also hopes to deliver continent-specific data.
“I want to put together as much information for most of the CERTs to be able to do something about it,” he said. “There’s still quite a lot of analysis left to be done.”

Updated to correct the size of the uncompressed file received by Parth Shukla to 910 MB. The previous report of 9 TB is the size of the uncompressed public torrent.