Re: nmap-dev Digest, Vol 73, Issue 12

[dheeraj suthar <dheerajsuthar2008 () gmail com>]

Hi,
I was going through the NSE scripts. I would like to work on the Web
Scanning and Vuln and Exploitation script as I have previous experience in
creating scripts for scanning(https://launchpad.net/opengenparser). However
the problem is that I have worked in python. I can learn Lua once my exams
get over(30Apr).
My idea is to present a command line menu based system for the exploits,
similar to that of metaspoilt. Rather then intializing one script can't we
create groups and run the scripts for particular platform. This will also
make future additions easy. We can add the new vulnerabilities as they come
up through an easy interface(which I plan to design). The deliverable will
be a script manager which help one to guide the script to choose as per the
platform.
 Can you kindly guide how can refine this idea.

On Mon, Apr 4, 2011 at 4:13 AM, <nmap-dev-request () insecure org> wrote:

> Send nmap-dev mailing list submissions to
>        nmap-dev () insecure org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://cgi.insecure.org/mailman/listinfo/nmap-dev
> or, via email, send a message with subject or body 'help' to
>        nmap-dev-request () insecure org
>
> You can reach the person managing the list at
>        nmap-dev-owner () insecure org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of nmap-dev digest..."
>
>
> Today's Topics:
>
>   1. Re: [NSE]smb-psexec failed(Attacker: Windows 7, Victim:
>      Windows 7) (Ron)
>   2. RE: How to cancel a script scan (Rob Nicholls)
>   3. Does nmap enable you to scan using a specified interface?
>      (Frank Church)
>   4. Re: Does nmap enable you to scan using a specified interface?
>      (Houcem HACHICHA)
>   5. Re: How to cancel a script scan (Toni Ruottu)
>   6. Re: writing brute scripts for UDP based protocols
>      (Patrik Karlsson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 3 Apr 2011 15:37:22 -0500
> From: Ron <ron () skullsecurity net>
> Subject: Re: [NSE]smb-psexec failed(Attacker: Windows 7, Victim:
>        Windows 7)
> To: nmap-dev () insecure org
> Message-ID: <20110403153722.1e53a7fe@ankh>
> Content-Type: text/plain; charset=ISO-2022-JP
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> It looks like the login failed on Nmap. I *think* I fixed a bug related to
> logins failing fairly recently, but I could be wrong. Can you try the latest
> svn version and see if it works?
>
> The other thing to try is adding:
> - --script-args=smbtype=nvlmv2
>
> Right now I'm defaulting the hashtype to NTLMv1. I think I'm going to
> update the scripts, at some point, and default it to NTLMv2. I don't see any
> reason not to.
>
> Ron
>
> On Mon, 4 Apr 2011 00:44:21 +0900 kaito <kaito834 () gmail com> wrote:
> > Hello
> >
> > This is kaito.
> >
> > I failed to execute smb-psexec script for Nmap Script Engine(NSE).
> > I tried to Windows 7 from Nmap 5.51 on another Windows 7 and failed.
> > But, I tried to Windows 7 from PsExec v1.98 on Windows 7
> > and succeeded.
> >
> > I configured a registry "LocalAccountTokenFilterPolicy" to DWORD 1
> > on Windows 7 for Victim; the registry key is explained in following
> > url.
> > http://technet.microsoft.com/en-us/library/ee844186%28WS.10%29.aspx
> > Therefore, PsExec was successful, I think.
> >
> > I wrote output of Nmap and PsExec in this mail, and attached pcap
> > files.
> >
> > * Nmap result from Windows 7 to another Windows 7
> > --------------------------------
> > D:\Nmap>nmap -d --script=smb-psexec
> > --script-args=smbuser=user_admin,smbpass=admin -p 445 192.168.0.50
> > Winpcap present, dynamic linked to: WinPcap version 4.1.2 (packet.dll
> > version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b
> > (20091008)
> >
> > Starting Nmap 5.51 ( http://nmap.org ) at 2011-04-03 22:44 ??
> > (???) --------------- Timing report ---------------
> >   hostgroups: min 1, max 100000
> >   rtt-timeouts: init 1000, min 100, max 10000
> >   max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
> >   parallelism: min 0, max 0
> >   max-retries: 10, host-timeout: 0
> >   min-rate: 0, max-rate: 0
> > ---------------------------------------------
> > NSE: Loaded 1 scripts for scanning.
> > NSE: Starting runlevel 1 (of 1) scan.
> > Initiating ARP Ping Scan at 22:44
> > Scanning 192.168.0.50 [1 port]
> > Packet capture filter (device eth6): arp and arp[18:4] = 0x000B97BE
> > and arp[22:2] = 0x858C
> > Completed ARP Ping Scan at 22:44, 0.59s elapsed (1 total hosts)
> > Overall sending rates: 1.69 packets / s, 71.19 bytes / s.
> > (snip)
> > DNS resolution of 1 IPs took 0.09s. Mode: Async [#: 7, OK: 0, NX: 1,
> > DR: 0, SF:0, TR: 1, CN: 0]
> > Initiating SYN Stealth Scan at 22:44
> > Scanning 192.168.0.50 [1 port]
> > Packet capture filter (device eth6): dst host 192.168.0.108 and (icmp
> > or ((tcp or udp or sctp) and (src host 192.168.0.50)))
> > Discovered open port 445/tcp on 192.168.0.50
> > Completed SYN Stealth Scan at 22:44, 0.03s elapsed (1 total ports)
> > Overall sending rates: 35.71 packets / s, 1571.43 bytes / s.
> > NSE: Starting runlevel 1 (of 1) scan.
> > NSE: Starting smb-psexec against 192.168.0.50.
> > NSE: Script scanning 192.168.0.50.
> > Initiating NSE at 22:44
> > NSE: smb-psexec: Looking for the service file: nmap_service or
> > nmap_service.exe NSE: smb-psexec: Attempting to find file:
> > nmap_service NSE: smb-psexec: Attempting to find file: default
> > NSE: smb-psexec: Attempting to load config file:
> > D:\Nmap\nselib/data/psexec/default.lua
> > NSE: SMB: Attempting to log into the system to enumerate shares
> > NSE: SMB: Added account '' to account list
> > NSE: SMB: Added account 'guest' to account list
> > NSE: SMB: Added account 'user_admin' to account list
> > NSE: SMB: Extended login as \user_admin failed
> > (NT_STATUS_NOT_SUPPORTED) NSE: SMB: Extended login as \guest failed
> > (NT_STATUS_NOT_SUPPORTED) NSE: SMB: Extended login as \<blank> failed
> > (NT_STATUS_NOT_SUPPORTED) NSE: SMB: Enumerating shares failed,
> > guessing at common ones (No accounts left to try)
> > NSE: SMB: Extended login as \<blank> failed (NT_STATUS_NOT_SUPPORTED)
> > NSE: SMB: ERROR: All logins failed, sorry it didn't work out!
> > NSE: Finished smb-psexec against 192.168.0.50.
> > Completed NSE at 22:44, 0.21s elapsed
> > Nmap scan report for 192.168.0.50
> > Host is up, received arp-response (0.0022s latency).
> > Scanned at 2011-04-03 22:44:20 ?? (???) for 1s
> > PORT    STATE SERVICE      REASON
> > 445/tcp open  microsoft-ds syn-ack
> > MAC Address: 00:0C:29:75:ED:ED (VMware)
> >
> > Host script results:
> > | smb-psexec:
> > |_  ERROR: NT_STATUS_NOT_SUPPORTED (May not have an administrator
> > account) Final times for host: srtt: 2250 rttvar: 6250  to: 100000
> >
> > NSE: Starting runlevel 1 (of 1) scan.
> > Read from D:\Nmap: nmap-mac-prefixes nmap-payloads nmap-services.
> > Nmap done: 1 IP address (1 host up) scanned in 3.06 seconds
> >            Raw packets sent: 2 (72B) | Rcvd: 2 (72B)
> > --------------------------------
> >
> > * PsExec result from Windows 7 to another Windows 7
> > --------------------------------
> > D:\PsTools>psexec \\192.168.0.50 -u user_admin -p admin ipconfig
> >
> > PsExec v1.98 - Execute processes remotely
> > Copyright (C) 2001-2010 Mark Russinovich
> > Sysinternals - www.sysinternals.com
> >
> > Windows IP ??
> >
> > ?????? ????? ???? ?????:
> >
> >    ????? DNS ?????? . . . :
> >    ??????? IPv6 ????. . . . : fe80::6cfa:6faa:5805:71d2%11
> >    IPv4 ???? . . . . . . . . . . : 192.168.0.50
> >    ????? ??? . . . . . . . . : 255.255.255.0
> >    ????? ?????? . . . . . : 192.168.0.1
> >
> > Tunnel adapter isatap.{D9412E54-B207-497F-ACF1-A74FAD2C26C6}:
> >
> >    ???????. . . . . . . . . . : ??????????????
> >    ????? DNS ?????? . . . :
> >
> > Tunnel adapter ???? ?????* 9:
> >
> >    ????? DNS ?????? . . . :
> >    IPv6 ???? . . . . . . . . . . . :
> > 2001:0:4137:9e76:24a3:fba8:2575:aff6 ??????? IPv6
> > ????. . . . : fe80::24a3:fba8:2575:aff6%12 ?????
> > ?????? . . . . . : :: ipconfig exited on 192.168.0.50 with
> > error code 0. --------------------------------
> >
> >
> > --
> > kaito<kaito834 () gmail com>
> > Blog: http://d.hatena.ne.jp/kaito834/
> > Twitter: http://twitter.com/kaito834/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAk2Y2oIACgkQ2t2zxlt4g/QPNQCgsjGIHs7hmWsuLdYflUkEqkk+
> NcgAn1SpXyF6FCsM8qffZIwRT2+XSxT9
> =OKzU
> -----END PGP SIGNATURE-----
>
> ------------------------------
>
> Message: 2
> Date: Sun, 3 Apr 2011 22:01:15 +0100
> From: "Rob Nicholls" <robert () robnicholls co uk>
> Subject: RE: How to cancel a script scan
> To: <nmap-dev () insecure org>
> Cc: 'Ron' <ron () skullsecurity net>
> Message-ID: <020f01cbf242$45855380$d08ffa80$@robnicholls.co.uk>
> Content-Type: text/plain;       charset="us-ascii"
>
> I suspect we could make some major improvements to the hostgroup and resume
> features, and it could make a good (if not slightly "boring" compared to
> things like improving IPv6 support) GSoC project.
>
> Even with things like --defeat-rst-ratelimit, a single host can tie up a
> long scan and prevent the next scanning phase, or next hostgroup, from
> being
> launched. Not being able to --resume just those remaining hosts, never mind
> resuming where it had left off, is quite annoying as you have to scan the
> entire hostgroup again (which is why I pretty much never use --resume, I
> try
> to manually time scans to complete by a certain time, even if it means
> manually merging XML data together). It might be useful if the hostgroup
> can
> move onto the service scans and NSE scripts while the final hosts are still
> undergoing their original portscans.
>
> Those slow hosts can prevent the output from being written, and even if you
> check the verbose output for the discovered ports, you won't end up with
> XML
> output, which I find far more useful nowadays. It'd be nice if we could
> somehow resume scans from and still generate the XML files - I know there
> are issues, but what are they and can we work around them?
>
> I'm aware that it could affect the grepable output and potentially break
> (poorly written) scripts that people have written that assume, for example,
> that completed IPs will match the input list order or range (e.g.
> 192.168.0.1-4 could produce scan results for .3, .2, .4 and finally .1).
>
> Rob
>
> -----Original Message-----
> From: nmap-dev-bounces () insecure org [mailto:nmap-dev-bounces () insecure org]
> On Behalf Of Ron
> Sent: 03 April 2011 21:17
> To: nmap-dev () insecure org
> Subject: Re: How to cancel a script scan
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 29 Mar 2011 11:35:30 +0100 Houcem HACHICHA
> <houcem.hachicha () gmail com> wrote:
> > Hello everyone,
> >
> > Is there a way to cancel an undergoing script scan? (without losing
> > the portscan results of course)
> >
> > Thanks in advance,
> There's a secret way: pull out your network cable.
>
> It doesn't work for every script, but in most cases it'll cause the script
> scan to fail quickly.
>
> Something that Nmap really ought to have, and maybe we should add it to the
> TODO list if it isn't already there, is the ability to display the "output
> so far" when you kill nmap with ctrl-c. That way, if you have to kill a
> scan
> half-way through, you don't lose all the data you've already accumulated.
>
> One step further would be to add a feature like Hydra or John has, where
> it'll save its progress to a file and can resume from where it left off.
> That'd be super awesome, but I'm not sure if it's possible.
>
> Ron
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAk2Y1aUACgkQ2t2zxlt4g/SWoACeN8fUliIzHpc2LD9hxopYtgSb
> XkEAoL47rEGWPO2vcTrtJWi9Fl7zXkrL
> =p9ar
> -----END PGP SIGNATURE-----
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 3 Apr 2011 22:29:02 +0100
> From: Frank Church <vfclists () gmail com>
> Subject: Does nmap enable you to scan using a specified interface?
> To: nmap-dev () insecure org
> Message-ID: <BANLkTin9WNp-1KPXMcvmyZDjKNKXHJDxfQ () mail gmail com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Does nmap enable you to scan using a specified interface, that interface
> only?
>
> --
> Frank Church
>
> =======================
> http://devblog.brahmancreations.com
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 3 Apr 2011 22:31:59 +0100
> From: Houcem HACHICHA <houcem.hachicha () gmail com>
> Subject: Re: Does nmap enable you to scan using a specified interface?
> To: Frank Church <vfclists () gmail com>
> Cc: nmap-dev () insecure org
> Message-ID: <BANLkTin5E_UQdymodneobeJZ2fYueYfoeA () mail gmail com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sun, Apr 3, 2011 at 10:29 PM, Frank Church <vfclists () gmail com> wrote:
>
> > Does nmap enable you to scan using a specified interface, that interface
> > only?
> >
> > *-e interface_name* should do it
>
>
> > --
> > Frank Church
> >
> > =======================
> > http://devblog.brahmancreations.com
> > _______________________________________________
> > Sent through the nmap-dev mailing list
> > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > Archived at http://seclists.org/nmap-dev/
>
>
>
> --
> *Regads,
> Houcem*
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 4 Apr 2011 01:24:21 +0300
> From: Toni Ruottu <toni.ruottu () iki fi>
> Subject: Re: How to cancel a script scan
> To: Rob Nicholls <robert () robnicholls co uk>
> Cc: nmap-dev () insecure org, Ron <ron () skullsecurity net>
> Message-ID: <BANLkTikzuNbnCmsLh8AKE8ubu66kceF-pQ () mail gmail com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Would this be at all related to the the "scan playlist" feature we
> were discussing earlier. The idea was that nmap would have a list of
> pending so a script could add scans to the queue, in addition to
> adding targets to the ongoing scan. The details about this are in the
> air. No one knows have one should avoid adding duplicate scans into
> the queue and how or if one should aggregate scan results. I just
> thought I'd bring it up, as you are discussing resume, and I think
> that is another type of scanning management thing.
>
> On Mon, Apr 4, 2011 at 12:01 AM, Rob Nicholls <robert () robnicholls co uk>
> wrote:
> > I suspect we could make some major improvements to the hostgroup and
> resume
> > features, and it could make a good (if not slightly "boring" compared to
> > things like improving IPv6 support) GSoC project.
> >
> > Even with things like --defeat-rst-ratelimit, a single host can tie up a
> > long scan and prevent the next scanning phase, or next hostgroup, from
> being
> > launched. Not being able to --resume just those remaining hosts, never
> mind
> > resuming where it had left off, is quite annoying as you have to scan the
> > entire hostgroup again (which is why I pretty much never use --resume, I
> try
> > to manually time scans to complete by a certain time, even if it means
> > manually merging XML data together). It might be useful if the hostgroup
> can
> > move onto the service scans and NSE scripts while the final hosts are
> still
> > undergoing their original portscans.
> >
> > Those slow hosts can prevent the output from being written, and even if
> you
> > check the verbose output for the discovered ports, you won't end up with
> XML
> > output, which I find far more useful nowadays. It'd be nice if we could
> > somehow resume scans from and still generate the XML files - I know there
> > are issues, but what are they and can we work around them?
> >
> > I'm aware that it could affect the grepable output and potentially break
> > (poorly written) scripts that people have written that assume, for
> example,
> > that completed IPs will match the input list order or range (e.g.
> > 192.168.0.1-4 could produce scan results for .3, .2, .4 and finally .1).
> >
> > Rob
> >
> > -----Original Message-----
> > From: nmap-dev-bounces () insecure org [mailto:
> nmap-dev-bounces () insecure org]
> > On Behalf Of Ron
> > Sent: 03 April 2011 21:17
> > To: nmap-dev () insecure org
> > Subject: Re: How to cancel a script scan
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Tue, 29 Mar 2011 11:35:30 +0100 Houcem HACHICHA
> > <houcem.hachicha () gmail com> wrote:
> > > Hello everyone,
> > >
> > > Is there a way to cancel an undergoing script scan? (without losing
> > > the portscan results of course)
> > >
> > > Thanks in advance,
> > There's a secret way: pull out your network cable.
> >
> > It doesn't work for every script, but in most cases it'll cause the
> script
> > scan to fail quickly.
> >
> > Something that Nmap really ought to have, and maybe we should add it to
> the
> > TODO list if it isn't already there, is the ability to display the
> "output
> > so far" when you kill nmap with ctrl-c. That way, if you have to kill a
> scan
> > half-way through, you don't lose all the data you've already accumulated.
> >
> > One step further would be to add a feature like Hydra or John has, where
> > it'll save its progress to a file and can resume from where it left off.
> > That'd be super awesome, but I'm not sure if it's possible.
> >
> > Ron
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.9 (GNU/Linux)
> >
> > iEYEARECAAYFAk2Y1aUACgkQ2t2zxlt4g/SWoACeN8fUliIzHpc2LD9hxopYtgSb
> > XkEAoL47rEGWPO2vcTrtJWi9Fl7zXkrL
> > =p9ar
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > 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/
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 04 Apr 2011 00:43:34 +0200
> From: Patrik Karlsson <patrik () cqure net>
> Subject: Re: writing brute scripts for UDP based protocols
> To: Toni Ruottu <toni.ruottu () iki fi>,   nmap-dev <nmap-dev () insecure org>
> Message-ID: <C9BEB735.3163%patrik () cqure net>
> Content-Type: text/plain; charset="us-ascii"
>
> Den 2011-03-22 13.15 skrev Toni Ruottu <toni.ruottu () iki fi>:
>
>
> >  hey,
> >
> > Do we have an example of a brute script against a UDP based protocol?
> > I think the brute library is useless here. If the service reports
> > errors we can send auth packages, and check we get an error response
> > for each one we send. If the service only responds to packages with
> > correct credentials this becomes a lot harder, as we'll never know how
> > much traffic we can send and how many times we should retry given
> > credentials. Should we create a separate udpbrute library, or try to
> > squeeze this into the existing one?
> >
> >  --Toni
> > _______________________________________________
> > Sent through the nmap-dev mailing list
> > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > Archived at http://seclists.org/nmap-dev/
>
> Hi Toni,
>
> The word useless inspired me to write the first UDP based brute script. I
> first tried to re-write the SNMP brute script but it didn't turn out that
> great. While the brute library can be used it ends up being very slow. The
> reason for this is that the guessing engine needs to wait for a timeout in
> each cycle. A way around this is to run a huge amount of parallel
> coroutines (brute.threads), which will get a reasonable speed. As sockets
> are unconnected this seems to work reasonably well, although I didn't
> pursue this further.
>
> I also tried the same approach used by the current SNMP brute script, ie.
> sending all the requests first, and then wait for the response to come
> back. Unfortunately this didn't work great when the list of community
> names became larger. Running tcpdump on the server showed the request
> coming in, but every now and then there was no response coming back, even
> though the correct community string was supplied. This obviously wasn't
> reliable enough.
>
> After a while, I moved on to another protocol, SIP. While it took some
> time to implement what I needed I think the results turned out reasonably
> well. So, in my opinion, I believe this is more of an application protocol
> issue rather than the issue of UDP services in general.
>
> I'm attaching the SIP library (sip.lua), the brute script (sip-brute.nse)
> and a script that allows for user enumeration (sip-enum-users.nse).
>
> Cheers,
> Patrik
> --
> Patrik Karlsson
> http://www.cqure.net
> http://www.twitter.com/nevdull77
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: sip.lua
> Type: application/octet-stream
> Size: 28058 bytes
> Desc: not available
> URL: <
> http://cgi.insecure.org/mailman/private/nmap-dev/attachments/20110404/bac0585d/attachment.obj
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: sip-enum-users.nse
> Type: application/octet-stream
> Size: 4187 bytes
> Desc: not available
> URL: <
> http://cgi.insecure.org/mailman/private/nmap-dev/attachments/20110404/bac0585d/attachment-0001.obj
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: sip-brute.nse
> Type: application/octet-stream
> Size: 3201 bytes
> Desc: not available
> URL: <
> http://cgi.insecure.org/mailman/private/nmap-dev/attachments/20110404/bac0585d/attachment-0002.obj
> >
>
> ------------------------------
>
> _______________________________________________
> nmap-dev mailing list
> nmap-dev () insecure org
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
>
>
> End of nmap-dev Digest, Vol 73, Issue 12
> ****************************************
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/