49 - Ataques a nuestro AS/400 - 18/08/2006


Autor: Noe Espinoza

http://www.segu-info.com.ar

Footprinting


Comenzaremos listando cierta cantidad de puertos por defecto de los AS/400 mencionando solo algunos que se conocen como puertos seguros (utilizan SSL) e inseguros (todos los demás). A estos puertos se los puede hallar fácilmente en Google o bien directamente en la página de IBM.

Inseguros

  1. Ddm - DDM Server: usado para el acceso vía DRDA - 446
  2. AS-Central - Servidor central: usado cuando un cliente requiere acceso para descargar tablas - 8470
  3. AS-database: usado para acceder las bases de datos - 8471

Seguros

  1. Ddm-SSL - DDM Server: idem el inseguro - 447 y 448
  2. AS-Central-s: idem el inseguro) - 9470
  3. AS-databse-s: idem al inseguro) - 9471

Si analizamos nos damos cuenta que si se usan los puertos inseguros (esto es visto en un 60% de las instalaciones) podemos realizar un Sniffing, el cual se tratará con detalle más delante.

Ahora bien!... usemos nuestro escáner preferido (recomiendo Nmap) y comencemos a "jugar".

Nmap -sS -P0 victimaAS400.com -p446,447,9470,8470 -sV

Nota: es recomedable leer un manual de Nmap.

Con este comando escaneamos puertos específicos pero podemos barrer todos (-p 1-65535) y -sV nos dará el Banner descriptivo de los mismos. Realizamos esto para verificar si realmente se ejecutan los servicios en los puerto por defecto.

Si nuestro análisis resulta positivo procedemos a usar la navaja suiza, el popular NetCat u Open NetCat[4].

Nota: es recomedable leer un manual de NetCat, los hay muchos y muy variados.

NC -vv victimaAS400.com 21

Con este comando obtendremos el banner de identificación del servicio.

El paso siguiente es el intento de conexión a través de Telnet. Usaremos un cliente "especial" ya que AS/400 lo utiliza para realizar conexiones aunque con algunos podemos realizar un telnet con el cliente de Windows. En esta oportunidad utilizaremos TN5250 un cliente telnet para mainframes que se puede descargar de mochasoft.

Es común encontrar abiertos algunos puertos por defecto como lo son SMTP, POP3, FTP, Telnet entre otros y aquí deberemos utilizar nuestra imaginación para aprovechar todo lo que se puede realizar sobre ellos.

Una herramienta que puede utilizarse para verificar que MTA se usa en el servicio de SMTP se puede encontrar en GreyHats incluyendo documentos para el uso de la misma. Otro servicio que se puede investigar es SNMP, que si está habilitado nos proporcionará mucha información. Para ello usaremos snmpwalk. Se debe prestar especial atención a la entrada de las versiones de SNMP que se puedan estar manejando y las diferentes comunidades. Por ejemplo:

Snmpwalk victimaAS400.com public -v2

Ahora estamos listos para pasar al siguiente paso.


Enumeración de usuarios

Antes de comenzar cabe mencionar que algunos de los exploits utilizados requieren un usuario válido y otros no. Recordemos también que muchas empresas en sus AS/400 usan los mismos usuarios y passwords en forma permanente. Otras (las menos), se preocupan y utilizan buenas políticas. Cabe mencionar también que muchas veces es mas fácil ingresar a un servidor que no sea AS/400 debido a que la cultura de seguridad no es tan buena. Entonces, si colocamos los mismos usuarios y passwords en el AS/400 y en los otros servidores, si uno de esos es comprometido el AS/400 también puede serlo.

Como ya se vio en anteriores entregas, existe una gran lista de los diferentes usuarios por defecto que tiene un iSeries y por mencionar algunos QAUTPROF, QDBSHR, QRJE, QSRV, QUSER, QTFTP, QSYSOPR, etc.

Aunque en la actualidad la mayoría de los AS/400 instalados soportan encripción en la transmisión de sus datos muchos de ellos no lo tienen habilitados (yo diría un gran porcentaje) y un atacante puede hacer Sniffing a la red para enumerar los diferentes usuarios y sus passwords; dando por finalizado nuestro pequeño juego.

Continuando, al realizar un intento de conexión por Telnet al equipo, se pueden obtener diferentes errores. Por ejemplo:

CPF1116 next no valid sing-on attemp varies off device
CPF1392 nex no valid sing-on disables user profile
CPF1394 user profile ABC cannot sing on
CPF118 No password associated with user ABC

Entre otros tantos, así que se debe prestar atención porque algunos administradores cambian estos mensajes para despistar. La forma de hacerlo es la siguiente:

CHGMSGD MSGID(CPF1120) MSGF(QCPFMSG) MSG('Invalid login attemp')

Por otro lado algo parecido sucede con el intento de login por FTP y POP3. Todos estos nos arrojan ciertas características que nos dicen si realmente un usuario existe o no (quien tenga oportunidad de practicar se dará cuenta del motivo del comentario).

Bueno... entremos al juego interesante.

Vamos a listar usuarios mediante FTP manipulando algunas librerías y el contenido de las mismas. Veamos lo siguiente:

ftp victimaAS400.com

Estando dentro ingresamos lo siguiente:

quote stat (nos dará la configuración inicial)

Luego ingresamos:

quote site namefmt 1
cd /

Con esto usaremos naming format "1". Ahora ingresamos:

quote site listfmt 1

Con eso pondremos la lista de directorios en formato LISTFMT.

Finalmente ingresamos:

dir /qsys.lib/*usrprf

Para listar los usuarios.

Aquí podemos tener éxito o puede salir un error indicando que la extensión es desconocida. En este caso creamos un link simbólico hacia la librería QSYS en un directorio (IFS: Integrated File System). Esto se realiza mediante el comando ADDLNK y los siguientes pasos:

mkdir patito
quote rcmd ADDLNK OBJ('/qsys.lib') NEWLNK ('/patito/qsys')

Ahora ya podemos ejecutar:

quote rcmd QSH CMD('ln -fs /qsys.lib /patito/qsys')
cd /patito
dir /patito/qsys/*.usrprf

Y tendremos nuestros usuarios.

Más Información:

http://auditmyit.blogspot.com/2006/04/as400-it-security-audit-program.html

Buenos Aires, 01 de julio de 2006

Con más de 24 años de experiencia compartiendo la mejor información de Seguridad

Contacto