Apache Mod_perl Cross Site Scripting Vulnerability

Home » CentOS » Apache Mod_perl Cross Site Scripting Vulnerability
CentOS 6 Comments

Hello,

I’ve failed latest PCI scan because of CVE-2009-0796. CentOS 6.7. The Red Hat Security Response Team has rated this issue as having moderate security impact and bug as wontfix.

Explanation: The vulnerability affects non default configuration of Apache HTTP web server, i.e cases, when access to Apache::Status and Apache2::Status resources is explicitly allowed via httpd.conf configuration directive. Its occurrence can be prevented by using the default configuration for the Apache HTTP web server (not exporting /perl-status).

I haven’t used but Trustwave still finds me vulnerable.

Evidence:
Request: GET /perl-
status/APR::SockAddr::port/”> HTTP/1.1
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: www.mydomain.com Content-Type: text/html Content-Length: 0
Response: HTTP/1.1 404 Not Found Date: Mon, 07 Aug 2015 11:10:21 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/5.3.3
Set-Cookie: PHPSESSID=kj6bpud7htmbtgaqtcwhsqk7j1; path=/

Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-
check=0
Pragma: no-cache Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8
Body: contains ‘”>‘

How can I get around this?

6 thoughts on - Apache Mod_perl Cross Site Scripting Vulnerability

  • […]

    You clearly aren’t serving perl-status; that’s a red herring here.

    […]

    That’s your problem; they’re flagging you for an XSS “vulnerability”. I’m guessing you have a custom 404 page that naively echoes the entire request URL as part of the page? You need to be using htmlspecialchars() or HTML::Entities or whatever your language/environment has to escape strings for safe inclusion in HTML
    content.

    There is of course more to it than that (sigh), try for starters:
    https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

    –ln

  • How about something like:

    # disallow public access
    Order Deny, Allow
    Deny from all
    Allow from 127.0.0.1

    SetHandler perl-script
    PerlResponseHandler Apache2::Status

    2015-08-11 14:46 GMT+03:00 Proxy One :

  • Indeed, I don’t have mod_proxy installed.

    There is PHP generated 404 page. I’ll check that with web developer. What’s strange, I’m trying to reproduce this and I don’t see that string. Trustwave support suggested I use Burp Suite and it’s repeater tool. I find some windows machine, installed it and all I see inside body is “Unable to resolve the request
    “perl-status/APR::SockAddr::port”.

    Is there way to use curl for testing? I’m getting new line because of the single quote inside string and escaping it with back slash gives me bash: syntax error near unexpected token `<' Very nice reading, thanks!

  • Thanks to this I noticed that I don’t have mod_perl installed at all. So even this vulnerability is marked as CVE-2009-0796, it’s related to my
    404 page.

    Thanks!

  • You can use curl’s -K option which lets you stick arguments in a file, helpful for getting around shell quoting nightmares. For example make a file named test-url-file which contains the line url = http://www.mydomain.com/%5Bbad stuff, don’t want this message tripping over some filter for containing a malicious-looking URL]

    then do curl -g -K test-url-file

    Note that just gets you around shell interpretation; curl does some of its own as well. the -g switch I used there disables its interpretation of {}[] as special globbing characters. If you put the url in double quotes then not only do you have to escape any double quotes in the string, it also starts interpreting backslash sequences so you have to double all backslashes–so oddly it’s best to just leave quotes off.

    –ln

  • Thanks, it works! I was able to reproduce problem and was able to see how my changes affected response from the server.