How Google Hacking:is done ?

GOOGLE HACKING:

Google hacking is the use of a search engine, such as Google, to locate a security vulnerability on the Internet. There are generally two types of vulnerabilities to be found on the Web: software vulnerabilities and misconfigurations.

Google hacking involves using advanced operators in the Google search engine to locate specific strings of text within search results. Some of the most popular examples are finding specific versions of vulnerable Web applications. The following search query would locate all web pages that have that particular text contained within them.

PUNCTUATION & SYMBOLS:

First, let’s understand how Google search engine will consider different symbols and meaning of it.

SNO	Symbols	How to Use
1.	+	Search for Google pages and blood groups E.g. +chrome or AB+
2.	@	To find social tags E.g. @googler
3.	$	To find price E.g. Canon $300
4.	#	To find hashtags of treading topics E.g. newyearparty
5.	–	Using – before word or site will exclude the word or site. Usually one word has many meaning Jaguar the animal and Jaguar the car.
6.	“	The result will include pages with the same words in same order as in the quotes. E.g. “Imagine all the People”
7.	*	Add an asterisk as a place holder for any unknown or wildcard terms. E.g. “a * saved * is a * earned”
8.	..	Separate numbers by two periods without spaces to see results that contain numbers in range. E.g. Camera $50 . . $100

ADVANCED OPERATORS:

These are the advanced operators in Google hacking

Sno	Advanced Operators	How to use
1	Intitle	Searches for strings in the title of the pages. E.g. title: webinar ( finds pages with “webinar” in the page title)
2	all in title	Searches for all string within the page title. E.g. all in title: webinar Briskinfosec (Finds pages with “webinar” and “Briskinfosec” in the page title)
3	Inurl	Searches for strings in the URL E.g. inurl: webinar (Find pages with the string “conference” in the URL)
4	allinurl	Searches for all strings in the URL E.g. allinurl: webinar Briskinfosec (Find pages with string “conference” & “ Brisk” in the URL)
5	info	Info about a page E.g. info: www.example.com (Finds information about the Google website)
6	filetype	Searches for files with files extension. E.g. filetype:ppt (Finds information about the Google website)
7	Cache	Display the Google cache of the page E.g. cache: www.example.com (shows the cached version of the page without performing the search)
8	Link	Linked pages E.g. link: www.examle.com (Finds pages that link to the given URL).
9	related	Related pages of the given domain name E.g. related: www.example.com (finds pages that links to the given URL)
10	site	Searches only one website E.g. webinar site: www.briskinfosec.com (searches briskinfosec site for webinar info)

What is HTTP Request and Response?

OVERVIEW OF HTTP REQUEST AND RESPONSE

WHAT IS HTTP?

• HTTP is an application layer protocol
• The default port for HTTP is 80
• World Wide Web Consortium and the Internet Engineering Task Force, both coordinates in the standardization of the HTTP protocol
• The resources that can be requested by using HTTP protocol is made available with the help of a type of URI (Uniform Resource Identifier) called URL (Uniform Resource Locator).
• A series of request and response in HTTP is called as a session in HTTP
• HTTP version 0.9 was the first documented version of HTTP
• HTTP is a stateless protocol (which means each and every connection is independent of each other.)
• Hypertext Transfer Protocol (HTTP) uses Transmission Control Protocol (TCP) as the Transport Layer Protocol at Well Known port number 80. Once the TCP connection is established, the two steps in Hypertext Transfer Protocol (HTTP) communication are
  • HTTP Client Request
  • HTTP Server Response

• HTTP Client Request: Hypertext Transfer Protocol (HTTP) client sends a Hypertext Transfer Protocol (HTTP) Request to the Hypertext Transfer Protocol (HTTP) Server according to the HTTP standard, specifying the information the client like to retrieve from the Hypertext Transfer Protocol (HTTP) Server.

E.g. HTTP Request Message

GET /hello.htm HTTP/1.1User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)Host: wwww.example.comAccept-Language: en-usAccept-Encoding: gzip, deflateConnection: Keep-Alive

• HTTP Server Response: Once the Hypertext Transfer Protocol (HTTP) Request arrived at the Hypertext Transfer Protocol (HTTP) server, it will process the request and creates a Hypertext Transfer Protocol (HTTP) Response message. The Hypertext Transfer Protocol (HTTP) response message may contain the resource the Hypertext Transfer Protocol (HTTP) Client requested or information why the Hypertext Transfer Protocol (HTTP) request failed.

E.g. HTTP Response Message

POST /cgi-bin/process.cgi HTTP/1.1User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)Host: www.example.comContent-Type: application/x-www-form-urlencodedContent-Length: lengthAccept-Language: en-usAccept-Encoding: gzip, deflateConnection: Keep-Alive licenseID=string&content=string&/paramsXML=string

• HTTP Response varies from the different server the HTTP request is sent.

From an Apache 1.3.23 server

HTTP/1.1 200 OK

Date: Sun, 15 Jun 2003 17:10: 49 GMT

Server: Apache/1.3.23

Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT

ETag: 32417-c4-3e5d8a83

Accept-Ranges: bytes

Content-Length: 196

Connection: close

Content-Type: text/HTML

From a Microsoft IIS 5.0 server:

HTTP/1.1 200 OK

Server: Microsoft-IIS/5.0

Expires: Yours, 17 Jun 2003 01:41: 33 GMT

Date: Mon, 16 Jun 2003 01:41: 33 GMT

Content-Type: text/HTML

Accept-Ranges: bytes

Last-Modified: Wed, 28 May 2003 15:32: 21 GMT

ETag: b0aac0542e25c31: 89d

Content-Length: 7369

From a Netscape Enterprise 4.1 server:

HTTP/1.1 200 OK

Server: Netscape-Enterprise/4.1

Date: Mon, 16 Jun 2003 06:19: 04 GMT

Content-type: text/HTML

Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT

Content-length: 57

Accept-ranges: bytes

Connection: close

There are various HTTP Header Security implementation required for a secure web application. Please go through my next blog HTTP Header Security.

What is HTTP Headers & Methods ?

WHAT IS HTTP HEADERS & METHODS ?

INTRODUCTION:

HTTP stands for “Hypertext Transfer Protocol“. The entire World Wide Web uses this protocol. It was established in the early 1990’s. Almost everything you see in your browser is transmitted to your computer over HTTP.  HTTP/1.1 is the version of HTTP in common use.

HTTP is based on the client-server architecture model and a stateless request/response protocol that operates by exchanging messages across a reliable TCP/IP connection.

E.g. HTTP Request Message

GET /hello.htm HTTP/1.1User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)Host: www.tutorialspoint.comAccept-Language: en-usAccept-Encoding: gzip, deflateConnection: Keep-Alive

E.g. HTTP Response Message

POST /cgi-bin/process.cgi HTTP/1.1User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)Host: www.tutorialspoint.comContent-Type: application/x-www-form-urlencodedContent-Length: lengthAccept-Language: en-usAccept-Encoding: gzip, deflateConnection: Keep-Alive licenseID=string&content=string&/paramsXML=string

HTTP METHODS:

HTTP defines a set of request methods to indicate the desired action to be performed for a given resource.

1. GET – The GET method is used to retrieve information from the given server using a given URL. Requests using GET should only retrieve data and should have no other effects on the data.
2. HEAD – Same as GET, but transfer the status line and header section only.
3. POST – A POST request is used to send data to the server, for example, customer information, file upload, etc. Using HTML forms.
4. PUT – Replaces all the current representation of the target resource with the uploaded content.
5. DELETE – Removes all current representation of the target resource given by a URL.
6. CONNECT – Establishes a tunnel to the server identified by a given URL.
7. OPTIONS – Describes the communication option for the target resources.
8. TRACE – Performs a message loop-back test along the path to the target resource.

HTTP RESPONSE STATUS CODES

HTTP response status codes indicate whether a specific HTTP request has been successfully completed. Responses are grouped into five classes: informational responses, successful responses, redirects, client errors, and server’s errors.

1. 1XX – Informational

It means the request has been received and the process is continuing.

2. 2XX – Success

It means the action was successfully received, understood and accepted.

3. 3XX – Redirection

It means further action must be taken in order to complete the request.

4. 4XX – Client Error

It means the request contains incorrect syntax or cannot be fulfilled.

5. 5XX – Server Error

It means the server failed to fulfill an apparently valid request.

The Internet Engineering Task Force has released a DRAFT on July 8, 2013, which describes an advanced version of HTTP, which in the coming near future will become an RFC for HTTP version 2 Protocol. This future version of HTTP will be having a good number of advanced features, which the current version lacks.

There were some main shortcomings in HTTP version 1 protocol and HTTP version 1.1, which are addressed by HTTP version 2. Some of these shortcomings are mentioned below.

• HTTP version 1 allowed processing of only one request at a time. Due to this, clients will have to make multiple HTTP connections to the server, to reduce page load time.
• Headers in multiple requests were repetitive and were very descriptive, which results in generation of larger packets(in other words previous versions were not using network resources in an optimized manner)

HTTP version 2 is also an application layer protocol, similar to previous versions. Some of the new advancements in HTTP version 2 are based on a protocol developed by Google called as speedy.

Recommended: HTTP Request and Response

CWE-79 Improper Neutralization of Input during Web Page Generation (‘Cross-site Scripting’)

CWE-79 IMPROPER NEUTRALIZATION OF INPUT DURING WEB PAGE GENERATION (‘CROSS-SITE SCRIPTING’) 

DESCRIPTION:

Cross-site scripting (XSS) is one of the most prevalent, obstinate, and dangerous vulnerabilities in web applications.

1. Data enters a Web application through an untrusted source, most frequently a web request.
2. The data is included in dynamic content that is sent to a web user without being validated for malicious content.

The malicious content sent to the web browser often takes the form of a segment of JavaScript, but may also include HTML, Flash, or any other type of code that the browser may execute. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data, like cookies or other session information, to the attacker, redirecting the victim to web content controlled by the attacker.

Stored and Reflected XSS Attacks

Stored XSS Attacks

Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-I XSS.

Reflected XSS Attacks

Reflected attacks are those where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other website. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable website, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a “trusted” server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS.

DOM XSS Attacks

DOM Based XSS (or as it is called in some texts,  is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script.

That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

PROBLEM LOCATION:

– Common Parameter Or Injection Points example  (Customizable Themes & Profiles via CSS,Event or meeting names, URI based, Imported from a 3rd party (think Facebook integration),JSON POST Values (check returning content type),File Upload names, Uploaded files (swf, HTML, ++),Login and Forgot password forms, Custom Error pages,params – ?realparam=1&foo=bar’+alert(/XSS/)+’.

– Popular Sources (document.URL, document.documentURI, location.href, location. Search, location.*, window.name, document. Referrer)

– Popular Sinks (HTML Modification sinks document. Write (element).innerHTML HTML modification to behaviour change (element).src (in certain elements) Execution Related sinks eval setTimout / setInterval execScript )

MITIGATION

Encode all fields when displaying them in the browser. Additionally, ensure that user input is properly filtered especially in the case of special characters. Ensure that cookie properties (such as HttpOnly) and security headers are set accordingly. A web application firewall (WAF) is the most commonly used solution for protection from XSS and web application attacks. Implement Content Security Policy (CSP) header.

GENERAL RESOURCES:

https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet 

https://www.owasp.org/index.php/DOM_Based_XSS

https://github.com/fuzzdb-project/fuzzdb/tree/master/attack/xss

GENERAL TOOLS:

1. Burp suite

2. xenotix xss

Owasp Mobile Top 10 M4 – Insecure Authentication

In this post, we are going to discuss the insecure Authentication which holds the Fourth position in Owasp Top 10 mobile Risks. Android apps are facing this vulnerability when the app fails to identify the user, allowing an anonymous user to login and using default login credentials. This category includes session management issues, privacy issues related to authentication, and issues where user identification tokens are compromised. Even if the mobile app uses a weak password policy to simplify entering a password, it suffers from insecure authentication.

To exploit this vulnerability, we have different approaches like attacking activities, Brute-force attack, user enumeration and checking password policy.

Attacking Activities:

In Android apps, everything is activities if you are in login screen it’s an activity if you are in profile screen its other activity so we can able to bypass the authentication by forcing the app to show the profile activity without giving username and password. To exploit activities we need to use a drozer framework which we have already discussed in earlier blogs.

first, we need to know what are the activities are available in insecure bank app for that we need to give the below commands

dz> run app.activity.info -a com.android.insecurebankv2

From the results, we come to know that that are 5 activities which are exported and first two are related to the login process.

 Fig. 1

 Com.android.insecurebankv2.LoginActivity is for login page screen (Fig 1.) and the com.android.insecurebankv2.PostLogin activity (Fig 2) is the screen which triggers when the user logged in. so we need to use the com.android.insecurebankv2.PostLogin activity to bypass the authentication. By using drozer let we start the activity by giving the below commands

dz> run app.activity.start  --component  com.android.insecurebankv2 com.android.insecurebankv2.PostLogin

 Fig 2.

 finally, we have bypassed the login page now we can do the transfer, changing the password or viewing the statement is possible. A brute-force attack is also possible but if the app has any brute-force protection mechanism it makes hard to attack. for example, if the app gets often login request it will block the user and it will restrict the access for a while. and there is another issues like Username Enumeration which occur when a user logged and for the second time when he/she too going login in app it shows the username and also when app gets the correct username and the wrong password that time it may show password of the username is wrong so it will conform us the username, it mostly happens in WordPress logins in web applications.

How to Fix:

• Don’t export unnecessary activities or use permissions when the activity is exported
• Implement two-factor authorization if called for the sensitivity of your application
• Disable anonymous accounts
• Implement strong password policy and don’t store the password in local storage

In this post, we have discussed how to attack activities using the drozer tool, and how the way android apps are vulnerable to owasp’s insecure authentication, and how to fix the vulnerability.