Re: [NSE] TN3270 version script

[Phil <mainframed767 () gmail com>]

Hi Daniel,

Thanks for the help and support!

1) do you have any feedback on the product name, which is currently "IBM OS/390 or SNA telnetd” ?

The IBM OS/390 patch went in years ago (i think 2003) when the IBM operating system os/390 was around. Now they’ve 
replaced it with z/OS (and others like z/VM). SNA Telnetd: I have no idea where this came from. It’s not a telnetd as 
we’d understand it nor is it running over SNA if you used a TCPIP network scanner to identify it :D

Anyway, this is a lot of words to say : Might be better to just call it ‘IBM Telnet 3270’

Someone can correct me but as far as I know IBM z/OS and z/VM, ESA, DOS, etc are the only ones using TN3270 today.

2)  is there some text like a banner that the server sends?

Not really. I have a script which can do this:

▶ nmap --script tn3270-info,tn3270-screen -p 23 -sV 12.12.12.12

Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-08-30 14:14 PDT
Nmap scan report for 12.12.12.12
Host is up (0.092s latency).
PORT   STATE SERVICE VERSION
23/tcp open  tn3270  Telnet TN3270
| tn3270-screen:
| MLUSS2
|
|
|
| MMM   MMM                                 lll
| MMMM MMMM   aaaaa      ii                  ll        ii
| MM MMM MM       aa     ii                  ll        ii                eeeeee
| MM  M  MM       aa            nn nnnn      ll               nn nnnn   ee    ee
| MM     MM  aaaaaaa    iii     nnn   nn     ll       iii     nnn   nn  eeeeeeee
| MM     MM aa    aa     ii     nn    nn     ll        ii     nn    nn  ee
| MM     MM aa    aa     ii     nn    nn     ll        ii     nn    nn  ee
| MM     MM aa    aa     ii     nn    nn     ll        ii     nn    nn  ee     e
| MM     MM  aaaaaa     iiii    nn    nn   llllll     iiii    nn    nn   eeeeee
|
|       Mainline Premier Services
|
|                                    z/OS 1.10
|
|
|
|
| IPADDR: 13.13.13.13
|
|_ ==>

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 4.19 seconds

So it’s kinda like a banner but there’s no standardization here or anything thats easy to consistently grab. Note that 
the above is using a new library for nmap called tn3270.lua which i’ve released but it needs some work / cleanup before 
I feel comfortable submitting.

3) then just use comm.tryssl to do your connection

I’ve done this with my current script and it works really well. I’m also changing the library to do this as well. 
Thanks for the suggestion!

4) The portrule should definitely be: shortport.version_port_or_service({23, 992}, {"telnet", "telnets", "tn3270”})

Yup, I’ve changed it. The reason I think some matched IIS SSL was the beginning of the packets look the same (ff:fd:28)

5) far easier than getting a new script to work in older Nmap versions

Yes, this is a problem my friend was having. None of my scripts worked with his older version of nmap because stdnse 
(debug, verbose) had some changes and there were changes to brute/creds (which I used in my CICS/TSO/VTAM enumeration 
scripts).

6) Let us know if there's anything else we can do to help

If you’re changing the portrule then the script doesn’t really need to exist except for the situation where you get 
‘IAC DO TTYPE’ and you want to test if it’s a mainframe or not (by sending a 3270 terminal type). This would 
technically be like advanced versioning so would I still include it as a ‘version’ script or something else?

If the portrule changes then I could do OS version detection, is that something that could be done with a script or is 
it changes to nmap os detection itself? (its the way z/OS and z/VM do the telnet handshake that gives them away. In my 
testing both send 'IAC DO TN3270E' on first connection but if you reply with 'IAC DO TN3270E’ z/VM will immediately 
reply with ‘IAC DONT TN3270’.)

> On Aug 29, 2015, at 8:02 PM, Daniel Miller <bonsaiviking () gmail com> wrote:
>
> Phil,
>
> Ok, this is making good sense to me now. We'll distinguish tn3270 as a separate service name. I'll change the one 
> current match to tn3270 from telnet; do you have any feedback on the product name, which is currently "IBM OS/390 or 
> SNA telnetd" ? I'd guess this could be corrected to something either more accurate or more general.
>
> After the initial terminal type negotiation, is there some text like a banner that the server sends? It would be nice 
> to be able to retrieve more than just the service name in that case.
>
> For SSL (probably telnets on port 992), the best way to handle this is to let version detection spot the SSL tunnel, 
> then just use comm.tryssl to do your connection. It leverages the version detection results (if -sV says it's SSL, 
> use that) and port number (992 is probably SSL, 23 is probably plaintext) to determine when to try SSL with a 
> fallback to plaintext if that fails. In other words, don't worry about detecting and reporting SSL tunnel in this 
> script.
>
> The portrule should definitely be: shortport.version_port_or_service({23, 992}, {"telnet", "telnets", "tn3270"}). 
> Don't worry about supporting older service databases; that's one of the easiest things to manually update, far easier 
> than getting a new script to work in older Nmap versions.
>
> Let us know if there's anything else we can do to help.
>
> Dan
>
> On Fri, Aug 28, 2015 at 3:57 PM, Phil <mainframed767 () gmail com <mailto:mainframed767 () gmail com>> wrote:
> Hi Daniel,
>
> let me try and answer your questions:
>
> 1)  in this case we label it telnet, since it's using the Telnet option negotiation mechanism
>
> Yes, this is correct, TN3270 is built on top of telnet but isn’t like telnet
>
> 2) Do these scripts make sense running against tn3270?
>
> No they don’t. Those scripts won’t work at all (I’ve tested) because TN3270 has further handshake negotiations and is 
> a different protocol.
>
> 3) should TN3270 be really treated like a different service altogether?
>
> It really should be treated as a different service, it’s only related to telnet in the very beginning of protocol 
> handshake.
>
> 4) Is this always the case, or should the script attempt to negotiate TN3270 with any telnetd that asks for Terminal 
> Type, even among other options?
>
> Pretty much in all my testing of test mainframes and some internet available one this is the case. But basically, if 
> it says ‘send ttype’ and you send 'IBM-3279-4-E’ the next reply will be another ‘IAC DO’ for further option 
> negotiation, other wise it will ask for other terminal types (IAC SB).
>
> 5 ) Once we answer these questions, we can move into more implementation-related issues like what portrule would be 
> best (my guess would be some invocation of shortport.version_port_or_service [1]), using comm.tryssl [2] instead of 
> tn_open, and how to best report the script's findings.
>
> Great, I certainly struggled with making a portrule robust enough to detect tn3270 appropriately. The reason I used 
> ‘unknown’ was in previous version of NMAP the version detection would list things like ‘IIS’ and ‘unknown’ and ‘Gnu 
> Telnetd’ as the services detected so I was casting a wide net. And the SSL components were based on older scripts, I 
> had never seen tryssl.
>
>
> > On Aug 28, 2015, at 1:04 PM, Daniel Miller <bonsaiviking () gmail com <mailto:bonsaiviking () gmail com>> wrote:
> >
> > Phil,
> >
> > I'm excited to see better mainframe support in NSE! I think we should carefully consider how this script and others 
> > may interact so that we build a good picture of the target and allow scripts to properly inform each other.
> >
> > A quick check through nmap-service-probes shows that we have at least one probe match for the same TN3270 service:
> >
> > Probe TCP NULL q||
> > match telnet m|^\xff\xfd\($| p|IBM OS/390 or SNA telnetd|
> >
> > So in this case we label it telnet, since it's using the Telnet option negotiation mechanism. This is used as a 
> > signal to other scripts like telnet-brute and telnet-encryption that the port in question should be probed further. 
> > Do these scripts make sense running against tn3270? Or should TN3270 be really treated like a different service 
> > altogether?
> >
> > Your script also looks for a response of "\xff\xfd\x18", the Terminal Type option. This option is obviously used by 
> > more telnet daemons than just TN3270-capable ones, but yours specifically will only match those that send no other 
> > options. Is this always the case, or should the script attempt to negotiate TN3270 with any telnetd that asks for 
> > Terminal Type, even among other options?
> >
> > Once we answer these questions, we can move into more implementation-related issues like what portrule would be best 
> > (my guess would be some invocation of shortport.version_port_or_service [1]), using comm.tryssl [2] instead of 
> > tn_open, and how to best report the script's findings.
> >
> > Thanks again for sharing your work with us!
> >
> > Dan
> >
> > [1] https://nmap.org/nsedoc/lib/shortport.html#version_port_or_service 
> > <https://nmap.org/nsedoc/lib/shortport.html#version_port_or_service>
> > [2] https://nmap.org/nsedoc/lib/comm.html#tryssl <https://nmap.org/nsedoc/lib/comm.html#tryssl>
> >
> > On Wed, Aug 26, 2015 at 1:30 PM, Phil <mainframed767 () gmail com <mailto:mainframed767 () gmail com>> wrote:
> > Hi,
> >
> > This script enhances the version detection for mainframes (or others, but mostly mainframes) running TN3270 and 
> > appropriately identifies ports which support TN3270 (either through IAC DO TN3270E or through the more common IAC 
> > SEND TTYPE).
> >
> >
> > Output:
> > PORT    STATE SERVICE    VERSION
> > 23/tcp  open  tn3270     Telnet TN3270
> > 992/tcp open  ssl/tn3270 Telnet TN3270 w/SSL
> >
> > This is my first NSE script submission so let me know if there’s anything I’ve missed or need to change.
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Sent through the dev mailing list
> > https://nmap.org/mailman/listinfo/dev <https://nmap.org/mailman/listinfo/dev>
> > Archived at http://seclists.org/nmap-dev/ <http://seclists.org/nmap-dev/>

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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