Denegación de servicio en Cisco IOS XR

Cisco ha confirmado una vulnerabilidad de denegación de servicio remota
que afecta a dispositivos con Cisco IOS XR para Cisco CRS-3 Carrier
Routing System.

El problema, con CVE-2015-0769, reside en el tratamiento inadecuado de
paquetes IPv6 que incluyan cabeceras de extensión. Un atacante podría
aprovechar esta vulnerabilidad mediante el envío de un paquete IPv6,
incluyendo cabeceras de extensión, a un dispositivo afectado configurado
para procesar tráfico IPv6.

Cisco ha publicado actualizaciones para evitar este problema
hfr-px-4.1.0.CSCtx03546.pie para versiones 4.1.0
hfr-px-4.1.1.CSCtx03546.pie para versiones 4.1.1
hfr-px-4.1.2.CSCtx03546.pie para versiones 4.1.2
hfr-px-4.2.0.CSCtx03546.pie para versiones 4.2.0

Cisco IOS XR Software Crafted IPv6 Packet Denial of Service Vulnerability
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cis...

Tags: 

Ataque a Kaspersky

Los Laboratorios Kaspersky han publicado un aviso en el que reconocen
haber sufrido un ataque dirigido, de igual forma confirman que ninguno
de sus productos, servicios o clientes se han visto afectados. Sin
embargo, los datos detrás del ataque resultan de lo más interesantes.

Las empresas de seguridad siempre están (estamos) en el punto de mira
de los atacantes. Bien por el prestigio que puede dar la publicidad del
ataque, la información obtenida, o conocer debilidades de otros posibles
objetivos; el ataque a una empresa de seguridad resulta ser un objetivo
muy suculento para un atacante.

Esto parece ser lo que le ha ocurrido a Kaspersky, han sufrido un ataque
avanzado sobre sus sistemas internos. Según la firma, el ataque es
sumamente avanzado y desarrollado, lo que junto con algunas similitudes
en el código ha hecho que este ataque, el malware y su plataforma
asociada, quede bautizado como Duqu 2.0.

Evidentemente, una de las cosas que Kaspersky quiere dejar, y deja, bien
claro, es que ninguno de sus productos se ha visto comprometido, y que
sus clientes no se enfrentan a ningún riesgo causado por este ataque.

"Ya hemos comprobado que el código fuente de nuestros productos está
intacto. Podemos confirmar que nuestras bases de datos de malware no
se han visto afectadas, y que los atacantes no han tenido acceso a
los datos de nuestros clientes."

Pero detrás de Duqu 2.0, se esconde "algo realmente grande", según
confirman este malware está una generación por delante de todo lo visto
hasta ahora, además de utilizar una serie de trucos que hacen que sea
muy difícil de detectar y neutralizar.

Las investigaciones de Kasperky han relacionado las nuevas infecciones
de este malware con eventos y lugares del P5+1, un grupo de seis
potencias mundiales con especial interés en el programa nuclear iraní y
las negociaciones sobre un acuerdo nuclear con este país. El P5+1 está
formado por los cinco miembros permanentes del Consejo de Seguridad de
la ONU, Estados Unidos, Rusia, China, Reino Unido y Francia, además de
Alemania. De igual forma, Duqu 2,0 también habría lanzado un ataque
similar en relación con el evento del 70 aniversario de la liberación
de Auschwitz-Birkenau. Kaspersky ha encontrado víctimas de Duqu 2.0 en
diferentes lugares, incluidos los países occidentales, Oriente Medio y
Asia.

Lo avanzado del ataque, la cantidad de recursos necesarios para su
desarrollo y puesta en marcha, así como los objetivos hacen pensar que
sin duda detrás de esto se encuentra un país, ¿Cuál? Eso está todavía
por descubrir. Y Kaspersky, que confirma que aun investiga más datos
sobre el ataque, no adelanta ninguna información al respecto.

Por otra parte hay que agradecer a Kasperky el reconocer el ataque, y
comunicarlo de forma adecuada, así como presentar un completo informe
sobre el malware y su plataforma digno de estudio.
https://securelist.com/files/2015/06/The_Mystery_of_Duqu_2_0_a_sophistic...

El vector inicial del ataque todavía se desconoce, aunque sospechan que
posiblemente haya sido a través de correos de spear-phishing (phishings
específicamente dirigidos y construidos para un objetivo concreto). Lo
que sí se ha confirmado es el uso de varios exploits 0day para su
introducción en los sistemas.

En 2011, el ataque original de Duqu empleaba una vulnerabilidad día cero
en Word (CVE-2011-3402), un exploit que permitía a los atacantes saltar
al modo kernel desde un documento Word. En 2014 se detectó una técnica
muy similar, también con exploit día cero (CVE-2014-4148), contra una
importante organización internacional. El servidor C&C (Comando y
Control) empleado en este ataque del 2014, así como otros factores,
tenían similitudes con Duqu, aunque la muestra de malware empleada era
diferente tanto a Duqu, como a Duqu 2.0. Según Kaspersky todo indica que
este 0day (CVE-2014-4148), parcheado por Microsoft en noviembre de 2014,
fuera el empleado para instalar Duqu 2.0.

Si bien, para el caso del ataque a Kaspersky Lab, el ataque se aprovechó
de otro día cero (CVE-2015-2360) sobre el kernel de Windows, parcheada
por Microsoft este pasado martes (en el boletín MS15-061) y posiblemente
hasta otras dos vulnerabilidades diferentes, actualmente corregidas,
pero que también fueron día cero en su momento.

Sin duda, los atacantes cometieron un error al atacar a una firma de
seguridad como Kaspersky, ¿qué otros objetivos similares habrán tenido?
Al atacar a Kaspersky los atacantes estaban interesados en aprender
sobre las tecnologías de seguridad, y los productos antivirus de la
firma. Buscaban información para conseguir permanecer más tiempo ocultos
sin que los objetivos atacados se percataran de ello. Ese fue su error.

Aparte del análisis técnico del malware, resulta también interesante y
digno de destacar el análisis que el propio Eugene kaspersky realiza
sobre los motivos sobre la revelación del ataque.
"En primer lugar, no revelarlo sería como no informar a la policía de un
accidente de tráfico con víctimas porque pueda afectar tu historial.
Además, conocemos la anatomía de los ataques dirigidos suficientemente
bien como para entender que no hay nada de qué avergonzarse en la
divulgación de este tipo de ataques, esto le puede pasar a cualquiera.
(Recuerda, sólo hay dos tipos de empresas: las que han sido atacadas y
los que no saben que han sido atacadas). Al revelar el ataque: (i)
enviamos una señal al público y cuestionamos la validez y la moralidad
de los ataques que creemos orquestados por un Estado contra el negocio
privado en general, y las empresas de seguridad, en particular; (ii)
compartimos nuestros conocimientos con otras empresas para ayudarles a
proteger sus activos. Si esto daña nuestra ‘reputación’, no nos importa.
Nuestra misión es salvar el mundo, y esto no admite concesiones."

P5+1 Negotiations with Iran
https://www.whitehouse.gov/issues/foreign-policy/iran-negotiations

Kaspersky Lab investiga un ataque hacker a su propio sistema
https://blog.kaspersky.es/kaspersky-statement-duqu-attack/6231/

The Mystery of Duqu 2.0: a sophisticated cyberespionage actor returns
https://securelist.com/blog/research/70504/the-mystery-of-duqu-2-0-a-sop...

The duqu 2.0
Technical Details
https://securelist.com/files/2015/06/The_Mystery_of_Duqu_2_0_a_sophistic...

Duqu, ¿el nuevo malware descendiente de Stuxnet?
http://unaaldia.hispasec.com/2011/10/duqu-el-nuevo-malware-descendiente-...

Tags: 

La suma de todo los miedos

Si existe un elemento malicioso con poder, temible y endiabladamente
silencioso todo el mundo tiende a pensar en un rootkit. Un rootkit se
instala en el mismo corazón del sistema, ahí construye su morada, habita
y sale de caza cuando las condiciones le son propicias. Es devastador,
el depredador perfecto, con capacidad para engañarte y los privilegios
del núcleo del sistema e incluso más. Lo más parecido a un rootkit en el
mundo real sería una cuenta en un paraíso fiscal. Oculta, poderosa,
resistente a la ingeniería inversa y pensada para aprovecharse de los
recursos del sistema mediante la perversión.

El dominio de un rootkit se mide por la capacidad de este para penetrar
en el sistema. Más profundo, más privilegios. Todo el mundo piensa en el
núcleo, pero imagina por un momento que antes de que el propio núcleo
tenga la oportunidad de pasar por la CPU, mucho antes, existe un proceso
de arranque que toma el control de todos los elementos para finalizar
entregando el mando al sistema. Si es posible llegar hasta ese lugar
donde comienza a despertar la máquina, el rootkit no solo será poderoso,
también será inmortal.

Todo esto es lo que podría haber pasado por la cabeza del investigador
portugués Pedro Vilanças (@osxreverser) cuando descubrió que todos los
MacBook de Apple, anteriores a mediados de 2014, podían ser envenenados
y al despertar de la hibernación notar la extraña presencia de un nuevo
inquilino en el lugar.

Vilanças se interesó por los ataques a la EFI (Extensible Firmware
Interface) a raíz de la recuperación de una contraseña de firmware que
olvidó. Hablar de firmware e ingeniería inversa es hablar de adentrarse
en una nueva dimensión donde parte del tiempo el investigador ha de
alejarse del teclado para llevar sus dedos sobre los propios chips donde
ya no se habla de simples variables, punteros o estructuras en memoria,
sino de pulsos, frecuencias y voltajes.

A raíz de los trabajos de los investigadores: Trammell,
(http://events.ccc.de/congress/2014/Fahrplan/speakers/4825.html)
y Rafal Wojtczuk junto con Corey Kallenberg
(http://events.ccc.de/congress/2014/Fahrplan/events/6129.html), se podía
llegar a la conclusión de que la modificación del firmware con acceso
físico era posible a través del ataque de Trammell, ayudado con un
dispositivo denominado OptionROM. Eso dejaba el vector de ataque
limitado por ese "acceso físico", lo cual no es práctico para un
atacante (ya sabéis lo engorroso que es eso de montar una operación de
campo: alquilar disfraces, distraer al objetivo y vigilarlo a través de
un periódico agujereado desde un banco del parque).

Escribir en la BIOS no es trivial. Existen varias capas de protección
para impedir una manipulación del código de la BIOS. Básicamente las
operaciones que intentan escribir en direcciones mapeadas a la BIOS
están protegidas por ciertas "banderas" que son comprobadas por
componentes encargados de verificar los privilegios de quienes inician
estas acciones. Por supuesto, los trabajos comentados publicaban
técnicas para evadir estas protecciones capa por capa.

Un ataque al que se le queda corto el adjetivo de sofisticado. Pero
estaba esa pega del acceso físico, la necesidad de enchufar un cacharro
que portaba un exploit en un puerto Thunderbolt, eso le quitaba
elegancia al ataque.

Si se tiene cierto dominio del portugués, es fácil imaginar la
exclamación de sorpresa que Pedro Vilança pudo haber soltado al
descubrir algo que iba a cambiar la aproximación al ataque. Es posible
manipular el firmware de un MacBook en remoto, sin necesidad de hardware
adicional o acceso físico.

Vilanças se dio cuenta de que las protecciones contra escritura de la
BIOS se encontraban desactivadas tras la vuelta del sistema desde el
modo Sleep. Curiosamente y en concreto el sistema ha de estar algo más
de 30 segundos para que tal evento ocurra.

Observemos un extracto del software empleado para leer la BIOS y su
estado 'flashrom', antes del modo Sleep:

SPIBAR = 0xfed1c000 + 0x3800
0x04: 0xe008 (HSFS)
HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1,
FLOCKDN=1
Warning: SPI Configuration Lockdown activated.
Reading OPCODES... done

Y esta otra cuando se toma tras volver del modo Sleep:

SPIBAR = 0xfed1c000 + 0x3800 0x04: 0x6008 (HSFS)
HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1,
FLOCKDN=0
Programming OPCODES... done

Asombrosamente las protecciones están desactivadas (observemos la
bandera FLOCKDN, flash lockdown) y esto no pasa desapercibido incluso
para el propio software, cuando avisa del bloqueo en el primer registro:

Warning: SPI Configuration Lockdown activated.

La especificación ACPI define varios niveles o estados de consumo. El
estado S3 hace referencia a la suspensión del sistema en RAM, es decir,
todos los componentes son "apagados" a excepción de la RAM en la que el
estado del sistema es mantenido hasta la transición hacia un estado
operacional. Esa transición es controlada por un proceso perteneciente
al EFI y según Vilanças es posible que contenga un bug que explicaría la
vulnerabilidad.

Explica el propio Vilanças en su blog que no ha encontrado el mismo
fallo en unidades posteriores a mediados o finales de 2014. Se pregunta
si esto ha sido parcheado por Apple. Queda la duda abierta, puesto que
aun no ha salido una corrección para los firmwares afectados.

Uniendo todas las piezas queda claro que, aunque es complejo, existe
ventana para manipular la BIOS de un Macbook mediante la visita de una
web, abriendo un archivo de video o un documento. Si los elementos se
alinean del modo adecuado la fatalidad puede llegar a morder la manzana
y envenenarla.

Cualquier servicio de inteligencia hubiera cubierto de oro a Vilanças
por tener exclusividad, sin embargo ahí tenemos la información y es de
agradecer que todos los usuarios de un Macbook sepan que cuando su
portátil se deshaga del abrazo del sueño y vuelva a mundo de los vivos
puede que no sea el mismo. Es más puede que ya no sea ni suyo.

Propuso Goya que el sueño de la razón produce monstruos. Ahora sabemos
que el despertar instala rootkits.

The Empire Strikes Back Apple – how your Mac firmware security is completely broken
https://reverse.put.as/2015/05/29/the-empire-strikes-back-apple-how-your...

Tags: 

Actualice su PHP

Recientemente el equipo de desarrollo de PHP ha publicado
actualizaciones para las ramas 5.6, 5.5 y 5.4 de PHP para solucionar
siete vulnerabilidades que pueden ser aprovechadas para provocar
denegaciones de servicio e incluso comprometer los sistemas afectados.

Dos de las vulnerabilidades residen en el nucleo de PHP, una de
denegación de servicio (con CVE-2015-4024), y una corrección de
regresiones en versiones superiores a la 5.4 (con CVE-2015-4025). Un
desbordamiento de entero en ftp_genlist() (CVE-2015-4022), pcntl_exec()
no debería permitir caracteres "null" (CVE-2015-4026), también se ha
actualizado pcrelib a la versión 8.37 (CVE-2015-2325, CVE-2015-2326) y
por último una corrupción de memoría en phar_parse_tarfile cuando el
nombre de archivo comienza con "null" (CVE-2015-4021)

Se recomienda actualizar a las nuevas versiones 5.6.9, 5.5.25 y 5.4.41
desde http://www.php.net/downloads.php

Tags: 

Crecimiento del mundo Movil



Tags: 

Páginas