Actualizado: Mitigando la vulnerabilidad de Adobe Reader

Actualización 25-febrero 23:00hs

Desactivar JavaScript NO es una forma efectiva de eliminar el riesgo y ya hay pruebas de concepto que lo confirman como
describe Carsten Eiram en el blog de Secunia.
A continuación nuestra nota corregido y actualizado con las opciones válidas para mitigar el riesgo.

Como se sabe desde la semana pasada Adobe se tomará un tiempo para publicar la solución a la vulnerabilidad que afecta al Adobe Reader y que ya está siendo explotada activamente.

Mientras tanto hay algunas medidas que pueden tomarse para mitigar esta amenaza:

Raúl de la Redaccion de Segu-Info en base a las fuentes mencionadas.

Read the original here: 
Actualizado: Mitigando la vulnerabilidad de Adobe Reader |

Presentaciones de Black Hat DC 2009 disponibles

Se acaban de publicar las presentaciones y algunos videos sobre Black Hat DC 2009 llevada a cabo en Washington DC el pasado 17 y 18 de febrero.

Las presentaciones son las siguientes:

  • Ryan C. Barnett
    WAF Virtual Patching Challenge: Securing WebGoat with ModSecurity
  • Cesar Cerrudo
    SQL Server Anti-Forensics
  • Matthew Flick
    XSS Anonymous Browser
  • Xinwen Fu
    One Cell is Enough to Break Tor’s Anonymity
  • Travis Goodspeed
    Reversing and Exploiting Wireless Sensors
  • Vincenzo Iozzo
    Let Your Mach-O Fly
    Prajakta Jagdale
  • Blinded by Flash: Widespread Security Risks Flash Developers Don’t See
  • Dan Kaminsky
    DNS 2008 and the New (old) Nature of Critical Infrastructure
  • William Kimball
    Emulation-based Software Protection Providing Encrypted Code Execution and Page Granularity Code Signing
  • Paul Kurtz
    Keynote: The Move from Strategic Indecision to Leadership in Cyberspace
  • Brian Krumheuer, Jason Raber
    QuietRIATT: Rebuilding the Import Address Table Using Hooked DLL Calls
  • Adam Laurie
    Satellite Hacking for Fun and Profit
  • Andrew Lindell
    Making Privacy-Preserving Data Mining Practical with Smartcards
  • David Litchfield
    The Forensic Investigation of a Compromised Oracle Database Server
  • Moxie Marlinspike
    New Techniques for Defeating SSL/TLS
  • Michael Muckin
    Windows Vista Security Internals
  • Duc Nguyen
    Your Face Is NOT Your Password
  • Peter Silberman
    Snort My Memory
  • Val Smith, Colin Ames
    Dissecting Web Attacks
  • Michael Sutton
    A Wolf in Sheep’s Clothing: The Dangers of Persistent Web Browser Storage
  • Rafal Wojtczuk & Joanna Rutkowska
    Attacking Intel® Trusted Execution Technology
  • Paul Wouters
    Defending Your DNS in a Post-Kaminsky World
  • Stefano Zanero
    Alternate: Masibty: A Web Application Firewall Based on Anomaly Detection
  • Earl Zmijewski
    Defending Against BGP Man-In-The-Middle Attacks

Cristian de la Redacción de Segu-Info

Read more from the original source:
Presentaciones de Black Hat DC 2009 disponibles |

El SSL no está roto… ¿o sí? (I)

Moxie Marlinspike protagonizó la semana pasada una conferencia en la Black Hat en la que demostraba cómo eludir la autenticación y el cifrado SSL de las páginas supuestamente seguras. El investigador se ha centrado en una inteligente combinación de técnicas que permiten confundir a los usuarios (incluso a los avanzados) sobre si están o no en la página correcta. Ninguna de las técnicas usadas es realmente nueva, pero todas en conjunto forman una excelente herramienta llamada sslstrip.

Sslstrip combina una buena tanda de técnicas con el único objetivo de que el usuario realmente no sepa que está en una web falsa o que su tráfico no está siendo realmente cifrado. Aclarar que el problema no está en el SSL, sigue siendo lo mejor de lo que disponemos para realizar conexiones seguras. El fallo está un poco en los navegadores, un mucho en los usuarios, algo en los certificados, bastante en las redes… pero no en la tecnología en sí.

Como siempre, teniendo en cuenta el éxito del que gozan técnicas mucho más sencillas, sslstrip todavía no será usado por atacantes de forma masiva, sino para ataques muy específicos contra usuarios avanzados. Y estos son quizás los que deban estar más atentos.

Para ser víctima del sslstrip, la primera condición ineludible es que la conexión debe estar siendo interceptada. Bien a través de un envenenamiento de ARP en red interna, bien a través de puntos de acceso wireless falsos… el caso es que el atacante debe actuar como proxy en la comunicación, teniendo acceso al tráfico. Esta es una premisa importante, pero no es extraña. El investigador usó con éxito la red de anonimato Tor para sus pruebas. Sslstrip hace todo en tiempo real, básicamente sustituyendo el tráfico cifrado (https) por uno no cifrado (http), de forma que al usuario se le presenta una página idéntica a la que necesita, pero sin cifrar y probablemente en otro servidor que pertenece al atacante. Acude al servidor real para tomar la información necesaria, pero en vez de devolverla cifrada al usuario, lo hace sin cifrar. Esta es su funcionalidad básica.

En la mayoría de las ocasiones esto sería suficiente para engañar a muchos usuarios. Pero obviamente esto llamaría la atención de otros tantos, que echarían en falta las advertencias que normalmente el navegador realiza cuando se está sobre una página cifrada (el candado, la barra dorada, el https, etc). Marlinspike, en su charla en la Black Hat, dio un buen montón de ideas y métodos para hacer que esto pase desapercibido incluso para los usuarios más avispados.

Una de ellas es la sustitución de un “favicon” de la página por un simple candado. El candado real no aparecería pero en los últimos tiempos se ha abusado tanto de esta imagen que su simple presencia (aunque no sea en el lugar correcto) da sensación de seguridad a los usuarios.

Otra de las técnicas es muy vieja ya. Se basa en el uso de caracteres especiales para hacer pensar al usuario que se encuentra en el dominio correcto. El atacante no tiene más que comprar un certificado válido para ese dominio, y de esta forma se evitarían todas las advertencias del navegador. Solo quien comprobase realmente la cadena de certificación del certificado estaría a salvo.

También presenta otras técnicas para eludir problemas como las cookies de seguridad y el manejo de sesiones autenticadas. Su herramienta tiene soluciones para evitar que el usuario más experimentado note que está siendo víctima de un robo de sus datos.

Otro de los puntos interesantes de la charla que ofreció Marlinspike, además de la presentación de la herramienta (que ha hecho pública), son las reflexiones sobre la seguridad SSL y cómo está implementada en los navegadores, de lo que hablaremos en la siguiente entrega.

Sergio de los Santos
[email protected]

Fuente: Hispasec

View original post here:
El SSL no está roto… ¿o sí? (I) |

Vulnerabilidad en Excel sin parchear

En el día de hoy Microsoft a liberado un boletín de seguridad (968272) respecto a una vulnerabilidad en varias versiones de Microsoft Excel que podría permitir a un atacante la ejecución de código remoto. Hasta el momento, Microsoft manifiesta estar al tanto solo de un número limitado de ataques aislados. Según el boletín, la empresa está trabajando para remediar la vulnerabilidad a través de un parche (en las actualizaciones del próximo mes o, de ser necesario, en una actualización fuera de ciclo).

Las versiones afectadas son las siguientes: Microsoft Office 2000, Microsoft Office 2002, Microsoft Office 2003, Microsoft Office 2007, Microsoft Office 2004 for Mac, and Microsoft Office 2008 for Mac.

Para mitigar los riesgos, hasta la aparición del parche, se recomienda a los usuarios tener en cuenta los siguientes consejos:

  • No abrir archivos de Excel que provengan de fuentes no confiables o que fueron recibidos sin solicitar. La vulnerabilidad no puede explotarse por correo electrónico. Solo es posible si el usuario ejecuta el archivo de Office.
  • Utilizar cuentas de usuario con permisos limitados. Un atacante que logre explotar exitósamente la vulnerabilidad, podrá contar con los mismos permisos que el usuario que ejecute el archivo. Por lo tanto, utilizar usuarios sin permisos administrativos disminuye el riesgo.
  • Las herramientas de Microsoft Office Document Open Confirmation Tool (para Office 2000), Microsoft Office Isolated Conversion Environment (MOICE) y Microsoft Office File Block policy colaboran a mitigar el riesgo.

Hasta la aparición del parche, recomendamos a los usuarios prestar atención a los consejos aquí descritos y estar atentos para actualizar rápidamente, ya que los ataques podrían aumentar luego de la publicación del boletín de Microsoft.

Sebastián – Redaccion de Segu-Info

Original post:
Vulnerabilidad en Excel sin parchear |

Diez equivocaciones que cometen los nuevos administradores Windows

Puede que usted sea un nuevo administrador de red. Tomó algunos cursos, pasó algunos exámenes de certificación, quizás incluso tenga armado un dominio Windows en su casa. Pero pronto encontrará que ser responsable de la red de una compañía trae desafíos que no había anticipado. O quizás ya es una persona experimentada en TI en compañías, pero hasta ahora había trabajado en ambientes UNIX. Ahora, ya sea por un cambio de trabajo o un nuevo desarrollo en su lugar actual de trabajo, se encuentra en el menos familiar mundo de Windows.

Este artículo apunta a ayudarlo a evitar algunos de las equivocaciones más comunes que cometen los nuevos administradores Windows.

  1. Tratar de cambiar todo a la vez

Cuando llega a un trabajo nuevo, o comienza a trabajar con una nueva tecnología, puede que tenga todo tipo de ideas brillantes. Si es nuevo en el lugar de trabajo, mejorará inmediatamente aquellas cosas que su predecesor (ó parece que, ó estaba) haciendo mal. Está lleno de todas las mejores prácticas y trucos que aprendió en la escuela. Si es un administrador que viene de una ambiente diferente, puede que esté acostumbrado a sus propias formas y quiera hacer las cosas de la forma que las hacía antes, en vez de aprovechar la características del nuevo SO.

De cualquier forma, es probable que se cause a usted mismo una gran pena. La mejor opción para alguien nuevo en redes Windows (o para cualquier otro trabajo) es darse un tiempo para adaptarse, observar y aprender, y proceder de forma pausada. Así hará más sencillo su trabajo y de esta forma a largo plazo hará más amigos (o al menos, menos enemigos).

  1. Sobrestimar la capacidad técnica de los usuarios finales

Muchos administradores nuevos esperan que los usuarios tengan una mejor comprensión de la tecnología de la que tienen. No asuma que los usuarios finales comprendan la importancia de la seguridad, o que serán capaces de describir con precisión los errores que tienen, o que saben lo que se quiere decir cuando les dice que realicen una tarea sencilla (para usted) tal como ir al Administrador de Dispositivos y verificar el estado de la placa de sonido.

Mucha gente en el mundo de los negocios usa computadoras todos los días, pero saben muy poco sobre ellas más allá de operar ciertas aplicaciones específicas. Si se frustra con ellos, o los hace sentir estúpidos, la mayoría tratará de evitar llamarlo cuando haya un problema. En lugar de eso lo ignorarán (si pueden) o peor, tratarán de arreglarlo por sí mismos. Eso significa que los problemas podrán ser mucho peores para cuando se de cuenta de ellos.

  1. Subestimar la experiencia técnica de los usuarios finales.

Aunque lo de arriba aplica para muchos de sus usuarios, la mayoría de las compañías tienen al menos algunos que son aficionados avanzados de computación y saben mucho de tecnología. Esos son los que surgirán con maneras innovadoras de sortear las restricciones que ponga si es que estas restricciones les resultan un inconveniente. La mayoría de estos usuarios no son maliciosos; solo están molestos que alguien más controle el uso de sus computadoras, especialmente si los trata como si no supieran nada.

La mejor táctica con estos usuarios es mostrarle que respeta sus habilidades, buscar su colaboración, y hacerles saber los motivos de las reglas y restricciones. Señalar que incluso el mejor corredor de autos que ha demostrado su habilidad por conducir de forma segura a alta velocidad debe soportar los límites de velocidad en las vía publica, y que no es porque se dude de sus habilidades tecnológicas, que usted debe insistir en señalarle a todos que sigan las reglas.

  1. No habilitar la auditoría

Los sistemas operativos Windows Server tienen una auditoría de seguridad propia, pero no está habilitada por defecto. Tampoco es una de las características mejor documentadas, así que algunos administradores no logran aprovecharla. Y es una lástima, porque con las características de auditoría, usted puede llevar registro de los intentos de ingreso (logon), acceso a archivos y otros objetos, y acceso a los servicios de directorio. La auditoría de los Servicios de Dominio de Directorio Activo (AD DS) han sido mejorados en Windows Server 2008 y se pueden hacer ahora de forma más granular. Sin la auditoría propia o de software de terceros, puede ser casi imposible ubicar con exactitud y analizar que pasó en una brecha de seguridad.

  1. No mantener actualizados los sistemas

Esto no requiere pensarse siquiera. Mantener sus servidores y máquinas cliente emparchados con las últimas actualizaciones de seguridad puede ser el camino para prevenir caídas, pérdidas de datos, y otras consecuencias del malware y los ataques. A pesar de ello muchos administradores se retrasan y sus redes están funcionando con sistemas que no están emparchados apropiadamente.

Esto sucede por varias razones. Departamentos de TI recargados y con poco personal sencillamente no consiguen aplicar los parches tan pronto son publicados. Después de todo, no es siempre una cuestión de “solo hacerlo”, todos saben que algunas actualizaciones pueden romper cosas, provocando que toda su red se detenga. Por lo tanto es prudente verificar los nuevos parches en un ambiente de prueba que simule las aplicaciones y configuraciones de su ambiente de red productivo.

Sin embargo, eso lleva tiempo, tiempo que puede que no tenga. Automatizar el proceso tanto como sea posible puede ayudarlo a mantener fluyendo esas actualizaciones. Tenga su red de prueba lista cada mes antes que, por ejemplo, Microsoft publique sus parches regulares. Use los Servicios de Actualización de Windows Server (WSUS) u otra herramienta para simplificar y automatizar el proceso una vez que decidió que el parche es seguro para ser aplicado. Y no olvide que las aplicaciones, no sólo el sistema operativo, también necesitan ser actualizadas.

  1. Volverse descuidado con la seguridad

Muchos administradores fuerzan las mejores prácticas de seguridad para sus usuarios pero se vuelven descuidados con sus propias máquinas. Por ejemplo, profesionales de TI que nunca permiten a los usuarios correr XP usando una cuenta de administrador, no lo tienen en cuenta para ellos mismos mientras realizan tareas rutinarias que no requieren ese nivel de privilegios. Algunos administradores parecen pensar que ellos son inmunes al malware y los ataques porque ellos “saben más”. Pero este exceso de confianza puede llevar al desastre, tal como sucede en el caso de oficiales de policía que tienen la tasa más alta de accidentes con armas de fuego porque estando todo el tiempo alrededor de las armas se vuelven displicentes respecto de los peligros.

  1. No documentar los cambios ni los arreglos

    Documentar es una de las cosas más importantes que usted, como administrador de red, puede hacer para que su propio trabajo sea más sencillo y para facilitárselo a alguien más que ingrese y se haga cargo de la red en su ausencia. Sin embargo esta es una de las tareas más descuidadas de todas las tareas administrativas.

    Puede pensar que recordará que parche aplicó o que cambio de configuración hizo que solucionó un problema exasperante, pero un año después, probablemente no lo recordará. Si documenta sus acciones, no deberá perder tiempo precioso reinventando la rueda (o el arreglo) de nuevo.

    Algunos administradores no quieren documentar lo que hacen porque piensan que si lo tienen todo en su cabeza, serán indispensables. En verdad, nadie nunca es irreemplazable y por hacer más difícil que algún otro aprenda su trabajo, hace menos probable que alguna vez sea promovido de ese trabajo.

    Además, ¿que pasa si es atropellado por un camión mientras cruza la calle? ¿Realmente quiere que la compañía se paralice porque nadie sabe las contraseñas administrativas o tenga idea como ha configurado las cosas y que tareas diarias tiene que realizar para mantener la red en buen funcionamiento?

  1. No probar los respaldos

    Una de las cosas de las cuales se arrepienten más los usuarios hogareños es de olvidar respaldar su información importante y debido a eso lo pierden todo cuando les falla un disco rígido. La mayoría de los profesionales de TI comprenden la importancia de hacer respaldos y lo hacen de forma regular. Lo que algunos administradores muy ocupados no recuerdan hacer es probar regularmente esos respaldos para asegurarse que la información realmente está allí y que puede ser recuperada.

    Recuerde que hacer el respaldo es solo el primer paso. Necesita asegurarse que esos respaldos funcionaran cuando los pueda necesitar.

  1. Prometer lo que no se puede dar y no cumplir con las expectativas

    Cuando su jefe lo presiona por respuestas a preguntas tales como “¿Cuando podrás tener todos los sistemas de escritorio actualizados con la nueva versión del software?” o “¿Cuánto costará tener el nuevo servidor de base de datos instalado y funcionando?”, su tendencia natural puede ser de dar una respuesta que lo haga quedar bien. Pero si hace promesas que no puede cumplir y luego se atrasa o se pasa del presupuesto, se hace a si mismo más un daño que un bien.

    Una buena regla general en cualquier negocio es prometer menos y entregar más en vez de hacer lo opuesto. Si piensa que tomará dos semanas implementar un nuevo sistema, dese un poco de margen y prométalo para dentro de tres semanas. Si está seguro que podrá comprar el nuevo hardware que necesita por $10.000, por las dudas pida $12.000.
    Su jefe quedará impresionado cuando termine el proyecto algunos días antes de tiempo o cuando gaste menos dinero que el esperado.

  1. Tener miedo de pedir ayuda

    El ego es algo divertido, y muchos administradores de TI han invertido mucho en el suyo. Cuando se trata de tecnología, puede que sea reticente en admitir que no lo sabe todo, y por lo tanto tema, o sienta vergüenza, de pedir ayuda. He conocido MCSEs y MVPs que no pueden soportar pedir ayuda a sus colegas porque sienten que se supone que son los “expertos” y que su reputación podría dañarse si admiten lo contrario. Pero lanzarse a un proyecto cuando no sabe lo que está haciendo puede sumergirlo en agua caliente, costarle mucho dinero a la compañía, e incluso costarle a usted su trabajo.

    Si algo lo sobrepasa, esté dispuesto a admitirlo y busque ayuda de alguien con más conocimiento sobre el tema. Puede ahorrarse días, semanas e inclusos meses de fracasos.

Traducido para blog de Segu-Info por Raúl Batista

Autor: Debra Littlejohn Shinder, MCSE, MVP.
Fuente: TechRepublic

See the original post here: 
Diez equivocaciones que cometen los nuevos administradores Windows |