New Post

Rss

Tuesday, October 28, 2014
Boolean Exploitation Technique to exploit SQL Injection Vulnerability | INJECTION ATTACKS - PART 7

Boolean Exploitation Technique to exploit SQL Injection Vulnerability | INJECTION ATTACKS - PART 7

In our Previous tutorial we learnt about SQL Injection characters and different exploitation techniques to exploit SQL Injection Vulnerability. From today we will start learning all exploitation techniques in details with help of examples starting from Boolean Exploitation Technique.

Boolean Exploitation Technique is basically an SQL Injection Exploitation technique where a set of Boolean operations are executed in order to extract juicy information regarding the tables of the database of an web application. Boolean Exploitation technique is mostly used in cases where Hackers have predicted that Blind SQL Injection is possible i.e. in cases where output of the operations or requests is not known. For example, consider an web application in which all the error messages are replaced with custom error messages (which does not reveal any important information to the users) by the web designer or developer i.e. Page may not return the SQL Error instead of SQL Error it shows 404 or 500 or some other custom messages. This method consists of carrying out a series of Boolean queries against the server, observing the answers and finally deducing the meaning of such answers.

Boolean Exploitation Technique to exploit SQL Injection Vulnerability
Boolean Exploitation Technique


Consider an example, suppose we have a vulnerable website say www.example.com and it has a parameter namely "Id" which is vulnerable to SQL Injection. Now suppose we execute the below request in our web browser :

http://www.example.com/index.php?id=1’

The above query will result into opening of one web page which might throw an custom error message say 404 or 500. If that happens, we suppose that below query is executed at backend of website:

SELECT Field1, Field2, Field3 FROM Users WHERE Id=’$Id’ 

As we have discussed in previous articles that above SQL is vulnerable to SQL Injection. Our current and most important GOAL is to get values of the username field which is currently not known as we only know about ID parameter as of now. The exploits or tests that we will execute now will aim to get the values of username filed character by character. This can be possible by using some set of inbuilt functions (i.e. standard functions) present in almost all databases. 

List of some important functions that we will use to extract information are below:
1. SUBSTRING (text, start_position, length) : This function returns a substring starting from the position “start_position” of text and upto length “length”. If “start_position” is greater than the length of text, the function returns a null value.

2. LENGTH (text): It gives back the number of characters in the input text.

3. ASCII (char): It gives back ASCII value of the input character. A null value is returned if char is 0.

There are lot more functions but above 3 are needed as of now.  Using these functions we will execute test on first character and once we get the value of first character, we will move to the second character and so on, until we get the complete value. SUBSTRING function will help us to select one character at a time (selecting a single character means to force the length parameter to 1), and the function ASCII, in order to obtain the ASCII value, so that we can do numerical comparison. The results of the comparison will be done with all the values of the ASCII table, until the right value is found. 

For example, lets try below value of "Id" parameter:

$Id=1’ AND ASCII(SUBSTRING(username,1,1))=97 AND ‘1’=’1 

So the URL will be something like :

http://www.example.com/index.php?id=1’ AND ASCII(SUBSTRING(username,1,1))=97 AND ‘1’=’1

And SQL Query will be something like :

SELECT Field1, Field2, Field3 FROM Users WHERE Id=’1’ AND ASCII(SUBSTRING(username,1,1))=97 AND ‘1’=’1’


The above example returns a result if and only if the first character of the field username is equal to the ASCII value 97. If we get a false value, then we increase the index of the ASCII table from 97 to 98 and we repeat the request. If instead we obtain a true value, we set to zero the index of the ASCII table and we analyze the next character, modifying the parameters of the SUBSTRING function. 

The only problem with above example is that how we will distinguish our tests which are returning true value from ones which are returning false value. This can be possible if we create a query which always returns false, so below value of ID can solve this problem for us :

$Id=1’ AND ‘1’ = ‘2 

So Query will be something like :

SELECT Field1, Field2, Field3 FROM Users WHERE Id=’1’ AND ‘1’ = ‘2’ 

Hence URL will be something like :

http://www.example.com/index.php?id=1’ AND ‘1’ = ‘2 

The above query will always returns false value. Does this rings a bell? Huh...

The above query execution will throw an error message (i.e. custom error message say 500). This will be the false value for our tests. Now this custom error message will help us to distinguish the values of test results i.e. which one is true and which one is false. 

Sometimes it may happen that above method does not work. For example, If the web server returns two different pages as a result of two identical consecutive web requests i.e. Boolean query executions, we will not be able to discriminate the true value from the false value. In these particular cases, it is necessary to use some filters that allow us to eliminate the code that changes between the two requests and to obtain a template for getting username character by character. Later on, for every Boolean request executed, we will extract the relative template from the response using the same function, and we will perform a comparison between the two templates in order to decide the result of the test.

In the above method, we haven't discussed about determining the termination condition i.e. when we should end the Boolean procedure. The technique to solve this problem uses one characteristic of the SUBSTRING function and the LENGTH function. When the test compares the current character with the ASCII code 0 (i.e., the value null) and the test returns the value true, then either we are done with the Boolean procedure (we have scanned the whole string), or the value we have analyzed contains the null character. To achieve this we will use below value of Id parameter :

$Id=1' AND LENGTH(username)=N AND '1' = '1 

where N is the number of characters we have scanned so far. Note: Null value is not counted in value of N.  

So the query will become something like below:

SELECT Field1, Field2, Field3 FROM Users WHERE Id='1' AND LENGTH(username)=N AND '1' = '1' 

And URL to hit above query will be something like :

http://www.example.com/index.php?id=1' AND LENGTH(username)=N AND '1' = '1 

The above query will return either true or false. If above query returns true that means we have extracted the complete value of username. If we get false, it means that username parameter contains a null character in between, so continue the Boolean procedure as explained above until you get the true condition. 

That's all about the Boolean Exploitation technique to Exploit SQL Injection Vulnerability. If you have any doubts, feel free to ask. Enjoy Learning! Happy Hacking!
Sunday, October 26, 2014
How to Exploit SQL Injection Vulnerability | Injection attacks - Part 6

How to Exploit SQL Injection Vulnerability | Injection attacks - Part 6

Previously we have learnt about standard SQL Injection and simple techniques to test SQL Injection Vulnerability. Today we will learn how to exploit SQL Injection vulnerability. There are lot of ways to exploit SQL Injection flaw, we will learn all of them one by one. Today i will brief about different Exploitation Techniques used to exploit SQL Injection Vulnerability.

Different ways to exploit SQL Injection Vulnerability :

1. Boolean Exploitation Technique
2. Union Exploitation Technique
3. Error Based Exploitation Technique
4. Out of band Connection Exploitation Technique
5. Time Delay Exploitation Technique
6. Stored Procedure Injection Exploitation Technique
7. Automated Exploitation Technique using SQLi Tools


But before starting with any of above topic, we must know what are all SQL Injection Characters ? Huh... SQL Injection characters are those characters which directly or indirectly results into SQL injection. More than 99% of SQL Injection attacks occurs only because of these characters parsing. I will not give complete list but will share most important one, because it can result into misuse of knowledge.

SQL Injection Characters :

 ' or " character String Indicators
' closes the string parameter. Everything after is considered part of the SQL command. 

 --      Single-line comment 
#      Single-line comment in MySQL or date delimiter in MS Access
/*…*/   multiple-line comment
+      Addition operator or Concatenation operator i.e. when used in an URL it becomes a white space
||     Concatenation operator in Oracle and Postgres Databases
-      Subtraction operator or a range indicator in CHECK constraints
%    Wildcard attribute indicator
=     Equality operator
<> !=     Inequality operators
><   Greater-than and Less-than operators
( )    Expression or hierarchy 
,       List item separator
.       Identifier qualifier separator
@var    Local variable
@@var      Global variable
?Param1=foo&Param2=bar    URL Parameters
PRINT useful as non transactional command
waitfor delay '0:0:10'  Time delay

The above SQL Injection characters are base for every SQL Injection. Hackers use these SQL Injection characters to successfully exploit an SQL Injection Vulnerability.

Also we have missed one thing in our previous article related to fingerprinting of database. Below are some differences that can be used to determine what db we are in if we have no other easier way. By trying out conditions using the 'and condition and '1'='1 statement we can determine what type of database we have connected to.


fingerprinting of database
Fingerprinting of database


In later articles we will learn each SQL Injection Exploitation Technique one by one in detail. Keep learning. Enjoy!
Sunday, October 12, 2014
How to test SQL Injection Vulnerability | Injection attacks - Owasp #1 Vulnerability - Part 5

How to test SQL Injection Vulnerability | Injection attacks - Owasp #1 Vulnerability - Part 5

In our previous article we have learned about Standard SQL Injection also known as Classical SQL Injection with set of examples. Today we will learn about "How to test SQL Injection flaws?"and SQL Database Fingerprinting as these two are major steps for exploitation of SQL Injection flaws. 

Exploitation of SQL Injection flaw depends on two basic things:
1. How to test that website or web application is vulnerable to SQL Injection i.e. knowing test subject is vulnerable or not.
2. Fingerprinting the database i.e. knowing the type of Database i.e. MySQL, Oracle, MS SQL etc..

So let's learn them one by one in detail for better understanding.


How to test that website or web application is vulnerable to SQL Injection attack?


In order to test a website or web application for SQL Injection vulnerability, first of all we must know when does a website or web application interacts with Database or DB. Most website and web applications interacts with their database when they have to retrieve a similar set of items from the some tables, for example during authentication ( user enters username and password for login which is stored in one of the tables of database), another example can be consider an eCommerce website which retrieves all its items details from some products table, another example can be search engine where search values are retrieved from some indexed table. 



How to test SQL Injection Vulnerability
How to test SQL Injection Vulnerability 


In order to craft the similar SQL which developer has used in his/her website or web application, Hacker has to note down all probable input fields including all hidden POST fields of POST request too. For doing this, Hacker can use tools like "TAMPER DATA (Firefox addon)" to alter the data in real time. Tamper Data allows hackers to manipulate all requests in real time, so this will allow hackers to visit all Hidden POST fields too.

1. Testing of certain special characters and keywords:
We will recommend to start your testing with adding an single quote(') or a semicolon (;) to the field or parameter in the request. For example :


http://www.example.com/product.php?id=10'

                                  or


http://www.example.com/product.php?id=10;

If this result into error, then this means website is vulnerable to SQL injection, we will learn exploitation techniques in next part. If no error comes test it further by adding Comment (/* or --) or using other keywords like 'AND' or 'OR' to modify the request.


2. Testing Fields with Content type:
This way of testing is very easy to perform, in this way Hacker needs to find out what type of values a field accepts. Suppose a field only accepts integer values, then pass String value in the field or parameter. Another way is to insert all special characters or insert encoded characters in the field. If the request result into an error then it means website is vulnerable to SQL Injection. For Example, say ID field only accept integer values and we try to insert string into it:


http://www.example.com/product.php?id=mycheck


Hackers need to monitor all the responses from the web server and have to look at the HTML/javascript source code too because sometimes the error is present inside them but for security reasons javascript error, HTML comments, etc is not presented to the user. A full error message provides lot of juicy information to the Hacker in order to attempt a successful injection attack. However, applications often do not provide so much detail: a simple '500 Server Error' or a custom error page or 404 response code might be issued, meaning that we need to use blind injection techniques. In any case, it is very important to test each field separately: only one variable must vary while all the other remain constant, in order to precisely understand which parameters are vulnerable and which are not.



Fingerprinting the Database:

All databases(DBMS) have their uniqueness associated with them and differs from each other on several aspects for example special commands, functions to retrieve data, other features etc.

Advance SQL Injection involves knowing of Database type and its features in order to exploit the flaw.


The first way to find out what back end database is used is by observing the error returned by the application. For example:

Web Application uses mySQL as backend database:



You have an error in your SQL syntax; check the manualthat corresponds to your MySQL server version for theright syntax to use near '\'' at line 1


Web Application uses Oracle as backend database:


ORA-00933: SQL command not properly ended

Web Application uses MS SQL as backend database:




Microsoft SQL Native Client error ‘80040e14’Unclosed quotation mark after the character string
and so on...


Alternate way to find the backend database is  to, try to inject into string field using concatenation technique.

For Example:


MySql: ‘Hack’ + ‘ing’


Ms SQL Server: ‘Hack’ ‘ing’


Oracle: ‘Hack’||’ing’


If string is concatenated properly then it confirms what backend database web application or website is using.


That's all for today friends. We will learn all SQL Injection Exploitation techniques one by one in detail in later articles.

If you have any doubts or queries feel free to ask.



Thursday, October 9, 2014
Standard SQL Injection | Injection attacks - Owasp #1 Vulnerability - Part 4

Standard SQL Injection | Injection attacks - Owasp #1 Vulnerability - Part 4

In our previous article we have learned about basic of Blind SQL Injection using untrusted data parsing. Today we will learn in detail about Standard SQL Injection (or Classical SQL Injection) attack in detail. Lets revisit what we have learned in previous article, we have learned about (OR 1=1) i.e. always true condition.

Standard SQL Injection | Injection attacks - Owasp #1 Vulnerability
Standard SQL Injection | Injection attacks - Owasp #1 Vulnerability


Consider an example that we have a table named "users" which contains login credentials and SQL query which validates data from login table is something like below:

SELECT * FROM Users WHERE Username='$username' AND Password='$password'

 If the query returns a value it means that inside the database a user with that set of credentials exists, then the user is allowed to login to the system, otherwise access is denied. The values of the input fields are generally obtained from the user through a web form. Suppose we insert the following Username and Password values:

$username = 1' or '1' = '1

$password = 1' or '1' = '1


Then the query will become something like:
SELECT * FROM Users WHERE Username='1' OR '1' = '1' AND Password='1' OR '1' = '1' 

If we suppose that the values of the parameters are sent to the server through the GET method, and if the domain of the vulnerable web site is www.example.com, the request will be something like below:

http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1&password=1'%20or%20'1'%20=%20'1 


After a short analysis we notice that the query returns a value (or a set of values) because the condition is always true (OR 1=1). In this way the system has authenticated the user without knowing the username and password.
In some systems the first row of a user table would be an administrator user. This may be the profile returned in some cases.


Above one was the typical example of SQL Injection which nowadays is not that much effective as most of developers use Encryption on password, usually MD5. So do imposing an encryption on passwords can protect databases? Answer is straight forward "NO". Lets consider an another example, which contains encryption employed in it. Say developer uses below SQL Query to authenticate users on website:

SELECT * FROM Users WHERE ((Username='$username') AND (Password=MD5('$password'))) 

Now above query has two issues for Hackers to hack into this, first parenthesis and second one MD5 Encryption both highlighted in red. So first of all lets solve the problem of parenthesis. First of all we need to identify correct number of parenthesis specially opening ones, it is quite easy just keep on adding closing parenthesis until we get the correct number of closing parenthesis but why? Simply because we wish to bypass the second problem :D yes we want to comment the MD5 encryption within the query to bypass the authentication. Every DBMS has its own syntax for comments, however, a common symbol to the greater majority of the databases is /*. In Oracle the symbol is "--". 
In this case we will use below username and password to bypass:

$username = 1' or '1' = '1'))/*

$password = foo


So the query will become something like below:

SELECT * FROM Users WHERE ((Username='1' or '1' = '1'))/*') AND (Password=MD5('$password'))) 


Now due to the inclusion of a comment delimiter in the $username value, the password portion of the query will be ignored i.e. commented.

And the URL Request to execute above query will be something like :


http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1'))/*&password=foo 

This may return a number of values. Sometimes, the authentication code verifies that the number of returned records/results is exactly equal to 1. 

In the previous examples, this situation would be difficult (in the database there is only one value per user).

In order to go around this problem, it is enough to insert a SQL command that imposes a condition that the number of the returned results must be one. (One record returned) In order to reach this goal, we use the operator "LIMIT <num>", where <num> is the number of the results/records that we want to be returned. With respect to the previous example, the value of the fields Username and Password will be modified as follows:

$username = 1' or '1' = '1')) LIMIT 1/* 

$password = foo 

This will result into a query something like below:
SELECT * FROM Users WHERE ((Username='1' or '1' = '1')) LIMIT 1/* /*') AND (Password=MD5('$password'))) 


In order to execute above query, URL will be something like below:

http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1')) LIMIT 1/*&password=foo


The above URL will fetch the first value from the users table and will allow hackers to bypass the authentication of website.

That's all for today. We will learn more about SQL Injection Exploitation techniques in later articles. Keep Learning!



Friday, October 3, 2014
Secure Sockets Layer Tutorial | What is SSL | SSL Hackers Guide

Secure Sockets Layer Tutorial | What is SSL | SSL Hackers Guide

You might have heard some times that not to give your password or credit card information or any other sensitive information on public computers or on Facebook, yahoo etc chats.The reason why you might have heard that the Hackers have some ways to you would have probably heard that hackers have a way to steal your your credit card numbers , passwords etc.


Secure Sockets Lock Tutorial | What is SSL | SSL Hackers Guide
Secure Sockets Lock Tutorial | What is SSL | SSL Hackers Guide


A hacker can use different types of attacks such as Packet sniffing or ARP Poisoning to steal your sensitive information.

Secure Sockets Layer (SSL) is the most widely used technology for creating a secure communication between the web client and the web server. You must be familiar with http:// protocol and https:// protocol, You might be wondering what they mean. HTTP protocol is used for standard communication between the Web server and the client. HTTPS is used for a secure communication.


Cryptography



If two users want to have a secure communication they can also use cryptography to accomplish it

For example: 

TFDVSF=Encrypted Text

SECURE= Decrypted Text

You might be wondering how i Decrypted it, Here i have used Algorithm=+ for the communication and the key is "1", What comes after S is T so as you can see that S is converted into T, What comes After is to letter E from the word secure if converted into F and so on, To help you understand this more better I am adding a Video - 






So If the hacker starts sniffing from between he will get Encrypted text and as the Hacker does not know the keys so he cant decrypt it, but if the attacker or hacker is sniffing from the starting point so he will get the key and can easily Decrypt the data.



Standard Communication VS Secure communication 



Suppose there exists two communication parties A (client) and B (server) 


Standard communication(HTTP)



When A will send information to B it will be in unencrypted manner, this is acceptable if A is not sharing Confidential information, but if A is sending sensitive information say "Password" it will also be in unencrypted form, If a hacker starts sniffing the communication so he will get the password.

This scenario is illustrated using the following figure -


Standard Communications HTTP
Standard Communications HTTP



Secure communication(HTTPS) 



In a secure communication i.e. HTTPS the conversation between A and B happens to be in a safe tunnel, The information which a user A sends to B will be in encrypted form so even if a hacker gets unauthorized access to the conversion he will receive the encrypted password (“xz54p6kd“) and not the original password.
This scenario is illustrated using the following figure - 


Secure communication(HTTPS)
Secure communication(HTTPS) 




How is HTTPS implemented?


HTTPS protocol can be implemented by using Secure Sockets Layer (SSL), A website can implement HTTPS by purchasing SSL certificate.

Which websites need SSL Certificate?


The websites where a private conversation is occurred, Websites related to online transactions or other sensitive information needs to be protected needs to SSL Certificate.



How to identify a Secure Connection?


In Internet Explorer and google chrome, you will see a lock icon in the Security Status bar. The Security Status bar is located on the right side of the Address bar. You can click the lock to view the identity of the website. 

If you are making an online transaction through Credit card or any other means you should check if https:// secured communication is enabled.

Source: RHA InfoSec
How to Bypass Disabled Right Click on Any Website

How to Bypass Disabled Right Click on Any Website

You might remember an experience where you tried to right-click on a web page but got a pop-up message saying that the “right-click functionality has been disabled”. Sometimes you may be trying to copy an image or view the source of a web page but when the right-click is disabled, these things would seem impossible. Bank websites and other sites that require a secure transaction such as a payment gateway are the ones to impose this kind of limited functionality on their pages. In this post, I will show you the ways by which you can easily bypass right-click block feature on any website.
How to Bypass Right Click Block on Any Website
How to Bypass Right Click Block on Any Website

In order to block the right-click activity, most websites make use of JavaScript which is one of the popular scripting languages used to enhance functionality, improve user experience and provide rich interactive features. In addition to this, it can also be used to strengthen the website’s security by adding some of the simple security features such as disabling right-clickprotecting images, hiding or masking parts of a web page and so on.

How JavaScript Works?

Before you proceed to the next part which tells you how to disable the JavaScript functionality and bypass any of the restrictions imposed by it, it would be worthwhile for you to take up a minute to understand how JavaScript works.
JavaScript is a client side scripting language (in most cases), which means when loaded it runs from your own web browser. Most modern browsers including IE, Firefox, Chrome and others support JavaScript so that they can interpret the code and carry out actions that are defined in the script. In other words, it is your browser which is acting upon the instruction of JavaScript to carry out the defined actions such as blocking the right-click activity. So, disabling the JavaScript support on your browser can be a simple solution to bypass all the restrictions imposed by the website.

How to Disable the JavaScript?

Here is a step-by-step procedure to disable JavaScript on different browsers:

For Internet Explorer:

If you are using IE, just follow the steps below:
  1. From the menu bar, go to Tools -> Internet Options.
  2. In the “Internet Options” window, switch to Security tab and click on the button Custom level…
Bypass Right Click on Internet Explorer
Bypass Right Click on Internet Explorer

3. From the Security Settings, look for the option Active scripting and select the Disable radio button as shown above and click on “OK”.
 4. You may even select the Prompt radio button, so that each time a page is loaded, you will have the option to either enable or disable the scripting.

For Google Chrome:

If you are using Chrome, you can disable the JavaScript by following the steps below:
  1. Click on the Chrome “menu” button (on the top right corner) and select Tools.
  2. From the “Settings” page, click on Show advanced settings…
  3. Now under Privacy, click on the button Content settings
  4. Under the JavaScript, select the radio button which says “Do not allow any site to run JavaScript” and click on “Done”.
Bypass Right Click on Chrome
Bypass Right Click on Chrome



For Mozilla Firefox:

Steps to disable JavaScript on Firefox:
  1. From the menu bar, click on Tools -> Options.
  2. From the Options window, switch to Content tab, uncheck the option which says “Enable JavaScript” and click on “OK”.
Bypass Right Click on Mozilla Firefox
Bypass Right Click on Mozilla Firefox


How to Bypass the Right Click Block?

In order to bypass the right-click block or any other restriction imposed by JavaScript, all you need to do is just disable it in the browser and refresh the same page, so that it now reloads without JavaScript functionality. You are now free to right-click on the page, view its source or even copy any of the images that you may want to. Don’t forget to re-enable the JavaScript once again when your job is over. Otherwise lack of JavaScript support may result in unusual rendering of web pages.
Source: GoHacking by Srikanth Ramesh
Tuesday, September 30, 2014
Shellshock Bash Bug Complete List of Vulnerabilities by Hackingloops

Shellshock Bash Bug Complete List of Vulnerabilities by Hackingloops

Shellshock aka Bash Bug vulnerability was discovered just one week back and its growing day by day. Most of security researchers are aware of just two vulnerabilities related to shellshock or bash bug i.e. CVE-2014-6271 and CVE-2014-7169. But my friends there are lot more vulnerabilities that come under the scope of Shellshock bash bug. Today i will share complete list of vulnerabilities which are related to Shellshock bash bug. In our previous two articles, we have learned about basics of shellshock i.e. bash vulnerability and how to patch those. Today we will learn how to test all vulnerabilities related to Shellshock aka bash bug.

Shellshock Bash Bug Complete List of Vulnerabilities and Test String
Shellshock Bash Bug Complete List of Vulnerabilities and Test String



Complete list of Shellshock bash bug vulnerabilities and how to test that you are vulnerable to them:

CVE-2014-6271:


Overview: 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, aka "ShellShock." NOTE: the original fix for this issue was incorrect; CVE-2014-7169 has been assigned to cover the vulnerability that is still present after the incorrect fix.

Testing CVE-2014-6271 that you are vulnerable or not. Open bash prompt and run the below command:

env X='() { :; }; echo "CVE-2014-6271 vulnerable"' bash -c id
If you get "CVE-2014-6271 vulnerable" then it means you are vulnerable, if you get bash error that means your version of bash is not vulnerable.

Impact: Network exploitable, no authentication required for running the exploit, allows unauthorized disclosure of information, allows unauthorized modification and even allows Distributed DOS attack.
Complete details of CVE-2014-6271 vulnerability : NIST



CVE-2014-7169 :


Overview: GNU Bash through 4.3 bash43-025 processes trailing strings after certain malformed function definitions in the values of environment variables, which allows remote attackers to write to files or possibly have unknown other impact 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. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-6271.

Testing CVE-2014-7169 that you are vulnerable or not. Open bash prompt and run the below command:

env X='() { (a)=>\' bash -c "echo date"; cat echo

If you are vulnerable to CVE-2014-7169, then it will create a file named echo in cwd with date in it.

Impact: Network exploitable, no authentication required for running the exploit, allows unauthorized disclosure of information, allows unauthorized modification and even allows Distributed DOS attack.

Complete details of CVE-2014-7169 vulnerability : NIST


CVE-2014-6277 :


Overview: GNU Bash through 4.3 bash43-026 does not properly parse function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code or cause a denial of service (uninitialized memory access, and untrusted-pointer read and write operations) 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. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-6271 and CVE-2014-7169.

How to test you are vulnerable to CVE-2014-6277 or not. Just test the following code in shell:


foo='() { echo CVE-2014-6277 Vulnerable; }' bash -c foo
If you get "CVE-2014-6277 Vulnerable" then it means you are vulnerable. 

This vulnerability causes an attempt to access uninitialized memory leading to reads from, and then subsequent writes to, a pointer that is fully within attacker's control. Basically untrusted pointer use issue leading to remote code execution.

Impact: Network exploitable, no authentication required for running the exploit, allows unauthorized disclosure of information, allows unauthorized modification and even allows Distributed DOS attack.

Complete details of CVE-2014-6277 vulnerability : NIST


CVE-2014-6278 :


Overview: GNU Bash through 4.3 bash43-026 does not properly parse function definitions in the values of environment variables, which allows remote attackers to execute arbitrary commands 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. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-6271, CVE-2014-7169, and CVE-2014-6277.

Red Hat believes that changes introduced via updates RHSA-2014:1306, RHSA-2014:1311, and RHSA-2014:1312 that prevent Bash from defining new functions based on arbitrary environment variables sufficiently mitigate this issue.

The underlying parser flaw has not yet been disclosed and might still exist in latest released bash packages. However Florian Weimer's variables-affix.patch patch applied in Debian prevents exploitation of this issue by making bash only use environment variables with specific names (BASH_FUNC_*()) to define functions from its environment.

How to test you are vulnerable to CVE-2014-6277 or not. Just test the following code in shell:


foo='() { echo CVE-2014-6278 Vulnerable; }' bash -c foo

<br />
If you get "CVE-2014-6278 Vulnerable" then it means you are vulnerable.  In order to patch this Florian patch is available online.

Complete details of CVE-2014-6278 vulneraiblity : NIST


CVE-2014-7186 :


Overview: The redirection implementation in parse.y in GNU Bash through 4.3 bash43-026 allows remote attackers to cause a denial of service (out-of-bounds array access and application crash) or possibly have unspecified other impact via crafted use of here documents, aka the "redir_stack" issue.

How to test you are vulnerable to CVE-2014-7186 or not. Just test by running below string in shell:

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "CVE-2014-7186 vulnerable, redir_stack"

If you get "CCVE-2014-7186 Vulnerable" then you are vulnerable to this.

Impact: Network exploitable, no authentication required for running the exploit, allows unauthorized disclosure of information, allows unauthorized modification and even allows Distributed DOS attack.

Complete details of CVE-2014-7286 vulnerability : NIST



CVE-2014-7187 :


Overview: Off-by-one error in the read_token_word function in parse.y in GNU Bash through 4.3 bash43-026 allows remote attackers to cause a denial of service (out-of-bounds array access and application crash) or possibly have unspecified other impact via deeply nested for loops, aka the "word_lineno" issue.

How to test you are vulnerable to CVE-2014-7186 or not. Just test by running below string in shell:

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"

If you get "CVE-2014-7187 Vulnerable" then it means you are vulnerable to this bug.

Impact: Network exploitable, no authentication required for running the exploit, allows unauthorized disclosure of information, allows unauthorized modification and even allows Distributed DOS attack.

Complete details of CVE-2014-7286 vulnerability : NIST


Recommended Articles related to Bash Bug or Shellshock vulnerability:



That's all for today. In my later articles we learn more about Proof of concept of all vulnerabilities related to Shellshock Bash bug. So keep connected and keep learning.


Designed by Hackingloops.