Anonymous comparte Código para atacar el FBI

Desde el momento que el FBI bloqueo el sitio de MegaUpload, se lanzó una batalla contra el FBI. Anoche, Anonymous, usando como vía de comunicación los seguidores de Twitter (una de las maneras para llegar a sus seguidores), lanzó la operacion Megaupload. De esta manera publicaban sitios que permtía atacar desde diferentes puntos de planeta al sitio del FBI (http://www.fbi.gov/) para producir una DoS, o códigos que podrían ser bajados y ejecutados con el fin de sumar tráfico para intentar producir la DoS al sitio.
Se entiende por DoS, Deny of Service o Denegación de Servicio, al envío masivo de paquetes de cierto tamaño, para que los servidores que deben responder ante una inquietud, colapsen
Para llevarlo más al lenguaje humano, hagan de cuenta, que Ustedes están en la plaza principal de su ciudad, hablando con un amigo, de pronto, 500 personas quieren hablar contigo al mismo tiempo generando miles de preguntas. ¿cómo se sentirían?. Imaginen un servidor Web o con ciertos servicios publicando los mismos a Internet.
Está tecnica es similar a un software que se bajaba en las Pc al comienzo del año 2000, que era un protector de pantalla, en donde se bajaba porciones de sonido cosmico y mientras el protector de pantalla funcionaba, analizaba si no existía conversaciones de extraterrestres.
Para los expertos de seguridad, que quieran analizar los códigos que se generan, les dejo alguno sitios de interes. Los mismo son referenciados para su análisis y no con el fin de sumarse a la causa.

Sitio de ataque : http://www.turbytoy.com.ar/admin/archivos/hive.html
En este sitio, a la derecha podrán observar hasta las cantidad de personas que se han sumado a la ejecución del DoS de este sitio.

Ejemplo de código del site: http://pastebin.com/Gh2Jrd2D

Si prueban el código, recomendamos usarlo en un ambiente aislado para su análisis. Recomendamos no usar los mismos, recuerden que si no conocen de técnicas de spoofing o enmascaramiento, pueden ser detectados, y estas prácticas no son legales.

Actualmente, siguen compartiendo sitios y código para que sea usado contra el sitio del FBI.Estaremos actualizando los estados de seguridad.
Hasta la próxima.

Microsoft Security Update Guide, Second Edition

Esta segunda edición de la Guía de actualización de seguridad de Microsoft incluye contenido adicional que describe cómo Microsoft realiza pruebas de actualizaciones de seguridad antes de su lanzamiento, el asesoramiento y la orientación revisadas en las pruebas de cambios en su propio entorno, y una sección ampliada y actualizada de recursos.
El Objetivo de Microsoft con la guía es ayudar a los profesionales de TI gestionar el riesgo de la organización y desarrollar un mecanismo repetible, la implementación efectiva de las actualizaciones de seguridad.
En la Guía, se encuentra un glosario de términos convenientes, una visión general del proceso de Boletín de seguridad de Microsoft, y una revisión de la etapa por etapa, de Microsoft las actualizaciones de seguridad.
La guía está organizada de acuerdo a las siguientes etapas del proceso de actualización de seguridad:
- Etapa 1, de recepción de seguridad de Microsoft lanzamiento de Comunicaciones,
- Etapa 2, evaluar el riesgo,
- Etapa 3, Evaluación de mitigación,
- Etapa 4, la línea de tiempo Implementación de la actualización estándar o urgente,
- Etapa 5, el Monitor de sistemas, y, la etapa en curso, Watch. Cada sección se describe el propósito y el objetivo de esta etapa, así como los resultados previstos se espera que al finalizar la etapa.

Esta guía está disponible desde este sitio.

Hasta la próxima.

Microsoft SDL - Security Development Lifecycle

Introducción.
El ciclo de vida de desarrollo de seguridad (SDL) es un proceso de control de seguridad orientado al desarrollo de software. Siendo una iniciativa corporativa y una directiva obligatoria desde el año 2004, SDL ha desempeñado un papel muy importante en la integración de la seguridad y de la privacidad en el software y la cultura de Microsoft. Con un enfoque tanto holístico como práctico, SDL tiene como objetivo reducir el número y la gravedad de las vulnerabilidades en el software.

¿Por qué usar SDL?
Es una manera de evitar problemas de seguridad en el desarrollo, como:
- Anticipando Fallas en el Código: esas fallas que se detectan en la ejecución de la aplicación.
- Atacantes atacan todo el código: proteger todo el desarrollo, no solo un componente. Los intrusos atacan todo el software y buscan fallas.
- No enfocarse en “hacerlo bien la próxima vez”: clásica excusa para dejar las mejoras en próximas etapas.
- Remover código viejo: el software se modifica y no hay un proceso de mejora que permita borrar código que ya no forma parte en la nueva versión.
- Eliminar funciones antiguas: mejoradas por otras.
- Reemplazar protocolos viejos
- Problemas de perfomance: permite mejorar el desarrollo, haciéndolo mas perfomante.
- Reconocer que el código fallará y reducir la superficie de ataque.

Conceptos Básicos
El proceso SDL de Microsoft se basa en tres conceptos básicos: formación, mejora continua de los procesos y responsabilidad. La formación continua de los roles técnicos dentro de un grupo de desarrollo de software es fundamental. Si se invierte de manera apropiada en la transferencia de los conocimientos, las organizaciones podrán responder adecuadamente a los cambios que sufren las tecnologías y las amenazas. Dado que los riesgos para la seguridad no son estáticos, SDL destaca especialmente la importancia de comprender la causa y el efecto de las vulnerabilidades de seguridad y requiere una evaluación periódica de los procesos de SDL y la introducción de cambios como respuesta a los avances tecnológicos o las nuevas amenazas. Se recopilan datos para evaluar la eficacia de la formación, se usan métricas de procesos para documentar su conformidad y métricas posteriores al lanzamiento ayudan a definir los futuros cambios. Por último, SDL requiere el archivado de todos los datos necesarios para realizar el mantenimiento de una aplicación en caso de que surjan problemas. Si lo combinan con detallados planes de comunicación y de respuesta en materia de seguridad, las organizaciones podrán orientar de manera concisa y contundente a todas las partes implicadas.

El modelo de optimización de SDL está estructurado en torno a cinco áreas de capacidades que, en líneas generales, se corresponden con las fases del ciclo de vida de desarrollo de software:
1)Formación, directivas y capacidades organizativas
2) Requisitos y diseño
3) Implementación
4) Comprobación
5) Lanzamiento y respuesta

¿Donde aplicar SDL?
Es de vital importancia definir claramente las expectativas de una organización con respecto a los tipos de proyectos que se van a someter a los controles impuestos por el proceso SDL de Microsoft. Por experiencia, se recomienda someter a SDL las aplicaciones con una o varias de las siguientes características:
- Aplicaciones implementadas en un entorno empresarial
- Aplicaciones que procesan información de identificación personal (PII) u otro tipo de información confidencial
- Aplicaciones que se comunican frecuentemente a través de Internet u otras redes
Teniendo en cuenta la propagación de las tecnologías informáticas y la evolución del entorno de amenazas, quizás sea más fácil identificar los proyectos de desarrollo de aplicaciones que no estén sujetos a los controles de seguridad como los de SDL.

Actividades de seguridad simplificadas de SDL
En términos sencillos, el proceso SDL de Microsoft es un conjunto de actividades de seguridad obligatorias, que se presentan en el orden en que deben llevarse a cabo y se agrupan por cada una de las fases de un ciclo de vida de desarrollo de software tradicional. Muchas de las actividades descritas aportarían ciertos beneficios en materia de seguridad si se implementaran de manera independiente. Sin embargo, la experiencia en Microsoft demuestra que las actividades de seguridad realizadas como parte de un proceso de desarrollo de software aportan mayores beneficios que las actividades implementadas de manera poco sistemática o de modo ad hoc.

Actividades de Seguridad Obligatorias
Los diferentes procedimientos están encuadrados en diferentes actividades, como las veremos a continuación.

Formación - Seguridad Básica
Procedimiento 1 de SDL: requisitos de formación
Todos los miembros de un equipo de desarrollo de software deben recibir una formación apropiada con el fin de mantenerse al corriente de los conceptos básicos y últimas tendencias en el ámbito de la seguridad y privacidad. Las personas con roles técnicos (desarrolladores, evaluadores y administradores de programas) que están directamente implicadas en el desarrollo de programas de software deben asistir como mínimo una vez al año a una clase de formación en materia de seguridad.

Primera fase: requisitos
Procedimiento 2 de SDL: requisitos de seguridad
La necesidad de considerar la seguridad y la privacidad "desde el primer instante" es un aspecto fundamental del desarrollo de un sistema seguro. La fase de planificación inicial es el momento más apropiado para definir los requisitos de fiabilidad de un proyecto de software.

Procedimiento 3 de SDL: umbrales de calidad y límites de errores
Se usan umbrales de calidad y límites de errores para establecer niveles mínimos aceptables de calidad en materia de seguridad y privacidad. Al definir estos criterios al comienzo de un proyecto, se comprenderán mejor los riesgos asociados a los problemas de seguridad y los equipos podrán identificar y corregir los errores de seguridad durante el desarrollo.

Procedimiento 4 de SDL: evaluación de los riesgos de seguridad y privacidad
Las evaluaciones de los riesgos de seguridad (SRA) y de privacidad (PRA) son procesos obligatorios que identifican los aspectos funcionales del software que requieren una revisión exhaustiva. Dichas evaluaciones deben incluir la siguiente información:
1. (Seguridad) Partes del proyecto que van a requerir modelos de riesgos antes del lanzamiento.
2. (Seguridad) Las partes del proyecto que van a requerir revisiones del diseño de seguridad antes del lanzamiento.
3.(Seguridad) Partes del proyecto (si procede) que van a requerir pruebas de penetración por parte de un grupo externo al equipo de proyecto y acordado mutuamente.
4. (Seguridad) Requisitos de análisis o de pruebas adicionales que el asesor de seguridad considera necesarios para mitigar los riesgos de seguridad.
5. (Seguridad) Ámbito específico de los requisitos en materia de pruebas de exploración de vulnerabilidades mediante datos aleatorios.
6. (Privacidad) ¿Cuál es el nivel de impacto sobre la privacidad?

Segunda fase: diseño
Procedimiento 5 de SDL: requisitos de diseño
El momento más oportuno para influir en la fiabilidad del diseño de un proyecto es la etapa inicial de su ciclo de vida. Es muy importante que se estudien detenidamente las cuestiones de seguridad y de privacidad durante la fase de desarrollo. La mitigación de los problemas de seguridad y de privacidad es mucho menos costosa si se realiza en la etapa inicial del ciclo de vida de un proyecto. Los equipos de proyecto deben evitar abordar deprisa y corriendo las características de seguridad y de privacidad y las mitigaciones cerca del final del desarrollo de un proyecto.
Además, es de suma importancia que los equipos de proyecto entiendan la diferencia entre "características seguras" y "características de seguridad". Es perfectamente posible que se implementen características de seguridad que, en realidad, son inseguras. Las características seguras se definen como características cuya funcionalidad está debidamente diseñada con respecto a la seguridad, incluida una rigurosa validación de todos los datos antes de su procesamiento o una implementación criptográficamente robusta de bibliotecas para los servicios de cifrado. El término características de seguridad describe la funcionalidad de un programa que tiene implicaciones para la seguridad, como la autenticación Kerberos o un firewall.

Procedimiento 6 de SDL: reducción de la superficie de ataques
La reducción de la superficie de ataques está estrechamente relacionada con los modelos de riesgos, si bien aborda los problemas de seguridad desde una perspectiva ligeramente diferente. La reducción de la superficie de ataques es una forma de reducir el riesgo dando a los atacantes menos oportunidades para aprovechar un posible punto débil o una posible vulnerabilidad. Para reducir la superficie de ataques, se cierra o se restringe el acceso a los servicios del sistema, se aplica el principio de privilegios mínimos o se usan en la medida de lo posible defensas por capas.

Procedimiento 7 de SDL: modelos de riesgos
Los modelos de riesgos se usan en entornos donde existe un riesgo significativo para la seguridad. Este procedimiento permite a los equipos de desarrollo considerar, documentar y describir de manera estructurada las implicaciones para la seguridad de los diseños en el marco de su entorno operativo previsto. Los modelos de riesgos también permiten estudiar los problemas de seguridad en el nivel de los componentes o aplicaciones. La creación de un modelo de riesgos es un trabajo de equipo que implica a los administradores de programas o proyectos, desarrolladores y evaluadores; además, es la principal tarea de análisis de seguridad que se realiza en la fase de diseño del software.

El método preferido para generar modelos de riesgos es la herramienta de creación de modelos de riesgos de SDL. Esta herramienta se basa en la taxonomía de la clasificación de amenazas según el método STRIDE.

Tercera fase: implementación
Procedimiento 8 de SDL: usar herramientas aprobadas
Todos los equipos de desarrollo deben definir y publicar una lista de las herramientas aprobadas y de las comprobaciones de seguridad asociadas, como las advertencias y las opciones del compilador o del vinculador. Esta lista la debe aprobar el asesor de seguridad del equipo de proyecto. En términos generales, los equipos de desarrollo deben procurar usar la versión más reciente de las herramientas aprobadas a fin de aprovechar las nuevas protecciones y funciones de análisis de seguridad.

Procedimiento 9 de SDL: prohibir funciones no seguras
Un gran número de las funciones y API de uso común no son seguras de cara al actual entorno de amenazas. Los equipos de proyecto deben analizar todas las funciones y API que se van a usar con un proyecto de desarrollo de software y prohibir las que consideran inseguras. Una vez determinada la lista de funciones prohibidas, los equipos de proyecto deben usar archivos de encabezado (por ejemplo, banned.h y strsafe.h), compiladores más recientes o herramientas de análisis de código para comprobar si hay funciones prohibidas en el código (incluido código heredado si procede) y reemplazarlas por alternativas más seguras.

Procedimiento 10 de SDL: análisis estático
Los equipos de proyecto deben realizar un análisis estático del código fuente. Este tipo de análisis permite revisar el código de seguridad de forma escalable y contribuye a asegurar que se observan las directivas de codificación segura. En general, por sí solo, el análisis de código estático no puede reemplazar una revisión de código manual. El equipo de seguridad y los asesores de seguridad deben ser conscientes de las ventajas y desventajas de las herramientas de análisis estático y deben estar preparados para ampliar dichas herramientas con otras o con la revisión humana, según procede.

Cuarta fase: comprobación
Procedimiento 11 de SDL: análisis dinámico de los programas
Es necesario comprobar los programas de software en tiempo de ejecución para asegurar que su funcionalidad sea acorde con el diseño. Esta tarea de comprobación debe especificar las herramientas que supervisan el comportamiento de las aplicaciones para detectar si la memoria está dañada, si hay problemas con los privilegios de los usuarios u otro tipo de problemas de seguridad críticos. El proceso SDL usa herramientas en tiempo de ejecución como AppVerifier, junto con otras técnicas como pruebas de exploración de vulnerabilidades mediante datos aleatorios, para lograr los niveles de cobertura deseados de las pruebas de seguridad.

Procedimiento 12 de SDL: pruebas de exploración de vulnerabilidades mediante datos aleatorios
Este tipo de pruebas es una forma especializada de análisis dinámico que se usa para provocar errores en los programas introduciendo deliberadamente datos aleatorios o de formato incorrecto en una aplicación. Esta estrategia se deriva del uso previsto de la aplicación y de sus especificaciones funcionales y de diseño. Es posible que el asesor de seguridad requiera un número adicional de estas pruebas o amplíe su ámbito o duración.

Procedimiento 13 de SDL: revisión de los modelos de riesgos y de la superficie de ataques
En muchas ocasiones, una aplicación se desvía de manera significativa de las especificaciones funcionales y de diseño creadas durante las fases de requisitos y de diseño de un proyecto de desarrollo de software. Por ello, es muy importante que se revisen los modelos de riesgos y la medición de la superficie de ataques de una aplicación una vez completado su código. De este modo, se asegura que se toman en consideración los cambios de diseño o de implementación realizados en el sistema y que se revisan y se mitigan los nuevos vectores de ataque creados como resultado de los cambios.

Quinta fase: lanzamiento
Procedimiento 14 de SDL: plan de respuesta a incidentes
Cada lanzamiento de software sujeto a los requisitos de SDL debe incluir un plan de respuesta a incidentes. Incluso los programas sin vulnerabilidades conocidas en el momento de su lanzamiento pueden estar expuestos a nuevas amenazas. El plan de respuesta a incidentes debe incluir:
- Un equipo de ingeniería sostenida identificado o, si el equipo es demasiado reducido para tener recursos de ingeniería sostenida, un plan de respuesta a emergencias en el que se identifica el personal de ingeniería, marketing, comunicaciones y administración que representa el primer punto de contacto en caso de una emergencia de seguridad.

- Contactos con capacidad para tomar decisiones y disponibilidad las 24 horas del día y los 7 días de la semana.

- Planes de servicios de seguridad para código heredado de otros grupos dentro de la organización.

- Planes de servicios de seguridad para código de terceros bajo licencia, incluidos nombres de archivo, versiones, código fuente, datos de contacto de terceros y permiso contractual para realizar cambios (si procede).

Procedimiento 15 de SDL: revisión de seguridad final
La revisión de seguridad final es una inspección deliberada de todas las actividades de seguridad realizadas con una aplicación de software antes de su lanzamiento. Esta revisión la lleva a cabo el asesor de seguridad con ayuda del personal de desarrollo habitual y de los responsables de los equipos de seguridad y de privacidad. La revisión de seguridad final no consiste en "penetrar y parchear", ni tampoco en realizar las actividades de seguridad que se han omitido o se han olvidado. Suele consistir en un estudio de los modelos de riesgos, las solicitudes de excepciones, los resultados de las herramientas y el rendimiento teniendo en cuenta los umbrales de calidad y los límites de errores previamente determinados

Procedimiento 16 de SDL: lanzamiento o archivado
Las versiones RTM (Release To Manufacturing) y RTW (Release To Web) dependen de la finalización del proceso SDL. El asesor de seguridad asignado a la versión debe certificar (mediante la revisión de seguridad final y otros datos) que el equipo de proyecto ha cumplido los requisitos de seguridad. De manera similar, para todos los productos que tienen al menos un componente con el nivel de impacto en la privacidad P1, el asesor de privacidad del proyecto debe certificar que el equipo de proyecto ha cumplido los requisitos de privacidad para que se pueda enviar el software.

Herramientas recomendadas

−SDL Threat Modeling Tool version 3.1.8

http://www.microsoft.com/download/en/details.aspx?id=2955

−Anti-Cross Site Scripting (Anti-XSS) Library

http://msdn.microsoft.com/en-us/security/aa973814

−AppVerifier

http://www.microsoft.com/download/en/details.aspx?id=20028

Bibliografía

Microsoft Security Development Lifecycle Tools
http://www.microsoft.com/security/sdl/adopt/tools.aspx

El ciclo de vida de desarrollo de seguridad de Trustworthy Computing
http://msdn.microsoft.com/es-es/library/ms995349.aspx#EXAA

Microsoft Security Development Lifecycle (SDL) for Line-of-Business Applications
http://msdn.microsoft.com/en-us/library/dd831975.aspx

Fuente: Microsoft. Basado en la Guía "
Implementación simplificada del proceso SDL de Microsoft"

Ley S.O.P.A.

¿Qué es la Ley S.O.P.A?
El Stop Online Piracy Act (Ley de cese a la piratería en línea) también conocida como Ley H.R. 3261; es un proyecto de Ley del representante Lamar S. Smith, y un grupo de copatrocinadores bipartidario formado inicialmente por 12 miembros. El proyecto de ley extiende las competencias del Departamento de Justicia de los Estados Unidos y amplía las capacidades de los propietarios de derechos intelectuales para combatir el tráfico online de contenidos y productos protegidos, ya sea por derechos de autor o de propiedad intelectual.

¿Qué contenidos son afectados?
Entre estos se pueden contar por ejemplo música, películas, libros, obras artísticas y productos copiados o falsificados que no tributan las correspondientes tasas a los propietarios de sus derechos de autoría o invención.

¿Cuál es su alcance?
El proyecto de ley originalmente propuesto permite que tanto el Departamento de Justicia de los Estados Unidos, como los propietarios de derechos intelectuales, puedan obtener órdenes judiciales contra aquellos sitios de internet que permitan o faciliten la violación de los derechos de autor. Dependiendo de quién sea el que solicite la orden judicial, las acciones previstas contra el sitio web podrían incluir:
1) Restricción al acceso a empresas que brindan un servicio de facilitación de pago tales como Paypal o que ofrecen dinero a cambio de colocar publicidad online.
2) Restricción en los buscadores que vinculan con tales sitios.
3) Requerimiento a los proveedores de internet, para que bloqueen el acceso a tales sitios.

¿Penalidades?
El proyecto de ley convierte en un crimen al la difusión de contenido no autorizado o protegidos por copyright, y prevé una pena máxima de cinco años de prisión por cada diez piezas musicales o películas descargadas dentro de los seis meses desde su estreno. El proyecto además brinda inmunidad a todos aquellos proveedores de Internet que voluntariamente lleven a cabo acciones contra tales sitios haciendo además responsable al sitio web infractor de cualquier daño producido al titular de los derechos, incluso sin tener que demostrarlo.

Hay un video en español muy claro, donde explica más sobre la Ley, para accederlo visite este sitio.

Hasta la próxima

Fuente: wikipedia

Actualizaciones plataforma Microsoft - ENERO 2012

Empezamos el año con nuevas actualizaciones para la plataforma Microsoft. El boletín publicado en el día de la fecha contiene siete actualizaciones:

1) MS12-004: Vulnerabilidades en Windows Media podrían permitir la ejecución remota de código (2636391) Esta actualización de seguridad resuelve dos vulnerabilidades de las que se ha informado de forma privada en Microsoft Windows. Las vulnerabilidades podrían permitir la ejecución remota de código si un usuario abre un archivo multimedia especialmente diseñado. Un atacante que aprovechara estas vulnerabilidades podría conseguir el mismo nivel de derechos de usuario que el usuario local. Los usuarios cuyas cuentas estén configuradas con menos derechos de usuario en el sistema correrían un riesgo menor que los que cuenten con derechos de usuario administrativos.
Si bien esta actualización figura como crítica, en los servidores que no se usen archivos de multimedia puede ser desestimado.
CLASIFICACION: CRITICO

2) MS12-001: Una vulnerabilidad en el kernel de Windows podría permitir la omisión de característica de seguridad (2644615) Esta actualización de seguridad crítica resuelve una vulnerabilidad de la que se ha informado de forma privada en Microsoft Windows. La vulnerabilidad podría permitir a un atacante omitir la característica de seguridad de SafeSEH en una aplicación de software. Un atacante podría usar otras vulnerabilidades para aprovechar el controlador de excepciones estructuradas para ejecutar código arbitrario. Solo las aplicaciones de software que se compilaron con Microsoft Visual C++ .NET 2003 se pueden usar para aprovechar esta vulnerabilidad.
CLASIFICACION: IMPORTANTE

3) MS12-002: Una vulnerabilidad en Empaquetador de objetos podría permitir la ejecución remota de código (2603381) Esta actualización de seguridad crítica resuelve una vulnerabilidad de la que se ha informado de forma privada en Microsoft Windows. La vulnerabilidad podría permitir la ejecución remota de código si un usuario abre un archivo legítimo con un objeto empaquetado insertado que se encuentre en el mismo directorio de red que un archivo ejecutable especialmente diseñado. Un intruso que aprovechara esta vulnerabilidad podría conseguir el mismo nivel de derechos de usuario que el usuario que ha iniciado sesión. De esta forma, un intruso podría instalar programas; ver, cambiar o eliminar datos; o crear cuentas nuevas con todos los derechos de usuario. Los usuarios cuyas cuentas estén configuradas con menos derechos de usuario en el sistema correrían un riesgo menor que los que cuenten con derechos de usuario administrativos.
CLASIFICACION: IMPORTANTE

4) MS12-003: Una vulnerabilidad en el subsistema de tiempo de ejecución de cliente-servidor de Windows podría permitir la elevación de privilegios (2646524) Esta actualización de seguridad crítica resuelve una vulnerabilidad de la que se ha informado de forma privada en Microsoft Windows. Esta actualización de seguridad se considera importante para todas las ediciones compatibles de Windows XP, Windows Server 2003, Windows Vista y Windows Server 2008. Todas las ediciones compatibles de Windows 7 y Windows Server 2008 R2 no están afectadas por esta vulnerabilidad.
CLASIFICACION: IMPORTANTE

5) MS12-005: Una vulnerabilidad en Microsoft Windows podría permitir la ejecución remota de código (2584146) Esta actualización de seguridad crítica resuelve una vulnerabilidad de la que se ha informado de forma privada en Microsoft Windows. La vulnerabilidad podría permitir la ejecución remota de código si un usuario abre un archivo de Microsoft Office especialmente diseñado con una aplicación ClickOnce insertada malintencionada. Un intruso que aprovechara esta vulnerabilidad podría conseguir el mismo nivel de derechos de usuario que el usuario local. Los usuarios cuyas cuentas estén configuradas con menos derechos de usuario en el sistema correrían un riesgo menor que los que cuenten con derechos de usuario administrativos.
CLASIFICACION: IMPORTANTE

6) MS12-006: Una vulnerabilidad en SSL/TLS podría permitir la divulgación de información (2643584) Esta actualización de seguridad resuelve una vulnerabilidad que se ha divulgado públicamente en SSL 3.0 y TLS 1.0. Esta vulnerabilidad afecta al protocolo y no es específica del sistema operativo Windows. La vulnerabilidad podría permitir la divulgación de información si un atacante intercepta tráfico web cifrado que se sirva desde un sistema afectado. TLS 1.1, TLS 1.2 y todos los conjuntos de programas de cifrado que no usan el modo CBC no están afectados.
CLASIFICACION: IMPORTANTE

7) MS12-007: Una vulnerabilidad en la biblioteca AntiXSS podría permitir la divulgación de información 2607664) Esta actualización de seguridad resuelve una vulnerabilidad de la que se ha informado de forma privada en la biblioteca antiscripts de sitios de Microsoft (AntiXSS). La vulnerabilidad podría permitir la divulgación de información si un atacante pasa un script malintencionado a un sitio web con la función de saneamiento de la biblioteca AntiXSS. Las consecuencias de la divulgación de dicha información dependen de la naturaleza de la propia información.
CLASIFICACION: IMPORTANTE


Les recordamos que se realizará un Webcast con las explicaciones de las actualizaciones publicadas en este boletín, para asistir al mismo, visite este sitio.

Para los clientes de ambientes corporativos, recomendamos:

1) Implemente el servicio de WSUS, el mismo le permitirá verificar las actualizaciones y hacer un despligue ordenado del mismo.
2) Revise los documentos técnicos en aquellas actualizaciones que puedan impactar en servidores que poseen aplicaciones de tercero. Se recomienda implementar las actualizaciones previamente en un escenario de prueba.
3) Mantenga la plataforma actualizada, es la mejor manera de prevenir problemas de seguridad.

Hasta la próxima.

Fuente: Microsoft.

WebCast Actualizaciones de Seguridad de Enero 2012

En el día de hoy, Microsoft publicará el boletín de seguridad correspondiente al mes de Enero, para aquellos que quieran interiorizarse más sobre estas actualizaciones, en el día de mañana, se realizará un Webcast ampliando los contenidos del boletín.
Para suscribirse al Webcast, visitar esta url.

En la próxima publicación, estaremos dando a conocer las actualizaciones de este mes.

Hasta la próxima!

Adiós a Internet Explorer 6

En varios países de Latinoamérica, muchos de los usuarios de los S.O Ms Windows, aún hoy siguen usando el navegador Internet Explorer 6.0, sobre todo en ambientes corporativos. Esta versión aún perdura, por varias razones:

1) Es la versión que traía consigo el S.O XP y no se procedió actualizarlo.
2) Compatible con sitios Web desarrollados en algunas tecnologías que si bien son compatibles con Internet Explorer 7.0 o posteriores, pero no se desean tocar líneas de código o bien hacer ajustes en algunos de los parámetros de los nuevos navegadores. Muchos de esos parámetros pueden ser desplegados por políticas de Active Directory, reduciendo la carga administrativa en las redes.
3) No se actualizan los S.O. XP por contar con muy bajo recursos de memoria.

Tarde o temprano, deberán actualizar la versión de Internet Explorer que nació en el 2001, sobre todo si desean aprovechar las opciones de seguridad que protegen el ordenador al momento de navegar por Internet.
En Microsoft, se ha desarrollado un plan, que por el momento estará vigente en Australia y Brasil, que permitirá al Ms Windows Update realizar la actualización dle IE 6.0 a la versión IE 8.
La versión de IE 8.0 además de poseer ventajas importantes para el ambiente del desarrollo, posee elementos que permiten ofrecer al usuario una navegación segura.

Dentro de algunas de las ventajas de seguridad del IE 8.0, encontramos:

1) Resaltado del dominio: a medida que el usuario navega por Internet, podrá observar que el nombre de DNS del sitio que está visitando está en negrita. El usuario podrá verificar la dirección del sitio que visita y de esta manera no ser engañado, por ejemplo, por sitios de phising.

2) Filtro SmartScreen: ayuda al usuario a protegerse contra los ataques de suplantación de identidad (phishing) en línea, sitios web simulados o sitios fraudulentos. También analizará las descargas y le avisará al usuario de un posible malware (software malintencionado).

3) El filtro de scripts de sitios (XSS): evita ataques de sitios fraudulentos que podrían intentar robar su información personal y financiera (ataques de phising).

4) Navegación InPrivate: el usuario lo puede usar para visitar la web sin guardar datos relacionados, como cookies, históricos de sitios visitados y archivos temporales de Internet.

5) Filtrado ActiveX: bloquea los controles ActiveX para todos los sitios y permite que, después, usted pueda volver a activarlos sólo para los sitios en los que confía.

6) Notificaciones: advierten si la configuración de seguridad se encuentra por debajo de los niveles recomendados, si bien en versiones anteriores esto estaba disponible, recomendamos siempre tenerlo activo.

El plan establecido, involucra a Internet Explorer 8 que sustituirá automáticamente a IE7 e IE6 en Ms Windows XP que tengan instalado el Service Pack 3 (recordemos que esta es la versión actualmente soportada por Microsoft), mientras que los usuarios de Ms Windows Vista SP2 y Ms Windows 7 recibirán Internet Explorer 9. Por otro lado, recordamos que Ms Windows XP no tiene soporte para IE9, por lo cual quedarán con IE 8.0

Lo cierto es que la actualización es necesaria, sobre todo si queremos mantener los parámetros de seguridad. Para aquellos que aún no saben que impacto puede provocar esta actualización en la compañía, sugerimos:

1) Armar un ambiente de prueba con XP, Vista y Windows 7 (seleccionar el S.O más representativo de la organización) y actualizar el IE a la version IE 8.0
2) Realizar pruebas de acceso a la Intranet y aplicativos Web.
3) Verificar comportamiento en la navegación a Internet y realizar los ajustes necesarios.
4) Verificar el funcionamiento con la opción o modo de "Vista de Compatibilidad".
5) Documentar los ajustes y verificar un despliegue por GPO o políticas de Active Directory.
6) Confeccionar un plan de actualización.

Si requiere de Guías para implementar IE 9 adecuadamente les recomiendo visitar estos sitios:

1) Guía de implementación de Windows® Internet Explorer®, presione AQUI.
2) Kit de administración de Internet Explorer 9, presione AQUI.
3) Internet Explorer 9 Overview, presiona AQUI.



IE 6.0 se nos vá, a ponerse en marcha...
Hasta la próxima.

Fuente : Microsoft

Boletín de seguridad de Microsoft MS11-100 - Crítica

Estimados, hemos comenzado el año con las actualizaciones. A fin del 2011, mas precisamente el 29/12 Microsoft publicó un boletín crítico fuera del período regular de actualizaciones.
Esta actualización de seguridad resuelve una vulnerabilidad de la que se ha informado de forma pública y tres vulnerabilidades de las que se ha informado de forma privada en Microsoft .NET Framework.
La más grave de estas vulnerabilidades podría permitir la elevación de privilegios si un atacante no autenticado envía una solicitud web especialmente diseñada al sitio de destino. Un atacante que consiguiera aprovechar esta vulnerabilidad podría realizar cualquier acción en el contexto de una cuenta existente en el sitio ASP.NET, incluida la ejecución de comandos arbitrarios. Para aprovechar esta vulnerabilidad, el atacante debe poder registrar una cuenta en el sitio ASP.NET y debe conocer un nombre de usuario existente.
Esta actualización de seguridad se considera crítica para Microsoft .NET Framework 1.1 Service Pack 1, Microsoft .NET Framework 2.0 Service Pack 2, Microsoft .NET Framework 3.5 Service Pack 1, Microsoft .NET Framework 3.5.1 y Microsoft .NET Framework 4 en todas las ediciones compatibles de Microsoft Windows.
Para más información sobre dicho boletín, visitar el artículo aquí.

Hasta la próxima.

Fuente: Microsoft