Buscar este blog

viernes, 29 de octubre de 2010

Celular en 1928-Viaje en el tiempo (Chaplin's Circus Premiere Footage)


La película "The Circus" de Charlie Chaplin realizada en 1928 ha causado sensación en Internet debido a que al parecer muestra a una mujer hablando a través de un celular o al menos esa es la impresión que da.

Hay que tomar en cuenta que el "Walkie Talkie" se inventó en 1940 y el celular hasta 1983.

George Clarke analizó la cinta cuadro por cuadro con un zoom especial y fue quien encontró esta fantástica escena.

Aquí les mostramos una edición que se incluye en Youtube por parte de alexxvall1.

Adobe publica aviso de seguridad para Flash Player, Reader y Acrobat

Adobe ha publicado el aviso de seguridad APSA10-05, en el que informa de una vulnerabilidad crítica en Flash Player, Reader y Acrobat, que permite a un atacante remoto tomar el control de los sistemas afectados. Adobe confirma que se está explotando de forma activa en Adobe Reader y Acrobat 9.x.

Se encuentran afectadas las versiones de Adobe Flash Player 10.1.85.3 para Windows, Macintosh, Linux y Solaris; Adobe Flash Player 10.1.95.2 para Android; y el componente authplay.dll incluido en Adobe Reader 9.4  para Windows, Macintosh y UNIX, y Adobe Acrobat 9.4 para Windows y Macintosh.

Adobe no ha facilitado detalles del problema, ya que por el momento confirma que está trabajando en el desarrollo de una actualización para corregir este problema. Para Flash Player espera ofrecer esta corrección el 9 de noviembre mientras que los usuarios de Adobe Reader y Acrobat deberán esperar a la semana del 15 de noviembre.

Para evitar los ataques Adobe publica en su boletín una serie de contramedidas, que pasan por eliminar, renombrar o impedir el acceso a authplay. Para Windows basta con cambiar el archivo authplay.dll localizado en C:\Program Files\Adobe\Reader 9.0\Reader\authplay.dll for o C:\Program Files\Adobe\Acrobat 9.0\Acrobat\authplay.dll.

Se recomienda consultar el boletín donde se explican detalladamente los procesos a seguir para cada sistema operativo afectado. http://www.adobe.com/support/security/advisories/apsa10-05.html

Si quieren más información pueden visitar: http://www.hispasec.com/unaaldia/4387

jueves, 28 de octubre de 2010

¿Cómo enfriar una cerveza en 3 minutos?

Como siempre estamos al servicio de la comunidad con información útil e indispensable jajaja

La carne ya está en la parrilla

 

Entonces, llegan los amigos con latas y más latas de 
cerveza, estúpidamente calientes. ¿Cómo las enfriamos?
 

El profesor Cláudio Furukawa, del Instituto de Física de la 
Universidad de Sao Paulo lo explica.


Ponga el hielo en la hielera....


Agregue 2 litros de agua por cada bolsa de hielo


...agregue medio kilo de sal 


y medio litro de alcohol 


El agua aumenta la superfície de contacto, la sal reduce la temperatura de fusión del hielo (tarda más en derretirse) y por una reacción química, el alcohol retira el calor de la mezcla.
Algunos llaman a este líquido "mezcla frigorífica"
HIELO, ALCOHOL, SAL y AGUA


La mezcla frigorífica es barata y la cerveza queda helada en solo 3 minutos.
Y esperar 3 minutos no es ningún sacrifício, ¿verdad?


Pasen esta información de utilidad pública.

0-day en Firefox explotado activamente

Se ha detectado la explotación activa de una vulnerabilidad desconocida que afecta a Firefox en las versiones 3.5 y 3.6.

El 0-day fue descubierto por el equipo de Trend-Micro, mismo que informó que el sitio web oficial de los Premios Nobel había sido comprometido y que los atacantes habrían insertado un script PHP malicioso denominado "JS_NINDYA.A", con objeto de propagar malware.

El script determina si va a explotar o no la vulnerabilidad a través de la lectura del campo User-agent, del que extrae la información sobre el navegador y del sistema operativo. En caso de explotarla procede a descargar el troyano BKDR_NINDYA.A a la computadora de la víctima.

El script afecta al navegador Firefox en las versiones 3.5 y 3.6, aunque tan solo intenta su explotación en la versión 3.6 sobre Windows en versiones anteriores a Vista.

Mozilla está trabajando en una solución para esta vulnerabilidad, en breve podría estar disponible una nueva versión del navegador. Recomiendan el uso de la extensión NoScript para mitigar el riesgo de exposición hasta que la solución vea la luz.

Si quieren más información pueden visitar: http://www.hispasec.com/unaaldia/4386

miércoles, 27 de octubre de 2010

Actualización para IBM WebSphere Application ServerSi quieren más información pueden visitar:

Se ha publicado una actualización de IBM WebSphere Application Server (versiones anteriores a 7.0 Fix Pack 13) destinada a corregir cuatro vulnerabilidades que permiten la realización de ataques de cross-site scripting y cross-site request forgery.

El primer problema está provocado por errores de validación de entradas en la consola Integrated Solution Console, que permite la construcción de ataques de cross-site scripting y de inyección de URL. Otras dos vulnerabilidades se deben a errores de validación de entradas en la consola administrativa, que podrían permitir llevar a cabo ataques de cross-site scripting y cross site request forgery.

La última vulnerabilidad reside en un error no detallado del componente de Seguridad y podría permitir llevar a cabo ataques de cross-site scripting. 

Se recomienda la actualización a IBM WebSphere Application Server version 7.0 Fix Pack 13 (7.0.0.13): http://www.ibm.com/support/docview.wss?uid=swg24027977 

Si quieren más información pueden visitar: http://www.hispasec.com/unaaldia/4385

martes, 26 de octubre de 2010

Éxitos y fracasos de Stuxnet (III)

Después de reflexionar sobre las características de este malware, han consultado la base de datos en VirusTotal, buscando referencias sobre Stuxnet para comprobar su evolución. Nos hemos llevado algunas sorpresas.

Por ejemplo, según la base de datos de Virustotal, la primera referencia a Stuxnet viene el 1 de julio de 2009. Sí, 2009 (Stuxnet saltó a los medios en julio de 2010). Pero no es el troyano como tal. Lo que encontraron entonces son las primeras referencias a malware que aprovecha una vulnerabilidad por entonces llamada simplemente por algunos antivirus "Autorun". Solo era detectado por 6 motores. Lo que no sabían, es que esta sería la vulnerabilidad que más tarde se calificaría como CVE-2010-2568, y que permitía a Stuxnet la ejecución de código a través de enlaces LNK. En pocas palabras: esta vulnerabilidad era conocida desde hacía más de un año y, aunque algunos motores la detectaban entonces, no descubrieron que era "nueva". La metieron en el saco de malware genérico que se ejecutaba a través del Autorun. Tuvo que entrar en escena Stuxnet para que se analizase, saliera a la luz y fuera corregida.

Las primeras muestras en aprovechar esta falla vienen desde Vietnam, China y una casa antivirus en el Reino unido en julio de 2009. Se siguen recibiendo muestras durante todo 2009 y 2010, y no es hasta julio de 2010 que es ampliamente reconocida como lo que realmente es. Una muestra real de Stuxnet en nuestra base de datos la encontraron por primera vez el 16 de mayo de 2010. Se trata de un driver que no era detectado entonces por ningún motor. Sigue pasando relativamente desapercibido hasta el 7 de julio, cuando un antivirus lo bautiza como Stuxnet. A partir de ahí recibieron muchas muestras, pero no es hasta finales de julio que es detectado por la mayoría.

El primer ejecutable Stuxnet del que se tiene noticia, se remonta también al 16 de mayo de 2010 y sigue una trayectoria muy similar al driver en nivel de detección.

Durante los últimos 30 días Virustotal ha recibido más de 300 muestras calificadas como Stuxnet, y son detectadas por una media de 31 motores antivirus. Esto no quiere decir que se trate del propio Stuxnet que ataca a plantas nucleares. A partir del descubrimiento de la vulnerabilidad en archivos LNK en julio, muchos otros troyanos comenzaron a incorporar esta vulnerabilidad como método de difusión. Ante la confusión inicial, las casas antivirus comenzaron a llamar Stuxnet a cualquier malware que la explotara, por lo tanto podemos encontrar referencias a Stuxnet en archivos de apenas 100 bytes y en otros de hasta 5 megabytes.

Se cree que es probable que existan otros "Stuxnet" ahora mismo ocultos en sistemas críticos, que compartan las virtudes de este troyano y todavía no hayan salido a la luz.

Si quieren más información pueden visitar: http://www.hispasec.com/unaaldia/4384

Éxitos y fracasos de Stuxnet (II)

Seguimos repasando algunas de sus virtudes y errores y comentaremos la evolución de algunas muestras en VirusTotal.

Objetivos concretos 

Otra de sus virtudes es que dentro de su código contiene la contraseña por defecto "2WSXcder" para la base de datos central del producto SCADA WinCC de Siemens. El troyano consigue acceso de administración de la base de datos. Los sistemas "Supervisory Control and Data Acquisition (SCADA)" son programas críticos de producción industrial: toman datos muy sensibles de sensores de una fábrica, por ejemplo, y los envían a un sistema central para ser controlados. Se usan en grandes plantas de tratamiento de agua, control eléctrico, de tráfico, etc. Por lo tanto, se trata de un malware destinado a un perfil muy diferente del usuario "medio". En otras palabras, malware para al espionaje industrial. Se encontró sobre todo en Indonesia, India, Irán y China. Esto, unido a las cualidades anteriormente mencionadas, permitía llegar a su objetivo de forma silenciosa y eficaz.

Todas estas cualidades nos hacen pensar que el troyano ha sido concebido no solo por una mafia organizada como la que sostiene la industria antivirus actual, sino que va más allá: forma parte de un entramado que parece tocar altas esferas. Descubrir cuatro vulnerabilidades potentes y desconocidas en Windows y crear exploits eficaces para ellas requiere tiempo y mucho conocimiento, o en su defecto, del dinero para comprarlo. El supuesto robo físico de certificados, el objetivo Iraní, los involucrados han ido mucho más allá de la simple creación de laboratorio y buscan algo más que limpiar las cuentas de unos cuantos infectados.

El punto débil 

El punto débil ha sido solo uno: ¿por qué un gusano que se autorreplica indiscriminadamente? ¿Qué necesidad de infectar más allá de los sistemas objetivo? Esto ha facilitado su difusión pero también que escape del círculo cerrado que se supone eran sus objetivos primarios y por lo tanto que sea conocido, reconocido y detectado por las casas antivirus. No había ninguna necesidad de salir de los entornos SCADA, puesto que su "payload" solo era válido contra estas infraestructuras; en una máquina de usuario, resulta relativamente "inocuo".

La "fama" del troyano también permite que las vulnerabilidades hayan sido eliminadas rápidamente: todavía queda una de elevación de privilegios por corregir, pero Microsoft ha solucionado tres de ellas en los últimos tres meses. Además ha provocado que los certificados sean revocados; en resumen, que su salida a los medios eche a perder el trabajo y Stuxnet no siga siendo tan eficaz. El troyano debería, o bien no replicarse indiscriminadamente, o bien controlar sobre qué sistemas lo hace para evitar los que escapen a su objetivo. 

En otra entrega veremos algunos datos curiosos sobre este troyano que han recopilado en Virustotal. 

Si quieren más información pueden visitar: http://www.hispasec.com/unaaldia/4383

Éxitos y fracasos de Stuxnet (I)

Stuxnet ha marcado un antes y un después en la mitología del malware, acaparando titulares y una buena parte de las últimas noticias sobre malware. Hay quienes dicen que asistimos al nacimiento "de un nuevo mundo". No es para menos, sus virtudes no son pocas. Pero también ha cometido un error.

Eugene Kaspersky considera que Stuxnet es "el prototipo funcional de una ciber-arma, que dará el tiro de salida a una ciber-guerra en el mundo". Según Eugene, "este programa no ha sido diseñado para robar dinero, enviar spam o acceder a datos personales: ha sido diseñado para sabotear plantas y causar daños en entornos industriales. Me temo que es el principio de un nuevo mundo. Los 90 fueron la década de los ciber-vándalos, la década del 2000 fue la de los ciber-criminales, y me temo que ahora es la nueva era de las ciber-guerras y el ciber-terrorismo".

Al margen de los hitos establecidos, veamos algunos de los puntos fuertes de Stuxnet.

El uso de vulnerabilidades desconocidas hasta el momento para difundirse

Stuxnet utiliza hasta cuatro vulnerabilidades desconocidas hasta el momento para ejecutar código en las máquinas infectadas. Esto lo hace 100% eficaz contra cualquier Windows, desde 2000 hasta 7. Solo los administradores que tomen las máximas precauciones (evitar la ejecución de programas no conocidos, limitar al máximo los privilegios u otras medidas similares) se pueden librar de la amenaza.

El uso combinado e inteligente de estas vulnerabilidades

De las cuatro vulnerabilidades desconocidas, una permite la ejecución de código aunque el AutoPlay y AutoRun se encuentrasen desactivados. Esto implica que se descubrió una forma totalmente nueva de ejecutar código en Windows cuando se inserta un dispositivo extraíble, independientemente de que se hayan tomado todas las medidas oportunas conocidas hasta el momento para impedirlo.

La segunda permitía la ejecución de código a través del servicio de impresión de cualquier Windows. En impresoras compartidas por red, el troyano podía enviar una petición al servicio y colocar archivos en rutas de sistema. Esto permitía su máxima difusión dentro de una red interna, por ejemplo.

Las otras dos, permiten la elevación de privilegios. Esto cierra el círculo: si los administradores habían tomado la precaución de limitar los permisos de los usuarios, el troyano podía conseguir ser administrador a través de estas fallas. No había escapatoria, puesto que podía ejecutar código tanto en red como a través de dispositivos extraíbles, y una vez ahí, obtener todos los privilegios.

Uso de certificados válidos 

Los drivers de Stuxnet utilizados como rootkit estaban firmados digitalmente por la empresa china Realtek. Esto significa que solo Realtek puede ser responsable de ese código, excepto que su clave privada haya sido comprometida de alguna forma, cosa que no se ha confirmado todavía. En cualquier caso, Microsoft trabajó con Verisign para revocar en sus sistemas los certificados. Los atacantes reaccionaron firmando su troyano de nuevo con un certificado válido de otra empresa Taiwanesa dedicada también a crear controladores, llamada JMicron. El caso es que el uso de certificados válidos les permitía instalarse sin advertencias en los sistemas de 64 bits, por ejemplo, que requieren controladores firmados.

En una segunda entrega repasaremos otras cualidades.

Si quieren más información pueden visitar: http://www.hispasec.com/unaaldia/4382

lunes, 25 de octubre de 2010

Las nuevas Mac no vendrán con Flash Player preinstalado

Como pasó con Vista, la nueva MacBook Air de Apple no contará con Flash instalado de serie. La seguridad es la excusa pero en este caso, los motivos quizás vayan un poco más allá.

El nuevo sistema operativo de Apple soportará Flash, solo que no lo traerá de fabrica. No solo eso, sino que Apple no publicará actualizaciones por su cuenta. Hasta ahora, Mac OS X venía con una versión de Flash preinstalada; ahora si tomamos en cuenta el historial de graves fallas de seguridad de Adobe, en cuanto el sistema estaba en la calle ya estaba anticuado y requería una actualización. Apple, que acostumbra a emitir megaparches de seguridad cada cierto tiempo se encargaba entonces de incluir las nuevas versiones de Adobe en su propio actualizador en forma de paquetería propia.

Pero esto se ha acabado y Apple ha decidido que sea el usuario el que se encargue de instalar Flash y actualizarlo él mismo.

Por su lado XP venía con una versión de Flash por defecto. En ese entonces los tiempos eran otros Flash era de Macromedia. A partir de Vista, Microsoft dejó de incluir una versión de Flash en su sistema operativo. Pero en Windows Adobe ha trabajado duro para intentar proteger a sus usuarios. Su mayor logro es el actualizador automático, intentar organizar las actualizaciones, incorporar el ciclo de desarrollo seguro de software, colaborar estrechamente con Microsoft para mejorar la seguridad, etc.

Pero en Mac es diferente. La versión de Flash de este sistema todavía no cuenta con un sistema de actualización automático todavía, por lo tanto toda la responsabilidad recae en el usuario. En cualquier caso, Adobe ha contado otras ayudas como la Firefox y Chrome que desde hace algunas versiones, se encargan de comprobar el estado de actualización de sus plugins en cualquier plataforma.

En realidad, los motivos para esta decisión pueden encontrarse en la particular guerra entre Apple y Adobe que se ha agravado en los últimos tiempos. No es un secreto que Apple rechaza abiertamente Flash. Además de no incluirlo en sus dispositivos móviles (iPod Touch, iPad e iPhone), aboga por el inminente HTML5 que, en sus funciones multimedia, puede mellar en la hegemonía de Flash y de paso, no tener que pagar licencias.

Si quieren más información pueden visitar: http://www.hispasec.com/unaaldia/4381

Actualizaciones de seguridad de Java para Mac OS X

Apple ha sacado nuevas actualizaciones de seguridad de Java para Mac OS X versiones 10.5 y 10.6 que solventan diversas vulnerabilidades que podrían ser aprovechadas con diversos efectos.

Esta es la octava actualización de Java para Mac OS X 10.5 y la tercera para MAC OS X 10.6. En ella se corrigen diversos problemas en Java, que permiten a un atacante evitar restricciones de seguridad, provocar denegaciones de servicio o comprometer los sistemas afectados.

Las actualizaciones pueden ser instaladas a través de Software Update de Mac OS X o, según versión y plataforma, descargándolas directamente desde: http://support.apple.com/downloads/ 

Si quieren más información pueden visitar: http://www.hispasec.com/unaaldia/4380

jueves, 21 de octubre de 2010

Boletines de seguridad de la Fundación Mozilla

La Fundación Mozilla ha dado a conocer nueve boletines de seguridad, del MFSA2010-64 al MFSA2010-72, para corregir 12 vulnerabilidades en productos Mozilla (Firefox, Thunderbird y SeaMonkey). Según la propia clasificación de Mozilla cinco de los boletines presentan un nivel de gravedad "crítico", dos son de carácter "alto", otro es "moderado" y un último considerado como "bajo".

Se han publicado las versiones 3.6.11 y 3.5.14 de Firefox, las versiones 3.1.5 y 3.0.9 de Thunderbird y la 2.0.9 de SeaMonkey; que corrigen todas estas vulnerabilidades, disponibles desde: 
http://www.mozilla-europe.org/es/firefox/ 
http://www.mozillamessaging.com/es-ES/thunderbird/ 
http://www.seamonkey-project.org/ 

Si quieren más información pueden visitar: http://www.hispasec.com/unaaldia/4379