How Hackers hack credit cards or debit cards password Online
How Hackers hack credit cards or debit cards password Online
Hello Friends, today I will explain you how a credit card hack works: how to hack 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 card’s password. Nowadays, fund transfers and online shopping are done using primarily internet banking and credit cards. Interestingly, those methods utilize SSL (click here to learn more about SSL). People tend to believe that their accounts cannot be hacked because their transactions are secured by extra security layer, SSL, but it’s actually quite easy to break the SSL. It is always better to secure your computer and internet connection rather than depend on payment sites. So first, we should know how credit cards work and how transactions are performed. Please read on.
First, know that it’s virtually impossible to see the actual data that is transferred during a transaction, but by using session hijacking and packet sniffing we can achieve see the data in an encrypted form.
What really is attacked?
The fatal flaw that enables sensitive information to be stolen occurs when an end-user is not properly educated on the easily executable, well-known SSL exploit: SSL MITM. Hackers take advantage of that to get access to your sensitive data. A great saying applies here: PREVENTION IS BETTER THAN A CURE. The only thing required to block the loopholes in the system is a properly educated end user. I have already shared two articles with you about how to secure yourself. The first 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:
PLEASE NOTE THAT hacking credit or debit cards is illegal and will result in serious consequences, including imprisonment. This tutorial is for educational purposes only. I am explaining this tutorial to make you aware of how it works.
Suppose you use a WiFi connection to connect to internet. A hacker will hack your WiFi network and connect to it. He will then run a series of utilities to redirect other user data through his machine, followed by more utilities to sniff the data, acting as an SSL Certificate Server 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:
It is important to know that a certificate is used to establish the secure SSL connection. This is a good thing if you have the right certificate and are connecting directly to the website 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 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
His first step would be to turn on Fragrouter, so that his machine can perform IP forwarding
After that, he’ll want to direct your WiFi network traffic to his machine, rather than 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 simple technique, he determines your IP address is 192.168.1.15 and the Default Gateway of the WiFi network is 192.168.1.1:
The next step is to enable DNS Spoofing via DNSSpoof:
Since he will be replacing the bank 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:
At this point, he is ready to go. Now he needs to begin actively sniffing your data passing through his machine, including your login and credit card information. He opts to do this with Ethereal, then saves his capture:
He now has the data, but it is still encrypted with 128-bit SSL. No problem, since he has the key. What he needs to do now is simply decrypt the data using the certificate that he gave you. He does this with SSL Dump:
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 reveals the banking site as National City. FYI, the better, more secure banking and online store websites will have you first connect to another, preceding page via SSL, prior to connecting to the page where you enter sensitive information such as bank login credentials or credit card numbers. The reason for this is to stop the MITM-type attack. This helps because if you were to access this preceding page first with a “fake” certificate the next page where you were to enter the sensitive information would not display. 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:
With this information, he can now log into your online bank 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.
Bad News for SSL VPN Admins
This type of attack could be particularly bad for corporations, because 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 an 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:
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:
 |
| 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.
To get our free books emailed to you and more detailed information on these credit and debit card hacking concepts on an ongoing basis you can join our list. Please remember that this is all for educational purposes only and you should never hack someones debit or bank cards. This wrong morally and illegal as well.
Today we will learn about SQL Injection by Untrusted Data Parsing. 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 by Untrusted Data Parsing. How an data from untrusted source can result into SQL Injection flaw.
 |
| 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 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.
Today we will learn about SQL Injection basics. In previous article “INJECTION ATTACKS TUTORIAL – OWASP #1 VULNERABILTY – PART 1”, we have learned about Injection attack basics and type of Injection attacks. 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 |
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.
Injection attacks are the most popular attacks among hackers, topping OWASP’s Top 10 Vulnerability list every year. Injection is an entire class of attacks that rely on injecting data into a web application in order to facilitate the execution or interpretation of malicious data in an unexpected manner. So friends, let’s learn about injection attacks from the very beginning.
Injection attacks are popular because of its 4 basic things:
1. Easy to exploit
2. Hard to secure (i.e. compromise on dynamic query usage).
3. Coder’s negligence ( i.e. deciding character set, stored procedures usage issues, handling escape sequences etc.).
4. Unawareness of secure coding practices among developers.
 |
| Injection Attacks |
So its not wrong to say:
” Security does not suffer because of Hackers, it actually suffers due to lack of secure coding awareness among Coders”.
In this Injection Attacks Tutorial, I will share different types of the most common injection attacks that are quite common among Hackers. In the future, I will share in detail about these injection techniques and how to prevent these attacks.
What is Injection?
Injection, as the word implies, is injecting something extra into the code. Injection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database, or change data on a web application or website. Injection attacks are dangerous because they are an open windows for hackers to enter in your system through your web interface and do whatever they like i.e. delete tables, modify databases, exposing your users information, or even get hold of your corporate network.
When does an injection attack occurs? Where does it usually occur? What is its impact?
Injection attacks occurs when an application sends untrusted data ( i.e. data which is not intended to behave as it should or simply we can say data which the system is not expecting) to an interpreter or compiler. Injection flaws are usually found in SQL, LDAP, Xpath, OS commands(i.e. shell command Injection), XML parsers, SMTP Headers, program arguments, etc. Injection can result in data loss or corruption, lack of accountability, or denial of access. Injection can sometimes lead to complete host takeover. If your web application uses any of these, then there are chances of SQL Injection.
Different Type of Injection Attacks:
1. SQL Injection ( Blind SQL Injection and SQL Injection)
2. Code Injection (or Remote file Inclusion)
3. Log Injection
4. Directory Traversal (or Path Traversal)
5. XML or xPath Injection
6. SOAP Injection
7. Command Injection
8. LDAP Injection
9. SSI Injection (Server Side Inclusion)
10. Buffer Overflow
11. String Format Attack
We will discuss all above topics in detail in later articles. So keep connected and enjoy learning.
About Gamemaker gafoor.2
No comments