New Post

Rss

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.
Friday, September 26, 2014
Shellshock Bash Bug in Linux, Unix, Mac OS X Tutorial and Patch

Shellshock Bash Bug in Linux, Unix, Mac OS X Tutorial and Patch

A Critical remotely exploitable vulnerability has been discovered in the widely used Linux and Unix command-line shell, known as Bash, Bash stands for Bourne-Again SHell. It's a computer program that allows users to type commands and executes them. ShellShock Bash Bug left countless websites, servers, PCs, OS X Macs, various home routers, and many more open to the cyber criminals for Injection attack vulnerabilites by altering special environment variables. Bash has a feature where users can set "environment variables" and retrieve them later. This vulnerability exploits bash functionality that evaluates specially formatted environment variables passed to it from another environment. 

An attacker could use this feature to override or bypass restrictions to the environment to execute shell commands before restrictions have been applied.  Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.


ShellShock Bash Bug
ShellShock Bash Bug


The vulnerability (CVE-2014-6271) affects versions 1.14 through 4.3 of GNU Bash and being named as Bash Bug, and Shellshock by the Security researchers on the Internet discussions.
According to the technical details, a hacker could exploit this bash bug to execute shell commands remotely on a target machine using specifically crafted variables. This 22-year-old vulnerability stems from the way bash handles specially-formatted environment variables, namely exported shell functions. When assigning a function to a variable, trailing code in the function definition will be executed.

While bash is not directly used by remote users, but it is a common shell for evaluating and executing commands from other programs, such as web server or the mail server. So if an application calls the Bash shell command via web HTTP or a Common-Gateway Interface (CGI) in a way that allows a user to insert data, the web server could be hacked.

In Simple words, If Bash has been configured as the default system shell, an attacker could launch malicious code on the server just by sending a specially crafted malicious web request by setting headers in a web request, or by setting weird mime types. Proof-of-concept code for cgi-bin reverse shell has been posted below:
http://pastebin.com/raw.php?i=166f8Rjx


This is a serious risk to Internet infrastructure, just like Heartbleed bug, because Linux not only runs the majority of the servers but also large number of embedded devices, including Mac OS X laptops and Android devices are also running the vulnerable version of bash Software. NIST vulnerability database has rated this vulnerability “10 out of 10” in terms of severity.


HOW TO CHECK FOR VULNERABLE SHELL

To determine if a Linux or Unix system is vulnerable, run the following command lines in your linux shell:
env X="() { :;} ; echo Infected" /bin/sh -c "echo completed"

env X="() { :;} ; echo Infected" `which bash` -c "echo completed"
If you see the words "Infected" in the output, then you are at risk.
The string '() { :;}; echo vulnerable" takes advantage of a bug in the way Bash handles environment variables to trick it into treating the string "echo Infected" as a command rather than just a string of letters.

BASH BUG PATCH

You are recommended to disable any CGI scripts that call on the shell, but it does not fully mitigate the vulnerability. 

Many of the major operating system and Linux distribution vendors have released the new bash software versions today, including:



If your system is vulnerable to bash bug, then you are highly recommended to upgrade your bash software package as soon as possible.
Thursday, September 25, 2014
How Hackers hack credit or debit cards password Online

How Hackers hack credit or debit cards password Online

Hello Friends, today i will explain you how the credit cards hack works. How hackers hack the credit cards using packet sniffing and session Hijacking. In this tutorial we will discuss how we can exploit the vulnerability in credit or debit card functionality to hack the credit or debit cards password. Nowadays Internet banking and credit cards are very common methods of funds transfer and online shopping. And the most interesting thing is that it is done over SSL (click here to learn more about SSL). So people always have a misconception that their accounts cannot be hacked as their transactions are secured by extra security Layer i.e. SSL but its quite easy to break the SSL. So its always better to secure your computer and internet connection rather than depending on payment sites . So guys first of all we should know How the Credit cards work and how transactions performed. So guys read on..

First of guys let me tell you its virtually impossible to see the actual data that is transferring during a transaction but using session hijacking and packet sniffing we can achieve that but that also is in the encrypted format so if we are able to get that then we can move to further step to crack the encrypted data. So lets start the tutorial...


What really is attack?
The fatal flaw that enabled the sensitive information to be stolen is possible when an end-user is not properly educated on an easy to do and well-known SSL exploit – SSL MITM. The hackers take benefit of that to get access your sensitive data. As its a great saying PREVENTION IS BETTER THAN CURE. So an properly educated end user is really the requirement so that he can block all loopholes in the system. I have already shared two articles with you about how to secure yourself. First one is Make your computer 100% hacker proof (Click here to read) and other is 10 easy tips to secure your computer(click here to read) .

How the Hack works and How to do it?
First thing i will tell you hacking credit or debit cards is illegal and it will result in serious consequences like 10 years imprisonment and much more. This tutorial is for educational purposes only. I am explaining this tutorial is just to make you aware that how it works.


How the hacker will do it?? suppose you are using a wifi connection to connect to internet. Now what hacker will do it will hack your wifi network ( to learn how to hack wifi click here) and connect to it. He runs a series of utilities to redirect other user’s data through his machine. He runs a number of other utilities to sniff the data, act as an SSL Certificate Server and to be the Man-the-Middle. 
The following diagram shows a very simplified graphic of how your SSL Banking session should work under normal conditions, then how it would work during an attack:

how credit card works,hack credit cards,hack credit cards online,how to hack credit card password

how credit card works,hack credit cards,hack credit cards online,how to hack credit card password

An important concept to grasp here is that a certificate is used to establish the secure SSL connection. This is a good thing, if you have a good certificate and are connecting directly to the website to which you intended to use. Then all your data is encrypted from your browser to the SSL website where the bank’s website will use the information from the certificate it gave you to decrypt your data/credentials. If that is truly the case, then it is pretty darn hard for a hacker to decrypt the data/credentials being transmitted, even if he is able to sniff your data.

This is a bad thing if you have a “Fake” certificate being sent from the hacker, and you are actually connecting to his machine, not directly to the bank’s website. In this case, your credentials are being transmitted between your browser and the hacker’s machine. The hacker is able to grab that traffic, and, because he gave you the certificate to encrypt the data/credentials, he can use that same certificate to decrypt your data/credentials.

 EXACT STEPS TO HACK CREDIT CARDS OR DEBIT CARDS
 The first thing he would do is turn on Fragrouter, so that his machine can perform IP forwarding 

how credit card works,hack credit cards,hack credit cards online,how to hack credit card password

After that, he’ll want to direct your Wi-Fi network traffic to his machine instead of your data traffic going directly to the Internet. This enables him to be the “Man-in-the-Middle” between your machine and the Internet. Using Arpspoof, a real easy way to do this, he determines your IP address is 192.168.1.15 and the Default Gateway of the Wi-Fi network is 192.168.1.1:  


how credit card works,hack credit cards,hack credit cards online,how to hack credit card password

The next step is to enable DNS Spoofing via DNSSpoof

how credit card works,hack credit cards,hack credit cards online,how to hack credit card password

Since he will be replacing the Bank's or Online Store’s valid certificate with his own fake one, he will need to turn on the utility to enable his system to be the Man-in-the-Middle for web sessions and to handle certificates. This is done via webmitm:  

how credit card works,hack credit cards,hack credit cards online,how to hack credit card password

At this point, he is setup and ready to go, he now needs to begin actively sniffing your data passing through his machine including your login information and credit card info. He opts to do this with Ethereal, then saves his capture: 

how credit card works,hack credit cards,hack credit cards online,how to hack credit card password

He now has the data, but it is still encrypted with 128-bit SSL. No problem, since he has the key. What he simply needs to do now is decrypt the data using the certificate that he gave you. He does this with SSL Dump:  

how credit card works,hack credit cards,hack credit cards online,how to hack credit card password

The data is now decrypted and he runs a Cat command to view the now decrypted SSL information. Note that the username is “Bankusername” and the password is “BankPassword”. Conveniently, this dump also shows that the Banking site as National City. FYI, the better, more secure banking and online store websites will have you first connect to another, preceeding page via SSL, prior to connecting to the page where you enter the sensitive information such as bank login credentials or credit card numbers. The reason for this is to stop the MITM-type attack. How this helps is that if you were to access this preceeding page first with a "fake" certificate and then proceeded to the next page where you were to enter the sensitve information, that page where you would enter the sensitive information would not display. That is because the page gathering the sensitive information would be expecting a valid certificate, which it would not receive because of the Man-in-the-Middle. While some online banks and stores do implement this extra step/page for security reasons, the real flaw in this attack is the uneducated end-user, as you'll soon see:

how credit card works,hack credit cards,hack credit cards online,how to hack credit card password

With this information, he can now log into your Online Banking Account with the same access and privileges as you. He could transfer money, view account data, etc.

Below is an example of a sniffed SSL credit card purchase/transaction. You can see that Elvis Presley was attempting to make a purchase with his credit card 5440123412341234 with an expiration date of 5/06 and the billing address of Graceland in Memphis, TN (He is alive!). If this was your information, the hacker could easily make online purchases with your card. 

how credit card works,hack credit cards,hack credit cards online,how to hack credit card password


Also Real Bad News for SSL VPN Admins

This type of attack could be particularly bad for corporations. The reason for this is that Corporate SSL VPN solutions are also vulnerable to this type of attack. Corporate SSL VPN solutions will often authenticate against Active Directory, the NT Domain, LDAP or some other centralized credentials data store. Sniffing the SSL VPN login then gives an attacker valid credentials to the corporate network and other systems.

What an End-User Needs To Know

There’s a big step and end-user can take to prevent this from taking place. When the MITM Hacker uses the “bad” certificate instead of the “good”, valid certificate, the end-user is actually alerted to this. The problem is that most end-users don’t understand what this means and will unknowingly agree to use the fake certificate. Below is an example of the Security Alert an end-user would receive. Most uneducated end-users would simply click “Yes”… and this is the fatal flaw: 

how credit card works,hack credit cards,hack credit cards online,how to hack credit card password

By clicking “Yes”, they have set themselves up to be hacked. By clicking the “View Certificate” button, the end-user would easily see that there is a problem. Below are examples of the various certificate views/tabs that show a good certificate compared to the bad certificate:  

how credit card works,hack credit cards,hack credit cards online,how to hack credit card password

how credit card works,hack credit cards,hack credit cards online,how to hack credit card password

how credit card works,hack credit cards,hack credit cards online,how to hack credit card password
Left One Good Certificate and right one fake certificate

How an End-User Can Prevent This


  • Again, the simple act of viewing the certificate and clicking “No” would have prevented this from happening.
  • Education is the key for an end-user. If you see this message, take the time to view the certificate. As you can see from the examples above, you can tell when something doesn’t look right. If you can’t tell, err on the side of caution and call your Online Bank or the Online store.
  • Take the time to read and understand all security messages you receive. Don’t just randomly click yes out of convenience.

How a Corporation Can Prevent This


  • Educate the end-user on the Security Alert and how to react to it.
  • Utilize One Time Passwords, such as RSA Tokens, to prevent the reuse of sniffed credentials.
  • When using SSL VPN, utilize mature products with advanced features, such as Juniper’s Secure Application Manager or Network Connect functionality. 
Tuesday, September 23, 2014
SQL Injection by Untrusted Data Parsing - INJECTION ATTACKS - PART 3

SQL Injection by Untrusted Data Parsing - INJECTION ATTACKS - PART 3

In our previous article we have learned about "SQL Injection basics" which is #1 among Injection attacks. We have learned that SQL Injection majorly occurs because of three things : 
1. Untrusted Data Parsing
2. Dynamic Queries Creation from user data.
3. Escape Sequences, Encoded Character Set Parsing.

Today we are going to learn about SQL Injection caused by Untrusted Data Parsing. How an data from untrusted source can result into SQL Injection flaw.

SQL Injection by Untrusted Data parsing
SQL Injection by Untrusted Data parsing

What is untrusted data?

Here’s a simple rule which is applicable for all web applications. If you are not sure that incoming data doesn't contain attacks, then it’s untrusted. All the data from the browser, including URL parameters, form fields, headers, and cookies are all untrusted. But so are other sources like flat files, web services, databases, etc… Even internal sources of data can (and probably should) be considered untrusted.
Most untrusted data comes in the form of a "string" without any restrictions on the size, characters, format, or pattern. 


SQL Injection Caused by Untrusted Data Parsing:

Most web applications or web pages use web forms or text boxes(like search box etc.) to accept data from users. Developers consider the data coming through these text boxes or web forms as trusted data and use this data in their programs for some other functionality. But in real world scenario, the data from web forms or text boxes should not be considered as trusted or safe because data can come from untrusted sources like unvalidated users, network connections and other untrusted sources. The data coming from web forms or text boxes must be sanitized before using it further in the web application programs or i would advise that it should be validated even before sending to parser.

Untrusted data must be sanitized because subsystem might not be prepared to handle this malformed data input. Also this untrusted data may even contain the Injection attack attached with it.

Ideally data must be validated before it is being sent for parsing or interpretation. If it contains anything suspicious which you think that your sub program will not be able to handle, then it must be sanitized before sending for parsing.

Consider an database which have a users table where user names and passwords are stored to authenticate users to use the web application. 


SELECT * FROM users WHERE username='+USERNAME+' AND
                            password='+PASSWORD+'

Now this query will work successfully when user supplies correct username and password.

Now once user provides correct username and passwords, this SQL works perfectly but in case user has supplied some special characters or special sequences or some random data in username or password or both. If the user input is not sanitized properly then it will result into SQL Injection attack. 
Characters like '(single quote), "(double quote), -(single dash) , --(double dash), =(equals), (, {, /* etc.. are part of SQL database language syntax, these characters provides different functionality. So if any user passes any of escape sequences or data type which SQL parser understands then SQL will not work as it should. It may result into error or just successful execution. Whatever is the result, but one thing is confirmed that web application or website is vulnerable to SQL Injection.

Now say i passes user123' or '1'='1 in the username, then the SQL will become something like:

SELECT * FROM users WHERE username='user123' or '1'='1' AND password='PASSWORD'

Now if user123 is an valid user then this SQL will fetch the user123 from the table and password will never be checked because statements after 'OR' is not being tested according to syntax of SQL. So user123 will able to login into website if the user123 is a valid user.

Now suppose i pass ' OR '1'='1 in password and pass null or spaces in username, now SQL will become something like :

SELECT * FROM users WHERE username='' AND password='' OR '1'='1'
Now this OR will allow 1'='1 always true condition i.e. whatever is the username or password it doesn't matter because 1'='1 is always true condition. So the hacker will login into website without any credentials at all.


This is the reason why Developer needs to sanitize the input Data received from web form or text boxes. None of the data can be trusted blindly, every field needs to be validated properly so that the untrusted data will not alter the actual behavior of the existing SQL and its functionality.

This type of SQL injection is also referred as Blind SQL Injection.

That's it for today. In later article we learn other two causes of SQL Injection in detail and then we will learn how to protect ourselves from these type of vulnerabilities. 

Monday, September 22, 2014
SQL Injection - INJECTION ATTACKS - OWASP #1 VULNERABILTY - PART 2

SQL Injection - INJECTION ATTACKS - OWASP #1 VULNERABILTY - PART 2

In previous article "INJECTION ATTACKS TUTORIAL - OWASP #1 VULNERABILTY - PART 1", we have learned about Injection attack basics and type of Injection attacks. Today we will learn about SQL Injection basics. As we have learned in previous article that Injection means adding something extra into code which changes the actual behavior of the code or Query. Similarly SQL Injection means adding something extra into SQL query which result into deviation of SQL from actual behavior. 

SQL Injection - Injection Attacks
SQL Injection - Injection Attacks


What is SQL Injection?

SQL injection is an attack in which malicious code is inserted into strings that are later passed to an instance of SQL Server for parsing and execution. SQL Injections operate by injecting data into a web application which is then used in SQL queries. The data usually comes from untrusted input such as a web form. However, it’s also possible that the data comes from another source including the database itself. Programmers will often trust data from their own database believing it to be completely safe without realizing that being safe for one particular usage does not mean it is safe for all other subsequent usages. Data from a database should be treated as untrusted unless proven otherwise, e.g. through validation processes.

If successful, an SQL Injection can manipulate the SQL query being targeted to perform a database operation not intended by the programmer.


How SQL Injection happens?

Normally what happens in web applications, Coders embed their SQL queries into web pages in order to submit and retrieve data to/from databases, which is a normal practice in corporate world. When visitors visit these web applications or websites which contains embedded SQL queries, these SQL queries are parsed into HTML formatting i.e. invisible to regular user. So a regular user cannot view what SQL is embedded into web application or web page. Now what Hackers do which normal regular user doesn't? Hackers inspect's the web page to check how particular value is being retrieved, how particular search form or text box field(can be login box or any input) is validated and much more. During this inspect, if Hacker encounters some type of error message or abend, then this confirms web application is vulnerable to Injection flaws. But how exactly hacker validates these things? For checking SQL injection its not a rocket science, they just tests values lies in Special Character Set, Escape Sequence Set and last but not the least Encoded value of previous two. 

SQL injection occurs when any of below things happen:

1. Data enters a program from an untrusted source.
2. SQL Injection can attack those SQL queries which are dynamically created by using some inputs from either program or user or some functionality.
3. SQL Injection can also occur if escape sequences and types are not handled properly in the SQL query.


Consider the following example :

$db = new mysqli('localhost', 'username', 'password', 'mydatabase');
$result = $db->query(
    'SELECT * FROM transactions WHERE user_id = ' . $_POST['user_id']
);
Above query has plenty of Injection flaws associated with it. Things which are wrong in it :
1. First of all contents of POST are not validated to ensure that its a valid User ID.
2. We are allowing an untrusted source to tell us which user_id to use - an attacker could set any valid user_id they wanted to. Most developers believe that just using the POST to hide user_id will work. But they are wrong because hacker can submit anything into the forms. 
3. We have not escaped the user_id or passed it to the query as a bound parameter which also allows the attacker to inject arbitrary strings that can manipulate the SQL query given we failed to validate it in the first place.

The above three issues are quite a bit common among all web applications. We will discuss each one of them in detail in later articles.

That's it for today, we will learn SQL injection and its reasons how does SQL injection occurs and how to fix SQL Injection in later articles. So keep connected.
 
Copyright © 2012 Learn How to Hack - Best Online Ethical Hacking Website All Right Reserved
Designed by Hackingloops.