TEMARIO

Auditoría de contraseñas en Oracle Database (1 de 4). Introducción y primeros pasos
Auditoría de contraseñas en Oracle Database (2 de 4). Adivinación de Oracle SID (System ID)
Auditoría de contraseñas en Oracle Database (3 de 4). Fuerza bruta sobre claves Oracle
Auditoría de contraseñas en Oracle Database (4 de 4). Ataques de diccionario sobre claves Oracle

Finalizamos la serie hablando de ataques de diccionario en el mundo de las contraseñas de Oracle. En el tercer capítulo de la entrega comentamos cómo se obtenían las distintas combinaciones de usuario y hash de clave en Oracle. Recordad que propusimos algunos ejemplos reales en una instalación XE, disponibles en http://www.sahw.com/images/oracle_audit/usuarios.txt.

Los ataques de diccionario son tremendamente fáciles de ejecutar cuando se dispone de los hashes, y dependerá de la calidad de nuestro diccionario, así como de la complejidad de la clave a analizar, el éxito de la prueba. Como en cualquier otro ataque de diccionario, se trata de obtener el hash de una palabra conocida (presente en el diccionario) y verificar si es igual al del usuario cuya contraseña estamos analizando. En caso de que coincidan, la clave del usuario será la palabra que estemos empleando en el diccionario.

Ejemplos

Una de las herramientas más conocidas, aunque no es la única, es checkpwd, que podéis obtener en http://www.red-database-security.com/software/checkpwd.html. Su empleo es extremadamente sencillo, y puede ejecutarse en Windows, Linux y MacOS. Cuenta además con un binario que realizará la verificación sin mostrar la contraseña, con lo que se puede preservar el conocimiento de la misma. Adicionalmente permite al auditor ejecutar la verificación tanto offline como directamente contra la base de datos, método con el cual no haría falta obtener la relación de hashes.

En el siguiente ejemplo, conectamos a la base de datos y hacemos la verificación. El operador -quiet hará que solo se muestren las contraseñas que sea posible vencer por ataque de diccionario, no apareciendo las claves que resitan el ataque:

Los métodos de ataque en línea no están recomendados, salvo que se tenga permiso expreso para ello. Por tanto, si tenéis que analizar offline un fichero con cientos o incluso miles de usuarios, emplear la utilidad se vuelve tedioso, ya que para cada caso, hay que introducir el usuario y el hash. Para facilitaros la vida, he escrito este sencillo script Perl con el que sólo hay que procurar tener un fichero llamado usersandpasswordhashes.txt en el que en cada linea, separado por al menos un espacio, haya una relación de usuario y hash. Los usuarios de sistemas no Windows, siéntanse libres de modificar las llamadas al sistema.

 
#!/usr/bin/perl -w
# chechpwd.exe automation 
 
my $input="usersandpasswordhashes.txt";
my $output="checkpwd_audit_results.txt";
 
open (INPUT,"< $input") || die "ERROR: Cannot open entry file $input\n";
 
while ($line=<INPUT>){	
 
	my @string = split (" ", $line);
	my $userandhash = $string[0].":".$string[1];
    print "Analyzing username $string[0]\n\n";
	system("ECHO ===================== >> $output");
	system("ECHO $string[0] >> $output");
	system("ECHO ===================== >> $output");
	system("checkpwd.exe $userandhash password_file.txt >> $output");
    system("ECHO. >> $output");
	} 
 
close INPUT;
 

Tenéis un ejemplo del fichero que produce el script en http://www.sahw.com/images/oracle_audit/checkpwd_audit_results.txt

Pues aquí acaba nuestro recorrido por la auditoría de contraseñas en Oracle Database. Espero que estos contenidos os sean de utilidad y os ayuden a mejorar la calidad de las claves presentes en vuestros sistemas.

Un saludo,

TEMARIO

Auditoría de contraseñas en Oracle Database (1 de 4). Introducción y primeros pasos
Auditoría de contraseñas en Oracle Database (2 de 4). Adivinación de Oracle SID (System ID)
Auditoría de contraseñas en Oracle Database (3 de 4). Fuerza bruta sobre claves Oracle
Auditoría de contraseñas en Oracle Database (4 de 4). Ataques de diccionario sobre claves Oracle

Buenas,

Continuando con lo explicado en los dos primeros artículos toca hablar de cómo utilizar ataques de fuerza bruta para evaluar la calidad de las claves Oracle. No obstante, antes de hacerlo, es preciso comprender dónde y cómo se almacenan las claves.

Distintas versiones, distintas ubicaciones

Las contraseñas Oracle se guardan, por norma general, en una tabla llamada DBA_USERS. Excepciones a esta norma hay muchas, así por ejemplo, SYS.USER$, o la tabla USERS$, lugar donde se almacenan en la versión XE que estamos utilizando para esta serie de artículos.

Históricamente la presencia de numerosos usuarios de sistema en la configuración de fábrica ha supuesto y sigue suponiendo muchos problemas para la seguridad Oracle. Me recuerda al caso de los servidores de largo y medio alcance de IBM, donde los sistemas operativos suelen venir con una cantidad ingente de usuarios creados que si no son modificados pueden provocar un problema cuando el sistema entre en producción.

A lo largo de los años, y según han ido cambiando las versiones de Oracle, también han ido cambiando los métodos de generación y conservación de claves. Desde el cifrado de la concatenación de usuario y clave en las versiones entre 7 y 10g R2 hasta el empleo de salts en 11g, donde se emplea SHA-1 para generar un hash de la concatenación de clave y salt. Para cada versión el auditor debe repasar la documentación y comprender cómo y dónde se conservan las claves. Tenéis un estupendo artículo al respecto en http://www.red-database-security.com/whitepaper/oracle_passwords.html que puede servir de orientación.

Es importante reseñar que desde la versión 11g en adelante los hashes no se almacenan en DBA_USERS. En esta versión hay que recuperar los campos name y spare4 de SYS.USER$.

SELECT name,spare4 FROM SYS.USER$ WHERE password is not null;

Tampoco entraremos a comentar otras ubicaciones donde puedan estar presentes los hashes de las claves, como las vistas que se hayan creado, duplicados de las tablas, rollbacks, copias de seguridad, etc. En definitiva, la misión del auditor es identificar dónde están las claves y obtener la relación usuario-hash para poder así realizar una verificación de calidad de las mismas. También es importante determinar quién puede obtener esos datos, qué permisos son necesarios y por supuesto, hay que indagar en todos los métodos posibles para obtenerlos, incluyendo el pentesting.

Caja negra, gris y blanca

En el primero de los casos, las pruebas irán encaminadas, mediante pentesting, a hacernos con un listado de usuarios y hash de clave para tratar de obtener claves en claro. El ataque constará de dos partes:

• Intrusión al sistema, habitualmente por cuentas con clave por defecto no modificadas o bien aprovechando algún exploit que nos permita el acceso.
• Extracción de relación de usuarios y hashes, bien por haber logrado acceso privilegiado que permita hacerlo directamente, bien por provocar escalada de privilegios que nos permita finalmente obtener la relación. En algunos casos, si la configuración de seguridad no es adecuada, bastará con tener los privilegios mínimos para obtener la relación.

En el caso de caja gris el auditor tratará de obtener la relación de usuarios empleando las credenciales no privilegiadas que le han sido entregadas. Es frecuente, por mala configuración, que incluso los perfiles más bajos puedan obtener la relación de usuarios y hashes. Este modelo es análogo al de caja negra, pero con la diferencia de que el auditor contará de partida con una cuenta en el sistema.

Para el caso de caja blanca, que será el que ejemplifiquemos, el auditor solicitará al DBA que extraiga la relación de usuarios y hashes para analizarlas.

Los usuarios especiales y los datos críticos, el botín más cotizado

Siempre que sea posible, habida cuenta de que por defecto son las cuentas más poderosas, el análisis tendrá en cuenta especialmente los siguientes usuarios: SYS, SYSTEM, SYSMAN y DBSNMP. En la documentación hallaréis descripciones de cada uno de estos usuarios.

No debemos perder de vista los usuarios con privilegios elevados (DBA y otros) que se hayan podido crear tras la instalación. Basta con descuidar un sólo perfil privilegiado para que un atacante tome control total de la instalación. Es tan importante que SYS disponga de una clave de alta calidad como cualquier otro usuario creado con perfil suficiente para acceder a los datos críticos. No olvidemos que en Oracle la seguridad debe siempre enfocarse a la seguridad de los datos, así pues, si el usuario SHERNANDO tiene privilegios mínimos globales pero es dueño de la tabla más importante del sistema, su compromiso es equivalente al de comprometer la cuenta SYS.

Fuerza bruta sobre las claves

En nuestro ejemplo vamos a crear algunos usuarios adicionales con distintas claves:

A continuación, sacaremos a fichero todas las relaciones usuario-hash, empleando el comando spool.

Recogemos el fichero, en este caso de C:\XEClient\bin y lo ponemos a buen recaudo. He dejado una copia del fichero en http://www.sahw.com/images/oracle_audit/usuarios.txt por si queréis utilizarlo.

Hay infinidad de programas para someter a los hashes obtenidos a fuerza bruta. Uno de los más populares es orabf, que incluye una lista de claves habituales y diversas opciones para construir los ataques de fuerza bruta. Veamos un ejemplo de cómo se utiliza:

En el ejemplo anterior vemos cómo el usuario SYS tiene una clave por defecto llamada password, que ni siquiera ha sido preciso romper mediante fuerza bruta puesto que estaba en el diccionario. Otro ejemplo:

En este caso ha bastado un minuto para averiguar la clave. Veamos qué pasa si cambiamos la clave de pass2 a clave2 (ampliamos de 5 a 6 caracteres)

Sometemos el nuevo hash a fuerza bruta:

Como era previsible, el tiempo de ataque se ha elevado a varios minutos. A mayor calidad de la clave, más tiempo. Por lo general el tiempo de cómputo elevado no hace rentable los intentos de fuerza bruta en claves complejas de 7 o más caracteres.

Existen infinidad de herramientas para fuerza bruta: herramientas W32 como la mostrada, UNIX, procedimientos PL/SQL, scripts Perl ... Tenéis una buena selección de las mismas en http://www.petefinnigan.com/tools.htm, y cada día aparecen más. Cuestión de probarlas, y elegir la que más os guste.

Fuerza bruta con múltiples cuentas

Entre las muchas herramientas existentes siempre recomiendo Inguma, de Joxean Koret, un framework de seguridad bastante completo que además tiene funcionalidades específicas para Oracle. Además de su versatilidad, Inguma está escrita en Python, con lo que es multiplataforma, y para el caso que nos ocupa tiene un módulo de fuerza bruta para contraseñas Oracle llamado bruteora que podemos lanzar contra las cuentas usuales en la base de datos:

Al ser código abierto, es fácil incorporar las cuentas declaradas en la base de datos para complementar las cuentas frecuentes empleadas por Inguma, con lo que finalmente es posible obtener también una valoración de la calidad de todas las contraseñas que existan en el sistema. Este método, a diferencia de otros, es online, con lo que el auditor debe tener presente el impacto sobre el sistema a auditar.

Un saludo,

TEMARIO

Auditoría de contraseñas en Oracle Database (1 de 4). Introducción y primeros pasos
Auditoría de contraseñas en Oracle Database (2 de 4). Adivinación de Oracle SID (System ID)
Auditoría de contraseñas en Oracle Database (3 de 4). Fuerza bruta sobre claves Oracle
Auditoría de contraseñas en Oracle Database (4 de 4). Ataques de diccionario sobre claves Oracle

Hola,

En la introducción que hicimos ayer vimos que para conectar a una instancia Oracle es necesario, antes de autenticarnos, alcanzar el Oracle Listener, y para eso hacen falta 3 datos:

• La dirección de la máquina (hostname o IP)
• El puerto donde Oracle Listener está a la escucha
• El SID (System ID), o identificador del sistema

El listener es un proceso que corre en el lado del servidor que como su propio nombre indica, realiza escuchas a las peticiones de conexión con el objetivo de gestionar las conexiones entrantes. Cuando se hace una petición, esta llega al listener, el cual verifica que contiene los parámetros que han sido definidos en el servidor (mediante el fichero listener.ora). Si la verificación es positiva, se permite al cliente peticionario establecer conexión con el servidor, lo que posibilita que pueda a posteriori autenticarse con su usuario y contraseña.

Este fichero está normalmente ubicado en $ORACLE_HOME/network/admin, si tenemos una versión UNIX, o en ORACLE_HOME\network\admin si tenemos una versión Windows. En el caso de la versión Express Edition que estamos utilizando para nuestros ejemplos, este fichero reside por defecto en C:\oraclexe\app\oracle\product\10.2.0\server\NETWORK\ADMIN junto a los ficheros de configuración sqlnet.ora y tnsnames.ora, comentado en el artículo anterior. Por defecto, el fichero listener.ora tiene los siguientes contenidos:

SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = C:\oraclexe\app\oracle\product\10.2.0\server)
(PROGRAM = extproc)
)
(SID_DESC =
(SID_NAME = CLRExtProc)
(ORACLE_HOME = C:\oraclexe\app\oracle\product\10.2.0\server)
(PROGRAM = extproc)
)
)

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC_FOR_XE))
(ADDRESS = (PROTOCOL = TCP)(HOST = nimoy)(PORT = 1521))
)
)

DEFAULT_SERVICE_LISTENER = (XE)

Del fichero anterior se deduce que para la versión de Oracle Express que estamos utilizando, el SID principal es XE, que el host se llama nimoy (es local, puede ser invocado mediante 127.0.0.1) y que el puerto es 1521. Esta información casa a la perfección con las declaraciones que hay que hacer en tnsnames.ora documentadas en el artículo anterior. Estos son los tres datos que nos permitirán conectar al listener.

¿Es el SID un dato adivinable?

La respuesta es sí. Todo se basa en que si el SID es incorrecto cuando intentamos conectar se devuelve al cliente un mensaje ORA-12505: TNS:listener does not currently know of SID given in connect descriptor, lo que puede ser utilizado para determinar que pese a que la dirección y el puerto son correctos, el SID no lo es.

Esto hace extremadamente sencillo programar una utilidad que lance peticiones al listener empleando los SID más comunes, y que verifique si se devuelven mensajes del tipo ORA-12505, lo que permite dilucidar si la base de datos está empleado un SID por defecto o adivinable en cuestión de segundos. Ejemplos de adivinadores de SID son sidguess de Red Database Security, o SIDguesser de Patrik Karlsson. La diferencia fundamental entre ambas es que sidguess permite la adivinación del SID mediante ataque de diccionario y fuerza bruta, mientras que SIDguesser sólo emplea diccionario. Para esta última modalidad, tenéis publicada una lista de SIDs comunes en http://www.red-database-security.com/scripts/sid.txt.

Otras herramientas para la adivinación de SID son:

• Inguma, de Joxean Koret, un excelente framework que incluye un módulo específico de adivinación de SID (CSidGuess.py). Ojo: Requiere los módulos Python cx_Oracle y readline
• The Oracle Assessment Kit (OAK), de David Litchfield. Se puede descargar en http://www.vulnerabilityassessment.co.uk/oak.htm
• oscanner, también de Patrick Karlsson, que además de enumeración SID realiza otras tareas de auditoría en la base de datos. Se puede descargar en http://www.cqure.net/wp/oscanner/
• También es posible usar Metasploit para estos menesteres, a través del módulo sid_brute. Otros módulos están disponibles, como spy_sid, pero debe tenerse en cuenta que en las versiones 9.2.0.8 y superiores, el listener está protegido y hay que recurrir a la fuerza bruta o adivinación. En cualquier caso, la adivinación de SIDs puede ser obtenida mediante consultas directas al listener (sid_enum), aplicando fuerza bruta y/o diccionario (sid_brute), así como realizando consultas a otros componentes que puedan contener el SID (sid_enum+spy_sid)

Algunos ejemplos:

SIDguesser en la instalación por defecto de Oracle XE

sidguess (diccionario) en la instalación por defecto de Oracle XE

sidguess (fuerza bruta) en la instalación por defecto de Oracle XE

OAK (ora-brutesid) en la instalación por defecto de Oracle XE

OAK (ora-getsid) en la instalación por defecto de Oracle XE

inguma (sidguess) en la instalación por defecto de Oracle XE

Metasploit (sid_brute) en la instalación por defecto de Oracle XE

Enumeración Metasploit (sid_enum) fallida por protección de listener

Y que nadie olvide una de las maneras más simples de obtener los SID: empleando Oracle listener control utility. Nótese que los comandos status y services de esta utilidad no pueden ser lanzados remotamente si la autenticación contra el sistema operativo está activa (LOCAL_OS_AUTHENTICATION), cosa que sucede por defecto en las versiones 10g R1 y superiores.

A la vista de lo explicado, el primer paso fundamental para proteger las contraseñas es proteger la base de datos. La regla número uno del buen DBA es siempre instalar instancias de Oracle cuyo SID no sea adivinable y cuyo contenido no sea revelable mediante ningún tipo de consulta, y a la vista está el porqué.

Un saludo,

TEMARIO

Auditoría de contraseñas en Oracle Database (1 de 4). Introducción y primeros pasos
Auditoría de contraseñas en Oracle Database (2 de 4). Adivinación de Oracle SID (System ID)
Auditoría de contraseñas en Oracle Database (3 de 4). Fuerza bruta sobre claves Oracle
Auditoría de contraseñas en Oracle Database (4 de 4). Ataques de diccionario sobre claves Oracle

Buenas,

He recibido durante los últimos meses alguna que otra petición para que hablara de la auditoría de productos Oracle. Me es imposible escribir entradas para cada uno de los productos de esta compañía, porque además de ser muy numerosos y complejos, algunos son sólo de aplicación en entornos muy determinados, con lo que el ejercicio sólo tendría interés para unos pocos. Hablamos de los productos y servicios tan variopintos como la gama on demand, Fusion middleware, Portal, Data mining, OLAP y dentro del mundo de aplicaciones podríamos citar la gestión centralizada de datos (MDM), sectoriales para banca, finanzas, capital humano, JD Edwards, Peoplesoft, Siebel ... la lista es demasiado larga para escribirla completa.

Sin embargo, me vienen a la mente dos productos que quizás si gocen de más popularidad. En la mayoría de corporaciones son los dos entry-level products por excelencia, y es relativamente frecuente toparse con ellos. Se trata de Oracle E-Business Suite y cómo no, de Oracle Database, la base de datos. Podríamos escribir muchísimo sobre ambos, ya que son productos extremadamente extensos y complejos, pero en esta serie de artículos sólo nos vamos a centrar en uno de los productos y en una única faceta de auditoría del mismo: contraseñas en Oracle Database.

Gama de Oracle Database

Oracle Database tiene hoy en día 4 ediciones principales, con un importante nímero de versiones en cada una:

• Express Edition
• Standard Edition One
• Standard Edition
• Enterprise Edition

Todas funcionan en Linux y Windows, si bien la versión básica no puede correr en Unix ni en 64 bits. No sabría deciros qué predomina en el mercado, ya que este es un caso donde el mero hecho de correr en un derivado Unix no garantiza mejor rendimiento. Las versiones Windows tienen una tremenda popularidad, ya que en práctica igualdad de rendimiento en lo que al motor se refiere, tienen una gran ventaja sobre los derivados Unix: Un sistema operativo Windows es, por lo general, más fácil de instalar, usar y mantener, con lo que también es más fácil (y económico) contratar a personal con nociones suficientes para el mundo Microsoft. Por otro lado, también tienen una estructura de licencias completamente distinta y potencialmente menos beneficiosa, con lo que tampoco son siempre la opción a implementar.

Las diferencias entre el producto gratuito (Express Edition) y el destinado a corporaciones (Enterprise Edition) son más que apreciables. Sinceramente he visto de todo, aunque probablemente he visto con un poco más de asiduidad Enterprise Edition corriendo en Linux o Unix. La mayor incidencia sobre el rendimiento la determinan siempre la configuración y la presencia de productos de optimización, y no el sistema operativo sobre el que corren los productos.

Para todo aquel que quiera practicar lo que aquí explicaremos recomiendo la descarga e instalación de la Oracle Database 10g Express Edition, que es gratuita y relativamente sencilla de instalar. Asumiendo que la mayoría de auditores se sienten más cómodos en Windows, emplearemos una instalación para Windows, aunque aquellos que se sientan mejor con Linux pueden optar por este formato. En esencia lo que vamos a ver es independiente (con sus matices, claro) de la plataforma. Recomiendo la instalación de estos dos productos:

• Oracle Database 10g Express Edition (el motor de base de datos)
• Oracle Database 10g Express Client (el software cliente)

Recomiendo a todos los que quieran instalarse estos productos que lean muy detenidamente la documentación. Todo está en la documentación, e insisto que pese a ser la versión más pequeña y simple de Oracle, la puesta en marcha y mantenimiento de la misma no es trivial.

Conectar a Oracle Database

Aunque es posible realizar pentesting en caja negra, siempre es recomendable auditar las contraseñas en caja blanca o gris, ya que el hecho de que no podamos hacer intrusión no implica que las calidades de las claves sean las mejores. En algín momento necesitaremos conectar con la base de datos para ver si podemos hacernos con los hashes de las claves, o directamente para descargarlos y ser analizados. ¿Cómo conectar con Oracle?

• SQL*Plus. Es el producto oficial de Oracle para la línea de mandatos. Para mí, salvo que se vaya a hacer desarrollo, es el más aconsejable.
• Oracle SQL Developer. Es un producto oficial de Oracle, adecuado para desarrolladores, ya que tiene interfaz gráfico y ayudas a la productividad.
• Otros productos comerciales. Casi todos están enfocados al desarrollo y a la utilización gráfica. Posiblemente, PL/SQL Developer sea el más conocido, aunque no es el único.

Mi primera conexión local a Oracle

Una vez instalado podremos conectar vía Application Express (Apex) o vía línea de comandos. Apex está disponible por defecto tras la instalación en http://127.0.0.1:8080/apex/.

En el caso de la edición XE que hemos recomendado, los binarios de SQL*Plus se instalan junto a la base de datos. Suponiendo que estás en Windows:

Durante el proceso de instalación habrás creado contraseñas (es la misma) para las cuentas SYS y SYSTEM. Para probar si todo ha ido bien, así como para hacer ajustes de configuración, trata de conectar mediante la cuenta SYSTEM:

Nótese que SYSTEM es el usuario con el que conectamos, password es la clave de dicho usuario y localhost es la dirección del servidor de Oracle Database.

Conexiones en remoto

Aunque también se puede emplear SQL*Plus, es preciso contar con la definición del listener Oracle para poder hacer la conexión. Esta definición se introduce en el fichero tnsnames.ora, cuyo estándar es el siguiente:

addressname =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(Host = hostname)(Port = port))
)
(CONNECT_DATA =
(SERVICE_NAME = SID)
)
)

Como podéis ver, para conectarse a una base de datos Oracle hacen falta 3 datos: la dirección del servidor, el puerto en el cual el listener está a la escucha y por íltimo el SID (System ID) o identificador de sistema. Veremos más adelante que el SID puede ser adivinado en remoto, y como más de uno podrá imaginar, a veces nos dejanos este fichero abierto al mundo (http://www.google.com/search?&q=%22tnsnames%22+filetype%3Aora, la versión Bing disponible aquí por cortesía de Chema)

Si has instalado Oracle en una máquina virtual o en un servidor, utiliza la documentación para configurar tu fichero tnsnames.ora. Ten presente que SQL*Plus lo va a buscar en determinadas ubicaciones, con lo que si no usas las que recomienda el fabricante (ver documentación) tendrás que crear variables de enterno (ver documentación). Por defecto, XE coloca el fichero en la ruta C:\oraclexe\app\oracle\product\10.2.0\server\NETWORK\ADMIN, siendo sus contenidos los siguientes:

XE =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = nimoy)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = XE)
)
)

EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC_FOR_XE))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)

ORACLR_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC_FOR_XE))
)
(CONNECT_DATA =
(SID = CLRExtProc)
(PRESENTATION = RO)
)
)

A la vista de lo anterior, ya sabéis que mi host se llama nimoy, que mi SID es XE y que el listener admite peticiones en el puerto 1521, que es el puerto por defecto.

Próxima lección

En la próxima lección veremos cómo se audita si el nombre escogido como identificador de sistema (SID), necesario para poder conectar a instancias Oracle, puede ser adivinado remotamente. Esto, como veremos, juega un papel importante en la seguridad de la instalación.

Un saludo,

Aprovecho que estos últimos días han estado movidos en el tema botnets para lanzar al aire una serie de comentarios.

El pasado 16 de Febrero Damballa publicó su top ten de incidentes debidos a botnets criminales, situándose el infame Zeus en primera posición, con un 19% de nuevas víctimas coporativas integradas en su red. No le anda a la zaga Koobface, otro conocido de la escena. Para todos aquellos que queráis profundizar en el tema, pasaos por el blog del amigo Dancho, que suele publicar al respecto con bastante asiduidad. El asunto da para mucho, y podríamos estar años hablando de esta problemática.

El malware provoca daños allá por donde pasa. Da igual que sea en un ordenador doméstico o en un servidor empresarial. El objetivo es el mismo, y aunque ampliamente matizable, al final se trata de apoderarnos de lo que no es nuestro. Aun así, cada ámbito tiene sus ventajas y desventajas, pero en ninguno de los dos casos son sencillas las soluciones. En casa sólo hay que controlar un ordenador, pero, ¿tiene todo el mundo recursos y conocimientos para evitar el malware? No. En el ámbito empresarial tenemos otra importante disyuntiva, complementaria a la anterior. Ahora no se trata de controlar un equipo, sino miles. Pero en esta ocasión si hay recursos y conocimiento (o debería haberlos) para controlarlos. ¿Quiere decir esto que la seguridad corporativa es más fácil que la doméstica? Tampoco.

Me vais a permitir que hoy no me centre en el ámbito doméstico. Sigo creyendo que un buen antivirus para lo conocido y una buena dosis de sentido común, conocimiento y prudencia para lo desconocido pueden mitigar la mayor parte de los problemas, por mucho que se empeñen algunos en reducirlo todo a que en Linux no hay problemas con los troyanos o que con la última versión de Windows 7 tu equipo será infranqueable. Creo que estaremos todos de acuerdo que un buen antivirus y sentido común no parecen suficientes para afrontar la seguridad corporativa.

El asunto no es fácil de digerir. ¿Es la lucha contra el malware un asunto puramente económico? No. Las grandes dotaciones presupuestarias no tienen por qué ser efectivas en este campo. ¿Es un asunto puramente tecnológico? Tampoco, ya que disponer de la mejor tecnología de seguridad tampoco te exime de sufrir problemas. ¿Es entonces un asunto comportamental o humano? Sería injusto reducirlo sólo a eso. ¿De qué estamos hablando entonces? ¿Esto cómo se afronta?

La solución es muy fácil de enunciar sobre el papel. Se trata de disponer, simultáneamente, de dotaciones presupuestarias efectivas para robustecer la seguridad así como invertir en el capital humano para mejorar su concienciación y entrenamiento, con el objetivo gradual de ir reduciendo el rato de incidencias hasta dejarlo en cifras residuales asumibles en cuenta de resultados. Esto que se escribe en dos líneas se traduce al final en millones de euros, no sólo por las pérdidas que provocan los incidentes, sino porque la tecnología y la concienciación cuestan mucho dinero, y amigos míos, aquí no hay fórmulas mágicas que se amolden a todos los escenarios. Ojalá tuviéramos una guía de los diez pasos para invertir y sufrir lo mínimo que fuera apicable a cualquier entorno y bajo cualquier circunstancia, pero como no la tenemos, hay planificar, invertir con inteligencia, implantar controles efectivos y en función a las desviaciones, volver a comenzar. Y todo esto sin olvidar que hagamos lo que hagamos en seguridad, el impacto en la sostenibilidad y rentabilidad del negocio debe ser el mínimo posible.

2009 ha sido, posiblemente, el año de los botnets corporativos. Nada me hace pensar que en 2010 mejore mucho el panorama actual, fundamentalmente porque lo que hemos enunciado antes en nuestro papel ya llevan años haciéndolo los amigos de lo ajeno. Los criminales combinan con eficacia y eficiencia la inversión (no les falta capital), la tecnología (siempre mejoran la aplicación de sus recursos tecnológicos) y la concienciación (reclutan y forman de modo continuo a especialistas). Esta letal combinación de los tres ejes claves de la seguridad es la que hace que esta gentuza que nos roba dia a día propiedad intelectual, dinero en la cuenta del banco, secretos industriales, información financiera reservada y ese largo etcétera de jugosos activos sea hoy en día prácticamente imparable.

Quizás vaya siendo hora de aprender del enemigo, pero que nadie crea que esta será una tarea sencilla.

Un saludo,

Parece que el mes viene calentito en lo que a seguridad de navegadores se refiere. Hace poco estaba en el candelero Internet Explorer, y hoy le toca subir a la palestra a Firefox.

Según veo en este advisory de Secunia, Firefox padece un problema de seguridad de bastante gravedad. En el enlace se apunta al foro de Inmunity Inc donde se puede apreciar que la comunicación inicial data de comienzos de Febrero, momento en que el código de explotación fue incorporado a VulnDisco Pack 9.0, un módulo de la popular suite de pentesting Immunity's Canvas. No hay mucha información al respecto, pero parece que el problema afecta a la versión 3.6 y posiblemente a las anteriores. Según la gente de Inmunity el código necesita cierto trabajo para funcionar, pero por las pruebas que han realizado parece bastante estable. No tengo tampoco constancia de que el código haya sido liberado públicamente, lo cual no me extraña lo más mínimo, ya que la exclusividad es un aliciente para los potenciales compradores de Canvas que perdería su sentido si el código estuviera públicamente disponible.

A este problema hay que añadir otros problemas de extrema gravedad que también podrían propiciar el compromiso de la máquina de las víctimas. Estos problemas (ver enlace) pueden ser solucionados instalando las versiones 3.0.18 o 3.5.8 que fueron liberadas ayer mismo. Aunque parece que estas versiones no resuelven el primero de los problemas que os comento, es más que sensato actualizar para prevenir daños mayores, o al menos para reducir la exposición ante ataques.

Como no podía ser de otro modo, habida cuenta de que la seguridad no está garantizada sin que estos problemas sean resueltos, es de recibo desaconsejar el uso de Mozilla Firefox hasta que dispongáis de versiones actualizadas, especialmente para el primero de los problemas que hemos comentado, sobre el cual no tengo más información y para el que de momento, no hay parche disponible.

Un saludo,

Ahora sí, ahora no. No voy a entrar en este triste asunto de los dichos y desmentidos porque no es el que quiero tratar, si bien esto podría significar el enésimo caso que presenciamos en Internet de donde se lanzan las campanas al vuelo sin tener toda la información en la mano y luego, consecuentemente, se termina metiendo la pata hasta la oreja. Todos los que escribimos podemos incurrir en estos errores, pero parece que no terminamos de aprender que para dar nuestra opinión es conveniente tener en la mano todos los datos, y que las prisas a la hora de vertir opinión no son buenas consejeras.

Hace unos días se determinó que dos de las extensiones existentes en el repositorio AMO (Mozilla Add-ons) de Mozilla, la versión 4.0 de Sothink Web Video Downloader y Master Filer en todas sus versiones, contenían malware. Al final resulta que no, que aunque es cierto que se han detectado indicios confirmados de contaminación en Master Filer, no había problema alguno con Sothink Web Video Downloader. Bien. Ambas vuelven a estar disponibles sin (según Mozilla) riesgos para el usuario.

Hasta aquí poco más. Un incidente, una respuesta ante el incidente, una solución y una comunicación. Pero a la vista de los hechos, no puedo conformarme con darle una palmada en la espalda a Mozilla por su investigación. Creo que es sensato recomendar a todos los usuarios que sean incapaces de analizar el código de las extensiones (las XPI son tristes ficheros comprimidos con contenidos en texto plano) y a todos aquellos que sean incapaces de establecer niveles y fuentes de confianza para las extensiones que utilizan, que no usen extensiones de Firefox. También sería sensato recordar que podemos llenar Mozilla de extensiones, y sin embargo reservar el uso del mismo a todo aquello que no conlleve actividad sensible (banca a distancia, trámites en línea, etc.). ¿Te priva alguien de usar Firefox para tu día a día, y sin embargo tener una instalación limpia de otro navegador con baja incidencia de malware para entrar en tu banco? ¿Te impide alguien dejar la instalación de Firefox tal y como está sin incurrir en instalación de addons? Hay muchas soluciones para diversificar el riesgo, y todos los navegadores son vulnerables, con lo que mal haremos si convertimos Firefox en un huerto de extensiones de las que no tenemos ni la más remota idea sobre su fiabilidad y trayectoria.

Me duele tener que decirlo, pero que haya malware en las extensiones es INTOLERABLE. No sólo por el hecho de que no es la primera vez que pasa, ya que todos recordaremos los tristes acontecimientos acaecidos en 2008 cuando se distribuyó un fichero de lenguaje vietnamita con regalito sorpresa, sino porque estos acontecimientos minan la confianza de los usuarios en algo tan crítico como la herramienta que usamos para acceder a la Red. En este caso en particular, hechos como el sucedido generan dudas más que lógicas sobre los procesos de calidad que Mozilla aplica a las extensiones que luego distribuye, procesos que a la vista de lo ocurrido, no parecen los mejores y que a mí no terminan de inspirarme confianza por muy buenas intenciones que tenga el equipo de desarrollo al completo.

Podemos evocar trescientos mil argumentos para justificar que no pasa nada porque se cuele malware de vez en cuando en los complementos de Firefox. Que si es gratis, que si es software libre, que si somos una comunidad cojonuda y aquí hacemos lo que podemos, y todo lo que queráis, pero a mí ningún argumento me convence. Podría entender que a Mozilla le colasen binarios infectados empaquetados a mala leche y ofuscados hasta la saciedad, y que porque no haya gente que haga reverse engineering decente les metan un gol. Puedo entender que tras una intrusión coloquen binarios modificados en los servidores de descarga y que durante un tiempo pasen inadvertidos. Pero con las extensiones, no, lo siento pero no. Si no tienes medios para analizarlas como es debido para asegurar el máximo nivel de calidad, no las sirvas. Y si quieres servirlas traslada a los usuarios de una manera CLARA que que el riesgo de infección por adulteración de las mismas existe, que hay que tener una mínima consciencia de la procedencia y naturalez de lo que se instala, y que cada cual elija si instalar o no.

Hagamos lo posible por que los usuarios asemejen los repositorios de Mozilla a cualquier otro de software. Es lo mismo bajarse una extensión que un programa freeware de la página de un desarrollador cualquiera, ya que el riesgo de contaminación siempre estará presente, con lo que creo interesante trasladar a los usuarios que Mozilla.com no es un Olimpo donde nunca ocurre nada, y que como cualquier otra fuente de software, las incidencias pueden ocurrir y están a la orden del día. Nadie está a salvo.

Es obvio que a tenor de los casos documentados el riesgo es pequeño, ya que son casos puntuales, pero eso no es óbice para no dejar claro que instalar extensiones de Firefox adulteradas puede conllevar a la contaminación de equipos. Esto es un hecho, y en vez de perder el tiempo en rebatirlo con tonterías sobre idílicas comunidades, quizás deberíamos perderlo en explicarle al usuario que hay maneras de analizar lo que se utiliza, y que si no se sabe o no se tienen medios para el análisis técnico, hay que aprender establecer nuestros niveles de confianza, basándonos en la opinión de otros usuarios, en la de conocidos y allegados con nociones y experiencia superiores a las nuestras, en los antecedentes, en la trayectoria de los desarrolladores, en los procesos de calidad que se ejecuten, en la opinión experta de analistas y en un sinfín de parámetros. Y si con todo eso no somos capaces o albergamos dudas, señores, lo que hay que hacer es no usar ese software y buscar una alternativa de la que sí podamos fiarnos. Es así de simple. Tarde o temprano nos acabaremos fiando porque no nos queda más remedio (no es sensato ni productivo analizar todo lo que ejecutamos), así que pongamos la carne en el asador para ver cuál es la mejor manera de poder fiarnos incurriendo en los mínimos riesgos posibles.

Un saludo,

Definitivamente 2010 no ha empezado con buen pie para Internet Explorer. Si hace poco vivía un 0-day con importantes consecuencias para la seguridad, ahora tenemos en lo alto de la mesa un problema moderadamente crítico (definitivamente menos relevante que el anterior) que sin embargo vuelve a requerir por parte de los usuarios una atención especial.

Los amigos de Core Security descubrieron tiempo atrás un par de problemas (uno tiene que ver con la etiqueta de objetos dinamicos y el otro con URLMON) que ahora han hecho públicos, mediante los cuales un atacante podría extraer información sensible almacenada en ficheros locales de un sistema Windows siempre y cuando el usuario emplease una versión vulnerable y visitase una página especialmente conformada. No se necesita intervención alguna del usuario mas allá de visitar la pagina maliciosa, si bien este problema no permite (afortunadamente) comprometer el sistema en su totalidad como ocurriera con el exploit Aurora.

Quizás sea reseñable indicar que estas vulnerabilidades son, en palabras de los descubridores, una variación de otros problemas descubiertos anteriormente por Core (CoreLabs Security Advisories CORE-2008-0103 y CORE-2008-0826), lo que quizás sirva para reavivar el eterno debate sobre si los parches que ofrecen los fabricantes solventan siempre los problemas de raíz o si por el contrario, son paños de agua caliente para salir del paso.

No hay parche disponible para estas vulnerabilidades y Microsoft ha documentado el correspondiente Security Advisory en el que se comentan los posibles medidas de mitigación y donde la compañia deja entrever que no descarta publicar un parche fuera de ciclo (out-of-band) al respecto.

¿Es mi versión de Internet Explorer vulnerable?

De acuerdo a la información liberada por los descubridores, la relación de versiones vulnerable es la que sigue:

• Internet Explorer 5.01 SP4 corriendo en Windows 2000 SP4
• Internet Explorer 6 SP1 corriendo en Windows 2000 SP4
• Internet Explorer 6 SP2 corriendo en Windows XP SP2
• Internet Explorer 6 SP2 corriendo en Windows XP SP3
• Internet Explorer 7 corriendo en Windows XP SP2
• Internet Explorer 7 corriendo en Windows XP SP3
• Internet Explorer 7 corriendo en Windows Vista SP1
• Internet Explorer 7 corriendo en Windows Vista SP2
• Internet Explorer 7 corriendo en Windows Server 2003 SP2 si el modo protegido está desactivado y no se usa la configuración mejorada de seguridad
• Internet Explorer 7 corriendo en Windows Server 2008 si el modo protegido está desactivado y no se usa la configuración mejorada de seguridad
• Internet Explorer 8 corriendo en Windows XP SP2
• Internet Explorer 8 corriendo en Windows XP SP3
• Internet Explorer 8 corriendo en Windows Vista SP1 si el modo protegido está desactivado
• Internet Explorer 8 corriendo en Windows Vista SP2 si el modo protegido está desactivado
• Internet Explorer 8 corriendo en Windows 7 si el modo protegido está desactivado
• Internet Explorer 8 corriendo en Windows Server 2003 SP2 si el modo protegido está desactivado y no se usa la configuración mejorada de seguridad
• Internet Explorer 8 corriendo en Windows Server 2008 R2 si el modo protegido está desactivado y no se usa la configuración mejorada de seguridad

No son vulnerables las siguientes configuraciones:

• Internet Explorer 7 corriendo en Windows Vista, Windows Server 2003 o Windows 7 si el modo protegido está activado
• Internet Explorer 8 corriendo en Windows Vista o Windows Server 2003 si el modo protegido está activado
• Internet Explorer 8 corriendo en Windows Server 2003 si el modo protegido está activado
• Internet Explorer 8 corriendo en Windows 7 o Windows Server 2008 R2 si el modo protegido está activado

Lo que debes hacer si usas Internet Explorer

Lo primero es leete el Microsoft Security Advisory (980088): http://www.microsoft.com/technet/security/advisory/980088.mspx.

Una vez te lo hayas leído puedes aplicar alguna de las siguientes acciones de mitigación (no es necesario ejecutarlas todas)

1. Asegúrate de ejecutar Internet Explorer con el modo protegido activado, si es que tu sistema operativo lo permite y si entiendes las limitaciones que se pueden producir al usarlo (http://blogs.msdn.com/ie/archive/2007/04/04/protected-mode-for-ie7-in-windows-vista-is-it-on-or-off.aspx). Como probablemente te suene a chino esto del modo protegido, puedes documentarte en http://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspx. Este modo viene activado por defecto en la zona de seguridad de Internet sólo en Windows Vista, Windows 7 y Windows Server 2008.
2. Emplea la funcionalidad Network Protocol Lockdown del navegador. Puedes activarlo y desactivarlo en http://support.microsoft.com/kb/980088.
3. En la configuración por zonas, establece el nivel de seguridad tanto para Internet como Intranet en ALTO, con lo que se impedirá la ejecucion de scripts y controles ActiveX. Nótese que esto puede tener implicaciones en ciertas aplicaciones Web que usen estos componentes.
4. Desactiva el scripting activo para las zonas Internet e Intranet Local manualmente, estableciendo una configuración de las mismas de tipo personalizado.

Si por alguna razón no comprendes el trasfondo de estas posibles soluciones (lo cual no me extrañaría lo más mínimo) o si tienes dudas sobre su utilización, lo más sensato, hasta que se publique un parche, es no usar Internet Explorer a la hora de visitar páginas que no sean de nuestra más exclusiva confianza. Un navegador alternativo es recomendable en estos casos.

Un saludo,

Hará un tiempo me compré un router Linksys WRT54G cuya clave de administración desconocía. Hoy he estado echando un vistacito ya que quería resetearlo para añadir unos NAT, pero finalmente no ha hecho falta.

Me sorprende que este router, tan afamado desde el punto de vista de conectividad, tenga una configuración de seguridad tan mala. Intentaré actualizar el firmware en cuanto pueda, a ver si en revisiones posteriores este problema se ha corregido.

FTP por defecto

El origen del problema. El router admite conexiones entrantes de FTP con indiferencia del usuario y la clave que introduzcamos, lo cual ya es de por sí flagrante.

Os puedo asegurar que no tengo ese usuario creado en el router :)

Una vez dentro, podemos listar los contenidos a los que tenemos acceso:

Nos bajamos a local el fichero igwpricf.dat:

Os podéis bajar también el fichero nvram.cfg, que trae información jugosa sobre la configuración del router (así como la clave WLAN). Cuando terminéis, cerrad la sesión FTP.

Ejecutamos un strings para obtener las cadenas de texto del fichero, y sorpresa:

Donde Aadmin es el usuario administrador, c******** es la clave del administrador, Simpleminds es el nombre del BSSID y d******** es la clave precompartida WLAN. Lamentable.

El firmware instalado (se puede recuperar en http://IP_DEL_ROUTER/sysinfo.htm) en este modelo es v7.00.1 (11g RF Firmware Version:4.1.2.56SP4) y aparentemente, está prácticamente en configuración de fábrica salvo la definición WLAN ¿Alguien que tenga este modelo con un firmware superior me puede confirmar si la chapuza del FTP está solventada? (mejor no pregunto si los ficheros de configuración están cifrados en vez de en texto plano)

Un saludo,

Os traslado un mensaje que he recibido la semana pasado de la organización de este interesante evento. Creo que bien merece compartirlo con los posibles interesados.

Resta menos de un mes para que comience el evento internacional sobre eConfianza Trust in the Information Society, que se celebrará los días 10 y 11 de febrero en León, con motivo de la presidencia de España en la Unión Europea.

Los conferenciantes de distintas nacionalidades europeas, durante los dos días de duración del evento, intervendrán a través de sesiones de alto nivel estratégico, tratando cuestiones y temas de ámbito político y social.

Programa

Pueden consultar el Programa del Evento a través de los siguientes enlaces:

• 10 de febrero: http://trustworthyict.inteco.es/index.php/es/programa/programa-10-febrero
• 11 de febrero: http://trustworthyict.inteco.es/index.php/es/programa/programa-11-febrero

Si lo desean, pueden descargarse el programa en formato pdf.

Inscripciones

Pueden inscribirse al evento a través de la página web, en el apartado de inscripción, donde encontrarán toda la información relativa a la asistencia al mismo.

Organización del evento

Email: trustworthyict@cert.inteco.es
Teléfono: 34 987 877 189 Extensiones: 5106 y 4007
Web: https://trustworthyict.inteco.es
www.inteco.es

Un saludo,