Nabble - Nmap - Dev

Re: Kerberos probes for nmap

2009-12-21T23:55:58Z

Hi again,

I forgot to attach the signatures. Here they are:

Heimdal - Linux

SF-Port88-UDP:V=5.10BETA1%I=7%D=12/22%Time=4B307A41%P=i386-apple-darwin10.2.0%r(Kerberos,64,"~b0`\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e\xa4\x11\x18
SF:\x0f20091222075021Z\xa5\x05\x02\x03\x02\xbc\xda\xa6\x03\x02\x01<\xa9\x0
SF:4\x1b\x02NM\xaa\x170\x15\xa0\x03\x02\x01\0\xa1\x0e0\x0c\x1b\x06krbtgt\x
SF:1b\x02NM\xab\x16\x1b\x14No\x20client\x20in\x20request");

AD - Windows

SF-Port88-UDP:V=5.10BETA1%I=7%D=12/22%Time=4B3079C6%P=i386-apple-darwin10.2.0%r(Kerberos,4C,"~J0H\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e\xa4\x11\x18
SF:\x0f20091222074817Z\xa5\x05\x02\x03\x07A\xc0\xa6\x03\x02\x01D\xa9\x04\x
SF:1b\x02NM\xaa\x170\x15\xa0\x03\x02\x01\0\xa1\x0e0\x0c\x1b\x06krbtgt\x1b\
SF:x02NM");

//Patrik

On 22 dec 2009, at 08.01, David Fifield wrote:

> On Wed, Dec 16, 2009 at 02:38:30AM +0100, Patrik Karlsson wrote:
>> Here's a modified version of the packet where I have removed the things you mentioned.
>> I have not touched the algorithms, because I'm uncertain which ones to leave.
>> Removing some of them could reduce the footprint size by some 10 bytes or so.
>>
>> I ran the new probe against my Heimdal which got me:
>>
>> SF-Port88-UDP:V=5.10BETA1%I=7%D=12/16%Time=4B283757%P=i386-apple-darwin10.2.0%r(Kerberos,69,"~g0e\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e\xa4\x11\x18
>> SF:\x0f20091216012641Z\xa5\x05\x02\x03\x0e/\xc3\xa6\x03\x02\x01<\xa9\x15\x
>> SF:1b\x13<unspecified\x20realm>\xaa\x0b0\t\xa0\x03\x02\x01\0\xa1\x020\0\xa
>> SF:b\x16\x1b\x14No\x20server\x20in\x20request");
>>
>> I also tested it against a Windows server and it worked well, even
>> returned the name of the realm. Unfortunately I don't have access to a
>> OS X kerberos server or to MIT Kerberos for additional testing.
>
> I just tried the probe against Mac OS X (which I think uses MIT
> Kerberos) and it didn't get a response. I tried re-added the server name
> and that got a response. This time the error message returned was
> NULL_CLIENT instead of CLIENT_NOT_FOUND. Would you see if this probe
> works for you? I think it's the same as your original except that it
> uses the 1970-01-01 date and doesn't have a client name.
>
> Probe UDP Kerberos
> q|\x6a\x81\x6e\x30\x81\x6b\xa1\x03\x02\x01\x05\xa2\x03\x02\x01\x0a\xa4\x81\x5e\x30\x5c\xa0\x07\x03\x05\0\x50\x80\0\x10\xa2\x04\x1b\x02NM\xa3\x17\x30\x15\xa0\x03\x02\x01\0\xa1\x0e\x30\x0c\x1b\x06krbtgt\x1b\x02NM\xa5\x11\x18\x0f19700101000000Z\xa7\x06\x02\x04\x1f\x1e\xb9\xd9\xa8\x17\x30\x15\x02\x01\x12\x02\x01\x11\x02\x01\x10\x02\x01\x17\x02\x01\x01\x02\x01\x03\x02\x01\x02|
>
> Here's the response I get:
>
> SF-Port88-UDP:V=5.10BETA1%I=2%D=12/21%Time=4B306D97%P=i686-pc-linux-gnu%r(
> SF:Kerberos,6F,"~m0k\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e\xa2\x11\x18\x
> SF:0f19860718214913Z\xa4\x11\x18\x0f20091222065618Z\xa5\x05\x02\x03\x03G\x
> SF:e7\xa6\x03\x02\x01\x06\xa9\x04\x1b\x02NM\xaa\x170\x15\xa0\x03\x02\x01\0
> SF:\xa1\x0e0\x0c\x1b\x06krbtgt\x1b\x02NM\xab\x0e\x1b\x0cNULL_CLIENT\0");
>
> User Datagram Protocol, Src Port: kerberos (88), Dst Port: 46208 (46208)
> Kerberos KRB-ERROR
> Pvno: 5
> MSG Type: KRB-ERROR (30)
> ctime: 1986-07-18 21:49:13 (UTC)
> stime: 2009-12-22 06:56:18 (UTC)
> susec: 215015
> error_code: KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN (6)
> Realm: NM
> Server Name (Unknown): krbtgt/NM
> e-text: NULL_CLIENT
>
> Also, what tool are you using to make these packets? I was able to add
> the server name by hand but it's tricky to keep all the ASN.1 length
> values updated.
>
> David Fifield
> _______________________________________________
> 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

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

Re: Kerberos probes for nmap

2009-12-21T23:40:13Z

Hi David,

Heimdal now returns an error "No client in request" while Windows is saying KDC_ERR_WRONG_REALM.

When building my KrbGuess tool, that guesses valid usernames against a Kerberos server, I had to look into the details of the Kerberos protocol. I wrote some code that builds Kerberos packets, that unfortunately doesn't handle removing the stuff I have done now. So I have done it all by hand too.

//Patrik

On 22 dec 2009, at 08.01, David Fifield wrote:

Re: Kerberos probes for nmap

2009-12-21T23:01:22Z

On Wed, Dec 16, 2009 at 02:38:30AM +0100, Patrik Karlsson wrote:

> Here's a modified version of the packet where I have removed the things you mentioned.
> I have not touched the algorithms, because I'm uncertain which ones to leave.
> Removing some of them could reduce the footprint size by some 10 bytes or so.
>
> I ran the new probe against my Heimdal which got me:
>
> SF-Port88-UDP:V=5.10BETA1%I=7%D=12/16%Time=4B283757%P=i386-apple-darwin10.2.0%r(Kerberos,69,"~g0e\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e\xa4\x11\x18
> SF:\x0f20091216012641Z\xa5\x05\x02\x03\x0e/\xc3\xa6\x03\x02\x01<\xa9\x15\x
> SF:1b\x13<unspecified\x20realm>\xaa\x0b0\t\xa0\x03\x02\x01\0\xa1\x020\0\xa
> SF:b\x16\x1b\x14No\x20server\x20in\x20request");
>
> I also tested it against a Windows server and it worked well, even
> returned the name of the realm. Unfortunately I don't have access to a
> OS X kerberos server or to MIT Kerberos for additional testing.

I just tried the probe against Mac OS X (which I think uses MIT
Kerberos) and it didn't get a response. I tried re-added the server name
and that got a response. This time the error message returned was
NULL_CLIENT instead of CLIENT_NOT_FOUND. Would you see if this probe
works for you? I think it's the same as your original except that it
uses the 1970-01-01 date and doesn't have a client name.

Probe UDP Kerberos
q|\x6a\x81\x6e\x30\x81\x6b\xa1\x03\x02\x01\x05\xa2\x03\x02\x01\x0a\xa4\x81\x5e\x30\x5c\xa0\x07\x03\x05\0\x50\x80\0\x10\xa2\x04\x1b\x02NM\xa3\x17\x30\x15\xa0\x03\x02\x01\0\xa1\x0e\x30\x0c\x1b\x06krbtgt\x1b\x02NM\xa5\x11\x18\x0f19700101000000Z\xa7\x06\x02\x04\x1f\x1e\xb9\xd9\xa8\x17\x30\x15\x02\x01\x12\x02\x01\x11\x02\x01\x10\x02\x01\x17\x02\x01\x01\x02\x01\x03\x02\x01\x02|

Here's the response I get:

SF-Port88-UDP:V=5.10BETA1%I=2%D=12/21%Time=4B306D97%P=i686-pc-linux-gnu%r(
SF:Kerberos,6F,"~m0k\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e\xa2\x11\x18\x
SF:0f19860718214913Z\xa4\x11\x18\x0f20091222065618Z\xa5\x05\x02\x03\x03G\x
SF:e7\xa6\x03\x02\x01\x06\xa9\x04\x1b\x02NM\xaa\x170\x15\xa0\x03\x02\x01\0
SF:\xa1\x0e0\x0c\x1b\x06krbtgt\x1b\x02NM\xab\x0e\x1b\x0cNULL_CLIENT\0");

User Datagram Protocol, Src Port: kerberos (88), Dst Port: 46208 (46208)
Kerberos KRB-ERROR
Pvno: 5
MSG Type: KRB-ERROR (30)
ctime: 1986-07-18 21:49:13 (UTC)
stime: 2009-12-22 06:56:18 (UTC)
susec: 215015
error_code: KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN (6)
Realm: NM
Server Name (Unknown): krbtgt/NM
e-text: NULL_CLIENT

Also, what tool are you using to make these packets? I was able to add
the server name by hand but it's tricky to keep all the ASN.1 length
values updated.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

Re: Zenmap Target - Still cant fix it !

2009-12-21T16:38:59Z

On Sun, Dec 20, 2009 at 09:21:55AM +0800, Mike E-Wire Mail wrote:
> Recently I raised an issue about clearing Zenmap target history.
> The very quick reply sounded fine and I deleted the relevant file.
> Unfortunately this didnt fix the problem so I assumed that Zenmap was
> getting its history from elsewhere. As I couldnt find another likely
> file I unistalled both NMap and Zenmap - a simple task.
> After reinstalling both I assumed all would be fixed. It wasnt !!! The
> same long list appears.
> So where does Zenmap really get its info from ?
> Any help would be good. Thanks

target_list.txt is the only place Zenmap stores is list of targets. Try
searching for any any other copies of that file. The one you deleted
might have been in a directory of a previous installation or something.

If you're running as root on Unix you have to delete
/root/.zenmap/target_list.txt, not the one in your normal user's home
directory.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

Re: [NSE] NTP info gathering script...

2009-12-21T12:36:28Z

Hey,

For what it's worth, I've already gotten a lot of value out of this script.

Thanks for writing it!

Ron

On 11/28/2009 01:30 PM, Richard Sammet wrote:

> Hi Guys,
>
> as there is no NTP info gathering script yet, I decided to assemble one:
>
>>>>
>
> $> nmap --script=ntp-info -sV -sU -p 123 192.168.1.33 -n
>
> Starting Nmap 5.00 ( http://nmap.org ) at 2009-11-28 20:22 CET
> Interesting ports on 192.168.1.33:
> PORT STATE SERVICE VERSION
> 123/udp open ntp NTP v4
> | ntp-info:
> | |_version: ntpd 4.2.4p6@... Thu Oct 22 21:58:37 UTC 2009 (1)
> | |_processor: i686
> | |_system: Linux/2.6.31-15-generic
> |_ |_refid: 91.189.94.4
> MAC Address: 00:0C:29:15:50:0C (VMware)
>
> Service detection performed. Please report any incorrect results at
> http://nmap.org/submit/ .
> Nmap done: 1 IP address (1 host up) scanned in 3.58 seconds
>
> <<<
>
> Please find it attached. Some testing would be good ;)
>
>
> Greetings,
> Richard
>
>
>
> _______________________________________________
> 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/

Re: [NSE] NTP info gathering script...

2009-12-21T12:28:43Z

On Mon, Dec 14, 2009 at 06:55:31PM +0100, Richard Sammet wrote:

> Hi David,
>
> On Sun, Dec 13, 2009 at 12:46 AM, David Fifield <david@...> wrote:
> ...
> > * As a consequence of the above, short timeouts are no longer required,
> > so I removed the timeout code to just use the defaults.
> ...
>
> well, it looks like this was a bad idea ;) I performed some extensive
> tests with the version you checked in to the trunk and I noted that
> the script now "blocks" the hole scan if no data is returned by the
> ntp server while waiting for the default timeout value which is -
> obviously - to long.
>
> The benchmarks:
>
> command and options: ./nmap -sU -p 123 --script=ntp-info
> XXX.XXX.72.0/24 XXX.XXX.12.0/24 --open -n -T5 --max-hostgroup 128
> --max-retries 1 -vvv -PN
>
> Script with default timeouts (version from trunk):
>
> Nmap done: 512 IP addresses (512 hosts up) scanned in 1640.67 seconds
> Raw packets sent: 1021 (77.596KB) | Rcvd: 22 (1608B)
>
> Script with modified timeouts:
>
> Nmap done: 512 IP addresses (512 hosts up) scanned in 65.72 seconds
> Raw packets sent: 1020 (77.520KB) | Rcvd: 18 (1232B)

You're right. I hadn't considered that the script will run for
open|filtered ports. The 30-second default timeout is too long to do
many of those. I think the proposed timeouts of 5500, 3500, 3000, 1500,
and 750 ms, differing based on timing template, are overall too short.
I've set a static timeout of 5000 ms, as is used in some other UDP
scripts, and changed the script not to wait for a response to the second
probe if the first one didn't work.

If this is still too slow, a way to do this scan faster is to increase
--max-parallelism, which will increase the number of simultaneous
sockets used by NSE. It is 20 by default.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

Re: [PATCH] Allow NSE script to set service info without -sV

2009-12-21T11:27:26Z

On Sat, Dec 19, 2009 at 11:27:45AM -0600, Tom Sellers wrote:

> I have attached a patch that changes nmap behavior so that NSE scripts can
> modify a service's product, version, extrainfo, ostype and devicetype
> even if nmap was called without version detection (-sV).
>
> As far as I can tell nmap will not let you set these values unless version
> detection is requested. I often want to run very targeted scans against
> a service using a script, output that data to XML and then use ruby code
> to parse and report on the findings. If this change is implemented I can
> cut down on the network overhead and potential impact on my targets.
>
>
>
> In nse_nmaplib.cc starting at line 551 the code logic says that if a service
> scan is requested set all the service values (product, version, etc), if
> not just set the probe state, name and tunnel values.
>
> The change I made basically detects if any of the normally unset values
> have been populated, if so set the o.servicescan value to be true. I had
> tried just writing the values out without touching the o.servicescan variable
> but this tripped an assert in NmapOutputTable.cc because there were not
> enough columns allocated in the service table output.
>
> Ultimately the change I settled on consists of adding the following two
> lines to nse_nmaplib.cc:
>
> if ( product || version || extrainfo || hostname || ostype || devicetype )
> o.servicescan = true;

I'd like you to try solving this a different way. In the printportoutput
function in output.cc, it allocates an extra column in the output table
if o.servicescan is true. You could change this to do a quick pass over
the port table (encapsulated in a function) to check if any ports have
version results. That function would also always return true if
o.servicescan is set. With the new Port structure after the recent
memory reduction work, all you have to do is check that Port::service is
non-NULL.

I don't think there's a good reason for l_set_port_version to refuse to
store all the service information if o.servicescan is not set. You
should take that out if it doesn't cause problems.

The reason I don't like changing o.servicescan is that it might have
side effects. In fact, won't that cause a real service scan to be run
for following host groups?

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

Re: POC Payloader dat

2009-12-21T11:16:59Z

On Sat, Dec 19, 2009 at 12:16:59PM -0500, Jay Fink wrote:

> On Mon, Dec 14, 2009 at 7:38 PM, Jay Fink <jay.fink@...> wrote:
> > On Sun, Dec 13, 2009 at 5:32 PM, David Fifield <david@...> wrote:
> >> That looks pretty good, but if we're not going to be 100% compatible
> >> with Unicornscan's file, then there's no need for ours to look like
> >> theirs. The braces and semicolon can be removed. I'm thinking about a
> >> format more like we have in nmap-service-probes, with named fields
> >> instead of positional values.
> >>
> >> /* comment */
> >> payload udp 1604,1645,1812
> >> "\x1e\x00\x01\x30\x02\xfd\xa8\xe3\x00\x00\x00\x00\x00\x00\x00\x00"
> >> "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
> >> source 100
>
> Attached is a sample of this; I guess the only question I have is do
> we really need the payload label? Wouldn't it be simpler with just:
>
> /* payload_citrix */
> udp 1604,1645,1812
> "\x1e\x00\x01\x30\x02\xfd\xa8\xe3\x00\x00\x00\x00\x00\x00\x00\x00"
> "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
> source 100

Thanks, that looks really good. Now that I've thought about it some
more, I think the file should use # comments instead of /* */ comments
for uniformity with the other data files. Commonents would still be
allowed between lines of the payload.

I agree with you that we don't need the "payload" specifier. "udp" works
fine as a keyword.

I'm happy with this format if you want to get started.

> So basically - pending that first label - I am about ready to jump off.
> I will need to do some more mining to figure out which payloads can
> share dports and who might need a non-magic sport but at least with
> the format down I can get started.

So far our needs for this are modest. The radius probe having two
destination ports and the ike wanting a source port of 500 are the only
examples I know of.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

Re: [SCRIPT] IBM DB2 Server Profile export + Version detection

2009-12-21T08:41:55Z

Works great for me against a handful of work servers!

The only issue I had is that port 523 isn't in the default portlist, so
make sure you give it on the commandline if you're testing this.

Ron

On 12/19/2009 07:41 AM, Tom Sellers wrote:

> I have finally (only a month late) finished the script to query the IBM DB2
> Administration Server (DAS) service. The script connects to the DB2 DAS
> service
> on either TCP or UDP port 523. No authentication is required for the
> connection.
>
>
> The data it returns matches what would be returned if one were to use
> the Export
> Server Profile command using the DB2 Control Center GUI:
>
> PORT STATE SERVICE VERSION
> 523/tcp open ibm-db2 IBM DB2 Database Server 9.07.0
> | db2-das-info: DB2 Administration Server Settings
> | ;DB2 Server Database Access Profile
> | ;Use BINARY file transfer
> | ;Comment lines start with a ";"
> | ;Other lines must be one of the following two types:
> | ;Type A: [section_name]
> | ;Type B: keyword=value
> |
> | [File_Description]
> | Application=DB2/LINUX 9.7.0
> | Platform=18
> | File_Content=DB2 Server Definitions
> | File_Type=CommonServer
> | File_Format_Version=1.0
> | DB2System=MYBIGDATABASESERVER
> | ServerType=DB2LINUX
> |
> | [adminst>dasusr1]
> | NodeType=1
> | DB2Comm=TCPIP
> | Authentication=SERVER
> | HostName=MYBIGDATABASESERVER
> | PortNumber=523
> | IpAddress=127.0.1.1
> |
> | [inst>db2inst1]
> | NodeType=1
> | DB2Comm=TCPIP
> | Authentication=SERVER
> | HostName=MYBIGDATABASESERVER
> | ServiceName=db2c_db2inst1
> | PortNumber=50000
> | IpAddress=127.0.1.1
> | QuietMode=No
> | TMDatabase=1ST_CONN
> |
> | [db>db2inst1:TOOLSDB]
> | DBAlias=TOOLSDB
> | DBName=TOOLSDB
> | Drive=/home/db2inst1
> | Dir_entry_type=INDIRECT
> |_Authentication=NOTSPEC
>
> The script will also set the service product and version data if possible.
>
> There is quite a bit of recon value in the data returned:
> DB2 version, server OS/platform, database names and port numbers, file
> system
> path names, hostname and IP address.
>
> Oddly enough I have see DB2 return the IPv6 address when queried over
> the IPv4 interface.
>
> Any testing or feedback with the functionality and structure of the
> script would
> be greatly appreciated!
>
> Of particular interest are:
> 1. Is the feedback too verbose? This is the format that the server returns
> the data in, barring some noise prior to the data. Should this be
> parsed out and reformatted?
>
> 2. If you test it on server I would love to see feedback on the Platform
> numbers that are returned and on what OSes. So far I have seen
> Platform=18 on Linux and Platform=5 on Windows.
>
> Thanks,
>
> Tom
>
>
>
>
>
>
>
>
> _______________________________________________
> 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/

Re: nmap-dev Zenmap Target - Still cant fix it ! (Mike E-Wire Mail)

2009-12-20T16:40:35Z

I thought this might be a fun problem to solve. I cannot duplicate the issue in zenmap 5.0 on Ubuntu Linux 9.10.
What operating system are you using?
-wolf

--Find out What You Need To Know - Network Security News

Does your Windows Computer run slow? Find out how to speed it up to how it ran when it was NEW! ComputerRepairBuddy.com
--------

Message: 2
Date: Sun, 20 Dec 2009 09:21:55 +0800
From: Mike E-Wire Mail <mikeody@...>
Subject: Zenmap Target - Still cant fix it !
To: nmap-dev@...
Message-ID: <4B2D7C33.90402@...>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Recently I raised an issue about clearing Zenmap target history.
The very quick reply sounded fine and I deleted the relevant file.
Unfortunately this didnt fix the problem so I assumed that Zenmap was
getting its history from elsewhere. As I couldnt find another likely
file I unistalled both NMap and Zenmap - a simple task.
After reinstalling both I assumed all would be fixed. It wasnt !!! The
same long list appears.
So where does Zenmap really get its info from ?
Any help would be good. Thanks
A copy of my previous posting is as follows :

/"I have an irritating but [I am sure] simple question to ask re Zenmap
and was wondering if someone could help please ? On the main interface
screen the box labeled 'Target' contains a list of the IP addresses and
[in some cases host names] of scan targets that have taken place - in
most cases I have NOT saved the results from these scans. I am trying to
clear out this list but cannot find the file where the IP addresses/host
names have been stored. Can anyone help please ? Thanks"./

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

_______________________________________________
nmap-dev mailing list
nmap-dev@...
http://cgi.insecure.org/mailman/listinfo/nmap-dev

End of nmap-dev Digest, Vol 57, Issue 25
****************************************

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

Zenmap Target - Still cant fix it !

2009-12-19T17:21:55Z

Recently I raised an issue about clearing Zenmap target history.
The very quick reply sounded fine and I deleted the relevant file.
Unfortunately this didnt fix the problem so I assumed that Zenmap was
getting its history from elsewhere. As I couldnt find another likely
file I unistalled both NMap and Zenmap - a simple task.
After reinstalling both I assumed all would be fixed. It wasnt !!! The
same long list appears.
So where does Zenmap really get its info from ?
Any help would be good. Thanks
A copy of my previous posting is as follows :

/"I have an irritating but [I am sure] simple question to ask re Zenmap
and was wondering if someone could help please ? On the main interface
screen the box labeled 'Target' contains a list of the IP addresses and
[in some cases host names] of scan targets that have taken place - in
most cases I have NOT saved the results from these scans. I am trying to
clear out this list but cannot find the file where the IP addresses/host
names have been stored. Can anyone help please ? Thanks"./
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

Re: [SCRIPT] IBM DB2 Server Profile export + Version detection

2009-12-19T15:29:42Z

Hi Tom,

I ran the script against both Windows and Linux and at first it looked great. Looking a bit closer I noticed that the server profile ended in the middle of a node description. Running the script against the same server several times sometimes ended up with a complete server profile and other times with just half of it.

My guess is that as your script searches for the beginning of the profile and breaks the loop once it detects it, you sometimes end up with incomplete data in the receive buffer, needing to call it again to retrieve the remaining data. I made some small changes so that it reads until it finds "\r\n\0" at the end of the receive buffer instead and then breaks. This change allowed me to get consistent results. If your interested in the diff let me know.

An even better (or overambitious?) solution might be to read a fixed length data header of the socket, retrieve the length of the data from this header, and then read the remaining data from the socket. That would require protocol documentation/knowledge or some packet analysis though. I did some initial packet analysis and found some stuff that was the same in each packet and some bytes that probably contain length info.

Regarding the platform, I'm seeing 5 for windows, but 30 for Linux.
I'm running it on a 64-bit Linux platform, don't know if this makes a difference.

| [File_Description]
| Application=DB2/LINUXX8664 9.7.0
| Platform=30
| File_Content=DB2 Server Definitions
| File_Type=CommonServer
| File_Format_Version=1.0
| DB2System=HARDY-SRV01
| ServerType=DB2LINUXX8664

| [File_Description]
| Application=DB2/NT 9.7.0
| Platform=5
| File_Content=DB2 Server Definitions
| File_Type=CommonServer
| File_Format_Version=1.0
| DB2System=EDUSRV011
| ServerType=DB2NT

//Patrik

On 19 dec 2009, at 14.41, Tom Sellers wrote:

> I have finally (only a month late) finished the script to query the IBM DB2
> Administration Server (DAS) service. The script connects to the DB2 DAS service
> on either TCP or UDP port 523. No authentication is required for the connection.
>
>
> The data it returns matches what would be returned if one were to use the Export
> Server Profile command using the DB2 Control Center GUI:
>
> PORT STATE SERVICE VERSION
> 523/tcp open ibm-db2 IBM DB2 Database Server 9.07.0
> | db2-das-info: DB2 Administration Server Settings
> | ;DB2 Server Database Access Profile
> | ;Use BINARY file transfer
> | ;Comment lines start with a ";"
> | ;Other lines must be one of the following two types:
> | ;Type A: [section_name]
> | ;Type B: keyword=value
> |
> | [File_Description]
> | Application=DB2/LINUX 9.7.0
> | Platform=18
> | File_Content=DB2 Server Definitions
> | File_Type=CommonServer
> | File_Format_Version=1.0
> | DB2System=MYBIGDATABASESERVER
> | ServerType=DB2LINUX
> |
> | [adminst>dasusr1]
> | NodeType=1
> | DB2Comm=TCPIP
> | Authentication=SERVER
> | HostName=MYBIGDATABASESERVER
> | PortNumber=523
> | IpAddress=127.0.1.1
> |
> | [inst>db2inst1]
> | NodeType=1
> | DB2Comm=TCPIP
> | Authentication=SERVER
> | HostName=MYBIGDATABASESERVER
> | ServiceName=db2c_db2inst1
> | PortNumber=50000
> | IpAddress=127.0.1.1
> | QuietMode=No
> | TMDatabase=1ST_CONN
> |
> | [db>db2inst1:TOOLSDB]
> | DBAlias=TOOLSDB
> | DBName=TOOLSDB
> | Drive=/home/db2inst1
> | Dir_entry_type=INDIRECT
> |_Authentication=NOTSPEC
>
> The script will also set the service product and version data if possible.
>
> There is quite a bit of recon value in the data returned:
> DB2 version, server OS/platform, database names and port numbers, file system
> path names, hostname and IP address.
>
> Oddly enough I have see DB2 return the IPv6 address when queried over the IPv4 interface.
>
> Any testing or feedback with the functionality and structure of the script would
> be greatly appreciated!
>
> Of particular interest are:
> 1. Is the feedback too verbose? This is the format that the server returns
> the data in, barring some noise prior to the data. Should this be
> parsed out and reformatted?
>
> 2. If you test it on server I would love to see feedback on the Platform
> numbers that are returned and on what OSes. So far I have seen
> Platform=18 on Linux and Platform=5 on Windows.
>
> Thanks,
>
> Tom
>
>
>
>
>
>
> <db2-das-info.nse>_______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/

Re: Nmap's memory use

2009-12-19T14:19:26Z

On Thu, Nov 19, 2009 at 06:04:58PM -0700, David Fifield wrote:

> We've had some report recently about Nmap using a lot of memory.
>
> "Port memory bloat"
> http://seclists.org/nmap-dev/2009/q3/926
> "nmap 5 memory usage"
> http://seclists.org/nmap-dev/2009/q4/300
>
> In the first link above, Pavel Kankovsky observed that it is the Port
> class that is using up most of the memory in some scans. My preliminary
> tests agree with this. I used the Massif memory profiling too
> (http://valgrind.org/docs/manual/ms-manual.html) from the Valgrind suite
> as follows:
>
> Pavel provided a patch that reduces the memory usage of all the Ports in
> the default state at the end. I think that is the right idea. I am going
> to try to see if there's a way to reduce their memory use even further,
> perhaps by changing the programming interface so that the creation of
> discrete objects isn't necessary.

I've finished working on memory reduction for now. Apart from the
earlier nmap-os-db parsing memory improvement described in
http://seclists.org/nmap-dev/2009/q4/479, I just merged two more
important improvements from the nmap-mem branch in r16308.

For a bit of context, first look at this benchmark scan, all UDP ports
on four hosts. It uses a maximum of 33.63 MB, almost all of it coming
from addPort at the end of the scan.
http://www.bamsoftware.com/wiki/Nmap/Memory#a20091118

The first new improvement was a reduction in size of Port objects. I
used Pavel's idea of dynamically allocating parts of Port that aren't
need for every port, like service and RPC information. The size of a
bare Port object dropped from 92 to 40 bytes on my machine. Now the peak
memory usage is 17.66 MB.
http://www.bamsoftware.com/wiki/Nmap/Memory#r16276

The second improvement is to avoid allocating some Port objects at all.
In many scans, the majority of probes don't receive a response. The big
spike in memory at the end of the previous two graphs is thousands of
Ports being created for the open|filtered ports that didn't respond. Now
the code has a notion of a "default port state" for ports that don't get
a response. All the ports in the default state share a single Port
object. This further reduced memory use to 5.94 MB.
http://www.bamsoftware.com/wiki/Nmap/Memory#r16290

The second improvement won't help, for example, when TCP ports are
closed because of RSTs rather than being filtered, but you will still
get the benefit of smaller Port objects.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

Re: Citrix scripts

2009-12-19T12:36:47Z

Hi Tom,

Nice to hear that the scripts are working and that they're retrieving the information they're expected to.
The ACL's are particularly interesting when searching for Citrix applications published anonymously.

//Patrik

On 19 dec 2009, at 15.19, Tom Sellers wrote:

> Patrik,
>
> Thanks for writing this code. I have recently run it against quite a few server
> and I really dig the output of published applications and who has rights to them. Excellent
> for use by a PenTester or System Admin that is looking for improperly secured apps.
>
> Kodos!
>
> Tom
>
> On 12/2/2009 3:19 PM, Patrik Karlsson wrote:
>> Hi all,
>>
>> I have re-worked and documented my Citrix scripts and made some changes and additions.
>> The new scripts target the XML Service rather than the ICA Browser and therefore can do more.
>>
>> As an example the XML versions of the application enumeration script does not only fetch a list of all published applications but also the required user or group memberships needed to access them. It will also find applications published anonymously.
>>
>> The Citrix XML Service usually listens to ports 80, 443 or 8080. It can be identified by the following server header: "Citrix Web PN Server". It can also "share ports" with IIS by running as an ISAP filter.
>>
>> I am attaching a zip file with the lot and a brief explanation of each file.
>> Feedback, suggestions and bug reports are most welcome!
>>
>> The zip contains 6 files:
>>
>> citrix-enum-apps-xml.nse
>> - A script that queries the Citrix XML Service for a list of applications
>>
>> citrix-enum-apps.nse
>> - A script that queries the ICA Browser for a list of applications
>>
>> citrix-enum-servers-xml.nse
>> -A script that queries the Citrix XML Service for a list of Citrix servers
>>
>> citrix-enum-servers.nse
>> - A script that queries the ICA Browser for a list of Citrix servers
>>
>> citrix-brute-xml.nse
>> - A script that attempts to guess usernames and passwords against the Citrix XML service
>> - It allows you to perform password guessing against the local Windows server or the domain
>>
>> citrixxml.lua
>> - The library containing some of the many XML requests and response parsers
> ed 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/

[PATCH] Allow NSE script to set service info without -sV

2009-12-19T09:27:45Z

I have attached a patch that changes nmap behavior so that NSE scripts can
modify a service's product, version, extrainfo, ostype and devicetype
even if nmap was called without version detection (-sV).

As far as I can tell nmap will not let you set these values unless version
detection is requested. I often want to run very targeted scans against
a service using a script, output that data to XML and then use ruby code
to parse and report on the findings. If this change is implemented I can
cut down on the network overhead and potential impact on my targets.

In nse_nmaplib.cc starting at line 551 the code logic says that if a service
scan is requested set all the service values (product, version, etc), if
not just set the probe state, name and tunnel values.

The change I made basically detects if any of the normally unset values
have been populated, if so set the o.servicescan value to be true. I had
tried just writing the values out without touching the o.servicescan variable
but this tripped an assert in NmapOutputTable.cc because there were not
enough columns allocated in the service table output.

Ultimately the change I settled on consists of adding the following two
lines to nse_nmaplib.cc:

if ( product || version || extrainfo || hostname || ostype || devicetype )
o.servicescan = true;

In my limited testing I have not found any problems or unexpected behaviors.
Obviously it needs further testing and review from more experienced eyes.

Any testing or feedback would be greatly appreciated.

Thanks much,

Tom

Index: nse_nmaplib.cc
===================================================================
--- nse_nmaplib.cc (revision 16303)
+++ nse_nmaplib.cc (working copy)
@@ -548,6 +548,9 @@
else
luaL_argerror(L, 2, "invalid value for port.version.service_tunnel");

+ if ( product || version || extrainfo || hostname || ostype || devicetype )
+ o.servicescan = true;
+
if (o.servicescan)
port->setServiceProbeResults(probestate, name, tunnel, product,
version, extrainfo, hostname, ostype, devicetype, NULL);

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

Re: POC Payloader dat

2009-12-19T09:16:59Z

On Mon, Dec 14, 2009 at 7:38 PM, Jay Fink <jay.fink@...> wrote:

> On Sun, Dec 13, 2009 at 5:32 PM, David Fifield <david@...> wrote:
>> That looks pretty good, but if we're not going to be 100% compatible
>> with Unicornscan's file, then there's no need for ours to look like
>> theirs. The braces and semicolon can be removed. I'm thinking about a
>> format more like we have in nmap-service-probes, with named fields
>> instead of positional values.
>>
>> /* comment */
>> payload udp 1604,1645,1812
>> "\x1e\x00\x01\x30\x02\xfd\xa8\xe3\x00\x00\x00\x00\x00\x00\x00\x00"
>> "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
>> source 100

Attached is a sample of this; I guess the only question I have is do
we really need the payload label? Wouldn't it be simpler with just:

/* payload_citrix */
udp 1604,1645,1812
"\x1e\x00\x01\x30\x02\xfd\xa8\xe3\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
source 100

So basically - pending that first label - I am about ready to jump off.
I will need to do some more mining to figure out which payloads can
share dports and who might need a non-magic sport but at least with
the format down I can get started.. I *don't* want to start without a
final format :-)

thanks,
j

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

payloads (18K) Download Attachment

Re: Citrix scripts

2009-12-19T06:19:46Z

Patrik,

Thanks for writing this code. I have recently run it against quite a few server
and I really dig the output of published applications and who has rights to them. Excellent
for use by a PenTester or System Admin that is looking for improperly secured apps.

Kodos!

Tom

On 12/2/2009 3:19 PM, Patrik Karlsson wrote:

> Hi all,
>
> I have re-worked and documented my Citrix scripts and made some changes and additions.
> The new scripts target the XML Service rather than the ICA Browser and therefore can do more.
>
> As an example the XML versions of the application enumeration script does not only fetch a list of all published applications but also the required user or group memberships needed to access them. It will also find applications published anonymously.
>
> The Citrix XML Service usually listens to ports 80, 443 or 8080. It can be identified by the following server header: "Citrix Web PN Server". It can also "share ports" with IIS by running as an ISAP filter.
>
> I am attaching a zip file with the lot and a brief explanation of each file.
> Feedback, suggestions and bug reports are most welcome!
>
> The zip contains 6 files:
>
> citrix-enum-apps-xml.nse
> - A script that queries the Citrix XML Service for a list of applications
>
> citrix-enum-apps.nse
> - A script that queries the ICA Browser for a list of applications
>
> citrix-enum-servers-xml.nse
> -A script that queries the Citrix XML Service for a list of Citrix servers
>
> citrix-enum-servers.nse
> - A script that queries the ICA Browser for a list of Citrix servers
>
> citrix-brute-xml.nse
> - A script that attempts to guess usernames and passwords against the Citrix XML service
> - It allows you to perform password guessing against the local Windows server or the domain
>
> citrixxml.lua
> - The library containing some of the many XML requests and response parsers

ed 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/

[SCRIPT] IBM DB2 Server Profile export + Version detection

2009-12-19T05:41:26Z

I have finally (only a month late) finished the script to query the IBM DB2
Administration Server (DAS) service. The script connects to the DB2 DAS service
on either TCP or UDP port 523. No authentication is required for the connection.

The data it returns matches what would be returned if one were to use the Export
Server Profile command using the DB2 Control Center GUI:

PORT STATE SERVICE VERSION
523/tcp open ibm-db2 IBM DB2 Database Server 9.07.0
| db2-das-info: DB2 Administration Server Settings
| ;DB2 Server Database Access Profile
| ;Use BINARY file transfer
| ;Comment lines start with a ";"
| ;Other lines must be one of the following two types:
| ;Type A: [section_name]
| ;Type B: keyword=value
|
| [File_Description]
| Application=DB2/LINUX 9.7.0
| Platform=18
| File_Content=DB2 Server Definitions
| File_Type=CommonServer
| File_Format_Version=1.0
| DB2System=MYBIGDATABASESERVER
| ServerType=DB2LINUX
|
| [adminst>dasusr1]
| NodeType=1
| DB2Comm=TCPIP
| Authentication=SERVER
| HostName=MYBIGDATABASESERVER
| PortNumber=523
| IpAddress=127.0.1.1
|
| [inst>db2inst1]
| NodeType=1
| DB2Comm=TCPIP
| Authentication=SERVER
| HostName=MYBIGDATABASESERVER
| ServiceName=db2c_db2inst1
| PortNumber=50000
| IpAddress=127.0.1.1
| QuietMode=No
| TMDatabase=1ST_CONN
|
| [db>db2inst1:TOOLSDB]
| DBAlias=TOOLSDB
| DBName=TOOLSDB
| Drive=/home/db2inst1
| Dir_entry_type=INDIRECT
|_Authentication=NOTSPEC

The script will also set the service product and version data if possible.

There is quite a bit of recon value in the data returned:
DB2 version, server OS/platform, database names and port numbers, file system
path names, hostname and IP address.

Oddly enough I have see DB2 return the IPv6 address when queried over the IPv4 interface.

Any testing or feedback with the functionality and structure of the script would
be greatly appreciated!

Of particular interest are:
1. Is the feedback too verbose? This is the format that the server returns
the data in, barring some noise prior to the data. Should this be
parsed out and reformatted?

2. If you test it on server I would love to see feedback on the Platform
numbers that are returned and on what OSes. So far I have seen
Platform=18 on Linux and Platform=5 on Windows.

Thanks,

Tom

description = [[
Connects to the IBM DB2 Administration Server (DAS) on TCP or UDP port 523 and
exports the server profile. No authentication is required for this request.

The script will also set the port product and version if a version scan is
requested.
]]

-- rev 0.6 (2009-12-16)

author = "Tom Sellers"

license = "Same as Nmap--See http://nmap.org/book/man-legal.html"

categories = {"safe", "discovery", "version"}

require "stdnse"
require "shortport"

portrule = shortport.port_or_service({523},"ibm-db2", {"tcp","udp"}, {"open", "open|filtered"})

action = function(host, port)

-- create the socket used for our connection
local socket = nmap.new_socket()

-- set a reasonable timeout value
socket:set_timeout(10000)

-- do some exception handling / cleanup
local catch = function()
stdnse.print_debug("%s", "db2-das-info: ERROR communicating with " .. host.ip .. " on port " .. port.number)
socket:close()
end

local try = nmap.new_try(catch)

try(socket:connect(host.ip, port.number, "tcp"))

-- ************************************************************************************
-- Transaction block 1
-- ************************************************************************************
local query = string.char(0x00, 0x00, 0x00, 0x00, 0x44, 0x42, 0x32, 0x44, 0x41, 0x53, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20)
query = query .. string.char(0x01, 0x04, 0x00, 0x00, 0x00, 0x10, 0x39, 0x7a, 0x00, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00)
query = query .. string.char(0x00, 0x00, 0x00, 0x00, 0x02, 0x0d, 0x00, 0x00, 0x00)
query = query .. string.char(0x00, 0x00, 0x00, 0x0d, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x4a, 0x00)

try(socket:send(query))

-- ************************************************************************************
-- Transaction block 2
-- ************************************************************************************
query = string.char(0x00, 0x00, 0x00, 0x00, 0x44, 0x42, 0x32, 0x44, 0x41, 0x53, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20)
query = query .. string.char(0x01, 0x04, 0x00, 0x00, 0x00, 0x10, 0x39, 0x7a, 0x00, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00)
query = query .. string.char(0x00, 0x00, 0x00, 0x00, 0x05, 0x2c, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x2c, 0x00, 0x00, 0x00)
query = query .. string.char(0x0c, 0x00, 0x00, 0x00, 0x08, 0x59, 0xe7, 0x1f, 0x4b, 0x79, 0xf0, 0x90, 0x72, 0x85, 0xe0, 0x8f)
query = query .. string.char(0x3e, 0x38, 0x45, 0x38, 0xe3, 0xe5, 0x12, 0xc4, 0x3b, 0xe9, 0x7d, 0xe2, 0xf5, 0xf0, 0x78, 0xcc)
query = query .. string.char(0x81, 0x6f, 0x87, 0x5f, 0x91)

try(socket:send(query))

-- ************************************************************************************
-- Transaction block 3
-- ************************************************************************************
query = string.char(0x00, 0x00, 0x00, 0x00, 0x44, 0x42, 0x32, 0x44, 0x41, 0x53, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20)
query = query .. string.char(0x01, 0x04, 0x00, 0x00, 0x00, 0x10, 0x39, 0x7a, 0x00, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00)
query = query .. string.char(0x00, 0x00, 0x00, 0x00, 0x03, 0x34, 0x00, 0x00, 0x00)
query = query .. string.char(0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00, 0x0c)
query = query .. string.char(0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x0c)
query = query .. string.char(0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x4c)
query = query .. string.char(0x00, 0x00, 0x04, 0xb8)

--try(socket:send(query))

-- ************************************************************************************
-- Transaction block 4
-- ************************************************************************************
query = string.char(0x00, 0x00, 0x00, 0x00, 0x44, 0x42, 0x32, 0x44, 0x41, 0x53, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20)
query = query .. string.char(0x01, 0x04, 0x00, 0x00, 0x00, 0x10, 0x39, 0x7a, 0x00, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00)
query = query .. string.char(0x00, 0x00, 0x00, 0x00, 0x0a, 0x5d, 0x00, 0x00, 0x00)
query = query .. string.char(0x00, 0x00, 0x00, 0x0d, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x4a, 0x01, 0x00, 0x00, 0x00)
query = query .. string.char(0x10, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x4c, 0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00)
query = query .. string.char(0x20, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x04, 0xb8, 0x64, 0x62, 0x32)
query = query .. string.char(0x64, 0x61, 0x73, 0x4b, 0x6e, 0x6f, 0x77, 0x6e, 0x44, 0x73, 0x63, 0x76, 0x00, 0x00, 0x00, 0x00)
query = query .. string.char(0x20, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x04, 0xb8, 0x64, 0x62, 0x32)
query = query .. string.char(0x4b, 0x6e, 0x6f, 0x77, 0x6e, 0x44, 0x73, 0x63, 0x76, 0x53, 0x72, 0x76, 0x00)

try(socket:send(query))

-- ************************************************************************************
-- Transaction block 5
-- ************************************************************************************
query = string.char(0x00, 0x00, 0x00, 0x00, 0x44, 0x42, 0x32, 0x44, 0x41, 0x53, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20)
query = query .. string.char(0x01, 0x04, 0x00, 0x00, 0x00, 0x10, 0x39, 0x7a, 0x00, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00)
query = query .. string.char(0x00, 0x00, 0x00, 0x00, 0x06, 0xca, 0x00, 0x00, 0x00)
query = query .. string.char(0x00, 0x00, 0x00, 0x0d, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x4a, 0x01, 0x00, 0x00, 0x00)
query = query .. string.char(0x20, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03)
query = query .. string.char(0x48, 0x00, 0x00, 0x00, 0x00, 0x4a, 0xfb, 0x42, 0x90, 0x00, 0x00, 0x24, 0x93, 0x00, 0x00, 0x00)
query = query .. string.char(0x10, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x4c, 0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00)
query = query .. string.char(0x10, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x4c, 0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00)
query = query .. string.char(0x20, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x04, 0xb8, 0x64, 0x62, 0x32)
query = query .. string.char(0x4b, 0x6e, 0x6f, 0x77, 0x6e, 0x44, 0x73, 0x63, 0x76, 0x53, 0x72, 0x76, 0x00, 0x00, 0x00, 0x00)
query = query .. string.char(0x20, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x04, 0xb8, 0x64, 0x62, 0x32)
query = query .. string.char(0x64, 0x61, 0x73, 0x4b, 0x6e, 0x6f, 0x77, 0x6e, 0x44, 0x73, 0x63, 0x76, 0x00, 0x00, 0x00, 0x00)
query = query .. string.char(0x0c, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00)
query = query .. string.char(0x0c, 0x00, 0x00, 0x00, 0x4c, 0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00)
query = query .. string.char(0x0c, 0x00, 0x00, 0x00, 0x4c, 0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x11, 0x00, 0x00, 0x00)
query = query .. string.char(0x0c, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x04, 0xb8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x42)
query = query .. string.char(0x32, 0x44, 0x41, 0x53, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x01, 0x04, 0x00, 0x00, 0x00, 0x10)
query = query .. string.char(0x39, 0x7a, 0x00, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07, 0xa4)
query = query .. string.char(0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x04, 0x00)
query = query .. string.char(0x00, 0x04, 0xb8, 0x64, 0x62, 0x32, 0x64, 0x61, 0x73, 0x4b, 0x6e, 0x6f, 0x77, 0x6e, 0x44, 0x73)
query = query .. string.char(0x63, 0x76, 0x00, 0x00, 0x00, 0x00, 0x20, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x04, 0x00)
query = query .. string.char(0x00, 0x04, 0xb8, 0x64, 0x62, 0x32, 0x4b, 0x6e, 0x6f, 0x77, 0x6e, 0x44, 0x73, 0x63, 0x76, 0x53)
query = query .. string.char(0x72, 0x76, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x4c, 0x00)
query = query .. string.char(0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x4c, 0x00)
query = query .. string.char(0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x4c, 0x00)
query = query .. string.char(0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x08, 0x00)
query = query .. string.char(0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x4c, 0x00, 0x00, 0x00, 0x01, 0x00)
query = query .. string.char(0x00, 0x00, 0x18, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00, 0x0c, 0x00)
query = query .. string.char(0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x18)

try(socket:send(query))

-- ************************************************************************************
-- Transaction block 6
-- ************************************************************************************
query = string.char(0x00, 0x00, 0x00, 0x00, 0x44, 0x42, 0x32, 0x44, 0x41, 0x53, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20)
query = query .. string.char(0x01, 0x04, 0x00, 0x00, 0x00, 0x10, 0x39, 0x7a, 0x00, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00)
query = query .. string.char(0x00, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00)

try(socket:send(query))

local status
local response

status, response = socket:receive()

local db2_config = nil
local temp_string = nil

while status do
status, response = socket:receive()

if response ~= nil then
-- Strip the nulls out of the response, they do odd things to string operations
temp_string = string.gsub(response,"%z","")

-- We get a couple of packets back, the one we want contains what amounts to a dump of a config file
if string.find(temp_string,";DB2 Server Database Access Profile") then
break
end

end -- if response
end -- while status

socket:close()

if (not status) or (response == "TIMEOUT") or (response == nil) then
stdnse.print_debug("%s","db2-das-info: ERROR: No data, ending communications with " .. host.ip .. ":" .. port.number .. "/" .. port.protocol)
return
end

-- The next block of code is essentially the version extraction code from db2-info.nse
local server_version = string.match(temp_string, "(SQL%d+)")
if string.sub(server_version,1,3) == "SQL" then
local major_version = string.sub(server_version,4,5)

-- strip the leading 0 from the major version, for consistency with
-- nmap-service-probes results
if string.sub(major_version,1,1) == "0" then
major_version = string.sub(major_version,2)
end
local minor_version = string.sub(server_version,6,7)
local hotfix = string.sub(server_version,8)
server_version = major_version .. "." .. minor_version .. "." .. hotfix
end

-- Try to determine which of the two values (probe version vs script) has more
-- precision. A couple DB2 versions send DB2 UDB 7.1 vs SQL090204 (9.02.04)
local _
local current_count = 0
if port.version.version ~= nil then
_, current_count = string.gsub(port.version.version, "%.", "%.")
end

local new_count = 0
if server_version ~= nil then
_, new_count = string.gsub(server_version, "%.", "%.")
end

if current_count < new_count then
port.version.version = server_version
end

-- The response contains various data before it gets to the config information
-- that we are after. The data we want starts with a semi-colon
-- Search for that marker ";" and copy it and everything after it into a string
local temp_int = string.find(temp_string,";")

if temp_int ~= nil then
temp_string = string.sub(temp_string,temp_int,string.len(temp_string))
end

if temp_string ~= nil then
result = "DB2 Administration Server Settings\r\n"
result = result .. temp_string

-- Strip out some noise
-- result = string.gsub(result,";DB2 Server Database Access Profile\r\n","")
-- result = string.gsub(result,";Use BINARY file transfer\r\n","")
-- result = string.gsub(result,";Comment lines start with a \";\"\r\n","")
-- result = string.gsub(result,";Other lines must be one of the following two types:\r\n","")
-- result = string.gsub(result,";Type A: %[section_name%]\r\n","")
-- result = string.gsub(result,";Type B: keyword=value\r\n\r\n","")

-- Set port information
port.version.name = "ibm-db2"
port.version.product = "IBM DB2 Database Server"
port.version.name_confidence = 100
nmap.set_port_version(host, port, "hardmatched")
nmap.set_port_state(host, port, "open")
end

return result

end

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

Dear Nmap-Dev, If you can't find it in google try JUSTDIAL.COM

2009-12-19T01:56:43Z

Dear Nmap-Dev,I strongly recommend this website www.justdial.com. It's a world class local search service & I've always found anything I've ever wanted.You can find info on any company, product, or service in over 240 cities in India.You can also call them up 24x7, on phone (69999999), a local call in 240 Indian cities.Ask for anything, you'll get the info on the phone and/or by SMS within 30 secs, and this service is absolutely FREE!For a change, it's an original Indian idea and an Indian company with world class service, and with a vision to spread all over the world.Be a proud Indian and forward this to every Indian you know.Best Wishes,KarthikClick Here to unsubscribe.

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

Re: cppcheck on nmap

2009-12-18T15:54:12Z

David Fifield wrote:

> On Thu, Dec 17, 2009 at 01:06:37AM +0200, Reijo Tomperi wrote:
>> I am one of the Cppcheck developers and I noticed this on your mailing list:
>>
>>> here is a scan of cppcheck over Nmap 5.10BETA1:
>>>
>>> [.\osscan2.cc:2942]: (error) Dangerous usage of erase
>>> [.\output.cc:354]: (error) Dangerous usage of erase
>>> [.\scan_engine.cc:1802]: (error) Dangerous usage of erase
>>> [.\scan_engine.cc:1849]: (error) Dangerous usage of erase
>>> [.\traceroute.cc:1253]: (error) Dangerous usage of erase
>> I'm posting this to inform you that all of these are false positives
>> (Cppcheck assumed that vector was used, when list was used instead). I
>> created a ticket about it for us:
>> http://sourceforge.net/apps/trac/cppcheck/ticket/1107

The ticket is now fixed. These false positives do not show up anymore
with the trunk version of Cppcheck.

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

Re: cppcheck on nmap

2009-12-18T15:28:37Z

On Thu, Dec 17, 2009 at 01:06:37AM +0200, Reijo Tomperi wrote:

> I am one of the Cppcheck developers and I noticed this on your mailing list:
>
> > here is a scan of cppcheck over Nmap 5.10BETA1:
> >
> > [.\osscan2.cc:2942]: (error) Dangerous usage of erase
> > [.\output.cc:354]: (error) Dangerous usage of erase
> > [.\scan_engine.cc:1802]: (error) Dangerous usage of erase
> > [.\scan_engine.cc:1849]: (error) Dangerous usage of erase
> > [.\traceroute.cc:1253]: (error) Dangerous usage of erase
>
> I'm posting this to inform you that all of these are false positives
> (Cppcheck assumed that vector was used, when list was used instead). I
> created a ticket about it for us:
> http://sourceforge.net/apps/trac/cppcheck/ticket/1107

Thanks Reijo, that's good to know.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

nmapsi4 -- nmap qt4 interface

2009-12-18T06:28:47Z

--
Hello,

I have developed an qt4 interface for nmap.

Project Description:
NmapSi4 is a complete Qt4-based Gui with the design goals
to provide a complete nmap interface for Users, in order to
management all options of this powerful security net scanner!

Home Page:
http://www.nmapsi4.org/
http://code.google.com/p/nmapsi4/

Git repository:
http://gitorious.org/nmapsi4

ScreenShot 0.1.1 / 0.2 alpha1:
http://kde-apps.org/content/show.php/nmapsi4?content=67158

Cheers,
Francesco
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

nmapsi4 -- nmap qt4 interface

2009-12-18T04:10:43Z

Nmap bug - Doesn't folow static route (plain text)

2009-12-18T02:59:06Z

Hi,
I use Nmap frequently at home and at work, before being useful in many
situations and I want to thank you for this sweet product.
Recently I discovered that when using static routes to subnet, Nmap does
not follow the route, but looking directly into local broadcast (ARP)

Ex:
[Nmap Host] <-10.1.0.0/20-> [GW1] <-192.168.1.0/24-> [GW2]
<-10.1.3.0/24-> [Target Host]

[Nmap Host]
IP : 10.1.0.15/20
GW1: 10.1.0.1
Static Route: 10.1.3.0/24 gw 10.1.0.1

[Target Host]
IP: 10.1.3.9/24
GW2: 10.1.3.1

> nmap --packet-trace -sS 10.1.3.9
Starting Nmap 5.00 ( http://nmap.org ) at 2009-12-18 08:41 GTB Standard Time
SENT (0.6720s) ARP who-has 10.1.3.9 tell 10.1.0.15
SENT (0.7820s) ARP who-has 10.1.3.9 tell 10.1.0.15
Note: Host seems down. If it is really up, but blocking our ping probes,
try -PN
Nmap done: 1 IP address (0 hosts up) scanned in 0.91 seconds

> nmap --iflist
Starting Nmap 5.00 ( http://nmap.org ) at 2009-12-18 08:41 GTB Standard Time
************************INTERFACES************************
DEV (SHORT) IP/MASK TYPE UP MAC
eth0 (eth0) 10.1.0.15/20 ethernet up 00:1A:DC:3E:34:AC
lo0 (lo0) 127.0.0.1/8 loopback up
DEV WINDEVICE
eth0 \Device\NPF_{00744106-FFB1-473B-AED9-3CD94673D5AA}
lo0 <none>
<none> \Device\NPF_GenericDialupAdapter
**************************ROUTES**************************
DST/MASK DEV GATEWAY
10.1.0.15/32 lo0 127.0.0.1
10.255.255.255/32 eth0 10.1.0.15
255.255.255.255/32 eth0 10.1.0.15
10.1.3.0/0 eth0 10.1.0.1
10.1.0.0/0 eth0 10.1.0.15
127.0.0.0/0 lo0 127.0.0.1
224.0.0.0/0 eth0 10.1.0.15
0.0.0.0/0 eth0 10.1.0.1

> ping -n 1 10.1.3.9
Pinging 10.1.3.9 with 32 bytes of data:
Reply from 10.1.3.9: bytes=32 time<1ms TTL=253
Ping statistics for 10.1.3.9:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

Best Regards,
Piroi Ninel

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

Re: zenmap: problems with GUI language

2009-12-17T03:58:11Z

On 2009/12/14 I wrote:
>
> Actually, I don't know of any Windows application that uses the LANG
> variable. I've seen some Windows applications that enable changing
> locale in their preferences (e.g. VLC media player and InfraRecorder,
> both under GNU GPL). It would be fine if I could do that in zenmap
> also.

I've found out that GIMP (www.gimp.org) supports changing locale using
the LANG variable. E.g. in a Windows with Croatian system locale if I
do:
set LANG=en
and then call gimp-2.6.exe, it starts with English GUI.

Maybe zenmap can learn this from GIMP.

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

Re: [patch] nmap-services update for port 2000 and sieve

2009-12-16T22:33:07Z

On Wed, Dec 16, 2009 at 07:52:50PM -0400, Matt Selsky wrote:
> Port 2000 should be cisco-sccp. sieve has now been assigned port 4190/tcp by IANA.

Thanks Matt, applied.

Cheers,
-F
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

[patch] nmap-services update for port 2000 and sieve

2009-12-16T15:52:50Z

Port 2000 should be cisco-sccp. sieve has now been assigned port 4190/tcp by IANA.

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

sieve-port2000.patch (977 bytes) Download Attachment

Re: cppcheck on nmap

2009-12-16T15:06:37Z

Hi,

I am one of the Cppcheck developers and I noticed this on your mailing list:

> here is a scan of cppcheck over Nmap 5.10BETA1:
>
> [.\osscan2.cc:2942]: (error) Dangerous usage of erase
> [.\output.cc:354]: (error) Dangerous usage of erase
> [.\scan_engine.cc:1802]: (error) Dangerous usage of erase
> [.\scan_engine.cc:1849]: (error) Dangerous usage of erase
> [.\traceroute.cc:1253]: (error) Dangerous usage of erase

I'm posting this to inform you that all of these are false positives
(Cppcheck assumed that vector was used, when list was used instead). I
created a ticket about it for us:
http://sourceforge.net/apps/trac/cppcheck/ticket/1107

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

Re: A Simple Question - Zenmap

2009-12-16T02:05:20Z

On Wed, Dec 16, 2009 at 02:33:41PM +0800, Mike E-Wire Mail wrote:
> I have an irritating but [I am sure] simple question to ask re Zenmap
> and was wondering if someone could help please ?
> On the main interface screen the box labeled 'Target' contains a list of
> the IP addresses and [in some cases host names] of scan targets that
> have taken place - in most cases I have NOT saved the results from these
> scans.
> I am trying to clear out this list but cannot find the file where the IP
> addresses/host names have been stored.
> Can anyone help please ?

It's in target_list.txt, which is in a directory that depends on your
operating system. If you delete it Zenmap will create a new blank one.
See http://nmap.org/book/zenmap-files.html#zenmap-user-conf.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

A Simple Question - Zenmap

2009-12-15T22:33:41Z

I have an irritating but [I am sure] simple question to ask re Zenmap
and was wondering if someone could help please ?
On the main interface screen the box labeled 'Target' contains a list of
the IP addresses and [in some cases host names] of scan targets that
have taken place - in most cases I have NOT saved the results from these
scans.
I am trying to clear out this list but cannot find the file where the IP
addresses/host names have been stored.
Can anyone help please ?
Thanks.

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

Re: Kerberos probes for nmap

2009-12-15T17:38:30Z

Here's a modified version of the packet where I have removed the things you mentioned.
I have not touched the algorithms, because I'm uncertain which ones to leave.
Removing some of them could reduce the footprint size by some 10 bytes or so.

I ran the new probe against my Heimdal which got me:

SF-Port88-UDP:V=5.10BETA1%I=7%D=12/16%Time=4B283757%P=i386-apple-darwin10.2.0%r(Kerberos,69,"~g0e\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e\xa4\x11\x18
SF:\x0f20091216012641Z\xa5\x05\x02\x03\x0e/\xc3\xa6\x03\x02\x01<\xa9\x15\x
SF:1b\x13<unspecified\x20realm>\xaa\x0b0\t\xa0\x03\x02\x01\0\xa1\x020\0\xa
SF:b\x16\x1b\x14No\x20server\x20in\x20request");

I also tested it against a Windows server and it worked well, even returned the name of the realm.
Unfortunately I don't have access to a OS X kerberos server or to MIT Kerberos for additional testing.

Let me know how it works out.
//P

On 16 dec 2009, at 00.39, David Fifield wrote:

> On Sat, Nov 28, 2009 at 09:20:53PM +0100, Patrik Karlsson wrote:
>> I noticed that Kerberos get's detected fine when running against
>> Windows but my Heimdal hosts are not detected. Running over TCP the
>> RPCCheck probe seems to trigger an answer. Here's the signature:
>>
>> SF-Port88-TCP:V=5.10BETA1%I=7%D=11/28%Time=4B1181BB%P=i386-apple-darwin10.2.0%r(RPCCheck,55,"\0\0\0Q~O0M\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e\xa4\
>> SF:x11\x18\x0f20091128200203Z\xa5\x05\x02\x03\x08i@\xa6\x03\x02\x01=\xa9\x
>> SF:15\x1b\x13<unspecified\x20realm>\xaa\x0b0\t\xa0\x03\x02\x01\0\xa1\x020\
>> SF:0");
>>
>> I have put together a probe that works both against 88/tcp and 88/udp.
>> The probe is a request for a TGT for the user NM in realm NM. Again,
>> my matches might need some improvement. Attaching signatures for
>> reference.
>>
>> SF-Port88-TCP:V=5.10BETA1%I=7%D=11/28%Time=4B1184BD%P=i386-apple-darwin10.2.0%r(kerberos,67,"\0\0\0c~a0_\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e\xa4\
>> SF:x11\x18\x0f20091128201453Z\xa5\x05\x02\x03\x0c\xd3O\xa6\x03\x02\x01\x06
>> SF:\xa7\x04\x1b\x02NM\xa8\x0f0\r\xa0\x03\x02\x01\x01\xa1\x060\x04\x1b\x02N
>> SF:M\xa9\x04\x1b\x02NM\xaa\x170\x15\xa0\x03\x02\x01\0\xa1\x0e0\x0c\x1b\x06
>> SF:krbtgt\x1b\x02NM")%r(RPCCheck,55,"\0\0\0Q~O0M\xa0\x03\x02\x01\x05\xa1\x
>> SF:03\x02\x01\x1e\xa4\x11\x18\x0f20091128201459Z\xa5\x05\x02\x03\x03\x80\x
>> SF:ae\xa6\x03\x02\x01=\xa9\x15\x1b\x13<unspecified\x20realm>\xaa\x0b0\t\xa
>> SF:0\x03\x02\x01\0\xa1\x020\0");
>>
>> SF-Port88-UDP:V=5.10BETA1%I=7%D=11/28%Time=4B118543%P=i386-apple-darwin10.2.0%r(kerberos,63,"~a0_\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e\xa4\x11\x18
>> SF:\x0f20091128201702Z\xa5\x05\x02\x03\n\xf9m\xa6\x03\x02\x01\x06\xa7\x04\
>> SF:x1b\x02NM\xa8\x0f0\r\xa0\x03\x02\x01\x01\xa1\x060\x04\x1b\x02NM\xa9\x04
>> SF:\x1b\x02NM\xaa\x170\x15\xa0\x03\x02\x01\0\xa1\x0e0\x0c\x1b\x06krbtgt\x1
>> SF:b\x02NM");
>
> Sorry, I didn't understand before that there was no probe getting a
> response from UDP. I tried the UDP probe and it worked against UDP
> Kerberos on Mac OS X, the TCP counterpart of which is detected as "Mac
> OS X kerberos-sec" by the RPCCheck probe. The response I get back is
> this:
>
> SF-Port88-UDP:V=5.10BETA1%I=2%D=12/15%Time=4B2816A5%P=i686-pc-linux-gnu%r(
> SF:kerberos,8D,"~\x81\x8a0\x81\x87\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e
> SF:\xa2\x11\x18\x0f19780623234544Z\xa4\x11\x18\x0f20091215230646Z\xa5\x05\
> SF:x02\x03\x0e8\xfc\xa6\x03\x02\x01\x06\xa7\x04\x1b\x02NM\xa8\x0f0\r\xa0\x
> SF:03\x02\x01\x01\xa1\x060\x04\x1b\x02NM\xa9\x04\x1b\x02NM\xaa\x170\x15\xa
> SF:0\x03\x02\x01\0\xa1\x0e0\x0c\x1b\x06krbtgt\x1b\x02NM\xab\x13\x1b\x11CLI
> SF:ENT_NOT_FOUND\0");
>
> It's rather different than your Heimdal response, so we have an
> opportunity for discrimination here. I think this could make a good UDP
> payload too.
>
> I want you to see if you can refine the probe. Here's the Wireshark
> dissection of it:
>
> User Datagram Protocol, Src Port: 57945 (57945), Dst Port: kerberos (88)
> Kerberos AS-REQ
> Pvno: 5
> MSG Type: AS-REQ (10)
> KDC_REQ_BODY
> Padding: 0
> KDCOptions: 50800010 (Forwardable, Proxyable, Renewable, Renewable OK)
> Client Name (Principal): NM
> Realm: NM
> Server Name (Unknown): krbtgt/NM
> from: 2009-10-12 11:35:05 (UTC)
> till: 2009-10-12 21:35:05 (UTC)
> Nonce: 267493544
> Encryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 rc4-hmac des-cbc-crc des-cbc-md5 des-cbc-md4
>
> It looks like this came from the packet capture of some tool. Maybe
> there are parts of it that can be omitted to make the packet shorter and
> less specific. I'm looking at section 5.4.1 of RFC 4120 where it says
> that "Server Name" and "from" are optional. You can probably reduce the
> number of encryption types offered; you probably want to keep strong,
> commonly implemented ones because sometimes servers will ignore requests
> for weak ciphers (in other protocols--I don't know about Kerberos). Try
> omitting the "Client Name" too. I don't think that would work for
> authentication purposes but we're only looking for a response, and it
> reduces the chance that we'll hit a real "NM" user name.
>
> I can imagine that having the "till" time in the past might be a problem
> for some servers. The RFC says: "It is not optional, but if the
> requested endtime is '19700101000000Z', the requested ticket is to have
> the maximum endtime permitted according to KDC policy." That is worth a
> try.
>
> The Kerberos protocol looks pretty specific, so there's probably not
> much chance another general-purpose probe will work. I just tried
> --version-all and didn't get any responses. So adding a refined
> Kerberos-specific probe is fine by me. Please test my suggestions above
> and write back with your results. If you want help with packet crafting
> then you can ask here too.
>
> David Fifield

kerberos-probe.patch (1K) Download Attachment

Re: Kerberos probes for nmap

2009-12-15T15:39:55Z

On Sat, Nov 28, 2009 at 09:20:53PM +0100, Patrik Karlsson wrote:

> I noticed that Kerberos get's detected fine when running against
> Windows but my Heimdal hosts are not detected. Running over TCP the
> RPCCheck probe seems to trigger an answer. Here's the signature:
>
> SF-Port88-TCP:V=5.10BETA1%I=7%D=11/28%Time=4B1181BB%P=i386-apple-darwin10.2.0%r(RPCCheck,55,"\0\0\0Q~O0M\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e\xa4\
> SF:x11\x18\x0f20091128200203Z\xa5\x05\x02\x03\x08i@\xa6\x03\x02\x01=\xa9\x
> SF:15\x1b\x13<unspecified\x20realm>\xaa\x0b0\t\xa0\x03\x02\x01\0\xa1\x020\
> SF:0");
>
> I have put together a probe that works both against 88/tcp and 88/udp.
> The probe is a request for a TGT for the user NM in realm NM. Again,
> my matches might need some improvement. Attaching signatures for
> reference.
>
> SF-Port88-TCP:V=5.10BETA1%I=7%D=11/28%Time=4B1184BD%P=i386-apple-darwin10.2.0%r(kerberos,67,"\0\0\0c~a0_\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e\xa4\
> SF:x11\x18\x0f20091128201453Z\xa5\x05\x02\x03\x0c\xd3O\xa6\x03\x02\x01\x06
> SF:\xa7\x04\x1b\x02NM\xa8\x0f0\r\xa0\x03\x02\x01\x01\xa1\x060\x04\x1b\x02N
> SF:M\xa9\x04\x1b\x02NM\xaa\x170\x15\xa0\x03\x02\x01\0\xa1\x0e0\x0c\x1b\x06
> SF:krbtgt\x1b\x02NM")%r(RPCCheck,55,"\0\0\0Q~O0M\xa0\x03\x02\x01\x05\xa1\x
> SF:03\x02\x01\x1e\xa4\x11\x18\x0f20091128201459Z\xa5\x05\x02\x03\x03\x80\x
> SF:ae\xa6\x03\x02\x01=\xa9\x15\x1b\x13<unspecified\x20realm>\xaa\x0b0\t\xa
> SF:0\x03\x02\x01\0\xa1\x020\0");
>
> SF-Port88-UDP:V=5.10BETA1%I=7%D=11/28%Time=4B118543%P=i386-apple-darwin10.2.0%r(kerberos,63,"~a0_\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e\xa4\x11\x18
> SF:\x0f20091128201702Z\xa5\x05\x02\x03\n\xf9m\xa6\x03\x02\x01\x06\xa7\x04\
> SF:x1b\x02NM\xa8\x0f0\r\xa0\x03\x02\x01\x01\xa1\x060\x04\x1b\x02NM\xa9\x04
> SF:\x1b\x02NM\xaa\x170\x15\xa0\x03\x02\x01\0\xa1\x0e0\x0c\x1b\x06krbtgt\x1
> SF:b\x02NM");

Sorry, I didn't understand before that there was no probe getting a
response from UDP. I tried the UDP probe and it worked against UDP
Kerberos on Mac OS X, the TCP counterpart of which is detected as "Mac
OS X kerberos-sec" by the RPCCheck probe. The response I get back is
this:

SF-Port88-UDP:V=5.10BETA1%I=2%D=12/15%Time=4B2816A5%P=i686-pc-linux-gnu%r(
SF:kerberos,8D,"~\x81\x8a0\x81\x87\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e
SF:\xa2\x11\x18\x0f19780623234544Z\xa4\x11\x18\x0f20091215230646Z\xa5\x05\
SF:x02\x03\x0e8\xfc\xa6\x03\x02\x01\x06\xa7\x04\x1b\x02NM\xa8\x0f0\r\xa0\x
SF:03\x02\x01\x01\xa1\x060\x04\x1b\x02NM\xa9\x04\x1b\x02NM\xaa\x170\x15\xa
SF:0\x03\x02\x01\0\xa1\x0e0\x0c\x1b\x06krbtgt\x1b\x02NM\xab\x13\x1b\x11CLI
SF:ENT_NOT_FOUND\0");

It's rather different than your Heimdal response, so we have an
opportunity for discrimination here. I think this could make a good UDP
payload too.

I want you to see if you can refine the probe. Here's the Wireshark
dissection of it:

User Datagram Protocol, Src Port: 57945 (57945), Dst Port: kerberos (88)
Kerberos AS-REQ
Pvno: 5
MSG Type: AS-REQ (10)
KDC_REQ_BODY
Padding: 0
KDCOptions: 50800010 (Forwardable, Proxyable, Renewable, Renewable OK)
Client Name (Principal): NM
Realm: NM
Server Name (Unknown): krbtgt/NM
from: 2009-10-12 11:35:05 (UTC)
till: 2009-10-12 21:35:05 (UTC)
Nonce: 267493544
Encryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 rc4-hmac des-cbc-crc des-cbc-md5 des-cbc-md4

It looks like this came from the packet capture of some tool. Maybe
there are parts of it that can be omitted to make the packet shorter and
less specific. I'm looking at section 5.4.1 of RFC 4120 where it says
that "Server Name" and "from" are optional. You can probably reduce the
number of encryption types offered; you probably want to keep strong,
commonly implemented ones because sometimes servers will ignore requests
for weak ciphers (in other protocols--I don't know about Kerberos). Try
omitting the "Client Name" too. I don't think that would work for
authentication purposes but we're only looking for a response, and it
reduces the chance that we'll hit a real "NM" user name.

I can imagine that having the "till" time in the past might be a problem
for some servers. The RFC says: "It is not optional, but if the
requested endtime is '19700101000000Z', the requested ticket is to have
the maximum endtime permitted according to KDC policy." That is worth a
try.

The Kerberos protocol looks pretty specific, so there's probably not
much chance another general-purpose probe will work. I just tried
--version-all and didn't get any responses. So adding a refined
Kerberos-specific probe is fine by me. Please test my suggestions above
and write back with your results. If you want help with packet crafting
then you can ask here too.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

license for Oracle default SIDs

2009-12-15T14:07:31Z

Hello Nmap team,

Patrik Karlson asked me to forward this to nmap dev mailing list.

Hereby I (Alexander Kornbrust) grant the Nmap project explicitly the rights to distribute the list of Oracle Default SIDs under the Nmap license (http://nmap.org/svn/COPYING).

The attached file is an updated version of http://www.red-database-security.com/scripts/sid.txt

Hope this is sufficient.

Regards

Alexander

_____________________________
Red Database Security GmbH
Alexander Kornbrust
Bliesstrasse 16
D-66538 Neunkirchen
Germany

Office: +49 (0) 6821 - 951 76 37
Mobil: +49 (0) 151 - 2411 0359
Fax: +49 (0) 6821 - 912 73 54
Mail: ak at red-database-security.com
Web: www.red-database-security.com

Zuständiges Amtsgericht:
Amtsgericht Saarbrücken, HRB14503

Geschäftsführer:
Alexander Kornbrust

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

Re: zenmap: problems with GUI language

2009-12-15T03:16:30Z

As i know. In windows not have application whitch uses LANG variable.
gtk application uses self variables for this.
last nmap installing on my russian windows 7 perfect, and have Russian
interface.
Although for 5.00 i was must set LANG variable for my language.
Best regards,
Khodyrev "SpxnezzaR" Alexander

2009/12/14 David Fifield <david@...>

> On Mon, Dec 07, 2009 at 12:46:35PM +0100, Robert Premuž wrote:
> > As I use Croatian regional settings in Windows, the zenmap GUI is in
> > Croatian. Unfortunately, I haven't been able to change that by
> > following the procedures on http://nmap.org/book/zenmap-lang.html
> >
> > I tried to run the following commands in the Windows command shell
> > (cmd.exe):
> >
> > set LANG=en_US
> > zenmap
> >
> > but zenmap started with GUI in Croatian language.
> > Just in case I tried to set LANG using the Control Panel but the
> > effect was the same.
> >
> > As a last resort I renamed
> > "C:\Program Files\Nmap\share\zenmap\locale\hr" so that zenmap couldn't
> > find the Croatian language file and this way I got GUI in English.
> >
> > So, is there something broken in zenmap for Windows regarding these
> > issues? Am I doing something the wrong way?
>
> Zenmap gets the locale by calling the locale.getdefaultlocale function.
>
> http://docs.python.org/library/locale.html#locale.getdefaultlocale
>
> On Windows, this first tries to get the locale by calling the
> GetLocaleInfo function.
>
> http://msdn.microsoft.com/en-us/library/dd318101(VS.85).aspx
>
> If that fails, then it examines environment variables such as LANG.
> Maybe there's a Windows way to accomplish this without LANG? Is there a
> way to run just one application in a different locale? Does anybody have
> a non-English system locale, but run certain applications in English,
> for example?
>
> David Fifield
> _______________________________________________
> 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/

Re: POC Payloader dat

2009-12-14T16:38:38Z

On Sun, Dec 13, 2009 at 5:32 PM, David Fifield <david@...> wrote:

> That looks pretty good, but if we're not going to be 100% compatible
> with Unicornscan's file, then there's no need for ours to look like
> theirs. The braces and semicolon can be removed. I'm thinking about a
> format more like we have in nmap-service-probes, with named fields
> instead of positional values.
>
> /* comment */
> payload udp 1604,1645,1812
> "\x1e\x00\x01\x30\x02\xfd\xa8\xe3\x00\x00\x00\x00\x00\x00\x00\x00"
> "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
> source 100
>
> The "source 100" above is just an example of how a source port might be
> specified, even though it's not used for this particular payload. I
> would rather have payloads that use a source port say so explicitly than
> have most of them with a dummy -1 value.
>
> I don't think we need a label for each payload beyond the comments.

That certainly looks a great deal easier and is more consistent with
what other nmap code does.

> I want the interface for accessing a payload to stay pretty much the
> same. This is what we have now:
>
> const char *get_udp_payload(u16 dport, size_t *length);

*ditto* - less system shock too :-)

> I can imagine changing the return value to non-const for the case of
> dynamic payloads, or perhaps requiring a caller-supplied buffer.
>
> Parsing is certainly a non-trivial part of this problem. There are
> custom parsers for all of Nmap's data files. The main thing is to watch
> out for buffer overflows and such.

The services probe has some good bits in it I think.

Thanks for the pointers!
j
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/