Notepad++ soluciona una vulnerabilidad de Vault 7 explotada por la CIA

Hace dos días, la plataforma WikiLeaks publicó una gran cantidad de documentos secretos de la CIA bajo el nombre de Vault 7 donde se demostraba cómo la organización conocía una serie de vulnerabilidades utilizadas para explotar sistemas informáticos y romper el cifrado de, por ejemplo, las aplicaciones de mensajería instantánea. Tan pronto como estas vulnerabilidades se han dado a conocer, los responsables de las mismas ya han empezado a solucionarlas, y ya nos están llegando los primeros parches de seguridad, como el de Notepad++.

Notepad++ es uno de los editores de texto más completos que podemos encontrar. Este editor de texto, gratuito y de código abierto, es muy utilizado tanto por usuarios que buscan una alternativa más completa al bloc de notas de Microsoft como por programadores, ya que también funciona como un completo y eficaz IDE de programación.

Read More

Vulnerabilidades en Cisco ASA

Cisco ha confirmado la existencia de dos vulnerabilidades en los dispositivos Cisco ASA (Adaptive Security Appliance).

El primero de los problemas reside en un fallo de validación de entrada a la hora de procesar componentes URL codificados con Rot13 en la funcionalidad SSL VPN. Un atacante remoto no autenticado podría aprovechar esto para ejecutar código script o HTML arbitrario (Cross Site Scripting) mediante URLs especialmente manipuladas.

Un segundo problema se debe a un fallo de validación de entrada en el componente WebVPN que podrían permitir a un atacante remoto no autenticado eludir ciertos mecanismos de protección relativos a la reescritura HTML y URL. Esto podría ser aprovechado para, manipulando el primer carácter hexadecimal de una URI de Cisco, ejecutar código script o HTML (Cross Site Scripting).

Estos problemas se han corregido en las versiones 8.0.4.34 y 8.1.2.25 del software de Cisco ASA que puede descargarse desde:

http://www.cisco.com/public/sw-center

http://www.cisco.com/pcgi-bin/tablebuild.pl/ASAPSIRT

Fuente:Noticias Hispasec

Read More

Diversas vulnerabilidades de seguridad en Solaris Kerberos

Sun ha publicado una actualización de Solaris Kerberos que corrige cuatro fallos de seguridad que podrían permitir a un atacante remoto lograr la ejecución de código arbitrario.

El primero de los problemas reside en un fallo en la función get_input_token de la implementación de SPNEGP en Kerberos 5 que podría permitir a un atacante provocar una denegación de servicio y potencialmente obtener información sensible a través de un valor de longitud especialmente manipulado.

Otro un fallo se presenta en la función asn1_decode_generaltime en lib/krb5/asn.1/asn1_decode.c en el decodificador ASN.1 GeneralizedTime de Kerberos 5. Esto podría permitir a un atacante provocar una denegación de servicio (referencia a puntero nula) y potencialmente ejecutar código arbitrario.

Una tercera vulnerabilidad está relacionada con la función spnego_gss_accept_sec_context de la librería lib/gssapi/spnego/spnego_mech.c de la implementación de SPNEGP en Kerberos 5 que podría permitir a un atacante provocar una denegación de servicio.

Por último, un fallo en la función asn1buf_imbed en el decodificador

ASN.1 de Kerberos 5 cuando se usa PK-INIT. Esto podría permitir a un atacante provocar una denegación de servicio a través de valores de longitud relacionados con el cálculo incorrecto de aritmética de punteros.

Según versión y plataforma, las actualizaciones están disponibles desde:

Plataforma SPARC:

Solaris 10 aplicar parche 140074-08 o superior:

http://sunsolve.sun.com/pdownload.do?target=140074-08&method=h

OpenSolaris compilación snv_116 o posterior.

Plataforma x86:

Solaris 10 aplicar parche 140130-09 o superior:

http://sunsolve.sun.com/pdownload.do?target=140130-09&method=h

OpenSolaris compilación snv_116 o posterior.

De igual forma, Sun anuncia que quedan pendiente de publicación los parches para Solaris 9 y SEAM (Sun Enterprise Authentication Mechanism).

Fuente:Noticias Hispasec

Read More

Múltiples vulnerabilidades en VMWare ESX 3.x

VMWare ha publicado una actualización de OpenSSL, bind y vim para VMware
ESX 3.0.3 y 3.0.2, que corrigen múltiples vulnerabilidades que podrían
permitir a un atacante remoto evadir restricciones de seguridad y
ejecutar código arbitrario.

VMware es un software que permite ejecutar diferentes sistemas
operativos en un mismo PC de forma virtual. Entre otras aplicaciones,
VMware es muy utilizado en seguridad informática por la versatilidad
que ofrece. VMWare ESX permite asignar recursos de procesador, memoria,
almacenamiento de información y redes en múltiples máquinas virtuales.

La primera de las vulnerabilidades corregidas es un fallo en OpenSSL
que omitía la validación del valor de retorno de la función
‘EVP_VerifyFinal’. Esto podría ser aprovechado por un atacante remoto
para evadir restricciones de seguridad a través de firmas ‘SSL/TLS’
para claves RSA y ECDSA especialmente manipuladas.

Se ha corregido un fallo en bind que omitía la validación del valor de
retorno de la función ‘DSA_do_verify’. Esto podría ser aprovechado por
un atacante remoto para evadir restricciones de seguridad a través de un
servidor DNS malicioso con un certificado DSA especialmente manipulado.

Otro de los problemas corregidos reside en el escapado de caracteres
especiales en Vim, lo que permitiría ejecutar comandos de la shell
introduciendo la clave de carácter ‘K’ en líneas que contengan el
carácter ‘;’. Esto podría ser aprovechado por un atacante remoto
ejecutar comandos de la shell a través de archivos vimscript
especialmente manipulados.

También se solucionan varios problemas de validación de entrada en
funciones de sistema de Vim. Un atacante podría ejecutar código si
la víctima abre con vim un documento especialmente manipulado.

Se ha corregido un desbordamiento de memoria intermedia basada en heap
en la función ‘mch_expand_wildcards’ de ‘os_unix.c’ en Vim. Esto podría
ser aprovechado por un atacante remoto para ejecutar código arbitrario
a través de nombres de archivo especialmente manipulados.

Por último, se ha corregido un error en el procesamiento de cadenas en
la función ‘helptags_one’ de ‘src/ex_cmds.c’ en Vim. Esto podría ser
aprovechado por un atacante remoto para ejecutar código arbitrario a
través de un archivo con ‘help-tags’ especialmente manipuladas.

Se recomienda aplicar la actualización disponible según versión desde:

Para ESX 3.0.2:

ESX-1008409 (openssl)
http://download3.vmware.com/software/vi/ESX-1008409.tgz

ESX-1008408 (bind)
http://download3.vmware.com/software/vi/ESX-1008408.tgz

ESX-1008406 (vim)
http://download3.vmware.com/software/vi/ESX-1008406.tgz

Para ESX 3.0.3:

ESX303-200903406-SG (openssl)
http://download3.vmware.com/software/vi/ESX303-200903406-SG.zip

ESX303-200903405-SG (bind)
http://download3.vmware.com/software/vi/ESX303-200903405-SG.zip

ESX303-200903403-SG (vim)
http://download3.vmware.com/software/vi/ESX303-200903403-SG.zip

Fuente:Noticias Hispasec

Read More

Boletines de seguridad != gestión de seguridad

Secunia, Secwatch, Securiteam, Vupen, US-CERT … son muchos los sitios de Internet que se dedican a hablar de vulnerabilidades. Hay servicios gratuitos, los hay de pago. Demasiados para enumerarlos.

Estos servicios tienen un denominador común: son repositorios de información en los que se publica, para un producto y un problema determinado, una ficha en la que suele presentarse, además del producto y versión afectados, datos como nivel de riesgo o criticidad, existencia de parches o workarounds mitigatorios, fechas de descubrimiento, actualización y solución de las vulnerabilidades, así como una breve explicación de la problemática que se denuncia. Es lo que se llama un boletín de seguridad, y los hay de todos los colores y para todos los gustos.

Un boletín tiene una utilidad principal, y esa no es otra que poner en conocimiento de los equipos de gestión del cambio que se ha descubierto un problema de seguridad en un componente que podría pertenecer o pertenece a su parque. Aunque los boletines incluyen enlaces a parches, soluciones, comentarios, vida, obra y milagros de los descubridores del problema, y mucha más información (útil, nadie dice que no) los boletines per se sirven principalmente para avisar. Es por esto que los anglosajones los suelen llamar advisories, lo que a veces se traduce como avisos, pero estaría mejor traducido como consejos.

¿Y por qué son consejos o avisos y no mandatos? ¿Por qué es un error convertir cualquier aviso de seguridad en un mandato de seguridad? Pues oiga, muy fácil. Los boletines clasifican los riesgos sin tener en cuenta el despliegue real del producto. Cuando un investigador o empresa escribe un boletín, no lo hace poniéndose en la piel de la totalidad de los n usuarios que pueden tener instalado un producto determinado, entre otras razones, porque es imposible. A lo sumo, se basará en una batería de pruebas lo más amplia posible y en su experiencia, pero es imposible reproducir todas las condiciones que pueden darse cuando se instala un paquete o conjunto de programas. El boletín, en mayor o menor medida, se suele escribir de un modo abstracto, analizando los riesgos teniendo en cuenta el elemento de un modo aislado.

Los boletines suelen clasificar los riesgos en función de tres parámetros:

  • Ámbito de explotación: local, remota o ambas
  • Existencia de parches, contramedidas y exploits conocidos
  • Tipología de acción maliciosa a la que puede conducir: revelación de información, escalada de privilegios, ejecución de código, denegación de servicio, etc.

Así, por poner dos ejemplos básicos, siguiendo esta clasificación un problema que sólo se puede explotar en local, sin acceso al sistema y condicionado, será poco crítico, mientras que una vulnerabilidad que pueda ejecutarse en remoto sin condiciones, y que conduzca a la ejecución de código, existiendo además exploits circulando en redes públicas, será un asunto altamente crítico.

Vamos a ver algunos ejemplos reales donde podremos comprobar que basarnos exclusivamente en un boletín de seguridad para calificar un riesgo para un despliegue determinado es un terrible error. Son cuatro ejemplos sobre cuatro productos distintos, y en este caso, son boletines públicos de la empresa Secunia, más o menos recientes en el tiempo.

Ejemplo 1

Título: Internet Explorer Data Binding Memory Corruption Vulnerability (10 de diciembre de 2008)

Calificación según el boletín: Extremadamente crítico (explotación remota, existencia de exploits confirmados, ejecución arbitraria de código)

Comentarios: ¿Dónde está reflejado ahí el ámbito de actuación de ese Internet Explorer? En ningún sitio. Es decir, si Internet Explorer es un producto de escritorio en una organización, donde es empleado para acceder a un CRM en red local, donde los equipos no admiten entrada de datos externos (no USB, no CD/DVD, etc) y donde no existe salida a Internet, ¿dónde está la criticidad? En ningún sitio.

Sin embargo, si es un navegador de usuario doméstico o profesional, existiendo salida a Internet y acceso a correo electrónico, sin presencia de medidas de protección, así como una fuerte interrelación con otras aplicaciones en la red, el riesgo sí puede considerarse como muy elevado. Entre ambos extremos, imaginaos la cantidad de supuestos que pueden existir.

Ejemplo 2

Título: IBM Tivoli Access Manager WebSEAL Denial of Service Vulnerability (25 de noviembre de 2008)

Calificación según el boletín: Moderadamente crítico. Razón fundamental, la mezcla de que sea un problema explotable remotamente que puede conducir a una denegación de servicio, y no a un problema de calado mayor (escalada de privilegios, ejecución de código, etc)

Comentarios: ¿Qué sucedería si ese TAM estuviera corriendo frente a una infraestructura crítica de autenticación admitiendo tráfico de Internet (lo habitual en un TAM, por cierto) y denegamos el servicio? Por lo pronto, teniendo en cuenta que estos productos suelen estar instalados en grandes infraestructuras, y habitualmente en servicios financieros, el primer efecto de un DoS en un TAM son los perjucios económicos, así como el daño de imagen y el daño reputacional, con lo que aventurar un problema moderadamente crítico podría hacer que nos quedemos cortos.

¿Y si estuviera en un segmento no accesible directamente por el tráfico de Internet, dando cobertura a una estrategia de autenticación de menor importancia? Poco, o nada. ¿Será siempre algo moderadamente crítico? La respuesta es no.

Ejemplo 3

Título: IBM AIX Multiple Privilege Escalation Vulnerabilities (27 de noviembre de 2008)

Calificación según el boletín: Poco crítico. Explotable localmente, y con posibilidad de escalada de privilegios, condicionada a que el sistema opere en determinadas maneras.

Comentarios: La primera pregunta. ¿Ha visto Usted un AIX en ejecución alguna vez? Como probablemente no lo habrá visto, yo le cuento: es un sistema profesional, propietario, y además de costar un pastón entre sistema y máquina (porque no corre en el PC que tiene en lo alto de la mesa, por desgracia) suele dar servicio, entre otras cosas, a aplicaciones que necesitan servidores Web estáticos y dinámicos que por desgracia, ni son para poner foros, ni fotos de los amiguetes ni musiquita MP3. Corriendo en un AIX es frecuente ver aplicaciones del mundo de seguros y de la banca a distancia, así como aplicaciones financieras no core y/o con datos muy sensibles. En definitiva, una escalada de privilegios, aunque sólo sea local, puede ser dramática dependiendo de dónde corra ese AIX.

¿Y si ese AIX está en una red interna, protegida del tráfico exterior, y su tráfico está convenientemente filtrado, por ejemplo, porque sólo se accede mediante transacciones CICS? Pues la escalada de privilegios deja de tener sentido, porque los accesos que no son CICS los harán los administradores y operadores de las máquinas, que normalmente tienen accesos UID 0. En estos casos, no es de esperar que haya cuentas de usuario susceptibles de atacar el sistema elevando privilegios.

Ejemplo 4

Título: Debian update for amarok (16 de enero de 2009)

Calificación según el boletín: Altamente crítico (acceso ilegítimo al sistema en remoto)

Comentarios: Lo primero es pensar, y darse cuenta de que las probabilidades de encontrarse Amarok corriendo en Debian (siendo la distribución un servidor) son análogas a las de encontrarse Winamp en un servidor Windows: escasas. ¿Que hay gente capaz de todo? Sí. ¿Que hay administradores poco o nada profesionales que tienen 800 paquetes en sus servidores, y sólo usan 50? Sí. ¿Que hay gente que tiene desktops Debian repletos de aplicaciones multimedia? Sí ¿Que la proporción de usuarios desktop en Debian es menor que la de usuarios profesionales? Probablemente. ¿Que lo normal es que alguien que sabe instalar Debian para usarlo de servidor no tenga instalado Amarok ni ninguna otra aplicación de escritorio? También.

Algunas conclusiones

  1. Los boletines son útiles y necesarios para administrar la seguridad, pero es absolutamente necesario contextualizar la problemática en el despliegue particular que tengamos. Si no sabemos traducir las problemáticas abstractas de un aviso en los riesgos reales de una instalación, mejor que nos dediquemos a otra cosa. Asumir que el riesgo particular de una instalación es el que marca un boletín es un tremendo error.
  2. Los boletines no son mandatos de seguridad, sino consejos de seguridad. Antes de instalar un parche hay que estudiar el caso con calma, y determinar los riesgos reales para nuestra instalación, no sólo los que puede explotar el problema de seguridad, sino la estrategia de aplicación de parches que puede llevar asociada (especialmente, en términos de incompatibilidad entre productos). Incluso en el caso de un usuario doméstico, tampoco deben ser entendidos como mandatos. Si ha aparecido un problema crítico en el Net Framework y yo no lo tengo instalado, ¿qué urgencia tengo en aplicar parche alguno?
  3. Por último, y tal y como indica el título de este pequeño artículo, Boletines de seguridad != gestión de seguridad. Ni la gestión de parches es la gestión de cambios, ni la gestión de la seguridad es la gestión de parches. Cada disciplina tiene su ámbito y hay que saber diferenciar bien qué es cada cosa. Si vas a construir la gestión de tu seguridad obedeciendo sólo lo que te llega en forma de boletín, tu estrategia fallará, porque además de los boletines, de los servicios de consultoría y de las buenas prácticas, tu estratregia necesita algo que sólo puedes darle tú: el conocimiento de tu negocio y cómo atender sus riesgos.

Fuente:SeguInfo

Read More