Securizando Android para un uso corporativo (parte 2)

Contribución de Ángel Alonso-Párrizas que continua el post anterior:

En el primer post explicamos como configurar el túnel VPN. Ahora vamos a utilizar ese túnel para gestionar de manera remota el dispositivo mediante SSH. Esto nos permitie deshabilitar el acceso al smartphone por USB y así garantizar que sólo las persona autorizadas dentro de la compañía acceden al mismo. Además, el túnel es de gran utilidad para instalar software de manera remota y controlada, ya que unos de los objectivos del proyecto, como se mencionó en el post anterior, es evitar que se instale software no autorizado.

Configuración de SSH 

En primer lugar, generamos las claves RSA para el servidor VPS mediante el siguiente comando:

test -d $HOME/sshids || mkdir $HOME/sshids && ssh-keygen -t rsa -f $HOME/sshids/idrsa-1

Esto genera un par de ficheros, la clave privada (idrsa-1) y la clave pública (idrsa-1.pub). La clave pública hay que importarla a la tarjeta SD, para a su vez poder incluirlo en el fichero authorized_keys en Android.

En segundo lugar, hay que configurar el servidor SSH en el smarphone, y para ello es necesario ejecutar los siguientes comandos:

adb shell # abrimos una shell

mkdir /data/dropbear # creamos el directorio dropbear

chmod 755 /data/dropbear # cambiamos los permisos

mkdir /data/dropbear/.ssh # creamos el directorio .ssh

chmod 700 /data/dropbear/.ssh # cambiamos los permisos

mv /sdcard/authorized_keys /data/dropbear/.ssh/ # copiamos la clave publica del cliente 

chown root: /data/dropbear/.ssh/authorized_keys # cambiamos el propietario 

chmod 600 /data/dropbear/.ssh/authorized_keys # cambiamos los permisos

dropbearkey -t rsa -f /data/dropbear/dropbear_rsa_host_key # generamos la clave RSA

dropbearkey -t dss -f /data/dropbear/dropbear_dss_host_key # generamos la clave dss 

Con esto ya se tiene configurado el servidor. Ahora, solo hay que lanzarlo para que la autenticación funcione únicamente con claves, en lugar de usuario y password. En el siguiente post veremos como se se ejecuta el servidor ssh de manera automatica al iniciar el dispositivo. 

En una shell en Android ejecutamos el comando dropbear -s -g y a continuación en el VPS usaremos el cliente SSH con el parámetro ¨-i¨ y el fichero con la clave privada, algo del estilo: ssh -p 22 root@172.16.1.99 -i idrsa-1

Un ejemplo del la negociación SSH y del acceso al sistema se puede ver en la captura:

Al estar el SSH corriendo es posible subir cualquier fichero mediante SCP, así pues tenemos total control mediante shell y SCP sobre el sistema.

Deshabilitar la instalación de software y el acceso por USB

Una vez ya tenemos garantizado el acceso al dispositivo hay que restringir el acceso mediante USB. 

Existen varias maneras de instalar software en Android y una de ellas es mediante el acceso por USB. 

Hay dos binarios fundamentales en Android que son los que dan soporte a estas funcionalidades:

• /sbin/adbd es el daemon que gestiona el acceso mediante shell 
• /system/bin/pm es el binario que gestiona la instalación de paquetes

Si quitamos los permisos a estos binario, el acceso por USB/shell no funcionara y además no sera posible instalar software mediante la shell. Más adelante explicaremos como deshabilitar las aplicaciones como el Market, que sirven para instalar aplicaciones por red.  

Este proceso se hace de manera automatica mediante un script que publicaremos en el próximo post.

Un punto importante a destacar es que si queremos instalar algo de manera controlada el administrador de seguridad puede restablecer los permisos del binario /system/bin/pm  (por SSH) e instalar cualquier fichero 'apk' subido por SCP. De esta manera tenemos la posibilidad de instalar nuevas versiones del software o nuevo software.

Deshabilitar bluetooth 

En este proyecto consideré que el bluetooth no era necesario en un entorno corporativo. Puede estar justificado su funcionamiento en algunos casos (por ejemplo algún responsable que necesite hablar por bluetooth mientras conduce) pero a priori el bluetooth no debe poder usarse.

Análogamente a como se deshabilitó la instalación del software, haremos lo mismo con los dispositivos de blueetooth: 

/dev # ls -l /dev/* | grep blue

crw-rw---- 1 bluetoot bluetoot 249, 0 Jun 29 19:48 /dev/ttyHS0

crw-rw---- 1 bluetoot bluetoot 250, 0 Jun 29 19:48 /dev/ttyMSM0

crw-rw---- 1 system bluetoot 10, 223 Jun 29 19:48 /dev/uinput

srw-rw---- 1 bluetoot bluetoot 0 Jun 29 19:49 dbus

Así, si revocamos los permisos a /dev/ttyHS0 y /dev/ttyMSM0 bluetooth no funcionara como podemos ver en los logs:

V/NotificationService( 164): Active profile: Default

I/PROFILE ( 164): Group: Gmail containing : com.android.server.vpn : false

I/PROFILE ( 164): Group: Phone containing : com.android.server.vpn : false

I/PROFILE ( 164): Group: Calendar containing : com.android.server.vpn : false

I/PROFILE ( 164): Group: Email containing : com.android.server.vpn : false

I/PROFILE ( 164): Group: SMS containing : com.android.server.vpn : false

V/ProfileManager( 164): No active group, returning default: Other

V/NotificationService( 164): Pkg: com.android.server.vpn group: Other

E/bluedroid( 164): bt_enable: Timeout waiting for HCI device to come up

D/BluetoothService( 164): Bluetooth state 11 -> 10

V/BluetoothEventRedirector( 791): Received android.bluetooth.adapter.action.STATE_CHANGED

D/SettingsAppWidgetProvider( 791): Widget is from a previous version... Let's update

D/SettingsAppWidgetProvider( 791): No instances yet... Wait for at least one instance to exist before adding global set

tings

Deshabilitar la tarjeta SD

Conectar un dispositivo externo, como un pendrive, a un sistema seguro puede ser peligroso y las políticas corporativas deben de limitar estas situaciones. En el caso de Android, tenemos varios problemas con la tarjeta SD:

•  La ausencia de cifrado de datos
•  El modelo de permisos. Al ser FAT, una aplicación con permisos de lectura/escritura tiene acceso a toda la tarjeta independientemente de los permisos de las aplicaciones dueñas de los datos.
• Algunas vulnerabilidades que aprovechan la SD com la descubierta por el colega Mario Ballano.

Por estas razones la tarjeta hay que deshabilitarla desmontándola con 'umount' en tiempo de booting.

(Continuará..)