Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: nmap-dev Digest, Vol 73, Issue 12
From: dheeraj suthar <dheerajsuthar2008 () gmail com>
Date: Mon, 4 Apr 2011 15:04:59 +0530

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/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]