I guess you could call it hacking or just using a wide-open system!
The user would need:
- Network access to the FTP and listen port
- Firewalls could prevent
- The TCP stack could limit (TERMINAL, SERVAUTH, etc)
- Access to FTP and ability to upload an executable file
- An FTP exit could be used to prevent either
- Permission to submit a job
- SAF and/or a FTP exit could limit this
- A job would need permission to listen on a port
- User could be prevented from running a shell "default program" in OMVS segment
Basically, the person must be able to ftp into a UNIX subdirectory and to submit a job. They upload a program called "netcat" into a data set starting with their RACF id and the batch job may be submitted via FTP; the hacker needn't have a TSO session. And it's pretty obvious that FTP submit doesn't use
TSO SUBMIT internally, so it's fairly likely that the TSO exits won't be entered. They then submit a job which copies the data set into the /tmp subdirectory with a "random" name, chmod the name to be executable, then executable does start the netcat in the "background" (asynchronous to the batch job) and piping to/from the z/OS UNIX shell.
The Last Detail:
Once connected to the FTP server it uploads netcat and a randomly generated JCL file. The JCL file uses BPXBATCH to copy the netcat binary to OMVS and executes it as a listener running /bin/sh. The script then connects to the random port it picked and you can start issuing UNIX commands. Super Simple!
The script takes this generated JCL file and stores it temporarily on your system. Then it tells the FTP server to accept a file in JES mode. It then uploads the JCL file After uploading the JCL it switches the FTP server back to file mode and deletes the netcat binary. This coupled with the JCL means all files uploaded are deleted after you disconnect and the only traces are logs of your JCL file.
The "hacker" simply connects to the port that netcat is listening on, and presto, they have a shell on their desktop.