Home Tags Network devices

Tag: network devices

BrandPost: DevOps at Wells Fargo

Portions of this post were originally posted on the Puppet blog, and are republished here with Puppet's permission.As one of the world's largest banks, Wells Fargo competes by innovating its IT.

At the heart of its innovation is the ability to conti...

Linux nasty kicks weak, hacked gadgets when they’re already down

Linux-Proxy-10 allows crooks to remain anonymous online Several thousand Linux devices have been infected with a new Linux-based trojan, Russian security software firm Doctor Web warns. The Linux-Proxy-10 Trojan infects network devices running Linux, turning them into a platform for cybercrime that allows crooks to remain anonymous online.

Black hats run freeware code called the Satanic Socks Server on infected devices. Miscreants hack into devices that are running with default passwords or are already infected with Linux malware in order to plant the malware. Back in 2004, the Sasser worm removed infections caused by the MyDoom mass mailer worm on compromised systems.

This kind of red-on-red action is messy and chaotic. Last year's Mirai worm showed the carnage that could result from abusing compromised IoT systems.

The appearance of a new trojan that – like Mirai – takes advantage of default user credentials to infect IoT devices is therefore bad enough, without considering the possibility of more strains of malware capable of easily spreading onto already hacked devices. ® Sponsored: Continuous lifecycle London 2017 event.

DevOps, continuous delivery and containerisation. Register now

Networks Getting Younger As Organisations Start To Embrace Workplace Mobility, IoT,...

The number of enterprises with at least one security vulnerability is the highest in five years

London, UK - 9 November 2016 - Enterprises across the globe are refreshing their network equipment earlier in its lifecycle in a move to embrace workplace mobility, Internet of Things, and software-defined networking strategies.
In addition, their equipment refresh is more strategic, with architectural vision in mind.

But despite the higher refresh rate, networks are getting less secure, largely due to neglected patching.

These are some of the highlights in the annual Network Barometer Report today by Dimension Data.

First published in 2009, the 2016 Network Barometer Report was compiled from data gathered from 300,000 service incidents logged for client networks that Dimension Data supports.

Dimension Data also carried out 320 technology lifecycle management assessments covering 97,000 network devices in organisations of all sizes and all industry sectors across 28 countries.

Andre van Schalkwyk, Senior Practice Manager Network Consulting, Dimension Data said, “Since 2010, networks had been ageing.

This year’s Report reverses that trend, and for the first time in five years, we’re seeing networks age more slowly.

“Ageing networks are not necessarily a bad thing: companies just need to understand the implications.

They require a different support construct, with gradually increasing support costs. On the other hand, this also means that organisations can delay refresh costs,” says van Schalkwyk, and points out that ageing networks are unlikely to support initiatives such as software-defined networking and automation, or handle traffic volumes necessary for collaboration or cloud.

According to the Report, in Europe, Asia-Pacific, and Australia enterprises’ network age reduced in line with the global average, while in the Americas, the number of ageing and obsolete devices decreased much faster, from 60% in the 2015 Report to 29% in the 2016 Report.

This can be attributed to the release of pent-up spend following four years of financial constraint.
Van Schalkwyk said clients in the Americas appear to be refreshing networks with the new generation of programmable infrastructure.
In Asia-Pacific and Australia, equipment refresh occurred as part of data centre network redesigns.

In contrast to the global trend, in Middle East and Africa, the network age increased, possibly the result of economic uncertainty, particularly in South Africa.

Meanwhile, of the 97,000 network devices that Dimension Data discovered, the number of devices that have at least one known [1]security vulnerability increased from 60% in the 2015 Report to 76% in the 2016 Report – the highest figure in five years.

In Europe the rise in network vulnerabilities has been very steep over the last three years, hiking from 26% in 2014 to 51% in 2015 and to 82% in the 2016 Report. Network vulnerability has also risen in organisations in the Middle East and Africa over the last three years.
In Australia, 87% of network devices have at least one known vulnerability.
In Asia-Pacific and the Americas, networks are slightly less vulnerable - respectively 49% and 66%, compared to 61% and 73% in the previous edition.

Other highlights in the 2016 Network Barometer Report include:

  • The percentage of devices supporting IPv6 rose steeply from 21% last year to 41% this year, due to the increase in current devices in networks.

    This allows organisations with newer networks to support their digitisation strategies by enabling connectivity for the Internet of Things, big data, analytics, and containerisation.
  • Software-defined networking is coming soon, but not just yet. While there is market interest in software-defined networks, it’s early in the adoption cycle and today, few organisational networks are capable of supporting a software-defined approach.
    In 2015 less than 0.4% of devices could support software-defined WAN and only 1.3% of data centre switches were SDN-ready.
  • Incident response is 69% faster, and repair time 32% faster networks monitored by Dimension Data.
    These numbers reduce by a further 55% and 36% respectively, when combined with Dimension Data’s service desk integration.
  • 37% of incidents are caused by configuration or human error, which can be avoided with proper monitoring, configuration management, and automation.

[1] A security advisory is a notice issued by a manufacturer that they are aware of a security vulnerability on one of their products.

Follow us on

About Dimension Data
Dimension Data uses the power of technology to help organisations achieve great things in the digital era.

As a member of the NTT Group, we accelerate our clients’ ambitions through digital infrastructure, hybrid cloud, workspaces for tomorrow, and cybersecurity. With a turnover of USD 7.5 billion, offices in 58 countries, and 31,000 employees, we deliver wherever our clients are, at every stage of their technology journey. We’re proud to be the Official Technology Partner of Amaury Sport Organisation, which owns the Tour de France, and the title partner of the cycling team, Team Dimension Data for Qhubeka.
Visit us at http://www.dimensiondata.com

For more information
Charlotte Martin / Jonathan Mathias
Finn Partners
020 3217 7060

10 decisions you'll face when deploying a honeypot

Honeypots provide the best way I know of to detect attackers or unauthorized snoopers inside or outside your organization. For decades I've wondered why honeypots weren't taking off, but they finally seem to be reaching critical mass.
I help a growing number of companies implement their first serious honeypots -- and the number of vendors offering honeypot products, such as Canary or KFSensor, continues to grow. If you're considering a honeypot deployment, here are 10 decisions you'll have to make. 1. What's the intent? Honeypots are typically used for two primary reasons: early warning or forensic analysis.
I'm a huge proponent of early-warning honeypots, where you set up one or more fake systems that would immediately indicate maliciousness if even slightly probed. Early-warning honeypots are great at catching hackers and malware that other systems have missed. Why? Because the honeypot systems are fake -- and any single connection attempt or probe (after filtering out the normal broadcasts and other legitimate traffic) means malicious action is afoot. The other major reason companies deploy honeypots is to help analyze malware (especially zero days) or help determine the intent of hackers. In general, early-warning honeypots are much easier to set up and maintain than forensic analysis honeypots. With an early-warning honeypot, when you detect a probe or connection attempt, the mere connection attempt gives you the information you need, and you can follow the probe back to its origination to begin your next defense. Forensic analysis honeypots, which can capture and isolate the malware or hacker tools, are merely the beginning of a very comprehensive analysis chain.
I tell my customers to plan on allocating several days to several weeks for each analysis performed using a honeypot. 2. What to honeypot? What your honeypots mimic is usually driven by what you think can best detect hackers earliest or best protect your "crown jewel" assets. Most honeypots mimic application servers, database servers, web servers, and credential databases such as domain controllers. You can deploy one honeypot that mimics every possible advertising port and service in your environment or deploy several, with each one dedicated to mimicking a particular server type.
Sometimes honeypots are used to mimic network devices, such as Cisco routers, wireless hubs, or security equipment. Whatever you think hackers or malware will most likely to attack is what your honeypots should emulate. 3. What interaction level? Honeypots are classified as low, medium, or high interaction. Low-interaction honeypots only emulate listening UDP or TCP ports at their most basic level, which a port scanner might detect.

But they don't allow full connections or logons. Low-interaction honeypots are great for providing early warnings of malicious behavior. Medium-interaction honeypots offer a little bit more emulation, usually allowing a connection or logon attempt to appear successful.

They may even contain basic file structures and content that could be used to fool an attacker. High-interaction honeypots usually offer complete or nearly complete copies of the servers they emulate.

They're useful for forensic analysis because they often trick the hackers and malware into revealing more of their tricks. 4. Where should you place the honeypot? In my opinion, most honeypots should be placed near the assets they are attempting to mimic.
If you have a SQL server honeypot, place it in the same datacenter or IP address space where your real SQL servers live.
Some honeypot enthusiasts like to place their honeypots in the DMZ, so they can receive an early warning if hackers or malware get loose in that security domain.
If you have a global company, place your honeypots around the world.
I even have customers who place honeypots that mimic the CEO's or other high-level C-level employees' laptops to detect if a hacker is trying to compromise those systems. 5.

A real system or emulation software? Most honeypots I deploy are fully running systems containing real operating systems -- usually old computers ready for retirement. Real systems are great for honeypots because attackers can't easily tell they're honeypots. I also install a lot of honeypot emulation software; my longtime favorite is KFSensor.

The good ones, like KFSensor, are almost "next, next, next" installs, and they often have built-in signature detection and monitoring.
If you want low-risk, quick installs, and lots of features, honeypot emulation software can't be beat. 6. Open source or commercial? There are dozens of honeypot software programs, but very few of them are supported or actively updated a year after their release.

This is true for both commercial and open source software.
If you find a honeypot product that's updated for longer than a year or so, you've found a gem. Commercial products, whether new or old, are usually easier to install and use. Open source products, like Honeyd (one of the most popular programs) are usually much harder to install, but often far more configurable. Honeyd, for example, can emulate nearly 100 different operating systems and devices, down to the subversion level (Windows XP SP1 versus SP2 and so on), and it can be integrated with hundreds of other open source programs to add features. 7. Which honeypot product? As you can tell, I'm partial to commercial products for their feature sets, ease of use, and support.
In particular, I'm a fan of KFSensor. If you choose an open source product, Honeyd is great, but possibly overly complex for the first-time honeypot user.
Several honeypot-related websites, such as Honeypots.net, aggregate hundreds of honeypot articles and link to honeypot software sites. 8. Who should administer the honeypot? Honeypots are not set-and-forget it solutions -- quite the opposite. You need at least one person (if not more) to take ownership of the honeypot.

That person must plan, install, configure, update, and monitor the honeypot.
If you don't appoint at least one honeypot administrator, it will become neglected, useless, and at worst, a jumping-off spot for hackers. 9. How will you refresh the data? If you deploy a high-interaction honeypot, it will need data and content to make it look real.

A one-time copy of data from somewhere else isn't enough; you need to keep the content fresh. Decide how often to update it and by what method. One of my favorite methods is to use a freely available copy program or a copy commands to replicate nonprivate data from another server of a similar type -- and initiate the copy every day using a scheduled task or cron job.
Sometimes I'll rename the data during the copy so that it appears more top secret than it really is. 10. Which monitoring and alerting tools should you use? A honeypot isn't of any value unless you enable monitoring for malicious activity -- and set up alerts when threat events occur.

Generally, you'll want to use whatever methods and tools your organization routinely uses for this.

But be warned: Deciding what to monitor and alert on is often the most time-consuming part of any honeypot planning cycle.

Internet of Things Devices Used to Boost Scale of DDoS Attacks

NEWS ANALYSIS: More than a million security cameras, video recorders and other devices were used in attacks on a U.S. security researcher and French network service provider. For the past several days, security researcher Brian Krebs has been battling a cyber-attack on a scale unlike any ever previously observed on the internet.Krebs, who writes the security blog Krebs on Security, was on the receiving end of a distributed denial-of-service (DDoS) attack that delivered connection requests at the rate of nearly 700 gigabits per second.

Equally alarming, the attack was generated by well over a million video cameras as well as other internet-connected devices ranging from set-top boxes to video recorders.This is the first time network-connected devices have been used in such a massive attack, although it's worth noting that smart devices, especially laser printers, have been used to launch malware attacks for several years.

And although this is also not the first time video cameras have been used as part of a DDoS attack, it is the first time they have been marshaled for an attack on this scale.Krebs has said that he was attacked in retaliation for a story he reported about an Israeli attack-for-hire service called "vDOS" that was earning its operators hundreds of thousands of dollars per year.

After the story appeared on Krebs' blog, the principals of the company were arrested, fined and placed under house arrest.

Apparently the internet of things (IoT) attack on Krebs was done to prove that vDOS still had teeth. Since then, Krebs has moved his website to the protection of Google's Project Shield, which was created to protect human rights advocates and journalists from censorship by DDoS. Previously Krebs was protected by the Akamai content delivery service, but that company dropped him because handling the attacks was costing Akamai millions of dollars and Krebs was getting the service for free. The attack on Krebs highlights the growing security problem of the IoT. Unfortunately, while the problem has been growing for years, very little has been done to address the threat. Worse, very few organizations have taken any steps to develop a protocol for making sure that devices that connect to the internet are secure.

Adding to the problem is the fact that there's little indication that once acquired, the devices are kept secure through proper management and timely updates.The security cameras that were used in the attack on Krebs were mostly produced by Dahua Technology, which produces a wide variety of cameras used both in businesses and by consumers.

These cameras are typically delivered with a default user name and password, and relatively few customers change the passwords before installation.

Even fewer of these devices are ever updated once they're installed. While Dahua products were used in this attack, the company is not unique in how it delivers its products.
Very few connected devices have any security beyond a simple name and password, and quite a few don't even have that.
If you want a picture of how bad this problem is, just turn on a WiFi device in a crowded area and look at the list of SSIDs. Note how many are simply the name of the company that made the product.There are several things your organization can do to reduce the chance of your assets being used in a DDoS attack and that in turn will help you avoid any liability, and any expense for the traffic your network devices may generate. Here's a list to get you started:1. Develop and enforce a protocol for any network-connected device that enters your organization to ensure that it gets a secure name and password, is set up for secure WiFi and gets on the list of devices that need regular updates.2. Set your routers and firewalls to reject any attempt by your network devices to communicate outside of your internal network unless there's a legitimate need. Print servers, for example, probably don't need to have access to the internet.3. Make sure your intrusion protection system is set to scan for unauthorized devices and check to see if your firewall is set to trigger alerts when devices attempt to reach the internet.4. Confirm that any new devices that come into your organization will support your security requirements, including the ability to support secure WiFi.5. Where possible, try to use wired networking rather than WiFi.Perhaps most important, make sure your security staff knows that they have to remain vigilant for the introduction of new, insecure devices on to your network and realize that those devices can be attached to your network in seconds by nearly anyone in your company.

Those new devices will probably be insecure and the people installing them won't be in a hurry to tell you about them.The devices on your network, whether they're intended to help you stay secure or simply intended to make your life easier, have a great potential to help, but they have an equally great potential to endanger your organization. You can limit the security risks by watching what those devices are up to, but only if you have a plan for handling them in the first place. 

The Secret Behind the NSA Breach: Network Infrastructure Is the Next...

How the networking industry has fallen way behind in incorporating security measure to prevent exploits to ubiquitous routers, proxies, firewalls and switches. Advanced attackers are targeting organizations’ first line of defense--their firewalls—and turning them into a gateway into the network for mounting a data breach. On August 13, the shady “Shadow Brokers” group published several firewall exploits as proof that they had a full trove of cyber weapons. Whether intended to drive up bids for their “Equation Group Cyber Weapons Auction” (since removed), or to threaten other nation states, the recent disclosure raises the question: if organizations can’t trust their own firewalls, then what can they trust? Does the cache of cyber weapons exposed by Shadow Brokers signal a shift in attack methods and targets? We analyzed the dump and found working exploits for Cisco ASA, Fortinet FortiGate and Juniper SRX (formerly NetScreen) firewalls.

The names of the exploits provided by the Shadow Brokers match the code names described in Edward Snowden’s 2013 revelations of NSA snooping. The exploit names are not the only link to the NSA.

By analyzing the implementation of a cryptographic function, researchers at Kaspersky have found the same encryption constant used in malware attributed to the Equation Group (Kaspersky’s nickname for the NSA) and python code in the latest breach. Cyber Attacks with a Side of EXTRABACONResearching one of the Cisco ASA exploits (dubbed EXTRABACON) in our lab, we found that it’s a simple overflow using SNMP read access to the device.

The additional payload bundled with the exploit removes the password needed for SSH or telnet shell access, providing full control over the appliance.

The payload can also re-enable the original password to reduce the chance that the attacker will be detected. The python code handles multiple device versions and patches the payload for the version at hand.

This indicates the amount of operations the group had in the past as the developers probably modified the exploit on a case-by-case basis. We ran the exploit against a supported version of a Cisco ASA in our lab multiple times and it didn’t crash once, showing the prowess of the exploit developers. Our attempt yielded a shell without password protection: Networking Equipment in the CrosshairsWhile the exploits themselves are interesting in their own right, no one is addressing the elephant in the room: attackers increasingly target network infrastructure, including security as a means to infiltrate networks and maintain persistence. While the entire cybersecurity industry is focused on defending endpoints and servers, attackers have moved on to the next weak spot.

This advancement underscores the need to detect active network attackers because they can certainly—one way or another—penetrate any given network. Persisting and working from routers, proxies, firewalls or switches requires less effort than controlling end points; attackers don’t need to worry that an anti-virus agent will detect an unusual process, and networking devices are rarely updated or replaced. Most networks have the same routers and switches from a decade ago. Plus, few forensics tools are available to detect indicators of compromise on networking devices and attackers can gain an excellent vantage point within the network.  Network devices vendors have fallen behind operating system vendors in terms of implementing stronger security measures.

A wide range of networking equipment still run single-process operating systems without any exploit mitigation enabled (Cisco IOS, I’m looking at you) or exhibit the effects of little to no security quality assurance testing.
In recent years, endpoint and mobile operating systems have incorporated security techniques such as address space layout randomization (ASLR), data execution prevention (DEP), sandboxes, and other methods that made life harder for every exploit writer.

The affected networking devices provide none of these security mechanisms and it shows. Not the First and Definitely Not the LastThe Equation Group breach is not the first example of highly capable attackers targeting network devices.

The threat actor behind last year’s Hacking Team breach leveraged a vulnerability in a VPN device to obtain full access to their internal network without any obstacles.

The attacker moved from the networking device to endpoints without using a single piece of malware, only taking what he needed from endpoints remotely or running well known administrative tools.

This is a soft spot in every endpoint solution’s belly; a privileged attacker using credentials to access files is not considered malicious as long he doesn’t use any malicious software. Notice that as we have stated earlier, the attacker, quoted in pastebin, opted for an embedded exploit and not the other options, stating that it’s the easiest one: So, I had three options: look for a 0day in Joomla, look for a 0day in postfix, or look for a 0day in one of the embedded devices.

A 0day in an embedded device seemed like the easiest option, and after two weeks of work reverse engineering, I got a remote root exploit.
As always, nation state attacks are usually a step ahead of the entire industry on both the defensive and offensive. We will probably see the same methods employed by less sophisticated attackers as it becomes increasingly difficult to compromise endpoint devices and stay undetected. We have seen this happen before; cybercrime attackers stole techniques from Equation Group, as well as Stuxnet and Flame malware and Reign and other APTs and it will surely happen again with the Equation Group’s recently leaked exploits. In the meantime, here are four recommendations to help fortify network devices against attack: Recommendation 1: Patch your network devices promptly. Replace network devices that have reached their end of support date. Recommendation 2: Restrict access to devices management addresses to the minimum required, and block any unneeded, seemingly benign protocols including SNMP and NTP. Recommendation 3: Manage your device passwords as you would with your administrator accounts by periodically changing your passwords and defining a different password for each device.

Do not use a standard template for passwords.

For example, the password Rout3rPassw0rd192.168.1.1 might seem strong, but after compromising one device, the attacker will know all of the passwords. Recommendation 4: Deploy a network monitoring solution that can profile users and IP-connected devices to establish a baseline of normal behavior and then detect unusual activity originating from network devices.

Attackers have no way of knowing what “normal” looks like for any given network and network detection is the only generic way to stop attackers from compromising network devices. Related Content:   Yoni Allon is responsible for leading the LightCyber research team in monitoring and researching cybercriminal and cyberwarfare actions and ensuring that the LightCyber Magna platform accurately finds these behaviors through its detectors and machine learning. Mr.

Allon has ...
View Full Bio More Insights

FalseCONNECT sends vendors scrambling to patch proxy MITM bug

Protocols pwned, but patches parachuted for many popular platforms For the many people that dislike corporate proxies, this probably won't be much of a surprise: a bunch of environments are vulnerable to man-in-the-middle attacks. “FalseCONNECT” is a combination of protocol bug and implementation error – which means it affects end users via operating systems, as well as network devices. The problem is in how two Web protocols interact: HTTP CONNECT (which asks a firewall or proxy to forward a connection, described in RFC 7230), and HTTP Authentication (described in RFC 7235), which the firewall or proxy use to ask users to authenticate. The discoverer, Jerry Decime, explains FalseCONNECT here. If an attacker can see users' requests to connect (for example, via a rogue wireless access point), they can replace the proxy's OK message (expected under RFC 7230) with “407 Proxy Authentication Required” message – and grab the victim's credentials. Here's some detail from the US CERT advisory about this mess: “HTTP CONNECT requests and 407 Proxy Authentication Required messages are not integrity protected and are susceptible to man-in-the-middle attacks. WebKit-based applications are additionally vulnerable to arbitrary HTML markup and JavaScript execution in the context of the originally requested domain.” This is a potent attack, because the user's browser can then go ahead and establish their “trusted” connection via the proxy.

The victim won't get anything like a browser warning to tell them something's wrong. And because it happens before the handshakes set up trust, it doesn't trip warnings like pinned certificates. “This vector happens before the server public key can be provided to the client as shown in step five, but not before a trust relationship has already been established or maintained by the browser or application as shown in step one,” Decime writes. “Unfortunately this implementation resulted in false trust situations whereby untrusted code delivered in the response body of the CONNECT could execute within trusted browser and application states.” Who's affected? So far, the CERT advisory lists Apple, Microsoft, Opera, and Oracle as affected. Lenovo reckons its machines aren't affected. Ten other vendors and systems are on the notice but are still working out whether they're vulnerable: Arista, Belkin, CentOS, Cisco, CoreOS, Debian, DesktopBSD, DragonFly BSD, EMC and F5 Networks. Others will, we expect, be added to that list as time passes. Decime's post concentrates on how the bug can be exploited against iOS, because of how WebKit handles the CONNECT / 407 interaction. He notes that the attack code leaves out the header that the 407 message should include, because that would risk tipping the user off: “On iOS, WebKit renders the markup provided in a '407 Proxy Authentication Required.' This allows a proxy server that requires authentication to give the user a soft-error after a certain number of failed authentication attempts, but because the contents of the HTTP response are rendered within a trust realm, it can be used to attack cryptography trust in WebKit.” Apple has fixed the bug in the iOS 9.3.3 update and in El Capitan's 10.11.6 update. ® Sponsored: Global DDoS threat landscape report

Industrial cybersecurity threat landscape

 Download ICS availability statistics (PDF version)  Download ICS vulnerabilities statistics (PDF version) Overview Industrial control systems (ICS) surround us: they are used in electric, water and wastewater, oil and natural gas, transportation, chemical, pharmaceutical, pulp and paper, food and beverage, and discrete manufacturing (e.g., automotive, aerospace, and durable goods).
Smart cities, smart houses and cars, medical equipment – all of that is driven by ICS. Expansion of the Internet makes ICS easier prey to attackers.

The number of ICS components available over the Internet increases every year.

Taking into account that initially many ICS solutions and protocols were designed for isolated environments, such availability often provides a malicious user with multiple capabilities to cause impact to the infrastructure behind the ICS due to lack of security controls. Moreover, some components are vulnerable themselves.

The first available information about vulnerabilities in ICS components is related to 1997, only two vulnerabilities were published that year.
Since then the number of vulnerabilities significantly increased. Over the past five years this index has increased from 19 vulnerabilities in 2010 to 189 vulnerabilities in 2015. Sophisticated attacks on ICS systems are not somewhat new anymore.
It is worth remembering an incident in 2015 in Ivano-Frankivsk, Ukraine where around a half of houses were left without electricity because of a cyber-attack against the Prykarpattyaoblenergo power company, and it was only one of multiple victims of the BlackEnergy APT campaign. Another notable incident, happened in 2015 and described in Verizon Data Breach Digest, is an attack on Kemuri Water Company’s ICS infrastructure, when intruders infiltrated a water utility’s control system and changed the levels of chemicals being used to treat tap water.

The intrusion was performed through a vulnerable externally available system, that managed programmable logic controllers (PLCs) regulating valves and ducts that controlled the flow of water and chemicals used to treat it through the system. Also in 2015 there were other ICS-related incidents, such as attacks on a steel mill in Germany and on the Frederic Chopin Airport in Warsaw. In this research we provide an overview of the current situation with ICS security worldwide from the point of view of vulnerabilities, and vulnerable ICS components exposed to the Internet. Analysis Approach The research is focused on two areas: Vulnerabilities and ICS Availability over the Internet.
Vulnerabilities information gathering was carried out based on open sources, such as Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) advisories, NVD/CVE, SCADA Strangelove, Siemens Product CERT and other information available online.
Severity levels for the vulnerabilities were assessed based on a Common Vulnerability Scoring System (CVSS) of the versions 2 and 3.

CVSS v2 was used to compare vulnerability statistics in the years 2014 and 2015, and it was also used for any vulnerabilities that didn’t have CVSS v3 score assigned. In the second part of research results (ICS Availability over the Internet) we used a passive approach for analysis based on information from the Shodan search engine.

To identify ICS systems in Shodan search we used a fingerprint knowledgebase, containing about 2000 records and allowing to identify product vendors and versions by banners. Main Findings The number of vulnerabilities in ICS components keeps growing. With increased attention to ICS security over the last several years, more and more information about vulnerabilities in these systems is becoming public. However, vulnerabilities themselves could be present in these products for years before they are revealed.
In total, 189 vulnerabilities in ICS components were published in 2015, and most of them are critical (49%) or have medium severity (42%). ICS vulnerabilities by year Vulnerabilities are exploitable. For 26 of the vulnerabilities published in 2015, exploits are available.

Besides, for many vulnerabilities (such as hard-coded credentials) an exploit code is not needed at all to obtain unauthorized access to the vulnerable system. Moreover, our ICS security assessment projects show that ICS are often considered by their owners as a “black box”, so default credentials in ICS componenets are often not changed and could be used to gain remote control over the system.

The SCADAPASS project of the SCADA Strangelove team provides a representation of known default ICS credentials.

Currently information on 134 ICS components of 50 vendors is available. ICS vulnerabilities in 2015 by risk level (CVSS v.2 and CVSS v.3) ICS vulnerabilities are widely diversified. New vulnerabilities were found in 2015 in the ICS components of different vendors (55 different manufacturers) and types (HMI, electric devices, SCADA, industrial network devices, PLCs and multiple others).

The largest amount of vulnerabilities were found in Siemens, Schneider Electric and Hospira devices.
Vulnerabilities in ICS components have a different nature.

The most widespread types are buffer overflows (9% of all detected vulnerabilities), use of hard-coded credentials (7%) and cross-site scripting (7%). Not all of the vulnerabilities found in 2015 are fixed. Patches and new firmware are available for 85% of the published vulnerabilities, the rest are not fixed or are only partially fixed for different reasons. Most of the unpatched vulnerabilities (14 out of 19) are of high level risk.

These unpatched vulnerabilities pose significant risk to the owners of the corresponding systems, especially for those who, due to inappropriate network configuration management, have their vulnerable ICS systems exposed to the Internet.

Examples include the 11,904 remotely available SMA Solar Sunny WebBox interfaces that are under risk of compromise though hard-coded passwords.

Although for Sunny WebBox this number has significantly reduced since 2014 (when over 80 thousand available components were found), the amount is still high, and the unfixed hardcoded credentials issue (published in 2015) is now putting these systems under a much higher risk than was previously thought. ICS patching Numerous ICS components are available via the Internet. 220,668 ICS components were discovered by the Shodan search engine.

They are located on 188,019 hosts in 170 countries. Most of the remotely available hosts with ICS components are located in the United States (30.5%) and Europe.

Among European countries Germany has a leading position (13.9%) followed by Spain (5.9%).

The available systems are of 133 different vendors.

The most widespread ones are Tridium (11.1%), Sierra Wireless (8.1%), and Beck IPC (6.7%). TOP 20 countries by ICS availability Insecure protocols are widely used by remotely available ICS components. There is a number of protocols, which are open and insecure by design, such as HTTP, Niagara Fox, Telnet, EtherNet/IP, Modbus, BACnet, FTP, Omron FINS, Siemens S7 and many others.

They are used on 172,338 different hosts, which corresponds to 91.6% of all the externally available ICS devices found.

This provides an attacker with additional ways to compromise the devices by performing man-in-the-middle attacks. TOP 15 protocols used by externally available ICS components Multiple vulnerable ICS components are externally available. We found 13,033 vulnerabilities on 11,882 hosts (6.3% of all hosts with externally available components).

The most widespread revealed vulnerabilities are Sunny WebBox Hard-Coded Credentials (CVE-2015-3964), and critical vulnerabilities CVE-2015-1015 and CVE-2015-0987 in Omron CJ2M PLC.

Combining these results with statistics of usage of insecure protocols, we were able to estimate the total number of vulnerable ICS hosts as 172,982 (92%). TOP 5 vulnerabilities on ICS components Multiple industries are affected. We found that at least 17,042 ICS components on 13,698 different hosts in 104 countries likely belong to large companies, and availability of these components from the Internet is likely related with significant risks.

Among owners we were able to identify 1,433 large organizations, including ones belonging to the following industries: electricity, aerospace, transportation (including airports), oil and gas, metallurgy, chemical, agriculture, automotive, utilities, drinks and food manufacturing, construction, liquid storage tanks, smart cities, and ICS vendors.

There are also research and education entities, government institutions (including police), medical centers, financial organizations, resorts, hotels, museums, libraries, churches and multiple small businesses among identified owners of remotely available ICS.

The number of vulnerable externally available ICS hosts, which likely belong to large organizations, is 12,483 (91.1%), where 453 hosts (3.3%), including hosts belonging to energy, transportation, gas, engineering and manufacturing organizations, drink and foods manufacturing, energy and transportation organizations, contain critical vulnerabilities. ICS availability by vendor The above results are only lower bound estimations, and real number of available ICS components associated with significant risks could be much higher. Conclusion Where protection is concerned, the isolation of critical environments can no longer be regarded as a sufficient security control for ICS.

The business requirements of the 21st century often make it necessity to integrate ICS with external systems and networks.
In addition, the capabilities, motivations and number of threat actors focusing on ICS environments are increasing.

From infected hard drives or USB sticks, to unauthorized connections from ICS networks to the Internet through personnel smart phones or modems, and from infected distributive kits obtained from vendors, to a hired insider – all of these methods are available to highly-skilled intruders planning an attack on a physically and logically isolated ICS network. Nowadays, ICS owners should be aware of modern vulnerabilities and threats, and actively improve the security of their ICS environments based on this knowledge. Here, active vendor support is crucial for the prompt identification and remediation of vulnerabilities in ICS products, as well as for sharing workarounds to protect systems before patches are released. The specifics of ICS – that its cybersecurity is closely tied with physical safety – often receives an attitude opposite to the demandable treatment in such conditions.
Small and medium businesses, as well as individuals, completely rely on vendors when it comes to security of the Internet of Things.

The consumers don’t go beyond simple basic steps from device manuals, thus obtaining ready-to-work and easily accessible, but also vulnerable devices. On the contrary, in the enterprise area, companies understand the high risks, which are related with incorrect configuration of ICS environment. However, because of that system owners often consider ICS devices as “black-boxes”, and have a dread to make changes in the environment, including cybersecurity enhancement. The findings of this research are an additional reminding that the “Security through Obscurity” principle cannot serve as a good basis to achieve effective protection from modern attacks, and that industrial control systems security should not be treated superficially in favor of safety, especially because the security and safety in this area are inextricably connected.

Not so fast: Some security defaults shouldn't change

There's an old security mantra that says "always change the defaults!" Although this seems like a good general rule, in fact it's true only for certain kinds of settings.

Changing the defaults in other cases will just end up biting you in the end with ...