Memoria RAM en Linux; una valiosa fuente de información

La memoria RAM (Random Access Memory) es indispensable para el uso de cualquier tecnología, ya sea para dispositivos pequeños como para super-ordenadores; memoria que es usada todos los días por todo tipo de personas: personas que juegan con el móvil, gente que realiza tareas cotidianas en su ordenador, etc... Lo que muchos no tienen en cuenta es que esta memoria es exactamente eso: Una memoria, valga la redundancia; y como tal almacena mucha información; información que muchos no tienen en cuenta pero que puede resultar muy valiosa y/o peligrosa, dependiendo del caso.

Las pruebas que he realizado han sido sobre sistemas Debian y Ubuntu, pero perfectamente sería aplicable para equipos basados en Red Hat, con un par de modificaciones. Lo primero que necesitamos hacer para leer el contenido de la memoria RAM, es realizar un volcado de ésta en un fichero, para luego leer éste a placer. A lo largo del tiempo han habido diferentes métodos para volcar la memoria RAM, pero el más usado a día de hoy es el uso de LiME (Linux Memory Extractor); principalmente debido a que trabaja a nivel de Kernel y puede usarse para realizar un volcado de la memoria RAM de todo sistema que trabaje con un Kernel Linux, incluidos los móviles Android.

Dependiendo de la distribución que tengamos y de la versión de ésta, podemos vernos obligados por instalar LiME a mano, pero generalmente, las últimas versiones de la mayoría de las distribuciones nos permiten instalar la herramienta desde los repositorios; cosa altamente recomendable, ya que el instalarla a mano nos puede dar problemas debido a que suele requerir de ciertas dependencias externas. Para instalar la herramienta desde los repositorios basados en Debian, junto con una serie de dependencias que son importantes tener instaladas, habría que escribir el siguiente comando:

apt-get install make build-essential lime-forensics-dkms

La instalación es automática y a primera vista, no apreciaremos ningún cambio; es más, no veremos ningún comando que haga referencia a LiME. Esto es debido a que LiMe trabaja como si se tratase de un módulo del Kernel; un módulo que tendría que ser cargado a mano, ya que dicho módulo tiene la función de volcar la memoria, y es un módulo que no funciona de la misma forma que el resto. Aún así vayamos por pasos... ¿Donde se halla dicho módulo? Para no andar volviéndonos locos buscando éste, nuestra mejor opción es recurrir al comando modinfo:

modinfo lime

Gracias a este comando, lograríamos ver la información de dicho módulo, esté o no cargado en el kernel, cosa interesante, ya seas para conocer la ubicación de este módulo como la de cualquier otro. Este módulo en concreto tendría la siguiente ubicación (válida para cualquier Kernel): /lib/modules/$(uname -r)/updates/dkms/lime.ko.

A sabiendas de donde tenemos dicho módulo, tendríamos que cargarlo en el kernel; si bien el método para cargarlo es ligeramente diferente al habitual. La forma para cargar el módulo y, al mismo tiempo, realizar el volcado de la memoria RAM, sería:

insmod /lib/modules/$(uname -r)/updates/dkms/lime.ko "path=/tmp/RAM.lime format=lime"

El proceso tardaría desde unos segundos a varios minutos, dependiendo de la cantidad de RAM a volcar. Es importante tener en cuenta que tras terminar el proceso de volcado, el módulo lime quedaría cargado, pero no estaría continuando volcando memoria; es decir que tras cargar el módulo lime, tendríamos un volcado completo de la RAM.

Si deseasemos optar por un volcado desde un equipo remoto, tendríamos que cargar el módulo de la siguiente forma:

insmod /lib/modules/$(uname -r)/updates/dkms/lime.ko "path=tcp:4444 format=lime"

Para después desde un equipo remoto obtener el volcado de memoria. Imaginemos que hemos realizado el volcado de memoria de esta forma en un equipo con IP: 192.168.1.2; para obtener remotamente dicho volcado, el otro equipo tendría que tener netcat instalado y poder acceder a dicha IP y puerto (4444). Cumpliendo dichos requisitos, desde el otro equipo haríamos:

192.168.1.2 4444 > /tmp/RAM.lime


Como veis la obtención de la información de la memoria RAM no es difícil, si bien obviamente dicho volcado no es "legible"; es decir que no es un volcado en texto plano, sino que requiere de herramientas especiales que tengan la capacidad de leer la información existente en el archivo. Para este punto la mejor alternativa sería recurrir a la herramienta de lectura de volcados de memoria más famosa en Linux: Volatility.

Esta herramienta es famosa por ser Open Source y estar preparada para leer volcados de memoria extraídos tanto de Windows, Linux y Mac; siendo una herramienta de lo más versátil. Dicha utilidad puede ser descargada desde GitHub, pero al igual que con LiME, yo recomiendo que a ser posible se descargue desde los repositorios, ya que te descarga todas las librerías necesarias para ser plenamente operativa; cosa recomendable para evitarnos posibles problemas. La instalación de esta herramienta es muy sencilla, y debe de ir acompañada de otra utilidad que trabaja estrechamente con ésta, llamada dwardump; con lo que para instalar ambas herramientas juntas haríamos:

apt-get install dwarfdump volatility

Ahora bien, con tener esto instalado no basta; ya que Volatility trabaja con perfiles para leer la memoria; con lo que ésta tiene que tener un perfil que sea compatible con el volcado de memoria que se quiere leer. Un perfil sería un archivo, comprimido en formato zip, que contiene tanto la estructura como la información de un kernel, haciendo que Volatility sepa donde y cómo buscar la información en la RAM; sin dicho perfil Volatility no sabría qué buscar ni donde hacerlo. Volatility incluye perfiles Windows por defecto, pero por desgracia no tiene ni un solo perfil de Linux incluido por defecto con lo que tenemos dos opciones:

• Descargarnos un perfil "preconstruido" desde: 

https://github.com/volatilityfoundation/profiles

• Crearnos nuestro propio perfil; cosa que generalmente se recomienda, ya que los perfiles que hay online son genéricos y se han creado bajo una versión de kernel y una CPU que no tiene por qué ser compatible con lo que nosotros tenemos. 

Es importante tener en cuenta que el perfil tiene que ser del mismo "tipo" que del sistema del que hemos extraído el volcado de memoria, ya que en caso contrario volatility será incapaz de leer el volcado de memoria. Por ejemplo si hemos hecho una extracción desde un Fedora; un perfil Debian no sería válido para leerlo.  

En este caso en concreto esa posible incompatibilidad no se va a dar ya que vamos a hacer un perfil propio nosotros mismos y al querer leer una captura de memoria RAM realizada en nuestro propio equipo, la compatibilidad va a ser del 100%.

Para crear el perfil, lo primero que tendremos que hacer será crear un módulo dwarf especialmente diseñado para nuestro sistema. Dicho módulo se encargaría de leer la información del sistema y hacerla legible para la herramienta, y es uno de los componentes del perfil que necesitamos crear para la lectura de la memoria. Para ello haremos lo siguiente:

1. cd /usr/src/volatility-tools/linux/
2. make

En caso de no habernos dado ningún mensaje de error, debería de haber creado dentro de la carpeta /usr/src/volatility-tools/linux, el fichero module.dwarf.

Ahora que tenemos el fichero creado, es hora de crear nuestro perfil, que se trata de un archivo comprimido que contiene el fichero que hemos creado y nuestro System.map. Dicho perfil se almacena dentro de /usr/lib/python2.7/dist-packages/volatility/plugins/overlays/linux (siempre y cuando lo hayamos instalado desde los repositorios) y para crearlo realizaríamos el siguiente comando:

1. zip /usr/lib/python2.7/dist-packages/volatility/plugins/overlays/linux/Perfil.zip \
2. /usr/src/volatility-tools/linux/module.dwarf /boot/System.map-$(uname -r)

Con el fichero comprimido alojado en la ubicación correcta, pasaríamos  a usar Volatility. Lo primero que deberíamos hace sería mirar que, efectivamente,  el perfil está preparado para ser usado. La mejor forma de saberlo sería con el comando de a continuación:

volatility --info |grep Linux

En este caso, veremos un perfil con nombre LinuxDebianx64 en cuya descripción dice claramente el tipo de perfil que es. Si os fijáis bien, el nombre que se ha puesto al perfil no importa (en mi caso he puesto antes como nombre Perfil.zip) ya que lo que le importa a Volatility es el contenido de dicho fichero zip. A sabiendas que tenemos un perfil válido, leeríamos el volcado de memoria, si bien antes de nada hay que tener en cuenta que la sintaxis de Volatility para leer un volcado es la siguiente:

volatility -f fichero.lime --profile nombre_perfil acción

Por ejemplo:

volatility -f /tmp/RAM.lime --profile LinuxDebianx64 linux_bash

Con este comando en concreto lo que haríamos sería obtener el historial de los últimos comandos realizados; una información que a primera vista puede parecer inofensiva, pero que puede ser muy valiosa... Pero no solo podemos obtener el historial; dependiendo de la acción que elijamos podemos obtener datos de lo más curiosos; hay muchísimas acciones pero las más útiles serían:

• linux_pstree: Lista los procesos que estaban corriendo en el sistema cuando se realizó el volcado de la memoria.
• linux_lsmod: Lista los módulos que estaban cargados en el kernel en el momento que se extrajo la memoria.
• linux_netstat: Muy útil; con este se conocen los puertos abiertos en el equipo; una información muy valiosa y al mismo peligrosa.
• linux_arp: Muestra la tabla ARP del equipo del que se ha realizado el volcado... Dicha información puede parecer inofensiva, pero recordad que la tabla ARP muestra la IP y la MAC de los "vecinos" de aquel equipo.
• linux_ifconfig: La RAM también almacena la IP del equipo, con lo que obviamente es una información que puede extraerse de ésta.

Existen muchas más acciones que las que he mencionado, pero estas son mi opinión las más interesantes; ya que ofrecen una información de lo más curiosa... Y valiosa. 

Con este artículo no quiero dar a entender que la memoria RAM sea más o menos vulnerable que otros elementos de un equipo, pero sí que creo que es útil conocer lo valiosa que puede resultar como fuente de información dicha memoria; un factor que muchas veces no se tiene en cuenta.

Espero que os haya resultado útil.

Saludos.

Cómo crear un segundo factor de autenticación en ssh

Tras una semana santa de desconexión tecnológica total, hoy vuelvo con algo muy curioso que estoy seguro que os resultará útil. Más de una vez he comentado que las contraseñas "planas" están destinadas a desaparecer o evolucionar, ya que han demostrado ser altamente inseguras... La mejor opción (en mi opinión) es recurrir a métodos de autenticación basados en claves pública y privadas, como se hace muy a menudo para accesos seguros SSH, pero esa solución es muy técnica y no es cómoda para todos los usuarios, con lo que hoy vengo a hablaros de una alternativa muy popular que es usada también en otras plataformas, tales como el acceso a la cuenta de Google: Se trata de la autenticación en dos pasos, también conocida como segundo factor de autenticación.

La autenticación en dos pasos, no es ni más ni menos que un recurso que tras introducir la clave del usuario, obliga a éste a introducir una segunda clave; clave que únicamente posee un dispositivo móvil y que es completamente aleatoria. Además dicha clave "extra" cambia tras pasar unos segundos, con lo que a menos que se posea el móvil en cuestión y se tenga la clave "habitual" del usuario, es muy complicado tener acceso a la cuenta protegida mediante dicho método. Imaginemos que alguien ha obtenido la contraseña de nuestro usuario... Éste no podría acceder a nuestra cuenta gracias a esta medida extra de seguridad, ya que solamente el dueño del móvil tendría la segunda clave en su poder, lo que hace que esta medida de seguridad sea muy interesante. Aunque hoy centraremos dicha funcionalidad en las conexiones ssh, podemos ver en la actualidad múltiples aplicaciones y/o servicios que contienen dicha medida de seguridad, con lo que en caso de tener la posibilidad de activar el segundo factor de autenticación en alguna cuenta y/o servicio web es muy recomendable hacerlo.

Para lograr el segundo factor de autenticación en conexiones SSH necesitaremos instalar Google Authenticator tanto en nuestro móvil como en el equipo que queremos salvaguardar. Para el primero con tan solo descargarlo del Play Store sería suficiente, pues es una aplicación gratuita que no tiene complicación alguna para instalarla... En cuanto a la instalación del la herramienta en el servidor, al ser una utilidad "poco habitual", no se encuentra dentro de los repositorios oficiales... Pero no pasa nada, ya que podemos obtenerla gracias al conocido git; si bien antes son necesarios instalar algunos paquetes; paquetes que en este caso sí que estarían incluidos en los repositorios. Estos paquetes serían ntp, make, gcc y libpam0g-dev:

apt-get install git ntp make gcc libpam0g-dev

Además de forma opcional podemos instalar qrencode, cosa que (en mi opinión) es bastante recomendable:

apt-get install qrencode

Con los requisitos cumplidos, ahora podemos obtener los paquetes relacionados con Google Authenticator; la URL en la que están alojados los paquetes sería https://github.com/google/google-authenticator, así que la operación para descargar e instalar esta utilidad sería la siguiente:

1. mkdir /usr/src/2FA
2. cd /usr/src/2FA
3. git clone https://github.com/google/google-authenticator
4. cd google-authenticator/libpam
5. make && make install

Con esto la librería que trabaja con Google Authenticator estaría disponible, pero no activada... La librería está relacionada con los módulos PAM (Pluggable Authentication Modules); en concreto con el módulo PAM de ssh, el cual es /etc/pam.d/sshd. Hablar sobre PAM requeriría un post entero, ya que es algo muy completo y complejo, pero se podría decir a groso modo que el módulo PAM, sshd, se encargaría de gestionar las tareas de autenticación relacionadas con las conexiones ssh. En dicho módulo tenemos dos posibilidades:

• Hacer que sea 100% necesario interactuar con el módulo de google en TODAS las conexiones ssh. Esto lo lograríamos ejecutando este comando:

echo 'auth required pam_google_authenticator.so' >> /etc/pam.d/sshd

• Hacer que se ejecute el segundo factor de autenticación únicamente en las cuentas preparadas para ello; es decir en cuentas que soporten dicha funcionalidad debido a que se ha creado una clave secreta que se usa para sincronizarse con el móvil. Generalmente es más recomendable esta opción ya que esto no nos obligaría a crear claves en todas las cuentas con acceso por ssh, sino que solamente aquellas que nosotros queramos.

echo 'auth sufficient pam_google_authenticator.so' >> /etc/pam.d/sshd

Por motivos de compatiblidad con la modificación realizada en este módulo, es necesario también modificar el comportamiento del servicio ssh; en concreto sería necesario modificar el parámetro ChallengeResponseAuthentication. Este parámetro se encontraría dentro del fichero /etc/ssh/sshd_config y su valor por defecto sería "no"; aunque generalmente dicho valor no da problemas, en este caso habría que cambiar su valor a "yes" para que el módulo de google funcione correctamente, con lo que el valor quedaría tal que así:

ChallengeResponseAuthentication yes

Obviamente, para aplicar los cambios realizados en la configuración del servicio ssh habría que reiniciarlo:

/etc/init.d/ssh restart

Ahora únicamente habría que configurar las cuentas en las que queramos aplicar el segundo factor de autenticación; la sintaxis para hacerlo sería:

su - usuario -c /usr/local/bin/googe-authenticator

Por ejemplo para el usuario ivan sería:

su - ivan -c /usr/local/bin/googe-authenticator

Tras responder sí a todas las preguntas que nos vaya lanzando el comando habremos generado lo siguiente:

• Una URL en la que podremos visualizar un código QR legible desde el móvil.
• El mismo código QR en la consola en caso de haber instalado qrencode.
• La clave que tendremos que introducir en el Google authenticator del móvil en caso de no tener lector de códigos QR.
• El código de verificación que irá cambiando cada poco segundos.
• Una lista de claves de emergencia que se pueden usar en caso de haber perdido el móvil.

Supongamos que tenemos la capacidad de leer el código QR, ya sea con la URL o mediante el QR mostrado en la terminal; solo habría que coger el móvil y abrir Google Authenticator; después tan solo habría que seleccionar la opción Seleccionar código de barras y leer el código QR.

Pantalla principal Google Authenticator sin configurar

Configuración de nueva cuenta

Una vez sincronizados el smartphone y el equipo, veremos un código que cambia cada 30 segundos junto con el nombre del equipo con el que nos hemos sincronizado. Ahora si nos logueamos al equipo en cuestión por ssh, veremos que tras introducir la contraseña, nos pedirá un código de verificación; dicho código sería el mostrado en el smartphone:

Con esto ya tendríamos un entorno con un segundo factor de autenticación perfectamente funcional.

Espero que os haya resultado útil.

Saludos.

Ramsomware... esa odiosa moda

Las modas vienen y van. Las vulnerabilidades varían, los viruses mutan y los métodos de los criminales para obtener dinero... TAMBIÉN. Pantallazos azules, phising, estafas online... Los métodos para obtener dinero son cada vez más imaginativos, algunos con mayor éxito que otros dependiendo de la facilidad con la que se puede realizar el ataque, la efectividad, y el número de usuarios que puede abarcar... Desafortunadamente actualmente existe una amenaza que ha ido ganando mucha popularidad los últimos años, popularidad que parecer ir en aumento; hablo por supuesto del famoso ramsomware.

Si observamos bien, las últimas noticias relacionadas con el cybercrimen y los usuarios "de a pie" están relacionados con ramsomware dirigido a equipos de sobremesa y a smartphones; Pero qué significa este concepto? El ramsomware se basa en nada más y nada menos que en cifrar una serie de ficheros y carpetas; obviamente ese cifrado habría sido realizado por un atacante y siempre buscaría cifrar contenido de cierta relevancia; contenido que puede impedir el manejo normal del equipo o incluso contenido de carácter personal.

Generalmente el ramsomware es instalado en el sistema de una de estas dos maneras: Mediante la explotación de una vulnerabilidad del sistema (Como recientemente ha ocurrido con Magento, aunque ya se ha solucionado) o mediante la descarga de un archivo malicioso. Lo más común es que la infección se realice mediante este segundo método, pues los cybercriminales se aprovechan en gran parte de la confianza o el desconocimiento de los usuarios para que éstos se bajen aplicaciones fraudulentas; esto significa que en la mayoría de los casos, los usuarios que se piensan dos veces las cosas antes de descargarse una aplicación "curiosa" suelen estar más a salvo de estos ataques, si bien no impunes...

El motivo principal de que estos ataques se haya propagado tanto es que no requieren elevación de privilegios en el sistema; es decir que no requiere tener que indagar o buscar métodos para adquirir privilegios de root/administrador (dependiendo del sistema operativo en el que trabajemos) y eso evita MUCHOS problemas a los atacantes, pues "únicamente" requieren de un cifrado muy fuerte para poner en jaque en los usuarios.

El objetivo de este post no es enseñar cómo lograr este objetivo, ya que yo estoy totalmente en contra de este tipo de actividades delictivas, sino más bien advertir al lector de que el cifrar una carpeta "relevante" no es tan difícil como parece... Con lo que la mejor medida (que repito que no es infalible, pero que si que previene de más de la mitad de estos ataques) es el navegar por internet con cabeza y el no descargarse archivos desde fuentes no fiables, cosa que desgraciadamente ocurre especialmente en Android.

A modo de ejemplo, vamos a ver como un usuario normal en Linux, sin privilegios especiales ni ningún tipo de herramienta especial puede ponerse la zancadilla a sí mismo cifrando su propio directorio personal... Dicho usuario no requiere tener ninguna herramienta instalada, pues todos los recursos necesarios ya los tiene el propio sistema operativo; recursos que por sí mismos y usados correctamente no hacen nada especialmente raro ni malintencionado, pero que pueden convertirse en herramientas de doble filo, tal y como veréis a continuación; únicamente se requieren de dos herramientas: tar y gpg. Tar es un simple compresor que es usado habitualmente para tratar con cualquier archivo comprimido, mientras que gpg es una herramienta usada para cifrar y descifrar archivos. Ahora veremos cómo con muy pocas líneas podemos hacer que este usuario se moleste a sí mismo; el daño que se haría no sería "fatal", pero sí que sería muy molesto.

Para ello comenzaríamos comprimiendo todos los archivos de la carpeta home y guardándolos en la carpeta /tmp; el formato del archivo comprimido sería tar.gz, y el comando sería algo como esto:

tar -cvzf /tmp/${USER}.tar.gz /home/${USER}

Simplemente hemos comprimido toda la carpeta personal del usuario y la hemos guardado en el directorio /tmp; el proceso de compresión deja el contenido original intacto, con lo que de momento no se ha hecho nada excepcional, ni dañino ¿No es así?

Ahora usaríamos la herramienta de cifrado gpg; herramienta que está instalada por defecto en los sistemas Linux y que puede valernos como perfectamente para hacer una prueba de concepto. Gpg ofrece dos tipos de cifrado; el simétrico que usa la misma clave para cifrar y descifrar y el asimétrico, que requiere de dos claves una pública y una privada... El método asímetrico es el más seguro de los dos, pero para una prueba de concepto como ésta no nos es necesario, con lo que haremos un cifrado sencillo... Para cifrar el archivo comprimido usaríamos el comando:

gpg --symmetric ${USER}.tar.gz

El fichero estaría comprimido y cifrado, con lo que únicamente habría que eliminar todos los archivos originales no cifrados; esto quiere decir que habría que eliminar el contenido de la carpeta home del usuario y también el archivo que recién hemos comprimido. Obviamente, también habría que mover el archivo cifrado a la carpeta home del usuario para dejar todo debidamente en su sitio y evitar que el fichero cifrado se borre accidentalmente; recordemos que el contenido de la carpeta /tmp se elimina automáticamente al reiniciar el equipo.

1. rm -rf /home/${USER}
2. rm /tmp/${USER}.tar.gz
3. mv /tmp/${USER}.tar.gz.gpg /home/${USER}

Al ser todo propiedad del usuario, éste no tiene impedimentos para hacer ninguna de estas tareas. Sin restricciones, sin barreras... El usuario ha sido capaz de cifrar su propia carpeta con herramientas básicas que no tienen otro objetivo que hacer el bien, pero que debido a intenciones malignas han hecho que el usuario no pueda acceder al contenido de su carpeta home... Fotos, vídeos, documentos... Todo ha quedado cifrado... ¿Se ha usado algún comando mágico? ¿Ha requerido un programa elaborado o la explotación de alguna vulnerabilidad? No. Cierto es que el caso expuesto es irreal y que jamás nos encontraremos con un archivo con este tipo de cifrado; además de que en este caso no se ha hecho intrusión alguna sino que simplemente se ha escrito una serie de comandos normales loggeados como el usuario, pero a nivel conceptual es interesante conocerlo, pues nos da una idea aproximada de lo que nos hacen a nuestro equipo al mismo tiempo de que nos hacen ver que no se necesitan privilegios especiales para hacer daño al usuario (aunque obviamente si se adquiriesen dichos privilegios el daño que se podría hacer sería mucho mayor).

¿La solución para prevenir este tipo de eventos? Aparte de no ejecutar programas de fuentes poco fiables, es importante mantener el sistema actualizado y contar con algún antivirus; esto nunca es infalible, pero eso no significa que tengamos que ponerles las cosas fáciles a los malos...

¿Qué hacer si hemos sido victimas de este ataque?

Lamentablemente, si hemos caído presos del ramsomware lo habitual es que el delincuente pida un "rescate" para recuperar nuestros ficheros... En estos casos NUNCA hay que pagar a estos malechores, pues no solo carecemos de garantías de que vayamos a recuperar la información, sino que además el pagar a estos tipos promueve la continuación de este tipo de actividades... El cifrado es muy seguro y muy difícil de romper, con lo que lo mejor en estos casos es cortar por lo sano: Restaurar el sistema mediante con la copia de seguridad más reciente, o (en caso de carecer de ésta) formatear el equipo aún cuando la perdida resulte dolorosa, pues con cosas como éstas es mejor no correr riesgos.

Espero que os haya resultado instructivo.

Saludos.

Android 6 y el administrador de permisos ¡Por fin!

Ayer se hizo oficial el lanzamiento de la nueva versión de Android: El hasta ahora conocido como Android M, por fin se ha anunciado oficialmente como Android 6.0 Marshmallow, lo cual traducido al castellano sería denominado como malvavisco o nube. En un principio parecía que no iba a presentar una gran mejora con respecto a su predecesor más allá de nuevas funcionalidades creadas con el fin de mejorar la experiencia del usuario final, si bien leyendo diferentes artículos he observado dos mejoras que me llaman especialmente la atención: La primera se trata de ni más ni menos que el uso de memorias USB como discos de almacenamiento internos en lo cuales poder instalar aplicaciones de la misma forma en que lo haríamos en una tarjeta micro SD... Una novedad de lo más curiosa que los móviles con poco espacio sin duda aprovecharán para poder expandir su memoria y no tener que sufrir tanto para ahorrar espacio en el disco aunque habría que tener dicho USB siempre conectado para sacarle partido. La segunda opción que es la que realmente me ha llamado la atención ha sido la nueva mejora de seguridad implantada por Android: La administración de permisos.

Dos de los problemas principales de Android que han ido arrastrándose desde hace años son la fragmentación y la seguridad, y si bien con lo primero todavía les queda un largo camino, al menos parece que en lo segundo están intentando mejorarlo todo lo posible. Cualquier aplicación descargada e instalada en nuestro móvil (ya provenga del Play Store o de cualquier otro origen) pedirá una serie de permisos a nuestro móvil; permisos que la mayoría de las personas no se molesta en leer, pero que aún así siguen ahí y en algunos casos son más que innecesarios como ocurrió en su día con la famosa linterna. Juegos que piden permisos para usar la cámara o el micrófono, aplicaciones "fabulosas" que piden tener acceso a prácticamente todo lo posible, etc... Es por ello que en esta versión por fin tendremos la deseada posibilidad de administrar los permisos que queremos otorgar a la aplicación en cuestión desde "Ajustes --> Aplicaciones" y dentro de la aplicación seleccionada veremos una opción denominada "Permisos" en la cual podremos activar o desactivar los permisos.

Fuente imagen: Xakatandroid

Esta funcionalidad en un principio controlaría "solamente" las funciones de: calendario, cámara ,contactos, micrófono, SMS, sensores, teléfono y ubicación; dejando de lado por ejemplo la información personal del teléfono que contempla el modelo de teléfono y la versión de Android (entre otras cosas). Desgraciadamente de momento hay que ser muy cuidadoso con esta utilidad ya que si desactivásemos algún permiso importante que requiera la aplicación para funcionar adecuadamente, ésta dejaría de funcionar hasta que la reactivásemos con lo que habría que ver si en efecto esta utilidad será capaz de aportar realmente a la seguridad o si por lo contrario el hecho de "capar" cualquier permiso nos impedirá utilizar nuestra aplicación. De momento se tendrán que adaptar las aplicaciones a la nueva versión para que en caso de faltarles un permiso vital pidan al usuario la reactivación de éste para poder funcionar, aunque probablemente veamos dichas adaptaciones pronto, especialmente en las aplicaciones más populares tales como Whatsap.

Aún así es innegable que este cambio probablemente marque un antes y un después en la seguridad de nuestro sistema operativo móvil aunque desafortunadamente deja la seguridad en manos del usuario final... ¿Es realmente prudente ésto? Evidentemente yo o aquellos a los que nos guste la tecnología no dudaremos en sacarle provecho a esta opción, ¿Pero que hay de aquellos que simplemente compran un móvil que funcione y en el que puedan instalar Whatsap y juegos que bajan sin molestarse siquiera en comprobar su origen y/o credibilidad? ¿Realmente serán conscientes siquiera de la existencia de esta opción? De momento tengo mis dudas con respecto a este punto, aunque con el tiempo se verá si en efecto esta medida ha supuesto un gran cambio para aquellos usuarios que no tienen nociones sobre tecnología o si en cambio se quedará como una excelente funcionalidad que solamente que cuatro "geeks" conoceremos.

Saludos.

Cómo salvaguardar parcialmente Android de Stagefright

Ayer ya hablé sobre la nueva gran vulnerabilidad de Android: Stagefright; la cual me tiene altamente preocupado; especialmente debido a la incógnita de la recepción del parche... Lo ideal sería que todos publicasen los parches para todos los móviles y versiones de Android, pero más allá de esa utopía: ¿Cuantos fabricantes moverán ficha? ¿Cuantos móviles cubrirán? ¿Cuantos móviles quedarán desamparados y sin protección alguna?

Debido a ello, indagando por Internet encontré una solución que, aunque no es un parche en sí, nos proveerá de cierta protección contra este ataque. Eso no significa que no se deba actualizar el móvil (en caso de tener la posibilidad de hacerlo); pero si eres uno de aquellos que han quedado desamparados, obviamente será muy recomendable aplicar está solución, ya que en caso contrario hay muchas posibilidades de que tu móvil quede infectado, pues lo único que el atacante necesitaría sería nuestro número de móvil.

La solución es bastante sencilla, y se basa en deshabilitar la autorrecuperación de los mensajes; funcionalidad que ejecuta los vídeos recibidos automáticamente sin intervención del usuario. Esto no inhabilita la funcionalidad en sí, sino que evita que los MMS se carguen automáticamente, evitando que el ataque se pueda producir; a menos que obviamente se cargue el MMS en cuestión manualmente. Obviamente no es una solución infalible, pero sí que añade una capa de seguridad considerable a nuestro dispositivo; capa necesaria visto lo "jugoso" que puede resultar dicho ataque.

Para lograr dicha deshabilitación habría que dirigirse a la sección Mensajes --> Ajustes --> Mensajes Multimedia (MMS). Dentro de dicha sección observaríamos diferentes parámetro relacionados con los mensajes multimedia; entre ellos hay una opción llamada Autorecuperar. Esa opción está activada por defecto y hace que el mensaje multimedia se cargue automáticamente, con todo el peligro que ello conlleva. Afortunadamente dicha opción se puede deshabilitar, impidiendo la carga automática del contenido y protegiendo notablemente nuestro equipo.

Obviamente no es una solución infalible, ya que si por ejemplo cargásemos manualmente el mensaje recibido no tendríamos escapatoria, pero al menos la infección de nuestro equipo requeriría la intervención del usuario.

Dicho proceso se vería representado en el siguiente esquema:

Esquema MMS

El problema con esto sería que mucha gente podría cargar el mensaje por accidente; por ello sería necesaria la concienciación de las personas acerca de este problema, pero para empezar... ¿Son las personas conscientes de esta noticia?

Más allá de las páginas dedicadas exclusivamente a la informática y/o tecnología; ¿Habéis leído algún periódico que haya alertado a la gente sobre este problema? ¿Habéis visto las noticias locales advirtiendo sobre este problema? Desafortunadamente he visto pocas noticias al respecto y todas ellas muy poco promulgadas o muy mal posicionadas (esquinas de periódicos online en las cuales se ve la noticia pero no de forma llamativa)... Tal vez le den más relevancia más tarde, no lo sé; pero lo cierto es que la mayoría de los usuarios no técnicos no son conscientes del peligro que corren y de esto gran parte de la culpa es de los medios de comunicación... Tal vez el hecho de que Windows10 vea hoy la luz haya eclipsado esta catástrofe, pero eso no es excusa para que no se molesten en darle relevancia a una catástrofe como ésta.

Os recomiendo probar a preguntar a 5 personas de vuestro circulo cercano que no esté relacionado con el mundo de la informática. Preguntadles acerca de la nueva vulnerabilidad de Android; no de forma técnica, sino de forma coloquial. Algo como: "Te has enterado del nuevo fallo de seguridad de Android?". Probablemente el 99% os conteste con un rotundo no.

Esto ha sido todo por hoy. Espero que el "truco" os haya resultado útil.

Saludos cordiales.