Re: backorifice-brute

[Gorjan Petrovski <mogi57 () gmail com>]

Ah yes, David proposed the fire and forget method with UDP I guess it's my
fault it got forgotten. I'd be happy to try it out once I finish with some
of the current scripts if that's alright with the mentors.

Nice catch Ron.
On Jun 17, 2011 8:43 PM, "Patrik Karlsson" <patrik () cqure net> wrote:
> I did some experimenting with "fire-and-forget" style using snmp a while
back, didn't turn out as great as I hoped.
> http://seclists.org/nmap-dev/2011/q2/56
>
> //Patrik
>
> On Jun 17, 2011, at 6:54 PM, Ron wrote:
>
> > True, but a risk of false negatives isn't that big of a deal - it's false
positives that are really worth worrying about.
> > Ron
> >
> > On Fri, 17 Jun 2011 12:35:10 +0300 Toni Ruottu <toni.ruottu () iki fi>
wrote:
> > > Even with slower speeds there is a serious problem of false negatives
> > > by packages being dropped. We would need statistics about success
> > > rates, and even then network situation might change everything.
> > > On 17 Jun 2011 03:53, "Ron" <ron () skullsecurity net> wrote:
> > > > I wasn't part of the original discussions, so sorry if I'm repeating
> > > something that's already been discussed, but I'm not convinced. ;)
> > > > The magic of UDP is the fire-and-forget style. You can send 30,000
> > > > packets
> > > to a host in a couple seconds, and it'll process them and respond
> > > when it gets one it can handle (unless you blow up a queue or cause a
> > > traffic jam or something). It seems to me that you could guess the
> > > top 1000 or 10000 passwords in under a second, then wait 5 or 10 or
> > > 30 seconds for a response. If you get a response, then you can go
> > > back and do the check properly (unless the response contains the
> > > password or whatever, then the problem is solved).
> > > > Does that make sense for this protocol? Or is something odd going
> > > > on?
> > > >
> > > > (Like I said, sorry if this is rehashing stuff you already talked
> > > > about
> > > and decided against)
> > > > Ron
> > > >
> > > > On Fri, 17 Jun 2011 02:28:06 +0200 Gorjan Petrovski
> > > > <mogi57 () gmail com>
> > > wrote:
> > > > > We discussed the initiation of the backorifice-brute script at
> > > > > great length at the NSE meetings and we decided that it shouldn't
> > > > > run by default because the backorifice service is far from
> > > > > widespread an it's going to be even less used in the future. I'd
> > > > > like to point out that this is the BackOrifice server not the
> > > > > BackOrifice2000, with which the situation is a little bit
> > > > > different.
> > > > >
> > > > > Thanks for your remark nevertheless. It is a valid one to say the
> > > > > least.
> > > > >
> > > > > Gorjan
> > > > >
> > > > >
> > > > > On Thu, Jun 16, 2011 at 11:26 PM, Ron <ron () skullsecurity net>
> > > > > wrote:
> > > > > > Why did you decide not to run it by default against 31337? I
> > > > > > realize that it can be slow, and that 31337 will almost always be
> > > > > > open-filtered, but all brute scripts are nasty like that.
> > > > > >
> > > > > > Ron
> > > > > >
> > > > > > On Wed, 11 May 2011 23:53:31 +0200 Gorjan Petrovski
> > > > > > <mogi57 () gmail com> wrote:
> > > > > > > Hi folks,
> > > > > > >
> > > > > > > I've finally finished the backorifice-brute script, and decided
> > > > > > > on the criteria on which the script should run.
> > > > > > >
> > > > > > > The BackOrifice service is a very old service which now we
> > > > > > > presume would be used only in a galaxy far far away. Because of
> > > > > > > the time needed for the bruteforcing we've included a mandatory
> > > > > > > script argument. This argument (backorifice-brute.ports)
> > > > > > > specifies the ports on which the script should run and if
> > > > > > > omitted, the script never runs. We've also included a debug
> > > > > > > message if the default port on which the service is found,
> > > > > > > 31337/udp, is open|filtered but not selected with the ports
> > > > > > > argument, thus notifying the user of a chance for version
> > > > > > > detection using the backorifice-brute script.
> > > > > > >
> > > > > > > The host.times.timeout worked out perfectly with the service, I
> > > > > > > guess I made a mistake in testing it out before. Sorry for the
> > > > > > > confusion, David.
> > > > > > >
> > > > > > > I've also skimmed through the BackOrifice2000 client source
> > > > > > > code. The protocol is different, the encryption is different
> > > > > > > compared to the BackOrifice client. BO2K looks like a piece of
> > > > > > > art compared to BO :-)
> > > > > > >
> > > > > > > Feel free to comment, as always.
> > > > > > >
> > > > > > > I'm waiting for approval on committing this script. (But I have
> > > > > > > plenty to work on, and it's a pretty non-popular service, so no
> > > > > > > pressure)
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Gorjan
> > > > > > _______________________________________________
> > > > > > Sent through the nmap-dev mailing list
> > > > > > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > > > > > Archived at http://seclists.org/nmap-dev/
> > > > > _______________________________________________
> > > > > Sent through the nmap-dev mailing list
> > > > > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > > > > Archived at http://seclists.org/nmap-dev/
> > > > _______________________________________________
> > > > Sent through the nmap-dev mailing list
> > > > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > > > Archived at http://seclists.org/nmap-dev/
> > > _______________________________________________
> > > Sent through the nmap-dev mailing list
> > > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > > Archived at http://seclists.org/nmap-dev/
> > _______________________________________________
> > Sent through the nmap-dev mailing list
> > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > Archived at http://seclists.org/nmap-dev/
>
> --
> Patrik Karlsson
> http://www.cqure.net
> http://www.twitter.com/nevdull77
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/