Re: Cross Site Scripting for .exe?

• Previous message: Lawrence DčOliveiro: "Re: Saving old emails..."
• In reply to: kashmira.phalak_at_gmail.com: "Cross Site Scripting for .exe?"
• Next in thread: Lawrence DčOliveiro: "Re: Cross Site Scripting for .exe?"
• Reply: Lawrence DčOliveiro: "Re: Cross Site Scripting for .exe?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Mon, 06 Jun 2005 22:17:39 -0500

kashmira.phalak@gmail.com wrote:
> Hi,
>
> I'm a newbie but from what i've read, most of the Cross Site Scripting
> vulnerabilities are associated with the .jsp, .asp, .htm etc. But i'm
> looking at a particular case of security testing where the forms
> containing user input post to a .exe. This .exe is under the /cgi-bin
> directory. What does this exactly mean? How can an exe take in these
> posted inputs?
> Also, If i put in any scripts into the user input field, after posting
> of this data to an exe, i get an error page which just lists the error
> number and no other info...How do i find out if my script has been
> executed or is there some other exploit i can use for a .exe ?
>
> Thanks.
>
Sounds to me as if you are attempting to exploit the exe called by the
post cgi script.

Depending on input checking and permission levels you very likely can't,
to the best of my knowledge, if it is done properly. That is the
general idea to defeat folks trying to doing unions and such with error
messages.

The error message (number) thrown probably, depending on method, does
not mean anything except to the help desk for the application so they
can identify easily what the users issue is. The error message does not
come from the DB but from the exe. It means your method has been
intercepted.

Sounds to me like your approach may very well can not succeed. Congrats
to the folks who understood the vulnerability of many HTML applications.
  That exe that is called by the cgi script handles several procedures:
        
        1. It determines if the input is valid and does not contain chars that
indicate a delimiter in the input. It also validates the input length
does not exceed define parameters (prevents buffer overflows)

        2. After the exe has validated the input string it places the
validation sequence verifier in the commo string as well as applies the
encryption template (probably used if they were astute enough to do this
properly) so the data can be passed to the DB server. This reduces the
probability of successful access to the DB if the web server is compromised.

        3. Formost purpose of the exe is to place a boundary between the DB and
the application user. DB error messages should never be thrown to the
user. This exe acts as a middle man to prevent this activity from
occurring. Unknown to you is another exe that filters the db input to
the web server to ensure the error (or other information you want to
keep secret such as the db schema) is never passed as data to the
application.

SQL injection is a major issue with many web applications. These
methods are designed to prevent access.

Once folks understand the threat from injection, the methods used to
prevent SQL injection is simple enough.

I suspect "if" the application allows file posting, you will find the
webserver input file input file from the DB checked for other keyword
activities. Once it is set up, it is actually simpler for the
application programmer to utilize these secure methods as the exe
handles the DB calls, not the application. This eliminates another
subset of exploits such as DB access data strings, algorithmic key
methods, and encryption template data from being easily revealed.

I assume you are hacking this site because you do not know what the exe
is or the meaning of the error code (arbitrary). This is by design to
prevent you from doing what you are attempting to do. I would expect
you will find at this site all of their input methods covered by this
same technique. Usually once this issue is understood, one goes through
site with fine tooth comb to ensure these methods are prevented. Even if
you compromise the webserver and gain access to the exe (which should
trip a number of tripwires) you still will not gain access to the db
because of methods used to synchronize the db communication. If all
sites used these methods, we wouldn't have all the credit card
compromises that certain (expletives deleted) attempt to access what
they have no right to access.

Winged

• Previous message: Lawrence DčOliveiro: "Re: Saving old emails..."
• In reply to: kashmira.phalak_at_gmail.com: "Cross Site Scripting for .exe?"
• Next in thread: Lawrence DčOliveiro: "Re: Cross Site Scripting for .exe?"
• Reply: Lawrence DčOliveiro: "Re: Cross Site Scripting for .exe?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]