Nmap Development mailing list archives

Previous By Date Next
Previous By Thread Next

Re: [NSE] Script to enhance mainframe TN3270 detection

From: Phil <mainframed767 () gmail com>
Date: Sun, 8 Nov 2015 14:19:03 -0800
This is so cool! It’s working great now!

Against TN3270E:
Host is up (0.042s latency).
PORT     STATE SERVICE VERSION
23/tcp open  tn3270  IBM Telnet TN3270 (TN3270E)

Against TN3270:
Host is up (0.083s latency).
PORT     STATE SERVICE VERSION
23/tcp open  tn3270  IBM Telnet TN3270 (traditional tn3270)


Thanks for all the help!


On Nov 8, 2015, at 10:43 AM, Daniel Miller <bonsaiviking () gmail com> wrote:

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 <mailto: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 <mailto: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 <mailto: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 <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://github.com/tvdw/gotor>
 # https://lists.torproject.org/pipermail/tor-dev/2015-January/008135.html 
<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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <https://nmap.org/mailman/listinfo/dev>
Archived at http://seclists.org/nmap-dev/ <http://seclists.org/nmap-dev/>




--
Soldier of Fortran
@mainframed767




--
Soldier of Fortran
@mainframed767

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/
Previous By Date Next
Previous By Thread Next

Current thread: