OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Sean McHugh (Sean.McHughEPIC.SUNGARD.COM)
Date: Fri Mar 23 2001 - 10:17:05 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    actually, b/c what others who know more than i do feel
    about the NT implementation of STDOUT, some of the system
    cli tools return screwy headers (or none at all ?) when
    run over a web interface. While dir and lots of others work
    fine, i have noticed that others will return with some of the
    data chewed off and some not at all. cmd.exe seems to always
    return for a dir, an echo, a tpye cmd, but still gives a 502
    error although you are getting data back to your browser.

    sean

    -----Original Message-----
    From: Chris Huseman [mailto:ChrisHA-T-G.COM]
    Sent: Wednesday, March 21, 2001 5:53 PM
    To: FOCUS-MSSECURITYFOCUS.COM
    Subject: Re: One of our sites had problem yesterday afternoon...

    <snip>
    The above three entries look like 502 response codes
    were returned for the requested files. This would
    mean that the request did not succeed...correct?

    > ->00:04:24 62.157.45.35 GET /scripts/E.asp 200
    > ->00:04:26 62.157.45.35 GET
    > /scripts/../../winnt/system32/attrib.exe 502
    > ->00:04:30 62.157.45.35 GET
    > /scripts/../../winnt/system32/cmd.exe 502

    Oddly enough...the request for E.asp did succeed, but
    subsequest requests for the other files failed. I
    don't know about a default install of IIS, but is
    E.asp included? If not, it must have been placed on
    the system prior to these log excerpts.

    > ->
    > ->I have two questions
    > ->1) What are they doing with the first line

    I'd say the cmd.exe file.

    > ->2) How can I look at my logs and identify what
    > vulnerability
    > ->was exploited.

    Well...you'd want 200 response codes in most cases.
    The older *.idc request technically succeeded if a 403
    was returned...the physical path was part of the error
    message. In the case of the log files you provided,
    it looks as though most of the GET requests
    failed...though it is very odd that one request for
    cmd.exe would succeed, but a subsequent one would
    not...
    </snip>

    This really isn't odd.. whats important with the cmd.exe request is the
    querystring (thats the dangerous part), which doesn't appear in these logs.

    For example, I hit:

    http://localhost/scripts/..%c0%af../..%c0%af../..%c0%af../winnt/system32/cmd
    .exe?/c+dir+c:\

    The log says:

    22:37:44 127.0.0.1 GET /scripts/../../../../../../winnt/system32/cmd.exe 200

    But when I hit:
    http://localhost/scripts/..%c0%af../..%c0%af../..%c0%af../winnt/system32/cmd
    .exe?/c+foo
    (foo is an unknown file)

    I get this in the log:

    22:38:48 127.0.0.1 GET /scripts/../../../../../../winnt/system32/cmd.exe 502

    I have seen on some IIS installations a 502 error with every 'cmd.exe /c'
    request because it really doesn't send a proper HTTP header, which is what
    the 502 is for (IIRC).. so I wouldn't try to guess which of the 502's were
    successful and which weren't.

    I'd also guess that the first 200 request was something like a cmd.exe /c
    dir c:\ request.. not just a request for the cmd.exe file, but something
    that would tell the would-be attacker that the box is vulnerable.

    -chris