|
||
|
SecureMyi.com Security and Systems Management Newsletter for the IBM i
August 13, 2014 - Vol 4, Issue 13
|
||
|
|
||
|
SecureMyi.com Security and Systems Management Newsletter for the IBM i
August 13, 2014 - Vol 4, Issue 13
|
||
|
|
Restricting Access to the System Request Function - Why?By Dan Riehl The IBM 5250 keyboard layout used by IBM i defines a special keyboard key as the System Request (SYSREQ) key. Technicians use this key to perform various tasks including canceling a previous request, displaying information about the current job, sending messages, displaying the QSYSOPR message queue, etc. While the SYSRQS key does provide some great capabilities for programmers and operations technicians, in the hands of a dishonest or unwitting user, the use of the key can be the cause of some real problems. In this article I'll first discuss the vulnerabilities and problems inherent in the SYSRQS key, followed by instructions on how to restrict access to the key to prevent its use. I highly encourage you to consider locking down the SYSRQS function to only those users who have a demonstrated need to use the function. Here is a snapshot of the System Request menu.
System Request
System: MYSYSTEM
Select one of the following:
1. Display sign on for secondary job
2. End previous request
3. Display current job
4. Display messages
5. Send a message
6. Display system operator messages
7. Display work station user
80. Disconnect job
90. Sign off
Selection __
F3=Exit F12=Cancel
What are Some of the Main Exposures?The SYSRQS key can be used to acquire a full list of your application libraries and database files, along with the description of each database file, e.g. PAY001P - Payroll Master File.
And, in a little known hacking exploit, the SYSRQS key can be easily be used to enumerate all of the users enrolled on the system. Enumeration (i.e. Getting a list of all user accounts) on the system is one of the chief tools used by hackers. Yes, to break into your system, a password is typically needed too, but in security studies and my own experience, the average system has a large number of passwords that exactly match the UserID. (UserID BOBSMITH with password BOBSMITH) This is referred to as a Default Password. So, in some cases having a list of your Users, can be the doorway needed to attack your system by trying the default passwords. (Note: A powerful security officer user on your system can get a listing of all these users with Default Passwords using the command ANZDFTPWD(Analyze Default Passwords). No user should ever have a default password. User Enumeration – Getting a List of all User ProfilesUsing Option 3(Display Current Job) from the System Request Menu above presents the screen as shown below in Figure 1. Option 13 from this screen provides access to the library list of the current job as shown below in Figure 2. Figure 1 - Display Job
Display Job
System: MYSYSTEM
Job: WS1 User: LAMEUSER Number: 411983
Select one of the following:
1. Display job status attributes
2. Display job definition attributes
3. Display job run attributes, if active
4. Display spooled files
10. Display job log, if active, on job queue, or pending
11. Display call stack, if active
12. Display locks, if active
13. Display library list, if active
14. Display open files, if active
15. Display file overrides, if active
16. Display commitment control status, if active
More...
Selection
F3=Exit F12=Cancel
Figure 2 – Display Library List
Display Library List
System: MYSYSTEM
Job: WS1 User: LAMEUSER Number: 411983
Type options, press Enter.
5=Display objects in library
ASP
Opt Library Type Device Text
_ QSYS SYS System Library
_ QSYS2 SYS System Library for CPI's
_ QHLPSYS SYS
_ QUSRSYS SYS System Library for Users
_ MYLIB CUR My Library
_ PAYCUST USR PAYROLL CUSTOMIZATIONS
_ PAYDATA USR PAYROLL DATA
_ PAYPGM USR PAYROLL PROGAMS
_ QGPL USR General Purpose Library
_ QTEMP USR
Bottom
F3=Exit F12=Cancel F16=Job menu F17=Top F18=Bottom
In Figure 2 above, you can see the IBM supplied library QUSRSYS which routinely exists in the system portion of the library list for each job on the system. QUSRSYS typically contains all of the User Message Queues on the system. A User Message Queue is created whenever a new User is added to the system. The User Message Queue has the same name as the User. By displaying the content of the QUSRSYS library, and scrolling down to the list of User Message Queues, you may view all the User Message queues. In effect, this list is the same as the list of enrolled Users. Figure 3 – List of Library QUSRSYS, showing User Message Queues of Users
Display Library
Library . . . . . . : QUSRSYS Number of objects . : 1605
Type . . . . . . . . : PROD Library ASP number . : 1
Create authority . . : *SYSVAL Library ASP device . : *SYSBAS
Library ASP group . : *SYSBAS
Type options, press Enter.
5=Display full attributes 8=Display service attributes
Opt Object Type Attribute Size Text
MARYJONES *MSGQ 12288
MDUNTITLED *MSGQ 12288 IBM DB2 WEB QUERY DEV
MONITOR *MSGQ 12288 Display Screen Monito
MRADMIN *MSGQ 12288 IBM DB2 WEB QUERY ADM
MRSCHEDULE *MSGQ 12288 IBM DB2 WEB QUERY BRO
PAYUSER *MSGQ 12288 Test Payroll User
PRODOWNER *MSGQ 12288 OWNER PROFILE
PRODOWN4 *MSGQ 12288 PRODOWN4
PROG1 *MSGQ 12288 Class User #1
PROG2 *MSGQ 12288 Class User #2
More...
F3=Exit F12=Cancel F17=Top F18=Bottom
For User Enumeration purposes, having this list of the all the User Message Queues is basically the same as looking at a list of all the system's enrolled users. At this point you might ask, "Why don't you just list the QSYS library and list out all the User Profiles that live in QSYS?" The answer is that User Profiles are normally created as *PUBLIC AUT(*EXCLUDE), which means that only the very powerful security officer type users on your system would be able to see the list of User Profile objects in QSYS. But, the User Message Queues in library QUSRSYS are typically created as *PUBLIC AUT(*CHANGE), allowing any user to view the associated User Message Queues. Listing Library Names and Database File Names and DescriptionsIn the same way as we listed the job's Library List and the User Message Queues in library QUSRSYS, we can see that the libraries PAYCUST, PAYDATA and PAYPGM are listed in the library list, and can be similarly cataloged as the QUSRSYS library is in the prior example. These three PAY* libraries comprise the Payroll Application. By Selecting Option 5 (Display Objects in Library) for the PAYDATA library will list the Payroll Database file names and descriptions of those files. Cancel Request VulnerabilityIn another vulnerability, Option 2 of the SYSRQS menu provides the capability to cancel a request. For example, a user just pressed ENTER to initiate a large series of production database updates, but, then immediately presses SYSRQS, and selects option 2 - to "Cancel the Previous Request". In the middle of this long series of database updates, the request is canceled, causing some of the updates to be applied, but not all. Now, we have a production database that is out of synch. (Note: Using Commitment Control in the applications could allow you to avoid such database anomalies.) So, the SYSRQS function Option 2(Cancel Request) can cause major damage when used improperly. How to Restrict Access to the SYSRQS KeyI would expect that restricting access to the System Request Key and menu would be a simple matter of restricting access to some IBM program that ran the SYSRQS menu. But, in searching for the answer, I was surprised to learn that IBM's preferred method of restricting access is to restrict access to the Panel Group(Screen Definition) of the Menu. See IBM's discussion of this topic in The IBM InfoCenter. Here is a link to a related IBM Software Support Technical Document. The IBM supplied Panel Group object QGMNSYSR in the QSYS library is the key to restricting access to the System Request function. To prohibit users on the system from using the System Request function, assign *EXCLUDE authority to *PUBLIC for the Panel Group. GRTOBJAUT OBJ(QSYS/QGMNSYSR) OBJTYPE(*PNLGRP) USER(*PUBLIC) AUT(*EXCLUDE) After running this command, when a user that does not have *ALLOBJ special authority tries to use the SYSRQS function, an authority failure will occur, which will prohibit the use of the function. The error message generated is: CPD2317 - No authority to use system request functions. Cause . . . . . : You tried to use the system request functions but you do not have the authority to do so. To use system request functions, you must have authority to use the panel group QGMNSYSR. Making Exceptions to the RuleEven if you restrict the SYSRQS function for *PUBLIC, you will probably want to allow technical staff to use continue to use SYSRQS. So, you can assign those users, but preferably Group Profiles, *USE rights to the panel group, as in: GRTOBJAUT OBJ(QSYS/QGMNSYSR) OBJTYPE(*PNLGRP) USER(IT_GROUP) AUT(*USE) Remember to apply the change again each time you upgrade the operating system, since the panel group will be replaced by the upgrade. About the Author 
Dan Riehl is the Editor of the SecureMyi Security Newsletter and a Security Specialist for Dan performs IBM i security assessments and provides security consulting, remediation, forensic evaluations, and other customized security services for his clients. He also provides training in all aspects of IBM i security and other technical areas through The 400 School, Inc. 
|
|
 
|