Hola a todos,
como actualización a la información entregada anoche, hoy hemos liberado el boletin MS08-67.
Esta actualización resuelve una vulnerabilidad al servicio Server de Windows que afecta todas las versiones actualmente soportados de estos sistemas operativos. Windows XP y versiones anteriores esto tienen una importancia máxima de “Critica” mientras que para Windows Vista y versiones más nuevas esta categorizada como “Importante”. Más detalle al respecto puede ser encontrada en el blog de MSRC, así como en el boletín en si.
Recomendamos a todos nuestros clientes que se dirijan al sitio de Seguridad de Microsoft para Latinoamerica: www.microsoft.com/latam/seguridad/ para revisar las acciones recomendadas.
La recomendación principial es probar e instalar la actualización de seguridad lo antes posible.
Christian.-
**Esto se publica “como está” sin garantías y no confiere derechos**
Hola, escribe Christian Linacre
para contarles que hemos descubierto un nuevo brote del gusano llamado Conficker, con una variación conocida como Conficker.B. Este gusano usa una vulnerabilidad que corregimos en Octubre con el boletín MS08-067. Esto significa que todos los clientes que hayan instalado correctamente esa actualización están fuera de peligro.
Este gusano puede infectar computadores en un red explotando la vulnerabilidad en Windows Server Services (SVCHOST.EXE) y, si la vulnerabilidad es exitosamente explotada podría permitir ejecución remota de código cuando la compartición de archivos está habilitada. Este malware deshabilita importantes servicios de sistema y productos de seguridad.
Ahora como saber si su sistema está infectado con este software malicioso. Los síntomas están descritos en la definición de Conficker.B en el Centro de Protección contra el Malware de Microsoft, pero en resumen:
Para prevenir ser infectados recomendamos:
Si usted cree que ha sido infectado no recomendamos la remoción manual sino que utilizando Windows Live Examen de Seguridad, que les permite realizar un Examen completo y gratuito, o contacte a Microsoft.
Adicionalmente, los productos de seguridad de Microsoft ya tienen la vacuna para este gusano. Requiere tener instalado la firma 1.49.1167.0 o posterior. Esto es válido para:
Forefront Client Security Windows Live OneCare Windows Live Safety Scanner (gratis)
Saludos, Christian.-
Hola, les escribe Roberto Arbeláez.
A partir de hoy voy a estar compartiendo este espacio con Christian Linacre, quien muy amablemente me abrió las puestas de su blog de Seguridad para Latinoamérica, para poder compartir con ustedes algunas reflexiones sobre los últimos acontecimientos en materia de seguridad de la información.
Una muy breve introducción: Soy Ingeniero y Magíster en Ingeniería de Sistemas y Computación, CISSP y CISA; trabajo en Microsoft hace más de 3 años, donde actualmente me desempeño como Security Program Manager para Latinoamérica.
--------------------
Ahora si, entremos en materia:
seguimos viendo un incremento en el número de infecciones de Conficker.B en Latinoamérica.
Esta variante es considerablemente diferente a la versión original de Conficker (Conficker.A), por lo que es importante estar atento para detectar sus síntomas.
Sintomas de infección de Conficker.B
Una de las diferencias entre la variante original de Conficker (ahora Conficker.A) y la nueva variante Conficker.B es que esta última utiliza diferentes vectores para propagarse. A diferencia de Conficker.A (que sólo se propagaba explotando la vulnerabilidad descrita en el boletín de seguridad MS08-067), Conficker.B también intenta explotar contraseñas débiles de administrador para esparcirse, por lo que es importante además de instalar la actualización de seguridad, verificar que las contraseñas de ADMIN$ share sean robustas.
Pasos para eliminar la infección
La actualización de la Herramienta de Eliminación de Software Malintencionado de Microsoft (MSRT - Malicious Software Removal Tool) liberada hoy Martes 13 de Enero, incluirá la detección y remoción de Win32/Conficker en todas sus variantes conocidas hasta el momento. Debido a que Conficker deshabilita las actualizaciones automáticas (automatic updates) de Windows , puede ser necesario emplear un método diferente para implantarlo en entornos empresariales, descrito en el KB891716 – Implantación de MSRT en un entorno empresarial.
También tenemos disponible una guía para la desinfección manual de Conficker.B, por si no es posible desinfectar de otra manera, con gusto la enviaré a vuelta de correo a quienes nos la soliciten.
Más información sobre Conficker.B en el blog de MMPC.
Más información sobre la Herramienta de Eliminación de Software Mailintencionado aqui.
Saludos,
Roberto.
En los ultimos dias se ha estado discutiendo mucho sobre las 10.000 cuentas de usuarios de Hotmail a las que se les reveló publicamente el password en dias pasados:
http://www.wired.com/threatlevel/2009/10/10000-passwords/
Muchas personas, sin entender qué fue lo que pasó, culparon a Hotmail (y a Microsoft) de lo ocurrido.
Esta lista fue solo el principio, habiéndose publicado inmediatamente después otra lista, con 20.000 usuarios y contraseñas de Gmail, Yahoo, y AOL, entre otros:
http://news.bbc.co.uk/2/hi/technology/8292928.stm
¿Qué fue lo que ocurrió?
¿Fallaron los proveedores de servicios de correo electrónico?
Pues no. Fallaron los usuarios!
Los hackers, siendo las personas inteligentes que son, siempre buscan atacar un sistema por su parte más débil. Y atacar un sistema como Hotmail de manera frontal es muy difícil. Así que optan por utilizar ataques destinados a explotar las debilidades de los usuarios finales.
Los usuarios afectados fueron victimas de un ataque de Phishing. Los atacantes enviaron a un gran numero de personas un correo electrónico falso, que se hacía pasar por un correo oficial de Hotmail, pidiendo a los usuarios actualizar sus credenciales (usuario y contraseña). Estos correos usan los mismos logos, los colores y la presentación que utilizan los correos electronicos que realmente vienen de los administradores de Hotmail. Por supuesto, las personas que ingresaban sus credenciales y daban click en “enviar” no le estaban mandando esta información a Hotmail, sino a los atacantes.
Como regla general, se debe desconfiar de cualquier correo electrónico que nos pida que ingresemos nuestras credenciales, y nunca las debemos enviar ni por correo electrónico, ni por programas de mensajería instantánea.
Aqui, algunas recomendaciones para no ser víctima de ataques de phishing:
http://www.microsoft.com/mscorp/safety/default.mspx
Es interesante, que habiéndose realizado un análisis de las contraseñas, la mayoría de ellas eran inseguras. A continuación, las contraseñas más encontradas en la lista:
1. 123456 – 64 occurrencias
2. 123456789 – 18 ocurrencias
3. alejandra – 11 ocurrencias
4. 111111 – 10 ocurrencias
5. alberto – 9 ocurrencias
6. tequiero – 9 ocurrencias
7. alejandro – 9 ocurrencias
8. 12345678 – 9 ocurrencias
9. 1234567 – 8 ocurrencias
10. estrella – 7 ocurrencias
11. iloveyou – 7 ocurrencias
12. daniel – 7 ocurrencias
13. 000000 – 7 ocurrencias
14. roberto – 7 ocurrencias
15. 654321 – 6 ocurrencias
16. bonita – 6 ocurrencias
17. sebastian – 6 ocurrencias
18. beatriz – 6 ocurrencias
19. mariposa – 5 ocurrencias
20. america – 5 ocurrencias
Como pueden ver, muchas de las víctimas son hispanoparlantes por lo que es importante que empecemos a mejorar nuestra seguridad personal en Latinoamérica, empezando por la selección de una contraseña segura para nuestro buzón de correo electrónico.
Algunas características de una buena contraseña son que debe contener mayúsculas, minúsculas, números, simbolos (por ejemplo !#$*), tener como mínimo 8 caracteres de longitud (idealmente al menos 12), y no contener información que se pueda deducir conociendo a la persona.
Aqui, unas buenas prácticas a seguir para crear y administrar contraseñas:
http://technet.microsoft.com/en-us/library/cc784090(WS.10).aspx
Por último, les recuerdo que la siguiente semana es semana de boletines de seguridad, por lo que aprovecho para invitarlos a que asistan a nuestra llamada mensual. Ya estaremos publicando el sitio en este mismo Blog.
Saludos, Roberto.
Hola, les escribe Roberto Arbeláez. Después de una exhaustiva investigación, Microsoft ha confirmado que los problemas reportados de BSoD (Blue Screen of Death – Pantalla Azul de la Muerte) solo se presentan cuando la actualización asociada al boletín de seguridad MS10-015 se instala en máquinas previamente infectadas con el Rootkit Alureon.
Microsoft llegó a esta conclusión después del análisis exhaustivo de vaciados de memoria obtenidas de múltiples máquinas de usuarios afectados, así como de pruebas extensivas contra aplicaciones y software de terceros.
Los reinicios son el resultado de las modificaciones que el Rootkit Alureon hace a los archivos binarios del kernel de Windows, que pone a las máquinas afectadas en un estado inestable. En ninguno de los incidentes investigados se encontraron problemas de calidad o bugs en el MS10-15.
En el caso particular de Alureon, los autores de este Rootkit modificaron el comportamiento de Windows al intentar acceder a un segmento específico de memoria directamente, en vez de dejar que el sistema operativo determinara la dirección de memoria que es lo que usualmente pasa cuando se carga un ejecutable. La cadena de eventos en este caso empezaba por que una máquina era infectada con Alureon, y este rootkit asumía en donde iba a estar ubicado el código de windows en memoria. Posteriormente, el MS10-015 era bajado e instalado, durante lo cual se cambiaba la ubicación del código de windows en memoria. Al siguiente reinicio, el código del rootkit hacía que el sistema se estrellara, al intentar acceder una dirección específica en el código de windows residente en memoria que ya no alojaba la función del sistema operativo a la que el rootkit intentaba acceder.
Microsoft ha desarrollado algunas medidas para evitar que se manipule el código del Kernel de Windows usando tecnologías como el Kernel Patch Protection (Protección de parcheo al Kernel, también conocido como PatchGuard) y Kernel Mode Code Signing (KMCS, Firmado de Código en Modo Kernel), ambas habilitadas en nuestros sistemas operativos de 64 bits. Estas tecnologías hacen posible detectar cuando las revisiones de integridad del códigio del kernel fallen. Las diferentes versiones de Alureon que se han investigado solamente afectan sistemas de 32 bits y son incapaces de infectar sistemas de 64-bits.
Puede obtener más información sobre el kernel de windows en este link. Más información sobre la investigación y los resultados obtenidos en el articulo asociado a este incidente en el blog de MSRC.
Nuestras recomendaciones siguen siendo las mismas: Los clientes deben implantar las actualizaciones de seguridad de Febrero y asegurarse de que sus sistemas estén protegidos con software antivirus actualizado.
Si usted es uno de nuestros clientes afectados, le podemos ayudar. Puede abrir un caso de soporte gratuito, en cualquiera de nuestros canales de soporte para Latinoamérica:
Sitio principal de soporte: http://support.microsoft.com/default.aspx?ln=ES-LA
Líneas de atención al cliente: http://support.microsoft.com/gp/contactusen/?ln=es-la
Soporte en línea (vía chat): http://support.microsoft.com/oas/default.aspx?&prid=7552
Roberto Arbeláez
Security Program Manager for Latin America
CSS Security
Microsoft Corp.
En respuesta a las continuas preguntas de clientes sobre cómo protegerse y defenderse contra el gusano Conficker, el Centro de Protección contra Software Malicioso de Microsoft (Microsoft Malware Protection Center) ha publicado una nueva entrada en su blog de Investigación y Respuesta a Amenazas en el que centraliza toda la información de guianza que sobre este tema tiene Microsoft:
http://blogs.technet.com/mmpc/archive/2009/01/22/centralized-information-about-the-conficker-worm.aspx
Continuamos pidiendo a nuestros clientes que implanten la actualización de seguridad asociada al boletín de seguridad MS08-067 tan pronto como sea posible. También les pedimos que implementen medidas de defensa en profundidad basadas en la información provista en el Blog del Centro de Protección contra Software Malicioso de Microsoft (Microsoft Malware Protection Center).
Continuaremos monitoreando la situación a través de nuestro Proceso de Respuesta a Incidentes de Seguridad de Software (Software Security Incident Response Process –SSIRP-) y estamos trabajando de manera activa con nuestros socios del Programa de Protección Activa de Microsoft (Microsoft Active Protections Program –MAPP-) y de la Alianza de Respuesta de Seguridad de Microsoft (Microsoft Security Response Alliance –MSRA-) para hacer frente a esta amenaza.
Boletin de Seguridad MS08-067:
http://www.microsoft.com/latam/technet/seguridad/boletines/2008/ms08-067.mspx
Blog del MMPC con la información centralizada de Conficker:
Hola, les escribe Roberto Arbeláez. Microsoft publica los siguientes seis boletines de seguridad para vulnerabilidades recientemente descubiertas:
ID del boletín
Título del boletín
Calificación máxima de la gravedad
Impacto de la vulnerabilidad
Se requiere reinicio
Software afectado
MS12-017
La vulnerabilidad en DNS Server podría permitir la negación de servicio (2647170)
Importante
Negación de servicio
Requiere reinicio
Microsoft Windows Server 2003, Windows Server 2008 (excepto los sistemas basados en Itanium) y Windows Server 2008 R2 (excepto los sistemas basados en Itanium).
MS12-018
La vulnerabilidad en las unidades en modo de kernel de Windows podría permitir la elevación de privilegios (2641653)
Elevación de privilegio
Microsoft Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7 y Windows Server 2008 R2.
MS12-019
La vulnerabilidad en DirectWrite podría permitir la negación de servicio (2665364)
Moderado
Puede requerir reinicio
Microsoft Windows Vista, Windows Server 2008 (excepto los sistemas basados en Itanium), Windows 7 y Windows Server 2008 R2.
MS12-020
La vulnerabilidad en el Escritorio remoto podría permitir la ejecución remota de códigos (2671387)
Crítica
Ejecución del código remoto
MS12-021
La vulnerabilidad en Visual Studio podría permitir la elevación de privilegios (2651019)
Microsoft Visual Studio 2008 y Visual Studio 2010.
MS12-022
La vulnerabilidad en Expression Design podría permitir la ejecución remota de códigos (2651018)
Microsoft Expression Design, Expression Design 2, Expression Design 3 y Expression Design 4.
Los resúmenes para los nuevos boletines se pueden encontrar en http://technet.microsoft.com/security/bulletin/MS12-mar.
Herramienta de Microsoft Windows para remover software malicioso
Microsoft libera una versión actualizada de la Herramienta de Microsoft Windows para remover software malicioso en Windows Server Update Services (WSUS), Windows Update (WU) y el Centro de descargas. La información en la Herramienta de Microsoft Windows para remover software malicioso se encuentra en http://support.microsoft.com/?kbid=890830.
Actualizaciones de alta prioridad que no son de seguridad
Las actualizaciones de alta prioridad que no son de seguridad que libera Microsoft estarán disponibles en Microsoft Update (MU), Windows Update (WU) o Windows Server Update Services (WSUS) se detallarán en el artículo de KB en http://support.microsoft.com/?id=894199.
Nuevo aviso de seguridad
Microsoft publicó un nuevo aviso de seguridad el 13 de marzo de 2012. Aquí está una descripción de este nuevo aviso de seguridad:
Aviso de seguridad 2647518
Acumulativo de actualizaciones para bits de interrupción de ActiveX
• Microsoft Windows XP
• Windows Server 2003
• Windows Vista
• Windows Server 2008
• Windows 7
• Windows Server 2008 R2
Resumen ejecutivo
• Con este aviso, Microsoft va a lanzar un paquete acumulativo de actualizaciones de bits de interrupción de ActiveX que contiene nuevos bits de interrupción y de todos los bits de interrupción publicados anteriormente.
• Esta actualización configura los bits de interrupción para el siguiente software de terceros:
o Biostat SamplePower (IBM)
o Blueberry Software Flashback Component (IBM)
o HP Photo Creative (HP)
Mayores informes
http://technet.microsoft.com/security/advisory/2647518
Webcast del boletín público
Microsoft realizará una transmisión Web para abordar las preguntas de los clientes sobre estos boletines:
Título: Información sobre los Boletines de seguridad de marzo de Microsoft (Nivel 200)
Fecha: Jueves, 15 de marzo 2012, 10:00 AM UTC/GMT -05 (Bogotá, Lima, Quito)
URL: https://www142.livemeeting.com/cc/microsoft/join?id=P5S2K4&role=attend
Detalles técnicos sobre el nuevo boletín de seguridad
En las siguientes tablas de software afectado y no afectado, habrá pasado el ciclo de vida de soporte de las ediciones de software que no aparezcan . Para determinar el ciclo de vida de soporte de su producto y edición, visite el sitio Web del Ciclo de vida de soporte de Microsoft en http://support.microsoft.com/lifecycle/.
Identificador del boletín
Boletín de seguridad de Microsoft MS12-017
Esta actualización de seguridad resuelve una vulnerabilidad reportada de manera privada en Microsoft Windows. La vulnerabilidad podría permitir la negación de servicio si un atacante remoto no autenticado envía una consulta DNS especialmente diseñada para tener como objetivo el servidor DNS.
La actualización de seguridad corrige la vulnerabilidad al modificar la manera en que el servidor DNS se encarga de los objetos en la memoria.
Calificaciones de gravedad y software afectado
· Esta actualización de seguridad se considera Importante para todas ediciones compatibles de Windows Server 2003, ediciones de 32 bits y x64 de Windows Server 2008 y x64 de Windows Server 2008 R2.
· Las instalaciones que utilicen Server Core se ven afectadas.
· Las versiones de Itanium no se ven afectadas.
Vectores de ataque
Un atacante remoto no autenticado podría aprovechar esta vulnerabilidad mediante el envío de una consulta DNS especialmente diseñada para tener como objetivo el servidor DNS.
Factores de migración
Microsoft no ha identificado factores atenuantes para esta vulnerabilidad.
Esta actualización requiere un reinicio.
Boletines reemplazados por esta actualización
MS11-058
Detalles completos
http://technet.microsoft.com/security/bulletin/MS12-017
Boletín de seguridad de Microsoft MS12-018
Esta actualización de seguridad resuelve una vulnerabilidad reportada de manera privada en Microsoft Windows. La vulnerabilidad podría permitir la elevación de privilegios si un atacante inicia sesión en un sistema y ejecuta una aplicación preparada especialmente.
La actualización de seguridad corrige la vulnerabilidad al modificar la forma en que la unidad del modo kernel de Windows maneja los mensajes de ventana.
· Esta actualización de seguridad está calificada como Importante para todas las versiones con soporte de Microsoft Windows.
Un atacante que es capaz de entrar en el sistema objetivo podría ejecutar una aplicación especialmente diseñada para continuar funcionando después de que el atacante cierre la sesión.
Un atacante debe tener credenciales válidas para iniciar una sesión y poder iniciar una sesión localmente para explotar esta vulnerabilidad.
MS12-008
http://technet.microsoft.com/security/bulletin/MS12-018
Boletín de seguridad de Microsoft MS12-019
Esta actualización de seguridad resuelve una vulnerabilidad en Windows DirectWrite que puede resultar en una condición de negación de servicio (la aplicación de destino dejará de responder) si una secuencia especialmente diseñada de caracteres Unicode se representa en el sistema de destino.
La actualización de seguridad corrige la vulnerabilidad al cambiar la forma en que DirectWrite representa los caracteres Unicode.
· Esta actualización de seguridad está calificada como Moderada para todas las ediciones con soporte de Windows Vista, Windows Server 2008 (excepto Windows Server 2008 para sistemas con Itanium), Windows 7 y Windows Server 2008 R2.
· Las instalaciones que utilicen Server Core no se ven afectadas.
· En caso de un ataque basado en la Web, un atacante no autenticado tendría que alojar un sitio Web que contenga una secuencia especialmente diseñada de caracteres Unicode.
· En un escenario de ataque basado en mensajería instantánea, un atacante no autenticado podría aprovechar esta vulnerabilidad mediante el envío de una secuencia especialmente diseñada de caracteres Unicode directamente a un cliente de mensajería instantánea como Windows Live Messenger. La aplicación de destino podría dejar de responder cuando se presenta la secuencia de DirectWrite especialmente diseñada de caracteres Unicode.
· Microsoft no ha identificado factores atenuantes para esta vulnerabilidad.
Esta actualización puede requerir un reinicio.
Ninguno
http://technet.microsoft.com/security/bulletin/MS12-019
Boletín de seguridad de Microsoft MS12-020
Esta actualización de seguridad resuelve dos vulnerabilidades en el Protocolo de escritorio remoto. La más grave de estas vulnerabilidades podría permitir la ejecución remota de códigos si un atacante envía una secuencia de paquetes RDP especialmente diseñados a un sistema afectado.
La actualización de seguridad corrige las vulnerabilidades al modificar la manera en que el Protocolo de escritorio remoto procesa los paquetes en la memoria y la forma en que el servicio RDP procesa los paquetes.
· Esta actualización de seguridad está calificada como Crítica para todas las versiones con soporte de Microsoft Windows.
· Un atacante remoto no autenticado podría aprovechar esta vulnerabilidad mediante el envío de una secuencia de paquetes RDP especialmente diseñados para el sistema de destino (CVE-2012-0002).
· El Protocolo de escritorio remoto (RDP) no está activado en cualquier sistema operativo Windows por defecto.
· Las mejores prácticas de firewall y las configuraciones de firewall por defecto pueden ayudar a proteger las redes frente a ataques que se originan fuera del perímetro de la empresa.
· El atacante debe autenticarse con el fin de explotar CVE-2012-0002 si la Autenticación a nivel de red está habilitada.
MS11-065
http://technet.microsoft.com/security/bulletin/MS12-020
Boletín de seguridad de Microsoft MS12-021
Esta actualización de seguridad resuelve una vulnerabilidad reportada de manera privada en Visual Studio. La vulnerabilidad podría permitir la elevación de privilegios si un atacante pone un complemento diseñado especialmente en la ruta utilizada por Visual Studio y convence a un usuario con mayores privilegios que inicie Visual Studio.
La actualización de seguridad corrige la vulnerabilidad al modificar la manera en que Visual Studio restringen los lugares donde los complementos se cargan.
Esta actualización de seguridad se considera Importante para todas las ediciones compatibles con Microsoft Visual Studio 2008 y Microsoft Visual Studio 2010.
Para aprovechar esta vulnerabilidad, un atacante tendría que iniciar sesión en el sistema. Un atacante podría colocar un complemento especialmente diseñado en la ruta utilizada por Visual Studio.
Un atacante debe tener credenciales válidas para iniciar una sesión y poder iniciar una sesión localmente para explotar esta vulnerabilidad. La vulnerabilidad no podría ser explotada de forma remota o por usuarios anónimos.
http://technet.microsoft.com/security/bulletin/MS12-021
Boletín de seguridad de Microsoft MS12-022
Esta actualización de seguridad resuelve una vulnerabilidad reportada de manera privada en Microsoft Expression Design. La vulnerabilidad podría permitir la ejecución remota de códigos si un usuario abre un archivo legítimo (como un archivo .xpr o .DESIGN) que se localice en el mismo directorio en red de un archivo de biblioteca con vinculación dinámica (DLL) especialmente preparado. La vulnerabilidad corregida por esta actualización se relaciona con la clase de vulnerabilidades que se describen en el Aviso de seguridad de Microsoft 2269637.
La actualización de seguridad trata la vulnerabilidad al corregir la forma en la que Microsoft Expression Design carga las bibliotecas externas.
Esta actualización de seguridad está calificada como Crítica para todas las versiones con soporte de Microsoft Expression Design.
· En caso de un ataque por correo electrónico, un atacante podría aprovechar esta vulnerabilidad mediante el envío de un archivo legítimo relacionada con Expression Design (como un archivo .xpr o .DESIGN) a un usuario, convencer al usuario para colocar el archivo adjunto en un directorio que contenga un archivo DLL especialmente diseñado y, a continuación, abra el archivo legítimo.
· En caso de un ataque de red, un atacante podría colocar un archivo legítimo relacionado con Expression Design y un archivo DLL especialmente diseñado en un recurso compartido de red, un UNC, o la ubicación de WebDAV y luego convencer al usuario para que abra el archivo.
· Comúnmente se desactiva SMB en el firewall del perímetro.
· Un usuario debe ser convencido para visitar un lugar remoto no confiable de sistema de archivos o recurso compartido WebDAV y abrir un archivo (como un archivo .xpr o .DESIGN) desde este lugar que se cargue entonces mediante una aplicación vulnerable.
· La explotación sólo gana los mismos derechos de usuario que la cuenta que inició la sesión.
http://technet.microsoft.com/security/bulletin/MS12-022
Como siempre, si tiene problemas al bajar o instalar una de las actualizaciones, o problemas después de instalar una actualización, tiene derecho a recibir soporte gratuito de seguridad Microsoft. el soporte lo pueden obtener aqui:
–Para usuario final: http://www.microsoft.com/latam/protect/support/default.mspx
–Para usuario corporativo: http://support.microsoft.com/default.aspx?ln=ES-LA
–Teléfonos de las líneas de soporte en Latinoamérica: http://support.microsoft.com/gp/contactusen/?ln=es-la
es importante que tenga en cuenta que el soporte gratuito de seguridad también aplica para cualquier caso de seguridad y de malware (virus, troyanos, gusanos, etc.) sin importar que marca de antivirus use. Así que si ha sido afectado (o sospecha que han sido afectado) por un ataque de seguridad o por malware, no vacile en contactarnos. Nuestros ingenieros de soporte harán la investigación respectiva para determinar si el caso es o no un problema de seguridad y/o de malware, y en caso afirmativo, le darán pronta solución al problema.
También quiero aprovechar para exterder una invitación para que nos sigan en twitter en los siguientes alias:
@LATAMSRC Información OFICIAL de Microsoft sobre alertas de seguridad, advisories, y boletines. Bajo volumen de twits (cuando se emitan alertas). En español.
@rarbelaez Información general de Seguridad. Alto volumen de twits. En español e inglés.
La nueva variante de Conficker en aparecer en escena, la variante Conficker.D, ha causado interés en los medios y preocupación entre los administradores de TI y usuarios en general.
El hecho de que esta variante active parte de su funcionalidad ofensiva en el 1ro. de Abril parece haber sido la causa principal del interés que ha despertado esta variante. Sin embargo, un análisis juicioso nos lleva a concluir que esta variante es una de las menos malignas de la familia de Conficker, he aqui las razones:
Debido a estas razones, tenemos menos que temer de Conficker.D que de las otras variantes que componen la familia, siendo esta variante, junto con Conficker.A las menos peligrosas de la familia Conficker, y las dos únicas variables que utilizan un solo vector de infección (la explotación de la vulnerabilidad descrita en MS08-067) para propagarse.
Nuestras recomendaciones siguen siendo las mismas anteriormente descritas y nuestras soluciones de antimalware son capaces de detectar esta variante al utilizar las nuevas definiciones disponibles. Esto incluye Windows Live One Care, los productos Forefront y la versión gratuita del examen de seguridad de Windows Live.
Si Ud. cree que pueda estar infectado con este gusano, contacte a Microsoft en http://support.microsoft.com/contactus
Roberto
Hola,les escribe Roberto Arbeláez.
Ya hay indicios sobre la aparición de código de prueba de concepto (POC – Proof of Concept) que trata de explotar la vulnerabilidad CVE2012-002. Esta vulnerabilidad hace posible la ejecución remota de código explotando una debilidad en el protocolo RDP – Remote Desktop Protocol.
Aunque aún no ha sido confirmada por Microsoft, la aparición del código de prueba de concepto ha sido documentada en la web en artículos como éste de Sophos, y éste de Threat Post. La generación de una prueba de concepto que demuestre la viabilidad de explotación de una vulnerabilidad es un paso previo al desarrollo de un código de explotación que funcione de manera confiable.
Debido a que la vulnerabilidad es potencialmente explotable por un gusano autoreplicante, es posible que en el futuro cercano / mediano, aparezca malware de éste tipo que explote la vulnerabilidad de manera automática, posiblemente llevando a que se presenten infecciones masivas.
Esta vulnerabilidad ya fue parchada por el boletín de seguridad de Microsoft MS12-020, publicado el Martes 13 de Marzo de 2012, por lo que es necesario que todos nuestros clientes instalen esta actualización en sus sistemas lo mas pronto posible.
¿Que debo hacer para protegerme?
Cómo protegerme: Implementando de inmediato las soluciones temporales
Las soluciones temporales no corrigen la vulnerabilidad subyacente pero ayudan a bloquear los tipos de ataque conocidos antes de aplicar la actualización. Microsoft ha probado las siguientes soluciones temporales:
Solución #1: Deshabilitar Terminal Services, Escritorio remoto, Asistencia remota y la característica Lugar de trabajo remoto en Web de Windows Small Business Server 2003 si ya no se necesitan
Cómo deshabilitar Escritorio remoto manualmente: Deshabilitar Escritorio remoto
Cómo deshabilitar Escritorio remoto mediante Directiva de grupo: artículo 306300 de Microsoft Knowledge Base
Cómo deshabilitar Asistencia remota manualmente y con Directiva de grupo, vea el artículo de TechNet Asistencia remota.
Cómo deshabilitar Terminal Services y Lugar de trabajo remoto en Web de Windows Small Business Server 2003: Proteger la red de Windows Small Business Server 2003.
Solución # 2: Bloquear el trafico entrante al puerto TCP 3389 en el firewall perimetral de la empresa
El puerto 3389 se usa para iniciar una conexión con el componente afectado. Al bloquear este puerto en el firewall perimetral de la red, se contribuirá a proteger los sistemas situados detrás del firewall frente a los intentos de aprovechar esta vulnerabilidad. Esto puede proteger a las redes de los ataques que se originan fuera del perímetro de la empresa.
Para Windows XP y Windows 2003 Server: En Windows XP y Windows Server 2003, el Firewall de Windows puede proteger los sistemas individuales. De forma predeterminada, Firewall de Windows no permite conexiones a este puerto, menos en Windows XP Service Pack 2 cuando la característica de Escritorio remoto está habilitada. Para obtener información acerca de cómo deshabilitar la excepción de Firewall de Windows para Escritorio remoto en estas plataformas, vea el artículo de TechNet Habilitar o deshabilitar la regla de firewall de Escritorio remoto.
Para Windows Small Business Server 2003: Windows Small Business Server 2003 usa una característica denominada Lugar de trabajo remoto en Web. Esta característica usa el puerto TCP 4125 para escuchar conexiones RDP. Si usa esta característica, debe validar que este puerto también esté bloqueado para Internet además del puerto 3389.
Nota Es posible cambiar manualmente los componentes afectados para que usen otros puertos. Si ha realizado estas acciones, también debe bloquear esos puertos adicionales.
Solución #3: Habilitar la autenticación de nivel de red en sistemas que ejecuten ediciones compatibles de Windows Vista, Windows 7, Windows Server 2008 y Windows Server 2008 R2
Puede habilitar la autenticación de nivel de red para impedir que los atacantes no autenticados aprovechen esta vulnerabilidad. Con la autenticación de nivel de red activada, un atacante primero debería autenticarse en Servicios de Escritorio remoto mediante una cuenta válida en el sistema de destino para que pudiera aprovechar la vulnerabilidad.
En el artículo 2671387 de Microsoft Knowledge Base hay disponible una solución Microsoft Fix it que automáticamente habilita esta solución temporal.
Para usar la autenticación de nivel de red, el entorno debe cumplir los siguientes requisitos:
Consecuencias de la solución provisional. Los equipos cliente que no admiten el protocolo de proveedor de compatibilidad para seguridad de credenciales (CredSSP) no podrán obtener acceso a los servidores protegidos con la autenticación de nivel de red. Nota Para los administradores que implementen esta solución provisional en un entorno de red mixto donde los sistemas Windows XP Service Pack 3 deban usar Escritorio remoto, vea el artículo de Microsoft Knowledge Base 951608 para obtener información acerca de cómo habilitar CredSSP en Windows XP Service Pack 3.
Para obtener más información acerca de la autenticación de nivel de red, incluido el modo de habilitar dicha autenticación mediante Directiva de grupo, vea el artículo de Technet Configurar la autenticación de nivel de red para las conexiones de Servicios de Escritorio remoto.
Cómo protegerme: Instalando la actualización tan pronto sea posible
Las actualizaciones de seguridad se pueden descargar del Catálogo de Microsoft Update. Microsoft siempre recomienda a sus clientes hacer pruebas en un laboratorio / entorno de pruebas controlado antes de liberar sus actualizaciones en el entorno de producción. En el caso de esta actualización, recomendamos darle la más alta prioridad, de manera que sea probada y liberada en producción lo antes posible.
Como siempre, si tiene problemas al bajar o instalar la actualización MS12-020 o cualquier otra actualización, o problemas después de instalarlas, tiene derecho a recibir soporte gratuito de seguridad Microsoft. el soporte lo pueden obtener aqui:
Hola todos, les escribe Roberto Arbeláez.
El 17 de Septiembre liberamos el Documento informativo de Seguridad 2416728 acerca de una vulnerabilidad de seguridad en ASP.NET. Esta vulnerabilidad existe en todas las versiones de ASP.NET.
Recomendamos que todos los clientes apliquen de inmediato una solución temporal (que se describe a continuación) para impedir que los atacantes utilicen esta vulnerabilidad contra sus aplicaciones ASP.NET.
A continuación, información detallada y preguntas frecuentes sobre esta vulnerabilidad, tomada del blog de Scott Guthrie.
¿Qué permite la vulnerabilidad?
El atacante que utiliza esta vulnerabilidad puede solicitar y descargar archivos dentro de una Aplicación ASP.NET como el archivo web.config (el cual con frecuencia contiene datos confidenciales).
El atacante que explota esta vulnerabilidad también puede descifrar los datos que se envían al cliente en un estado cifrado (como los datos ViewState dentro de una página).
Cómo funciona la vulnerabilidad
Para comprender cómo funciona esta vulnerabilidad, necesita saber acerca de los oráculos criptográficos (cryptographic oracles). Un oráculo en el contexto de la criptografía es un sistema que ofrece pistas mientras usted formula preguntas. En este caso, existe una vulnerabilidad en ASP. NET la cuál actúa como un oráculo de relleno (padding oracle). Esto permite que el atacante envíe texto cifrado al servidor Web y sepa si se descifró correctamente al examinar qué código de error devolvió el servidor Web. Al realizar varias solicitudes (y observar qué errores se devolvieron) el atacante puede saber lo suficiente para descifrar con éxito el resto del texto cifrado.
Cómo resolver temporalmente la vulnerabilidad
Una solución temporal que usted puede utilizar para prevenir esta vulnerabilidad es habilitar la característica <customErrors> de ASP.NET, y configurar explícitamente sus aplicaciones para que siempre devuelvan la misma página de error, sin importar el error que se genere en el servidor. Al redireccionar todas las páginas de error a una página de error única, usted impide que el atacante pueda diferenciar entre los diferentes tipos de errores que ocurren en el servidor.
Importante: No basta simplemente con activar CustomErrors o configurarla en RemoteOnly. También necesita asegurarse de que todos los errores están configurados para devolver la misma página de error. Esto requiere que usted establezca explícitamente el atributo “defaultRedirect” en la sección <customErrors> y se asegure de que no esté establecido ningún código por estado.
Cómo habilitar la solución temporal en ASP.NET V1.0 a V3.5
Si usted utiliza ASP.NET 1.0, ASP.NET 1.1, ASP.NET 2.0 o ASP.NET 3.5 entonces debe seguir los pasos a continuación para habilitar <customErrors> y correlacionar todos los errores a una página de error única:
1) Edite el archivo raíz Web.Config de su Aplicación ASP.NET. Si el archivo no existe, entonces cree uno en el directorio raíz de la aplicación.
2) Cree o modifique la sección <customErrors> del archivo web.config para establecer las configuraciones a continuación:
<configuration> <system.web> <customErrors mode="On" defaultRedirect="~/error.html" /> </system.web> </configuration>
3) Posteriormente usted puede agregar un archivo error.html a su aplicación que contenga la página de error de su elección (que incluya el contenido que usted desee). Este archivo aparecerá cada vez que ocurra un error dentro de la aplicación Web.
Notas: Lo importante que se debe observar de lo anterior es que customErrors está establecido en “activo”, y que todos los errores se manejan a través de la página de error defaultRedirect. No hay ninguna página de error código por estado definida, lo cual significa que no hay sub-elementos <error> dentro de la sección <customErrors>. Esto impide que el atacante pueda diferenciar por qué ocurrió un error en el servidor, e impide que se divulgue la información.
Cómo habilitar la solución temporal en ASP.NET V3.5 SP1 y ASP.NET 4.0
Si usted utiliza ASP.NET 3.5 SP1 o ASP.NET 4.0 entonces debe seguir los pasos a continuación para habilitar <customErrors> y redireccionar todos los errores a una página de error única:
2) Cree o modifique la sección <customErrors> del archivo web.config para establecer las configuraciones a continuación. Observe el uso de redirectMode=”ResponseRewrite” con .NET 3.5 SP1 y .NET 4.0:
<configuration> <system.web> <customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/error.aspx" /> </system.web> </configuration>
3) Posteriormente usted puede agregar un archivo Error.aspx a su aplicación que contiene la página de error apropiada de su elección (que incluye el contenido que usted desea). Este archivo aparecerá cada vez que ocurra un error dentro de la aplicación Web.
4) Recomendamos agregar el siguiente código al manejador de eventos de servidor Page_Load() dentro del archivo Error.aspx para agregar un retraso pequeño de hibernación aleatorio. Esto ayudará a ofuscar más a fondo los errores.
Versión VB
A continuación se encuentra la versión VB de un archivo Error.aspx que usted puede utilizar, y el cual tiene un retraso pequeño de hibernación aleatorio en él. No necesita compilarlo en una aplicación, simplemente puede guardar este archivo Error.aspx en el directorio de la aplicación en su servidor Web:
<%@ Page Language="VB" AutoEventWireup="true" %> <%@ Import Namespace="System.Security.Cryptography" %> <%@ Import Namespace="System.Threading" %> <script runat="server"> Sub Page_Load() Dim delay As Byte() = New Byte(0) {} Dim prng As RandomNumberGenerator = New RNGCryptoServiceProvider() prng.GetBytes(delay) Thread.Sleep(CType(delay(0), Integer)) Dim disposable As IDisposable = TryCast(prng, IDisposable) If Not disposable Is Nothing Then disposable.Dispose() End If End Sub </script> <html> <head runat="server"> <title>Error</title> </head> <body> <div> Lo sentimos – ocurrió un error </div> </body> </html>
Versión C#
A continuación se encuentra la versión C# de un archivo Error.aspx que usted puede utilizar, y el cual tiene un retraso pequeño de hibernación aleatorio en él. No necesita compilar éste en una aplicación, de otra manera simplemente puede guardarlo en el directorio de la aplicación en su servidor Web:
<%@ Page Language="C#" AutoEventWireup="true" %> <%@ Import Namespace="System.Security.Cryptography" %> <%@ Import Namespace="System.Threading" %> <script runat="server"> void Page_Load() { byte[] delay = new byte[1]; RandomNumberGenerator prng = new RNGCryptoServiceProvider(); prng.GetBytes(delay); Thread.Sleep((int)delay[0]); IDisposable disposable = prng as IDisposable; if (disposable != null) { disposable.Dispose(); } } </script> <html> <head runat="server"> <title>Error</title> </head> <body> <div> Un error ocurrió al procesar su solicitud. </div> </body> </html>
Cómo verificar si la solución temporal está habilitada
Una vez que aplique la solución temporal anterior, puede probarla para asegurarse de que la sección <customErrors> está correctamente configurada al acceder a una URL como ésta en su sitio: http://misitio.com/paginaquenoexiste.aspx (reemplace “misitio.com” por la dirección de su sitio web)
Si usted ve que aparece la página de error personalizada (porque la página “paginaquenoexiste.aspx” que usted solicitó no existe) entonces su configuración está correctamente establecida. Si ve un error estándar de ASP.NET, entonces es probable que haya omitido uno de los pasos anteriores. Para ver más información acerca de lo que podría estar causando el problema, puede probar la configuración <customErrorsmode=”remoteOnly”/>, la cual le permitirá ver el mensaje de error si usted se conecta al sitio desde un explorador local.
Cómo encontrar aplicaciones ASP.NET vulnerables en su servidor Web
Publicamos una secuencia de comandos .vbs que usted puede guardar y ejecutar en su servidor Web para determinar si hay aplicaciones ASP. NET instaladas en él que tengan desactivado <customErrors>, o qué mensajes de error diferentes dependiendo de los códigos de estado.
Usted puede descargar la secuencia de comandos .vbs aquí. Simplemente copie/pegue la secuencia de comandos en un archivo de texto de nombre “DetectCustomErrors.vbs” y guárdelo en una unidad de almacenamiento (disco duro) local. Posteriormente lance una ventana de comando que esté elevada como administrador y ejecute “cscript DetectCustomErrors.vbs” para ejecutarla contra su servidor Web local. Enumerará todas las aplicaciones dentro de su servidor Web y verificará que se haya especificado la configuración <customErrors> correcta.
Marcará cualquier aplicación donde encuentre que el archivo web.config de una aplicación no tiene la sección <customErrors> (en cuyo caso será necesario que lo agregue), o que no lo tiene establecido correctamente para solucionar temporalmente este ataque (en cuyo caso será necesario que lo actualice). Imprimirá “ok” para cada archivo web.config de la aplicación que encuentre que está bien. Se espera que esto facilite localizar los programas.
Nota: Desarrollamos esta secuencia de comandos de detección en las últimas horas, y la afinaremos más a fondo en el futuro. Se publicará una actualización cada vez que realicemos algún cambio a ella.
Preguntas frecuentes acerca de la vulnerabilidad de seguridad de ASP.NET
A continuación encontrará respuestas a algunas preguntas comunes que han formulado muchas personas respecto a la vulnerabilidad.
¿Microsoft va a liberar una actualización para reparar la vulnerabilidad?
Sí. Estamos trabajando en una actualización para ASP.NET que liberaremos a través de Windows Update una vez que se haya probado completamente y esté lista para su extensa distribución.
Hasta que la actualización esté disponible, también publicaremos los detalles sobre las soluciones temporales (como la que se describe en esta publicación) que se pueden aplicar de inmediato para ayudar a protegerse contra la vulnerabilidad. Observe que las soluciones son temporales, y no se requerirán una vez que la actualización repare la vulnerabilidad en los productos subyacentes. Tienen como objetivo ofrecer pasos que usted puede emprender de inmediato hasta que la actualización esté disponible.
¿Se trata de un problema en ASP.NET o de alguna vulnerabilidad criptográfica?
Ésta vulnerabilidad existe debido a la manera como ASP.NET utiliza la criptografía en ciertas circunstancias, que permite filtraciones de información por “canales alternativos” (side channels), también conocidos en seguridad como “covert channels”, a través de las respuestas de error. El uso actual de ASP.NET del encryption padding proporciona información en las respuestas de error que puede utilizar alguien malintencionado para atacar al sistema. Repararemos esta vulnerabilidad en la actualización de seguridad.
¿Esto afecta tanto a los formularios Web Forms de ASP.NET como a MVC de ASP.NET?
Sí, la explotación que se reveló públicamente se puede utilizar contra todos los tipos de Aplicaciones ASP.NET (incluyendo tanto formularios Web Forms como MVC).
¿Esto afecta a SharePoint?
Sí, la explotación que se reveló públicamente también se puede utilizar contra SharePoint 2010. El equipo de SharePoint recientemente publicó un artículo en su blog que describe una solución temporal que usted puede aplicar hasta que liberemos la actualización de seguridad.
¿Cómo se vería un ataque en la red o en mis registros?
La explotación que se reveló públicamente provocaría que el servidor Web generara miles (o probablemente docenas de miles) de respuestas de error HTTP 500 y 404 a las solicitudes de un cliente malintencionado.
Usted puede utilizar filtros de control de estado en su firewall o sistemas de detección de intrusiones en su red para detectar dichos patrones y bloquear tales clientes. El módulo Restricciones dinámicas de IP respaldadas por IIS 7 también se pueden utilizar para bloquear estos tipos de ataques.
Un intento de ataque como éste también debe generar miles de alertas en el registro de eventos de la aplicación de su servidor similar a:
Event code: 3005 Event message: An unhandled exception has occurred. Event time: 11/11/1111 11:11:11 AM Application information: Application domain: c1db5830-1-129291000036654651 Application Virtual Path: / Exception information: Exception type: CryptographicException Exception message: Padding is invalid and cannot be removed.
Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 11/11/1111 11:11:11 AM
Application information:
Application domain: c1db5830-1-129291000036654651
Application Virtual Path: /
Exception information:
Exception type: CryptographicException
Exception message: Padding is invalid and cannot be removed.
Es importante resaltar que también pueden haber razones no asociadas con ataques para ver este tipo de errores (incluyendo los casos en los que se tengan llaves no concordantes –mismatching keys- en una granja Web, o en los casos en los que un motor de búsqueda siga vínculos de forma incorrecta, etc.), de manera que la presencia de este tipo de errores no indica necesariamente un ataque.
La excepción tampoco implica que el ataque haya sido exitoso. La implementación de la solución temporal <customErrors> que proporcionamos puede proteger su aplicación contra la explotación, y garantizará que estas excepciones no divulguen información que el atacante pueda utilizar contra la aplicación.
¿Qué hace la solución temporal <customErrors>?
La solución temporal descrita anteriormente en este mismo artículo puede ser utilizada para proteger su aplicación contra la explotación al habilitar la característica <customErrors> de ASP.NET, y configurar explícitamente sus aplicaciones para siempre devolver la misma respuesta de error, sin importar el error que se encuentre en el servidor. Al redireccionar todas las páginas de error a una página de error única, usted puede dificultar que un atacante utilice la explotación para distinguir entre los diferentes tipos de errores que ocurren en un servidor.
Si usted utiliza .NET Framework versión 3.5 SP1 o 4.0, la solución temporal ofrece mayor protección al ayudar también a mitigar los ataques potenciales asociados a análisis de tiempo. La solución temporal utiliza la opción redirectMode="ResponseRewrite" en la característica customErrors e introduce un retraso aleatorio en la página de error. Estas dos soluciones trabajan juntas para dificultar que un atacante deduzca el tipo de error que ocurrió en el servidor al medir el tiempo que tomó recibir el error.
¿Puedo configurar una respuesta personalizada de la página de error 404 y una redirección predeterminada para el resto de los errores?
No. Al hacer esto usted sigue permitiendo que el atacante pueda distinguir entre un error 404 y otros tipos de errores. Lo homogenización de los errores es un componente crucial para mitigar este ataque. Observe que ésta es una solución temporal hasta que haya disponible una actualización de seguridad para reparar la vulnerabilidad del producto subyacente. Esta solución temporal no se requerirá una vez que liberemos la actualización de seguridad.
¿Soy vulnerable si tengo mi propio módulo de error personalizado?
Si las respuestas que se envían desde el módulo de registro personalizado no permiten que el cliente distinga entre las respuestas de error ya sea a través de su contenido, o el tiempo que toma para enviarlas, entonces dicho módulo es un reemplazo adecuado para la solución temporal de customErrors. Estas respuestas incluyen tanto la respuesta HTTP completa como el código de error HTTP. Si algo de lo anterior no se cumple en todo momento, entonces su solución no es suficiente. En su lugar usted debe enviar la misma respuesta de error para todos los errores hasta que la actualización de seguridad esté disponible para reparar la vulnerabilidad subyacente.
¿Me debo preocupar acerca de la vulnerabilidad si no almaceno ninguna información confidencial en mi estado de vista?
Sí, debe hacerlo. Hay una combinación de ataques que se demostró públicamente que pueden permitir fugas del contenido de su archivo web.config, incluyendo cualquier información confidencial no cifrada del archivo. Usted debe aplicar la solución temporal para bloquear el ataque de padding oracle en su etapa inicial del ataque. La actualización de seguridad reparará esta vulnerabilidad.
¿Cuáles son las mejores prácticas para proteger mis datos dentro del archivo web.config?
Siempre es una buena práctica cifrar los datos de configuración confidenciales dentro de los archivos web.config. De esa manera si su archivo web.config alguna vez queda expuesto, los atacantes no pueden utilizar su contenido. Esta documentación de MSDN describe cómo cifrar las secciones de configuración del archivo web.config: http://msdn. microsoft.com/en-us/library/zhhddkxy(VS.80).aspx. Este tutorial también ofrece más muestras de cómo cifrar el contenido del archivo web.config: http://www.4guysfromrolla.com/articles/021506-1.aspx
¿Por qué recibo un error cuando ejecuto la secuencia de comandos .vbs de detección de vulnerabilidades?
Al principio de éste artículo se indicó una secuencia de comandos .vbs que usted puede ejecutar contra un servidor para identificar cualquier aplicación dentro de él que necesite actualizar sus secciones <customErrors> como una solución temporal contra la explosión que se reveló públicamente.
En IIS 7, la secuencia de comandos requiere que usted instale la característica de compatibilidad de administración de IIS 6 para poder utilizar esta secuencia de comandos. Para habilitar esta característica, ejecute Agregar/Quitar programas en la estaciones de trabajo y Agregue los servicios del rol del servidor Web en los sistemas operativos de servidor, y seleccione la característica IIS 6.0 Management Compatibility dentro del área de características “Internet Information Services”. Si esta característica ya está instalada, por favor asegúrese de ejecutar la secuencia de comandos con los privilegios de administrador.
Cómo encontrar más información acerca de esta vulnerabilidad
Usted puede conocer más acerca de esta vulnerabilidad en:
Foro para preguntas
Establecimos un foro dedicado en el sitio www.asp.net para ayudar a responder preguntas acerca de esta vulnerabilidad.
Formule sus preguntas aquí para obtener ayuda acerca de esta vulnerabilidad.
Resumen
Publicaremos más detalles conforme aprendamos más, y liberaremos una revisión que se pueda utilizar para corregir la causa raíz del problema (y evitar la necesidad de la solución temporal anterior).
Hasta entonces, por favor aplique la solución temporal anterior a todas sus aplicaciones ASP.NET para impedir que los atacantes las exploten.
***Esta información fué tomada del artículo publicado en el Blog de Scott Guthrie aqui y de su sección de preguntas frecuentes aqui ***