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

           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.

78 government websites under hacking attacks till June - CERT IN

   
      A total of 78 government websites were hacked and 16,035 incidents related to spam, malware infection and system break-in were reported this year so far, Minister of State for Communications & IT Milind Deora said. "As per the information reported to and tracked by Indian Computer Response Team (CERT-In), a total number of 308, 371 and 78 government websites were hacked during the years 2011, 2012 and 2013 (up to June) respectively," Deora said in a written reply to the Lok Sabha. The Minister said 16,035 security incidents related to scanning, spam, malware infection, denial of service and system break-in including that of government, Defence and public sector undertakings were reported up to June this year. The number of security breach incidents stood at 13,301 in 2011 and 22,060 in 2012, he added.
"It has been observed that attackers are compromising computer systems located in different parts of the world and use masquerading techniques and hidden servers to hide the identity of actual system from which the attacks are being launched. It is difficult to attribute the origin of cyber attacks," he added. In order to detect and prevent cyber attacks, the government has taken various measures including release of a National Cyber Security Policy 2013, which addresses protection of information and infrastructure in cyber space and building capabilities to prevent cyber threats.
"All new government websites and applications are to be audited with respect to cyber security prior to their hosting," Deora said. It has also been mandated that all government websites to be hosted on infrastructure of NIC, ERNET or any other secure infrastructure service provider in the country. The Information Technology Act, 2000 provides legal framework to address the issues connected with cyber attacks, Deora added.

Researcher builds botnet-powered distributed file storage system using JavaScript

 The botnet-type system is called HiveMind and was built by Sean T. Malone, a principal security consultant at penetration testing firm FusionX.
HiveMind uses technologies like HTML5 WebSockets and Web Storage that are also used by legitimate Web applications.
There are no malicious exploits being used, so there is nothing that can be patched to prevent it, Malone said. However, building the botnet by getting other people's browsers to load a piece of JavaScript code and storing data on their computers falls into a legally gray area, he said.
"This was a research project, not production software" he said. "I'm not a lawyer, so I don't intend to give anyone legal advice with this," he said, adding that everyone is responsible for what they decide do with the software he plans to release later this week.
The HiveMind JavaScript code can be distributed to browsers in several ways, including hosting the JavaScript code on legitimate or compromised websites or by distributing the code through an advertising network, which would place it on multiple websites.
For his research, Malone set up an anonymous Web proxy server that later got added to proxy lists and started being used by people. Every time someone used the proxy server to browse to a Web page, the server would inject the HiveMind JavaScript code into that page.
According to the researcher, his proxy server was getting connections from 20,000 unique IP addresses every ten minutes, which then became nodes in the botnet.
HiveMind has a C&C (command and control) server that uses a SQL database to keep a record of all files and the nodes -- browsers running the JavaScript code -- they're distributed on.
When a file is uploaded to the server, it is encrypted using the AES (Advanced Encryption Standard) with a password provided by the uploader. The encrypted file then gets split into multiple blocks and those blocks are distributed across different nodes.
Every file can have a different password, Malone said.
Because the botnet is highly dynamic, with nodes constantly disappearing when users close their browsers, every file block is distributed across multiple nodes to achieve redundancy.
The nodes constantly announce their presence and the list of blocks they have back to the server, so that a particular block can be redistributed to new nodes if the number of nodes storing it drops under a certain threshold.
After a file is uploaded, encrypted and distributed to the nodes, it is no longer kept on the server. Only a record of the nodes that contain its different blocks is stored, because this is necessary to rebuild the file, Malone said.
If a government agency were to seize the server and take it away, the block replication process would fail because the nodes would start going offline, which would make the file unrecoverable, Malone said. There are a few ways to recover the data, but it is very difficult and it involves seizing a large number of nodes or compromising the server while it's still online and coercing the owner to provide the passwords necessary to decrypt the files.
There is a way to provide "plausible deniability" for the owner and it involves initially seeding the server with a large number of dummy files that contain random data, but this functionality is not yet built into the system, Malone said.
The user can say that he created the system, but did not put any real data in it, even though he did also upload some real files along with the dummy ones.
Because the random data in the dummy files looks the same as the random data in encrypted files, when trying to recover a file there is no way to tell if the password supplied by the user was correct and a dummy was decrypted, or if the password was wrong, the researcher said.
In this way, the user can supply the wrong password for the files he knows are real and the other party would have no way to prove that the password was correct or incorrect.
While the legality of building such a botnet is questionable, this system could also be set up as a collaborative effort, where users volunteer their browsers themselves and are able to upload files to the system, Malone said.

Secure Code Review:Need for every application

This article is about different code review techniques and their application in the real world
What you will learn:

What is secure code review and how to deal with them in real-life scenarios
What you should know:

Basic security concepts
Secure Code Review:

Secure Code Review is a process which identifies the insecure piece of code which may cause a potential vulnerability in a later stage of the software development process, ultimately leading to an insecure application. When a vulnerability is detected in earlier stages of SDLC, it has less impact than the later stages of SDLC – when the insecure code moves to the production environment. In the SDLC (Software Development Life Cycle) process [Figure-1], the secure code review process comes under the Development Phase, which means that when the application is being coded by the developers, they can do self-code review or a security analyst can perform the code review, or both. The developers may use automated tools which can be integrated with their IDE (Eclipse, MS VS, etc…) and can do coding and code review simultaneously. After that, they can take the help of a security expert to identify more flaws in the code, as the security experts have a more intrinsic view of security issues which might be missed by the developers.
Different studies and surveys shows that approximately 75% of attacks happen due to an insecure application, inside which includes insecure code. This way, it becomes a very essential part of SDLC which should be performed rigorously. Developers mostly tend to focus on the functionality of the application and ignore the secure coding approach. But nowadays they have become more conscious about code review due to the increasing incidents of hacking and server attacks.

Figure – 1

Techniques to secure code review:

Generally, we can divide the secure code review process into two different techniques:

1. Automated tool based/ Black Box: In this approach, the secure code review is done using different open source/commercial tools. Mostly developers use them while they are coding, but a security analyst may also take help of them. Tools are very useful while doing code review when we implement the secure SDLC process in the organization and provide the tool to developers themselves to do a “self-code” review while they are coding. Also, the tools are useful in analyzing large codebase (millions of lines). They can quickly identify potential insecure pieces of code in the codebase, which may be analyzed by the developer or a security analyst.
2. Manual/ White Box: In this technique, a thorough code review is performed over the whole code, which may become a very tedious and tiresome process. But in this process, logical flaws may be identified which may not be possible using automated tools, such as business logic problems. Automated tools are mostly capable of finding technical flaws such as injection attacks but may miss flaws like authorization problems. In this process, instead of going line by line through whole code base, we can concentrate on potential problems in the code. Those potential vulnerabilities can be given a high priority. For example, in C/C++, if we try to find any copying function in the code and check whether it’s using functions such as, strcpy() for performing copy function. As we know, strcpy() is known to be vulnerable to buffer overflow attacks. We may also want to check if any customized encryption is being used in the application, which automated tools may miss as they can identify standard algorithms only.
   So the best approach will be a mix of both, depending on the volume and criticality of data. In today’s world where many complex applications are developed, we can’t ignore any of the above mentioned techniques.

Benefits of Secure code review:

There are some factors that should be taken into consideration while developing a robust access control mechanism in the web application:

1. Effort benefit: The effort to fix the vulnerabilities in the earlier stage of the SDLC process is much less than the later stage of the process. Once the code is complete and the flaw is not identified, it’s a very tedious and time consuming process to find problems once the application is ready to move into production. Also, last minute fixing may affect the entire functionality of the program and hamper deadlines set for product release. Who knows, it may create another security flaw, which can easily be possible with a large and complex code.
2. Cost benefit: Cost is directly proportional to effort required. Not only development cost, but also, a vulnerability identified in the production environment may involve more costs. Again, it’s well worth it, as the costs associated with an attack can be much steeper.
3. Compliance: Some compliance, such as PCI, makes it necessary to do a secure code review before launching the product. So an organization following complete SDLC has better chance of being certified.
4. Reputation: Secure code review removes most of the security flaws in the earlier phase, making it more secure than just doing black box assessments. So there is less chance of the product being compromise, hence lesser chance of reputation damage.

Approach:

These are based on mix of standard process and my own approach. It may differ from person to person.
Standard process [Figure-2]:

Figure-2

Define scope: First, you need to understand and come up with a rough estimate about the scope of the code review and the efforts involved in it. Also, budget constraints may be defined. What type of code review may be performed? Black box or white box? Try to understand the business logic of the application. Remember which vulnerabilities you need to look for, such as OWASP Top 10, SANS, etc… One can try to review them as much as possible, if not all of them. Then you can deduce how many of them can be detected using tools and which are best suited for manual review.
Categorize the vulnerabilities: What is your priority, meaning what type of vulnerabilities you will take as a priority? For example, in business applications, you may concentrate mostly on the business logic of the application and dive deep into it, as the technical ones are easily detected by tools. Prioritize them.
The following are a few categories you can look at:

• Authorization
• Authentication
• Injection flaws
• Improper error handling/Exception flaws
• Encryption (Cryptography)
• Auditing and Logging
• Session related flaws (Session management)
• Insecure configuration

Recommendation: As a security analyst, it’s our duty filter false positives generated by tools and validate them in order to confirm that they are actual flaws. After doing a proper code review, you should document the vulnerabilities found in a comprehensive report coating the category of the vulnerability and their mitigation. You may go one step ahead and suggest a sample secure code. I personally include the code snippets as well in the report, preferably in an excel file and then attach it.
This is how I personally go about it. The points below are based on my experience till date in doing code review. I have still a lot to learn and the points below may or may not hold true in every condition:
Always perform manual reviews: Automated code review is a process where you run the scanning tools like Rational, Ounce Labs, and Parasofton the code base followed by a manual auditing of the results. The scanner flags the whole code with vulnerabilities based on its perception. Now it’s the job of the auditor to differentiate between real issues and false positives. Here is where the real pain starts. You don’t have command over each and every language. So taking help of language specific resources is required. Now, I have got familiar with almost all major languages (.NET, Java, PHP) specific vulnerabilities. Doing a black box assessment you never come to know where the real problem lies.
Talk to developers first: The more you involve developers in your code review process, the more effective the analysis will be. You get confidence that whatever you are doing is based on the right understanding of the code. On the other hand, developers also get happy that you are taking theminto confidence instead of declaring something vulnerable straightaway.
Have a notebook and pen handy to understand the flow of the program. Understanding the source of the taint and where does it reflects in the code is necessary to catch the real vulnerabilities. Just seeing that the taint is entering the program and reflecting in some other part of the program doesn’t always mean that it is vulnerable to Cross Site Scripting, for example. Again here, talking to developers helps, as they might be implementing some centralized input filtering/validation mechanism. So don’t just jump to any conclusions.
Use an advance text editor: The text editor should be capable of searching a term in the whole code base. One such text editor is Notepad++. It searches the term and highlights them so that you can see where all places the particular term is being used. It helps you in joining the pieces and seeing the complete picture.
Have sufficient time to do code review, as you need to apply your thoughts more than once to pick up real vulnerabilities. So always ask your customers for sufficient time in fully completing the project.
Being connected to Internet always helps at the time of code review. Certain terms, functions or methods always annoy you as you might have not have seen them before. Google helps a lot in understanding them.
Find vulnerabilities in context of the application: Not only should you pick up real and applicable vulnerabilities in the context of the application – as it decreases the number of issues – but also, you should propose the countermeasures in the report. That makes developers happy and confident. The scanner may flag any issue as High, Medium or Low. It’s your responsibility to give them appropriate ranking based on applications context.
Everybody loves his own program: Programs are like a developers baby. Don’t always pinpoint the weaknesses of the program, also appreciate them if you find any robust mechanism used in the program. That way, you can make them friendly and they will always come to use to get their code reviewed. So both are then happy.
Train them: Last but not least, train developers about the vulnerabilities in the real world. Give them training, involve them and encourage them to review their codes before production. Tell them how it saves effort and money. If you have a scanning tool that supports plug-ins for IDE, install it at their machines so that they can do proper development and a hand by hand review.
A Sample Illustration:

Consider this example( Owasp WebGoat Project):
String username = “”;

String password = “”;
username = s.getParser().getRawParameter(USERNAME);
password = s.getParser().getRawParameter(PASSWORD);

……………..

………..……

String query = “SELECT * FROM user_system_data WHERE user_name = ‘”

+ username + “‘ and password = ‘” + password + “‘”;

ec.addElement(new StringElement(query));

The inputs from the user are requested through getRawParameter, and assigned to the ‘username’ and ‘password’ variables. Again, they are being used directly in the SQL query without any input validation and also being embedded into the dynamic query. Any malicious user can tamper with this query to run his own arbitrary SQL codes. So if we try to find all the entry points into the codebase (getRawParameter in this case), we may detect injection flaws. Even if we search for SQL queries being used in the code, if we find that they are being used as dynamic queries, they may be a case of a possible SQL injection.

On the Net:
 https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project
https://www.owasp.org/images/2/2e/OWASP_Code_Review_Guide-V1_1.pdf