ESET Latinoamérica – Laboratorio

Archivo para la Categoria 'Vulnerabilidades'

Ciclo de vida de una vulnerabilidad: consejos para una respuesta eficiente

febrero 7, 2012 11:49 am

El proceso de descubrimiento y tratamiento de una vulnerabilidad recorre generalmente caminos similares. Un individuo, por lo general externo a la empresa, descubre algún tipo de falla en un software o sistema determinado. Este puede ser, por ejemplo, en una aplicación web (el portal web de la empresa) o también en algún producto de la misma empresa (por ejemplo alguna aplicación desarrollada por la misma), entre otros.

El proceso continúa mediante un informe por parte del individuo hacia la empresa detallando el tipo de vulnerabilidad y cómo esta puede ser explotada.

Software patchDe aquí la empresa en cuestión opta por una de las varias alternativas para responder:

  • Responde con un mensaje automatizado, como por ejemplo un e-mail, indicando que se va a ocupar de resolverlo.
  • Responde de manera fluida y amable, poniéndose a disposición y mostrando interés verdadero en resolver el problema.
  • No existe ningún tipo de respuesta. Este es el caso de grandes empresas que fueron alertadas sobre fallos en sus sistemas y éstas hicieron caso omiso a las mismas dando lugar a ataques posteriores con fugas importantes de información y hasta interrupción de sus servicios.

Otro aspecto que también hay que destacar es la conducta de aquella persona que descubre la vulnerabilidad. Muchas veces estos individuos buscan nuevas fallas con el fin de obtener beneficios personales y no de informar a los desarrolladores sobre lo descubierto. En estos casos la vulnerabilidad queda expuesta cuando ya ha obtenido repercusión por el alcance que esta tuvo sobre la red. A modo de ejemplo podemos citar el caso de Mysql.com, el cual tuvo mucha repercusión debido a que el ataque fue mediante inyección SQL.

En cuanto al rol de la empresa, muchas veces las alertas de vulnerabilidades no son rsepondidas de forma eficiente, como por ejemplo cuando no se repara el problema en cuestión. Esto suele deberse a que la organización probablemente no cuenta con un sistema de gestión para actualizar y reparar aplicaciones. Otras veces, simplemente por falta de conocimiento, las personas que reciben el reporte no analizan el alcance de la vulnerabilidad y por lo tanto le dan una jerarquía muy baja dentro de sus prioridades.

Es en estos casos, como ya se mencionó, una mala respuesta puede causar la exposición indebida y reiteradas veces esto ha finalizado en incidentes de seguridad para la organización en cuestión. En ese contexto, aquí algunos consejos que pueden ser de utilidad para las empresas al momento de gestionar el reporte de una vulnerabilidad:

  • Responda al correo de aviso amablemente, agradezca por el reporte y manifieste su compromiso en reparar el incidente. Aún si está enojado, una vez consumado el reporte lo más importante debe ser estar al tanto del mismo y priorizar la reparación. La falta de respuesta o un mensaje agresivo puede ser contraproducente para la organización.
  • Remita con urgencia el mensaje a quienes puedan reparar la vulnerabilidad. Si no conoce quién podría hacerlo, escale la información lo suficiente hasta averiguarlo. Una vez que una vulnerabilidad es conocida, debe ser prioritario la reparación de la misma.
  • Al haber sido el receptor del mensaje, solicite ser informado cuando la vulnerabilidad sea reparada.
  • En caso de no obtener respuesta, realice un seguimiento interno y escale de ser necesario para que la vulnerabilidad sea corregida.
  • Una vez corregida la vulnerabilidad, envíe un mensaje a quien reportó la misma indicando que esta ha sido reparada.
  • Finalmente, realice un resumen de lo ocurrido y reporte a la persona responsable de la Seguridad de la Información (CIO, CSO, CISO, COO o incluso CEO; según la organización).

Finalmente, vale destacar que más allá de quién recibe el reporte, este tipo de incidentes deben ser utilizados para optimizar el proceso (¡o crearlo!) de gestión de riesgos, de forma tal de minimizar la probabilidad de que puedan ocurrir, o mejorar la respuesta en caso de ocurrencia. Para esto, es recomendable realizar periódicamente análisis de la seguridad, como los brindados por ESET Security Services, de forma tal de poder conocer cuáles son las vulnerabilidades o aspectos de mejora en la organización.

Fernando Catoira
Analista de Seguridad

ESET Security Services: la seguridad debe gestionarse

febrero 3, 2012 2:55 pm

La seguridad de la información en la empresa tiene tres pilares fundamentales: las tecnologías, la educación y la gestión. Mientras que las tecnologías siempre estuvieron ligadas a la seguridad, o al menos de forma intuitiva para el usuario (es fácil asociar un antivirus, un firewall o una contraseña a la seguridad), también hace muchos años se insiste (e insistimos) con la importancia de la educación en seguridad, dada la cantidad de amenazas informáticas basadas en la Ingeniería Social. No obstante, asociar la seguridad de la información a la gestión es un concepto relativamente moderno, y los especialistas en seguridad de la información están pidiendo mayor foco en este aspecto para una eficiente protección en entornos corporativos.

En ese contexto, el año pasado lanzamos ESET Security Services, la nueva unidad de ESET Latinoamérica a través de la cual brindaremos servicios de seguridad a las empresas de la región.

En esta primer etapa, hemos decidido comenzar brindando servicios orientados a la auditoría de la seguridad, lo que implica poder evaluar cuál es el estado actual de determinados aspectos, de forma tal de poder proponer un plan de acción correctivo para el cliente.

¿Cuáles son los servicios que se brindan?

En primer lugar, el servicio de Vulnerability Assesment, que consiste en realizar análisis sobre los sistemas y servicios disponibles a fin de encontrar vulnerabilidades conocidas. Una vulnerabilidad es un error que permite que se realicen acciones no deseadas sobre un sistema. Dichas acciones pueden ser una interrupción del servicio, acceso a funciones o  información sin tener autorización, escalamiento de privilegios sobre la misma o ejecución de código en el sistema; entre otros. Es decir que, al existir una vulnerabilidad en una aplicación, un atacante (malintencionado o involuntario) podría causar un problema que afecte la seguridad de la información de una empresa, afectando alguno de los principios de protección de los datos: su disponibilidad, integridad o confidencialidad.

Ver más… »

Vulnerabilidades XSS presentes en populares sitios web

enero 31, 2012 1:13 pm

En el último tiempo se ha observado un incremento en el tipo de vulnerabilidad Cross Site Scripting. Esta clase de falla muchas veces pasa desapercibida por los diseñadores de los sitios web a la hora de codificar sus portales, y por lo tanto no estipulan este tipo de ataque y cuál es su alcance en caso de que se explote exitosamente.

En esta semana se han descubierto varios sitios web de entidades de gran jerarquía con esta clase de vulnerabilidad. En la mayoría de los casos el tipo de vulnerabilidad es de XSS no persistente. Puntualmente, un atacante puede adulterar un enlace web para incorporar código malicioso y mediante técnicas de Ingeniería Social obtener beneficios de la víctima. Un ejemplo claro es la adulteración del enlace para extraer la cookie de sesión del usuario.

Sitios Vulnerables XSS

Sin embargo existen casos de mayor gravedad, es decir, vulnerabilidades de tipo XSS persistente. Esta es la situación de una de las mayores empresas de Internet cuya plataforma de blogging no filtra correctamente los comentarios que se realizan, lo que permite, por ejemplo, insertar una etiqueta del tipo iframe dentro del código del sitio. De esta manera el código del portal es modificado de manera permanente y no es necesaria la adulteración del enlace ni el uso de Ingeniería Social para explotar la vulnerabilidad de manera exitosa.

Ver más… »

Vulnerabilidad en el módulo Count Per Day de WordPress

enero 24, 2012 3:28 pm

El pasado 12 de enero de este año se descubrió una vulnerabilidad en uno de los plugins de la conocida plataforma de publicación libre, WordPress. Específicamente el plugin vulnerado es Count Per Day, en todas sus versiones anteriores a la 3.3.1.

Este plugin es muy utilizado, y algunas de las funcionalidades de las que dispone son:

  • Contabilizar visitantes y lecturas
  • Mostrar lecturas por página
  • Mostrar visitantes del día, la semana, el mes, etc.
  • Mostrar visitantes por país
  • Traducción a diversos lenguajes

La explotación de la vulnerabilidad permite realizar una inyección XSS no persistente o descargar un archivo arbitrario del servidor.

La vulnerabilidad XSS permite inyectar código en el sitio vulnerable mediante la modificación de la URL. Concretamente, la falla se encuentra en el modulo map.php. A través de la misma, un atacante podría hacer uso de Ingeniería Social para obtener algún tipo de información mediante el envío de un hipervínculo adulterado, obteniendo provecho de esta vulnerabilidad. Un ejemplo claro de esto sería la inyección de algún tipo de formulario haciéndole creer a la víctima que este es auténtico, para que ingrese allí sus credenciales de acceso y así el atacante obtiene información valiosa. A su vez, existen otras variantes utilizando XSS.

XSS en Count Per Day de WordPress

Ver más… »

Oracle planea parche crítico con 78 actualizaciones

enero 16, 2012 1:22 pm

Oracle ha anunciado que este martes 17 de enero, publicará su primer actualización de seguridad del año. Este parche crítico contiene 78 actualizaciones de seguridad para vulnerabilidades en varios productos de Oracle. De hecho, algunas de estas solucionan fallas de más de un producto.

Según el informe de Oracle, los productos afectados son:

  • Oracle Database 11g Release 2, versions 11.2.0.2, 11.2.0.3
  • Oracle Database 11g Release 1, version 11.1.0.7
  • Oracle Database 10g Release 2, versions 10.2.0.3, 10.2.0.4, 10.2.0.5
  • Oracle Database 10g Release 1, version 10.1.0.5
  • Oracle Fusion Middleware 11g Release 1, versions 11.1.1.3.0, 11.1.1.4.0, 11.1.1.5.0
  • Oracle Application Server 10g Release 3, version 10.1.3.5.0
  • Oracle Outside In Technology, versions 8.3.5, 8.3.7
  • Oracle WebLogic Server, versions 9.2.4, 10.0.2, 11gR1 (10.3.3, 10.3.4, 10.3.5)
  • Oracle E-Business Suite Release 12, versions 12.1.2, 12.1.3
  • Oracle E-Business Suite Release 11i, version 11.5.10.2
  • Oracle Transportation Management, versions 5.5.06, 6.0, 6.1, 6.2

    Ver más… »

Contáctenos | Política de Privacidad | Noticias Legales Copyright © 1992-2012 por ESET, LLC y ESET, spol. s.r.o. Todos los derechos reservados.