RE: Netware ichain

["Eyal Udassin" <eyal () swiftcoders com>]

Hello,

I audited 3 iChain servers of different clients this year.
Until the last release, the server sends it's exact version and build in the
server HTTP header, which will make your life easier if this is a black box
test.

Following are known vulnerabilities from the last year - some are not
detailed as they where submitted by Novell:
http://www.securityfocus.com/bid/11061
http://www.securityfocus.com/bid/8732 - OpenSSL ASN.1 Buffer overflow
http://www.securityfocus.com/bid/10767
http://www.securityfocus.com/bid/10576
http://www.securityfocus.com/bid/9412

Other than that, I didn't find any additional application level
vulnerabilities, yet this was not the focus of my assessments... 

Regards,

Eyal Udassin
Swift Coders


-----Original Message-----
From: Taki Waki [mailto:iskooler () gmail com] 
Sent: Wednesday, October 06, 2004 4:25 AM
To: webappsec () securityfocus com
Subject: Netware ichain


Hi List,

Was wondering anyone done any penetration testing on Netware iChains before.
Are there any default scripts or instalations that can be exploited via the
Internet? Thanks.




On Wed, 6 Oct 2004 14:41:51 +1300, Mike Allison <mike.allison () asbbank co nz>
wrote:
> Hi Benoni,
>
> Three rules that I live by that relate to these issues:
> 1. Client side (Jscript) filtering has nothing to do with security (it 
> is trivial to bypass it). It is used merely to inform the user what 
> data is acceptable in order to prevent wasted posts back to the 
> server. In terms of security, it's irrelevant whether or not users 
> look at your Jscript; all input must also be filtered on the server. 
> 2. Never send server generated or ASP generated or SQL generated 
> errors back to the client; identify these errors in your code then 
> send back your own user-friendly message to the client. 3. I never let 
> user input anywhere near my database unless I know exactly what is in 
> it. I check the user input in my .asp code (using regular 
> expressions), and if it doesn't conform to what I expect, I send back 
> a friendly message to the client.
>
> Hope this helps,
> Mike.
>
> -----Original Message-----
> From: Bénoni MARTIN [mailto:Benoni.MARTIN () libertis ga]
> Sent: Wednesday, October 06, 2004 1:26 AM
> To: webappsec () securityfocus com
> Subject: Web Forms filtered with SQL constraints
>
> Hi list !
>
> I was wondering how to solve the 2 following problems: I have ASP (not
> ASP.NET) formulaires people have to fill in. To avoid SQ injection 
> attacks and other tricks, I have set up some Jscript filtering on each 
> field (i.e. for instance a name can just be alphabet's characters and 
> no figures :) ), and I am planning to do the same on my Database 
> (setting up constraints).
>
> But I have 2 questions:
>        - How can I hide my Jscript filtering from the user ? When I 
> want to see the source, everything is diaplayed, quite normal :( ... 
> Maybe it's not so good to tell people what I have done to filter them 
> :) I saw some sites where it is impossible to see the source, 
> impossible to "hoover the site", impossible even to print ... But I 
> have not been able to find on the net how to do this :(
>
>        - How can I deal with possible SQL errors within an ASP page ? 
> I mean, if a field has been filled in, bypass my Jscript filtering (no 
> matter how), and gets to the database but is then "stopped" by an SQL 
> onstraint, how do I raise this error on an ASP page without diplaying 
> an explicit error (giving the user the name of my database for 
> instance) ?
>
> Cheers for any clue, I am lost on this topic :( 
> ======================================================================
> ==================
> This email message and attachments are confidential to our organisation
and subject to legal privilege.  If you have received this email in error,
please advise the sender immediately and destroy the message and any
attachments. If you are not the intended recipient you are notified that any
use, distribution, amendment, copying or any action taken or omitted to be
taken in reliance of this message or attachments is prohibited.  You can
read our Privacy Policy here:
<http://www.asbbank.co.nz/privacystatement.stm>
>
============================================================================
=============
>