VULNERABILIDAD EN IE7 POR ERROR DE DISEÑO

Internet Explorer 7 posee una vulnerabilidad del tipo Cross-Site-Scripting (XSS) en uno de sus recursos locales.

Debido a un error de diseño del navegador, dicha vulnerabilidad podría ser utilizada por un atacante para llevar a cabo un ataque de phishing (suplantación de un sitio web legítimo).

Una vulnerabilidad XSS permite eludir las restricciones para ejecutar scripts (archivos de comandos), en ventanas pertenecientes a diferentes dominios. Esto es válido para cualquier sitio web o para un archivo local.

NAVCANCL.HTM es un recurso local que IE utiliza cuando por alguna razón se cancela la navegación (Exploración cancelada). Cuando ello ocurre, la dirección (URL) de la página cancelada, es proporcionada a un script local después del símbolo numeral (#), de la siguiente manera:

res://ieframe.dll/navcancl.htm#[URL cancelada]

El script (httpErrorPagesScripts.js, que es parte del sistema), permite que el usuario pueda ir a la página cancelada, si hace clic en el enlace "Actualice la página." que se muestra (ver imagen más adelante).

Debido a la vulnerabilidad, es posible inyectar otro script en el enlace proporcionado, que también se ejecutaría cuando el usuario haga clic en el link "Actualice la página." Debido a que Internet Explorer 7 ejecuta sus propios recursos locales en la zona de seguridad "Internet" (más restrictiva que la "Zona local" o "Mi PC" de versiones anteriores), esta vulnerabilidad no puede ser utilizada para la ejecución remota de código.

Sin embargo, por un error de diseño, cuando NAVCANCL.HTM se ejecuta, la dirección del sitio que se incluye después del numeral, es mostrada en la barra de direcciones (seguida de otro código que no siempre es una señal clara de alerta para un usuario desprevenido).

Una prueba de concepto, muestra como un atacante podría crear un enlace malicioso, que al ser cancelado lanzaría un script que desplegaría en la barra de direcciones un contenido que no sería el verdadero, pero que podría parecerlo. Por ejemplo, podría mostrarse el enlace real a un banco, pero cuando el usuario haga clic en "Actualice la página", en realidad sería redirigido a un sitio falso.

En la prueba de concepto, se simula que el enlace apunta a CNN.COM, cuando ello no es así.

No se ha demostrado si el filtro anti-phishing del IE7, en caso de estar habilitado, podría ayudar a evitar el engaño, pero tampoco se ha comprobado lo contrario. Son afectadas las versiones de Internet Explorer 7.0 para Windows XP y Windows Vista.

Se aconseja a los usuarios, no hacer clic en el enlace "Actualice la página" que muestra el sistema, cuando la navegación es interrumpida por cualquier motivo.

Más información:
Phishing using IE7 local resource vulnerability http://aviv.raffon.net/2007/03/14/PhishingUsingIE7LocalResourceVulnerability.aspx

Fuente

Ver más

SUCESOS DE SEGURIDAD

A veces, las cosas más sencillas acaban pareciendo las más complicadas. Una de ellas suele ser lo relativo a la gestión de sucesos de seguridad. Incidentes, eventos, incidencias, fallos... Un montón de términos que a veces se confunden, se entremezclan, y que a los encargados de tratar con ellos dan más quebraderos de cabeza de los que debieran. Y sin embargo, las cosas suelen ser más sencillas de lo que parecen...

Por un lado, tenemos las incidencias de seguridad. Entendidas, sencillamente, como que "ha pasado algo relacionado con la seguridad". Qué ha pasado? Tenemos tres opciones. La primera es que haya pasado "algo malo". Hemos tenido un problema, algo ha fallado. Técnicamente, una amenaza ha conseguido explotar una vulnerabilidad sobre un activo. Y qué hay que hacer? Simplemente, arreglarlo. A eso se le llama corrección.

Otra opción es que la incidencia haya quedado "en nada". Ha sucedido un evento, pero no ha llegado a ser incidente. Una amenaza que nos ha atacado pero finalmente no se ha materializado, una vulnerabilidad nueva que ha aparecido, pero que aún no ha sido explotada...

Lo que haya sucedido todavía no nos ha hecho ningún daño. Aunque si no hacemos nada, podría llegar a causarlo. Qué hay que hacer? Evitarlo antes de que suceda: corregir aquello que acabamos de descubrir que está mal, antes de que pase nada (acciones correctivas) o reforzar nuestras medidas de protección, por si acaso (acciones preventivas).

Todavía tenemos una tercera opción. Lo que ha pasado es que hemos descubierto que nuestros controles no funcionan bien. No es que haya pasado algo malo, sino que hemos encontrado un fallo en nuestro sistema de gestión. La incidencia, en este caso, se cataloga como no conformidad, y lo que tendremos que arreglar en este caso es el control en sí, mediante las acciones correctivas correspondientes.

Por último, existe otro tipo de entrada que puede dar lugar a este tipo de acciones. En este caso yo no lo catalogaría como incidencia, ya que no es que "haya pasado algo", sino que alguien realiza una aportación (sugerencia, comentario).

En este caso, la aportación (realizada por cualquier persona de la organización) puede ser una propuesta de mejora (lo que desencadenaría la correspondiente acción preventiva si así se considera) o puede "levantar alguna liebre", descubrir algún fallo que deba ser resuelto, mediante las correspondientes acciones correctivas.

Y no olvidemos que una corrección puede conllevar, en su tratamiento a posteriori, una acción correctiva para resolver la causa que ha provocado el incidente. Y que a su vez las acciones correctivas también pueden desencadenar acciones preventivas que ayuden a optimizar las protecciones existentes en relación al origen de los hipotéticos incidentes. En el fondo, todo está relacionado, no?

Fuente

Ver más

EL ENEMIGO INTERIOR
Tanto tiempo echando la culpa a malvados "hackers" de la revelación de datos confidenciales y ahora un estudio de la Universidad de Washington en Seattle revela que los intrusos sólo son responsables de menos de un tercio de esos episodios, mientras casi dos tercios son responsabilidad de las propias empresas.

Pérdidas de equipos, puesta on-line inadvertida de información confidencial, pérdidas de backups y otros errores de administración conforman el grueso de la responsabilidad empresarial en este campo...

Para Philip Howard, coautor del trabajo, cuando la empresa pierde un montón de datos de sus clientes, lo más fácil es echarle la culpa a un supuesto "hacker".

Otro estudio similar publicado la semana pasada por IT Policy Compliance Group proporcionaba resultados similares: 75% de responsabilidad atribuible a la empresa, 25% a intrusos externos.

Fuente
Mas información

Ver más

FORMAS DE ANALISAR UN VIRUS. UN PASEO POR RAPIDSHARE.

Dando vueltas por el diario de juanito, me tope con este ineresante post. Para los que estan acostumbrados a bajar de Internet todo lo que pueden, les recomiendo la lectura en cuestión.

"De vez en cuando me doy un paseillo por webs de descarga directa a ver si encuentro algún amiguete escondido entre tanto link. Esta vez me dí un paseo por rapidshare. Este tipo de Webs, como sabéis, ofrecen un servicio gratuito de alojamiento de archivos por un tiempo limitado. Chulo no? Lo malo es que se pueden alojar tanto archivos buenos, como archivos maliciosos.

Empecé buscando lo que busca todo el mundo. Un keygen para el Windows Vista. jaja. Tanto critiqueo pero estas Webs están llenas de cracks para el Vista. De los 5 archivos que me descargué 3 tenían un alien dentro. Llamádme loco, pero cada vez que descargo un archivo, tengo la paranoia de subirlo a virustotal. Los 3 amigos son los siguientes:

Troyano Zlob (2 archivos)
Un keylogger
Un posible virus sin identificar (Mirad la foto)

Tanto el troyano como el keylogger, lo detectaban perfectamente casi todos los antivirus de virustotal, pero con el tercero, la cosa cambia. El posible virus está empacado con Themida, un software comercial para empacado de archivos. Permite encriptación, técnicas anti-debbuger, etc.. Una aplicación que haya sido empacada con este software puede dar más de un falso positivo, y sólo algunos antivirus, con heurística paranoica, detectan algo, que en algunos casos, puede o no ser un virus.

En el blog de Hispasec pusieron una entrada hace no mucho tiempo que debatían sobre el tema de si los antivirus debían detectar estos packers.

En aquí.

Ni Mcafee, ni Norton, ni Panda, ni Kaspersky, ni Nod32 lo detectan. Se lo tragan completito. Y el nombre no puede ser más sugerente. Microsoft_Windows_Vista_Keygen. Si los antivirus no lo detectan, qué haría una persona medianamente normal? Doble click…. Y a jugar! Veamos un poco lo que hacen nuestros amigos.

Aquí empezamos a jugar con la máquina virtual. En post anteriores os he dado algunos enlaces directos a máquinas virtuales, así que podéis descargaros las de los links, o montaros alguna para pruebas. Ejecutamos nuestra máquina virtual y ejecutamos el posible virus. Doble click y el archivo desaparece… Y mi serial??
Acto seguido abro una shell de Windows y ejecuto el comando netstat, para ver las conexiones activas de mi equipo virtual. La ejecuto con los parámetros siguientes:

-n.- Muestra direcciones y puertos asociados
-a.- Muestra todas las conexiones
-b.- Muestra el ejecutable que crea la conexión
-o.- Muestra el PID asociado al ejecutable

netstat -nabo Jaja. Qué palabra más bonita! Los datos son reveladores

Como quiero saber más de nuestro sospechoso amigo, me descargo de Microsoft la herramienta ProcessExplorer, aplicación que me va a ayudar a conocer de una manera más íntima a nuestro amigo. Lo que voy a mirar será los strings que contiene, lo que carga en memoria, y las propiedades TCP/IP del amigo.

El comando Strings, me va a buscar cadenas de texto ASCII o Unicode en el ejecutable. De ahí podremos deducir algo si vemos cadenas legíbles.
Para ver los strings del fichero, hacemos doble click en el archivo (desde Process Explorer) y nos vamos a la pestaña Strings. El resultado no nos muestra mucho. Efectivamente está empacado con Themida y al final leemos que está intentando escribir o tomar un archivo, posiblemente de configuración. Lo podéis ver en la imagen adjunta.

Justo en esta misma pestaña, Process Explorer nos da la oportunidad de mirar también el contenido de la memoria. El contenido es más que revelador. Tenemos ante nosotros a un auténtico depredador. Virus con capacidad de troyano, downloader, gusano, Bot, etc…
Guarda en memoria todo tipo de datos. Posibles usuarios y contraseñas, diversas formas de explotar una serie de vulnerabilidades antiguas (DCOM, LSASS, RPC, etc.).

Si queremos ver el tipo de conexión que intenta realizar el virus, pulsamos la pestaña TCP/IP y nos muestra lo siguiente:

El virus está intentando crear una conexión a través de IRC y por el puerto 6667, un puerto típico de conexión para estos menesteres. También vemos que el estado de la conexión es SYN_SENT, es decir, el socket está esperando la conexión. El virus en cuestión crea una entrada en el registro de Windows, y se aloja en System32. Cabe decir que si ejecutásemos este virus bajo una cuenta NO Administrativa, este virus tendría un impacto NULO en un sistema Windows.

Espero que os quede un poco más claro que por muchas protecciones de seguridad que tengamos en un equipo, ninguna de ellas será efectiva ante un doble-clic de un usuario. Cuidadito por la Red y vigilad lo que os descargáis".

Ver más

PERTENECER A UN CLUB ZOMBIE SIN SABERLO

Desgraciadamente muchos host pueden estar trabajando codo a codo dentro de una red de máquinas zombies sin ser conscientes de ello, convirtiéndose en auténticos servidores de spam. Vamos a poner a un ejemplo.

Existe una web, SenderBase, perteneciente a la conocida empresa de seguridad en Internet IronPort, que se dedica a monitorizar el 25% mundial de todos los envios de correo electrónico que se producen.

Esta monitorización se logra gracias a la participación de más de 75.000 empresas de todo el mundo donde destacan algunos operadores de telefonía. En la página principal, podemos ver las redes que más emails envían, curiosamente (o no) en el momento de escribir este post nos encontramos con la red rima-tde.net de Telefónica en el primer puesto (ver foto).

“Hay que tener en cuenta que actualmente un 90% de los emails enviados son spam”. En el bloque inferior vemos otra lista ordenada por los host que más emails envían. He buscado el primer host dentro de la redes de telefónica (ver foto) y resulta ser muelle.portel.es con un volumen escalofriante de envíos diarios.

Posteriormente fue fácil descubrir que se envía spam desde ese host (las estadísticas no engañan) El host aparece en algunas blacklist como por ejemplo esta de Vortex Technology.

Probablemente la empresa que gestiona portel.es no es consciente de que su dominio es usado para propagar tanto spam, aunque nunca se sabe!

Fuente

Ver más