Security Testing of Critical Infrastructures
Energy, Water, Healthcare, Transport, Communication and Food are some examples of critical services essential for the functioning of any nation. Non-availability or even limited non-performance of these critical infrastructures quickly results in disturbance and distress.
Hacking of these systems has surpassed physical attacks as the most serious security issue facing network operators and governments. Criminals and nation/state actors can exploit the increasing complexity and connectivity of critical infrastructure systems for political or commercial gains. Outages also impact a critical infrastructure operator's bottom line by driving up costs, and hampering ability to innovate, win and maintain customers.
Diverse infrastructure services such as water supply, transportation, fuel and power stations tend to be coupled together. Owing to this coupling, interdependent networks are extremely sensitive to failures in neighbouring systems such that a failure of in one network can produce an iterative cascade of failures in several interdependent networks. For instance, all infrastructures rely on availability of electricity, hence a power outage can have direct impact on availability of other services, such as transport, emergency, finance, communication, water supply etc.
While natural disasters cannot be eliminated, our ability to prevent man-made disasters can be greatly enhanced through careful infrastructure design and implementation, followed by security testing, particularly with tools buffer overflow and fuzzy logic application testing. This article examines the prevalent dependency on ICT technologies to manage critical infrastructure services and discusses how isolating an ICT component failure at the development stage itself could potentially help prevent a cascading critical infrastructure failure later on.
Modern threats to critical infrastructure are evolving at the same rate as the technology on which that infrastructure is based. Some key critical infrastructure sectors include:
Most of these critical infrastructures, such as electricity generation systems, and transportation systems are monitored by the Industrial Control Systems (ICS) while others are controlled by the Supervisory Control and Data Acquisition (SCADA) and integrated PLC and HMI solutions.
The ICS manages almost every aspect of critical infrastructures. Initially, no data transfer took place between ICS networks and business networks. But this gap is no more present. Now businesses depend on ICS data reporting systems to keep a check on their operations. Therefore, it is important to have strict security guidelines on ICS, which no more remains an isolated system. Each ICS has its own typical vulnerability and is prone to a cyber-attack. For instance, manipulating the data in a SCADA system and HMI of one connected infrastructure implies meddling with the machinery, which may be linked to water lines, power grids or oil pipes, which again will result in the disrupted operations of that particular infrastructure.
What if the railway's wireless communication system fails? Or what if there is an irregularity in gas supply which may affect electricity generation? Or what if a lack of water supply may adversely affect the agriculture sector? Or what if there is no Internet connection to perform any online banking transactions?
Most critical infrastructure sectors are mutually-dependent for their smooth functioning. This is one main reason why vulnerabilities are also on a rise. Failure of one infrastructure quickly cascades into failure of another, if the fault is identified and isolated quickly. A prime example is the infamous California energy crisis. It started just from a shortage of electricity supply and then left cascading effects on the gas and oil sector, apart from affecting the transportation services. That resulted in lower production of natural gas due to scarcity of electricity, which implied low supply of gasoline and petroleum. Also the transportation sector was affected because of their increasing need for liquid fossil fuels.
Sure, mutual dependence is good to optimize costs, but it also escalates the risk of multiple infrastructure failure.
The Information Communication and Telecom (ICT) sector brings opportunities to other critical sectors by enabling functionality, faster performance and ease of service. No wonder physical critical infrastructures use ICT technologies heavily. The type of dependency and resultant vulnerabilities vary significantly depending on the purpose and service of the ICT component chosen. For instance, the ICT vulnerabilities of a power system include its three main components -- computer, communication, and the power generator itself. Cyber dependency vulnerabilities arise when attacks can be targeted at specific systems, subsystems, and multiple locations simultaneously from a remote location. That is why SCADA systems, not designed for either multi-location implementation or remote management via the Internet, are now increasingly vulnerable to cyber dependency related failures and malicious attacks.
Critical Infrastructure systems are either physical or virtual. Energy, transport, waste and water represent physical assets. Operational software systems such as SCADAs, process control systems (PCS) or distributed control systems (DCS), that yield the operational ability to supervise, acquire data from and control the physical process, represent the virtual assets.
Generally ICT and specifically SCADA systems rely on software development procedures and offer some degree of fault tolerance within their design. However, since most of these systems are now connected to other internal and external operational systems, they can be vulnerable to new types of failures that have not been considered when they were designed.
There are a variety of hazards that can hamper the operations of critical infrastructure. Such vulnerabilities may include denial of service, negligence, forced malfunctioning of control systems (ICS), application testing practices that don't predict vulnerabilities, terrorist attacks, natural calamities, accidents, or any kind of a criminal activity.
ICS often uses products based on standard embedded systems platforms. ICS tends to use commercial off-the-shelf software for these products, with the objective of minimizing costs and making the product user-friendly. As these products come in contact with the Internet, they're open to the same threats as servers and PCs. As such, there are increased chances of network-based attacks on critical infrastructure.
Interruptions in critical infrastructure operations substantiate that cyber-attacks have an adverse noteworthy effect on them, resulting in industrial espionage, data loss and sabotage. For example, the Iranian nuclear facilities were pulled apart in 2010 by the Stuxnet malware program, without any real physical attack. Such an incident highlights how dangerous a cyber-attack on a critical infrastructure can be. Let's see some of the common vulnerabilities in different sectors of critical infrastructure.
The nature of software, the criticality factor of the infrastructure, and how easily a vulnerability in it may be abused, together give an idea of how potent a damage might be. The ever-increasing number of vulnerabilities in critical infrastructure being disclosed is making the governments more vigilant and proactive so as to be able to act positively to any appalling consequences from such attacks. Reducing the vulnerabilities of critical infrastructure by providing an optimum level of security is the key to avoiding any negative effects on the society.
Security plays an extremely important role for ICS. It isn't difficult for a cyber intruder to access a networked control system. Also the more an efficient a system is, more are the chances of a disaster because of the probable loopholes in it. ICS usually faces communication hijacking, database attacks, and 'man-in-the-middle' attacks, and the SCADA control room level is one of the most common places to compromise with security in the network.
Developers produce applications that to a greater or lesser degree exchange information by adhering to a protocol as closely as possible. QA then tests application functionality against that protocol in the perfect world of the testing laboratory. However, to come up with a bug-free application is near impossible.
Given the numerous ways programmers can make mistakes, looking for security vulnerabilities in a piece of software should be an integral part of the development process. Apart from identifying probable vulnerabilities in the critical infrastructure network, ICS and SCADA use penetration testing to find out if a cyber attacker can get access to the ICS system. The testers use the same methods as the hackers to get illegal access to the industrial network, without actually disrupting the control system.
Red Team tests are also conducted to check if one can get access of a network after using all or a combination of different types of possible vulnerabilities, apart from the cyber-linked ones. This methodology is considered as one of the proven ways to identify vulnerabilities in ICS.
How are hackers finding buffer overflow opportunities missed during development and standard pre-release QA? A wide range of tools have been developed by the hacker community to enable the rank and file to find new exploits. These tools, fuzzers, work by creating and feeding a wide range of unexpected or corrupted inputs looking for a combination that will break the application. The production of these tools has become a small industry of its own. The QA world has attempted to adapt these rough and ready hacker tools into their test processes with some success, but also with many headaches. Most of these hacker-developed fuzzers are focused on a single type of code weakness or just on a single protocol or even on a single application.
Traditional security tools, such as intrusion detection systems and firewalls, check only for known hazards, which exploit known vulnerabilities, without looking for the new types of anomalies. So even after all the QA testing being done, buffer overflow error tests, protocol breach tests, and black-box testing should be done to further reduce the scope of adding vulnerabilities to the devices. How? We'll look at that now!
Translation of requirements during application development is the first cause of most programming errors. For instance, if you take the financial sector, during the development of a banking software application, a project manager translates the requirements from the desired end to the programming team, which members translate to individual programming assignments. The programmers then translate the assignment into a proper syntax for the programming language written by someone else, which a programming language interpreter translates into the corresponding machine code. All these translations are sources of potential programming errors during the design stage.
Off-by-one errors, programming language use errors, integer overflows are all examples of errors generated by a programmer while translating a concept to a proper algorithm. For example, if a programmer assumes that a variable contains only positive integers, but if the integer in question is actually a signed integer, arithmetic operations can cause an overwrite of the leftmost bit and make the result a negative number, possibly leadingto an exploitable behavior.
However, not all programming errors are created equally. Some allow attackers to gain something or to get an ability they didn't already have. They may be able to deny other users' access to the program by crashing it, or access information they shouldn't be able to. In some cases, they may be able to cause the program to execute any command they tell it. These errors are vulnerabilities. Other errors, while they may have the same causes, won't give attackers any access they didn't already have. So, the first task for a vulnerability researcher is to determine if the programming error is merely a bug or if it can lead to exploitation. If a bug can lead to exploitation, either by itself or when used in concert with other bugs, it is indeed vulnerability.
Buffer overflows and vulnerabilities caused by the application not checking space availability before copying un-trusted data into the pre-allocated space in the system memory, end up overwriting contents of memory outside the buffer. As a result, next time the program looks at that memory space, it sees data from the overflow instead of the original data. If the program tries to use values from that area, it will most likely not see what it expects, the consequences of which can range from a crash of the program to other more potentially dangerous actions like DoS or worse, execution of a new malicious code planted by someone. A stack-based buffer overflow can allow attackers to execute code on the victim's computer, as it overwrites memory addresses that will be used later, while a "stack overflow" typically results in a DoS, as it tries to write to memory that isn't available.
Multi-protocol, environment-variable "Smart" fuzzers like beSTORM are vital for finding buffer overflow weaknesses not only because they automate and document the process of delivering corrupted input, but also because they closely watch for unexpected response from the application. Instead of using different tools for testing different security parameters of a software, beSTORM lets the QA team complete the entire dynamic testing of the software with one tool, before it gets deployed.
For example, beSTORM will try packets with malformed headers, by manipulating packet content and providing the kind of data that the application may be looking for, using &, <, >, full stops and commas within email applications, or typical URL symbols for HTTP servers. This is simply unviable if done manually.
Device protocol APIs allow applications to talk to a device over industry standard protocols. Developers need to simply identify the device and then open a communication channel to it. Opening a channel prompts for access authorization. This is a critical step to help prevent programs from accidentally or maliciously communicating with one or more devices without the user's awareness. Once access is granted, the program can communicate with a device, including starting long data transfers.
For instance, the financial sector has the equity market as a part of it, and a huge database is shared online for trading. Multiple devices communicate with each other, and a manipulation of data in one system will affect the entire equity market. The hackers usually target the basic coding, and try to mishandle input validation or boundary checking (defensive programming errors), design flaws (logical, design specification, and similar), and the implementation of the protocol itself. The main problem with that is the amount of possible attack combinations increase by a significant factor, making the time-to-result (crash or similar) impractical in some cases. This problem is solved by using advanced algorithms in an attempt to utilize attacks that are more likely to cause an error first, and then proceed to cover the entire combination space.
Still, these algorithms are not easy to develop. On some occasions, trying to exploit a large buffer or to send input of the wrong data-type makes for easy catches, but more the fuzzer advances in its search, more significant the efficiency of the algorithms used by individual fuzzers matter.
The use of more advanced manipulations based on the basic two types (value manipulation and protocol manipulation) also considerably impact the capability of today's fuzzers to provide results. For example, trying to exploit a logical flaw in the program by sending a login request twice and then combining it into the melting pot of attacks increases the number of combinations required, and the success rate. Being able to work with more advanced protocols, requiring the fuzzer to wait for a response before sending the next request (basically establishing sessions with the attacked application-session-based fuzzing) is another step in fuzzing.
Some more advanced manipulation techniques based on the basic sets further increase bottom-line results and the success of fuzzing. One such advanced technique is logic manipulation. Based on protocol manipulation, the fuzzer attempts to find logical programming errors resulting in a potential vulnerability. Another advanced technique is session manipulation (also based on protocol manipulation), which manipulates the actual session. For example, sending a request for a key to be issued, and then when it is received using another one or proceeding without it can cause other types of potential errors.
The main challenge faced by second-generation fuzzers when they employ these new techniques is the time required to cover the combination space exhaustively. Some exotic vulnerabilities in a product can be located at the very end of the combination space. Developing the technology to try to find the most likely attack vectors to trigger likely vulnerabilities in the shortest time possible is the solution.
beSTORM, perhaps the only multi-protocol, environment-variable and user-friendly "Smart" fuzzer, addresses protocol breaches by testing over 50 protocols and adapts to new or proprietary protocol specifications while providing automated binary and textual analysis, advanced debugging and stack tracing. In fact, it comes up with the probable security vulnerabilities without having an access to the source code.
This is a technique that works by automatically feeding a program multiple input iterations that are specially constructed in a way to trigger an internal error indicative of a bug, and potentially crash it. Commonly referred to as "fault injection" technique, blackbox testing can be applied to a network service as much as to a CPU, a cell phone, program parameters, an API, a Web browser, or a file type.
Testers with no knowledge of the internal working of the application being tested go about their work by first sniffing traffic at target protocols, generate input iterations from what they observe, and then drive 'Random' or 'Garbled' messages or 'Legal' mouse and keyboard events at the application until vulnerabilities emerge. Application monitoring can vary from a watchdog that sees if the program is still running to a remote check to see if the service is still available and responding or all the way to more advanced techniques like watching with a debugger for an anticipated exception.
Fuzzing procedures detect critical vulnerabilities which are gullible from the Internet, even after following a strict security procedure in the programming guidelines. Commercial fuzzers, which offer substantial interface support and can be functioned intuitively, assist in a prompt analysis of an application in terms of its security level, thereby helping in highlighting the errors in that application.
By applying automated protocol-based fuzzing techniques, beSTORM, a powerful automated black-box auditing tool, tries virtually every attack combination, intelligently starting with the most likely scenarios and detects application anomalies, which indicate a successful attack. This way security holes can be found in the application far faster, without brute force testing and almost without any user intervention. Easily scalable, beSTORM is equipped with the ability to use multiple processors or multiple machines to parallelize the audit and substantially reduce the testing duration.
Beyond Security's beSTORM is an exhaustive fuzzer. A powerful blackbox auditing tool, it is designed to find security weaknesses in protocol implementations and uses formal RFC definitions to create an attack language which in turn is used to identify vulnerabilities in the tested application. Although it supports testing for predetermined test cases and tries to exploit more likely vulnerabilities before continuing with the full test, its main objective is to allow for the most complete testing that will cover as much of the protocol space as possible. With beSTORM, it is also possible to write custom modules for proprietary protocols using XML.
For more information, visit www.beyondsecurity.comMore Information and Free Trial