martes, 31 de enero de 2012

Elevación de privilegios en sudo (en multitud de distribuciones)

Se ha descubierto un problema de seguridad en sudo que permite a cualquier atacante local elevar privilegios y convertirse en root. El fallo afecta a casi todas las distribuciones basadas en el kernel Linux y además de BSD, Mac OS X, etc.

Sudo es una herramienta de administración, utilizada en muchas de las distribuciones basadas en el kernel Linux, que permite delegar privilegios (normalmente de root) a determinados usuarios y para ciertos comandos en concreto. Ello posibilita, por ejemplo, que determinado grupo de usuarios tenga acceso a ciertas herramientas, con privilegios de administrador, pero de forma controlada y segura.

El fallo, descubierto por joernchen del Phenoelit Groupoernchen, se encuentra en un error de formato de cadena en la función "sudo_debug de sudo.c", a la hora de procesar el nombre del programa que se le pasa por parámetro.

Para aprovechar la vulnerabilidad (con  CVE 2012-0809), el atacante debe, por ejemplo, realizar un enlace a nivel de sistema de fichero (ln) del binario sudo hacia un fichero con un nombre manipulado con caracteres especiales de cadena (por ejemplo "%n"). Al ejecutar ese nuevo enlace creado, se podrá ejecutar código con privilegios de root.

El fallo se ha confirmado en las versiones 1.8.x, y para solucionarlo, es necesario actualizar a 1.8.3.p2.

Este fallo es heredado por multitud de distribuciones y sistemas operativos que utilizan sudo. Fue notificado el día 24 de enero, y el día 30 ya se publicó un parche. Corren especial peligro las máquinas compartidas entre usuarios. También es posible que sea usado en un futuro para la elevación y "liberación" de dispositivos Android, por ejemplo.

Más información:

Vulnerabilidad:


Laboratorio Hispasec

lunes, 30 de enero de 2012

Denegación de servicio en Samba

Se ha anunciado una vulnerabilidad en Samba que podría permitir a un atacante provocar una denegación de servicio.

Samba es una implementación libre del protocolo de compartición de archivos Microsoft para sistemas de UNIX. De esta manera equipos con sistemas GNU/Linux, MacOS o Unix en general pueden formar parte de la red de directorios compartidos de Windows.

La vulnerabilidad, descubierta por Youzhong Yang e Ira Cooper, está causada por un error en el demonio smbd al no liberar memoria cuando maneja solicitudes de conexión, incluso si estas no tienen éxito debido a una autenticación incorrecta.

Un atacante en red local podría explotar esta vulnerabilidad para agotar la memoria y aumentar el uso de la CPU del sistema, causando una denegación de servicio mediante el envío de un gran número de solicitudes de conexión.

La vulnerabilidad, identificada como CVE-2012-0817, afecta a las versiones de Samba 3.6.0 hasta 3.6.2.

Desde la página oficial de Samba se puede descargar la versión 3.6.3, así como parches para otras versiones que corrigen la vulnerabilidad explicada anteriormente: http://www.samba.org/samba/security/

Más información:

CVE-2012-0817 - Memory leak/Denial of Service

Samba 3.6.3 Available for Download


Juan José Ruiz


domingo, 29 de enero de 2012

Microsoft, ¿No quedamos en dejar de utilizar MD5? (y II)

Describíamos en la entrega anterior un ataque de elevación de "serie" en Windows cuyo mayor obstáculo era perpetrar un ataque ataque "second-preimage" contra MD5. Veamos por qué eso no es tan complicado.

Esquema de una operación MD5.
Fuente: Wikipedia
La función de hash criptográfico MD5 (Message-Digest algorithm 5) lleva años mostrando signos de debilidad, inadecuado para los tiempos que corren. Si bien se ha llevado varios varapalos desde su creación, hace tiempo recibió lo que se pudo considerar su golpe de gracia: se podían crear arbitrariamente dos flujos de datos que resulten en el mismo hash o firma.

Desde su diseño en 1991 por Ron Rivest (uno de los implementadores de la criptografía pública), MD5 ha sido tomado prácticamente como estándar de facto para control de hash para firma de ficheros. Por diseño, convierte cualquier flujo de datos de cualquier tamaño en una serie de 128 bits diferente. Esto permite crear una "firma" corta que identifique a un archivo o flujo de datos. En la teoría, reduce un conjunto infinito a otro finito de 2 elevado a 128, con lo que las colisiones serían siempre posibles, pero en la práctica esta cantidad ha sido suficiente.

Desde 1996 ya se vienen recomendado otros algoritmos que han demostrado mejores capacidades (como el SHA en sus distintas variantes) pero su implantación es tan fuerte que, como muchos otros estándares en informática, descartarlo es un proceso lento y a veces incluso "doloroso".

El enemigo natural de estos algoritmos son las colisiones. Es decir, que varios ficheros tengan una misma firma identificadora. Esto sería como si dos personas tuvieran el mismo número de DNI o tarjeta de la seguridad social: podrían hacerse pasar uno por el otro. La firma MD5 también es usada en algunos casos para realizar hashes que a posteriori son firmados con claves privadas, por lo que su debilidad también salpicaría a la criptografía pública. En 2004 se consiguió crear dos certificados  X.509 distintos con igual hash MD5.

Además de las colisiones, MD5 tiene otros problemas. Para una firma o hash criptográfico, por definición, debe ser matemáticamente muy complicado realizar el proceso contrario: calcular los datos que produjeron el hash. Así, por esta razón, muchos programas almacenan el hash MD5 de las contraseñas de usuarios en las bases de datos. Hace algunos años se popularizaron las tablas rainbow con información preprocesada sobre hashes MD5. Esto, en teoría, permite a alguien que tenga acceso a esos hashes, realizar el proceso inverso en tiempo razonable, o sea: pasar del hash MD5 a la palabra que lo generó. Se ha popularizado como método eficaz de "crackeo" para contraseñas de este tipo, con lo que el almacenamiento de credenciales en este formato también se considera ya inseguro.

En verano de 2005 se dio un caso realmente curioso. Un australiano consiguió anular una multa de tráfico ante la imposibilidad de las autoridades de tráfico de demostrar fehacientemente que la imagen registrada por un radar no había sido alterada. El sujeto circulaba por una carretera que estaba siendo controlada con un radar. Cuando fue cazado y su coche "fotografiado", el abogado que representaba al amonestado recurrió la denuncia, argumentando que no se había probado que la imagen obtenida por la cámara asociada al radar no hubiese sido modificada de ninguna forma. Las autoridades australianas de tráfico respondieron que se utilizaba el algoritmo MD5 para obtener el hash de las imágenes obtenidas. No encontraron a ningún perito que demostrase ante el tribunal la validez de dicho algoritmo, y por tanto se libró de la multa.

Marc Stevens, Arjen Lenstra, y Benne de Weger le dieron el tiro de gracia en 2008. Diseñaron un método por el que, añadiendo un puñado de bytes a un archivo, pueden hacer que su firma, su hash MD5, sea idéntico a otro fichero arbitrario. La diferencia en este caso es que las colisiones pueden ser elegidas, provocadas sobre dos ficheros cualesquiera. Lo consiguieron con una sola máquina en menos de dos días. Un tiempo más que razonable. Ese mismo año, investigadores consiguen hacer que cualquier certificado SSL parezca válido, usando la firma MD5. Usaron la potencia de 200 consolas PlayStation3 para conseguir su objetivo.

Todas estas son pequeñas razones por las que nadie debería usar MD5 para asuntos medianamente serios. Y menos Microsoft.

Más información:

17/08/2005 Utilizar MD5 para recurrir las multas de tráfico

High-Speed Collisions

Investigadores consiguen hacer que cualquier certificado SSL parezca válido


Sergio de los Santos
Twitter: @ssantosv

sábado, 28 de enero de 2012

Ejecución remota de comandos en Apache Struts

Se han anunciado cuatro vulnerabilidades en Apache Struts (versiones 2.0.0 - 2.3.1.1), que podrían permitir a un atacante remoto ejecutar código Java.

Struts es un framework de código abierto para el desarrollo de aplicaciones Web Java EE bajo el patrón de arquitectura de software Modelo-Vista-Controlador (MVC). Anteriormente se desarrollaba como parte del proyecto Jakarta de la Apache Software Foundation, pero actualmente es un proyecto independiente conocido como Apache Struts.

Apache Struts2 utiliza XWork OpenSymphony y bibliotecas OGNL (Object-Graph Navigation Language). En XWork, existe por defecto el parámetro 'ParametersInterceptor' que permite hacer uso de las expresiones OGNL.

A través de OGNL se utilizan funciones Java estáticas. Esto podría ser usado por un atacante remoto para ejecutar código arbitrario a través de un valor de 'ParametersInterceptor' especialmente codificado en OGNL.

Este fallo se ha solucionado en la versión 2.3.1.2 y se le ha asignado el identificador CVE-2011-3923.

Más información:

Security Bulletins:

Fix:

Mailing list:


Víctor Antonio Torre


viernes, 27 de enero de 2012

Microsoft, ¿No quedamos en dejar de utilizar MD5? (I)

Cesar Cerrudo ha presentado un método que podría ser usado para elevar privilegios en Windows de forma relativamente "sencilla". Solo es necesario realizar un ataque "second-preimage". O sea, a partir de un fichero de sistema, crear otro con un mismo hash MD5. Veamos exactamente cómo funciona.

Instalaciones en Windows

En los últimos sistemas operativos de Microsoft, el directorio C:\Windows\Installer\ contiene ficheros de instalación de Windows (.msi y .msp). Ahí encontrarás los instaladores de los programas que utilizas en tu sistema. Los nombres son aleatorios.


Ejecutando como usuario normal estos ficheros, comenzará la (re)instalación de los programas... Se puede comprobar como ciertos programas se comportan diferente cuando son lanzados desde esa ruta o cuando son lanzados desde cualquier otra. En algunos paquetes oficiales de Microsoft, el intento de elevación (UAC) aparecerá en diferentes momentos de la instalación y en otros, no aparecerá.

Comprobarlo es sencillo. Basta con ejecutar como usuario cualquier msi mientras se aloja en C:\Windows\Installer\. Luego, lo copiamos en otra localización (por ejemplo F: en la imagen) y lo intentamos lanzar.


Puesto que ocurre con pocos paquetes y el usuario no tiene permisos para escribir ni modificar C:\Windows\Installer\, esto queda como un comportamiento "curioso". Lo peor viene cuando se estudia qué ocurre entre bambalinas en el sistema al lanzar alguno de estos instaladores oficiales de Microsoft. En el ejemplo, he probado con Microsoft Office Publisher MUI (English) 2007.

Parece que este y otros paquetes de este tipo elevan privilegios automáticamente durante unos momentos. Como se aprecia en la imagen, se crea un fichero del tipo Hx#cuatro números aleatorios en hexadecimal#.tmp en el directorio %temp% (o sea, c:\users\sergio\appdata\local\temp en el ejemplo) y además es lanzado por SYSTEM.



Un posible ataque

Si conseguimos recuperar ese fichero temporal (sólo está accesible unos instantes) comprobamos que se trata de una instancia de la librería HXDS.dll. En la imagen se comprueba cómo lo he hecho.



Esta librería la carga msiexec.exe (el instalador de ficheros .msi) cada vez que se lanza un proceso de instalación. A veces la lanza como el usuario y a veces... como SYSTEM, y aquí está el problema. El directorio temporal de cada usuario puede ser modificado por él mismo (tiene permisos totales sobre él). Así que el usuario podría sustituir ese fichero temporal por otro código y se lanzaría como SYSTEM cuando se ejecutase un MSI alojado en C:\Windows\Installer. Ya tenemos la elevación.

La restricción al ataque

Pero en teoría Microsoft lo tiene en cuenta y pone una pequeña restricción: Msiexec.exe en realidad conoce el hash MD5 de HXDS.dll (lo almacena temporalmente en c:\windows\installer\) y lo compara con la copia de la instancia de la DLL creada en el temporal. Si no coincide, no lanzará el instalador y por tanto, la DLL.

El posible ataque

Si se sustituye la DLL oficial con un ejecutable cuyo hash coincida con el hash MD5 que espera msiexec.exe (en principio en mi sistema es 9e7370cc3d6a43942433f85d0e2bbdd8), entonces el ataque será posible y la elevación viable (se ejecutará como SYSTEM si lanzamos el MSI desde c:\windows\installer como usuario).

Por tanto el éxito queda supeditado la dificultad de encontrar un ataque llamado "second-preimage". Lo que comúnmente se entiende por una colisión MD5 deseada entre dos flujos de datos. Quizás para atacantes "de a pie" no sea posible, pero para otras organizaciones de mayor envergadura, es totalmente viable, puesto que MD5 está roto desde hace tiempo. Si, el mayor problema para el atacante es realizar un ataque second preimage al MD5, solo es necesaria cierta cantidad de tiempo y capacidad de cómputo.

Hay que tener en cuenta que no ocurre con todos los paquetes ejecutables (no en todos crea la copia de la DLL en el directorio temporal y la lanza como SYSTEM). Sólo lo he conseguido por ahora con paquetes de Microsoft Office, que ejecutan varios procesos de msiexec.exe como SYSTEM.

Microsoft, ¿No quedamos en dejar de utilizar MD5?

Ahora que se cumplen 10 años de la Trustworthy Computing, hay que recordar que MD5 está "prohibido" en Microsoft dentro de su Security Development Lifecycle desde 2005. No se deben usar funciones criptográficas consideradas débiles... y no se nos ocurre una función más débil que MD5 como control para restringir una ejecución de código. Veremos por qué en la siguiente entrega.

Más información:

A free Windows Vulnerability for the NSA


Sergio de los Santos
Twitter: @ssantosv

jueves, 26 de enero de 2012

Grave vulnerabilidad en PCAnywhere (corregida cinco meses después)

Se ha publicado una vulnerabilidad en PCAnywhere que permite ejecutar código en el sistema donde esté corriendo la aplicación. Esto es especialmente grave puesto que la aplicación, por diseño, está pensada para ser accesible en remoto.

PCAnywhere es una popular aplicación comercial de control remoto creada por la empresa Symantec que permite a los usuarios administrar un ordenador a distancia. Esto es especialmente útil para situaciones donde el acceso físico no sea posible, para tareas de soporte en remoto, etc., por lo que suele estar accesible en redes abiertas. En el servidor, el proceso escucha por defecto en el puerto TCP 5631.

En el servidor, los procesos de conexión los maneja el componente awhost32. En este proceso existe un fallo a la hora de validar o filtrar los datos de acceso introducidos por el usuario, lo que permite un desbordamiento de memoria intermedia. Si se envían peticiones especialmente manipuladas, se podría ejecutar código arbitrario en el equipo con privilegios de SYSTEM (los máximos en Windows).

Symantec conocía el problema desde agosto de 2011, aunque a pesar de su gravedad se ha hecho público ahora. Fue reportado de forma privada a través de ZDI, y ahora han coordinado una solución. Aunque en teoría el gravísimo problema fuese conocido solo por el descubridor, ZDI (que "compró" la vulnerabilidad al descubridor) y por Symantec, esto siempre conlleva riesgos. Durante cinco meses, se puede desde filtrar la información hasta ser descubierta por cualquier otro investigador de forma independiente, y quizás con otras intenciones.

El fallo recuerda al que sufrió VNC en mayo de 2006. No se trataba entonces de un problema de desbordamiento de memoria intermedia, pero permitía eludir la autenticación en el servidor. Aun hoy se pueden encontrar muchos servidores con versiones no corregidas de este programa.

Los administradores de PCAnywhere que no hayan modificado el puerto por defecto, restringido el rango de direcciones que pueden conectarse, protegido el proceso con DEP, ASLR, o tomado otras consideraciones de seguridad básicas, tienen un grave problema hasta que actualicen. El fallo ya ha sido corregido y se recomienda actualizar a la última versión disponible lo antes posible.

Más información:

Security Advisories Relating to Symantec Products - Symantec pcAnywhere Remote Code Execution, Local Access File Tampering

Symantec PCAnywhere awhost32 Remote Code Execution Vulnerability


Daniel Vaca

Sergio de los Santos
Twitter: @ssantosv

miércoles, 25 de enero de 2012

Elevación de privilegios en el kernel Linux y un exploit interesante

El pasado día 17 de enero, Linus Torvalds hizo un commit para corregir una elevación de privilegios en el kernel Linux 2.6 (CVE-2012-0056). El fallo fue descubierto por Jüri Aedla y según comenta Torvalds en el propio parche, se debe a una incorrecta comprobación de privilegios al abrir el '/proc/#pid#/mem' de un proceso.


Este error no pasó desapercibido a Jason A. Donenfeld que ha escrito y publicado un interesante exploit. Lo ha bautizado como 'Mempodipper'.

Donenfeld estudió en detalle el proceso de explotación. De partida se encontró con que efectivamente la comprobación de permisos era débil y además, que la protección contra escritura en el espacio de memoria del proceso fue eliminada del código del kernel. De hecho puede leerse en el comentario del commit correspondiente, que se eliminaba la restricción porque no se consideraba un peligro la escritura en /proc/#pid#/mem.

Esto hace virtualmente vulnerables a los núcleos con versión 2.6.39 o superior.

Cómo funciona

Cuando se abre /proc/#pid#/mem se usa la función 'mem_open'. Dicha función almacena el 'self_exec_id' correspondiente al proceso que solicita la apertura. Esto se hace para comprobar posteriormente si son suficientes privilegios cuando se efectúan operaciones de lectura o escritura sobre el descriptor de fichero obtenido.

static int mem_open(struct inode* inode, struct file* file)
{
    file->private_data = (void*)((long)current->self_exec_id);

En el caso de la operación de escritura se hace la comprobación del 'self_exec_id' además de llamar a 'check_mem_permission'. En teoría, para escribir en /proc/#pid#/mem, o se es el mismo proceso #pid# o el proceso tiene ciertos permisos especiales relacionados con ptrace.

static ssize_t mem_write(struct file * file, const char __user *buf,
             size_t count, loff_t *ppos)
{
...
...

Se llama a 'check_mem_permission' y si 'mm' vuelve con error no se efectúa la operación:

mm = check_mem_permission(task);
    copied = PTR_ERR(mm);
    if (IS_ERR(mm))
        goto out_free;
                       
'check_mem_permission' simplemente llama a '__check_mem_permission' y como se observa dentro de su código efectúa la comprobación "task ==current":

static struct mm_struct *__check_mem_permission(struct task_struct *task)
{
    struct mm_struct *mm;

    mm = get_task_mm(task);
    if (!mm)
        return ERR_PTR(-EINVAL);
        
    if (task == current)
        return mm;
    
    ...
    ...

Si no coinciden devuelve error. Luego debe ser el mismo proceso el que escriba en su propia memoria y si queremos elevar privilegios necesitaríamos un proceso con 'suid'.

Primera aproximación al exploit

Donenfeld se figuró cómo hacer esto:

$ su "yeeeee haw I am a cowboy"
Unknown id: yeeeee haw I am a cowboy

Cualquier cosa que se escriba pasa por la memoria del proceso creado por 'su' (que posee 'suid'). Parecia obvio qué hacer:

Abrimos '/proc/self/mem' y obtenemos su descriptor de archivo. Ejecutamos 'dup2' para multiplexarlo con 'stderr'. Escribimos nuestro shellcode en él y ejecutando posteriormente con exec obtendríamos root... pero no.

Esto no iba a funcionar debido a que aun queda otra restricción más:

if (file->private_data != (void *)((long)current->self_exec_id))
        goto out_mm;

El 'self_exec_id' del proceso que va a ejecutar la escritura 'exec' ha de ser el mismo que abrió originalmente '/proc/#pid#/mem', recordad más arriba cuando se llama a 'mem_open'.

¿Por qué ha cambiado 'self_exec_id'?

Cuando se llama a 'exec' el 'self_exec_id', es aumentado en 1 impidiendo que esto ocurra:

void setup_new_exec(struct linux_binprm * bprm)
{
    ...
    ...
    current->self_exec_id++;

Resumiendo. No podemos abrir el '/proc/#pid#/mem' de un proceso cualquiera, hacer 'dup2' con 'stderr' y luego hacer 'exec' de un proceso con 'suid' para escribir allí, ya que al hacer 'exec' no van a coincidir los 'self_exec_id'.

Donenfeld solucionó esto de manera sencilla pero ingeniosa, muy ingeniosa.

El exploit

Se hace 'fork' de un proceso y en este hijo se ejecuta 'exec' a un nuevo proceso. De este modo el 'self_exec_id', que se ha heredado del padre, ahora tiene un valor de +1 con respecto al padre.

Ahora hacemos que el padre ejecute 'exec' sobre un proceso 'suid' que va a escribir nuestro shellcode. En este momento, al ejecutar 'exec' en el padre su 'self_exec_id' acaba de aumentar a +1 coincidiendo con el del hijo.

Mientras tanto en el proceso 'exec' que ha llamado el hijo se obtiene, al abrir, el descriptor del '/proc/#parent_pid#/mem'; y es posible abrirlo porque no existe restricción en la operación de apertura. Es decir, no van a ser comprobados los privilegios del 'exec' que ha creado el hijo.

En este momento tenemos un 'exec' del padre con un proceso 'suid' dispuesto a escribir el shellcode. Un 'exec' del hijo con un descriptor del '/proc/#pid#/mem' del padre y la salida 'stderr' acoplada a ese descriptor (llamada a 'dup2') y lo más importante, tenemos los 'self_exec_id' igualados por lo tanto la restricción ha sido evadida.

Solo queda que el hijo pase el descriptor al padre y éste va a escribir el shellcode allí ya que cuando llame a 'mem_write', como hemos dicho, las comprobaciones van a ser correctas.

Pero aún queda más, averiguar "dónde" se debe escribir en memoria para poder ejecutar de manera exitosa el shellcode. Se necesita una dirección fija de memoria, algo que podría ser complicado si se usa ASLR, pero Donenfeld observó que la mayoría de binarios 'su' de las distribuciones no están compilados con 'PIE'(Position-independent executable)

Podemos observarlo si hacemos:

$ readelf -h /bin/su | grep Type
  Type:                              EXEC (Executable file)

Como el mismo Donenfeld apunta, si el 'Type' fuera 'DYN' entonces si podría protegerse con ASLR debido a que el ejecutable permitiría ser reubicado en distintas posiciones de memoria. Al no ser el caso el desplazamiento en memoria siempre va a ser el mismo.

Buscando Donenfeld obtuvo la dirección 0x402178, correspondiente a una llamada a 'exit@plt'. Tan solo tenía que escribir en 0x402178 menos la longitud de la cadena 'Unknown id: ' y su shellcode se ejecutaría.

En definitiva, un exploit más interesante que la propia vulnerabilidad que explota y una muestra de ingenio por parte de Donenfeld al conseguir la explotación de la forma que hemos visto.

Más información:

Parche de Linus Torvalds

Commit de la eliminación de la protección de escritura

* Linux Local Privilege Escalation via SUID /proc/pid/mem Write


David García


martes, 24 de enero de 2012

Denegación de servicio en Asterisk a través de SRTP

Se ha solucionado un fallo en la implementación de SRTP (Secure Real-time Transport Protocol) que podría permitir a un atacante provocar una denegación de servicio en Asterisk.

Asterisk es una implementación de una central telefónica (PBX) de código abierto. Como cualquier PBX, se pueden conectar un número determinado de teléfonos para hacer llamadas entre sí e incluso conectarlos a un proveedor de VoIP para realizar comunicaciones con el exterior. Asterisk es ampliamente usado e incluye un gran número de interesantes características: buzón de voz, conferencias, IVR, distribución automática de llamadas, etc. Además el software creado por Digium está disponible para plataformas Linux, BSD, MacOS X, Solaris y Microsoft Windows.

SRTP es la implementación segura (que proporciona cifrado e integridad) de RTP (Real-time Transport Protocol) usado principalmente para el envío de flujo multimedia.

El fallo permite a un atacante remoto provocar una denegación de servicio en el servidor. Para conseguirlo debe crear una conexión de vídeo segura y que el servidor no tenga soporte de vídeo activo, pero sí cargado el módulo (res_srtp) de SRTP.

A esta vulnerabilidad se le ha asignado el identificador CVE-2012-0885, y se encuentra solucionada en las versiones 1.8.8.2 y 10.0.1.

Más información:

Security Advisory:

Fix:


Victor Antonio Torre

lunes, 23 de enero de 2012

La seguridad, mi abuela... y billetes de 5 pesetas

Mi padre fue obligado a hacer el servicio militar en Madrid, partiendo desde un pequeño pueblo de Málaga. Cuando era niño, mi abuela paterna me contó cómo le hacía llegar una pequeña cantidad de dinero a su hijo mientras él sufría "la mili" de los 60. Sus métodos, aunque simples y lógicos, me sorprendieron entonces. Hoy, en la era digital, lo que sorprende es que no se respeten las más mínimas medidas de seguridad con nuestros datos.

 
Eran los 60. El servicio militar duraba casi dos años y la distancia entre el pueblo y Madrid era de más de 500 kilómetros. En la mili, a mi padre le pagan 35 pesetas mensuales (de las que se le descontaban siempre gastos en desperfectos ocasionados por otros en ventanas, mantas robadas...). Mi abuela, con enorme esfuerzo e ilusión, enviaba a mi padre desde el pueblo un billete de 5 pesetas cada semana con un método muy sencillo: Envolvía el billete entre hojas de papel escritas (a veces con una carta real, otras con simples garabatos) y metía todo en un sobre. No usaba el buzón del pueblo, sino que acudía directamente a la pequeña oficina de correos principal. De vez en cuando, cambiaba el remitente. Aunque suene simple, son métodos que encierran un profundo conocimiento del sistema de correos, de las amenazas y sobre todo, que intenta mitigar los riesgos. Veamos por qué:
  • Mientras que otros compañeros de cuartel recibían mensualmente entre 20 y 30 pesetas en una sola partida, mi abuela enviaba el dinero una vez cada semana, y siempre un billete de 5 pesetas. No más. Esto permitía que, si el dinero era interceptado, siempre se perdiera como máximo esa cantidad. Aunque algo más caro (gastaba más en sellos) invirtió en seguridad y en una especie de "divide y vencerás". Esto proporcionaba a mi padre un flujo semanal de dinero que toleraba alguna pérdida ocasional del sobre.
        
  • Evitaba riesgos conocidos. Sabía de la mala reputación del cartero del pueblo (un poco borracho) así que no usaba el buzón a pie de calle. Acudía a la oficina donde la persona tras la ventanilla le ofrecía mucha más confianza. El pequeño esfuerzo de caminar un par de calles eliminaba una potencial amenaza de la ecuación. Además, (aunque en aquel momento no existía el vandalismo en el pueblo) evitaba otros riesgos inherentes al buzón a pie de calle.
         
  • Impedía, al envolver el billete en otras hojas de papel, que fuera visto al trasluz. No se fiaba de que, una vez en el cuartel, alguien decidiese comprobar las cartas antes de entregarlas en mano. Así que el simple método de interponer hojas entre el sobre y el dinero, mitigaba eficazmente este riesgo.
         
  • De vez en cuando, cambiaba el remitente. A veces aparecía ella, a veces mi abuelo, en ocasiones otro familiar. Intentaba así que la persona que repartiese el correo en el cuartel, encontrara un patrón fijo en su comportamiento y envío semanal. Entre semana, enviaba a veces cartas sin dinero en su interior.
De esta manera mi abuela, a pesar de sus limitaciones culturales y económicas (no podía permitirse comisiones por giros postales, o cartas certificadas), a pesar de las imperfecciones del método, conseguía enviar dinero a su hijo de una manera razonablemente segura y económica para la época. Y lo hacía por tres razones simples:

  • Con el dinero no se jugaba. Era un valor que merecía la pena proteger, y por el que incluso merecía la pena invertir modestamente (tiempo en ir a la oficina, más sellos para envíos semanales, etc.). Se tomó su tiempo para idear "un plan" razonado y eficaz dentro de sus posibilidades económicas.
      
  • Conocía el funcionamiento del correo y sus riesgos (qué clase de cartero recogía el buzón, cómo se repartían las cartas en el cuartel...).
       
  • Sabía que si no se preocupaba de su hijo y por el dinero, no lo haría nadie por ella. Las estrecheces económicas del momento afilaban la picaresca de muchos. Desconfiaba (con razón) por principios.
 
En la era digital, sin embargo, parecemos esperar que sean los propios sistemas informáticos los que nos protejan de forma automática. Fallamos en las premisas que mi abuela mantenía muy presentes: Ni valoramos lo suficiente nuestros datos en la Red, ni nos preocupamos por entender el funcionamiento... y exigimos que sea la propia tecnología la que nos proteja de ella misma. Esta es la receta para fallar estrepitosamente en el campo de la seguridad.
 
En la era digital, ¿se suelen establecer las mínimas medidas oportunas? ¿Utilizan los usuarios medios de mensajería cifrados?, ¿Instalan software preocupándose de su procedencia o informándose sobre qué hace realmente en su sistema operativo?; ¿Hacen copias de respaldo?... En general, parece que les resulta tedioso aprender cómo funciona el complejo mundo de la seguridad, prefieren restar importancia a sus datos ("¿a quién le va importar lo que hablo por WhatsApp, o mis datos en Facebook...?") antes que invertir en su protección.
 
Si mi abuela fuese hoy como un usuario medio de Internet, estaría enviando a mi padre, a través del buzón de la calle, postales con un billete de 100 euros pegado con celo. Aunque parezca absurdo, es muy parecido al efecto que conseguimos hoy en día en Internet al infravalorar la protección de nuestros datos. Creo que habría que aprender algo de mi abuela y sus billetes de 5 pesetas.

 

 

 

 
Sergio de los Santos
Twitter: @ssantosv

 

domingo, 22 de enero de 2012

Hispasec participa en los laboratorios de RootedLabs 2012


RootedLabs es un conjunto de actividades formativas que se llevarán a cabo en febrero de 2012 en Madrid, durante los tres días previos al congreso de seguridad informática RootedCON. Estos laboratorios de alto nivel técnico y enfoque eminentemente práctico, impartido por reputados profesionales del sector, abarcarán diferentes disciplinas relacionadas con la seguridad. Este año participa Sergio de los Santos de Hispasec.


La agenda de RootedLabs de 2012 se compone de la siguiente manera:

·               Lunes, 27 de febrero 2012,
Joxean Koret - Fundamentos de Ingeniería Inversa I 
Raúl Siles - Analizando y explotando aplicaciones web con Samurai-WTF
Juan Luís G. Rambla - Ataques en redes de datos IPv4 e IPv6
  
·               Martes, 28 de febrero 2012
Joxean Koret - Ingeniería Inversa Práctica Básica
Alejandro Ramos - Iniciación al Pentest
Juan Garrido - Análisis Forense de iDevices (iPhone, iPad e iPod Touch)
  
·               Miércoles, 29 de febrero 2012
Sergio de los Santos - Máxima Seguridad en Windows
Sebastián Guerrero - Ingeniería Inversa en Android
Chema Alonso y Daniel Romero- Pentesting Web Applications

Para asegurar la calidad y el dinamismo de las actividades formativas, las plazas de cada uno de los laboratorios están limitadas.

Cada laboratorio tendrá una duración de un día completo y en él está incluido el desayuno y la comida. El precio es de 200 euros + IVA por cada uno. Las instrucciones para inscribirse y las plazas restantes se encuentra en:


Laboratorio Hispasec

sábado, 21 de enero de 2012

Vulnerabilidades remotas en Apache Tomcat 5, 6 y 7

Esta semana Apache ha publicado la resolución de dos vulnerabilidades remotas calificadas como de nivel "importante" que afectarían a varias versiones de Apache Tomcat.

Apache Tomcat es un servidor web que funciona como contenedor de servlets, desarrollado en código abierto por la Apache Software Foundation. Tomcat implementa las especificaciones de las tecnologías servlets Java y de páginas JSP.

A continuación se detallan los errores:

·              Denegación de servicio remota (CVE-2012-0022) relacionada con las colisiones en las tablas hash. Este fallo ha afectado a otros fabricantes. Debido a una incorrecta gestión de las colisiones en las tablas hash, un atacante remoto podría generar una denegación de servicio a través del envío masivo de parámetros especialmente manipulados. Las versiones afectadas son la 5, 6 y 7 y para solucionar dicha vulnerabilidad deben actualizar a las siguientes:
Usuarios de Tomcat 7.0.x deben aplicar la revisión 7.0.23 o posterior.
Usuarios de Tomcat 6.0.x deben aplicar la revisión 6.0.35 o posterior.
Usuarios de Tomcat 5.5.x deben aplicar la revisión 5.5.35 o posterior.

·              Revelación de información sensible (CVE-2011-3375) debido a un error en el reciclado de objetos que podría volver visibles datos como IPs remotas o cabeceras HTTP a través de peticiones especialmente manipuladas. Las versiones afectadas son la 6 y 7 y para solucionar la vulnerabilidad deben actualizar a las siguientes:
Usuarios de Tomcat 7.0.x deben aplicar la revisión 7.0.22 o posterior.
Usuarios de Tomcat 6.0.x deben aplicar la revisión 6.0.35 o posterior.

Más información:

Apache Tomcat 7.x vulnerabilities


José Mesa Orihuela


viernes, 20 de enero de 2012

Oracle corrige 78 vulnerabilidades para su boletín de enero 2012

Oracle Systems ha publicado, como tenía establecido para el 17 de enero, un nuevo paquete de actualizaciones que afectaban a gran parte de sus productos, en especial a Oracle Database, MySQL y Solaris.

Ofrecemos un listado completo de los productos afectados:
·         Oracle Database
Oracle Database 11g Release 2, versiones 11.2.0.2, 11.2.0.3
Oracle Database 11g Release 1, versión 11.1.0.7
Oracle Database 10g Release 1, versión 10.1.0.5
Oracle Database 10g Release 2, versiones 10.2.0.3, 10.2.0.4, 10.2.0.5
  
·         Fusion Middleware
Oracle WebLogic Server, versiones 9.2.4, 10.0.2, 11gR1 (10.3.3, 10.3.4, 10.3.5)
Oracle Outside In Technology, versiones 8.3.5, 8.3.7
Oracle Application Server 10g Release 3, versión 10.1.3.5.0
Oracle Fusion Middleware 11g Release 1, versiones 11.1.1.3.0,11.1.1.4.0, 11.1.1.5.0
   
·         E-Business Suite
Oracle E-Business Suite Release 11i, versión 11.5.10.2
Oracle E-Business Suite Release 12, versiones 12.1.2, 12.1.3
  
·         Oracle Supply Chain
Oracle Transportation Management, versiones 5.5, 6.0, 6.1, 6.2
   
·         PeopleSoft
Oracle PeopleSoft Enterprise PeopleTools, versión 8.52
Oracle PeopleSoft Enterprise HCM, versiones 8.9, 9.0, 9.1
Oracle PeopleSoft Enterprise CRM, versión 8.9
   
·         JDEdwards
Oracle JDEdwards, versión 8.98

   
·         Oracle Sun Product Suite
Oracle Communications Unified 7.0
Sun Java System Application Server 8.1, 8.2
GlassFish Enterprise Server 2.1.1, 3.0.1, 3.1.1
Communications Server 2.0
Solaris versiones 8, 9, 10, 11 Express
   
·         Oracle Virtualization Product Suite
Oracle Virtual Desktop Infrastructure, versión 3.2
Oracle VM VirtualBox, versión 4.1
    
·         Oracle MySQL Product Suite
Oracle MySQL Server, versiones 5.0, 5.1, 5.5

En resumen las vulnerabilidades pueden considerarse de nivel medio-bajo. La mayoría de ellas se catalogan como denegaciones de servicio (Oracle DB, Solaris, MySQL y servicios relacionados con HTTP), mientras que las más elevadas son las que afectan a Oracle WebCenter Content, con una gravedad según la puntuación CVSS de 6.4 (CVE-2012-0083) y las de Solaris (CVE-2012-0094, CVE-2012-0100) con 7.8 y 6.8 respectivamente.

A continuación ofrecemos una relación de productos y el número de vulnerabilidades corregidas:

  • Oracle DB: dos parches que actualizan sendas denegaciones de servicio de remotas.
  • Fusion Middleware: 11 vulnerabilidades, 8 de ellas explotables remotamente.
  • E-Business Suite: tres vulnerabilidades relacionadas con el acceso a información confidencial y posible modificación de los datos.
  • Oracle Supply Chain: una denegación de servicio explotable remotamente.
  • PeopleSoft: seis vulnerabilidades relacionadas con el acceso a información confidencial y posible modificación de los datos.
  • JD Edwards: ocho vulnerabilidades relacionadas con el acceso a información confidencial y posible modificación de los datos.
  • Oracle Sun Products: 17 vulnerabilidades en total, 10 relacionadas con denegaciones de servicio y el resto  con el acceso a información confidencial y posible modificación de los datos.
  • Oracle Virtualization Product Suite: tres vulnerabilidades relacionadas con el acceso a información confidencial y posible modificación de los datos.
  • Oracle MySQL Product Suite: la mayor actualización, con 37 vulnerabilidades relacionadas en gran medida con denegaciones de servicio, acceso a información confidencial y posible modificación de los datos.

Debido a la amplia cuantía de sistemas afectados recomendamos la actualización de los mismos mediante los parches y guías de actualización facilitados.

Más información:

Oracle Critical Patch Update Advisory - January 2012


José Mesa Orihuela