Bash Vulnerability, or Shellshock, as the name suggests, attacks Bash which is used to execute scripts and commands by UNIX based systems. Bash is free and often used as the built in command line interface distributed with the Linux. Environment variables are defined in Bash along with the scripts and functions which can be executed. An attacker if allowed to execute Bash, could also execute other arbitrary commands or scripts or other exploits without the knowledge of the user.

How it affects the system?

Thus, Bash vulnerability allows remote code execution through a lot of default configurations and is a serious risk to a wide range infrastructure on the Internet and the severity is extreme as bash is part of the default configuration of most Linux servers.

Bash is commonly used in UNIX software packages or servers such as web and mail and it is not commonly allowed to be accessed by external users. Only the system administrators and the maintenance crew use Bash to administrate their servers as well as perform the maintenance works.

This doesn’t sound so bad right? But in truth, if any external user sends any carefully and specifically formatted request to the web server, the servers than pass it on to Bash. This is when the problem begins to show itself. The carefully formatted request, when it reaches Bash, can now execute and programmed scripts or commands on the Bash shell even though it doesn’t have any security or access level clearances.

Future of Bash/Shellshock bug?

A patch was released which allowed Unix and OS X users to update their BASH shell to fix this vulnerability. However, it isn’t a complete fix. The patch only makes it harder to exploit the vulnerability while it still exists. Millions of user remain at risk and any systems that haven’t been patched yet can be compromised. A hacker community with resources may exploit this bug to create wide scale panic and affect the systems.

How do we fix it?

Although no complete solution has been found yet, the easiest way to protect yourself from Shellshock is to update Bash. That’s it. If not a complete fix, it mitigates the risk and makes it much harder to exploit.
An easy way to check if the vulnerability exists is to run the command line:
env ‘VAR=() { :;}; echo Bash is vulnerable!’ ‘FUNCTION()=() { :;}; echo Bash is vulnerable!’ bash -c “echo Bash Test”
A “Bash is vulnerable!” output means the vulnerability exists. Ubuntu/Debiandistros can update their bash using the following command line:
sudo apt-get update &&sudo apt-get install –only-upgrade bash

Arshad Ahmed
MBA-IT
IIIT Allahabad

SQL Injection Example:
1 HttpServletRequest request = …;
2 Statement s = …;
3 String client = request.getParameter(‘‘client’’);
4 StringBuffer s1 = …;
5 s1.append (”SELECT ∗ FROM Users WHERE name =”);
6 s1.append (user);
7 String query = s1.toString ();
8 s.executeQuery(query);

SQL injection is one of the vulnerabilities that can be expressed as tainted object propagation problems. An object is tainted if it is obtained by applying relation derived to a source object zero or more times. In our example, if a tainted object is passed as a parameter i.e. the return value of HttpServletRequest.getParameter() to Statement.executeQuery(String p) (the sink), then there is a security vulnerability. Datalogqueries gives user complete control. On other hand it exposes program’s internal representation. So it is considered less practical. Instead, we use PQL, a program query language. PQL serves as syntactic sugar for Datalog queries, allowing users to express vulnerability patterns in a familiar Java-like syntax; we can then easily translate tainted object propagation queries from PQL into Datalog.

Penetration testing and runtime monitoring integrated with static taint analysis seems to be a promising approach for finding vulnerabilities besides manual code reviews.

Niharika Gupta,
M.Tech, Computer Science Engineering
Indraprastha Institute of Information Technology, Delhi

A zero-day attack is the one that exploits the unknown vulnerability of the system prior to the knowledge of software maker about the flaws. The known targets are telecom, government, NATO, Energy and academic. Although the bug bounty tries to point out the flaws as soon as possible but sometimes because of the non-availability of the security patches the attackers get to know about the unknown vulnerabilities and hence it is called as zero-day. The vulnerability window length may vary from 1 day to 10 years or more on an average it is around 10 months. Microsoft releases its security patches on every second Tuesday of the month. By analysing this patch the attackers immediately exploits the previous vulnerability and with this comes the term ‘exploit Wednesday’. The exploiters use various techniques such as Fuzz Technology to find out the bugs and snoop through PC. In the recent updates FireEye revealed the campaign of Russianattackers exploited two zero-day bugs for 32-bit windows which were impacted by the TTF flaw in the office documents. The attack vectors used by malware writers have made Microsoft to release MS14-058 for TTF flaw in office document and MS14-060 for OLE package to protect the systems. One of the major concern is for windows XP users as Microsoft has declared that it would discontinue the support for windows XP and it will have zero-day forever because of reverse engineered secure patch for the newer versions of windows.

US-CERT is an organisation which analyses the cyber threat and reduce the vulnerabilities and coordinate the incident response activities as well as has an expertise to target on the the malicious activities on the networks. As a protection scheme by any organisation against the zero day threat it is advisable to follow the guidelines provided by US-CERT.

There are several tactics given below for a zero day offense
1. Using more robust form of vulnerability management system and having resilient layers to protect against the zero day attack.
2. Having well configured firewalls
3. Providing full protection to the critical systems
4. Identification of the threat at an early stage
5. The testing of software codes at a more advance level.

Archita Srivastava
MBA-IT
IIIT Allahabad