Cross Site Scripting for .exe?

Cross Site Scripting for .exe?

Secure Home | Search | About
 Computer Software Security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content add this group's latest topics to your Google content
Subject Author Date
Cross Site Scripting for .exe? kashmira.phalak 06-06-2005
Posted by on June 6, 2005, 12:45 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
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.



Posted by Winged on June 6, 2005, 10:17 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
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










Posted by Lawrence DčOliveiro on June 7, 2005, 6:41 pm
If you were  Registered and logged in, you could reply and use other advanced thread options

>kashmira.phalak@gmail.com wrote:
>
>>This .exe is under the /cgi-bin directory.
>>
>Sounds to me as if you are attempting to exploit the exe called by the
>post cgi script.

If the executable resides in the cgi-bin directory, then the executable
*is* callable as a CGI.

>DB error messages should never be thrown to the user.

And yet PHP sites do this all the time.

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

<http://en.wikipedia.org/wiki/Sql_injection>


Posted by on June 7, 2005, 3:18 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Looks like CGI C has been used. I looked up the net but could not find
much info on vulnerabilities of CGI C. Anybody know where I can obtain
such info? I want to test all aspects of the site. Can anyone tell me
where I could find a comprehensive document of scripts/exploits I
should test for? The internet is scattered with bits and pieces, but I
havent come across any doc which sums up all such scripts.

Thanks in advance!



Similar ThreadsPosted
Hacking site! July 14, 2005, 12:14 pm
suspicious site January 23, 2008, 7:20 pm
US Gov looking for input about IE ONLY pre-patient web site... August 13, 2005, 11:57 pm
how to allow different companies to use a site without logging in? November 21, 2005, 1:55 pm
Funniest site name ever www.niggersandcrackers.com February 8, 2006, 3:26 pm
New Security site released May 12, 2008, 7:15 am
Please check the security hole of this site October 4, 2005, 2:02 pm
Charity site payments - secure or not ? April 1, 2006, 4:13 am
Forwarding HTTPS site by IP address May 11, 2007, 11:03 am
find out the hosting company of the web site July 18, 2007, 7:18 pm

The site map in XML format XML site map

Contact Us | Privacy Policy