New Post

Rss

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.


Sunday, September 28, 2014
How to Fix Shellshock Bash Vulnerability Tutorial

How to Fix Shellshock Bash Vulnerability Tutorial

Shellshock or the "Bash Bug" vulnerability allows remote attackers to execute arbitrary code given certain conditions, by passing strings of code following environment variable assignments. Because of Bash's ubiquitous status amongst Linux, BSD, and Mac OS X distributions, many computers are vulnerable to Shellshock; all unpatched Bash versions between 1.14 through 4.3 (i.e. all releases until now) are at risk. Today we will learn how to fix Shellshock bash Vulnerability on servers.

The Shellshock vulnerability can be exploited on systems that are running Services or applications that allow unauthorized remote users to assign Bash environment variables. Examples of exploitable systems include the following:

  • Apache HTTP Servers that use CGI scripts (via mod_cgi and mod_cgid) that are written in Bash or launch to Bash subshells
  • Certain DHCP clients
  • OpenSSH servers that use the ForceCommand capability
  • Various network-exposed services that use Bash
Complete description of the bug/Vulnerability can be found at CVE-2014-6271 and CVE-2014-7169.

How to Fix Shellshock Bash Vulnerability Tutorial
How to Fix Shellshock Bash Vulnerability Tutorial


Today i will show you how to test if your machines are vulnerable to shellshock aka Bash Bug and, if they are, how to update Bash to remove the vulnerability.


How to check that you are vulnerable to Bash bug or shellshock bash bug?


To check you system, first of all open the Bash prompt and execute the below command in bash prompt:

env X="() { :;} ; echo Bash is Infected" /bin/sh -c "echo completed"


env X="() { :;} ; echo Bash is Infected" `which bash` -c "echo completed"


env VAR='() { :;}; echo Bash is Infected' bash -c "echo completed"


If you see the output as "Bash is Infected", your version of Bash is vulnerable and should be updated.

The "echo Bash is Infected" portion of the command represents where a remote attacker could inject malicious code; arbitrary code following a function definition within an environment variable assignment.

If your output does not include "Bash is Infected", then you bash version is not vulnerable to Bash Bug or shellshock. It may look something like this :


bash: warning: VAR: ignoring function definition attempt
bash: error importing function definition for `VAR'
Bash Test

If your bash is vulnerable, then please find below tasks to fix Shellshock Bash Vulnerability.


How to test Remote sites or CGI Scripts that they are vulnerable to shellshock Bash Bug or Not?

If you want to test if websites or specific CGI scripts are vulnerable, use this online tool to test the website or script for shellshock or bash bug: 


If you wish to test complete website i.e. from root, enter the website url into text box below "Test Web Site Root and Known URL Attack Points" and press begin test.


How does above scanner works?
Bash Bug scanner test a website by building a special crafted header and if it get an answer back from website, then you are vulnerable to Shellshock. We won't collect any critical information from any scanned website. 
Also, please have in mind that your website might still be vulnerable in a particular page, ussualy found in /cgi-bin/* folder or from special private file that is using bash shell commands. 

If you only wish to test a specific CGI script then use the text box below "Test Specific Script URL" and press on begin test.

The above tool only uses the HTTP exploits. If you want to test your website or CGI scripts for Ping exploits, then please use below online tool :


Fix Bash Bug or Shellshock Vulnerability - Update Bash:


The easiest way to fix the vulnerability is to use your default package manager to update the version of Bash. To update Bash on various Linux distributions, including Ubuntu, Debian, CentOS, Red Hat, and Fedora please follow below instructions:

APT-GET: Ubuntu / Debian


On Ubuntu / Debian distributions, Update Bash to the latest version available via apt-get:

sudo apt-get update && sudo apt-get install --only-upgrade bash

Now check your system vulnerability again by running the command as mentioned above.


YUM: CentOS / Red Hat / Fedora


On CentOS or Red Hat or Fedora distributions, Update Bash to the latest version available via the yum:

sudo yum update bash

Now check your system vulnerability again by running the command as mentioned above.


Apple has not released the patch for OS X user yet but soon we will be having patch for Apple OS X too.


That's it for today. If you have any issues, feel free to ask in form of comments.
Saturday, September 27, 2014
How Hackers Hack Bank Accounts and Personal Information

How Hackers Hack Bank Accounts and Personal Information

Most people learning hacking always have a keen interest in knowing that how they can hack bank accounts of other people. But most of them find it pity much difficult such that now they have made a perception that bank account information like credit cards or debit cards or net banking passwords cannot be hacked. Its truth to an extent that hacking Banking account information and credit or debit cards passwords is most difficult and almost impossible part. Today i will discuss with you why hacking bank account information is tough and always considered as impossible task. We will also discuss the different methods that hackers use to hack bank account information nowadays.

how to hack bank details

I am quite sure that almost everybody using internet nowadays uses that internet to pay online bills, book reservation tickets, purchase online things or simply transfer money i.e. involved in at least some kind of online transaction that is related to money i.e. banking information, credit or debit card payments or simply Net banking. Most of banks uses SSL(Secured Sockets Layer) connection (to read more click here )and at least 128 or 256 bit encryption for online banking and transaction purposes. Also now an extra layer of security is introduced that is called transaction PIN layer means for each and every online transaction you have to enter your passwords and during transaction you have to enter PIN (a type of password that varies 4 to 8 chars in length). Thus bank do alot of work to protect your secret information and credentials from the eyes of the world that may wish to gain access to your such a vital information.

Below example will illustrate you how powerful the encryption method is:

  • 40 bit encryption, means there are  2^40 possible keys that could fit into the lock that holds your account information. That means there are many billions of possible keys that means brute forcing such thing is imposable. Only thing now left is dictionary and rainbow attack. But its not only the security measure that banks used to secure there information. Also its only 40 bit encryption.
  • 128 bit encryption means there are 2^88 times as many as key combinations that are being possible for 40 bit encryption.That means a computer would require exponentially more processing power and time than for 40-bit encryption to find the correct key.

That's a very powerful method of encrypting data sent from your machine to bank machine. But unfortunately it's all is useless to you once your system has been compromised or hacked.

Now How these all security Encryption can be bypassed and your system can be compromised online. There are several methods for exploiting and bypassing such account information. Note : This is for educational purposes only( For more details read Disclosure). 

Some of them are:

1. Phishing : We have discussed phishing on this website alot of times in tutorials like how to hack Gmail accounts password or hacking Facebook accounts and others too. But for new Guys I explain what is Phishing.  Phishing is a technique to hack password and login details of a particular website using Phish pages. Now what are Phish pages? Phish Pages are simply the fake pages that looks the original webpage. The only difference between phish page and original page is the Address bar link (for normal user) and redirection post and get method( inside source for advanced users). How to identify a fake link? Just check the address bar URL for a fake page or Phish page it will be showing different URL than the original URL. Also if you want that everything is done automatically then install a Web security tool bar in your browser (AVG and Crawler web security tool bars are good choices) as it detects the phishing automatically and do not allows you to visit Phishing Pages.

2. Trojans: Trojans are type to viruses that steals your information. It can be in many forms like Keyloggers or RAT's( remote administration tools). What a keylogger do is that it monitors all the keys that you have pressed from your physical keyboard and stores them in form of a log and send these details to hackers. RAT's are advanced form of Keyloggers that remotely monitors all your activities where keylogger is simply a functionality. Using RAT hacker can connect to your system anonymously i.e. without your information when you are online. RAT's have a huge list of functionality and these are best type of hacking tools available in the market. Now How you will protect yourself from Keyloggers? Just keep your antivirus updated and install Keyscramber that encrypts your keystrokes. Now why i haven't mentioned RAT there is because once the RAT enters your system you cannot do anything other than formatting your system. So RAT's attack only can be prevented before they enters in your system. For preventing from RAT's Please do not download any software or cracks or keygens online. Also avoid downloading freewares from new websites use certified websites only like CNET, filehippo etc.. Also please avoid testing fake hack tools (recommended for hackers) because most hacking tools have keylogger and RAT's attached to them. Test it under secured conditions like on Virtual Users. Means install virtual operating system user Virtual PC or Virtual Box and then test them there.

3. Session Hijacking: Most of us uses Wireless Networks to access the internet and data flow in form of packets and channels. And we know that Wireless are easier to hack as they have very weak encryption. So Hackers hack the wireless networks and using session Hijacking they take control of the internet data transfer and redirects the user from original path to their path. Means suppose you are visiting Google or Gmail or Facebook, then hacker when get access then he can redirect you to any of the page and capture you account details. Packet sniffing is another way to hack the account information and credentials using the wireless networks where Hackers captures packets and decrypt these encrypted information to get the information in form of plain text. Now how you will prevent this? Its also pity simple to prevent this, you need to hide you SSID and BSSID from being discovered by the other networks. Just leave the SSID or BSSID empty for that. Now hacker will not be able to discover your wireless router so he will not been able to hack it.

RECOMMENDED ARTICLES FOR YOU:


That's all for today friends, I hope you all have liked the discussion about Why Hacking Bank Account is tough. I know its not tough but its tough if user is aware  how its done because he can fix all loopholes and vulnerabilities.
If You like my posts or have any doubts please post your comments.
Designed by Hackingloops.