Auditoría de IBM Power Systems (AS/400). Parte 4. Perfiles de usuario (contraseñas por defecto)

Hola,

Seguimos con nuestro cursillo de auditoría de IBM Power Systems (AS/400). Continuamos repasando el apartado de perfiles de usuario, haciendo un alto en el camino para hablar de las contraseñas por defecto.

En capítulos anteriores …

Estos son los contenidos vistos con anterioridad:

Parte 1. Introducción

Parte 2. Valores del sistema

Parte 3. Perfiles de usuario (generalidades)

Contraseñas por defecto

Estudiar las contraseñas por defecto es una tarea típica en el análisis de la seguridad de un sistema operativo. El caso de un 400 no es una excepción.

En sistemas transaccionales de medio y largo alcance es relativamente frecuente, dado el elevado número de usuarios, que existan muchos perfiles con contraseñas por defecto. Adicionalmente son sistemas que vienen de fábrica poblados con multitud de perfiles que tienen contraseñas por defecto, los cuales, en ausencia de una administración de seguridad adecuada, pueden perdurar en la vida útil del sistema pasando inadvertidos. Para facilitar su localización, los sistemas operativos de un 400 tienen una utilidad a disposición de los administradores de seguridad: el análisis de las contraseñas por defecto.

El riesgo de la existencia de contraseñas por defecto es más que obvio, ya que facultan a un atacante a lograr acceso al sistema sin la necesidad de explotar vulnerabilidades.

Analyze Default Password (ANZDFTPWD)

Tal y como se puede leer en el capítulo cuarto de la guía de referencia de seguridad del fabricante, este comando permite imprimir un informe completo de todos los perfiles de usuario declarados en el sistema que tienen contraseña por defecto, así como tomar medidas para mitigar los riesgos que estos perfiles representan. Las acciones pueden ser *NONE (no se toma ninguna medida), *DISABLE (desactivar el perfil) y *PDWEXP (poner la contraseña como caducada, lo que hará que al siguiente inicio de sesión el usuario deba cambiarla). En un 400 se entiende como contraseña por defecto aquella en la que el nombre del perfil de usuario coincide con la clave de dicho perfil.

Este comando, restringido para el oficial de seguridad (QSECOFR), está principalmente orientado a localizar perfiles por defecto que están declarados en el sistema en una instalación nueva, pero lógicamente, también permite al auditor localizar malas prácticas en la gestión de contraseñas, identificando perfiles a los que en vez de otorgar claves complejas, le han sido otorgadas claves simples, coincidentes con su nombre de perfil. Técnicamente hablando, el comando se surte del fichero de datos QASECPWD2, presente en la libería QUSRSYS.

Contraseñas por defecto de fábrica

Las siguientes credenciales suelen ser las habituales en una instalación de fábrica. Resulta fácil comprobar que la lista de duplas (notadas como perfil;contraseña) no es precisamente corta, lo que hace más que justificable el análisis de las contraseñas por defecto:

11111111;11111111
22222222;22222222
IBM;PASSWORD
IBM;2222
IBM;SERVICE
IBM;IBM
QAUTPROF;
QDBSHR;
QDOC;
QLPAUTO;
QNETSPLF;
QPGMR;QPGMR
QSECOFR;11111111
QSECOFR;22222222
SECOFR;SECOFR
QSRVBAS;QSRVBAS
QTFTP;
QTSTRQS;
QBRMS;
QDBSHRDO;
QDSNX;
QLPINSTALL;
QNFSANON;
QPM400;
QSNADS;
QSVCDRCTR;
QTMHHTTP1;
QUMB;
QCLUMGT;
QDFTOWN;QDFTOWN
QEJB;
QMQM;
QNOTES;
QPRJOWN;
QSPL;
QSYS;
QTMHHTTP;
QUSER;QUSER
QCLUSTER;
QDIRSRV;
QFNC;
QMQMADM;
QNTP;
QRJE;
QSPLJOB;
QSYSOPR;QSYSOPR
QTMPLPD;
QYPSJSVR;
QCOLSRV;
QDLFM;
QGATE;
QMSF;
QPEX;
QRMTCAL;
QSRV;QSRV;IBMCEL
QTCP;
QTMTWSG;
QYPUOWN;
QSERV;QSERV

El menú SECTOOLS

sectools

Esta utilidad es parte de un menú especial llamado SECTOOLS, un menú accesible mendiante go sectools, en el que además del análisis de contraseñas por defecto (ANZDFTPWD), es posible desplegar la lista de perfiles activos (DSPACTPRFL), los inactivos, analizar la actividad de los perfiles (ANZPRFACT), consultar la agenda de activación y desactivación de perfiles (DSPACTSCD), cambiar la agenda (CHGACTSCDE), gestionar la agenda de expiraciones (DSPEXPSCDE y CHGEXPSCDE) y imprimir información interna de los perfiles (PRTPRFINT).

Una auditoría completa del 400 haría recomendable revisar todas estas ejecuciones para determinar si existen indicios de una configuración de seguridad incorrecta. Elementos que nos pueden hacer sospechar son, por ejemplo, una agenda de desactivación y/o expiración sin entradas (síntoma de que los perfiles se crean sin expiración), un elevado número de perfiles inactivos, etc.

En el próximo capítulo indagaremos más en el análisis de los perfiles de usuario.

Un saludo,

Auditoría de IBM Power Systems (AS/400). Parte 3. Perfiles de usuario (generalidades)

Hola,

Cuando auditamos un sistema operativo siempre es interesante analizar el perfilado de los usuarios. El perfilado arroja siempre información sobre los riesgos que derivan de que los usuarios tengan o no los privilegios adecuados para hacer uso del sistema, o si lo preferimos, de la capacidad que tienen los usuarios de realizar acciones maliciosas intencionadas o accidentales.

Por desgracia, es frecuente minusvalorar el análisis del perfilado, ya que muchas auditorías se centran en aspectos técnicos como la configuración de seguridad y la presencia de vulnerabilidades que permitan a un atacante la realización de actividades maliciosas en un equipo o conjunto de equipos. Sin restar importancia a este tipo de análisis, el estudio del perfilado cobra especial interés en grandes sistemas donde existe un número muy elevado de usuarios, algunos de los cuales podrían estar legítimamente presentes en el sistema con excesivas atribuciones que facilitarían en gran medida un ataque. En general, y para cualquier sistema, sería siempre deseable un estudio mixto que combine el análisis de la seguridad perimetral (test de intrusión basado en configuración de seguridad endeble y/o vulnerabilidades) así como el estudio de los perfiles (probabilidad de realizar acciones maliciosas disponiendo de cuenta en el sistema)

En grandes sistemas transaccionales es muy complicado, por no decir prácticamente imposible, la intrusión tradicional, es decir, aquella en la que un usuario sin cuenta logra acceso al sistema aprovechando vulnerabilidades. El histórico de vulnerabilidades en los 400, z/OS y similares es prácticamente inexistente, con lo que no es de esperar que existan vulnerabilidades que permitan entrar alegremente al sistema, ganar privilegios de administración o elevar los privilegios que tenemos concedidos. Donde normalmente vamos a encontrar problemas es en la configuración de seguridad, y concretamente, en cómo se administran los perfiles.

Es bastante frecuente que el perfilado no esté suficientemente ajustado a los requisitos deseables de seguridad establecidos para la instalación, y esto responde principalmente a dos factores: por un lado son sistemas con un legado anterior extenso, lo que implica que arrastran una configuración que puede tener años de vida y en la que pueden existir errores no advertidos, y por otro lado, son frecuentes las instalaciones donde se percibe cierta ausencia de tareas administrativas regulares que permitan sanear y actualizar la situación de los perfiles, lo que suele provocar que en la declaración de perfilado existan errores diversos como por ejemplo, la dotación de excesivos privilegios, la concesión de permisos sobre programas que el usuario no utiliza, bien porque ya no pertenece a la organización, bien porque ha cambiado su rol en la misma. En definitiva, cuando auditamos un 400 hay que prestar especial atención a los perfiles, ya que buena parte de la seguridad global del sistema reside en estas declaraciones.

Una vez más, seguiremos los contenidos de la guía de referencia de seguridad del fabricante, que hemos enlazado en los capítulos anteriores. Dado que el análisis de los perfiles de usuario requiere realizar numerosas comprobaciones, vamos a dividir este tema en varias secciones. En la que publicamos hoy, hablaremos de algunos conceptos introductorios y generales relacionados con la auditoría del perfilado, para ofrecer una visión general antes de entrar en detalle.

En capítulos anteriores …

Para situarnos, estos son los contenidos vistos con anterioridad:

Parte 1. Introducción

Parte 2. Valores del sistema

Display User Profiles (DSPUSRPRF)

El comando de consola DSPUSRPRF (Display User Profiles) permite, como su propio nombre indica, obtener información sobre los perfiles declarados en el sistema, tanto de grupos como usuarios.

Su funcionamiento es muy sencillo. Así pues, DSPUSRPRF USRPRF(SHERNANDO) mostraría en pantalla el perfil del usuario shernando, siempre y cuando se tengan permisos para realizar la consulta. Empleando el mismo comando es posible obtener un fichero que contenga todos los perfiles dados de alta en el sistema:

DSPUSRPRF USRPRF(*ALL) TYPE(*BASIC) OUTPUT(*OUTFILE) OUTFILE(AUDITORIA/PERFILES)

Esta ejecución escribirá en el fichero PERFILES de la librería AUDITORIA todos los perfiles del sistema. Normalmente el auditor solicitará al administrador de seguridad la extracción de estos perfiles, ya que mostrar perfiles de usuario ajenos al nuestro requiere permisos especiales. Adicionalmente, por una cuestión de asepsia, es recomendable ordenar la extracción y recogerla junto al administrador de seguridad para que quede constancia de que el material proporcionado es conforme a los deseos de ambas partes.

Mediante la ejecución anterior estaremos en condiciones de realizar diversas pruebas sobre la totalidad de usuarios. La consulta mostrará información suficiente para poder analizar estos siete grupos de información y sus correspondientes campos de información:

  1. Fecha y hora: UPDCEN, UPDDAT, UPDTIM, UPSYST
  2. Nombre de usuario: UPUPRF, UPUSCL, UPJBDS, UPJBDL, UPTEXT
  3. Claves/Sign-on: UPDSIN, UPDSIN, UPPWCC, UPPWCD, UPPWCT, UPPWEI, UPPWEX, UPPWON, UPPSOC, UPPSOD, UPPSOT, UPNVSA, UPSTAT
  4. Capacidades: UPLDVS, UPSPAU, UPMXST, UPMXSU, UPPRLT, UPLTCP
  5. Condiciones iniciales de usuario: UPINPG, UPINPL, UPINMN, UPINML, UPATPG, UPATPL
  6. Pertenencias: UPOWNR, UPGRPF, UPGRAU, UPGRPI, UPACCD
  7. Auditoría: UPOBJA, UPAUDL

El objetivo del auditor será opinar, para todos los perfiles, sobre las condiciones de los campos enumerados anteriormente. Los veremos uno a uno en capítulos posteriores.

Autoridades especiales

En el 400 hay un conjunto de autoridades que se consideran especiales. Son, por así decirlo, privilegios elevados que se confieren a usuarios y grupos para la realización de tareas administrativas. Hay que ser especialmente cauto al analizar los perfiles de usuario, ya que si hay usuarios capaces de realizar acciones maliciosas, intencionadas o no, son los usuarios con atributos especiales.

La manera más fácil de analizarlos es enumerar la totalidad de usuarios obtenidos en nuestra descarga que no tienen el parámetro UPSPAU igual a *NONE (es decir, aquellos que no están marcados como usuarios sin autorizaciones especiales). Los tipos de autoridades especiales son:

  • *ALLOBJ: Autoridad «todos los objetos» (All Objects). Permite realizar operaciones en todos los objetos del sistema.
  • *AUDIT: Autoridad de auditoría (Audit). Permite a los usuarios definir las características de la auditoría del sistema, objetos y usuarios
  • *IOSYSCFG: Autoridad de configuración de sistema (I/O System Config). Permite a los usuarios configurar la comunicación, así como los dispositivos de entrada y salidad del sistema.
  • *JOBCTL: Autoridad de control de trabajos (Job Control). Esta autoridad ofrece control sobre los jobs del sistema.
  • *SAVSYS: Autoridad de salvado del sistema (Save System). Permite salvar y restaurar objetos.
  • *SECADM: Autoridad de administrador de seguridad (Security Administrator). Permite trabajar con perfiles de usuario del sistema.
  • *SERVICE: Autoridad de servicio (Service). Permite la realización de funciones de mantenimiento del software en el sistema.
  • *SPLCTL: Autoridad de control de colas (Spool Control). Permite obtener control total sobre los jobs sometidos a batch y las colas de salida.

Autoridades públicas (Public Authorities)

Las autoridades públicas sirven para simplificar la administración del sistema. Un objeto con autoridad pública implica que es accesible por todos los usuarios, siempre y cuando no recaiga sobre ese objeto alguna restricción particular que acote su disponibilidad.

Por defecto, muchos comandos vienen por defecto con la autoridad pública en *EXCLUDE, es decir, que por defecto se impide que cualquier usuario pueda realizar uso de esos comandos. Tómese en especial atención la presencia de autoridades públicas ya que entrañan un riesgo potencial elevado.

QSECOFR

Por último, para terminar esta introducción al perfilado de usuarios, resulta obligatorio hablar de QSECOFR. Este perfil es el perfil de máxima autoridad en el sistema, y suele venir de fábrica con la clave QSECOFR (expirada, luego obliga al cambio) y goza de las autoridades especiales *ALLOBJ, *SAVSYS, *JOBCTL, *SECADM, *SPLCTL, *SERVICE, *AUDIT y *IOSYSCFG

A todos los efectos, QSECOFR es el UID 0 del sistema. No debe perderse de vista que los 400 vienen, en una instalación de fábrica, con numerosos perfiles declarados (comienzan todos por Q), con lo que es más que recomendable ojear la guía de referencia de seguridad, concretamente la sección Appendix B. IBM-Supplied User Profiles para comprender la naturaleza de estos usuarios a la hora de auditar los perfiles.

En lo que a QSECOFR se refiere, no resulta admisible que sea un usuario empleado en el día a día de la administración del sistema. Lo usual es crear usuarios administradores de seguridad con privilegios elevados, trazables y personalizados, dejando a QSECOFR para acciones de emergencia o para eventos donde sea estrictamente necesaria su utilización. Es por tanto que la clave de QSECOFR debe estar custodiada y cambiada siempre que se haga uso del usuario y como no podía ser de otro modo, la monitorización de seguridad debe ser implacable, registrando todos los movimientos de este usuario, aún a riesgo de que podría eliminar sus trazas, con lo que es recomendable la monitorización específica del mismo por terceras personas ajenas a los administradores de seguridad en los centros de explotación (por ejemplo, en la sala de operación). Estas medidas son igualmente aplicables a todos los usuarios con autoridades especiales activos, lo que incluye a los administradores de seguridad.

En el próximo capítulo veremos cómo opinar sobre la seguridad del sistema atendiendo a la información que podemos obtener del perfilado de los usuarios declarados.

Un saludo,