A las 8:54am del septiembre 16, 2009, Carles Pérez dijo...
***** TRUCOS DE WINDOWS VISTA *********
Acelerar los discos duros:
En este tip vamos a ver como aumentar la velocidad de los discos duros en Windows Vista, en primer lugar para discos duros SATA, y luego para discos USB. Estas opciones se pueden configurar de manera muy fácil desde el Administrador de Dispositivos.
Para ello tendremos que activar una opción llamada Cache de escritura, que por defecto no viene activa en Windows Vista. No se porqué no está activa por defecto, pero sí que si la activámos aumenta el rendimiento del sistema, aunque como refleja su activación si no disponemos de una SAI y tenemos cortes de corriente, es posible la perdida de datos.
Abrimos el Administrador de dispositivos, para ello escribe devmgmt.msc en el cuadro de Ejecutar. Ve al desplegable de Unidades de Disco, y haz clic derecho sobre el disco duro que quieras. Escoge la opción Propiedades. Ahora ve a la pestaña de Directivas, y activa la opción Habilitar Rendimiento Avanzado.
Nota: Tienes que repetir el proceso por cada disco duro que tengas instalado en tu sistema.
Puedes seguir este procedimiento también para tus discos duros externos conectados por USB. Abre de nuevo la pestaña de Directivas en el disco duro USB, y selecciona Optimizado para Rendimiento en las opciones. Este método tiene un punto muy a tener en cuenta, que es que necesitarás retirar siempre el Hardware de forma segura siempre que vayas a desenchufar el disco del ordenador. Aceptar conexiones de equipos con una version anterior de escritorio remoto
1. Abre Inicio y haz clic con el botón derecho del ratón sobre Equipo.
2. Pulsa sobre Propiedades.
3. Haz clic sobre el enlace Configuración avanzada del sistema (en el panel de la izquierda).
4. Cuando aparezca la ventana de confirmación, haz clic sobre Continuar.
5. Selecciona la pestaña Acceso remoto.
6. Selecciona la opción Permitir las conexiones desde equipos que ejecuten cualquier versión de Escritorio remoto (menos seguro).
A las 8:53am del septiembre 16, 2009, Carles Pérez dijo...
Atacan los servidores de la fundación Apache
Este viernes los servidores de la fundación Apache presentaron durante
unas cuantas horas una escueta página informando que se encontraban
investigando un incidente en sus servidores.
Aclaraban que no se trataba de un exploit que afectase al popular
servidor web, producto de la propia fundación, sino de una llave SSH
comprometida.
La llave en cuestión permitía el acceso a una cuenta para efectuar
copias de respaldo automáticas del sitio web "ApacheCon", en una máquina
situada en un alojamiento externo a la fundación. Dicha máquina fue
usada para subir archivos a un servidor de su infraestructura,
denominado minotaur.apache.org, con funciones notables, como proveer de
cuentas para los "comitters" -cuentas con acceso de escritura a los
repositorios de código- y de entrada a los distintos sitios web de la
fundación Apache.
Según las primeras investigaciones, fueron creados varios archivos
dentro del dominio "www.apache.org", incluyendo varios scripts CGI, que
fueron usados para sincronizar dichos archivos con varios servidores en
producción e inyectar procesos en los servicios web funcionales.
Tras detectar los procesos que inyectaron los atacantes procedieron a
detener los sistemas afectados, de esta manera, por algunos instantes,
no se podía acceder a ninguno de los sitios web de Apache, hasta que se
procedió a cambiar los DNS hacia una máquina no afectada para mostrar un
mensaje informativo indicando la situación en la que se encontraban.
Después de asegurarse de que la infraestructura que la fundación posee
en Europa no estaba afectada -los atacantes llegaron a subir los
archivos pero no fueron ejecutados-, usaron las copias de respaldo no
comprometidas para restaurar los servicios en lo posible, permaneciendo
gran parte de su infraestructura detenida para evaluar los daños
causados por los atacantes.
Aunque, según Apache, no tienen conocimiento de usuarios finales
afectados, ni de que las descargas fueran afectadas, enfatizan efectuar
la verificación de la firma digital de los archivos.
A las 8:52am del septiembre 16, 2009, Carles Pérez dijo...
Pantallazo azul (BSOD) en Windows Vista y 7 a través de unidades compartidas
-----------------------------------------------------------------------------------------------
Laurent Gaffié ha detectado un fallo de seguridad en Windows Vista que
podría permitir a un atacante provocar un BSOD (pantallazo azul, una
denegación de servicio) con solo enviar algunos paquetes de red
manipulados a una máquina que tenga activos los servicios de
compartición de archivos (protocolo SMB).
El fallo (incomprensiblemente simple) está en el intérprete de las
cabeceras SMB, concretamente en el driver srv2.sys. Como los
controladores operan en el "ring0", la capa de abstracción del sistema
operativo más cercana al hardware (en contraste con el "ring3", la capa
de usuario que no interactúa directamente con él) un fallo en cualquier
driver provoca que el sistema se bloquee por completo, al no poder
manejar la excepción correctamente. Se trata del temido pantallazo azul,
o BSOD. Los Windows anteriores a Windows 2000 no realizaban esta
separación de seguridad entre capas, por lo que todo operaba en el mismo
espacio de memoria y los fallos en el espacio de usuario podían causar
un bloqueo total del sistema. De ahí que los pantallazos azules fuesen
mucho más comunes en Windows 9x y Me.
El ataque es tan sencillo que recuerda a los "pings de la muerte" que
hicieron estragos a finales de los 90 en los sistemas Windows. Contenían
un fallo en la pila TCP que hacía que, si se enviaba un ping al sistema
especialmente manipulado (simplemente especificando con un parámetro,
por ejemplo, un tamaño mayor del paquete) se podía hacer que el sistema
dejara de responder. Esto, unido a la carencia de cortafuegos del
sistema, a que en aquellos momentos las conexiones se realizaban a
través de módem (que carecía de protección por cortafuegos o NAT) y el
hecho de no existir servicio de actualización automático del sistema,
hicieron muy popular el ataque.
Este fallo en el protocolo SMBv2 de compartición de archivos requiere
igualmente del envío de una sencilla secuencia de paquetes SMB (al
puerto 445) al sistema víctima con las cabeceras manipuladas. El truco
está en enviar un carácter "&" en el campo "Process Id High" de las
cabeceras SMBv2. Esto provoca una excepción en srv2.sys que provoca el
pantallazo azul. El exploit es público y realmente sencillo.
Vista mantiene el cortafuegos activo por defecto para su perfil
"público", y esto mitiga el problema. Pero todo depende del perfil. Si
el usuario usa un perfil de cortafuegos (ya sea de dominio, o el perfil
privado) en el que permite las conexiones a sus unidades compartidas
(puerto 445, normalmente abierto en las redes locales) será vulnerable.
No es necesario que comparta realmente una unidad, solo que el protocolo
SMB esté activo y preparado para compartir en su sistema. Esto puede
resultar especialmente grave en redes internas.
No existe parche oficial disponible. Se recomienda filtrar el puerto 445
(y los implicados también en la compartición de ficheros 137-139) a
través de cortafuegos. También es posible detener el servicio "Servidor"
del sistema (aunque se puede llegar a perder funcionalidad). Otra
contramedida posible es desactivar la casilla "compartir archivos e
impresoras" que aparece en las propiedades de las interfaces de red.
Aunque el ataque no permite ejecución de código y es poco viable que
pueda propagarse por la red pública, sí que puede resultar más que
molesto en redes internas donde los usuarios normalmente mantienen
reglas de cortafuegos mucho más relajadas. ¿Vuelven los tiempos del
"ping de la muerte"?.
A las 7:37pm del mayo 25, 2009, Carles Pérez dijo...
Relación de Confianza entre un dominio y windows Vista
Estos últimos meses ya he tenido la experiencia de Ver como mi Windows Vista Business de 64bits , ha perdido la relación de confianza con el servidor, en tres ocasiones.
Es Genial, cojonudo los fallitos de Vista, por qué con solo bloquear la sesión y al cabo de unos minutos volver e intentar desbloquear la sesión aparece el mensage de "Ha perdido la reclación de confianza entre ala estación de trabajo y el dominio principal". Brutal!!!!!, buscando en Microsoft para no tener que hacer lo que ya he hecho en estas ocasiones, quitarlo y volverlo a poner en el dominio, Microsoft dice que hay que hacer eso exáctamente eso, quitarlo y volverlo a añadir.
Cosa que con estos siete años con Windows XP, y en la misma red nunca me sucedio esto, en Windows vista con un año y medio ya son tres veces, menos mal que solo lo tengo yo, que si esto lo tuvieran más personas en mi empresa, ya podriamos ir apañados.
Supongo que no hay otra opción, por lo menos yo no la he visto, ni em Microsoft ni por San Google. Así que si alguien le pasa y no sabe una opción más rápida, por lo que yo sé la más rápida es esta
"Quitar cera, Poner cera Windows SAN"
Tiempo estimado en tener otra vez la máquina lista 20 minutos.
A las 1:53pm del enero 11, 2009, Carles Pérez dijo...
Acceso a la raíz del sistema de archivos en Samba
Se ha anunciado una vulnerabilidad en Samba por la que un usuario remoto
autenticado podría llegar a acceder a determinados archivos del sistema.
Samba es una implementación Unix "Open Source" del protocolo
SMB/NetBIOS, utilizada para la compartición de archivos e impresora en
entornos Windows. Gracias a este programa, se puede lograr que máquinas
Unix y Windows convivan amigablemente en una red local, compartiendo
recursos comunes.
El problema reside cuando un usuario remoto autenticado se conecta a un
compartido con un nombre vacío ("") mediante una versión antigua de
smbclient (anterior a 3.0.28), el usuario podrá acceder a la raíz del
sistema de archivos ("/"). Por ejemplo con: smbclient //server/ -U
user%pass
Se ven afectados los sistemas configurados como: "registry shares = yes"
y con "include = registry" y "config backend = registry" (no se trata de
la configuración por defecto).
Se ha publicado la versión 3.2.7 que corrige este problema.
A las 1:51pm del enero 11, 2009, Carles Pérez dijo...
La familia de malware DNSChanger instala "simuladores de DHCP" en la víctima
Hace unos días, tanto el SANS como distintas casas antivirus advertían
de un comportamiento más que curioso en la vieja conocida familia de malware DNSChanger. Esta ha evolucionado sustancialmente: Comenzó con el
cambio local de la configuración de servidores DNS en el sistema (para
conducir a la víctima a los servidores que el atacante quiera). Ha
llegado hasta el punto de instalar una especie de servidor DHCP e
infectar así a toda una red interna. Los servidores DNS que instala
el malware suelen estar en la red conocida como UkrTeleGroup.
La familia DNSChanger
Una característica interesante de DNSChanger es que es una de las
familias que más han atacado a sistemas Mac, además de a Windows. Entre
otras muchas formas de toparse con ellos, se suelen encontrar en
servidores eMule, camuflados bajo la apariencia de otros programas.
Es una familia conocida desde hace unos tres años. Se caracterizan por
modificar los servidores DNS de la víctima a la que infectan. De esta
forma, la asociación IP-Dominio queda bajo el control del atacante, de
manera que la víctima irá a la IP que el atacante haya configurado en su
servidor DNS particular. Normalmente, se confía en los DNS de los ISP,
pero si se configura cualquier otro, realmente la resolución queda a
merced de su administrador, cualesquiera que sean sus intenciones.
DNSChanger comenzó modificando la configuración del sistema en local, de
forma que cambiaba los servidores DNS del ISP de la víctima por otros
controlados por el atacante. Después, el malware evolucionó hacia la
modificación del router ADSL de la víctima. Buscaba la "puerta de
enlace" del sistema, que suele corresponderse con el router, y realizaba
peticiones o aprovechaba vulnerabilidades de routers conocidos para
modificar estos valores. Así el usuario se veía afectado por el cambio
pero de una forma mucho más compleja de detectar. Además, también se
verían afectadas el resto de las máquinas que tomaran estos valores del
propio router.
Dando un paso más allá
La última evolución observada implica la instalación en la víctima de un
pequeño servidor DHCP. Este es el protocolo usado en las redes locales
para que cuando un sistema se conecta a la red, el servidor lo reconozca
y le proporcione de forma automática los valores necesarios para poder
comunicarse (dirección, ip, puerta de enlace...). Habitualmente también
proporciona los valores de los servidores DNS que haya establecido el
administrador o el router.
El malware instala un driver que le permite manipular tráfico Ethernet a
bajo nivel, o sea, fabricar paquetes de cualquier tipo. Con esta técnica
simula ser un servidor DHCP. Cuando detecta preguntas de protocolo DHCP
legítimas de algún sistema en la red, el malware responde con su propia
configuración de DNS, de forma que el ordenador que acaba de enchufarse
a la red local, quedaría configurado como el atacante quiere, y no como
el administrador ha programado. El atacante confía en la suerte, pues el
servidor DHCP legítimo de la red, si lo hubiese, también respondería.
Quien llegue antes "gana". Consiguen así infecciones "limpias", pues es
complicado saber quién originó el tráfico si éste no es almacenado y
analizado. Además, con este método se pueden permitir realizar muchos
otros ataques en red local con diferentes impactos.
¿Qué valores DNS introduce el malware?
DNSChanger es una familia que necesita de una importante infraestructura
para que sea útil. Los servidores DNS (bajo el control de los atacantes)
de los que se vale, los que modifica en el usuario, suelen estar
alojados en la compañía ucraniana UkrTeleGroup, bajo el rango de
red 85.255.x.y. Casi un 10% de todas las máquinas en ese rango de
direcciones se corresponden con servidores DNS públicos que no contienen
las asociaciones legítimas de domino y dirección IP. En ocasiones
utilizan el servidor DNS para asociar dominios a la IP reservada
127.0.0.1, como es el caso del servidor de descargas de Microsoft download.microsoft.com. Con esto se consigue que la víctima no pueda
actualizar el sistema operativo con parches de seguridad. Curiosamente,
al parecer, las direcciones de actualización de Apple no están
bloqueadas (a pesar de que suele afectar a este sistema operativo).
También se bloquean un buen número de páginas de actualizaciones de
casas antivirus.
Algunos de estos servidores DNS (ATENCIÓN: no configurarlos en el
sistema bajo ningún concepto) son:
Sólo son necesarias algunas consultas "dig" (comando para averiguar qué
direcciones están relacionadas con qué dominios en un servidor DNS) para
comprobar qué dominios "interesan" o no a los atacantes.
A las 1:47pm del enero 11, 2009, Carles Pérez dijo...
La vulnerabilidad de Windows Media Player degradada a simple error
El día 24 de diciembre un mensaje en la lista de correo Bugtraq hacía
pública una supuesta vulnerabilidad en Windows Media Player que afectaba
a todas las versiones en todos los sistemas. El fallo en sí es un
desbordamiento de entero producido al procesar un archivo especialmente
manipulado en los formatos WAV, SND, o MID. La antesala a una ejecución
de código arbitrario.
El mensaje iba acompañado de una prueba de concepto, un script en Perl
que al ejecutarlo nos deja un archivo en formato MIDI que al ser abierto
por Windows Media Player provoca el cierre de la aplicación. Hasta ahí
todo correcto, era cuestión de tiempo para comenzar a ver exploits que
fuesen capaces de aprovechar el fallo para alcanzar el cáliz de las
vulnerabilidades: ejecutar código arbitrario. Pero días después no se
escuchaba nada, no había ruido de sables, no había exploit.
Según Christopher Budd del MSRC (Microsoft Security Response Center),
quien se queja de que el investigador no haya contactado con ellos antes
de su publicación, no hay vulnerabilidad. No hay posibilidad alguna de
ejecutar código. De hecho, según Jonathan Ness del SWI (Microsoft
Security Windows Initiative) incluso fue descubierto por ellos en sus
auditorías internas y ya está solucionado en el Service Pack 2 de
Windows Server 2003.
Sin entrar en detalles técnicos, la prueba de concepto proporcionada es
procesada por "quartz.dll" un componente de DirectShow encargado de los
archivos con extensión WAV, SND, y MID. El desbordamiento de entero
ocurre en una instrucción DIV -concretamente cuando se ejecuta EAX =
(EDX:EAX)/reg y el resultado no entra en el registro de 32 bits- , pero
la excepción levantada no es capturada por 'quartz.dll', ni se produce
corrupción de memoria.
Así que el susto se queda relegado a la categoría de bug y se programa
su eliminación para la próxima actualización de mantenimiento.
A las 1:43pm del enero 11, 2009, Carles Pérez dijo...
Ejecución de código a través del plugin gen_msn de Winamp
Se ha informado que existe una vulnerabilidad crítica en el plugin "Now
playing" gen_msn para el reproductor Winamp, que podría permitir la
ejecución remota de código.
Este popular complemento de Winamp (con más de 750.000 descargas) es el
que permite activar la funcionalidad "Lo que estoy escuchando" del
sistema de mensajería instantánea de Microsoft Live Messenger. Dicha
funcionalidad muestra como parte de nuestro apodo, el nombre del artista
y la canción que se está reproduciendo en ese momento en Winamp.
El fallo está causado por un desbordamiento de búfer basado en heap en
gen_msn.dll, al intentar procesar una lista de reproducción (archivo
.pls) especialmente manipulada que contenga entradas demasiado largas.
Todavía no existe parche disponible y la vulnerabilidad ha sido
confirmada con la aparición de un exploit público que afectaría a las versiones más recientes del plugin (gen_msn v.0.31) y del reproductor
(Winamp 5.541).
Se recomienda no abrir archivos pls no confiables y, a ser posible,
deshabilitar el plugin hasta que esté disponible una nueva versión no
vulnerable.
A las 1:37pm del noviembre 14, 2008, Carles Pérez dijo...
Ahora sí, TKIP usado en WPA parece estar herido de muerte
Los investigadores alemanes Erik Tews y Martin Beck dicen haber
conseguido saltarse parcialmente la seguridad que proporciona WPA (Wi-Fi
Protected Access) en las redes inalámbricas. WPA vino a salvarnos del
inseguro WEP (Wired Equivalent Privacy), que fue vencido pocos años
después de su estandarización y que hoy en día es un cifrado obsoleto.
Este descubrimiento hace pensar que WPA parece ir por el mismo camino.
Segundo ataque al algoritmo de cifrado y autenticación WPA para redes
inalámbricas, y esta vez va en serio. A principios de octubre se publicó
la noticia de que la compañía rusa ElcomSoft había conseguido reducir
sustancialmente el tiempo necesario para recuperar una clave de WPA,
ayudándose de tarjetas gráficas NVIDIA. Al parecer el método conseguía,
a través de fuerza bruta, deducir claves extraordinariamente rápido. La
fuerza bruta no supone un ataque o una debilidad del WPA en sí, por
tanto el cifrado se mantenía relativamente a salvo siempre que se usase
una contraseña suficientemente larga y entrópica. El descubrimiento de
ElcomSoft no era tan relevante en este sentido. Todo es susceptible de
ser atacado por fuerza bruta. Sin embargo lo que Tews y Beck han
encontrado sí es un problema inherente a una parte de WPA, un fallo en
la criptografía usada en muchas configuraciones.
Es importante recalcar que el método descubierto no permite recuperar
la contraseña. Y que tampoco influye el método de autenticación. El
problema está en el cifrado. Está limitado a descifrar paquetes
concretos o inyectar nuevos (y sólo una pequeña cantidad). También es
necesario destacar que el ataque sólo funciona si se utiliza el cifrado
TKIP, no el AES. El ataque inminente y posible es provocar una
denegación de servicio o inyectar paquetes ARP, lo que puede hacer que
se redirija el tráfico. Insistimos en que no es posible por ahora
recuperar la clave o descifrar todo el tráfico.
WPA puede usar diferentes algoritmos de cifrado: AES (estándar y seguro
por ahora) y el Temporal Key Integrity Protocol (TKIP). Aquí es donde se
ha encontrado la vulnerabilidad. Un ataque basado en la misma técnica
que volvió obsoleto al WEP (ataque conocido como chopchop) ha permitido
que se pueda descifrar un paquete de tipo ARP en menos de 15 minutos,
independientemente de la contraseña usada para proteger el WPA. TKIP
se creó precisamente para solucionar los problemas de WEP. Por ejemplo
añade entre otras, comprobación de integridad del mensaje (MIC) en vez
del débil CRC32 que usaba WEP. El problema es que TKIP también conserva
varios peligros heredados de WEP. TKIP se creó para que fuese compatible
con los dispositivos que ofrecían WEP sólo con actualizaciones del
firmware, sin necesidad de cambiar el hardware: un parche.
Los analistas han observado que aprovechándose de estas similitudes, y
eludiendo las mejoras introducidas con TKIP, se puede realizar un ataque
muy al estilo del que se creó contra WEP y con resultados limitados.
Para ello atacan a paquetes ARP (se usan estos paquetes porque son
pequeños y sólo quedan por conocer 14 bytes, una vez que se sabe en qué
subred nos movemos) y el resultado es que se puede descifrar en menos de
15 minutos. Para otros paquetes se debería emplear más tiempo. El truco
es usar un canal o cola QoS diferente de donde fue recibido el paquete.
El ataque funciona incluso si la red no tiene funcionalidad QoS.
En una versión en desarrollo de aircrack-ng, se puede encontrar la
implementación del ataque. Es bastante probable que, en cuestión de
tiempo, se mejore el ataque y se rompan las limitaciones que por ahora
sufre.
Los usuarios y administradores que usen WPA deben cambiar en la medida
de lo posible al cifrado AES, o mejor aún pasar a WPA2 que soluciona de
raíz el problema. Si no es posible, también cabe la posibilidad de
configurar WPA para que el recálculo de claves sea cada, por ejemplo,
120 segundos o menos. Aunque esto puede tener cierto impacto sobre el
rendimiento.
Si bien el algoritmo de cifrado no está completamente comprometido,
sí que puede servir de trampolín para que se estudien nuevas técnicas
y pueda ser finalmente roto. Lo mejor es que supone una llamada de
atención para actualizar a un protocolo más seguro como es WPA2, pero
sin que se corra un riesgo inminente y catastrófico al mantener el WPA
por ahora.
A las 10:58am del octubre 27, 2008, Carles Pérez dijo...
Problemas de seguridad en el navegador Opera
La versión 9.61 del navegador Opera corrige tres vulnerabilidades que
podrían ser aprovechadas por un atacante remoto para perpetrar ataques
de cross-site scripting, saltarse restricciones de seguridad o revelar
información sensible en un sistema vulnerable.
Opera, además de ser un navegador web, contiene cliente de correo
electrónico con gestor de contactos, cliente de IRC, lector de noticias
RSS y gestor para la descarga de archivos torrent, y un buen gestor de contraseñas.
La nueva versión 9.6, con aspecto y características mejoradas, fue lanzada a
principios de este mes, y ahora se publica la primera revisión de
seguridad sobre la misma.
De las tres vulnerabilidades corregidas recientemente, la primera está
catalogada como extremadamente severa por el equipo de Opera, puesto que
permitiría la inyección de código script y también el acceso al
historial de navegación del usuario (lectura de información sensible).
A continuación se explican con más detalle:
* Se ha subsanado un fallo de seguridad, provocado porque ciertas
entradas no son limpiadas de forma adecuada, por la funcionalidad
History Search, antes de ser usadas. Esto podría ser aprovechado para
inyectar código script arbitrario en la página, lo que podría ser
utilizado por un atacante para acceder al historial de navegación,
incluyendo la información sensible de las páginas visitadas.
* Un error de implementación de la funcionalidad Fast Forward podría
permitir cross-site scripting en el contexto de un frame distinto al
actual. Esto podría ser explotado por un atacante remoto para ejecutar
código JavaScript o HTML arbitrario en el contexto del frame afectado.
* Ciertos scripts no son bloqueados de forma correcta cuando se
previsualizan las fuentes de noticias. Esto podría ser aprovechado por
un atacante remoto para acceder a la colección de feeds a la que está
suscrito el usuario (revelación de información sensible), y también para
suscribirlo a otros a su elección.
Las vulnerabilidades están confirmadas para todas las versiones de
Opera, desde la 5.x hasta la 9.x.
Ahora deberemos de actualizar el Opera a la versión 9.61 Opera Ir a la Web oficial
A las 1:21pm del septiembre 24, 2008, Carles Pérez dijo...
Intento de "revival" de los virus de macro
Actualmente se están o se intenta revivir los virus de
macro, a través de un documento en Microsoft Word que está siendo
enviado a través de spam. El virus no representa ninguna evolución del
concepto y no se le espera repercusión alguna, pero supone un renovado y
discreto interés por este tipo de malware, prácticamente extinto desde
finales de los 90.
El espécimen se trata de un virus de macro "de toda la vida". Las macros
en Microsoft Office permiten ejecutar código VBA (Visual Basic for
Applications) incrustado dentro de documentos cuando son abiertos con
esta aplicación. Hasta la versión Office 2000, esto se hacía de forma
automática con todas las macros contenidas en los documentos, lo que
ayudó a popularizar lo que se llamarían los "virus de macro". Virus como
Melissa y sucesivas variantes dotaron a esta forma de ejecución
automática gran popularidad.
El archivo en concreto se ha difundido por algunos países europeos con
el nombre de Rechnung.doc. Lleva dentro incrustado un ejecutable, y la
macro se encarga de copiarlo al disco duro y ejecutarlo. Las casas
antivirus han tenido que rescatar del olvido el prefijo W97M y OF97para
denominar a Fordo, como se ha dado en llamar. La detección general por
parte de los antivirus ha aumentado en los últimos días, aunque desde un
principio ha sido muy efectiva.
La única novedad de Fordo es que en vez de ejecutar su payload
directamente desde la macro, como habitualmente se venía haciendo,
contiene en su interior un ejecutable. La macro lo copia al disco duro y
lo ejecuta. Se trata entonces de un dropper tradicional que en principio
no recurre a un servidor para descargar su componente principal.
La detección de la muestra del ejecutable contenido que hemos analizado
es aceptable. Se trata de un spyware tradicional, que intentará
conectarse a diferentes páginas.
Desde Word 2000 las macros no se ejecutan de forma automática por
defecto, a no ser que estén firmadas por alguien de confianza para el
equipo. Fordo ni siquiera usa vulnerabilidades conocidas o no para
saltarse esta restricción, simplemente confía en que el usuario o bien
use Word 97 o tenga las macros activadas en modo de seguridad "bajo" y
se ejecuten automáticamente. En caso contrario simplemente la macro será
ignorada. De ahí a que su difusión se espere muy discreta. En cualquier
caso el virus, una vez ejecutado, modifica esta opción y marca como
"bajo" el nivel de seguridad de las macros. Con esto puede llegar a
conseguir que otros virus de macro se ejecuten en el futuro.
A las 1:18pm del septiembre 24, 2008, Carles Pérez dijo...
Ubuntu y Vista problema reportado
Por el momento nos ha pasado con una máquina nueva de hace dos meses, es un DELL Vostro 1510 de 32bits.
Esta máquina viene de DELL con el Windows Vista Business.
Al llegarme a mis manos después de que su actual propietario lo dejara libre, lo formatee le instale todos los parches de Vista, los programas necesarios para que el usuario trabaje y una vez entregado al nuevo usuario, este me propone instalarle el Ubuntu 8.0.4, lo cual como sé que este usuario se defiende en Linux y sabe le deje instalarlo él mismo a su nuevo portátil, y lo que paso a sido curioso.
Cuidado si alguien tiene un Windows Vista, ya que al instalar el Ubuntu si se redimensiona la partición donde se ha instalado el Windows Vista, es decir en el mismo disco duro, después de la redimensionar Ubuntu da error y empieza a escanear el disco, si se vuelva a intentar el proceso de instalación, pero sin redimensionar la partición, ya que se ha hecho anteriormente, se instala y perfecto.
Ubuntu funciona, pero la partición de Vista no aparece, aunque se configure y se monte en el arranque lilo o grup, siempre dará error al cargar la partición de Windows.
Pero si se instala Ubuntu sin redimensionar la partición funcionan los dos entornos, o en dos discos separados todo funciona perfectamente.
Así que cuidado si tenemos un vista y queremos instalar Ubuntu en el mismo disco duro.
Lo que no sé si con otras distribucuines de Linux en Vista tiene el mismo efecto, Mandriva, RedHat, Suse, Fedora etc, pore si acaso tenedlo en cuenta.
A las 10:15am del septiembre 24, 2008, Carles Pérez dijo...
Ejecución remota de código PHP en phpMyAdmin
Se ha dado a conocer una vulnerabilidad en phpMyAdmin 2.x y 3.x que
podría ser aprovechada por un atacante remoto para ejecutar código PHP
arbitrario, pudiendo comprometer el sistema.
PhpMyAdmin es una popular herramienta de administración de MySQL a
través de Internet escrita en PHP. Este software permite crear y
eliminar Bases de Datos, crear, eliminar y alterar tablas, borrar,
editar y añadir campos, administrar privilegios y claves en campos,
exportar datos en varios formatos; y en general ejecutar cualquier
sentencia SQL. Además está disponible en más de 50 idiomas bajo licencia
GPL.
El fallo descubierto, catalogado como serio por el equipo de desarrollo
de phpMyAdmin, está causado porque el valor de entrada pasado al
parámetro "sort_by" en "server_databases.php" no se limpia de forma
adecuada antes de ser utilizado. Esto podría ser aprovechado por un
atacante remoto para inyectar y ejecutar código PHP arbitrario con los
privilegios del servidor web, lo que le permitiría conseguir el control
del sistema vulnerable. Para que el fallo de seguridad pueda ser
explotado, es necesario que el atacante disponga de credenciales de
autenticación válidas.
Se ha comprobado que el problema afecta a las versiones anteriores a la
2.11.9.1 de phpMyAdmin y también a la 3.0.0 RC1. Se recomienda
actualizar a cualquiera de las versiones no vulnerables (2.11.9.1 ó
3.0.0-rc2).
Para todos aquellos que dispongais de estas versiones instaladas, las podeis descargar las nuevas versiones de la web oficial del siguente link.
A las 10:07am del septiembre 24, 2008, Carles Pérez dijo...
Desbordamiento de búfer en ZoneAlarm Internet Security
Se ha descubierto una vulnerabilidad en el componente antivirus de Zone
Alarm Security Suite que podría ser aprovechado por un atacante para
ejecutar código arbitrario o causar una denegación de servicio.
ZoneAlarm es un cortafuegos por software producido por Check Point.
Incluye un sistema de detección de intrusiones entrantes, al igual que
la habilidad de controlar los programas que pueden crear conexiones
salientes. Existe una versión gratuita del cortafuegos y después una
serie de versiones o suites de pago que incluyen características extra.
La Internet Security Suite es su versión más completa y añade un
bloqueador de ventanas emergentes y cookies, Internet Messenger Secure,
antivirus y antispyware entre otras características.
Hace unos días se hizo público un problema de seguridad en el componente
antivirus (multiscan.exe) de esta última suite, causado por un fallo de
comprobación de límites al realizar un escáner en busca de virus sobre
archivos que estén alojados en directorios con un nombre de ruta
demasiado largo. La vulnerabilidad daría lugar a un desbordamiento de
búfer, que podría ser aprovechado por un atacante local o remoto para
causar una denegación de servicio en ZoneAlarm o para ejecutar código
arbitrario en el sistema afectado, si el usuario analiza una carpeta o
archivo con un nombre de ruta demasiado largo.
El argentino Juan Pablo Lopez Yacubian, investigador acreditado por el
descubrimiento de está vulnerabilidad, ha publicado un vídeo a modo de
prueba de concepto en el que se aprecia como un atacante local escala
privilegios, logra ejecutar código arbitrario y compromete por completo
un sistema vulnerable.
Por el momento no existe un parche disponible. La vulnerabilidad ha sido
comprobada para las versiones 7.0.483.000 y 8.0.020.000 de ZoneAlarm
Internet Security Suite y también podría afectar a otras versiones del
producto.
A las 11:22am del septiembre 5, 2008, Carles Pérez dijo...
El "secuestro" del portapapeles
Desde finales del mes pasado, muchos usuarios están detectando un
comportamiento extraño en su portapapeles. A la hora de copiar y pegar
cualquier dato, encuentran que siempre aparece almacenada en este
memoria una misma dirección de Internet, que no recuerdan haber copiado
nunca. Copian algún dato en su "clipboard", y cuando van a pegarlo esa
información ya ha sido modificada y en su lugar se memoriza una URL. No
parecen estar infectados por malware, en cuanto se visita alguna web el
problema reaparece... es solo que su portapapeles ha sido secuestrado.
Según se admite en una nota publicada por el Equipo de Respuesta ante
Incidentes de Seguridad en Productos de Adobe (Adobe Product Security
Incident Response Team) el problema está causado por una funcionalidad
en Flash Player que podría ser aprovechada por un atacante remoto para
"secuestrar" el portapapeles del sistema, forzando a que devuelva
siempre una misma cadena.
El problema se debe a que por medio de la función "setClipboard" de
ActionScript (el lenguaje de programación de Adobe Flash) se puede
modificar (pero no acceder) el contenido del portapapeles. La
descripción se puede leer en la documentación de Adobe Flash citada a
continuación: "El método System.setClipboard() permite a un archivo SWF
reemplazar el contenido del portapapeles con una cadena de caracteres en
texto claro. Esto no supone un riesgo de seguridad. Para proteger contra
los riesgos que supone que contraseñas y otra información sensible sea
cortada o copiada de los portapapeles, el método "getClipboard" de
lectura desde el portapapeles no existe".
Si se crea un archivo SWF modificado que invoque a esta función
repetidamente en bucle, cada cierto tiempo se actualizará el contenido
del portapapeles para forzar que contenga la cadena elegida.
Independientemente de la aplicación con la que se trabaje, siempre que
se intente copiar y pegar algún dato, dará como resultado la misma
cadena una y otra vez mientras el flash esté activo en una web que está
siendo visitada.
El ataque (más molesto que peligroso) se está usando para secuestrar el
portapapeles, pegando una URL que lleva a una página de un falso
antivirus que resulta ser malware. En el caso concreto detectado en los
últimos días, el código ActionScript malicioso venía incrustado en
anuncios flash alojados en sitios legítimos que tienen un gran tráfico
de visitas diarias, como Newsweek, Digg y MSNBC.
Este fallo no es realmente grave. Desde hace muchos años revive de vez
en cuando la polémica (es una funcionalidad vs. es una vulnerabilidad)
con respecto a un problema mucho más serio: El acceso al portapapeles
por parte de funciones de Internet Explorer. Aunque este ataque flash en
concreto es independiente del navegador, aun hoy día la configuración
por defecto de la mayoría de sistemas con Internet Explorer 6 permite de
forma transparente no solo modificar sino tener acceso al portapapeles.
El objeto clipboardData (incorporado en la versión 5 de Internet
Explorer) admite tres métodos para interactuar con los datos del
clipboard, "getData" para capturar la información, "setData" para
escribir, y "clearData" para borrar. Ya en 2005 Hispasec publicó una
prueba de concepto disponible en el apartado de más información.
También este ataque a través de flash recuerda al que se puso de moda
hace años, lo que se dio en llamar "secuestro del navegador" que
consistía en la modificación persistente de la página de inicio de
Internet Explorer. Mucho malware del momento era capaz de secuestrarla
con más o menos destreza. Hoy en día es una práctica en desuso.
Para "liberar" el portapapeles y que vuelva a funcionar de forma normal,
tan solo hace falta cerrar la pestaña del navegador con la que se está
visitando en el sitio web susceptible de contener el flash especialmente
manipulado.
A las 6:05pm del agosto 30, 2008, Carles Pérez dijo...
¿La seguridad de Windows Vista en entredicho?
"Como impresionar a las chicas traspasando la protección de memoria con
el navegador". Con ese jocoso título, los investigadores, Alexander
Sotirov y Mark Dowd, mostraron a una expectante audiencia en las
conferencias BlackHat 2008 como traspasar las protecciones de memoria
de Windows Vista y ejecutar a través del navegador cualquier tipo de
contenido.
Pronto, desde algunos medios, se exageró la noticia al extremo de
declarar que la seguridad de Windows Vista estaba rota y lo absurdamente
peor: Que no tenía solución y era mejor abandonar el sistema. El
sensacionalismo había prendido la hoguera de la confusión.
¿La realidad?, que no hay nada nuevo bajo el sol. No se trata de un
exploit que destruya a Windows Vista y tome el control del sistema del
usuario. Lo que Sotirov y Dowd demostraron es que es posible rebasar
las protecciones de Windows Vista para hacer lo que en cualquier otro
sistema es posible: ejecutar código.
Windows Vista implementa una serie de protecciones de seguridad para
evitar o prevenir la ejecución de código arbitrario. La tecnología DEP
(Data Execution Prevention), que permite marcar zonas de memoria no
ejecutables, ya presente en Windows XP SP2 y que se apoya en una
característica en las CPU conocida como bit NX; incluso en aquellas CPU
que no implementen el bit NX, DEP es capaz de ofrecer protección con
funcionalidad reducida. Mientras que con ASLR (Adress Space Layout
Randomization) se proporciona aleatoriedad en las direcciones del
espacio de memoria de un proceso, para dificultar la búsqueda de
direcciones "interesantes" desde el punto de vista del atacante. Además
de estás dos, Windows Vista también se beneficia de las anteriores como
la protección del heap, SafeSEH, etc.
Durante muchos años el anhelo de los diseñadores de sistemas operativos,
en materia de seguridad, ha sido neutralizar la ejecución de código
malicioso. Las características mencionadas anteriormente introducen una
mayor protección pero el ingenio humano carece de límites cuando se le
reta y en este caso Sotirov y Dowd lo han demostrado. Han desmontado una
a una las protecciones y han vuelto a reproducir vulnerabilidades
conocidas.
En palabras de los investigadores, estas protecciones elevan el nivel
de seguridad pero no son definitivas. Factores como la carga de
responsabilidad del navegador y su propia arquitectura con capacidad
para interpretar código, incrustar aplicaciones, imágenes y todo tipo de
aplicaciones de terceros vía plugins hacen que el atacante invierta su
tiempo en encontrar vectores sobre el navegador para llegar al sistema.
A las 7:18pm del agosto 24, 2008, Carles Pérez dijo...
Para los que utilizeis el Navegador Opera mirar este comentario.
Se ha lanzado la versión 9.52 del navegador Opera, que corrige un total
de siete vulnerabilidades, una de ellas de nivel crítico, que podrían
ser aprovechadas por un atacante remoto para perpetrar ataques de
falsificación y cross-site scripting, saltarse restricciones de
seguridad, revelar información sensible, causar una denegación de
servicio o ejecutar código arbitrario en un sistema vulnerable.
Opera, además de ser un navegador web, contiene cliente de correo
electrónico con gestor de contactos, cliente de IRC, lector de noticias
RSS y gestor para la descarga de archivos torrent.
La versión 9.5, con aspecto y características renovadas, fue lanzada a
mitad de junio y recientemente se ha publicado su segunda revisión de
seguridad (a la versión 9.52), después de que la v.9.51, publicada a
principios de julio, solventara tan sólo dos fallos de seguridad.
De las siete vulnerabilidades corregidas recientemente, la primera está
catalogada como extremadamente severa por el equipo de Opera, puesto que
permitiría la ejecución remota de código. A continuación se explican con
detalle todos los problemas solventados:
* Se ha subsanado un fallo de seguridad provocado por un error no
especificado en Opera al funcionar como un manejador para ciertos
protocolos. En este modo, el navegador puede ser llamado por una
aplicación externa, lo que podría ser aprovechado por un atacante
remoto para ejecutar código arbitrario. Esta vulnerabilidad solo
afecta a la versión de Opera para Windows.
* Se ha corregido una vulnerabilidad que consiste en un error en la
manera en que Opera comprueba qué marcos pueden ser modificados en una
página web. Mediante un sitio web malicioso, un atacante remoto podría
cargar contenido modificado en el marco de una página emergente
confiable.
* Se ha corregido un fallo no especificado que podría permitir que un
atacante remoto perpetrase ataques de tipo cross-site scripting,
pudiendo ser explotado para ejecutar código JavaScript o HTML en el
contexto de de la sesión del navegador de un usuario que visita un sitio
web afectado.
* Se ha solventado una vulnerabilidad que consiste en un error al
procesar atajos de teclado personalizados y comandos de menú utilizados
para llamar a aplicaciones externas. En determinados casos, los
parámetros pasados a las aplicaciones no son formateados correctamente
y podrían ser creados desde una zona de memoria no inicializada. Los
valores de dicha zona de memoria podrían ser interpretados de forma
errónea como si fueran parámetros adicionales, lo que, dependiendo de la
aplicación, podría ser aprovechado por un atacante remoto para ejecutar
código arbitrario. Esta vulnerabilidad afecta a las versiones de Opera
para Windows, Linux, FreeBSD y Solaris.
* Se ha corregido otro problema causado por un error al indicar en Opera
información sobre la seguridad de una pagina web. Una página no segura
podría mostrarse como segura si cargase contenido de un sitio seguro
en un frame. Un atacante remoto podría modificar así el estado de no
confiable a confiable del icono que indica la seguridad de una pagina
web, aunque sin mostrar ningún certificado de seguridad.
* Se ha solventado un posible salto de restricciones de seguridad que
podría permitir que un atacante, a través de un script, comprobase la
existencia de determinados archivos en un sistema local, por medio de
intentos de suscripción a los mismos a través de una página web.
* El último fallo está causado por un error al procesar nuevas
peticiones de suscripciones a fuentes (feeds) a través del botón de
suscripción. Un atacante remoto podría aprovecharse de la vulnerabilidad
para modificar el campo de dirección de la barra del navegador, pudiendo
mostrar una URL falsificada.
Las vulnerabilidades están confirmadas para todas las versiones de
Opera, desde la 5.x hasta la 9.x.
He instalado Ubuntu 8.04 en un Lenovo T61 con Vista Business preinstalado, y coexisten los dos sin problema incluso habiendo redimensionado la partición de Vista.
A las 2:15pm del agosto 18, 2008, Carles Pérez dijo...
¿Has reproducido con Windows Media Player algún archivo de audio o
video últimamente? Podrías estar infectado.
A finales de Julio hubo bastante revuelo con la aparición de un nuevo
troyano que afectaba a archivos multimedia. Este malware, que muchas
casas antivirus han denominado GetCodec, emplea una técnica de infección
que no había sido vista hasta el momento.
El troyano se ha detectado propagándose encubierto como cracks en
páginas de warez y cracks. Es totalmente silencioso, lo cual induce a
pensar que tan sólo se trata de otro crack corrupto más. Tras su
ejecución, el troyano busca todos aquellos archivos con extensiones
.MP2 .MP3 .WMA .WMV .ASF. El formato ASF es un formato propietario de
Microsoft empleado por Windows Media Player que permite introducir
secuencias ejecutables en flujos de audio/video. El troyano aprovecha
esta propiedad para introducir en los archivos multimedia de la
víctima una secuencia que solicita la descarga de un codec falso desde
un Sitio Web. Éste codec es a su vez otro troyano, aunque la técnica
podría emplearse para servir cualquier tipo de contenido.
Este método de infección también funciona con los archivos MPx porque
el troyano los convierte primero a formato ASF para después
inyectarles el código malicioso. De forma que un archivo con extensión
.MP3 puede estar infectado.
El espécimen modifica la configuración del usuario de tal forma que
este nunca llega a notar que sus archivos multimedia han cambiado, sin
embargo, todo aquel que no esté infectado e intente reproducirlos sí
notará el cambio. Cuando se reproduce un archivo multimedia infectado,
en una máquina limpia, Windows Media Player despliega una ventana
solicitando la descarga de un codec falso. Este codec puede ser
cualquier otro tipo de malware. Al aceptar la descarga se produce la
infección.
Tal y como se puede intuir, estas características lo hacen ideal para
la propagación vía redes P2P, unidades compartidas e intercambio de
medios de almacenamiento. Tomando como ejemplo las redes P2P,
cualquier usuario infectado estará actuando como servidor del malware.
Otro usuario que descargue sus archivos multimedia se verá infectado
si no es lo suficientemente cuidadoso.
A las 12:53pm del agosto 17, 2008, Carles Pérez dijo...
Apple ha sido el último en aplicar el parche del fallo de DNS, por lo que ya casi todos los grandes fabvricantes ya tienen está vulnerabilidad reparada muy grave.
Como es conocido el fallo detectado de DNs en él cuál la vulnerabilidad que permitía
falsificar las respuestas DNS, y por tanto redireccionar el tráfico a otros servidores, la resolución de nombres y de
problemas en los servidores DNS, la gravedad se multiplica porque se
supone que los servidores DNS sustentan la red.
..:::: Dan Kaminsky había
descubierto un fallo de base en el protocolo que permitía a cualquiera
falsificar las respuestas de un servidor. No era problema de ningún
fabricante sino de casi todos, un fallo de diseño de un estándar usado
en todo Internet. En un importante esfuerzo de coordinación todos los
grandes fabricantes están publicado sus actualizaciones desde el día
8 de julio.
Pero Dan Kaminsky no daba detalles sobre el asunto. Era demasiado grave
y pensaba que sería irresponsable proporcionar esa información sin dar
suficiente tiempo a todos los administradores para actualizar. Del
parche no se podía deducir el problema puesto que simplemente añadía
aleatoriedad y entropía a ciertos valores que desde hace mucho se sabía
que no eran la mejor solución para asegurar el protocolo. Es por esto
que se apostaba desde un principio por que la vulnerabilidad de Kaminsky
se tratara en realidad de una nueva forma más eficaz de engañar a los
servidores DNS para que den respuestas falsas, gracias a un fallo
inherente del protocolo (y así ha sido).
Kaminsky daría los detalles un mes después, en la conferencia Black Hat
de agosto. Por una parte, el descubridor estaba siendo responsable
(dando tiempo a los administradores) pero tremendamente mediático por
otra (creando una expectación exagerada en torno a la conferencia).
Todo esto, ayudado por la desinformación de los medios generalistas
ha ayudado a que la desconfianza siguiese creciendo. Todos defendían
su teoría: desde el escéptico hasta el que hablaba de la debacle de la
Red. Sólo un grupo de personas concretas conocía los detalles técnicos,
y tenían instrucciones de no revelarlos y de evitar las especulaciones
públicas. Kaminsky pretendía así ingenuamente asegurarse que sólo él
daría los detalles cuando lo tenía planeado, cumpliendo así la segunda
parte de su plan una vez publicadas las actualizaciones. Imposible...
poco después las listas estaban llenas de comentarios y elucubraciones.
Afortunadamente en la seguridad informática siempre hay alguien que
va más allá. Thomas Dullien, el CEO de la compañía Zynamics (también
conocido como Halvar Flake) se aventuró a publicar en su blog su
particular visión de lo que podía ser el problema descubierto por
Kaminsky, sin tener conocimiento previo de los detalles. Y no se
equivocó en su teoría. La insinuación de que estaba en lo cierto vino
desde varios frentes (entre ellos desde un post en Twitter del propio
Kaminsky), pero lo confirmó totalmente una entrada del lunes pasado en
el blog de Thomas Ptacek, director la compañía Matasano que era de los
que conocía los detalles reales. La entrada estaba firmada por un/a tal
"ecopeland" del equipo de Ptacek. Según linkedin.com existe un/a Erin
Ptacek (Copeland), desarrollador/a de software en Matasano (¿familiar
del director?). En el post se daba la razón a Dullien, junto con todo
lujo de detalles sobre el fallo que Dullien había 'redescubierto'. La
explicación fue retirada poco después (actualmente está disponible a
través de la caché de Google). Ptacek se ha disculpado públicamente,
probablemente se dejó llevar por su ánimo de compartir la información.
Demasiado tarde... ya circula libremente por Internet.
Los detalles técnicos pueden ser encontrados en el apartado de más
información. No tardarán en aparecer exploits. Ahora la gravedad del
problema se multiplica. Afortunadamente casi todos los fabricantes han
publicado ya un parche.
Aunque se conocía el problema desde enero, Kaminsky trabajó intensamente
con los grandes fabricantes para mantenerlo en secreto y coordinar la
aparición de parches un día concreto (que tuvo que coincidir con el día
de actualización de Microsoft). Esto resulta extremadamente complicado,
y hay que reconocer que ha debido resultar un trabajo complejo el
coordinar y mantener la discreción sobre un tema tan delicado. Un
esfuerzo elogiable. Sin embargo desde que se anunció la existencia del
problema, sólo se han necesitado dos semanas para que sea desvelado,
frustrando el plan de Kaminsky de aguantar un mes hasta la Black Hat
para revelar los detalles.
Son muchas las moralejas y conclusiones que se pueden extraer de este
incidente. De nuevo el debate sobre la revelación responsable de
vulnerabilidades, la fuerza del ego de muchos investigadores, la
demostración de que un esfuerzo coordinado para una actualización masiva
ante un problema común es posible... pero sobre todo llama la atención
la capacidad de Thomas Dullien de redescubrir un problema que siempre
habría estado ahí, pero que no se había planteado buscar hasta que
alguien apuntó que existía. Dullien contaba con las bases (el protocolo
DNS sufre de problemas inherentes conocidos) sólo había que mover las
piezas para encontrar lo que podía ser el fallo que otro decía ya saber.
Y acertó. Una de las mejores formas de captar el interés de un asunto,
(aunque siempre haya estado ante nuestras narices y creamos conocerlo)
es afirmar que oculta un secreto.
House of sysadmins
House of sysadmins
Comentarios de Carles Pérez
Comentario (24 comentarios)
Necesitas ser un miembro de House of sysadmins para añadir comentarios!
Participa en esta red social
Acelerar los discos duros:
En este tip vamos a ver como aumentar la velocidad de los discos duros en Windows Vista, en primer lugar para discos duros SATA, y luego para discos USB. Estas opciones se pueden configurar de manera muy fácil desde el Administrador de Dispositivos.
Para ello tendremos que activar una opción llamada Cache de escritura, que por defecto no viene activa en Windows Vista. No se porqué no está activa por defecto, pero sí que si la activámos aumenta el rendimiento del sistema, aunque como refleja su activación si no disponemos de una SAI y tenemos cortes de corriente, es posible la perdida de datos.
Abrimos el Administrador de dispositivos, para ello escribe devmgmt.msc en el cuadro de Ejecutar. Ve al desplegable de Unidades de Disco, y haz clic derecho sobre el disco duro que quieras. Escoge la opción Propiedades. Ahora ve a la pestaña de Directivas, y activa la opción Habilitar Rendimiento Avanzado.
Nota: Tienes que repetir el proceso por cada disco duro que tengas instalado en tu sistema.
Puedes seguir este procedimiento también para tus discos duros externos conectados por USB. Abre de nuevo la pestaña de Directivas en el disco duro USB, y selecciona Optimizado para Rendimiento en las opciones. Este método tiene un punto muy a tener en cuenta, que es que necesitarás retirar siempre el Hardware de forma segura siempre que vayas a desenchufar el disco del ordenador.
Aceptar conexiones de equipos con una version anterior de escritorio remoto
1. Abre Inicio y haz clic con el botón derecho del ratón sobre Equipo.
2. Pulsa sobre Propiedades.
3. Haz clic sobre el enlace Configuración avanzada del sistema (en el panel de la izquierda).
4. Cuando aparezca la ventana de confirmación, haz clic sobre Continuar.
5. Selecciona la pestaña Acceso remoto.
6. Selecciona la opción Permitir las conexiones desde equipos que ejecuten cualquier versión de Escritorio remoto (menos seguro).
Este viernes los servidores de la fundación Apache presentaron durante
unas cuantas horas una escueta página informando que se encontraban
investigando un incidente en sus servidores.
Aclaraban que no se trataba de un exploit que afectase al popular
servidor web, producto de la propia fundación, sino de una llave SSH
comprometida.
La llave en cuestión permitía el acceso a una cuenta para efectuar
copias de respaldo automáticas del sitio web "ApacheCon", en una máquina
situada en un alojamiento externo a la fundación. Dicha máquina fue
usada para subir archivos a un servidor de su infraestructura,
denominado minotaur.apache.org, con funciones notables, como proveer de
cuentas para los "comitters" -cuentas con acceso de escritura a los
repositorios de código- y de entrada a los distintos sitios web de la
fundación Apache.
Según las primeras investigaciones, fueron creados varios archivos
dentro del dominio "www.apache.org", incluyendo varios scripts CGI, que
fueron usados para sincronizar dichos archivos con varios servidores en
producción e inyectar procesos en los servicios web funcionales.
Tras detectar los procesos que inyectaron los atacantes procedieron a
detener los sistemas afectados, de esta manera, por algunos instantes,
no se podía acceder a ninguno de los sitios web de Apache, hasta que se
procedió a cambiar los DNS hacia una máquina no afectada para mostrar un
mensaje informativo indicando la situación en la que se encontraban.
Después de asegurarse de que la infraestructura que la fundación posee
en Europa no estaba afectada -los atacantes llegaron a subir los
archivos pero no fueron ejecutados-, usaron las copias de respaldo no
comprometidas para restaurar los servicios en lo posible, permaneciendo
gran parte de su infraestructura detenida para evaluar los daños
causados por los atacantes.
Aunque, según Apache, no tienen conocimiento de usuarios finales
afectados, ni de que las descargas fueran afectadas, enfatizan efectuar
la verificación de la firma digital de los archivos.
(BSOD) en Windows Vista y 7 a través de unidades compartidas
-----------------------------------------------------------------------------------------------
Laurent Gaffié ha detectado un fallo de seguridad en Windows Vista que
podría permitir a un atacante provocar un BSOD (pantallazo azul, una
denegación de servicio) con solo enviar algunos paquetes de red
manipulados a una máquina que tenga activos los servicios de
compartición de archivos (protocolo SMB).
El fallo (incomprensiblemente simple) está en el intérprete de las
cabeceras SMB, concretamente en el driver srv2.sys. Como los
controladores operan en el "ring0", la capa de abstracción del sistema
operativo más cercana al hardware (en contraste con el "ring3", la capa
de usuario que no interactúa directamente con él) un fallo en cualquier
driver provoca que el sistema se bloquee por completo, al no poder
manejar la excepción correctamente. Se trata del temido pantallazo azul,
o BSOD. Los Windows anteriores a Windows 2000 no realizaban esta
separación de seguridad entre capas, por lo que todo operaba en el mismo
espacio de memoria y los fallos en el espacio de usuario podían causar
un bloqueo total del sistema. De ahí que los pantallazos azules fuesen
mucho más comunes en Windows 9x y Me.
El ataque es tan sencillo que recuerda a los "pings de la muerte" que
hicieron estragos a finales de los 90 en los sistemas Windows. Contenían
un fallo en la pila TCP que hacía que, si se enviaba un ping al sistema
especialmente manipulado (simplemente especificando con un parámetro,
por ejemplo, un tamaño mayor del paquete) se podía hacer que el sistema
dejara de responder. Esto, unido a la carencia de cortafuegos del
sistema, a que en aquellos momentos las conexiones se realizaban a
través de módem (que carecía de protección por cortafuegos o NAT) y el
hecho de no existir servicio de actualización automático del sistema,
hicieron muy popular el ataque.
Este fallo en el protocolo SMBv2 de compartición de archivos requiere
igualmente del envío de una sencilla secuencia de paquetes SMB (al
puerto 445) al sistema víctima con las cabeceras manipuladas. El truco
está en enviar un carácter "&" en el campo "Process Id High" de las
cabeceras SMBv2. Esto provoca una excepción en srv2.sys que provoca el
pantallazo azul. El exploit es público y realmente sencillo.
Vista mantiene el cortafuegos activo por defecto para su perfil
"público", y esto mitiga el problema. Pero todo depende del perfil. Si
el usuario usa un perfil de cortafuegos (ya sea de dominio, o el perfil
privado) en el que permite las conexiones a sus unidades compartidas
(puerto 445, normalmente abierto en las redes locales) será vulnerable.
No es necesario que comparta realmente una unidad, solo que el protocolo
SMB esté activo y preparado para compartir en su sistema. Esto puede
resultar especialmente grave en redes internas.
No existe parche oficial disponible. Se recomienda filtrar el puerto 445
(y los implicados también en la compartición de ficheros 137-139) a
través de cortafuegos. También es posible detener el servicio "Servidor"
del sistema (aunque se puede llegar a perder funcionalidad). Otra
contramedida posible es desactivar la casilla "compartir archivos e
impresoras" que aparece en las propiedades de las interfaces de red.
Aunque el ataque no permite ejecución de código y es poco viable que
pueda propagarse por la red pública, sí que puede resultar más que
molesto en redes internas donde los usuarios normalmente mantienen
reglas de cortafuegos mucho más relajadas. ¿Vuelven los tiempos del
"ping de la muerte"?.
Estos últimos meses ya he tenido la experiencia de Ver como mi Windows Vista Business de 64bits , ha perdido la relación de confianza con el servidor, en tres ocasiones.
Es Genial, cojonudo los fallitos de Vista, por qué con solo bloquear la sesión y al cabo de unos minutos volver e intentar desbloquear la sesión aparece el mensage de "Ha perdido la reclación de confianza entre ala estación de trabajo y el dominio principal".
Brutal!!!!!, buscando en Microsoft para no tener que hacer lo que ya he hecho en estas ocasiones, quitarlo y volverlo a poner en el dominio, Microsoft dice que hay que hacer eso exáctamente eso, quitarlo y volverlo a añadir.
Cosa que con estos siete años con Windows XP, y en la misma red nunca me sucedio esto, en Windows vista con un año y medio ya son tres veces, menos mal que solo lo tengo yo, que si esto lo tuvieran más personas en mi empresa, ya podriamos ir apañados.
Supongo que no hay otra opción, por lo menos yo no la he visto, ni em Microsoft ni por San Google. Así que si alguien le pasa y no sabe una opción más rápida, por lo que yo sé la más rápida es esta
"Quitar cera, Poner cera Windows SAN"
Tiempo estimado en tener otra vez la máquina lista 20 minutos.
Se ha anunciado una vulnerabilidad en Samba por la que un usuario remoto
autenticado podría llegar a acceder a determinados archivos del sistema.
Samba es una implementación Unix "Open Source" del protocolo
SMB/NetBIOS, utilizada para la compartición de archivos e impresora en
entornos Windows. Gracias a este programa, se puede lograr que máquinas
Unix y Windows convivan amigablemente en una red local, compartiendo
recursos comunes.
El problema reside cuando un usuario remoto autenticado se conecta a un
compartido con un nombre vacío ("") mediante una versión antigua de
smbclient (anterior a 3.0.28), el usuario podrá acceder a la raíz del
sistema de archivos ("/"). Por ejemplo con: smbclient //server/ -U
user%pass
Se ven afectados los sistemas configurados como: "registry shares = yes"
y con "include = registry" y "config backend = registry" (no se trata de
la configuración por defecto).
Se ha publicado la versión 3.2.7 que corrige este problema.
Hace unos días, tanto el SANS como distintas casas antivirus advertían
de un comportamiento más que curioso en la vieja conocida familia de
malware DNSChanger. Esta ha evolucionado sustancialmente: Comenzó con el
cambio local de la configuración de servidores DNS en el sistema (para
conducir a la víctima a los servidores que el atacante quiera). Ha
llegado hasta el punto de instalar una especie de servidor DHCP e
infectar así a toda una red interna. Los servidores DNS que instala
el malware suelen estar en la red conocida como UkrTeleGroup.
La familia DNSChanger
Una característica interesante de DNSChanger es que es una de las
familias que más han atacado a sistemas Mac, además de a Windows. Entre
otras muchas formas de toparse con ellos, se suelen encontrar en
servidores eMule, camuflados bajo la apariencia de otros programas.
Es una familia conocida desde hace unos tres años. Se caracterizan por
modificar los servidores DNS de la víctima a la que infectan. De esta
forma, la asociación IP-Dominio queda bajo el control del atacante, de
manera que la víctima irá a la IP que el atacante haya configurado en su
servidor DNS particular. Normalmente, se confía en los DNS de los ISP,
pero si se configura cualquier otro, realmente la resolución queda a
merced de su administrador, cualesquiera que sean sus intenciones.
DNSChanger comenzó modificando la configuración del sistema en local, de
forma que cambiaba los servidores DNS del ISP de la víctima por otros
controlados por el atacante. Después, el malware evolucionó hacia la
modificación del router ADSL de la víctima. Buscaba la "puerta de
enlace" del sistema, que suele corresponderse con el router, y realizaba
peticiones o aprovechaba vulnerabilidades de routers conocidos para
modificar estos valores. Así el usuario se veía afectado por el cambio
pero de una forma mucho más compleja de detectar. Además, también se
verían afectadas el resto de las máquinas que tomaran estos valores del
propio router.
Dando un paso más allá
La última evolución observada implica la instalación en la víctima de un
pequeño servidor DHCP. Este es el protocolo usado en las redes locales
para que cuando un sistema se conecta a la red, el servidor lo reconozca
y le proporcione de forma automática los valores necesarios para poder
comunicarse (dirección, ip, puerta de enlace...). Habitualmente también
proporciona los valores de los servidores DNS que haya establecido el
administrador o el router.
El malware instala un driver que le permite manipular tráfico Ethernet a
bajo nivel, o sea, fabricar paquetes de cualquier tipo. Con esta técnica
simula ser un servidor DHCP. Cuando detecta preguntas de protocolo DHCP
legítimas de algún sistema en la red, el malware responde con su propia
configuración de DNS, de forma que el ordenador que acaba de enchufarse
a la red local, quedaría configurado como el atacante quiere, y no como
el administrador ha programado. El atacante confía en la suerte, pues el
servidor DHCP legítimo de la red, si lo hubiese, también respondería.
Quien llegue antes "gana". Consiguen así infecciones "limpias", pues es
complicado saber quién originó el tráfico si éste no es almacenado y
analizado. Además, con este método se pueden permitir realizar muchos
otros ataques en red local con diferentes impactos.
¿Qué valores DNS introduce el malware?
DNSChanger es una familia que necesita de una importante infraestructura
para que sea útil. Los servidores DNS (bajo el control de los atacantes)
de los que se vale, los que modifica en el usuario, suelen estar
alojados en la compañía ucraniana UkrTeleGroup, bajo el rango de
red 85.255.x.y. Casi un 10% de todas las máquinas en ese rango de
direcciones se corresponden con servidores DNS públicos que no contienen
las asociaciones legítimas de domino y dirección IP. En ocasiones
utilizan el servidor DNS para asociar dominios a la IP reservada
127.0.0.1, como es el caso del servidor de descargas de Microsoft
download.microsoft.com. Con esto se consigue que la víctima no pueda
actualizar el sistema operativo con parches de seguridad. Curiosamente,
al parecer, las direcciones de actualización de Apple no están
bloqueadas (a pesar de que suele afectar a este sistema operativo).
También se bloquean un buen número de páginas de actualizaciones de
casas antivirus.
Algunos de estos servidores DNS (ATENCIÓN: no configurarlos en el
sistema bajo ningún concepto) son:
85.255.122.103, 85.255.113.114, 85.255.122.103, 85.255.112.112...
Sólo son necesarias algunas consultas "dig" (comando para averiguar qué
direcciones están relacionadas con qué dominios en un servidor DNS) para
comprobar qué dominios "interesan" o no a los atacantes.
El día 24 de diciembre un mensaje en la lista de correo Bugtraq hacía
pública una supuesta vulnerabilidad en Windows Media Player que afectaba
a todas las versiones en todos los sistemas. El fallo en sí es un
desbordamiento de entero producido al procesar un archivo especialmente
manipulado en los formatos WAV, SND, o MID. La antesala a una ejecución
de código arbitrario.
El mensaje iba acompañado de una prueba de concepto, un script en Perl
que al ejecutarlo nos deja un archivo en formato MIDI que al ser abierto
por Windows Media Player provoca el cierre de la aplicación. Hasta ahí
todo correcto, era cuestión de tiempo para comenzar a ver exploits que
fuesen capaces de aprovechar el fallo para alcanzar el cáliz de las
vulnerabilidades: ejecutar código arbitrario. Pero días después no se
escuchaba nada, no había ruido de sables, no había exploit.
Según Christopher Budd del MSRC (Microsoft Security Response Center),
quien se queja de que el investigador no haya contactado con ellos antes
de su publicación, no hay vulnerabilidad. No hay posibilidad alguna de
ejecutar código. De hecho, según Jonathan Ness del SWI (Microsoft
Security Windows Initiative) incluso fue descubierto por ellos en sus
auditorías internas y ya está solucionado en el Service Pack 2 de
Windows Server 2003.
Sin entrar en detalles técnicos, la prueba de concepto proporcionada es
procesada por "quartz.dll" un componente de DirectShow encargado de los
archivos con extensión WAV, SND, y MID. El desbordamiento de entero
ocurre en una instrucción DIV -concretamente cuando se ejecuta EAX =
(EDX:EAX)/reg y el resultado no entra en el registro de 32 bits- , pero
la excepción levantada no es capturada por 'quartz.dll', ni se produce
corrupción de memoria.
Así que el susto se queda relegado a la categoría de bug y se programa
su eliminación para la próxima actualización de mantenimiento.
Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3718/comentar
Más información:
Marco Ramilli - Windows Media Player Integer Overflow
http://marcoramilli.blogspot.com/2008/12/windows-media-player-integer-overflow.html
Bugtraq - MS Windows Media Player * (.WAV) Remote Integrer Overflow
http://www.securityfocus.com/archive/1/499579
SVRD - Windows Media Player crash not exploitable for code execution
http://blogs.technet.com/swi/archive/2008/12/29/windows-media-player-crash-not-exploitable-for-code-execution.aspx
MSRC - Questions about Vulnerability Claim in Windows Media Player
http://blogs.technet.com/msrc/archive/2008/12/29/questions-about-vulnerability-claim-in-windows-media-player.aspx
Se ha informado que existe una vulnerabilidad crítica en el plugin "Now
playing" gen_msn para el reproductor Winamp, que podría permitir la
ejecución remota de código.
Este popular complemento de Winamp (con más de 750.000 descargas) es el
que permite activar la funcionalidad "Lo que estoy escuchando" del
sistema de mensajería instantánea de Microsoft Live Messenger. Dicha
funcionalidad muestra como parte de nuestro apodo, el nombre del artista
y la canción que se está reproduciendo en ese momento en Winamp.
El fallo está causado por un desbordamiento de búfer basado en heap en
gen_msn.dll, al intentar procesar una lista de reproducción (archivo
.pls) especialmente manipulada que contenga entradas demasiado largas.
Todavía no existe parche disponible y la vulnerabilidad ha sido
confirmada con la aparición de un exploit público que afectaría a las
versiones más recientes del plugin (gen_msn v.0.31) y del reproductor
(Winamp 5.541).
Se recomienda no abrir archivos pls no confiables y, a ser posible,
deshabilitar el plugin hasta que esté disponible una nueva versión no
vulnerable.
Los investigadores alemanes Erik Tews y Martin Beck dicen haber
conseguido saltarse parcialmente la seguridad que proporciona WPA (Wi-Fi
Protected Access) en las redes inalámbricas. WPA vino a salvarnos del
inseguro WEP (Wired Equivalent Privacy), que fue vencido pocos años
después de su estandarización y que hoy en día es un cifrado obsoleto.
Este descubrimiento hace pensar que WPA parece ir por el mismo camino.
Segundo ataque al algoritmo de cifrado y autenticación WPA para redes
inalámbricas, y esta vez va en serio. A principios de octubre se publicó
la noticia de que la compañía rusa ElcomSoft había conseguido reducir
sustancialmente el tiempo necesario para recuperar una clave de WPA,
ayudándose de tarjetas gráficas NVIDIA. Al parecer el método conseguía,
a través de fuerza bruta, deducir claves extraordinariamente rápido. La
fuerza bruta no supone un ataque o una debilidad del WPA en sí, por
tanto el cifrado se mantenía relativamente a salvo siempre que se usase
una contraseña suficientemente larga y entrópica. El descubrimiento de
ElcomSoft no era tan relevante en este sentido. Todo es susceptible de
ser atacado por fuerza bruta. Sin embargo lo que Tews y Beck han
encontrado sí es un problema inherente a una parte de WPA, un fallo en
la criptografía usada en muchas configuraciones.
Es importante recalcar que el método descubierto no permite recuperar
la contraseña. Y que tampoco influye el método de autenticación. El
problema está en el cifrado. Está limitado a descifrar paquetes
concretos o inyectar nuevos (y sólo una pequeña cantidad). También es
necesario destacar que el ataque sólo funciona si se utiliza el cifrado
TKIP, no el AES. El ataque inminente y posible es provocar una
denegación de servicio o inyectar paquetes ARP, lo que puede hacer que
se redirija el tráfico. Insistimos en que no es posible por ahora
recuperar la clave o descifrar todo el tráfico.
WPA puede usar diferentes algoritmos de cifrado: AES (estándar y seguro
por ahora) y el Temporal Key Integrity Protocol (TKIP). Aquí es donde se
ha encontrado la vulnerabilidad. Un ataque basado en la misma técnica
que volvió obsoleto al WEP (ataque conocido como chopchop) ha permitido
que se pueda descifrar un paquete de tipo ARP en menos de 15 minutos,
independientemente de la contraseña usada para proteger el WPA. TKIP
se creó precisamente para solucionar los problemas de WEP. Por ejemplo
añade entre otras, comprobación de integridad del mensaje (MIC) en vez
del débil CRC32 que usaba WEP. El problema es que TKIP también conserva
varios peligros heredados de WEP. TKIP se creó para que fuese compatible
con los dispositivos que ofrecían WEP sólo con actualizaciones del
firmware, sin necesidad de cambiar el hardware: un parche.
Los analistas han observado que aprovechándose de estas similitudes, y
eludiendo las mejoras introducidas con TKIP, se puede realizar un ataque
muy al estilo del que se creó contra WEP y con resultados limitados.
Para ello atacan a paquetes ARP (se usan estos paquetes porque son
pequeños y sólo quedan por conocer 14 bytes, una vez que se sabe en qué
subred nos movemos) y el resultado es que se puede descifrar en menos de
15 minutos. Para otros paquetes se debería emplear más tiempo. El truco
es usar un canal o cola QoS diferente de donde fue recibido el paquete.
El ataque funciona incluso si la red no tiene funcionalidad QoS.
En una versión en desarrollo de aircrack-ng, se puede encontrar la
implementación del ataque. Es bastante probable que, en cuestión de
tiempo, se mejore el ataque y se rompan las limitaciones que por ahora
sufre.
Los usuarios y administradores que usen WPA deben cambiar en la medida
de lo posible al cifrado AES, o mejor aún pasar a WPA2 que soluciona de
raíz el problema. Si no es posible, también cabe la posibilidad de
configurar WPA para que el recálculo de claves sea cada, por ejemplo,
120 segundos o menos. Aunque esto puede tener cierto impacto sobre el
rendimiento.
Si bien el algoritmo de cifrado no está completamente comprometido,
sí que puede servir de trampolín para que se estudien nuevas técnicas
y pueda ser finalmente roto. Lo mejor es que supone una llamada de
atención para actualizar a un protocolo más seguro como es WPA2, pero
sin que se corra un riesgo inminente y catastrófico al mantener el WPA
por ahora.
La versión 9.61 del navegador Opera corrige tres vulnerabilidades que
podrían ser aprovechadas por un atacante remoto para perpetrar ataques
de cross-site scripting, saltarse restricciones de seguridad o revelar
información sensible en un sistema vulnerable.
Opera, además de ser un navegador web, contiene cliente de correo
electrónico con gestor de contactos, cliente de IRC, lector de noticias
RSS y gestor para la descarga de archivos torrent, y un buen gestor de contraseñas.
La nueva versión 9.6, con aspecto y características mejoradas, fue lanzada a
principios de este mes, y ahora se publica la primera revisión de
seguridad sobre la misma.
De las tres vulnerabilidades corregidas recientemente, la primera está
catalogada como extremadamente severa por el equipo de Opera, puesto que
permitiría la inyección de código script y también el acceso al
historial de navegación del usuario (lectura de información sensible).
A continuación se explican con más detalle:
* Se ha subsanado un fallo de seguridad, provocado porque ciertas
entradas no son limpiadas de forma adecuada, por la funcionalidad
History Search, antes de ser usadas. Esto podría ser aprovechado para
inyectar código script arbitrario en la página, lo que podría ser
utilizado por un atacante para acceder al historial de navegación,
incluyendo la información sensible de las páginas visitadas.
* Un error de implementación de la funcionalidad Fast Forward podría
permitir cross-site scripting en el contexto de un frame distinto al
actual. Esto podría ser explotado por un atacante remoto para ejecutar
código JavaScript o HTML arbitrario en el contexto del frame afectado.
* Ciertos scripts no son bloqueados de forma correcta cuando se
previsualizan las fuentes de noticias. Esto podría ser aprovechado por
un atacante remoto para acceder a la colección de feeds a la que está
suscrito el usuario (revelación de información sensible), y también para
suscribirlo a otros a su elección.
Las vulnerabilidades están confirmadas para todas las versiones de
Opera, desde la 5.x hasta la 9.x.
Ahora deberemos de actualizar el Opera a la versión 9.61 Opera
Ir a la Web oficial
Actualmente se están o se intenta revivir los virus de
macro, a través de un documento en Microsoft Word que está siendo
enviado a través de spam. El virus no representa ninguna evolución del
concepto y no se le espera repercusión alguna, pero supone un renovado y
discreto interés por este tipo de malware, prácticamente extinto desde
finales de los 90.
El espécimen se trata de un virus de macro "de toda la vida". Las macros
en Microsoft Office permiten ejecutar código VBA (Visual Basic for
Applications) incrustado dentro de documentos cuando son abiertos con
esta aplicación. Hasta la versión Office 2000, esto se hacía de forma
automática con todas las macros contenidas en los documentos, lo que
ayudó a popularizar lo que se llamarían los "virus de macro". Virus como
Melissa y sucesivas variantes dotaron a esta forma de ejecución
automática gran popularidad.
El archivo en concreto se ha difundido por algunos países europeos con
el nombre de Rechnung.doc. Lleva dentro incrustado un ejecutable, y la
macro se encarga de copiarlo al disco duro y ejecutarlo. Las casas
antivirus han tenido que rescatar del olvido el prefijo W97M y OF97para
denominar a Fordo, como se ha dado en llamar. La detección general por
parte de los antivirus ha aumentado en los últimos días, aunque desde un
principio ha sido muy efectiva.
http://www.virustotal.com/analisis/d67fcf69c3b2218dba79f4b154e6b930
La única novedad de Fordo es que en vez de ejecutar su payload
directamente desde la macro, como habitualmente se venía haciendo,
contiene en su interior un ejecutable. La macro lo copia al disco duro y
lo ejecuta. Se trata entonces de un dropper tradicional que en principio
no recurre a un servidor para descargar su componente principal.
La detección de la muestra del ejecutable contenido que hemos analizado
es aceptable. Se trata de un spyware tradicional, que intentará
conectarse a diferentes páginas.
http://www.virustotal.com/es/analisis/def454a819753c1549253844a6249708
Desde Word 2000 las macros no se ejecutan de forma automática por
defecto, a no ser que estén firmadas por alguien de confianza para el
equipo. Fordo ni siquiera usa vulnerabilidades conocidas o no para
saltarse esta restricción, simplemente confía en que el usuario o bien
use Word 97 o tenga las macros activadas en modo de seguridad "bajo" y
se ejecuten automáticamente. En caso contrario simplemente la macro será
ignorada. De ahí a que su difusión se espere muy discreta. En cualquier
caso el virus, una vez ejecutado, modifica esta opción y marca como
"bajo" el nivel de seguridad de las macros. Con esto puede llegar a
conseguir que otros virus de macro se ejecuten en el futuro.
Por el momento nos ha pasado con una máquina nueva de hace dos meses, es un DELL Vostro 1510 de 32bits.
Esta máquina viene de DELL con el Windows Vista Business.
Al llegarme a mis manos después de que su actual propietario lo dejara libre, lo formatee le instale todos los parches de Vista, los programas necesarios para que el usuario trabaje y una vez entregado al nuevo usuario, este me propone instalarle el Ubuntu 8.0.4, lo cual como sé que este usuario se defiende en Linux y sabe le deje instalarlo él mismo a su nuevo portátil, y lo que paso a sido curioso.
Cuidado si alguien tiene un Windows Vista, ya que al instalar el Ubuntu si se redimensiona la partición donde se ha instalado el Windows Vista, es decir en el mismo disco duro, después de la redimensionar Ubuntu da error y empieza a escanear el disco, si se vuelva a intentar el proceso de instalación, pero sin redimensionar la partición, ya que se ha hecho anteriormente, se instala y perfecto.
Ubuntu funciona, pero la partición de Vista no aparece, aunque se configure y se monte en el arranque lilo o grup, siempre dará error al cargar la partición de Windows.
Pero si se instala Ubuntu sin redimensionar la partición funcionan los dos entornos, o en dos discos separados todo funciona perfectamente.
Así que cuidado si tenemos un vista y queremos instalar Ubuntu en el mismo disco duro.
Lo que no sé si con otras distribucuines de Linux en Vista tiene el mismo efecto, Mandriva, RedHat, Suse, Fedora etc, pore si acaso tenedlo en cuenta.
Se ha dado a conocer una vulnerabilidad en phpMyAdmin 2.x y 3.x que
podría ser aprovechada por un atacante remoto para ejecutar código PHP
arbitrario, pudiendo comprometer el sistema.
PhpMyAdmin es una popular herramienta de administración de MySQL a
través de Internet escrita en PHP. Este software permite crear y
eliminar Bases de Datos, crear, eliminar y alterar tablas, borrar,
editar y añadir campos, administrar privilegios y claves en campos,
exportar datos en varios formatos; y en general ejecutar cualquier
sentencia SQL. Además está disponible en más de 50 idiomas bajo licencia
GPL.
El fallo descubierto, catalogado como serio por el equipo de desarrollo
de phpMyAdmin, está causado porque el valor de entrada pasado al
parámetro "sort_by" en "server_databases.php" no se limpia de forma
adecuada antes de ser utilizado. Esto podría ser aprovechado por un
atacante remoto para inyectar y ejecutar código PHP arbitrario con los
privilegios del servidor web, lo que le permitiría conseguir el control
del sistema vulnerable. Para que el fallo de seguridad pueda ser
explotado, es necesario que el atacante disponga de credenciales de
autenticación válidas.
Se ha comprobado que el problema afecta a las versiones anteriores a la
2.11.9.1 de phpMyAdmin y también a la 3.0.0 RC1. Se recomienda
actualizar a cualquiera de las versiones no vulnerables (2.11.9.1 ó
3.0.0-rc2).
Para todos aquellos que dispongais de estas versiones instaladas, las podeis descargar las nuevas versiones de la web oficial del siguente link.
http://www.phpmyadmin.net/home_page/downloads.php
Se ha descubierto una vulnerabilidad en el componente antivirus de Zone
Alarm Security Suite que podría ser aprovechado por un atacante para
ejecutar código arbitrario o causar una denegación de servicio.
ZoneAlarm es un cortafuegos por software producido por Check Point.
Incluye un sistema de detección de intrusiones entrantes, al igual que
la habilidad de controlar los programas que pueden crear conexiones
salientes. Existe una versión gratuita del cortafuegos y después una
serie de versiones o suites de pago que incluyen características extra.
La Internet Security Suite es su versión más completa y añade un
bloqueador de ventanas emergentes y cookies, Internet Messenger Secure,
antivirus y antispyware entre otras características.
Hace unos días se hizo público un problema de seguridad en el componente
antivirus (multiscan.exe) de esta última suite, causado por un fallo de
comprobación de límites al realizar un escáner en busca de virus sobre
archivos que estén alojados en directorios con un nombre de ruta
demasiado largo. La vulnerabilidad daría lugar a un desbordamiento de
búfer, que podría ser aprovechado por un atacante local o remoto para
causar una denegación de servicio en ZoneAlarm o para ejecutar código
arbitrario en el sistema afectado, si el usuario analiza una carpeta o
archivo con un nombre de ruta demasiado largo.
El argentino Juan Pablo Lopez Yacubian, investigador acreditado por el
descubrimiento de está vulnerabilidad, ha publicado un vídeo a modo de
prueba de concepto en el que se aprecia como un atacante local escala
privilegios, logra ejecutar código arbitrario y compromete por completo
un sistema vulnerable.
Por el momento no existe un parche disponible. La vulnerabilidad ha sido
comprobada para las versiones 7.0.483.000 y 8.0.020.000 de ZoneAlarm
Internet Security Suite y también podría afectar a otras versiones del
producto.
Desde finales del mes pasado, muchos usuarios están detectando un
comportamiento extraño en su portapapeles. A la hora de copiar y pegar
cualquier dato, encuentran que siempre aparece almacenada en este
memoria una misma dirección de Internet, que no recuerdan haber copiado
nunca. Copian algún dato en su "clipboard", y cuando van a pegarlo esa
información ya ha sido modificada y en su lugar se memoriza una URL. No
parecen estar infectados por malware, en cuanto se visita alguna web el
problema reaparece... es solo que su portapapeles ha sido secuestrado.
Según se admite en una nota publicada por el Equipo de Respuesta ante
Incidentes de Seguridad en Productos de Adobe (Adobe Product Security
Incident Response Team) el problema está causado por una funcionalidad
en Flash Player que podría ser aprovechada por un atacante remoto para
"secuestrar" el portapapeles del sistema, forzando a que devuelva
siempre una misma cadena.
El problema se debe a que por medio de la función "setClipboard" de
ActionScript (el lenguaje de programación de Adobe Flash) se puede
modificar (pero no acceder) el contenido del portapapeles. La
descripción se puede leer en la documentación de Adobe Flash citada a
continuación: "El método System.setClipboard() permite a un archivo SWF
reemplazar el contenido del portapapeles con una cadena de caracteres en
texto claro. Esto no supone un riesgo de seguridad. Para proteger contra
los riesgos que supone que contraseñas y otra información sensible sea
cortada o copiada de los portapapeles, el método "getClipboard" de
lectura desde el portapapeles no existe".
Si se crea un archivo SWF modificado que invoque a esta función
repetidamente en bucle, cada cierto tiempo se actualizará el contenido
del portapapeles para forzar que contenga la cadena elegida.
Independientemente de la aplicación con la que se trabaje, siempre que
se intente copiar y pegar algún dato, dará como resultado la misma
cadena una y otra vez mientras el flash esté activo en una web que está
siendo visitada.
El ataque (más molesto que peligroso) se está usando para secuestrar el
portapapeles, pegando una URL que lleva a una página de un falso
antivirus que resulta ser malware. En el caso concreto detectado en los
últimos días, el código ActionScript malicioso venía incrustado en
anuncios flash alojados en sitios legítimos que tienen un gran tráfico
de visitas diarias, como Newsweek, Digg y MSNBC.
Este fallo no es realmente grave. Desde hace muchos años revive de vez
en cuando la polémica (es una funcionalidad vs. es una vulnerabilidad)
con respecto a un problema mucho más serio: El acceso al portapapeles
por parte de funciones de Internet Explorer. Aunque este ataque flash en
concreto es independiente del navegador, aun hoy día la configuración
por defecto de la mayoría de sistemas con Internet Explorer 6 permite de
forma transparente no solo modificar sino tener acceso al portapapeles.
El objeto clipboardData (incorporado en la versión 5 de Internet
Explorer) admite tres métodos para interactuar con los datos del
clipboard, "getData" para capturar la información, "setData" para
escribir, y "clearData" para borrar. Ya en 2005 Hispasec publicó una
prueba de concepto disponible en el apartado de más información.
También este ataque a través de flash recuerda al que se puso de moda
hace años, lo que se dio en llamar "secuestro del navegador" que
consistía en la modificación persistente de la página de inicio de
Internet Explorer. Mucho malware del momento era capaz de secuestrarla
con más o menos destreza. Hoy en día es una práctica en desuso.
Para "liberar" el portapapeles y que vuelva a funcionar de forma normal,
tan solo hace falta cerrar la pestaña del navegador con la que se está
visitando en el sitio web susceptible de contener el flash especialmente
manipulado.
"Como impresionar a las chicas traspasando la protección de memoria con
el navegador". Con ese jocoso título, los investigadores, Alexander
Sotirov y Mark Dowd, mostraron a una expectante audiencia en las
conferencias BlackHat 2008 como traspasar las protecciones de memoria
de Windows Vista y ejecutar a través del navegador cualquier tipo de
contenido.
Pronto, desde algunos medios, se exageró la noticia al extremo de
declarar que la seguridad de Windows Vista estaba rota y lo absurdamente
peor: Que no tenía solución y era mejor abandonar el sistema. El
sensacionalismo había prendido la hoguera de la confusión.
¿La realidad?, que no hay nada nuevo bajo el sol. No se trata de un
exploit que destruya a Windows Vista y tome el control del sistema del
usuario. Lo que Sotirov y Dowd demostraron es que es posible rebasar
las protecciones de Windows Vista para hacer lo que en cualquier otro
sistema es posible: ejecutar código.
Windows Vista implementa una serie de protecciones de seguridad para
evitar o prevenir la ejecución de código arbitrario. La tecnología DEP
(Data Execution Prevention), que permite marcar zonas de memoria no
ejecutables, ya presente en Windows XP SP2 y que se apoya en una
característica en las CPU conocida como bit NX; incluso en aquellas CPU
que no implementen el bit NX, DEP es capaz de ofrecer protección con
funcionalidad reducida. Mientras que con ASLR (Adress Space Layout
Randomization) se proporciona aleatoriedad en las direcciones del
espacio de memoria de un proceso, para dificultar la búsqueda de
direcciones "interesantes" desde el punto de vista del atacante. Además
de estás dos, Windows Vista también se beneficia de las anteriores como
la protección del heap, SafeSEH, etc.
Durante muchos años el anhelo de los diseñadores de sistemas operativos,
en materia de seguridad, ha sido neutralizar la ejecución de código
malicioso. Las características mencionadas anteriormente introducen una
mayor protección pero el ingenio humano carece de límites cuando se le
reta y en este caso Sotirov y Dowd lo han demostrado. Han desmontado una
a una las protecciones y han vuelto a reproducir vulnerabilidades
conocidas.
En palabras de los investigadores, estas protecciones elevan el nivel
de seguridad pero no son definitivas. Factores como la carga de
responsabilidad del navegador y su propia arquitectura con capacidad
para interpretar código, incrustar aplicaciones, imágenes y todo tipo de
aplicaciones de terceros vía plugins hacen que el atacante invierta su
tiempo en encontrar vectores sobre el navegador para llegar al sistema.
Se ha lanzado la versión 9.52 del navegador Opera, que corrige un total
de siete vulnerabilidades, una de ellas de nivel crítico, que podrían
ser aprovechadas por un atacante remoto para perpetrar ataques de
falsificación y cross-site scripting, saltarse restricciones de
seguridad, revelar información sensible, causar una denegación de
servicio o ejecutar código arbitrario en un sistema vulnerable.
Opera, además de ser un navegador web, contiene cliente de correo
electrónico con gestor de contactos, cliente de IRC, lector de noticias
RSS y gestor para la descarga de archivos torrent.
La versión 9.5, con aspecto y características renovadas, fue lanzada a
mitad de junio y recientemente se ha publicado su segunda revisión de
seguridad (a la versión 9.52), después de que la v.9.51, publicada a
principios de julio, solventara tan sólo dos fallos de seguridad.
De las siete vulnerabilidades corregidas recientemente, la primera está
catalogada como extremadamente severa por el equipo de Opera, puesto que
permitiría la ejecución remota de código. A continuación se explican con
detalle todos los problemas solventados:
* Se ha subsanado un fallo de seguridad provocado por un error no
especificado en Opera al funcionar como un manejador para ciertos
protocolos. En este modo, el navegador puede ser llamado por una
aplicación externa, lo que podría ser aprovechado por un atacante
remoto para ejecutar código arbitrario. Esta vulnerabilidad solo
afecta a la versión de Opera para Windows.
* Se ha corregido una vulnerabilidad que consiste en un error en la
manera en que Opera comprueba qué marcos pueden ser modificados en una
página web. Mediante un sitio web malicioso, un atacante remoto podría
cargar contenido modificado en el marco de una página emergente
confiable.
* Se ha corregido un fallo no especificado que podría permitir que un
atacante remoto perpetrase ataques de tipo cross-site scripting,
pudiendo ser explotado para ejecutar código JavaScript o HTML en el
contexto de de la sesión del navegador de un usuario que visita un sitio
web afectado.
* Se ha solventado una vulnerabilidad que consiste en un error al
procesar atajos de teclado personalizados y comandos de menú utilizados
para llamar a aplicaciones externas. En determinados casos, los
parámetros pasados a las aplicaciones no son formateados correctamente
y podrían ser creados desde una zona de memoria no inicializada. Los
valores de dicha zona de memoria podrían ser interpretados de forma
errónea como si fueran parámetros adicionales, lo que, dependiendo de la
aplicación, podría ser aprovechado por un atacante remoto para ejecutar
código arbitrario. Esta vulnerabilidad afecta a las versiones de Opera
para Windows, Linux, FreeBSD y Solaris.
* Se ha corregido otro problema causado por un error al indicar en Opera
información sobre la seguridad de una pagina web. Una página no segura
podría mostrarse como segura si cargase contenido de un sitio seguro
en un frame. Un atacante remoto podría modificar así el estado de no
confiable a confiable del icono que indica la seguridad de una pagina
web, aunque sin mostrar ningún certificado de seguridad.
* Se ha solventado un posible salto de restricciones de seguridad que
podría permitir que un atacante, a través de un script, comprobase la
existencia de determinados archivos en un sistema local, por medio de
intentos de suscripción a los mismos a través de una página web.
* El último fallo está causado por un error al procesar nuevas
peticiones de suscripciones a fuentes (feeds) a través del botón de
suscripción. Un atacante remoto podría aprovecharse de la vulnerabilidad
para modificar el campo de dirección de la barra del navegador, pudiendo
mostrar una URL falsificada.
Las vulnerabilidades están confirmadas para todas las versiones de
Opera, desde la 5.x hasta la 9.x.
video últimamente? Podrías estar infectado.
A finales de Julio hubo bastante revuelo con la aparición de un nuevo
troyano que afectaba a archivos multimedia. Este malware, que muchas
casas antivirus han denominado GetCodec, emplea una técnica de infección
que no había sido vista hasta el momento.
El troyano se ha detectado propagándose encubierto como cracks en
páginas de warez y cracks. Es totalmente silencioso, lo cual induce a
pensar que tan sólo se trata de otro crack corrupto más. Tras su
ejecución, el troyano busca todos aquellos archivos con extensiones
.MP2 .MP3 .WMA .WMV .ASF. El formato ASF es un formato propietario de
Microsoft empleado por Windows Media Player que permite introducir
secuencias ejecutables en flujos de audio/video. El troyano aprovecha
esta propiedad para introducir en los archivos multimedia de la
víctima una secuencia que solicita la descarga de un codec falso desde
un Sitio Web. Éste codec es a su vez otro troyano, aunque la técnica
podría emplearse para servir cualquier tipo de contenido.
Este método de infección también funciona con los archivos MPx porque
el troyano los convierte primero a formato ASF para después
inyectarles el código malicioso. De forma que un archivo con extensión
.MP3 puede estar infectado.
El espécimen modifica la configuración del usuario de tal forma que
este nunca llega a notar que sus archivos multimedia han cambiado, sin
embargo, todo aquel que no esté infectado e intente reproducirlos sí
notará el cambio. Cuando se reproduce un archivo multimedia infectado,
en una máquina limpia, Windows Media Player despliega una ventana
solicitando la descarga de un codec falso. Este codec puede ser
cualquier otro tipo de malware. Al aceptar la descarga se produce la
infección.
Tal y como se puede intuir, estas características lo hacen ideal para
la propagación vía redes P2P, unidades compartidas e intercambio de
medios de almacenamiento. Tomando como ejemplo las redes P2P,
cualquier usuario infectado estará actuando como servidor del malware.
Otro usuario que descargue sus archivos multimedia se verá infectado
si no es lo suficientemente cuidadoso.
Como es conocido el fallo detectado de DNs en él cuál la vulnerabilidad que permitía
falsificar las respuestas DNS, y por tanto redireccionar el tráfico a otros servidores, la resolución de nombres y de
problemas en los servidores DNS, la gravedad se multiplica porque se
supone que los servidores DNS sustentan la red.
..:::: Dan Kaminsky había
descubierto un fallo de base en el protocolo que permitía a cualquiera
falsificar las respuestas de un servidor. No era problema de ningún
fabricante sino de casi todos, un fallo de diseño de un estándar usado
en todo Internet. En un importante esfuerzo de coordinación todos los
grandes fabricantes están publicado sus actualizaciones desde el día
8 de julio.
Pero Dan Kaminsky no daba detalles sobre el asunto. Era demasiado grave
y pensaba que sería irresponsable proporcionar esa información sin dar
suficiente tiempo a todos los administradores para actualizar. Del
parche no se podía deducir el problema puesto que simplemente añadía
aleatoriedad y entropía a ciertos valores que desde hace mucho se sabía
que no eran la mejor solución para asegurar el protocolo. Es por esto
que se apostaba desde un principio por que la vulnerabilidad de Kaminsky
se tratara en realidad de una nueva forma más eficaz de engañar a los
servidores DNS para que den respuestas falsas, gracias a un fallo
inherente del protocolo (y así ha sido).
Kaminsky daría los detalles un mes después, en la conferencia Black Hat
de agosto. Por una parte, el descubridor estaba siendo responsable
(dando tiempo a los administradores) pero tremendamente mediático por
otra (creando una expectación exagerada en torno a la conferencia).
Todo esto, ayudado por la desinformación de los medios generalistas
ha ayudado a que la desconfianza siguiese creciendo. Todos defendían
su teoría: desde el escéptico hasta el que hablaba de la debacle de la
Red. Sólo un grupo de personas concretas conocía los detalles técnicos,
y tenían instrucciones de no revelarlos y de evitar las especulaciones
públicas. Kaminsky pretendía así ingenuamente asegurarse que sólo él
daría los detalles cuando lo tenía planeado, cumpliendo así la segunda
parte de su plan una vez publicadas las actualizaciones. Imposible...
poco después las listas estaban llenas de comentarios y elucubraciones.
Afortunadamente en la seguridad informática siempre hay alguien que
va más allá. Thomas Dullien, el CEO de la compañía Zynamics (también
conocido como Halvar Flake) se aventuró a publicar en su blog su
particular visión de lo que podía ser el problema descubierto por
Kaminsky, sin tener conocimiento previo de los detalles. Y no se
equivocó en su teoría. La insinuación de que estaba en lo cierto vino
desde varios frentes (entre ellos desde un post en Twitter del propio
Kaminsky), pero lo confirmó totalmente una entrada del lunes pasado en
el blog de Thomas Ptacek, director la compañía Matasano que era de los
que conocía los detalles reales. La entrada estaba firmada por un/a tal
"ecopeland" del equipo de Ptacek. Según linkedin.com existe un/a Erin
Ptacek (Copeland), desarrollador/a de software en Matasano (¿familiar
del director?). En el post se daba la razón a Dullien, junto con todo
lujo de detalles sobre el fallo que Dullien había 'redescubierto'. La
explicación fue retirada poco después (actualmente está disponible a
través de la caché de Google). Ptacek se ha disculpado públicamente,
probablemente se dejó llevar por su ánimo de compartir la información.
Demasiado tarde... ya circula libremente por Internet.
Los detalles técnicos pueden ser encontrados en el apartado de más
información. No tardarán en aparecer exploits. Ahora la gravedad del
problema se multiplica. Afortunadamente casi todos los fabricantes han
publicado ya un parche.
Aunque se conocía el problema desde enero, Kaminsky trabajó intensamente
con los grandes fabricantes para mantenerlo en secreto y coordinar la
aparición de parches un día concreto (que tuvo que coincidir con el día
de actualización de Microsoft). Esto resulta extremadamente complicado,
y hay que reconocer que ha debido resultar un trabajo complejo el
coordinar y mantener la discreción sobre un tema tan delicado. Un
esfuerzo elogiable. Sin embargo desde que se anunció la existencia del
problema, sólo se han necesitado dos semanas para que sea desvelado,
frustrando el plan de Kaminsky de aguantar un mes hasta la Black Hat
para revelar los detalles.
Son muchas las moralejas y conclusiones que se pueden extraer de este
incidente. De nuevo el debate sobre la revelación responsable de
vulnerabilidades, la fuerza del ego de muchos investigadores, la
demostración de que un esfuerzo coordinado para una actualización masiva
ante un problema común es posible... pero sobre todo llama la atención
la capacidad de Thomas Dullien de redescubrir un problema que siempre
habría estado ahí, pero que no se había planteado buscar hasta que
alguien apuntó que existía. Dullien contaba con las bases (el protocolo
DNS sufre de problemas inherentes conocidos) sólo había que mover las
piezas para encontrar lo que podía ser el fallo que otro decía ya saber.
Y acertó. Una de las mejores formas de captar el interés de un asunto,
(aunque siempre haya estado ante nuestras narices y creamos conocerlo)
es afirmar que oculta un secreto.
Bienvenido a
House of sysadmins
Registrarse
o Inicia la sesión
Acerca de
Distintivo
Obtener distintivo
¿DESEA PUBLICAR UNA OFERTA DE TRABAJO?
Póngase en contacto con nosotros y le ayudaremos en su búsqueda.
contáctanos
Patrocinadores oficiales
Las mejores partidas, en blog de poker.
RECOMENDADOS
-Administrador de Sistemas
-Seguridad Informática (red social)
-Red de sysadmins (versión en inglés)
Vídeos
10 Cosas que probáblemente no sabías de Mysql
Añadido por Iñaki R.
Windows Vista
Añadido por logadmin
El amigo informático
Añadido por Albert Farré Puche
© 2009 Creado por logadmin en Ning. Crear tu propia red social
Emblemas | Reportar un problema | Privacidad | Términos de servicio