Re: [NSE] Script to enhance mainframe TN3270 detection

[Daniel Miller <bonsaiviking () gmail com>]

Phil,

Thanks for catching that. I don't know if I had the wrong idea about the SE
directive (that it needed an argument like SB) or whether I just typed it
wrong, but I made the fix in r35395.

Dan

On Sat, Nov 7, 2015 at 5:55 PM, Phil <mainframed767 () gmail com> wrote:

> This is so awesome and I really appreciate all your help. We’re so close.
>
> Tested iagainst a bunch of systems and nmap was having problems with IAC
> DO TTYPE mainframes (mostly z/VM for those wondering).
>
> This line:
> # IAC DO TERMINAL TYPE, IAC SB TERMINAL TYPE SEND SE, .*, IAC DO EOR
> match tn3270 m|^\xff\xfd\x18\xff\xfa\x18\x01\xff\xf0\x18.*\xff\xfd\x19|
> p/IBM Telnet TN3270/ i/traditional tn3270/
> ------------------------------------------------------^
> has an extra char in it right here (the tenth char, the \x18 after IAC SB
> TYPE SEND SE (FF FA 18 01 FF F0) if my ascii art didn’t work)
>
> Removing that one typo fixed it!
> # IAC DO TERMINAL TYPE, IAC SB TERMINAL TYPE SEND SE, .*, IAC DO EOR
> match tn3270 m|^\xff\xfd\x18\xff\xfa\x18\x01\xff\xf0.*\xff\xfd\x19| p/IBM
> Telnet TN3270/ i/traditional tn3270/
>
> If you can make that final change NMAP will be able to detect most types
> of mainframes! Awesome!
>
> On Nov 7, 2015, at 12:50 PM, Daniel Miller <bonsaiviking () gmail com> wrote:
>
> Phil,
>
> Ok, I think I was just rushing this and made some dumb mistakes converting
> decimal to hex and missing the 3 main negotiation types. r35393 should fix
> this by:
>
> 1. Matching TN3270E (RFC 1647) and TN3270-REGIME (RFC 1041) separately
> under the NULL probe and indicating which was matched in the extrainfo
> template.
>
> 2. Adding the "traditional tn3270" probe you suggested and matching
> explicitly the DO TTYPE, SB TTYPE SEND SE, DO EOR response sequence.
>
> 3. Made IAC DO TTYPE a softmatch for telnet instead of a hard match for
> Cisco switch telnetd (in r35394).
>
> Please let me know if any of this does not work. Include the
> --version-trace option so that you can report which probes were sent and
> which line number matched.
>
> Dan
>
> On Tue, Nov 3, 2015 at 1:40 PM, Main Framed <mainframed767 () gmail com>
> wrote:
>
> > > > That's an exact string match, so nothing but IAC DO TTYPE immediately
> > upon connecting.
> >
> > Yes. Can it be changed to softmatch?
> >
> > > > But in order to match the tn3270 service with your dummy probes file,
> > it would have to send IAC DO TN3270E (0x24) or a response including IAC DO
> > Telnet 3270 regime (0x19)
> >
> > Looks like I wrote it wrong. But basically, if a server sends IAC DO
> > TN3270E we're done, it's tn3270. 3270-REGIME is actually 0x29 (as per:
> > https://tools.ietf.org/html/rfc1041) not 0x19. See below for what I
> > tried to make the probe do.
> >
> > > > I'm expanding the existing tn3270 match line to include any telnet
> > banner including IAC DO for either of those 3270 types,
> >
> > Just to make sure it will match IAC DO TN3270 and IAC DO 3270-REGIME (
> > \xff\xfd\( and \xff\xfd\( )
> >
> > > > but I'd need to know that the tn3270 Probe is successful in getting a
> > response from services which do *not* include that in their banner before I
> > can add that probe and match. So does the probe work in those cases
> > (which previously only responded positively to your script)?
> >
> > I don't think I understand the question.
> >
> > Here's what the handshake looks like
> >
> >    TN3270 Telnet server              Client
> >    --------------------------        -------------------------
> >    IAC DO TERMINAL-TYPE        -->
> >                                <--   IAC WILL TERMINAL-TYPE
> >    IAC SB TERMINAL-TYPE SEND
> >    IAC SE                      -->
> >                                      IAC SB TERMINAL-TYPE IS
> >                                <--   IBM-3270-4-E IAC SE
> >    IAC DO EOR                  -->
> >
> >
> > 0x19 is EOR (End of record) not a specific Telnet 3270 Regime, my
> > apologies if that wasn't clear. If the terminal type isn't supported the
> > servers replies with "IAC SB TERMINAL-TYPE SEND IAC SE" until a valid
> > terminal type is sent. Once it is the server will send IAC DO <something
> > else, most likely EOR>.
> >
> > The probe i wrote sends both IAC WILL TTYPE and IAC SB TERMINAL-TYPE IS
> > IBM-3279-4-E IAC SE together instead of waiting for replies and checks the
> > response for FF:FD:19.
> >
> >    TN3270 Telnet server              Client
> >    --------------------------        -------------------------
> >    IAC DO TERMINAL-TYPE        -->
> >                                      IAC WILL TERMINAL-TYPE
> >
> >                                      IAC SB TERMINAL-TYPE IS
> >                                <--   IBM-5555-C01 IAC SE
> >
> > IAC SB TERMINAL-TYPE SEND IAC SE --> IAC DO EOR -->
> >
> >
> > So here's a DIFF of changes to the current nmap-service-probes (just
> > pulled it down right now). This works against both a mainframe and a cisco
> > router to make sure it still reported the correct entry.
> >
> > Index: nmap-service-probes
> > ===================================================================
> > --- nmap-service-probes (revision 35376)
> > +++ nmap-service-probes (working copy)
> > @@ -3626,7 +3626,7 @@
> >  match telnet
> > m|^\xff\xfb\x01\xff\xfb\x03\xff\xfd\x18\xff\xfd\x1f\r\n\r\nPassword
> > required, but none set\r\n| p/Cisco router telnetd/ i/password required but
> > not set/ d/router/ cpe:/a:cisco:telnet/
> >  match telnet m|^Access not permitted\. Closing connection\.\.\.\n$|s
> > p/Cisco Catalyst switch telnetd/ i/access denied/ d/switch/
> > cpe:/a:cisco:telnet/
> >  # The match below matches Cisco microswitch devices and also Edge-core
> > ES3526XA
> > -match telnet m|^\xff\xfd\x18$| p/Cisco or Edge-core switch telnetd/
> > d/switch/
> > +softmatch telnet m|^\xff\xfd\x18$| p/Cisco or Edge-core switch telnetd/
> > d/switch/
> >  # OpenBSD 2.3
> >  # FreeBSD 5.1
> >  match telnet m|^\xff\xfd%$| p/BSD-derived telnetd/
> > @@ -14258,7 +14258,6 @@
> >  # https://github.com/tvdw/gotor
> >  #
> > https://lists.torproject.org/pipermail/tor-dev/2015-January/008135.html
> >  match tor-orport m|^\x00\x00\x07\x00\x02\x00\x04| p/GoTor/ i/supported
> > protocol versions: 4/
> > -
> >  ##############################NEXT PROBE##############################
> >  # TLS with Pre-Shared Key handshake, generated by NSE's tls.lua
> >  # SSL services that only support PSK will not respond to other probes.
> > @@ -14290,3 +14289,14 @@
> >  # If the port supports NJE it will respond with either a 'NAK' or 'ACK'
> > in EBCDIC
> >  match nje m|^\xd5\xc1\xd2| p/IBM Network Job Entry (JES)/
> >  match nje m|^\xc1\xc3\xd2| p/IBM Network Job Entry (JES)/
> > +#############################NEXT PROBE##############################
> >
> > +# Detects TN3270 Servers which send IAC DO TTYPE on initial connection
> > +# instead of IAC DO TN3270E
> > +Probe TCP tn3270 q|\xff\xfb\x18\xff\xfa\x18\x00IBM-3279-4-E\xff\xf0|
> > +totalwaitms 500
> > +rarity 8
> > +#Despite the standard ports being 992/23 these are the likely ports as
> > +#describe in various documentation
> > +ports 23,2323,2023,623
> > +sslports 992,23,2323,2023,623
> > +match tn3270 m|\xff\xfd\x19| p/IBM Telnet TN3270/ d/mainframe/
> >
> >
> >
> > On Mon, Nov 2, 2015 at 4:50 PM, Daniel Miller <bonsaiviking () gmail com>
> > wrote:
> >
> > > Phil,
> > >
> > > I'm confused because these match lines seem mutually exclusive. Here's
> > > the match line you say matches with the current version:
> > >
> > > match telnet m|^\xff\xfd\x18$| p/Cisco or Edge-core switch telnetd/
> > > d/switch/
> > >
> > > That's an exact string match, so nothing but IAC DO TTYPE immediately
> > > upon connecting. But in order to match the tn3270 service with your dummy
> > > probes file, it would have to send IAC DO TN3270E (0x24) or a response
> > > including IAC DO Telnet 3270 regime (0x19). I'm expanding the existing
> > > tn3270 match line to include any telnet banner including IAC DO for either
> > > of those 3270 types, but I'd need to know that the tn3270 Probe is
> > > successful in getting a response from services which do *not* include that
> > > in their banner before I can add that probe and match.
> > >
> > > So does the probe work in those cases (which previously only responded
> > > positively to your script)?
> > >
> > > Dan
> > >
> > > On Mon, Nov 2, 2015 at 2:17 PM, Main Framed <mainframed767 () gmail com>
> > > wrote:
> > >
> > > > Hi Daniel,
> > > >
> > > > So glad to hear back! You can call me Phil.
> > > >
> > > > This is a great idea and I wish I had thought of it earlier!
> > > >
> > > > This is what I put in a dummy nmap-service-probes:
> > > >
> > > > Probe TCP NULL q||
> > > >
> > > > totalwaitms 1000
> > > >
> > > > match tn3270 m|^\xff\xfd\($| p/IBM Telnet TN3270/
> > > >
> > > > # General-purpose telnet softmatch
> > > >
> > > > softmatch telnet m=^(?:\xff(?:[\xfb-\xfe].|\xf0|\xfa..))+[\0-\x7f]=
> > > >
> > > >
> > > >
> > > > Probe TCP tn3270 q|\xff\xfb\x18\xff\xfa\x18\x00IBM-3279-4-E\xff\xf0|
> > > >
> > > > match tn3270 m|\xff\xfd\x19| p/IBM Telnet TN3270/
> > > >
> > > > which results in:
> > > >
> > > > Nmap scan report for fake.fake (10.32.70.11)
> > > > Host is up (0.090s latency).
> > > > PORT     STATE SERVICE VERSION
> > > > 2323/tcp open  tn3270  IBM Telnet TN3270
> > > >
> > > >
> > > > Compared to the current SVN nmap-service-probes:
> > > >
> > > > Nmap scan report for fake.fake (10.32.70.11)
> > > > Host is up (0.094s latency).
> > > > PORT     STATE SERVICE VERSION
> > > > 2323/tcp open  telnet  Cisco or Edge-core switch telnetd
> > > > Service Info: Device: switch
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sun, Nov 1, 2015 at 8:50 PM, Daniel Miller <bonsaiviking () gmail com>
> > > > wrote:
> > > >
> > > > > SoF,
> > > > >
> > > > > Sorry it's taken me so long to get to your scripts! I hope to have
> > > > > them put through this week. I just had one final question on this one: Does
> > > > > the protocol require the back-and-forth of WILL TERMINAL TYPE/SEND TERMINAL
> > > > > TYPE/TERMINAL TYPE, or will it respond directly if we send the 3270
> > > > > terminal type immediately? I ask because if so, then we can turn this into
> > > > > a service probe. Example:
> > > > >
> > > > > Probe NULL
> > > > > softmatch tn3270 m|^\xff\xfd\($| p/IBM Telnet TN3270/
> > > > > # General-purpose telnet softmatch
> > > > > softmatch telnet m=^(?:\xff(?:[\xfb-\xfe].|\xf0|\xfa..))+[\0-\x7f]=
> > > > >
> > > > > Probe TCP tn3270 q|\xff\xfb\x18\xff\xfa\x18\x00IBM-3279-4-E\xff\xf0|
> > > > >
> > > > > match tn3270 m|something that matches here|
> > > > >
> > > > > Then we can start gathering specific match info from various versions,
> > > > > instead of simply identifying the service via this script. What do you
> > > > > think?
> > > > >
> > > > > Dan
> > > > >
> > > > > P.S. What's the best name to address you by?
> > > > >
> > > > > On Fri, Sep 4, 2015 at 6:09 PM, Main Framed <mainframed767 () gmail com>
> > > > > wrote:
> > > > >
> > > > > > Based on the change to nmap-service-probes (previously submitted)
> > > > > > this script will further help identify mainframes that only show up as
> > > > > > telnet/telnets (due to IAC DO TTYPE).
> > > > > >
> > > > > > --
> > > > > > Soldier of Fortran
> > > > > > @mainframed767
> > > > > >
> > > > > > _______________________________________________
> > > > > > Sent through the dev mailing list
> > > > > > https://nmap.org/mailman/listinfo/dev
> > > > > > Archived at http://seclists.org/nmap-dev/
> > > >
> > > >
> > > > --
> > > > Soldier of Fortran
> > > > @mainframed767
> >
> >
> > --
> > Soldier of Fortran
> > @mainframed767
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/