October 2014

Shellshock (also known as Bashdoor) is a security bug in the Bourne Again SHell (BASH)
Command Line Interpreter (CLI), also known as a shell. The BASH shell is widely distributed as the default CLI on many unix-like OS, including most types of Linux, many types of Unix, some types of BSD and Apple’s OSX.

Shellshock could allow hackers to remotely issue administrative commands to web servers. Seeing as a hacker can force a server to do anything he/she wants, there is a serious risk that private information can easily be stolen from affected servers. This could mean significant problems for companies with a web presence in the Internet whose servers are affected, according to a few information security professionals.

Since the announcement of the initial Shellshock bug (24 September 2014), related bugs in BASH were found by various researchers. The most important of these is the CVE-2014-6271 bug. It gives a good sense of the severity:

“GNU BASH through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from BASH execution.”

Therefore, it seems to be clear that anything that can manipulate the environment variables has the potential to be a vector for this vulnerability. Some experts are calling the Shellshock bug “a far more serious threat than the Heartbleed vulnerability”, which was discovered months ago (April 2014) and is still known to be affecting thousands of devices. That is because Shellshock allows unauthenticated attackers to remotely execute commands, while Heartbleed only allows intruders to steal information from servers. If an attacker identifies a vulnerable server, he/she can perform a number of different types of requests and several forms of attack, as a consequence. However, a more serious problem is faced by network devices that use embedded Linux, such as routers, switches, and security appliances. If there is an older, no longer supported model, it may be close to impossible to patch it and will likely be vulnerable to attacks.

An analysis of attacks experienced on this vulnerability shows that most of them are targeting HTTP web servers. Servers that run the Common Gateway Interface (CGI) or FastCGI have the capability to expose BASH to a HTTP request vector. A maliciously “handmade” HTTP request can allow an attacker to inject arbitrary commands onto the server and BASH will execute them, if invoked. BASH can be called directly by the CGI, or it could be called via a subprocess or system command. If BASH is started at any point within the context of this malicious CGI request, then the vulnerability will be triggered.
Actually, this bug has existed in the BASH code for over twenty years, since BASH program was written. However, it is not possible to estimate if or not this vulnerability was exploited in the past. The high level of severity is given by a combination of three concurrent factors:

• the large number of vulnerable (web) servers on the Internet;
• an easy accessibility of various exploit tools;
• the importance of the outcome of exploitation, seeing as once a vector is found, arbitrary code execution is often easily gained.

Here is a basic explanation on what network and security administrators can do to protect their corporate’s infrastructure:

first of all, note that there’s no evidence that an exploitable Windows OS vector exists, although it’s possible;

it’s necessary obtain the latest patches from vendors and patch the affected systems to the latest version of BASH (all major Linux distributors have released patches that stop most attacks);

• where patching is not possible, or if a patch is not available for your platform, evaluate migrating to another shell program;
• check system’s exposure: for example, Red Hat has released a comprehensive guide which explains how to determine if a system is or not un-patched and vulnerable;
• keep update network and server security products;
• note that Intrusion Prevention Systems (IPS) and other types of network based detection SW or appliances are very effective for detecting and preventing Shellshock exploits, because the string sequence required to trigger the vulnerability is very distinguishable. Therefore, make sure your IPS systems are updated with the correct rule sets to detect and prevent exploitation attempts;
• keep monitoring servers and access points in your network infrastructure;
• specifically for Apache Web server, there are some Mod_Security rules that can stop attempts to exploit Shellshock. Mod_security is an Apache module that helps to protect websites from various attacks. It is used to block commonly known exploits by use of regular expressions and rule sets. These rules, created by Red Hat, are as follow:

Request Header values:
SecRule REQUEST_HEADERS “^\(\) {” “phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”

SERVER_PROTOCOL values:
SecRule REQUEST_LINE “\(\) {” “phase:1,deny,id:1000001,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”

GET/POST names:
SecRule ARGS_NAMES “^\(\) {” “phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”

GET/POST values:
SecRule ARGS “^\(\) {” “phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”

File names for uploads:
SecRule FILES_NAMES “^\(\) {” “phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”

Moreover, note that all the major Linux distributions now have patches available for the two original issues (CVE-2014-6271 and CVE-2014-7169). Several other related vulnerabilities in BASH remain un-patched, for now. However, there are no public reports yet of attacks taking advantage of these vulnerabilities and they are more difficult to exploit.

Finally, the experience relating to the major security vulnerabilities shows that reactive patching in itself is not sufficient to ensure protection against this types of attack. A proper implementation of proactive auditing policies and procedures is required in order to achieve an in-depth knowledge of the enterprise’s network infrastructure.
The less an administrator know about what software is running and where in the network, the longer it will take for him to deal with crises like Shellshock.

References

http://www.zdnet.com/shellshock-makes-heartbleed-look-insignificant-7000034143/

http://www.zdnet.com/the-shellshock-faq-heres-what-you-need-to-know-7000034219/

https://access.redhat.com/articles/1200223

http://cve.mitre.org/index.html

In general terms, Identity Management can be defined as management of individual digital identity within an organization, being it a company, a city or an entire country. In the recognition of personal identity, the specific allocation of one or more roles within the company is a key issue in both a social and working context. In the modern IT world, with the proliferation of applications, userID, passwords, database, and different accounts for each single application, you need a generalist and centralized approach. This approach makes it possible to achieve two main objectives:

• Certain and unique recognition of the person that is trying to get access, with clear roles and features;
• Simplification of access functions, without neglecting any security aspect.

Identity Management is an IT discipline, founded relatively recently, which aims to solve and automate the mechanisms of start, development and termination of the workers digital identities.
The IdM (Identity Management) tools include:

• Password management tools;
• User provisioning and deprovisioning;
• User access centralization;
• Single-Sign-On systems;
• Roles and authorisations management;
• Authorization processes management.

It goes without saying that the IT tool is used to automate a well-designed organizational process. However, without a clear idea of resources organization, IT tools can only partly solve management problems.

How can the use of digital identity management systems make improvements? With the development of e-commerce, the implementation of mobile systems and web-based applications, the concept of the workstation has become an almost absolute level of abstraction. There is almost no connection between clients which use applications and users. Users have (or rather claim to have) the possibility to connect to corporate resources using the most various devices: smartphones, tablets, personal PCs, and with the most disparate operating systems. User recognition, accounting, and digital identity security measures play a fundamental role. Beyond legal issues and compliance with ITIL and security best practices, use of IdM tools can lead to undoubted practical benefits, just think about the Self Service Password Reset systems. Over 70% of help desk calls concern password reset and the difficulty task for operators is always the same: having a reasonable certainty that the user for which assistance is sought is actually the person who is calling. Automate password reset systems, with safe Identification tools lead to real benefit concerning the time and resources.

Generally each new application brings with it a clearly defined database of users and roles, resulting in a proliferation of users and passwords, all with different criteria of complexity and with different expiration times. Being able to access the payroll web application can become a real nightmare, between PC passwords, network passwords and application passwords. The use of valid IdM systems allows the company to maximize the centralization of password management, to allow access to most resources with a single password (SSO), or at least synchronize accesses to systems that do not support SSO.

The Single-Sign-On is a blessing and a curse for all IT administrators: on the one hand, the use of a single user makes easier life for both users and administrator. On the other hand, compromise of that account could provide access to a multitude of resources and information, including the most sensitive.
It goes without saying that it is necessary in every way to preserve that access from any kind of tampering.

Modern IdM systems generally consist of four main elements:

• A central storage that contains all digital IDs;
• A unique tool for managing the life cycle of user accounts (creation, modification, privileges assignment, deletion etc.);
• A system that manages Accesses and Authentications (which therefore it put Policies into operation);
• An auditing system that allows to check the development of events and any possible deviations from Policies.

It is rare when talking about Identity Management to not approach Access Management. Especially since the term most frequently used in the management of digital identities is not so much IdM as rather IAM (Identity Access Management). An equally effective access management, especially when talking about Single-Sign-On, and must accompany a strict policy on identity.

The Access and Authentication mechanisms must follow data privacy and importance to manage: you switch from password policy to strong authentication systems: token, OTP (one time password), biometric systems.

The evolution of Cloud Computing, which has become a current hot topic in the context of security, has opened up new vistas (scenarios) for what concerns the Identity Management: no more Software as a Service (SaaS), but now Infrastructure as a Service (IaaS): the needs of corporate IT infrastructure growth and shrinkage (perhaps to cope with service spikes) caused companies to draw upon Cloud services (partially or entirely). Digital Identities management in an exposed environment, assumes even greater relevance: you are no longer protected by perimeter security. Infrastructure fruition takes place through the more disparate devices that is not always controllable. Companies sometimes interface with dozens of Cloud service providers, who need to provide secure and transverse interfaces to the integration with IAM tools, in order to extend internal Authentication/Authorization methods to all third-party provider while preserving the SSO.

The security challenge in the Cloud has just begun: it goes from Hybrid Cloud, in which the third party part is simply seen as an extension of their IT infrastructure, to the Cloud Suit, where both services, application platforms and the same infrastructure are hosted by providers, while wanting to maintain management and control.