Re: nmap-6.49BETA6-1.dmg - zenmap still fails

[Peter Houppermans <ph () phx li>]

Hi Daniel,

I did a new download .  MD5, SHA1, SHA256 and GPG checksums were all correct, re-installed.  Issue persists.

Re. the github entry, I have macports installed too, but that happened AFTER nmap was installed.  I did not add any 
comments to github because that confuses communication.

Just to be sure:

nmap is executed as /usr/local/bin/nmap

nmap -V produces:

Nmap version 6.49BETA6 ( https://nmap.org )
Platform: x86_64-apple-darwin13.4.0
Compiled with: liblua-5.2.3 openssl-1.0.2d nmap-libpcre-7.6 nmap-libpcap-1.7.3 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: kqueue poll select

I will hold off pulling in the macports version so that I can help you guys debug this.  My intention was to switch to 
macports as I also use other tools (easier to keep it all up to date), but I can hold off a few days if that helps 
digging out what is happening, others may just need this binary.

Kind regards,   /// Peter ///


> From nmap-6.49BETA6-1.dmg, nmap now works correctly from command line.  However, zenmap does not start.
>
> Console showed these entries:
>
> 04/11/15 21:30:43,235 authexec[9108]: executing /Applications/Zenmap.app/Contents/MacOS/zenmap_wrapper.py
> 04/11/15 21:30:43,257 com.apple.xpc.launchd[1]: (org.insecure.Zenmap.981472[9096]) FairPlay decryption failed on 
> binary.
>
> I'm using OSX 10.11.1.
>
> Message: 3
> Date: Wed, 4 Nov 2015 19:04:55 -0600
> From: Daniel Miller <bonsaiviking () gmail com>
> To: d1312 () phx li
> Cc: Nmap-dev <dev () nmap org>
> Subject: Re: nmap-6.49BETA6-1.dmg - zenmap still fails
> Message-ID:
>       <CABmvJnN0zhFiLqUX99xFZUwvO4Fr+OpmyYFRb5PT=yqeH3RE5Q () mail gmail com>
> Content-Type: text/plain; charset="utf-8"
>
> Peter,
>
> Thanks for reporting this. We got one report of this for 6.49BETA1 as well,
> but were never able to track it down. I've linked your email on that issue
> [1], but I think you may have gotten a corrupted download. You can check
> the GPG signature for the file [2] or just do a checksum to detect
> corruption [3]. Please let us know if you find out more.
>
> Dan
>
> [1] https://github.com/nmap/nmap/issues/155
> [2] https://nmap.org/dist/sigs/nmap-6.49BETA6-1.dmg.asc
> [3] https://nmap.org/dist/sigs/nmap-6.49BETA6-1.dmg.digest.txt
>
> On Wed, Nov 4, 2015 at 2:34 PM, <d1312 () phx li> wrote:
>
> > Hi,
> >
> > From nmap-6.49BETA6-1.dmg, nmap now works correctly from command line.
> > However, zenmap does not start.
> >
> > Console showed these entries:
> >
> > 04/11/15 21:30:43,235 authexec[9108]: executing
> > /Applications/Zenmap.app/Contents/MacOS/zenmap_wrapper.py
> > 04/11/15 21:30:43,257 com.apple.xpc.launchd[1]:
> > (org.insecure.Zenmap.981472[9096]) FairPlay decryption failed on binary.
> >
> > I'm using OSX 10.11.1.
> >
> > Cheers, Peter
> > _______________________________________________
> > Sent through the dev mailing list
> > https://nmap.org/mailman/listinfo/dev
> > Archived at http://seclists.org/nmap-dev/
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://nmap.org/mailman/private/dev/attachments/20151104/93747833/attachment.html>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 5 Nov 2015 09:43:12 +0200
> From: Fotis Hantzis <ithilgore.ryu.l () gmail com>
> To: Daniel Miller <bonsaiviking () gmail com>
> Cc: nmap-dev <nmap-dev () insecure org>
> Subject: Re: Ncrack revived
> Message-ID:
>       <CAFOwBwOsXsePUHR=XbvjJsE-uRhgt5JHuQbmu+_3xQDVRvEkaw () mail gmail com>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks for the feedback!
>
> d33tah, do you think Travis CI is really worth the trouble? As far as I
> know, it's quite complicated to successfully set up.
>
> Dan, the interoperability between Nmap and Ncrack is a sought after goal,
> as already demonstrated by Ncrack's automatic service recognition (-iX,
> -iN). I think your idea about automatically feeding Ncrack new targets as
> they get discovered by Nmap, would be ideal if the network resources were
> segregated. So it would be even better if Ncrack was initiated through a
> different network segment (this could also be a cloud service).
>
> As for how this could be implemented, it would require some changes to
> Ncrack's architecture. Ncrack utilizes the nsock library (also used by Nmap
> for service detection [-sV]) which uses an asynchronous/non-blocking model.
> It would be better if we kept a total of one running process (not use any
> fork/pthread) and leverage another non-blocking socket to accomplish the
> communication between Ncrack and Nmap. The implementation of the pipeline
> would require some changes in Ncrack's core engine but that won't really be
> a problem.
>
> Since it's a task that would require a robust architecture - e.g properly
> authenticating Nmap requests to Ncrack (this could easily be abused
> otherwise since it won't necessarily be IPC) I would also like to hear the
> opinion of Fyodor on this one. It is overall a quite promising and exciting
> feature.
>
> Ithilgore
>
>
> On Wed, Nov 4, 2015 at 3:49 PM, Daniel Miller <bonsaiviking () gmail com>
> wrote:
>
> > Ithilgore,
> >
> > This is exciting news! For me, Ncrack's primary use has been as an SSH
> > brute-forcer, since NSE doesn't have that capability. I think it's greatest
> > strength going forward as part of the Nmap Project will be its
> > single-purpose design: NSE may support more protocols, but it has these
> > primary weaknesses:
> >
> > 1. A brute-force NSE script stops a network scan until it completes. This
> > means that Nmap's primary purpose is hindered in some way.
> >
> > 2. A brute NSE script can only handle as many hosts at a time as the
> > current hostgroup size. At the moment, NSE parallelization isn't the most
> > intelligent and probably under-utilizes the network.
> >
> > I think Ncrack could be improved by deliberately addressing these
> > deficiencies in NSE. One option would be an RPC listener of some sort for a
> > running Ncrack process to accept new targets. This would let us make a NSE
> > script to pass along targets as discovered, letting the Nmap scan continue
> > while Ncrack handles the brute-forcing, maybe even on a different computer.
> > I'm not familiar enough with Ncrack's architecture to know whether it would
> > easily support a pipelined approach (different targets starting at
> > different times) but it would at least have a better chance of batching in
> > an appropriate size group.
> >
> > Dan
> >
> > On Wed, Nov 4, 2015 at 2:10 AM, Fotis Hantzis <ithilgore.ryu.l () gmail com>
> > wrote:
> >
> > > Hello nmap-dev,
> > > it's been a while since I last updated Ncrack but I have been actively
> > > working on it for quite some time now. I already updated the SSH module by
> > > porting the latest openssh code (7.1) to the internal Ncrack ssh library
> > > (currently only on svn). Now it is working against all latest ssh servers.
> > > The analysis of how this was originally accomplished back when I
> > > originally built the first version of the Ncrack SSH module is here for
> > > anyone interested:
> > > http://sock-raw.org/papers/openssh_library
> > >
> > > I am aware that currently many people are using NSE for some of your
> > > brute-forcing tasks, but Ncrack still remains a highly specialized tool for
> > > this purpose, with a lot of useful features. Some of its main advantages
> > > are:
> > >
> > > * Intelligent core networking engine:
> > >
> > > Ncrack knows when to back off to avoid DoS-ing a service and when to
> > > increase its network connections by constantly trying to find a golden
> > > ration between efficiency (speed) and reliability.
> > > For example other competitors led to the shutdown of the FTP service
> > > while Ncrack managed to maintain a balance and find the credentials
> > > correctly:
> > > https://hackertarget.com/brute-forcing-passwords-with-ncrack-hydra-and-medusa/
> > >
> > > * Service recognition through Nmap:
> > >
> > > Ncrack can automatically get input from the normal (-oN) or XML (-oX)
> > > Nmap output, recognize which ports are open and brute-force the equivalent
> > > services that its modules support.
> > >
> > > *  Fine-grained timing control:
> > >
> > > Ncrack provides a variety of timing options with which you can optimize
> > > your brute-force scans. Alongside the generic timing templates (T0 - T5),
> > > you can specify the upper and lower limit of network connections per
> > > service, the total number of connections, the authentication tries per
> > > connection, the delay between each connection initiation and others which
> > > give the penetration tester total control of a brute-force attack allowing
> > > him to be flexible both in terms of stealth and performance.
> > >
> > > Other features include:
> > > * Stop current session and restore it later.
> > > * Built-in lists of most frequently used usernames and passwords.
> > > * Various modes of username/password list iteration (username first,
> > > password first, pairwise)
> > >
> > > It would be great if nmap-dev voiced their opinion on which new features
> > > they would like to see in Ncrack:
> > >
> > > - Which new protocols should Ncrack support? (prioritization list)
> > > - What new features would be most helpful for the pentester?
> > > - Any other ideas for improvement
> > >
> > > For anyone that would like to help improve Ncrack by building more
> > > protocol modules, I have written an extensive guide on how this can easily
> > > be accomplished: https://nmap.org/ncrack/devguide.html
> > >
> > > Cheers,
> > > Ithilgore
> > > (Fotis Hantzis)
> > >
> > > --
> > > http://sock-raw.org
> > >
> > >
> > >
> > > _______________________________________________
> > > Sent through the dev mailing list
> > > https://nmap.org/mailman/listinfo/dev
> > > Archived at http://seclists.org/nmap-dev/
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://nmap.org/mailman/private/dev/attachments/20151105/9bb808e3/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> dev mailing list
> dev () nmap org
> https://nmap.org/mailman/listinfo/dev
>
>
> ------------------------------
>
> End of dev Digest, Vol 128, Issue 11
> ************************************

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/