Admin Alert: QSECOFR Security Problems I Have Known

February 8, 2012 Joe Hertvik

Handling the QSECOFR user profile is always problematic. On one hand, it’s essential for the smooth operation of your system. Conversely, it can be a major issue if someone discovers its password. This week, I’ll review some real-life QSECOFR security breaches I’ve encountered and what can be done if you encounter these situations in your shop.

Real-Life QSECOFR Security Situations

A lot of strange things can occur with QSECOFR usage. Here are some common situations I’ve run into over the years and what can be done, if you encounter them.

1. Situation: Your IBM i administrator doesn’t change the QSECOFR password for years. I’ve encountered situations where the QSECOFR password is the same today as it was five years ago. The problem is chances are good that someone who was hanging around those shops then is still hanging around them now. And he probably still knows that password. The longer the QSECOFR password goes unchanged, the greater the risk someone will sign on and use it. After all, it’s not like leaving it unchanged will bite you. . . until it’s too late.

Recommended practice: Change QSECOFR on the same expiration schedule as your other passwords. If you have quarterly audit tasks, add it to those tasks.

2. Situation: QSECOFR password is commonly known throughout the shop and many users (even those performing operations work) use it for daily tasks. QSECOFR isn’t meant to be a do-it-all profile. Most shops need two trusted security officer users who are responsible for all administration (one primary and one backup) and for knowing the QSECOFR password. Those profiles should be used to do most of the administration, not QSECOFR. Don’t pass around the QSECOFR password and don’t use it for everyday tasks. The fewer people who know the password, the better.

Recommended practice: Change QSECOFR’s password on a regular basis per #1 and only give the password to your primary and backup administrators. Look at your other user’s duties and give them user profiles with appropriate authority to perform everyday tasks.

3. Situation: A staff member configures third-party software to use QSECOFR and its password for automatic sign-on functions from remote servers. I ran into this once when we changed the QSECOFR password and one of our controllers stopped working. The reason? The controller was using QSECOFR to start an automatic session with our Power i 550. When we changed the password, the controller could no longer connect. I’ve also run into shops where people use it for remote ODBC or FTP access (dumb). Using QSECOFR for embedded profile passwords is a security risk. If used in enough places, it makes it impossible to change the password (see point #2). It also makes it easier to discover the password.

Recommended practice: QSECOFR should never be used for automatic IBM i sign-on for other servers and software. If necessary, create another user profile that has just enough authority to run your automated remote function (and nothing else) and use that profile, instead. Many vendors create special profiles just for that purpose (though you have to be careful those aren’t security officer equivalent profiles either).

4. Situation: You have to temporarily give the QSECOFR password to another user or consultant for installing or configuring a software upgrade. Being a suspicious administrator, I’ve never liked this practice but sometimes software has to be installed or run under QSECOFR and you have no choice but to tell the installer what the password is. Remember there are two ways a QSECOFR user password can bite you: by giving an unauthorized user security officer access; and by using that access to provide other unauthorized users with security officer access.

Recommended practice: First, be present when someone is using the QSECOFR user profile. Next, if possible, sign that user on as QSECOFR and hang around while they do the installation, Finally, change the password immediately when they are finished. Be suspicious and don’t let the user out of your sight while they have the QSECOFR password.

5. Situation: QSECOFR password is left out in the open, taped to the wall somewhere, in a file, on the Internet, or taped to the system console. It constantly amazes me the stupid and dangerous things people will do to remember passwords. I have walked into shops where the QSECOFR password is posted on a wall in plain sight, sometimes right next to the system console. Be watchful and aware that users may do that.

Recommended practice: Don’t do that. Change the password often. Make sure you cover password protection in your company’s IT policies.

6. Situation: The QSECOFR password or a QSECOFR-equivalent password can sign on with a default password. I once worked in a shop with three administrators for 20 AS/400 partitions. We had to change our passwords on each partition every three months. After one of the admins automatically changed his password on all the machines, he would immediately use the Work with User Profile (WRKUSRPRF) command to change the password back to its default value. And remember this was a security officer user who should have known better. Running ANZDFTPWD on a regular basis would have helped us discover this situation.

Recommended practice: Run the ANZDFTPWD password on a regular basis. Consider setting ANZDFTPWD’s parameters to automatically disable default password users or force those users to change their password according to the published password change schedule. For more information on using ANZDFTPWD, see this article.

7. Situation: High-level security administrator who knows QSECOFR password leaves the organization. Usual audit recommendations specify that this user should be considered a liability. Assume the user could be disgruntled, even if it’s your mother.

Recommended practice: Immediately change the QSECOFR password. You should also change the passwords for any other security officer users on the system. Above all, remove them from any remote system access (such as VPN, Web-enabled IBM i sessions, etc.) they may have.

8. Situation: A user has discovered the QSECOFR password and is signing on with it on a regular basis. A few years ago, I was in an organization that had a static password, ala point #1. One of the programmers resented not to being able to do whatever he wanted to do on the system. He discovered the password and started signing on as QSECOFR, just because he could. We didn’t realize it was happening until we accidentally noticed it one day.

Recommended practice: If you have a monitoring system, set up a monitor to alert you whenever someone signs on using QSECOFR. If you discover an unauthorized usage, contact the user, end the job, and immediately change the QSECOFR password. Bring the matter up to appropriate management, if necessary.

Follow Me On My Blog and On Twitter

When you have a few minutes, come check out my new blog at joehertvik.com, where I focus on marketing and technical writing news and materials (including white papers, case studies, email campaigns, etc.), computer administration (especially iSeries), articles, and whatever else I come across.

You can also follow me on Twitter @JoeHertvik.

Joe Hertvik is the owner of Hertvik Business Services, a service company that provides written marketing content and presentation services for the computer industry. He also runs a data center for two companies outside Chicago. Joe is a contributing editor for IT Jungle and has written the Admin Alert column since 2002.