El formato PDF, de nuevo en el punto de mira

Al parecer se ha detectado un paquete de exploits capaz de aprovechar vulnerabilidades en el lector más usado de este formato, Adobe Reader. El "PDF Xploit Pack" permite explotar vulnerabilidades y gestionar de forma centralizada a las víctimas en las que se ha conseguido ejecutar código arbitrario. Muy al estilo del Mpack o cualquier otro producto engendrado por la industria del malware, pero específico para este producto. "PDF Xploit Pack" parece ser el primer paquete de exploits que se encarga exclusivamente de aprovechar y gestionar vulnerabilidades en el lector PDF de Adobe. Es importante tener en cuenta que los fallos pueden aprovecharse no sólo abriendo un fichero PDF que llegue por correo, sino también a través del navegador porque permiten visualizar archivos PDF incrustados en él gracias a un plugin. Los atacantes están consiguiendo (como viene siendo habitual) violar la seguridad de páginas legítimas y esconder ciertos IFRAMEs dentro. Al ser visitadas, se carga un enlace especialmente manipulado que aprovecha las vulnerabilidades. Lo que no se aclara desde la fuente original es si el paquete aprovecha vulnerabilidades conocidas (para las que se pueda estar protegido con las últimas versiones del lector) o desconocidas hasta el momento. El archivo PDF, cuando se abre con el lector vulnerable, descarga otro malware que realmente contiene el payload. Hay que recordar que el formato PDF ya fue usado como "downloader" en febrero de este mismo año, y el ataque resultó bastante "popular". Instalaba el troyano Zonebac. Hace justo un año, se aprovechó también de forma masiva una vulnerabilidad compartida entre Adobe Reader y Windows con Internet Explorer 7. En esta ocasión se usaba el fallo para, a través de una línea de comandos incrustada en el PDF, descargar por FTP y ejecutar código automáticamente al abrir el fichero. También ese mismo año, en junio, se popularizó de forma fulgurante pero efímera el correo basura en formato PDF, inundando los buzones de todo el mundo y eludiendo unos filtros antispam que no estaban preparados. ¿Qué hacer? Aunque el US CERT haya lanzado una alerta, no es necesario modificar los hábitos saludables de navegación. Los lectores de una al día ya saben que no sólo los ejecutables, sino que ningún formato de archivo es confiable hoy en día. El problema está en los lectores que interpretan ese archivo, no en el formato, y todos los lectores (como cualquier programa) pueden contener fallos. También hay que tener en cuenta que la noticia original (de donde se basa la alerta de US CERT) está lanzada desde una empresa que vende productos para precisamente protegerse de estos problemas, con lo que quizás el paquete no se esté difundiendo especialmente "in the wild" en estos momentos. En cualquier caso esto no le resta importancia ni los desacredita en absoluto. Hace tiempo que los atacantes buscan nuevas formas de engañar a los filtros automáticos y a los usuarios. Con formatos históricamente confiables es más sencillo ejecutar código en sus sistemas. Por tanto, la existencia de un pack que permite de forma cómoda explotar y crear una botnet a través de fallos en el lector PDF, resulta atractiva para la industria del malware. Los usuarios, que no suelen parchear su versión de Windows y mucho menos el resto de programas (como Adobe Reader) hacen el resto poniéndoselo muy fácil. Por último, recalcar que los exploits están enfocados hacia Adobe PDF Reader porque es el más popular. Actualizar a la última versión del producto o usar programas menos conocidos como Foxit PDF Reader, puede proteger también en cierta medida a los usuarios.

Múltiples vulnerabilidades en Firefox, Thunderbird y Seamonkey

La Fundación Mozilla ha informado sobre múltiples vulnerabilidades en
varios de sus productos que podrían ser aprovechadas por un atacante
remoto para revelar información sensible, perpetrar ataques de
cross-site scripting, provocar una denegación de servicio, saltarse
restricciones de seguridad o ejecutar código arbitrario en un sistema
vulnerable.

A continuación se detallan las vulnerabilidades publicadas:

1- Desbordamiento de búfer causado por URLs codificadas con UTF-8
especialmente manipuladas. Esto podría ser aprovechado por un atacante
remoto para ejecutar código arbitrario. Afecta a Firefox 2.x y
SeaMonkey.

2- Salto de restricciones de seguridad al no comprobar de forma adecuada
la política de mismo origen en nsXMLDocument::OnChannelRedirect(), lo
que podría ser aprovechado para ejecutar código JavaScript en el
contexto de un sitio web diferente al original. Afecta a Firefox 2.x,
Thunderbird y SeaMonkey.

3- Escalada de privilegios y cross-site scripting causado por múltiples
errores de validación de entrada en feedWriter. Esto podría permitir que
un atacante ejecutase código script arbitrario con los privilegios de
chrome (componente principal de Firefox, no confundir con el navegador
de Google). Afecta sólo a Firefox 2.x.

4- Un error durante el manejo de las pulsaciones del ratón podría
permitir que un atacante moviera el contenido de la ventana mientras el
ratón está siendo pulsado, pudiendo causar que un item fuera arrastrado
en vez de "clickeado". Esto podría ser aprovechado para forzar el
arrastre de ciertos componentes, lo que permitiría, entre otros efectos,
realizar una descarga no solicitada. Afecta a Firefox 2.x, 3.x y
SeaMonkey.

5- Múltiples fallos relacionados con XPCnativeWrapper podrían permitir a
un atacante remoto ejecutar código script arbitrario con los privilegios
de chrome. Afecta a Firefox 2.x, 3.x y SeaMonkey. Podría afectar a
Thunderbird si se habilita la ejecución de JavaScript.

6- Múltiples problemas de estabilidad en los motores de diseño, gráficos
y JavaScript de los productos Mozilla, que podrían ser explotados para
causar una denegación de servicio o incluso ejecutar código arbitrario
aprovechando una posible corrupción de memoria. Afecta a Firefox 2.x,
3.x, SeaMonkey y Thunderbird.

7- Cross-site scripting provocado por la interpretación de forma errónea
de caracteres BOM (Byte-Order Mark, tres caracteres que se encuentran al
principio de un archivo para indicar que está codificado como UTF-8,
UTF-16 o UTF-32. Ejemplo:  ). Afecta a Firefox 2.x, 3.x, SeaMonkey y
Thunderbird.

8- Errores en el protocolo "resource:" que podrían ser aprovechados para
conducir ataques de directorio trasversal y revelar información
sensible. Afecta a Firefox 2.x, 3.x, SeaMonkey y Thunderbird.

9- Un error en el decodificador XBM podría permitir la lectura de
pequeñas porciones aleatorias de memoria, lo que daría lugar a la
revelación de información sensible. Afecta a Firefox 2.x y SeaMonkey.

Se recomienda la actualización de los productos Mozilla a las siguientes
versiones no vulnerables: Firefox 2.0.0.17 ó 3.0.2, Thunderbird 2.0.0.17
y SeaMonkey 1.1.12 tan pronto como estén disponibles desde:
http://www.mozilla.com/

Recordamos que también se pueden descargar de forma automática una vez
que el propio programa nos avise de que hay una actualización pendiente.
Notificación que normalmente llegará entre 24 y 48 horas después de que
la nueva versión esté disponible.

Nueva macroactualización de seguridad para Mac OS X

Apple ha lanzado un nuevo paquete de actualizaciones para su sistema
operativo Mac OS X que solventa un mínimo de 35 problemas de seguridad
que podrían ser aprovechados por un atacante local o remoto para
conducir ataques de falsificación, revelar información sensible,
saltarse restricciones de seguridad, causar denegaciones de servicio o
ejecutar código arbitrario en un sistema vulnerable.

Dentro del paquete Security Update 2008-006, que actualiza a la versión
10.5.5 de Mac OS X se incluyen parches para los siguientes componentes:
ATS, BIND, ClamAV (actualización a la v.0.93.3), Directory Services,
Finder, ImageIO, Kernel, libresolv, Login Window, mDNSResponder,
OpenSSH, QuickDraw Manager, Ruby, SearchKit, System Configuration,
System Preferences, Time Machine, VideoConference y Wiki Server.

A continuación se analizan las distintas vulnerabilidades solventadas en
la última actualización de Mac OS X:

* Desbordamiento de búfer basado en heap en ATS (Apple Type Services)
que podría ser aprovechado para causar una denegación de servicio o
ejecutar código arbitrario.

* Actualización de seguridad de BIND.

* Actualización a ClamAV 0.93.3 que resuelve múltiples vulnerabilidades
encontradas desde el lanzamiento de la versión 0.92.1, última presente
en Mac OS X.

* Revelación de información sensible en Directory Services.

* Posible escalada de privilegios a través de Directory Services si un
administrador usa la herramienta slapconfig para configurar OpenLDAP.

* Fallo en la ventana Get Info de Finder al mostrar los permisos sobre
los archivos.

* Un atacante de la red local podría aprovechar una referencia a puntero
nulo en Finder para causar una denegación de servicio.

* Múltiples problemas de seguridad provocados por fallos en la librería
libTIFF de ImageIO al manejar imágenes especialmente manipuladas, lo que
podría causar una denegación de servicio y permitir la ejecución remota
de código.

* Actualización de seguridad a la versión 1.2.29 de libpng en ImageIO.

* Debido a un fallo en el kernel, un atacante local podría saltarse
restricciones de seguridad y acceder a ciertos archivos sin disponer de
los permisos necesarios.

* mDNSResponder y la librería libresolv son susceptibles de sufrir el
envenenamiento de la caché de DNS.

* Salto de restricciones y escalada de privilegios a través de Login
Window.

* Múltiples vulnerabilidades en OpenSSH.

* Ejecución de código arbitrario o denegación de servicio a través de
QuickDraw Manager.

* Posible denegación de servicio y ejecución de código arbitrario a
través de scripts maliciosos en Ruby.

* Falta de comprobación de límites en SearchKit que podría permitir la
ejecución remota de código arbitrario.

* Un fallo en System Configuration podría permitir que un atacante local
se hiciera con la contraseña PPP.

* Fallo en System Preferences al mostrar el nivel de fortaleza de
ciertas contraseñas.

* Solventado un fallo en System Preferences que podría permitir a
ciertos usuario acceder a archivos remotos a los que no deberían tener
acceso.

* Posible revelación de información sensible al realizar copias de
seguridad con Time Machine.

* Un fallo de corrupción de memoria en VideoConference podría permitir
que un atacante remoto causase una denegación de servicio o ejecutase
código arbitrario.

* Inyección persistente de código JavaScript a través de las listas de
correo en Wiki Server.

Las actualizaciones pueden ser instaladas a través de la funcionalidad
de actualización (Software Update) de Mac OS X o, según versión y
plataforma, descargándolas directamente desde:

Security Update 2008-006 Server (PPC):
http://www.apple.com/support/downloads/securityupdate2008006serverppc.html

Security Update 2008-006 Server (Universal):
http://www.apple.com/support/downloads/securityupdate2008006serveruniversal.html

Security Update 2008-006 (PPC):
http://www.apple.com/support/downloads/securityupdate2008006clientppc.html

Security Update 2008-006 (Intel):
http://www.apple.com/support/downloads/securityupdate2008006clientintel.html

Mac OS X 10.5.5 Combo Update
http://www.apple.com/support/downloads/macosx1055comboupdate.html

Mac OS X 10.5.5 Update
http://www.apple.com/support/downloads/macosx1055update.html

Mac OS X Server 10.5.5
http://www.apple.com/support/downloads/macosxserver1055.html

Mac OS X Server Combo 10.5.5
http://www.apple.com/support/downloads/macosxservercombo1055.html

Mitos y Leyendas: Cifrado EFS en Windows

Además de Bitlocker para Vista, Windows XP y 2000 ofrecen una seguridad
integrada, aceptable y sencilla con respecto al cifrado de la
información. Se llama EFS (Encrypted File System), y es una forma nativa
de Microsoft que hace el trabajo del usuario mucho más cómodo. De hecho,
resulta absolutamente transparente para él. Aunque existen herramientas
públicas que, aparentemente, afirman poder romper el cifrado EFS, puede
suponer una importante barrera para atacantes no expertos.

Cómo funciona

EFS es un sistema de cifrado transparente (que sólo puede usarse bajo
NTFS y no en XP Home) para Windows. Desde las propiedades de archivos o
carpetas, opciones avanzadas, es posible acceder a un menú donde se le
puede indicar al sistema que el directorio o unidad será empleado para
almacenar archivos cifrados (con lo que todo lo que se almacene en él se
cifrará) o se puede indicar también el cifrado de un archivo, cosa poco
recomendable. También es posible utilizar la herramienta de línea de
comando cipher.exe con el mismo efecto.

Una vez marcada una unidad o directorio como cifrado, todo lo que se
almacene en él quedará cifrado (incluso para el administrador del
sistema), pero no lo que ya hubiese dentro. El usuario no tendrá que
preocuparse de nada más. Cada vez que inicie sesión, los datos estarán
ahí para poder ser manipulados, pero una vez cerrada la sesión o si otro
usuario diferente se presenta en el sistema (incluso con otro sistema
operativo leyendo el disco duro) los datos aparecerán inaccesibles. En
el explorer los archivos y carpetas cifrados se colorearán de verde.

Es posible añadir la opción de "cifrar" y "descifrar" en el menú
contextual añadiendo en el registro:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced

una clave DWORD con valor 1 y nombre EncryptionContextMenu

EFS se basa en una mezcla de criptografía simétrica y asimétrica. Crea
certificados digitales para el usuario, que sirven para cifrar y
descifrar en base a claves públicas y privadas. Estos se almacenan
físicamente en tres sitios distintos del sistema.

C:\documents and settings\\application
data\microsoft\crypto\
C:\documents and settings\\application
data\microsoft\protect\
C:\documents and settings\\application
data\microsoft\systemcertificates\

Con esta clave privada, y para agilizar el proceso, cifra a su vez una
contraseña simétrica. En realidad EFS utiliza una contraseña única
generada automáticamente para cada fichero cifrado, pero el usuario no
lo percibe porque su par de claves pública y privada están trabajando
por él. Las contraseñas simétricas automáticas generadas se llaman FEK
(File Encryption key), se genera una cuando se cifra un fichero y se
almacena físicamente con él. Esta FEK es a su vez cifrada con la clave
pública del usuario. Las claves públicas y privadas del usuario se
generan de forma transparente para él la primera vez que cifra un
archivo. Los certificados son accesibles desde certmgr.msc.

Precauciones

En cualquier caso, antes de utilizar EFS, conviene tener claro que por
defecto Windows 2000 utiliza el algoritmo DESx de clave de 56 bits para
cifrar la información. Este algoritmo resulta, a estas alturas,
inseguro, por lo que no se recomienda. En Windows XP a partir del
Service Pack 1, 2003, 2008 y Vista, se utiliza AES de 256 bits por
defecto, estándar bastante seguro. Ya no es necesario activar la
directiva "Codificación de sistema: use algoritmos compatibles FIPS para
codificación, algoritmos hash y firma" en las opciones de seguridad.

Resulta muy conveniente exportar y realizar una copia de seguridad de
estos certificados si se utilizan para cifrar archivos. Estos
certificados están unidos al SID del usuario, de forma que si este
usuario se borra o el sistema se corrompe, los datos se perderán. No
importa si se crea un nuevo usuario con igual nombre... si el
certificado (que va con su SID) no es el mismo, estos no podrán
descifrar la FEK de cada archivo y los datos no podrán ser recuperados.
Además a partir de Windows XP, no existe la figura del "agente de
recuperación de datos" a menos que se le indique. Si se crea, este
usuario podría recuperar la información de otros usuarios con su
certificado.

En cualquier caso, la mejor opción, es exportar y realizar una copia de
seguridad de los certificados (clave privada incluida) y guardarlos en
un lugar seguro. Con estos certificados, aunque el sistema o el usuario
se corrompa, siempre se podrán importar como "agentes de recuperación de
datos" en otro Windows y desde ahí se podrán descifrar los archivos
perdidos..

Hay que tener en cuenta que las carpetas o archivos de sistema no podrán
ser cifradas bajo ninguna circunstancia.

Puntos débiles

EFS es un sistema al que no se le conocen grandes vulnerabilidades. En
entornos no profesionales que requieran de una seguridad media-alta, es
un sistema cómodo y útil. El claro punto débil es que depende totalmente
de la clave del usuario. El usuario se presenta en Windows de forma
normal, y con esto tiene acceso a sus certificados (las claves públicas
y privadas) para hacer uso de EFS, o sea, descifrar la FEK con la que se
almacena el archivo. Por tanto el eslabón más débil es precisamente esa
contraseña habitual de Windows con la que iniciamos la sesión. De nada
sirve cifrar archivos si la contraseña queda accesible por defecto en el
sistema por culpa del LM. Como dijimos, la SAM (Security Account
Manager) almacena dos cifrados por contraseña, LM y NTLM. LM es débil e
inseguro por diseño, y la protección que ofrece es virtualmente inútil.
LM no aprovecha bien los caracteres de las contraseñas y además comete
otra serie de fallos importantes. En Vista y 2008 viene desactivado por
defecto.

EFS se ha calificado en ocasiones de inseguro, cuando en realidad no lo
es. Usa estándares y no se le han encontrado vulnerabilidades graves en
su implementación. Su leyenda viene por depender de la contraseña del
usuario que puede llegar a estar almacenada de forma débil. Si el
usuario lo tiene en cuenta y usa EFS de forma responsable, esto es,
utilizando una contraseña de usuario de más de 15 caracteres o
deshabilitando el hash LM en el sistema, la confidencialidad de sus
datos puede llegar a ser bastante alta.

Para los más expertos o entornos profesionales, el programa libre y
gratuito TrueCrypt es la solución.

Intento de "revival" de los virus de macro

Se está detectando en Europa un tímido intento de 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.

Reflexiones sobre Google Chrome y la seguridad

A principios de septiembre Google lanza (después de muchos rumores) casi
por sorpresa (como suele hacer con todo) su nuevo navegador, conocido
como Chrome. Una semana después, Internet se inunda de comentarios sobre
todos los aspectos de esta nueva aplicación y en particular sobre su
seguridad. Muchos comentarios, exploits, actualizaciones y aclaraciones
después, nos enteramos de que el gobierno alemán ha desaconsejado
explícitamente el uso de este navegador. ¿Por qué?

Se lanza un nuevo navegador, concebido para la Internet de hoy. No es un
programa cualquiera. Genera gran expectación y curiosidad porque es
Google, y todo lo que hace parece hacerlo bien, elegante, sencillo,
robusto y bajo esa filosofía “don't be evil” con la que proyectan una
imagen de cercanía y respeto por el usuario. Si hay que sacrificar la
privacidad, el usuario medio parece sentirse más a gusto si los
servidores son de Google y no de otras compañías. Al fin y al cabo,
somos mayoría los que le confiamos a su buscador todas nuestras
inquietudes varias veces al día.

Además de la sencillez y otras muchas mejoras, de forma breve, las
principales avances técnicos sobre seguridad son:

* Cada pestaña se ejecuta en su propio proceso. Si alguna se cuelga, no
(debería) arrastra(r) a todo el navegador.

* Se ejecuta en una sandbox, de forma que en principio no se podría
acceder al sistema de ficheros real del ordenador a menos que sea
explícitamente ordenado. No está claro qué ocurre con los plugins en
este sentido.

* El modo Incognito (algo que también incorpora Internet Explorer 8 como
InPrivate) en el que el usuario puede navegar sin dejar rastro en su
sistema (básicamente histórico y cookies). Sin embargo sí que se envían
las cookies ya almacenadas si las hubiese por defecto.

En cuanto estuvo disponible para descarga, aparecieron las primeras
vulnerabilidades (y se descubrirán más... lo más grave vendrá cuando de
alguna forma se averigüe cómo saltarse esa sandbox). En principio
denegaciones de servicio básicamente. Una denegación de servicio no es
una vulnerabilidad grave en un navegador. Sí se puede considerar un
fallo de diseño en este caso concreto, puesto que hacer que el navegador
deje de responder por completo en principio contradice la filosofía de
crear cada pestaña en su propio proceso independiente. Por ejemplo,
existen literalmente decenas de formas de hacer que Internet Explorer
deje de responder. Firefox sufrió lo suyo (y aún hoy en día) con los
torpedos de Zalewski, que hacían que el navegador dejase de responder
una y otra vez incluso después de varias actualizaciones intentado
solucionar el problema.

"Es una beta, es normal" se puede argumentar, pero esto depende mucho de
los gustos, y de comulgar con la filosofía de negocio de Google. Hay
quien no es tan condescendiente con fallos en otros navegadores recién
salidos del horno. Google parece abusar de la etiqueta "beta",
manteniéndola más que cualquier otro fabricante en servicios y programas
de uso masivo pero eso nunca ha significado que descuide el producto.
Hay quien por muchos intereses parece retirarla demasiado pronto. Es su
decisión, depende de qué se exija para considerarlo "maduro". Todo
software seguirá teniendo errores y vulnerabilidades en cada ciclo de
producción, independientemente de que se etiquete en un estado u otro.
¿Está listo realmente el navegador? ¿Ser "beta" es una excusa? No hay
respuestas válidas.

La vulnerabilidad "real" vino después. Chrome está basado en Webkit, el
motor de Safari. Esta sí era un problema por dos razones. Primero por
estar heredada de un fallo ya conocido, admitido y corregido en junio
por Apple en Safari. Segundo por lo que permitía: la descarga de
archivos en el escritorio de forma automática (sin preguntar al usuario)
al visitar una web especialmente manipulada. Un atacante podría
descargar muchos archivos automáticamente en el escritorio hasta
"bombardearlo" (carpet bomging). ¿Por qué heredar un fallo ya corregido?
Se descubrieron otras de cierta gravedad. Rishi Narang publicó una
prueba de concepto pública que permitía una denegación de servicio, pero
se intuía la ejecución de código.

Todo se confirma cuando el día 8 se actualiza el navegador y se desvela
que soluciona al menos dos vulnerabilidades que permitían la ejecución
de código. Una a través de nombres largos en el cuadro de diálogo
"Guardar como" y otra relacionada con el manejo de enlaces en la barra
de estado. Sobre el "carpet bombing", se modifica el escritorio como
destino por defecto de archivos descargados. Se dejan sin parchear un
buen número de problemas que atacan directamente a la estabilidad del
programa.

En cuanto a problemas de privacidad, también se ha discutido bastante.
Desde un problema en el diseño de página 404 (en la que sugiere
búsquedas) que permitiría pasar por GET quizás sesiones o contraseñas a
los servidores de Google, hasta el hecho de que, en su política de
privacidad, se hablara claramente de enviar a Google información
tecleada por el usuario. El buscador siempre ha sido el gran recolector
de información en Internet, y nunca lo ha ocultado. En este aspecto
precisamente radica su poder. Gmail ya se curtió en cuestión de
polémicas, cuando pretendieron analizar el contenido de los correos para
ofrecer publicidad más ajustada al perfil del que lo escribía. Google
Toolbar era una extensión para IE sobre la que ya se polemizó en su
momento. Existe Google Calendar, Google Docs, Google Desktop Google
Adsense, las cookies de Google, su lector de RSS, etc... todos son
verdaderos almacenes de hábitos, gustos y datos personales o perfiles
únicos alojados en los servidores de Google. No nos deberíamos
escandalizar ahora por Chrome.

Pero hay quien no opina así. La Oficina Federal para la Seguridad de la
Información alemana advirtió el día 9 que resultaba arriesgado que los
datos de un usuario resultaran acaparados por un único fabricante y
desaconsejó abiertamente el uso del navegador Chrome en un importante
informativo televisado.

Chrome es mucho más que una navegador, y se ajustará perfectamente a
(los antiguos y a) los nuevos servicios que muy posiblemente lance
Google, con lo que ganará cuota en tanto en cuanto existan personas que
quieran disfrutar de todo lo que les ofrece la compañía sin pensar en
que sus datos están alojados en un sistema ajeno. Google pretende llevar
el escritorio cada vez más hacia la web y alejarlo del disco duro local,
y Chrome será la herramienta adecuada para conseguirlo. Quizás vivamos
una guerra de navegadores mucho más entretenida que la de finales de los
90, en la que Microsoft aplastó con malas artes a Netscape en apenas
unos meses.

Se celebra el nuevo Asegúr@IT III en Bilbao

El próximo 25 de septiembre se celebra en Bilbao el evento gratuito
Asegúr@IT III, en la sede de la Universidad de Deusto. Cuenta con la
partición de ponentes de empresas como Panda Security, Microsoft, S21Sec
e Informatica64.

Los ponentes serán Mikel Gastesi, Iñaki Etxeberría, Pablo Garaizar, Juan
Luís Rambla y David Carmona. Tendrá lugar en Bilbao, Universidad de
Deusto. El 25 de septiembre de 2008.

La agenda:

09:00 - 09:15 Registro

09:15 - 10:00 Cracking & protección de software

La disciplina de cracking software tiene mucho que ver con la protección
de software. En esta sesión Mike Gastesi, de S21Sec, contará cuales son
algunas de las técnicas utilizadas para la decompilación y crackeo de
software y al final dará algunas recomendaciones para proteger el
software contra este tipo de técnicas.

10:00 - 10:45 Rootkits in Action

La técnología rootkit llegó ya hace unos años para quedarse con
nosotros. En esta sesión Iñaki Etxeberría, de Panda Security, contará
cómo funcionan hoy en día los rootkits, cuáles son sus objetivos y cómo
podemos protegernos de ellos.

10:45 - 11:15 Café

11:15 - 12:00 Tempest, mitos y realidades

La tecnología Tempest ha dado mucho que hablar. La posibilidad de
interceptar la información generada en un equipo mediante la
intercepción de las ondas radiadas por los dispositivos electrónicos ha
sido utilizada en múltiples novelas y películas de ciencia ficción. No
obstante, las técnicas tempest existen y funcionan con unas
características. En esta sesión Pablo Garaizar, Txipi, de la Universidad
de Deusto mostrará que es mito, que es realidad y hará algún ejemplo de
estas técnicas.

12:00 - 12:45 Network Access Protecction

La protección de las redes en entornos en los que los trabajadores
utilizan dispositivos móviles para conectarse (portátiles, PDA,
teléfonos móviles) necesitan comprobar la salud de los equipos que se
conectan a la red. Windows Server 2008 y Windows Vista incorporan NAP,
una tecnología que permite controlar la salud de los equipos que se
desean conectar a la red. Juan Luís Rambla, MVP de Microsoft en Windows
Security de Informática 64 realizará una demostración de cómo implantar
esta tecnología.

12:45 - 13:30 Protección contra Botnets desplegadas por Web

Las técnicas de expansión de las redes botnets van cambiando día a día
buscando nuevos métodos de infectar máquinas. Actualmente una de las
disciplinas utilizadas consiste en atacar máquinas través de sitios web
legítimos vulnerados mediante fallos de programación. David Carmona,
Evangelista de Microsoft desgranará cómo funcionan estas nuevas formas
de despliegue y dará pautas para protegernos contra ellas.

13:30 - 14:00 Preguntas a los ponentes

El evento es gratuito. Es necesario registrarse desde:
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032382985&Culture=es-ES

Actualización del kernel para Red Hat Enterprise MRG 1.0

Red Hat ha publicado una actualización de el kernel de que corrige
múltiples vulnerabilidades que podrían permitir a un atacante remoto o
local efectuar una denegación de servicio o revelar información sensible
en Red Hat Enterprise MRG 1.0.

* Se ha corregido una vulnerabilidad basada en un desbordamiento de
enteros en SCTP (Stream Control Transmission Protocol). Un atacante
local podría aprovechar esta vulnerabilidad para efectuar un ataque de
denegación de servicio.

* Se ha corregido una vulnerabilidad en Ipsec que podría permitir a un
atacante remoto provocar una denegación de servicio al enviar un paquete
ESP (Encapsulating Security Payload) especialmente manipulado.

* Se ha corregido un error de desbordamiento en el valor "timeout" de la
funcionalidad "hrtimer" del kernel. Esto podría permitir a un atacante
local sin privilegios causar una denegación de servicio.

* Se ha corregido un error de desbordamiento en el valor
"timer-expiration" de la funcionalidad "hrtimer" del kernel en sistemas
de 64 bits. Esto podría permitir a un atacante local sin privilegios
causar una denegación de servicio.

* Se ha corregido un error en la funcionalidad "process-trace" del
kernel para arquitecturas AMD-64. Esto podría permitir a un atacante
local sin privilegios causar una denegación de servicio.

* Se ha corregido una fuga de memoria en la implementación SIT (Simple
Internet Transition) del kernel. Esto podría permitir a un atacante
local sin privilegios causar una denegación de servicio.

* Se ha corregido un error en la llamada al sistema "utimensat" del
kernel que impedía chequear los permisos de archivo cuando "UTIME_NOW" y
"UTIME_OMIT" se usan en ciertas combinaciones. Esto podría permitir a un
atacante local sin privilegios modificar los datos de tiempo en
cualquier fichero y posiblemente causar una denegación de servicio.

* Se ha corregido un fallo en las rutinas de copia de memoria del kernel
para sistemas AMD-64 que al efectuar una copia fallida del espacio de
memoria del kernel hacia otro espacio no pone a cero el espacio destino
permitiendo a un atacante local obtener información sensible.

* Se ha corregido un fallo en la implementación de memoria virtual del
kernel que podría permitir a un atacante local sin privilegios causar
una denegación de servicio a través de múltiples llamadas a la función
"get_user_pages".

Se recomienda actualizar a través de las herramientas automáticas
up2date.