text: ENISA is a Centre of Expertise in Network and Information Security in Europe

text: www.enisa.europa.eu individual discussions with experts. Additionally, the guide is based on a desk top research done for a number of non EU countries demonstrated expertise and knowledge in the area.

text: www.enisa.europa.eu recommend the establishment of such a strategic public private partnership with major stakeholders.

identifier: FAQ on NSIE

nummer: faq-on-nsie

publisher: Europeiska unionens cybersäkerhetsbyrå

sprak: en

title: FAQ on NSIE

serie: rapporter

text: FAQs to the report on ”Good Practice Guide Network Security Information Exchanges ”

type: stycke

text: FAQs to the report Good Practice Guide Network Security Information Exchanges

type: rubrik

text: What is the background to this report?

text: This report is a part of ENISA’s Multi-annual Thematic Program One (MTP 1), Resilience of Public e-Communication Networks. With this Program the Agency, among others, takes stock of and analyses Member States regulatory and policy environments related to resilience of public e-Communication Networks.

text: The report also contributes to European Commission (or EU) strategy of Critical Information Infrastructure Protection (CIIP) . This strategy calls for wide deployment of national ‘Network Security Information Exchanges’ (NSIEs) and the creation of a pan European Public Private Partnership for Resilience. An NSIE is a form of strategic partnership among key public and private stakeholders aiming at sharing information on a particular field of discussion.

text: Member States are strongly interested in better understanding and deploying the concept of information sharing using an information exchange model. They requested ENISA to develop a good practice guide based on observed practices of existing information exchanges.

text: What is the aim of the guide?

text: The aim of this Guide, for those countries who do not operate an NSIE, is to assist network communication stakeholders and public bodies in national governments to set up and run an NSIE as a public/private sector partnership. For those countries, which already operate an NSIE, the aim is to provide an insight into other countries’ good practice, to support continuous improvement and common approaches/practices.

text: A longer-term aim for this Guide is to support the development of common approaches and policies for information exchange and facilitate working relationships and understanding between each country’s NSIEs. Hopefully the guide will also pave the way for an accelerated deployment of national NSIE and consequently of the establishment of a pan European information sharing platform.

text: How was this report conducted?

text: The content of the guide represents the aggregation of good practices from a number of countries having significant expertise and knowledge in the area and

text: What does NSIE mean?

text: . An NSIE is a form of a strategic partnership among key public and private stakeholders aiming at sharing information on threats, vulnerabilities and risks related to communication networks and their applications or services.

text: The drivers for this information exchange are the benefits of members working together on common problems and gaining access to information, which is not available from any other source. NSIE is an excellent vehicle to: - better understand a changing security and resilience environment - learn in a holistic manner about intrusions, vulnerabilities and threats - develop recommendations for mitigating vulnerabilities, threats, & attack methods - jointly develop methods to continuously assess existing measures - provide unique insights and strategic views to policy makers and strategists.

text: What are the common characteristics of an NSIE?

text: The following list shows some of the common characteristics of an NSIE. • The most effective size of a sharing group is between 20 and 30 • Regular, face-face meetings to establish and further enhance trust • The Government’s role is instrumental in setting up and running an NSIE together with industry • An NSIE addresses strategic issues (e.g. major/critical disruptions) rather than operational ones • Participation is free of charge • New members require the unanimous agreement of existing members • Most existing NSIE’s are jointly chaired by a representative from the government and a representative from industry • An NSIE should provide with incentives their members to participate • An NSIE should respect members commercial sensitivities related to the disclosure of information to competitors and/or regulators • Emphasis is on information exchange, not on information transfer • High level security experts usually participate in NSIEs

text: What is really shared?

text: This is some of the information that is shared within an NSIE • Experience and information on threats, risks, impact, vulnerabilities, incidents, counter measures • Advisory support and warnings in implementing joint, sector wide, protective good practice measures • Experience and information on: contingency planning crisis management analysis & mitigation of threats, risks, incidents, dependencies • Information on emerging trends and changing environments • Information on exercises, on methodologies and scenarios for conducting them.

text: How do you plan for and setup an NSIE?

text: For those new to NSIEs, a section in the report describes what an NSIE looks like in terms of its characteristics and features based on observed examples of NSIEs. Before looking in detail at good practice for setting up and running an NSIE, it is useful to look at the overall concept. At a high level, several NSIEs have drawn up mission statements with a view to specifying clearly and succinctly what the NSIE is and what it aspires to be. It is a good idea to involve as many stakeholders as possible in producing and refining the mission statement, and this helps develop a sense of ownership and responsibility.

text: With an understanding of the characteristics of an NSIE and an understanding of the environment in which it will operate, the report describes the specific elements of an NSIE, such as membership, building trust in an NSIE, focus on relevant value add services, interfaces with an NSIE, funding and costs, legal considerations and information inputs and outputs.

text: When you are convinced of the need for an NSIE, and you are aware of its vital components, you need to think about the practical strategies that you can use to get your NSIE up and running. One section in the reports looks at these strategies, which are presented as a set of action points.

text: Was there a need for a good practice guide?

text: ENISA’s Resilience Program on the resilience of public e-Communication networks performed stock taking and analysis of Member States’ policy and regulatory environments. The analysis of the stock taking findings revealed the importance of good practices in numerous areas including information sharing exchanges.

text: Information Exchanges is an under explored concept in Europe, as well as other parts of the world but countries that have long experience in this area strongly

text: How is the guide structured?

text: Within the guide, issues and good practices are described within the various sections, using short quotes, presented in italics, from various sources to validate the points being made.

text: At suitable stages, observed good practices are highlighted to aid the reader of the guide make a choice whether the observed good practice is relevant to their own environment and need. These observed good practices are presented in a text box.

text: Who is this report for?

text: The main audience for this Guide is public and private sector stakeholders who operate and/or use communication networks and information systems and have responsibilities for infrastructure resilience matters.

text: Specifically, this guide will be useful for individuals and organisations who have an interest in setting up and running a Network Security Information Exchange, or who are looking for ways to enhance existing NSIEs.

text: For full report:

text: More information on the Resilience Program:

text: For further details, contact:

text: Dr. Vangelis OUZOUNIS, ENISA Senior Expert - IT Security Policies Technical Department, Evangelos.Ouzounis@enisa.europa.eu Ulf Bergstrom, Press & Communications Officer ENISA, press@enisa.europa.eu, Mobile: +30 6948 460143

type: vagledning

utgivare: enisa


text: PO Box 1309, 71001 Heraklion, Greece, Tel: +30 2810 391 280, Fax: +30 2810 391 410 www.enisa.europa.eu

identifier: Flash Note: Can Recent Attacks Really Threaten Internet Availability?

text: 12/04/2013 www.enisa.europa.eu FN/02/2013

text: ENISA is recommending that Internet network providers implement long-known traffic filtering techniques, which could have countered a major cyber incident that hit services across western Europe last Month (March 2013) [1]. The incident was an attack mounted against the non-profit organisation Spamhaus [2], leading to noticeable delays for internet users mostly in the UK, Germany and other parts of Western Europe. Spamhaus, which is based in Geneva and London, contributes to the fight against spam by providing a service that enables operators of email servers to check if a sender’s email server is known to be sending unsolicited commercial email. Although no clear evidence exists, the attack on Spamhaus is generally attributed to a hosting provider who was flagged as a spam sender by Spamhaus. This incident highlights some important vulnerabilities of the internet infrastructure, but at the same time also demonstrate its inherent resilience.

text: DNS Amplification and Open Resolvers

text: The attack on Spamhaus was dubbed by online media as the biggest Distributed Denial of Service (DDoS) th attack ever seen [3]. Spamhaus started experiencing a significant DDoS attack on its servers on 16 March. The attack spanned a period of more than one week and happened in three phases: first, the attack was directed at Spamhaus, then at CloudFlare, a service provider contracted by Spamhaus to deal with the attack, and finally at CloudFlare’s network providers. In this last stage of the attack, the enormous amount of traffic generated by the attack caused problems at the London Internet Exchange. The technique used for the DDoS attack is by no means new. The method used by the attackers to generate the traffic directed at the Spamhaus network, DNS amplification, has been known for many years. It is made possible by the fact that today it is still possible for most internet-connected hosts to send IP packets with forged (“spoofed”) source addresses. Another factor contributing to the size of the DDoS attack is the large number of so-called “open recursive resolvers” in the internet. Open resolvers are Domain Name Service (DNS) servers which answer all requests sent to them, not just those related to the DNS domain for which they are authoritative resolvers. Open resolvers can be misused to amplify DDoS attacks [4]. Unfortunately, even today many network providers have not implemented a set of recommendations (called BCP38 [5]), which has been around for almost 13 years. If the available recommendations were implemented by all networks, traffic filtering on border routers would block such attacks. A similar set of recommendations for operators of DNS servers (called BCP140 [10]), which could help reduce the number of servers that can be misused for DNS amplification attacks, was published in 2008. However, today there are still thousands of servers that can be abused for this kind of attacks.

text: BGP Hijacking

text: At the same time as the DDoS attack, Spamhaus was also attacked using Border Gateway Protocol (BGP) route hijacking [6]. The aim of this particular attack was to hijack legitimate queries away from Spamhaus’s servers in order to disrupt their operation and reputation reporting so that every IP address on the internet was regarded as a source of spam [7].

text: Flash Note

text: The BGP is used by network operators to exchange information about the reachability of blocks of internet addresses. BGP hijackings can be accidental, but can also be used by attackers in various ways to disrupt or intercept a network’s traffic, essentially by pretending to provide a faster way to reach the victim’s network.

text: Lessons Learned

text: When looking at this incident, the question arises as to how much any particular geographical area or economic sector depends on certain network operators, internet exchanges, or physical infrastructure. There are a number of lessons that can be learned from this incident:  While the incident didn’t affect the internet on a global scale, the effects on a local scale were rather noticeable. It therefore serves as a reminder that while the internet overall can be considered resilient, it cannot be taken for granted that this is also true for the local part of the Internet infrastructure serving a particular region, or country.  Even disputes between private, non-state actors can have important effects on internet infrastructure, due to the high degree of interconnections and the cross-border nature of the internet.  Attacks are increasing in size. While the largest publicly reported DDoS attack up to 2012 had been around 100 Gigabits of data per second, the March 2013 attack on Spamhaus reached a size of more than 300 Gigabits per second [8].  At this size of attacks, the capacity of commercial internet exchanges, which normally have very high availability/capacity infrastructure, can be exhausted.  Currently there exists no widely agreed scheme to assess the impact of the factors that played a role in the attack, or of incidents related to the physical layer of the internet infrastructure. This makes it difficult to assess the associated risks.

text: It is also interesting to note that despite the size of the DDoS attack, there is no clear evidence as to its originators. For the BGP route hijacking, the situation is different because the corresponding route announcements are made “in public” and were recorded [6].

text: Recommendations by ENISA

text: The interdependencies of various components forming the foundations of the internet infrastructure, such as cables, datacentres, network operators, internet exchanges, are still not completely understood. The recent incident shows that there are still many steps that can be taken even in the short term, to improve the resilience of the internet infrastructure.  Operators serving as upstream or transit providers to end-customer networks should implement BCP38 [5].  Operators of DNS servers should check whether their servers can be misused in DNS amplification attacks and should implement BCP140 [10].  Operators of internet exchange points should consider that their infrastructure might be attacked directly and make sure that they have appropriate security measures in place.

text: Flash Note

text: ENISA will continue to investigate the area of network interconnections with the aim of providing policymakers, telecommunications regulators, cyber security agencies and network operators in European Union Member States with recommendations on how issues related to the resilience of the internet infrastructure in Europe can be addressed. For further information on the resilience aspects of the internet interconnection ecosystem see also ENISA’s Inter-X report [11] and the Computer Emergency Response Team Austria’s blog [12].

text: References [1] Spamhaus DDoS grows to Internet-threatening size

text: http://arstechnica.com/security/2013/03/spamhaus-ddos-grows-to-internet-threatening-size/ [2] Spamhaus project http://www.spamhaus.org/ [3] Global internet slows after 'biggest attack in history' http://www.bbc.co.uk/news/technology- 21954636 [4] Open DNS Resolvers Center Stage in Massive DDoS Attacks http://threatpost.com/en_us/blogs/opendns-resolvers-center-stage-massive-ddos-attacks-032813 [5] Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing http://tools.ietf.org/html/bcp38 [6] Looking at the spamhaus DDOS from a BGP perspective http://www.bgpmon.net/looking-at-thespamhouse-ddos-from-a-bgp-perspective/ [7] Spam? Not Spam? Tracking a hijacked Spamhaus IP https://greenhost.nl/2013/03/21/spam-notspam-tracking-hijacked-spamhaus-ip/ [8] Putting the Spamhaus DDoS attack into perspective http://www.arbornetworks.com/corporate/blog/4813-putting-the-spamhouse-ddos-attack-inperspective [9] ‘Biggest ever’ Internet attack is indeed huge, but it isn’t global http://venturebeat.com/2013/03/27/biggest-ever-internet-attack-is-indeed-huge-but-not-global/ [10]Preventing Use of Recursive Nameservers in Reflector Attacks http://tools.ietf.org/html/bcp140 [11]Inter‐X: Resilience of the Internet Interconnection Ecosystem http://www.enisa.europa.eu/activities/Resilience-and-CIIP/critical-infrastructure-and-services/inter-x [12]Lessons from the Stophaus/CloudFlare/Spamhaus DDoS for ISPs http://www.cert.at/services/blog/20130328190708-815_en.html

text: Flash Note produced by: Thomas Haeberlen, Expert in Network and Information Security, and Rossella Mattioli, Security and Resilience of Communication Networks Officer, ENISA

text: ENISA’s Flash Notes are issued by the Agency to draw the attention of the media and other interested parties to emerging issues in cyber security. The material contained in Flash Notes may be reproduced freely, provided the source is acknowledged.


text: Heartbleed - A wake-up call TLP GREEN | Info Note | Final | April 2014

text: © European Union Agency for Network and Information Security (ENISA), 2014 01

text: © European Union Agency for Network and Information Security (ENISA), 2014 02

text: © European Union Agency for Network and Information Security (ENISA), 2014 03

identifier: Flash Note: Heartbleed - A wake-up call

nummer: flash-note-heartbleed-a-wake-up-call

title: Flash Note: Heartbleed - A wake-up call

text: Heartbleed - A wake-up call

text: 1 Introduction

text: Last week the entire web discovered the existence of the so called “Heartbleed” vulnerability affecting one of most popular mechanisms used to secure communication with web sites. Starting with the first open announcements on 07th of April 2014, news about this security hole triggered the interest and concern of more or less everybody online. The publication created panic on the Internet due to its simplicity and efficiency. An attacker could remotely retrieve information from the memory of computers using the Transport Layer Security (TLS) features of OpenSSL, that is designed to provide authentication and encryption services for securing communication with web sites. This means that passwords, session cookies used in online authentication and private keys were potentially exposed for everyone to see, without the need for authentication.

text: As expected attackers started to try to find their way into vulnerable systems as soon as proof of concept tools exploiting the vulnerability were made available. Moreover as more information started to emerge, more impressively, it became clear that this vulnerability got unnoticed for almost 2 years putting under discussion the entire security life chain.

text: It also turned out that numerous, both commercial and non-commercial products, services and applications that utilise the faulty code could remain exposed to this vulnerability for an unknown period of time. The popularity of this specific implementation has led to the situation where pieces of this faulty code, even if labelled “open source”, may be implemented in closed projects, products, or applications, which could be unfixed for a longer period of time.

text: Even though some major advisories and patches were quickly made available. Announcement to users and customers by affected services or suppliers were not in all cases handled sufficiently and transparent. Cisco, Blue Coat, Tor, VMware, and many others, sent out communication to their customers. Other services and companies have not issued an advisory or a patch until today.

text: 2 The underlying mistake

text: (CAREFUL: some techie information ahead!)

text: The cause of the problem can be traced down to un-validated user input. Basically, the heartbeat feature of TLS is designed to keep a connection alive, one party in the communication provides arbitrary information and the other sends it back.

text: OpenSSL used a user-provided length field to allocate the memory buffer in which it copies the information provided by the initiating party. Unfortunately, there was no check if the ‘length’ field that was provided by the user was indeed the length of the data that was originally sent. When there was a mismatch between a small amount of data sent, but a big amount announced, OpenSSL then essentially returned information coming from the computer’s memory. This information could include passwords, session cookies used in online authentication and private keys without the need for authentication.

text: As simple as it can sound, the fix that was implemented consisted simply in adding this consistency check before allocating memory.

text: 3 Failure of the Quality Assurance process

text: The faulty code was submitted to the project by a volunteer programmer. As it is usual with open source projects, many programmers can submit code, but this code is then checked by maintainers who are responsible for Quality Assurance (QA). In this case, this process failed: the maintainer did not spot the bug, and the faulty code went live without notice.

text: The root cause is thus the combination of:

text: 1. A programming mistake by lack of validation of input submitted by users.

text: 2. In addition the use of insecure memory management routines, which is a problem caused by the development environment.

text: 3. A failure in the QA process.

text: 4 Other common programming mistakes

text: The Open Web Application Security Project (OWASP) ”Top programming mistakes” lists the most common programming mistakes. While it focuses mainly on web application programming, it still encompasses ”Unvalidated user input” even before other more famous mistakes such as ”faulty access control” and ”buffer overflows”. In 2014 we would expect that Quality Assurance and code review would avoid such simple vulnerabilities. Unfortunately major problems today include code injection, cross-site-scripting and –still – faulty authentication and session management.

text: 5 Recommendations

text: 5.1 Methodology

text: This problem could have been avoided by following programming guidelines that have been known for years, especially: all user input must be considered as untrusted until properly checked for consistency and validity. This is still nowadays a common programming mistake and points to a fundamental lack of security awareness on developer level. Our first recommendation is therefore to use secure development

text: methodologies and increase the awareness of developers about programming mistakes and how to

text: avoid them.

text: 5.2 Coding standards

text: The C programming language is the most used programming language for systems-level development. It exists since decades, was developed with performance in mind, not security. It does not protect the programmers against mistakes or unforeseen circumstances. Security is not a feature of the libraries provided by the language and its development environment. It is too easy to introduce mistakes into the code in small projects, and even easier in huge projects with millions of lines of code (and tight deadlines). Our second recommendation is to follow and enforce secure coding principles, like those proposed by CERT/CC and others.

text: 5.3 Quality assurance

text: Before source code is used in a product, or an application, it is strongly recommended to review and test the code, and if necessary to make security improvements, even if that would influence the publication date. This is also true for open source project, were a common motto is that “given enough eyeballs, all bugs are shallow”. The Heartbleed case shows that in practice, open source software, like any software, needs to go through well-defined quality assurance processes. Our third recommendation: any software project must include security in the whole development process.

text: 5.4 Vulnerability communication

text: The communication process regarding the Heartbleed vulnerability has been, and still is, too fragmented. Vendor response is not synchronised and does not always provide actionable information. Also the level of detail of communicated information varies greatly from vendor to vendor, as is the audience addressed. Some vendors only provide information for service providers, others only for website owners, and information for the public at large is left to the mass media without guidance. Our fourth recommendation: es-

text: tablish standards, guidelines and (where appropriate) coordination for practical, non-headline-seeking

text: information sharing regarding serious vulnerabilities.

text: 6 About “Info Notes” from ENISA

text: With the “Info Notes” series ENISA aims at giving the interested reader some background and recommendations about NIS related topics. The background and recommendations are derived from past experiences and common sense, and should be taken as starting points for discussions on possible course of action by relevant stakeholders. Feel free to get in touch with ENISA to discuss or inquire more information on the “Info Notes” series (cert-relations@enisa.europa.eu).


text: Flash Note 01, 29th January 2014

text: Flash Note 01, 29th January 2014

text: Printers, scanners, webcams, drivers, etc.

identifier: Flash note: Risks of using discontinued software

text: Risks of using discontinued software

text: Risks of using discontinued software

text: ENISA warns about the risks of using discontinued software, not only because of the lack of support from the manufacturer, but also from third parties, like manufacturers of anti-malware or other kind of software, or computer peripherals. This will lead in persistent exposure to vulnerabilities and lack of possibility to update peripherals or third party applications.

text: 1 Introduction

text: Frequently, cyber-security incidents are caused by unpatched software systems which are vulnerable to widely accessible exploits. This is the case even when the patches are available in the moment of the attack. There are cases when such attacks are perpetrated before the patches are distributed, either as consequence of the exploitation of a zero day vulnerability or because the vulnerability was known but the solution to the problem was still pending and a turn-around solution was lacking. To prevent the spread of such incidents the European Union Agency for Network and Information Security (ENISA) calls upon: - CERTs to identify and classify vulnerabilities and attack patterns, and define countermeasures; - Manufacturers to adhere to “security by design” principles during software development and also to implement a predictable product patching life cycle; - Users’ vigilance; one should be able to detect abnormal behavior of their system, allow the quick detection of the threat, promptly install published patches and follow configuration guidelines. Installation of patches presumes their availability. They need to be developed by the manufacturer of the system. Normally commercial manufacturers produce patches during the life cycle of the product, and commit themselves to continue generating them for some years after the end of the product’s distribution in the market. At the end of this extended life cycle, the manufacturer discontinues its support for product maintenance, and stops any activity around it, once it is considered that customers have had enough time to upgrade their platforms to newer products. This risk scenario is particularly relevant in the case of legacy software in industrial control systems (ICS) and SCADA, because those ICS are implemented using proprietary software with relatively limited number of licenses distributed, and for this reason normally immune to the most widely known attacks targeting standard software. The problem is that in the last years the trend in cybercrime is the targeted attacks, based on attack patterns and tools specially tailored for one organisation or proprietary software. Energy, nuclear and financial Critical Infrastructures systems have experienced well known incidents, and for this reason special care has to be taken of them.

text: 2 Risks associated with the use of discontinued software

text: Using discontinued software implies exposure to the following risks:  End-users will be unable to check the integrity of the software, because Signing certificates may be expired, i.e. not-valid. This will be the case only if the last original distribution was signed by the manufacturer. o Being unable to check the integrity of the software package could expose the user to malware. o Potentially infected systems may spread the infection over the whole network.

text: Page 1

text: Risks of using discontinued software

text: o Also, this could lead to non-compliance with security policies.  Loss of product support by the discontinued software manufacturer could potentially lead to the following: o Users of discontinued systems will not benefit from security updates or notices; o New vulnerabilities will no longer be collected, reported and analysed, thus new security patches will not be released; consequently the discontinued software may stay exposed to each such vulnerability forever, as if it was a 0-day attack vector.  Lack of support from third party software and hardware manufacturers could lead to unavailability to use the platform, e.g.: o unknown bugs may stop discontinued software from running; o Incompatibility of old Operating Systems with new devices , unavailability of drivers for new versions of peripherals may prevent users from upgrading or replacing used or broken devices; o Suspension of support of existing devices on the discontinued platform may result on impossibility to continue using the device in case of failure; o Suspension of support by third party manufacturers of installed software may prevent customers from upgrading or patching also third party software with newer versions. This also applies to new applications. o This may be particularly critical in case of unavailability of updated versions of antivirus and anti-malware solutions.

text: 3 ENISA’s recommendations

text: 1. IT Managers should always keep systems up to date with the latest security patches. Discontinued software should be considered a high security risk for critical IT components and should be mitigated by migrating to newer solutions or other platforms. In the case of Critical Infrastructures Information systems, the risk of exposure may be extended to citizens, and thus the responsibility of IT managers is larger.

text: 2. Manufacturers should make sure that they provide enough time for migration. During this phase, ENISA strongly recommends the use of advance notices and also an in-depth analysis of the expected impact on users’ security after the product will be discontinued.

text: 3. Users should make sure that they are aware and understand the security risk they are exposing themselves to by continuing to use obsolete software. Page 2


text: The BASH Shellshock bug TLP WHITE | Info Note | Final | September 2014

text: © European Union Agency for Network and Information Security (ENISA), 2014 01

text: © European Union Agency for Network and Information Security (ENISA), 2014 02

text: © European Union Agency for Network and Information Security (ENISA), 2014 03

text: © European Union Agency for Network and Information Security (ENISA), 2014 04

identifier: Flash Note: The BASH Shellshock Bug

nummer: flash-note-the-bash-shellshock-bug

title: Flash Note: The BASH Shellshock Bug

text: The BASH Shellshock bug

text: Unintended consequences in reuse of software

text: 1 Introduction

text: On 24 September, advisories were published concerning a bug in the Bourne Again SHell, bash. This software is a command line interpreter for UNIX-like systems, and exists on many platforms, including enduser systems. To make matters worse, bash is used by popular software such as the apache web server or OpenSSH, to provide extendability. To put things in perspective, the apache web server deploys about half of the web sites on the internet today.

text: Under certain conditions, attackers can force these legitimate services to execute arbitrary commands on the server. This started to happen very soon after publication of the vulnerability, and the bug is now used as vector to spread malware. At the time of writing, systems administrators and web site operators are rushing to patch their systems.

text: 2 The problem

text: (This section makes use of technical language)

text: Bash was created 25 years ago to provide a versatile environment with which to administer UNIX systems. It provides scripting facilities that allow among other things the automation of common tasks. Parameters to scripts are often passed as environment variables. The content of these variables can be anything: the name of a file, a username, or even function definitions. In this particular case, the vulnerability lies in the fact that bash continued to process commands after the end of a function definition. More technical information about the problem is available online.

text: 3 Why is this bad?

text: 3.1 Widespread usage

text: The apache web server uses bash as engine for dynamic web pages, using the Common Gateway Interfaces protocol (CGI) as a means of communication. Other software, for example mail servers, also use bash for back-end operations. The apache web server runs on about 50% of the web servers on the internet, but that is not the full story! Derivatives of apache and bash exist on countless devices as back-end for the administration interface: home routers, media players, Small-Office/Home Office SAN appliances, etc. There are millions of these devices in the field, often operated by people with little to no expertise in systems administration, and who have no idea that their device is offering this kind of service and is vulnerable, and even less know how to fix the problem.

text: 3.2 Inappropriate reuse

text: Bash was never intended to be reachable online. The intent was rather that it is used locally or over trusted links by knowledgeable people to perform for example systems administration tasks. However, as already stated, the apache web server uses this feature to provide CGI pages (see Glossary), and this is only one of the most common uses: mail servers and countless other devices can pass commands to bash and might therefore be used as components of attack vectors.

text: The result of this bundling is that a tool and in particular extended functionality that were meant to be used by trusted persons in trusted environments are reachable by anyone with an internet connection. The bug, which has little impact in the intended environment, can now have devastating effects.

text: Most likely, the choice of bash as a mechanism to provide dynamic web pages was one of convenience rather than a carefully studied selection. Bash was already ubiquitous on systems where the web server could run, but the authors used it without caring for unnecessary features.

text: 3.3 Obsolete features

text: The idea of allowing a web server to execute CGI scripts dates back to 1993. In the early days of the internet, CGI was the only way for a web site to provide dynamic pages. Since then, alternatives to CGI exist like servlets or ASP. These are more efficient and better integrated in the web server, and make for a more comfortable development environment. Nevertheless, the feature remains and there are many reasons for this: fear of breaking popular sites; difficulty of removing old code; failure to review the feature list, etc.

text: 4 Recommendations

text: 4.1 Think before reusing

text: Reusing existing code and programs is a common development practice. Programmers are encouraged not to re-invent the wheel. However, they often reuse software without completely understanding the ramifications of the reuse, and without regard for unnecessary features in the reused software. Developers are under pressure to deliver faster, and have no time, no expertise, nor incentive to conduct proper review of reused code. This was also one of the underlying problems in the recent “Heartbleed” incident.

text: We recommend that any code reuse be the result of a thorough review and understanding of the reviewed code. Management must allow and encourage developers to take the time to perform this review, and developers must not only focus on speed and convenience. Unnecessary features should be stripped. Should that prove impossible or take too much time, then the code should not be reused, or any resulting risk consciously accepted.

text: 4.2 Review features

text: The idea of allowing a web server to execute CGI scripts dates back to 1993. Since then, alternatives to CGI (such as servlets or ASP) exist. In general, these alternatives are more efficient and better integrated in the web server, and make for a more comfortable development environment. However the CGI feature still exists today, and there are many reasons for this: fear of breaking popular sites; difficulty of removing old code; failure to review the feature list, etc.

text: We recommend providers of online services or infrastructure to regularly review the need to keep existing features in deployed software, and to plan for their removal when better alternatives exist. Product teams should not be afraid to deprecate old features, and even more when they prove to be dangerous.

text: Glossary

text: ASP (Active Server Page): Technology created by Microsoft to facilitate the development of web applications on their web server software

text: CGI (Common Gateway Interface): The first mechanism that allowed a web server to return dynamic pages

text: Command-Line Interpreter: A program that acts as text user interface for an Operating System Environment Variable: A named value that can be used in a script. Usage of the variable in a script will be replaced by its value. Servlet: Mechanism to extend the functionality of a web server in Java. Script: Small (usually) set of commands that automate tasks on a computer. UNIX: Operating System originally developed in the 70’s. Linux is one of the most popular variants.

text: Additional References

text: [1] NCSC-NL, “Beveiligingsadvies NCSC-2014-0595 [1.00] - Ernstige kwetsbaarheid in Bash verholpen,” 25 09 2014. [Online]. Available: https://www.ncsc.nl/dienstverlening/responseop-dreigingen-en-incidenten/beveiligingsadviezen/NCSC-2014- 0595+1.00+Ernstige+kwetsbaarheid+in+Bash+verholpen.html. [2] CERT-SE, “BM14-001 - Allvarlig sårbarhet i bash,” 26 09 2014. [Online]. Available: https://www.cert.se/2014/09/bm14-001-allvarlig-sarbarhet-i-bash. [3] CERT.LV, “Bourne Again Shell (Bash) attālināta koda izpildes ievainojamība jeb "Shellshock",” 25 09 2014. [Online]. Available: https://cert.lv/resource/show/537. [4] CERT Hungary, “GNU Bash kritikus sérülékenysége - frissült,” 25 09 2014. [Online]. Available: http://www.cert-hungary.hu/node/275. [5] CERT.be, “Severe Bash Vulnerability,” 25 09 2014. [Online]. Available: https://www.cert.be/docs/severe-bash-vulnerability. [6] NCSC-FI, “Shellshock-haavoittuvuutta hyödynnetään aktiivisesti,” 25 09 2014. [Online]. Available: https://www.viestintavirasto.fi/tietoturva/tietoturvanyt/2014/09/ttn201409251726.html. [7] CERT.SI, “SI-CERT 2014-05 / GNU bash ranljivost omogoča izvajanje ukazov na daljavo,” 25 09 2014. [Online]. Available: https://www.cert.si/si-cert-2014-05/. [8] CERT-FR, “Vulnérabilité dans GNU bash,” 25 09 2014. [Online]. Available: http://www.cert.ssi.gouv.fr/site/CERTFR-2014-ALE-006/index.html. [9] CSIRT.SK, “Závažná zraniteľnosť v Bourne Again Shell (Bash),” 25 09 2014. [Online]. Available: https://www.csirt.gov.sk/oznamenia-a-varovania-803.html?id=118.

text: About “Info Notes” from ENISA