Vulnerability Reference

Default and weak passwords on powerful profiles (QSECOFR and equivalents)

Critical Last verified

What Happened

Industry surveys of live IBM i shops, including Fortra's annual State of IBM i Security Study, have repeatedly found a meaningful share of systems with default or weak passwords still active on QSECOFR or on equivalent profiles carrying *ALLOBJ and *SECADM special authority. It is one of the findings that has stayed on the list year after year, which tells you something about how hard it is to clear rather than how obscure it is.

The reason it persists is structural rather than careless. QSECOFR is IBM-supplied, ships on every system, and cannot be deleted. On a lot of machines it is also a shared account: several administrators know the password, some scripts and scheduled jobs reference it, and changing it means coordinating with everyone and everything that depends on it. So it does not get changed, and the longer that runs the more people have known it at some point.

QSECOFR is only the visible half. The quieter half is the set of equivalent profiles created during migrations, vendor installations, and integration projects, each carrying the same special authorities with far less scrutiny. Those passwords tend to be set once and never rotated, and in older shops you still find the legacy convention where the password is simply the profile name.

What turns this from a theoretical concern into a live finding is reachability. A powerful profile is available from every network route that accepts a sign-on, not just the green screen somebody pictures when they think about who can log in.

Why It Matters

A profile holding *ALLOBJ and *SECADM can read, change, or delete any object on the system and administer other users' authority. There is no object-level control that constrains it, because *ALLOBJ is specifically the authority that skips those checks. Reaching such a profile is close to owning the system outright.

The shared-account part causes a second problem that survives the incident. The audit journal records which profile acted, not which person was driving it. If four people know the QSECOFR password, the journal can tell you what happened and cannot tell you who did it, which is exactly the question asked afterwards. Segregation of duties fails on paper at the same time.

*SECADM adds a multiplier worth understanding. It can create and change user profiles, so anyone who reaches a *SECADM profile can manufacture more privileged profiles. That converts a single compromise into persistent access that survives resetting the password you think was the problem.

It is also a reliable audit failure in its own right. A shared administrative account with a static password fails control requirements under PCI DSS, SOX-driven reviews, and most regulated frameworks, on any platform. Auditors do not need to demonstrate that anything went wrong to write it up.

Recommended Actions

  • Force a password change on QSECOFR and every profile carrying *ALLOBJ or *SECADM, and confirm the new value is not derived from the profile name, the system name, or the previous password
  • Stop using QSECOFR as a working account. Move day-to-day administration to named, individually owned profiles so the audit journal records a person rather than a role
  • Set QPWDEXPITV so powerful profiles rotate on a schedule, and move QPWDLVL to 2 or 3 if you are still limited to ten character passwords
  • Set QMAXSIGN and QMAXSGNACN so repeated failed sign-on attempts disable the profile or device instead of allowing unlimited attempts
  • Set QLMTSECOFR so profiles holding *ALLOBJ and *SERVICE can only sign on at devices you nominated, rather than anywhere on the network
  • Put MFA in front of every sign-on route that can reach a powerful profile, including ODBC and FTP, not only the 5250 session
  • Keep the QSECOFR password retrievable under a documented break-glass procedure, and treat its sign-on as an alert to investigate rather than a line in a log
  • Audit service, vendor, and integration accounts in the same pass, because they carry the same authority with the least attention on them

Sources

This is a recurring vulnerability class, not a single-incident CVE. It shows up repeatedly across live IBM i systems in industry security assessments, which is exactly why it is worth checking on yours rather than assuming it was handled.

Other Vulnerability Classes

Where This Fits