Beginner Guide to Google Dorks (Part 1)

Google is a tool which helps in finding what one is looking for. Google operators are the terms provided to us for making our search easy and refined. These operators also termed as advanced Google operators provides the exact information. It reduces the time of search by instantly providing the information as we don’t have to move from one page to another one. These operators’ works as a query.

The basic syntax is->operator: term to be searched

Some of these operators are enlisted below:

Intitle

e.g->intitle:hackingarticles

This query will return the pages which include the term “hackingarticles”in it.

inurl

e.g->inurl:hackingarticles

This query will return the pages which includes the term hackingarticles in its URL.

Related

e.g->related:pentest

It will provide the result related to our query i.e.pentest

Allintext

This operator will perform the task of locating a particular string in the text of the page .

e.g->allintext:rajchandel

The above given query will return only those pages which include the terms rajchandel in the text.

Filetype

e.g->www.kccitm.edu.in filetype:pdf

This query searches the file of the provided extension only. The above given query will search only the pdf files present on the given site.

Cache

This operator will show the cached version of the webpage instead of the current one. This operator is followed by the URL of the page of which we want to have the cached version.

Define

This operator provides the definition of a term as a result.

e.g->define:pentest.

Link

This operator will help you to search the pages which links to other pages. This operator is provided a URL instead of a term to search.

e.g->link:www.kccitm.edu.in

Allintitle

This operator is slightly different from the intitle operator.

In intitle operator there was no compulsion of the term in the query to be present in the title whereas in allintitle operator this is must for the term in the query to be present in the title.

e.g->allintitle:hackingarticles

ADVANTAGES:

1. These operators provides the exact results which we are looking for.

2. There is no wastage of time as there is no redirecting from one page to another.

3. There are different operators for every task to perform i.e. Phonebook to obtain residential and business phone numbers and so on.

DISADVANTAGES

1. There are some operators which do not mix with another in the same query, for e.g, allintitle,allintext operators .

BASIC GUIDELINES TO USE GOOGLE OPERATORS

1. There should be no space between the operators, colon and the search as violating this rule will not generate the desired result.

2. If the search term is a phrase then there should be no space between the operator, colon as well as the first quote of the phrase.

3. Some advanced operators cannot be combined with others such as allintitle, allintext etc.

4. Boolean operators and special characters such as ‘OR’ and ‘+’ can be used in the queries but they should not be placed in the way of the colon.

HOW HACKERS USE GOOGLE OPERATORS

Everyone  use google but most of them don’t know to make use of google.

Google operators are very famous among hackers and they take full benefit of it.

Sensitive information needed by hackers which are not easily retrieved through common search can be produced by the help of google operators.

If a hacker wants to retrieve a pdf file of a particular site then he/she has to use the operator “Filetype” with the URL as well  as the extension of the file.

A hacker can retrieve the site of the specified domain with the help of the operator “site”. This operator is followed by the separating colon and the  domain name.

It’s an easy tool for a hacker to get the exact outcome in just a click.

Thanks for reading the article. In next article we will be discussing about more google dorks with web penetration testing.

Author: Shrishtee Suman is Technical Writer in hacking Articles she is pursuing B. Tech in CS. Her interests are mainly in Web Penetration testing and vulnerability research. Contact Here

Beginner Guide to Understand Cookies and Session Management

Cookie is a small piece of data sent by a server to a browser and stored on the user's computer while the user is browsing. Cookies are produced and shared between the browser and the server using the HTTP Header.

It Allows server store and retrieve data from the client, It Stored in a file on the client side and maximum size of cookie that can stored is limited upto 4K in any web browser. Cookies have short time period because they have expiry date and time as soon as browser closed.

Example- when you visit YouTube and search for Bollywood songs, this gets noted in your browsing history, the next time you open YouTube on your browser, the cookies reads your browsing history and you will be shown Bollywood songs on your YouTube homepage

Creating cookie

The setcookie() function is used for the cookie to be sent along with the rest of the HTTP headers.

When developer creates a cookie, with the function setcookie, he must specify atleast three arguments. These arguments are setcookie(name, value, expiration);

Cookie Attributes

1.      Name: Specifies the name of the cookie

2.      Value: Specifies the value of the cookie

3.      Secure: Specifies whether or not the cookie should only be transmitted over a secure HTTPS connection. TRUE indicates that the cookie will only be set if a secure connection exists. Default is FALSE

4.      Domain: Specifies the domain name of the cookie. To make the cookie available on all subdomains of example.com, set domain to "example.com". Setting it to www.example.com will make the cookie only available in the www subdomain

5.      Path: Specifies the server path of the cookie. If set to "/", the cookie will be available within the entire domain. If set to "/php/", the cookie will only be available within the php directory and all sub-directories of php. The default value is the current directory that the cookie is being set in

6.      HTTPOnly: If set to TRUE the cookie will be accessible only through the HTTP protocol (the cookie will not be accessible by scripting languages). This setting can help to reduce identity theft through XSS attacks. Default is FALSE

7.      Expires: Specifies when the cookie expires. The value: time ()+86400*30, will set the cookie to expire in 30 days. If this parameter is omitted or set to 0, the cookie will expire at the end of the session (when the browser closes). Default is 0

Necessity of Cookies

Cookies can be used for various purposes –

§  Identifying Unique Visitors.

§  Http is a stateless protocol; cookies permit us to track the state of the application using small files stored on the user’s computer.

§  Recording the time each user spends on a website.

Type of cookies

Session Cookie

This type of cookies dies when the browser is closed because they are stored in browser’s memory. They’re used for e-commerce websites so user can continue browsing without losing what he put in his cart. If the user visits the website again after closing the browser these cookies will not be available. It is safer, because no developer other than the browser can access them.

Persistent Cookie

These cookies do not depend on the browser session because they are stored in a file of browser computer. If the user closes the browser and then access the website again then these cookies will still be available. The lifetime of these cookies are specified in cookies itself (as expiration time). They are less secure.

Third Party Cookie

A cookie set by a domain name that is not the domain name that appears in the browser address bar these cookies are mainly used for tracking user browsing patterns and/or finding the Advertisement recommendations for the user.

Secure Cookie

A secure cookie can only be transmitted over an encrypted connection.  A cookie is made secure by adding the secure flag to the cookie. Browsers which support the secure flag will only send cookies with the secure flag when the request is going to a HTTPS page.

HTTP Only Cookie

It informs the browser that this particular cookie should only be accessed by the server. Any attempt to access the cookie from client script is strictly prohibited. This is an important security protection for session cookies.

Zombies Cookie

A zombie cookie is an HTTP cookie that is recreated after deletion. Cookies are recreated from backups stored outside the web browser's dedicated cookie storage.

Sessions

PHP session: when any user made any changes in web application like sign in or out, the server does not know who that person on the system is. To shoot this problem PHP session introduce which store user information to be used across several web pages.

Session variables hold information about one single user, and are exist to all pages in one application.

Example: login ID user name and password.

Session ID

PHP code generates a unique identification in the form of hash for that specific session which is a random string of 32 hexadecimal numbers such as 5f7dok65iif989fwrmn88er47gk834 is known as PHPsessionID.

A session ID or token is a unique number which is used to identify a user that has logged into a website. Session ID is stored inside server, it is assigns to a specific user for the duration of that user's visit (session). The session ID can be stored as a cookie, form field, or URL.

Explanation:

Now let’s have a look over this picture and see what this picture says:

In given picture we can clearly see there are three components inside it: HTTP Client, HTTP server and Database (holding session ID).

Step1: client send request to server via POST or GET.

Step2: session Id created on web server. Server save session ID into database and using set-cookie function send session ID to the client browser as response.

Step3: cookie with session ID stored on client browser is send back to server where server matches it from database and sends response as HTTP 200 OK.

Session hijacking

As we know different users have unique session ID when an attacker sniff the session via man-in-middle attack or via XSS and steal session ID or session token this is called session hijacking. When attacker sends the stealing session ID to web server, server match that ID from database stored session ID. If they both matched to each other then the server reply with HTTP 200 OK and attacker get successfully access without submitting proper Identification.

Session hijacking tutorial

For this tutorial I have targeted DVWA, here cookie name is dvwa Session.

Note: session ID for this page will change every time when we will close the browser.

Now capture the browser request using burp suite.

From given image we can see the cookie holds PHPSESSID P38kq30vi6arr0b321p2uv86k0; now send this intercepted data into repeater to observe its response.

In response you can see the highlighted data show set –cookie: dvwaSession =1 more over HTTP 200 OK response from server side.

According to developer each time a new sessionID will generate by server each time, but attacker sniff this session ID P38kq30vi6arr0b321p2uv86k0 for unauthorized login.

Next time we receive another session id when data is intercepted through burp suite i.e. PHPSESSID= gutnu601knp4qsrgfdb4ad0te3, again send this intercepted data into repeater to observe its response.

But before we perceive its response, replace new PHPSESSID from old PHPSESSID.

From given image you can observe we have replaced the SESSION ID and then generate its response in which set –cookie: dvwaSession =6 and HTTP 200 OK response from server side.  

Now change the value inside intercepted data and then forward this request to the server.

Session Vs cookies

Session	Cookies
Data are stored on Server	Data are stored in Client’s Browser
Sessions Data are more secure because they never travel on every HTTPRequest	Travel with each and Every HTTP request
You can store Objects (Store Large Amount of Data)	You can store strings type (Max File Size 4 kb)
Session Cannot be used for Future Reference	Cookies are mostly used for future reference

Beginner Guide to Insecure Direct Object References

Insecure Direct Object References (IDOR) has been placed fourth on the list of OWASP Top 10 Web application security risks since 2013. It allows an authorized user to obtain the information of other users, and could be establish in any type of web applications. Basically it allows requests to be made to specific objects through pages or services without the proper verification of requester’s right to the content.

OWASP definition: Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact that the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.

The Application uses untested data in a SQL call that is accessing account information.

Let consider a scenario where a web application allow the login user to change his secret value.

Here you can see the secret value must be referring to some user account of the database.

Currently user bee is login into web server for changing his secret value but he is willing to perform some mischievous action that will change the secret value for other user.

Using burp suite we had captured the request of browser where you can see in the given image login user is bee and secret value is hello; now manipulate the user from another user.

SQLquery = "SELECT * FROM useraccounts WHERE account = ‘bee’;

Now let’s change user name into raj as shown in given image. To perform this attack in an application it requires atleast two user accounts.

SQLquery = "SELECT * FROM useraccounts WHERE account = ‘raj’;

Great!!!  We have successfully changed the secret value for raj.

Note: in any official website the attacker will replace user account from admin account.

Let take another scenario that look quite familiar for most of IDOR attack.

Many times we book different order online through their web application for example bookmyshow.com for movie ticket booking.

Let consider same scenario in bwapp for movie ticket booking, where I had book 10 tickets of 15 EUR for each.

Now let’s confirm it and capture the browser request through burp suite.

Now you can see we have intercepted request where highlighted text contains number of tickets and price of one ticket i.e 15 EUR it means it will reduce 150 EUR from my (user) account; now manipulate this price from your desire price.

I had changed it into 1 EUR which means now it will reduce only 10 EUR from account, you can observe it from given image then forward the request.

Awesome!!! We had booked the 10 tickets in 10 EUR only.

Beginner Guide to OS Command Injection

The dynamic Web applications may make the most of scripts to call up some functionality in the command line on the web server to process the input that received from the client and unsafe user input may led to OS command injection.  OS Command injection is refer as shell injection attack arise when an attacker try to perform system level commands through a vulnerable application in order to retrieve information of  web server or try to make unauthorized access into server .

Impact Analysis

Impact: Critical

Ease of Exploitability: Medium

Risk Rating: High

In this attack the attacker will inject his unwanted system level command so that he can fetch the information of web server; for example: ls , whoami , uname -a and etc.

Let’s consider a scenario where web application allows user to PING an IP other user so that it get confirms that the host connection is alive. Through given screenshot it is clear what will be output when host IP will submit.

Verify parameters to inject data

The following parameters should be tested for command injection flaws, as the application may be using one of these parameters to build a command back at the web server:

·         GET: In this method input parameters are sent in URLs.

·         POST: In this method, input parameters are sent in HTTP body.

·         HTTP header: Applications frequently use header fields to discover end users and display requested information to the user based on the value in the headers.

Some of the important header fields to check for command injection are:

·         Cookies

·         X-Forwarded-For

·         User-agent

·         Referrer

METACHARACTER

Using vulnerability scanner attacker come to know that current web application is vulnerable to command injection and try injecting system level unwanted command using Meta character.

Metacharacter are symbolic operators which are use to separate actual command from unwanted command. The ampercent (&) was used as a separator that would divide the authentic input and the command that you are trying to inject.

It will more clear in following image where attacker will inject his payload dir using metacharacter that retrieve present directory of web server.  

As result it will dump following output as shown in given image where it has validated wrong user input.

OS Command Injection Operators

The developer possibly will set filters to obstruct the some metacharacter. This would block our injected data, and thus we need to try out with other metacharacters too, as shown in the following table:

Operators	Description
;	The semicolon is most common metacharacter used to test an injection flaw. The shell would run all the commands in sequence separated by the semicolon.
&	It separates multiple commands on one command line. It runs the first command then the second command.
&&	It runs the command following  && only if the preceding command is successful
||(windows)	It run the command following || only if the preceding command fails. Runs the first command then runs the second command only if the first command did not complete successfully.
|| ( Linux)	Redirects standard outputs of the first command to standard input of the second command
‘	The unquoting metacharacter is used to force the shell to interpret and run the command between the backticks. Following is an example of this command: Variable= "OS version `uname -a`" && echo $variable
()	It is used to nest commands
#	It is used as command line comment

Steps to exploit – OS Command Injection

Step 1: Identify the input field

Step 2: Understand the functionality

Step 3: Try the Ping method time delay

Step 4: Use various operators to exploit OS command Injection

Type of Command Injection

Error based injection: When attacker injects a command through an input parameter and the output of that command is displayed on the certain web page, it proof that the application is vulnerable to the command injection. The displayed result might be in the form of an error or the actual outcomes of the command that you tried to run. An attacker then modifies and adds additional commands depending on the shell the web server and assembles information from the application.

Blind based Injection: The results of the commands that you inject will not displayed to the attacker and no error messages are returned it similar as blind SQL injection. The attacker will use another technique to identify whether the command was really executed on the server.

Mitigation-OS Command Injection

·         Strong server side validation

·         Implement a white list

·         OS Hardening

·         Use build in API’s for interacting with the OS if needed. More secure!!

·         Avoid applications from calling out directly the OS system commands