Malware infects power plants

During the past three months, unnamed malware infected two power plants' control systems using unprotected USB drives as an attack vector. At both companies, a lack of basic security controls made it much easier for the malicious code to reach critical networks.
In one instance, according to a recent report from the Department of Homeland Security's Industrial Control Systems Cyber Emergency Response Team (ICS-CERT), malware was discovered after a power generation plant employee asked IT staff to look into a malfunctioning USB drive he used to back up control systems configurations.
That discovery prompted a more thorough on-site inspection that revealed "a handful of machines that likely had contact with the tainted USB drive." This included two of 13 workstations in an engineering bay tied to critical systems. "Detailed analysis was conducted as these workstations had no backups, and an ineffective or failed cleanup would have significantly impaired their operations," according to the report.
Analysts noted the need for operators of the nation's critical infrastructure networks to follow best practices. In recent years security researchers have tried to draw more attention to SCADA and ICS security (or the lack thereof) as a way of pushing companies, usually privately owned, to invest more resources in protecting their networks from cybercriminal activity.
"While the implementation of an antivirus solution presents some challenges in a control system environment, it could have been effective in identifying both the common and the sophisticated malware discovered on the USB drive and the engineering workstations," they wrote in this report. The ICS-CERT team also recommended cleaning USB drives after each use or using other media, such as write-once CDs, to help reduce the risk of malware contamination.
"The organization also identified during the course of the investigation that it had no backups for the two engineering workstations. Those workstations were vital to the facility operation and, if lost, damaged, or inoperable, could have a significant operational impact. The recommended practice is to maintain a system of 'hot spares' or other effective backups for all critical systems."
In a separate incident in October, ISC-CERT investigators discovered 10 computers linked to another power company's turbine control system also were infected with a virus via a USB drive during a software update installation. "Unknown to the technician, the USB-drive was infected with crimeware. The infection resulted in downtime for the impacted systems and delayed the plant restart by approximately 3 weeks."

Security Issues for Cisco Routers Uncovered

Researchers have uncovered a root exploit zero-day affecting the default installation of an unknown number of Cisco’s Linksys routers. Cisco  has been urged to fix the potentially serious vulnerability before they release the full PoC on BugTraq and Full Disclosure in two weeks, per the vulnerability disclosure policy. The exploit on the Cisco Linksys WRT54GL model  was  performed and believe that other models are vulnerable as well. They aren’t entirely certain how many router models are impacted by the flaw, but they note that Cisco has sold some 70 million Linksys routers. The group claims to have previously reported the vulnerability to Cisco along with its proof-of-concept. Cisco allegedly responded to disclosure, telling them that the bug had been resolved in the most recent firmware update. The group later then tested their PoC again and determined that the current version of the router (4.30.14) and all previous versions remain vulnerable.
A Cisco spokesperson confirmed the vulnerability's existence via email, but claimed that the flaw only affected the Linksys WRT54GL home router, the same model on which the group tested their exploit. The spokesperson for Cisco assured claimed that Cisco has developed and is currently testing a fix for the issue. In the meantime, Cisco advises that customers using the WRT54GL router model stay safe by maintaining a securely configured wireless router.

Turn off Java on your browser

Due to the vulnerability on Java Plugin users have been advised to disable java on their browser. Note that Java is completely different from Java script. Disabling  Javascript thinking is also part of java will yield an unexpected result on the browser because most websites are coded in java script, AJAX. On the browser Javascript helps to craft the look and feel of your website. That doesn't mean there aren't security risks from JavaScript. There are, but they're different to the ones posed by Java, and they're generally fixed or patched directly by your browser vendor. JavaScript is very commonly used in modern websites. In fact, you won't get very far without it on many of the popular sites out there.

On the other hand, Java, made by Oracle, is a software package installed separately from your browser. It can be used for creating and running all sorts of regular-style software: web servers, code editors, word processors and much more. These are called applications, just like any other application such as Microsoft Word or Apple iMovie. Java also provides a plugin system that allows stripped-down Java programs called applets to run inside your browser. They aren't integrated with your browser like JavaScript programs, and their security generally depends on the Java system itself, not on your browser. Nevertheless, there have been several recent and widely-abused bugs in the applet part of Java that make your browser insecure. Time and time again we're seeing examples of cybercriminals exploiting flaws in Java to infect innocent users' computers.

For instance, earlier this year we saw more than 600,000 Macs infected by the Flashback malware because of a Java security flaw. In fact, it has become increasingly common to see malware authors exploiting vulnerabilities in Java - as it is so commonly installed, and has been frequently found to be lacking when it comes to security. Cybercriminals also love Java because it is multi-platform - capable of running on computers regardless of whether they are running Windows, Mac OS X or Linux. As a result it's not unusual for us to see malicious hackers use Java as an integral part of their attack before serving up an OS-specific payload. Seriously though, stop reading this article now and check if you have disabled Java or not. Chances are that if you don't think that you need Java, you don't need it. Even if you absolutely must use websites that require you to have Java installed, why not disable it in your main browser and have an alternative browser just for visiting that website? What you need to do now is reduce the opportunities for attack. For most people that means disabling Java - and doing it now.

So i recommend that you turn off Java in your browser.

Most recently, in January 2013, a new zero-day flaw affecting Java in web browsers was exploited. Apple and Mozilla are doing things to help fight the problem for their users, but you may decide that you still need to take steps yourself. There will be many pointing fingers at Oracle and arguing that it has not taken the security flaws seriously, but the accusations that are bound to fly aren't actually going to help the millions and millions of vulnerable devices out there. Those devices need a patch from Oracle - but as it may not be available for some time, the best advice I can give you is to disable Java.

Web application and attacks

There is no doubt that web application security is a current and very newsworthy subject. For all concerned, the stakes are high: for businesses that derive increasing revenue from Internet commerce, for users who trust web applications with sensitive information, and for criminals who can make big money by stealing payment details or compromising bank accounts. Reputation plays a critical role: few people want to do business with an insecure web site, and so few organizations want to disclose details about their own security vulnerabilities or breaches. Hence, it is not trivial to obtain reliable information about the state of web application security today. Any security threats arising from hosting a web site related largely to vulnerabilities in web server software (of which there were many). If an attacker compromised a web server, he would not normally gain access to any sensitive information, because the information held on the server was already open to public view. Rather, an attacker would typically modify the files on the server to deface the web site’s contents, or use the server’s storage and bandwidth to distribute “warez.”

Today, the World Wide Web is almost unrecognizable from its earlier form. The majority of sites on the web are in fact applications. They are highly functional, and rely upon two-way flow of information between the
server and browser. They support registration and login, financial transactions, search, and the authoring of content by users. The content presented to users is generated dynamically on the fly, and is often tailored to each specific user. Much of the information processed is private and highly sensitive. Security is therefore a big issue: no one wants to use a web application if they believe their information will be disclosed to unauthorized parties. Web applications bring with them new and significant security threats. Each application is different and may contain unique vulnerabilities. Most applications are developed in-house, and many by developers who have little understanding of the security problems that may arise in the code they are producing. To deliver their core functionality, web applications normally require connectivity to internal computer systems that contain highly sensitive data and are able to perform powerful business functions. Ten years ago, if you wanted to make a funds transfer, you visited your bank and someone performed it for you; today, you can visit their web application and perform it yourself. An attacker who compromises a web application may be able to steal personal information, carry out financial fraud, and perform malicious actions against other users.

Common Web Application Functions
Web applications have been created to perform practically every useful function
one could possibly implement online. Examples of web application functions
that have risen to prominence in recent years include:

• Shopping (Amazon)
• Social networking (MySpace)
• Banking (Citibank)
• Web search (Google)
• Auctions (eBay)
• Gambling (Betfair)
• Web logs (Blogger)
• Web mail (Hotmail)
• Interactive information (Wikipedia)

In addition to the public Internet, web applications have been widely adopted inside organizations to perform key business functions, including accessing HR services and managing company resources. They are also frequently used to provide an administrative interface to hardware devices such as printers, and other software such as web servers and intrusion detection systems. Numerous applications that predated the rise of web applications have been migrated to this technology. Business applications like enterprise resource planning (ERP) software, which were previously accessed using a proprietary thick-client application, can now be accessed using a web browser. Software services such as email, which originally required a separate email client, can now be accessed via web interfaces like Outlook Web Access. This trend is continuing as traditional desktop office applications such as word processors and spreadsheets are migrated to web applications, through services like Google Apps and Microsoft Office Live. The time is fast approaching when the only client software that most computer users will need is a web browser. A hugely diverse range of functions will have been implemented using a shared set of protocols and technologies, and in so doing will have inherited a distinctive range of common security vulnerabilities.

Benefits of Web Applications
It is not difficult to see why web applications have enjoyed such a dramatic rise to prominence. Several technical factors have worked alongside the obvious commercial incentives to drive the revolution that has occurred in the way we use the Internet:

• HTTP, the core communications protocol used to access the World Wide Web, is lightweight and connectionless. This provides resilience in the event of communication errors and avoids the need for the server to hold open a network connection to every user as was the case in many legacy client-server applications. HTTP can also be proxied and tunneled over other protocols, allowing for secure communication in any network configuration.
• Every web user already has a browser installed on their computer. Web applications deploy their user interface dynamically to the browser, avoiding the need to distribute and manage separate client software, as was the case with pre-web applications. Changes to the interface only need to be implemented once, on the server, and take effect immediately.
• Today’s browsers are highly functional, enabling rich and satisfying user interfaces to be built. Web interfaces use standard navigational and input controls that are immediately familiar to users, avoiding the need to learn how each individual application functions. Client-side scripting enables applications to push part of their processing to the client side, and browsers’ capabilities can be extended in arbitrary ways using thick-client components where necessary.
• The core technologies and languages used to develop web applications are relatively simple. A wide range of platforms and development tools are available to facilitate the development of powerful applications by relative beginners, and a large quantity of open source code and other resources is available for incorporation into custom-built applications.

Web Application Security
As with any new class of technology, web applications have brought with them a new range of security vulnerabilities. The set of most commonly encountered defects has evolved somewhat over time. New attacks have been conceived that were not considered when existing applications were developed. Some problems have become less prevalent as awareness of them has increased. New technologies have been developed that have introduced new possibilities for exploitation. Some categories of flaws have largely gone away as the result of changes made to web browser software. Throughout this evolution, compromises of prominent web applications have remained in the news, and there is no sense that a corner has been turned and that these security problems are on the wane. Arguably, web application security is today the most significant battleground between attackers and those with computer resources and data to defend, and it is likely to remain so for the foreseeable future.
SSL is an excellent technology that protects the confidentiality and integrity of data in transit between the user’s browser and the web server. It helps to defend against eavesdroppers, and it can provide assurance to the user of the identity of the web server they are dealing with. But it does not stop attacks that directly target the server or client components of an application, as most successful attacks do. Specifically, it does not prevent any of the vulnerabilities listed previously, or many others that can render an application critically exposed to attack. Regardless of whether or not they use SSL, most web applications still contain security flaws. flaws /vulnerabilty includes:

• Broken authentication (67%) — This category of vulnerability encompasses various defects within the application’s login mechanism, which may enable an attacker to guess weak passwords, launch a brute-force attack, or bypass the login altogether.
• Broken access controls (78%) — This involves cases where the application fails to properly protect access to its data and functionality, potentially enabling an attacker to view other users’ sensitive data held on the server, or carry out privileged actions.
• SQL injection (36%) — This vulnerability enables an attacker to submit crafted input to interfere with the application’s interaction with back-end databases. An attacker may be able to retrieve arbitrary data from the application, interfere with its logic, or execute commands on the database server itself.
• Cross-site scripting (91%) — This vulnerability enables an attacker to target other users of the application, potentially gaining access to their data, performing unauthorized actions on their behalf, or carrying out other attacks against them.
• Information leakage (81%) — This involves cases where an application divulges sensitive information that is of use to an attacker in developing an assault against the application, through defective error handling or other behavior.

Web Application And Security

With today’s web application platforms and development tools, it is possible for a novice programmer to create a powerful application from scratch in a short period of time. But there is a huge difference between producing code that is functional and code that is secure. A development team that begins a project with a complete knowledge of current threats may well have lost this status by the time the application is completed and deployed.
Most web application development projects are subject to strict constraints on time and resources, arising from the economics of in-house, one-off development. It is not usually possible to employ dedicated security expertise in the design or development teams, and due to project slippage security testing by specialists is often left until very late in the project’s lifecycle. In the balancing of competing priorities, the need to produce a stable and functional application by a deadline normally overrides less tangible security considerations. A typical small organization may be willing to pay for only a few man-days of consulting time to evaluate a new application. A quick penetration test will often find the low-hanging fruit, but it may miss more subtle vulnerabilities that require time and patience to identify.
Before the rise of web applications, organizations’ efforts to secure themselves against external attack were largely focused on the network perimeter. Defending this perimeter entailed hardening and patching the services that it needed to expose, and firewalling access to others. The core security problem faced by web applications arises in any situation where an application must accept and process untrusted data that may be malicious. However, in the case of web applications, there are several factors which have combined to exacerbate the problem, and which explain why so many web applications on the Internet today do such a poor job of addressing it.

• The majority of attacks against web applications involve sending input to the server which is crafted to cause some event that was not expected or desired by the application’s designer. Some examples of submitting crafted input to achieve this objective are as follows: Changing the price of a product transmitted in a hidden HTML form field, to fraudulently purchase the product for a cheaper amount.
• Modifying a session token transmitted in an HTTP cookie, to hijack the session of another authenticated user.
• Removing certain parameters that are normally submitted, to exploit a logic flaw in the application’s processing.
• Altering some input that will be processed by a back-end database, to inject a malicious database query and so access sensitive data.

Note:  Needless to say, SSL does nothing to stop an attacker from submitting crafted input to the server. If the application uses SSL, this simply means that other users on the network cannot view or modify the attacker’s data in transit. Because the attacker controls her end of the SSL tunnel, she can send anything
she likes to the server through this tunnel.

If a vulnerability exists within a web application, then an attacker on the public Internet may be able to compromise the organization’s core back-end systems solely by submitting crafted data from his web browser. This data will sail past all of the organization’s network defenses, in just the same way as does ordinary, benign traffic to the web application. The effect of widespread deployment of web applications is that the security perimeter of a typical organization has moved. Part of that perimeter is still embodied in firewalls and bastion hosts. But a significant part of it is now occupied by the organization’s web applications. Because of the manifold ways in which web applications receive user input and pass this to sensitive
back-end systems, they are the potential gateways for a wide range of attacks, and defenses against these attacks must be implemented within the applications themselves. A single line of defective code in a single web application can render an organization’s internal systems vulnerable.

For an attacker targeting an organization, gaining access to the network or executing arbitrary commands on servers may well not be what they really want to achieve. Often, and perhaps typically, what an attacker really desires is to perform some application-level action such as stealing personal information, transferring funds, or making cheap purchases. And the relocation of the security perimeter to the application layer may greatly assist an attacker in achieving these objectives. For example, suppose that an attacker wishes to “hack in” to a bank’s systems and steal money from users’ accounts. Before the bank deployed a web application, the attacker might have needed to find a vulnerability in a publicly reachable service, exploit this to gain a toehold on the bank’s DMZ, penetrate the firewall restricting access to its internal systems, map the network to find the mainframe computer, decipher the arcane protocol used to access it, and then guess some credentials in order to log in. However, if the bank deploys vulnerable web application, then the attacker may be able to achieve the same outcome simply by modifying an account number in a hidden field of an HTML form.

A second way in which web applications have moved the security perimeter arises from the threats that users themselves face when they access a vulnerable application. A malicious attacker can leverage a benign but vulnerable web application to attack any user who visits it. If that user is located on an internal corporate network, the attacker may harness the user’s browser to launch an attack against the local network from the user’s trusted position. Without any cooperation from the user, the attacker may be able to carry out any action that the user could perform if she were herself malicious. Network administrators are familiar with the idea of preventing their users from visiting malicious web sites, and end users themselves are gradually becoming more aware of this threat. But the nature of web application vulnerabilities means that a vulnerable application may present no less of a threat to its users and their organization than a web site that is overtly malicious. Correspondingly, the new security perimeter imposes a duty of care on all application
owners to protect their users from attacks against them delivered via the application.

While old and well understood vulnerabilities like SQL injection continue to appear, their prevalence is gradually diminishing. Further, the instances that remain are becoming more difficult to find and exploit. Much current research is focused on developing advanced techniques for attacking more subtle manifestations of vulnerabilities which a few years ago could be easily detected and exploited using only a browser.
A second prominent trend is a gradual shift in attention from traditional attacks against the server side of the application to those that target other users. The latter kind of attack still leverages defects within the application itself, but it generally involves some kind of interaction with another user, to compromise that user’s dealings with the vulnerable application. This is a trend that has been replicated in other areas of software security. As awareness of security threats matures, flaws in the server side are the first to be well
understood and addressed, leaving the client side as a key battleground as the learning process continues.While old and well understood vulnerabilities like SQL injection continue to appear, their prevalence is gradually diminishing. Further, the instances that remain are becoming more difficult to find and exploit. Much current research is focused on developing advanced techniques for attacking more subtle manifestations of vulnerabilities which a few years ago could be easily detected and exploited using only a browser.

A second prominent trend is a gradual shift in attention from traditional attacks against the server side of the application to those that target other users. The latter kind of attack still leverages defects within the application itself, but it generally involves some kind of interaction with another user, to compromise that user’s dealings with the vulnerable application. This is a trend that has been replicated in other areas of software security. As awareness of security threats matures, flaws in the server side are the first to be well understood and addressed, leaving the client side as a key battleground as the learning process continues.