Sent from my BlackBerry® from SYNTAX


----- Original Message -----
From: [email protected] 
<[email protected]>
To: [email protected] <[email protected]>
Sent: Mon Mar 01 16:08:20 2010
Subject: Openvas-plugins Digest, Vol 28, Issue 2

Send Openvas-plugins mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Openvas-plugins digest..."


Today's Topics:

   1. Re: MS-RPC for GSoC (Jonas Andradas)
   2. Re: MS-RPC for GSoC (Tim Brown)
   3. Re: MS-RPC for GSoC (Chandrashekhar B)
   4. Re: MS-RPC for GSoC (Felix Wolfsteller)
   5. Re: MS-RPC for GSoC (Dra?en Popovi?)
   6. Re: MS-RPC for GSoC (Dra?en Popovi?)
   7. Re: MS-RPC for GSoC (Chandrashekhar B)


----------------------------------------------------------------------

Message: 1
Date: Mon, 1 Mar 2010 12:05:08 +0100
From: Jonas Andradas <[email protected]>
Subject: Re: [Openvas-plugins] MS-RPC for GSoC
To: Vlatko Kosturjak <[email protected]>
Cc: [email protected]
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

Hello,

2010/2/27 Vlatko Kosturjak <[email protected]>

>
>   [...]
>
> Totally agree. OpenVAS was focusing too much on local checks recently. I
> would definitively vote for this as we need to improve remote checks in
> OpenVAS.
>
> Sooner the better...
>
> Kost
>
>
At the company I work for, we do auditing services, among other things.
Currently we are using Nessus, and I am introducing OpenVAS gradually. All
progress at improving remote checks with no credentials (identifying
services, versions, remote vulnerabilities) would help in OpenVAS replacing
Nessus :)

GSOC projects on this, I think could be very useful to the project.

Best Regards,

Jon?s.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20100301/0bd95ef9/attachment.html

------------------------------

Message: 2
Date: Sun, 28 Feb 2010 14:01:09 +0000
From: Tim Brown <[email protected]>
Subject: Re: [Openvas-plugins] MS-RPC for GSoC
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"

On Monday 01 March 2010 11:05:08 Jonas Andradas wrote:
> Hello,
> 
> 2010/2/27 Vlatko Kosturjak <[email protected]>
> 
> >   [...]
> >
> > Totally agree. OpenVAS was focusing too much on local checks recently. I
> > would definitively vote for this as we need to improve remote checks in
> > OpenVAS.
> >
> > Sooner the better...
> >
> > Kost
> 
> At the company I work for, we do auditing services, among other things.
> Currently we are using Nessus, and I am introducing OpenVAS gradually. All
> progress at improving remote checks with no credentials (identifying
> services, versions, remote vulnerabilities) would help in OpenVAS replacing
> Nessus :)
> 
> GSOC projects on this, I think could be very useful to the project.

There's no reason why we can't add more bindings to OpenVAS for the Samba 
libraries (and others).  This is what we agreed at DevCon 2.  Fact is that 
whilst SSH/SMB code exists in NASL, it is a massive pain in the ass to keep 
maintaining it. I would support a GSoC project to work on Samba integration.

Tim
Tim
-- 
Tim Brown
<mailto:[email protected]>
<http://www.openvas.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : 
http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20100228/8d951bf6/attachment-0001.pgp

------------------------------

Message: 3
Date: Mon, 1 Mar 2010 17:24:43 +0530
From: "Chandrashekhar B" <[email protected]>
Subject: Re: [Openvas-plugins] MS-RPC for GSoC
To: "'Tim Brown'" <[email protected]>,
        <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain;       charset="us-ascii"


> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On 
> Behalf Of Tim Brown
> Sent: Sunday, February 28, 2010 7:31 PM
> To: [email protected]
> Subject: Re: [Openvas-plugins] MS-RPC for GSoC
> 
> On Monday 01 March 2010 11:05:08 Jonas Andradas wrote:
> > Hello,
> > 
> > 2010/2/27 Vlatko Kosturjak <[email protected]>
> > 
> > >   [...]
> > >
> > > Totally agree. OpenVAS was focusing too much on local checks 
> > > recently. I would definitively vote for this as we need 
> to improve 
> > > remote checks in OpenVAS.
> > >
> > > Sooner the better...
> > >
> > > Kost
> > 
> > At the company I work for, we do auditing services, among 
> other things.
> > Currently we are using Nessus, and I am introducing OpenVAS 
> gradually. 
> > All progress at improving remote checks with no credentials 
> > (identifying services, versions, remote vulnerabilities) 
> would help in 
> > OpenVAS replacing Nessus :)
> > 
> > GSOC projects on this, I think could be very useful to the project.
> 
> There's no reason why we can't add more bindings to OpenVAS 
> for the Samba libraries (and others).  This is what we agreed 
> at DevCon 2.  Fact is that whilst SSH/SMB code exists in 
> NASL, it is a massive pain in the ass to keep maintaining it. 
> I would support a GSoC project to work on Samba integration.

I prefer that too. We are working on getting NTLMSSP part from Samba
already, though for authenticated tests, we should do the same here as well.


Chandra.



------------------------------

Message: 4
Date: Mon, 1 Mar 2010 14:23:54 +0100
From: Felix Wolfsteller <[email protected]>
Subject: Re: [Openvas-plugins] MS-RPC for GSoC
To: [email protected]
Message-ID: <[email protected]>
Content-Type: Text/Plain;  charset="utf-8"

Hi Drazen,

great to hear from you on the mailinglist, too.
I am very fine with your proposal. I would have comments for you and the 
responses to your post, but dont want to spawn other discussions right now.

You were praising the NSE libraries. I think it would not be too 
overwhelmingly difficult to access these. Depends a bit on how we plan to 
support nse. The current idea is to launch nmap, but afaik integrating a lua 
interpreter wouldnt be that difficult either.

One way or another, i like the basic idea very much, but would wait a bit with 
thinking about the details until we (including you, Drazen) are sure to be 
accepted for gsoc. Except you want to help out in every case ...

-- felix


On Friday 26 February 2010 20:18:27 Dra?en Popovi? wrote:
> Hello everyone. :)
>
> I have an idea for GSoC, so I would like to hear your thoughts about it.
> I've spent a lot of hours programming remote checks in NASL, and I must
> admit that it was somewhat a painfull experience. I think that remote
> checks are very important in pentesting, as such NASL should provide a
> strong framework for their development. By a "strong framework" I mean,
> various network protocols support including packet building/dissecting
> ".inc"s. For example, my goal is to port all of Metasploits DCERPC/SMB
> based exploits to OpenVAS in a form of intrusive checks, also utilize
> the use of MSRPC in all kinds of enumeration (service, users,
> shares...). So far my every step in implementing MSRPC was severly
> slowed down due to inadequate/incomplete NASL implementation of
> underlying network protocols such as SMB and NetBT. Why MS-RPC (a
> Microsofts port of DCE-RPC)? Because it seems to be a vulnerability
> "surfboard". Just count the Metasploit SMB/DCERPC exploit modules, or
> even CANVASs. To sum it all up, my idea is to implement the MSRPC
> protocol in NASL, including packet crafting .inc, data types handling
> (Network Data Representation marshalling and unmarashalling), statefull
> operations (bind, request, fault) and ofcourse calls to Windows remote
> procedures extracted from SAMBA 4.0 .idls. The main design guidelines
> would be Pythons Impacket DCERPC implementation and a beautiful NMAPs
> NSE MSRPC implementation.
>
> Regards,
> D.


-- 
Felix Wolfsteller |  ++49 541 335083-783  |  http://www.intevation.de/
PGP Key: 39DE0100
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


------------------------------

Message: 5
Date: Mon, 01 Mar 2010 14:44:35 +0100
From: Dra?en Popovi? <[email protected]>
Subject: Re: [Openvas-plugins] MS-RPC for GSoC
To: [email protected]
Message-ID: <1267451075.11521.16.ca...@dfp-buntu>
Content-Type: text/plain; charset="UTF-8"

On Mon, 2010-03-01 at 14:23 +0100, Felix Wolfsteller wrote:
> Hi Drazen,
>
> great to hear from you on the mailinglist, too.

:)

> You were praising the NSE libraries. I think it would not be too 
> overwhelmingly difficult to access these. Depends a bit on how we plan to 
> support nse. The current idea is to launch nmap, but afaik integrating a lua 
> interpreter wouldnt be that difficult either.

I saw the CR for the NMAP/NSE integration, but as far as I can tell, you
don't want NASL to become a second language in OV. It's not clear to me
what exactly is the purpose of integrating another language into OV. As
a NASL plugin developer I must admit, if presented with another language
like Lua I would consider abandoning NASL as OV language.
 
> One way or another, i like the basic idea very much, but would wait a bit 
> with 
> thinking about the details until we (including you, Drazen) are sure to be 
> accepted for gsoc. Except you want to help out in every case ...
> 
> -- felix
> 

In every case, of course.

Regards,
Dra?en.

-- 
Laboratory for Systems and Signals
Department of Electronic Systems and Information Processing
Faculty of Electrical Engineering and Computing
University of Zagreb



------------------------------

Message: 6
Date: Mon, 01 Mar 2010 14:50:07 +0100
From: Dra?en Popovi? <[email protected]>
Subject: Re: [Openvas-plugins] MS-RPC for GSoC
To: [email protected]
Message-ID: <1267451407.11521.22.ca...@dfp-buntu>
Content-Type: text/plain; charset="UTF-8"

On Sun, 2010-02-28 at 14:01 +0000, Tim Brown wrote:
> There's no reason why we can't add more bindings to OpenVAS for the Samba 
> libraries (and others).  This is what we agreed at DevCon 2.  Fact is that 
> whilst SSH/SMB code exists in NASL, it is a massive pain in the ass to keep 
> maintaining it. I would support a GSoC project to work on Samba integration.
> 
> Tim

I agree that maintenance would be painful and also wouldn't mind working
on Samba integration.

Regards,
Dra?en.

-- 
Laboratory for Systems and Signals
Department of Electronic Systems and Information Processing
Faculty of Electrical Engineering and Computing
University of Zagreb



------------------------------

Message: 7
Date: Mon, 1 Mar 2010 19:38:07 +0530
From: "Chandrashekhar B" <[email protected]>
Subject: Re: [Openvas-plugins] MS-RPC for GSoC
To: 'Dra?en Popovi?' <[email protected]>,
        <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain;       charset="iso-8859-2"

Hello,


> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On 
> Behalf Of Dra?en Popovic
> Sent: Monday, March 01, 2010 7:15 PM
> To: [email protected]
> Subject: Re: [Openvas-plugins] MS-RPC for GSoC
> 
> On Mon, 2010-03-01 at 14:23 +0100, Felix Wolfsteller wrote:
> > Hi Drazen,
> >
> > great to hear from you on the mailinglist, too.
> 
> :)
> 
> > You were praising the NSE libraries. I think it would not be too 
> > overwhelmingly difficult to access these. Depends a bit on 
> how we plan 
> > to support nse. The current idea is to launch nmap, but afaik 
> > integrating a lua interpreter wouldnt be that difficult either.
> 
> I saw the CR for the NMAP/NSE integration, but as far as I 
> can tell, you don't want NASL to become a second language in 
> OV. It's not clear to me what exactly is the purpose of 
> integrating another language into OV. As a NASL plugin 
> developer I must admit, if presented with another language 
> like Lua I would consider abandoning NASL as OV language.

The idea is definitely not to replace NASL with anything else. It was only
to have a facility to launch NSE scripts that do some specific tasks. We
aren't integrating another language into OV.

Chandra.



------------------------------

_______________________________________________
Openvas-plugins mailing list
[email protected]
http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins


End of Openvas-plugins Digest, Vol 28, Issue 2
**********************************************
_______________________________________________
Openvas-plugins mailing list
[email protected]
http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins

Reply via email to