Tag Archives: Ids

Attacking by Obscurity

Bellow the Radar

Everybody agrees to consider “security by obscurity” a false sense of security. By using this principle, the security of an information system in (falsely) increased by hiding sensitive details. Such information can be removed like: by altering the application welcome banner (in Apache, sendmail, etc), by changing the default port (example: binding your SSH daemon on port 2222 instead of the standard 22), by renaming critical files with invalid names or extensions.

From an offensive point if view, attacking by obscurity can be much more interesting. If you launch an attack on a specific target, there are (mis)chances that your behavior will be detected by an IDS, a firewall or any other security countermeasure. One of the solution is to work “below the radar”. It means performing the attack at a very low rate to not trigger the rules in the security system or by avoiding regular patterns in your packets. Example when using Nmap:

     # nmap -sF --max-rate 0.5 --scan-delay 3 192.168.0.0/24

In this command line:

  • “–scan-delay” asks Nmap to wait at least the given amount of time between each probe it sends to a given host.
  • “–max-rate” limits the scan sending rate to a given maximum

Note that,  by default, Nmap randomizes the ports to scan (except the well-know ports for efficiency)

Another method is to use a solution like inundator. What’s the purpose of this tool? Quoted from the official website: “inundator is a multi-threaded, queue-driven, IDS evasion tool. Its purpose is to anonymously flood intrusion detection systems (specifically Snort) with traffic designed to trigger false positives via a SOCKS proxy in order to obfuscate a real attack.

It could be resumed as “The security analyst’s nightmare;-) The principle is quite simple: Hide your real attacks amongst thousand of false-positive alerts generated by the IDS and hope that the real attack won’t be discovered.

Inundator Components

(Click to enlarge)

Based on the schema above, inundator reads the current Snort rules database and generate packets which will trigger the rules. A Nmap scan of the target host(s) is performed to detect interesting ports. inundator floods the target host(s) via the generated packets to the ports reported open by Nmap. In parallel, the real attack is performed. Of course, the flood of packets will be send via Tor or a bunch of open proxies to increase the number of sources.

Unfortunately, inundator is not able to detect the IDS in place and works only with the Snort signatures. If we come back to the “defensive” point of view, inundator can be used to stress test your Snort.

Source code: inundator_0.5.tar.gz

SCADA, from a Security Point of View

Recently, I read a RFP issued by a customer. The main topic focused on a perimeter security but a paragraph mentioned the protection of SCADA environments. I’ve no practical experience with SCADA and I tried to find relevant information about the deployment of security solutions in such environments. Here follows a compilation of information about this technology. This is just an introduction, I’m not a “guru”.

SCADA means “Supervisory Control And Data Acquisition“. It refers to the use of computers to monitor and control an industrial process. From a console (called HMI – “Human Machine Interface“), operators can interact with a bunch of sensors and programmable controllers. To explain shortly, it’s possible to collect information from a sensor (the “Acquisition” phase) or interact with active components (the “Control” phase). Practical examples are: to read the pressure in a pipe and to control the opening of a valve to reduce the pressure. SCADA could be compared (very rough comparison!) with SNMP: You can poll the value of SNMP OIDs from a network devices like a switch or receive traps and change the value of certain OIDs.

SCADA is used in multiple domains: industrial (example: energy production), infrastructure (distribution) or facilities (buildings,  cooling or heating systems, airport luggage handling systems). By reading those examples, you immediately realize that the environments where SCADA components are deployed are really critical. Bad interpretation or unexpected behavior can have major impacts up to the highest level: risk of body injuries or even death! Can you imagine a SCADA environment controlled by hackers? That’s basically the scenario of the latest Die Hard movie. Scaring? But this is not a movie: vulnerabilities have already been discovered for SCADA products!

The different components of a SCADA infrastructure must exchange information via a communication link. In the first generations of products, this was performed over serial or modem connections. Today, the last generation uses (what a surprise!) TCP/IP networks. Ethernet is commonly used but, for longer distance (example: to manager railways infrastructure), communication are based on SONET links. Helas, TCP/IP means also more vulnerabilities. Note that a SCADA infrastructure does not rely on a unique standardized protocol. A lot of them have been developed and understood by most of the manufacturers (good examples are  nice names like IEC 60870-5-101 or 104, IEC 61850 or DNP3). Old protocols are replaced by common networking protocols over IP. The “web madness” also reached the SCADA products manufacturers: more and more web interface are available to manage the components (more friendly interfaces).

What are the risks associated to a SCADA infrastructure?

  • First, IP protocols are routed protocols. Packets can be routed/NATed. The SCADA components must be physically separated from any other IP network. Installing a firewall between the organization LAN and the HMI console is not enough with today’s attacks. Of course, any Internet connectivity must be prohibited.
  • By introducing web interfaces, manufacturers increase the risks to introduce web vulnerabilities. Check out the OWASP Top-ten for more information about risks associated to web applications.
  • DoS (“Deny of Services“) attacks. Attackers could try to interrupt communications between the components or flood a component with false-positive information.
  • Common mistakes are the lack of controls and the principle of “security by obscurity”. SCADA protocols are obscure protocols but it does not mean they are not vulnerable.
  • Network outages: components must be able to exchange information in real-time without any interruption.

Those issues can be classified in two main types of threats: Unauthorized accesses to a control station (HMI) or injections of rogue packets on a SCADA network.

How to protect a network carrying SCADA protocols? First, physically disconnect the network segment used by the SCADA components from the rest of your network. Still today, too many SCADA devices are directly available on the Internet. Protect against inappropriate physical access to the network. Switches must be properly secured: all unused ports must be disabled, port-security must be enabled (example: by learning the MAC addresses). Perform end-point authentication for all devices connected to the SCADA network (using VMPS, 802.1x or any other solution). If packets must cross other segments (business or technical requirements), encrypt all the traffic using a VPN or a SSL tunnel.

At host level (the HMI  or console), restrict physical and logical access to the console. Prevent any communication with another network. Those hosts must be dedicated to the SCADA applications and never exchange e-mail, web traffic which are common sources of malwares and viruses. Local security must be enforced using anti-virus, anti-malwares or host-based IDS. Another good practice is to work with while lists of applications. Also, automatic patching can be disabled to prevent any unexpected reboot or problem. Patches must be validated first on a test system before being installed in the producion environment during defined intervention time-windows.

Like other networks, IDS and firewalls can be deployed. Intrusion Detection System could detect suspicious or malformed SCADA packets injected on a network. On Scadapedia, there are SCADA signatures ready to be used with Snort, a well-known open source IDS project. Signatures cover the following protocols: Modbus/TCP, DNP3 and ICCP. Some firewalls solutions exists for filter SCADA protocols. Those are commercial products and often based on a Linux kernel with iptables and a bunch of specific rules. Finally don’t forget to add some visibility on top of your SCADA network:

  • Monitor the components health using a monitoring tool.
  • Collect information about your network. Restrict the amount of trafic to the minimum to keep the network performant.
  • Monitor the network response time and availability.

Another interesting project is called the SCADA Honeynet Project. It simulates several industrial environments. The ISA (“International Society of Automation“) developed a standard (ISA99) called: Security for Industrial Automation and Control Systems: Establishing an Industrial Automation and Control Systems Security Program. It  addresses manufacturing and control systems whose compromise could result in situations like: the safety of public or employee, loss of confidential information, loss of profit, impact of the national security.

To conclude,  protecting a SCADA network is like any other network: the CIA-principle must be respected. But with two main differences:

  • Specific “obscure” protocols not supported by the common security devices (deployed solutions must be adapted to the SCADA protocols).
  • Incident can have major impacts on infrastructure outside the IT infrastructure or on people.