Así que gafas y relojes inteligentes, ¿eh?

Mucho se ha hablado sobre la reciente salida de dispositivos wearables, vamos, que puedes vestirte con ellos. Que si controles de frecuencia cardíaca, sincronización con otros dispositivos, unas gafas que te permiten hacer muchas cosas…

Permitid que me ponga en un tono más “conspiranoico”. Quiero expresar una serie de pensamientos que rondan por mi cabeza…

En primer lugar, las gafas inteligentes… véase las Google Glass. Según he estado leyendo por ahí, mucha gente aprueba esta tecnología ya que permitiría, por ejemplo, leer documentos para personas invidentes. Permitirá, mediante las correspondientes aplicaciones, salvar vidas, fotografías mediante un pestañeo… ahá.

En segundo lugar, tenemos el Smart Watch, un wearable que se pone en la muñeca cual reloj. Este, a diferencia de las gafas, no permite realizar fotografías (o al menos hasta ahora los modelos que he encontrado…). Sin embargo, sí lleva un micrófono. Sí, un micrófono que permite enviar comandos de voz, dictar mensajes, etc.

Toda esta tecnología moderna parece, y será, muy cómoda de utilizar y nos facilitará bastante la vida. Pero ¿a qué precio?

Ya hemos hablado del peligro de utilizar los Smartphones, pues es muy sencillo utilizarlo como mecanismo de espionaje. ¿Qué ocurrirá con las gafas y relojes inteligentes?

Existen ya noticias como que en el Reino Unido se ha prohibido el uso de las Google Glass en salas de cine. Pero, ¿hasta dónde llegarán estas prohibiciones? Es un tema que se ha tocado bastante; la privacidad.

Más allá de las posibles fotos que nos puedan hacer sin enterarnos, ahora con los relojes hay un micrófono disponible. Un micrófono que no tiene la limitación que tiene el Smartphone ya que NO está escondido en un bolsillo y es más discreto.

¿Veremos esta tecnología en malas manos? ¿Nos espiarán de una forma más eficaz?

Descubriendo vulnerabilidades tradicionales en sistemas ICS

Recordarán que en un post anterior, titulado La odisea de (intentar) hacer las cosas bien…, les daba los detalles del tortuoso camino que he tenido que atravesar desde el descubrimiento de una vulnerabilidad hasta su publicación. Dado que la vulnerabilidad ya es pública (véase Advisory (ICSA-14-203-01), Omron NS Series HMI Vulnerabilities), es el momento de hablarles de ella. Aunque lo cierto es que la publicación de esta entrada, tras unos 10 meses de espera, estaba ya previamente planificada.

Las vulnerabilidades que les comento fueron encontradas en el NS15 versión 3.19 (aunque desconozco si otras versiones están afectadas), un HMI de la marca OMRON.

La primera de ellas es un XSS persistente que permitiría inyectar código malicioso a través del formulario de configuración, concretamente en el parámetro “Page Title”, que se encarga de modificar el título de las páginas web del sistema. No obstante, para aprovecharse de ella, el atacante deberá estar autenticado en el sistema. Sin embargo…

Cuando el sistema almacena todas las opciones y sus valores, se puede comprobar como los valores introducidos en el formulario de configuración se transmiten mediante método “GET”, apareciendo todos los parámetros en la barra de navegación. Como no existe ningún parámetro que haga de token, un atacante podría aprovechar esta vulnerabilidad de tipo CSRF y crear una URL que permitiese cambiar la configuración del sistema HMI.

Aunque en un primer lugar ambas vulnerabilidades pueden parecer más bien simples e incluso irrelevantes, de explotarse en un sistema crítico los resultados podrían ser devastadores.

Imaginemos que un atacante decide realizar un ataque dirigido contra el operario que se encarga de controlar el sistema HMI. Para ello, el atacante le enviará un enlace que, aprovechándose del CSRF, inyecte un payload que aproveche la vulnerabilidad XSS. En este caso, la finalidad del payload será la de suplantar la página web de control por otra.

De este modo el atacante podría conseguir que el operario modificase el estado del sistema a partir de una información falsa (escogida por el atacante para sus propios propósitos). En otro escenario, si el atacante consiguiese atacar con éxito el sistema, el ataque resultaría invisible para el operador, a cuyos ojos todo estaría en perfecto estado. Algo, que si no recuerdo mal, también realizaba Stuxnet en su día.

Cómo secuestrar la identidad digital de una persona (III)

Seguimos con la sangría, después de suplantar su identidad en Gmail, en Facebook y en Spotify, en las dos entradas anteriores de esta serie.

Ahora vamos ahora a por su operador móvil, en este punto, el proceso de recuperación de contraseña es todavía más fácil, ya que nos va a remitir la compañía ¡un SMS gratuito! (¡bien! por lo menos no le cobraran al pobre chaval), mediante el cual se podrá acceder a la parte de gestión de la cuenta.

Y… ¿qué se puede hacer en la parte de clientes…? No me va hacer falta ni escribirlo ahí lo tienen:

De este servicio nos puede interesar la obtención de su DNI, para hacer posibles logins en otras Webs o incluso sustraer parte de su número de cuenta bancaría.

¿Cómo obtenemos su cuenta bancaria completa? Pues accediendo simplemente a un par de servicios donde venga recogida. Lo de un par es porque normalmente esa información va enmascarada en parte con una serie de ****, pero lo bueno es que cada proveedor (página) tapa una parte, aquí tenéis un ejemplo de Pepephone.

No voy a comentar ni siquiera el peligro que tiene hacerse con la cuanta de Amazon… pero ahí va lo que necesitas para “recuperar/secuestrar” una cuenta…

Por último porque esto puede ser un no parar, vamos a por los servicios de la administración pública 060.es, esto es lo necesario para poder recuperar la contraseña del usuario:

Seguramente que a nuestros lectores, llegado a este punto, se le ocurren mil sitios/servicios más que se pueden suplantar o secuestrar, pudiendo hacer mucho daño a una simple persona que tan solo había ido al cine a ver su película favorita.

Recordar también, la importancia de establecer un código o patrón de acceso al terminal y proceder a su borrado remoto en caso de pérdida.

Cómo secuestrar la identidad digital de una persona (II)

Siguiendo desde donde nos quedamos con la anterior entrada: Cómo secuestrar la identidad digital de una persona (I).

¿Y qué tal si para probar compramos un Nexus 5? Tras hacer login en la web de Google Wallet y añadir una nueva dirección de envío (la mía claro), procedemos a hacer la compra:

Ya tengo un segundo móvil nuevo, pero continuemos para bingo, lo siguiente que haríamos es secuestrarle las cuentas de sus redes sociales, por ejemplo vamos a probar con Facebook, siendo aplicable al resto de ellas (LinkedIn, Twitter…).

Aquí podemos hacer 2 cosas para obtener el usuario de Facebook, o bien mirarlo en la propia aplicación del móvil sustraído o utilizar un pequeño truco en la página web de esta red social. El truco consiste en dado un correo electrónico obtener su usuario asociado, utilizando para ello el formulario de “¿Has olvidado tu contraseña?”

Como ejemplo he utilizado un correo electrónico totalmente aleatorio peter12@gmail.com el cual dada la gran cantidad de usuarios que Facebook posee existe como perfil. Animo al lector cuando se aburra a introducir algunos de forma aleatoria, suele ser interesante ver las fotos y nombres que la gente se pone.

En nuestro caso no hubiéramos puesto el correo de “peter12” sino la cuenta de Gmail obtenida del teléfono. Como pueden ver en la imagen anterior, en la segunda opción nos invita a enviarnos un enlace de cambio de contraseña a nuestra cuenta de correo previamente secuestrada. Magnífico ya tenemos su Facebook, nuevamente ¿qué podemos hacer con una cuenta de Facebook…? Pues en primer lugar tocarle el bolsillo por ejemplo comprando en su nombre servicios de esta red (siempre que tuviera claro, la tarjeta de crédito previamente introducida).

Continuamos para Bingo… ¿Qué más se puede hacer con una cuenta de Facebook?, pues como esto de la autenticación con una única cuenta está de moda y gracias a esta red social es posible hacer login con sus credenciales en numerosas Webs, vamos por ejemplo a secuestrarle su cuenta de Spotify. Destacar que podríamos hacernos con cualquier servicio que utilice Facebook como validador.

Pero no todo queda aquí, ¿y si vamos ahora a por su operador móvil?

Más información en la próxima entrada.

Cómo secuestrar la identidad digital de una persona (I)

Hoy les vamos a mostrar el impacto que tiene perder su terminal móvil Android y no disponer de un código de seguridad o patrón de bloqueo robustos. Como se pueden imaginar por el título del post, la consecuencia va a ser el secuestro o suplantación de la identidad digital de la persona afectada. Comencemos…

Supongamos que soy una persona terriblemente malévola y que me he encontrado un teléfono Samsung Galaxy S4 en una butaca a la salida del cine. Este smartphone no dispone de bloqueo, por lo que a priori, lo primero que se me ocurre es que puedo llamar a mi novia en USA sin pagar ni un céntimo. Pues bien, esto es de lo mejor que le podría pasar a la pobre persona que ha perdido una parte de su cuerpo. Digo esto porque hoy en día nuestra vida completa la llevamos en el bolsillo convirtiéndose en una parte más de nuestro organismo, creando una necesidad que roza lo absurdo (conozco gente que duerme abrazada a su teléfono).

Lo siguiente que se me ocurre que se podría hacer es robar la cuenta de Gmail/Google de la siguiente manera:

    1. Obtengo la dirección de correo electrónico asociada en el terminal móvil, simplemente abriendo la aplicación de Gmail.

    2. Lanzamos los formularios de recuperación de contraseña a través de un navegador web en un ordenador. Haciendo click en ¿Necesitas ayuda? y posteriormente en “he olvidado mi contraseña”, le introducimos el correo electrónico que hemos obtenido en el paso 1.

    3. El asistente nos pregunta si recordamos alguna contraseña anterior, por lo que le diremos que “No lo sé”.

    4. A continuación Google nos deja elegir entre enviarnos a otra cuenta de correo electrónico el proceso de recuperación o… continuar a través del teléfono móvil asociado a la cuenta. Pincharemos en esta última.

    5. En este punto en nuestro ordenador aparece un aviso indicando que debemos autorizar a través del móvil, el cambio de contraseña. Siendo esta solicitud válida durante 10 minutos.

    6. Al instante en el terminal sustraído aparecen una serie de mensajes como los siguientes:

    7. Tras simplemente darle a “Permitir” podemos establecer la contraseña que nosotros queramos en el ordenador,obteniendo el control total de la cuenta de Google.

¿Pero que podemos hacer con una cuenta de Google? Por el momento acceder a todos los servicios asociados: Google+, GoogleDocs, Gmail, etc. Pero quizá uno de los más interesantes para un atacante pueda ser el Google Wallet, el cual te permite comprar productos, como: teléfonos móviles, tabletas, música o aplicaciones entre otros.

¿Interesante?

Seguiremos desde este punto en la próxima entrada.

Fundamentos sobre Certificados Digitales – Guía de uso seguro de Certificados Digitales

Recientemente, el Centro de Seguridad TIC de la Comunidad Valenciana (CSIRT-cv), ha publicado una “Guía de uso seguro de Certificados Digitales”, esta guía vino precedida por una campaña de concienciación emitida en redes sociales. Formada por una serie de consejos de seguridad diarios, relacionados con el uso de certificados digitales. A este respecto, y dado que esta serie de entradas en Security Art Work dedicada a Fundamentos de Certificados Digitales está perfectamente alineada con los temas tratados en la guía, he considerado introducir la guía dentro de la misma serie.

Es importante destacar que, quizás un poco como contrapunto a los temas tratados en cada una de las entradas precedentes de la serie, la guía tiene una audiencia con menos orientación técnica que la que abarcan el resto de entradas, más cargadas de contenido técnico más enfocado a profesionales de TI y entendidos en la materia. Sin embargo, esto no debe desmotivar a este colectivo más avanzado, ya que posiblemente se tengan ciertos conocimientos sobre el uso de certificados digitales, aunque posiblemente no en todos los ámbitos tratados en la guía. Dicho lo propio, pasamos a la presentación de la misma.

El objetivo principal de la guía es informar y concienciar respecto del uso seguro de certificados digitales en la vida cotidiana, y su audiencia objetivo son el conjunto de los ciudadanos y empleados públicos. Dentro de ella, se facilitan conocimientos básicos de uso de certificados en las principales aplicaciones de uso habitual que tengan requerimientos específicos respecto a privacidad de la información, así como que requieran asegurar la autenticidad del remitente o tercero con el que contactamos. Todo ello tratando de ser lo más sencillo posible en las explicaciones, orientadas a su público objetivo. Destacar además que está estructurada como una guía de referencia, facilitando el acceso a los contenidos que se requieran en cada situación de forma sencilla y clara.

A modo de resumen de contenido, la guía da soluciones y recomendaciones específicas respecto a los siguientes puntos principales:

  • El DNI Electrónico: Hace unos años se produjo una modernización profunda del Documento Nacional de Identidad Español, desde entonces se ha convertido en el certificado digital obligatorio del que disponemos todos los Españoles, y que la gran mayoría desconoce.
  • Certificados de Persona Física o Empleado Público: Se trata de certificados digitales identificativos de propósito general y son emitidos por Autoridades de Certificación de confianza. Permiten identificar a su propietario telemáticamente, así como cifrar comunicaciones digitales.
  • Uso de Certificados Digitales en correo electrónico: Se incluye un dedicado al correo electrónico, el medio de comunicación de uso más difundido en Internet. Del mismo modo que cualquier medio de comunicación digital que transmite datos por redes públicas requiere que se tengan en cuenta los requisitos de seguridad pertinentes; y como suele ser habitual, centrados en la confidencialidad de la información compartida, así como la autenticidad de la misma.
  • Navegación Segura: Del mismo modo que se puede emitir un certificado digital para una persona se puede emitir un certificado para un sitio web. En este caso, el certificado garantiza identificar inequívocamente al sitio web al que nos conectamos y a su vez implementa cifrado en todas las comunicaciones entre cliente y servidor. Por tanto, se debe verificar sin lugar a la calidad y fiabilidad del certificado cuando conectamos a un sitio web que por ejemplo, maneje información sensible.
  • Firma de código: Esta capacidad permite firmar código fuente de las aplicaciones que vamos a instalar en nuestros equipos. Cuando un código no está firmado o no está firmado por una entidad de confianza corremos el riesgo de que se haya modificado fraudulentamente, y muy posiblemente pueda ejecutar acciones maliciosas en nuestros ordenadores. Cada vez que instalemos un programa deberíamos asegurar su origen, integridad y su legitimidad.
  • Firma de documentos digitales: Cuando se firma un documento digital, dicha firma tiene la misma validez que una firma manuscrita; además asegura que el documento firmado no ha sido alterado o modificado. Del mismo modo, es fundamental poder identificar la legitimidad de la firma implementada en cualquier documento.

Por último, se incluye información adicional sobre la solicitud y gestión de certificados con la Agencia de Tecnología y Certificación Electrónica de la Comunidad Valenciana (ACCV), que es una Autoridad de Certificación de reconocida confianza y opera dentro de la Comunidad Valenciana, facilitando certificados digitales reconocidos gratuitos para los ciudadanos.

Como conclusión y en mi humilde opinión, me gustaría hacer un pequeño análisis de la situación actual respecto al uso de esta tecnología. En muchas ocasiones me gusta emplear la frase “Los certificados digitales, esos grandes desconocidos…”, y esa es por desgracia la realidad, y es que la mayoría de los usuarios de medios tecnológicos e internet los usan en su vida diaria, aunque no sean conscientes. Los certificados digitales están cada día más extendidos en los servicios TI; empleándose comúnmente para asegurar la confidencialidad, autenticidad y trazabilidad de la información en la red.

Los certificados son un mecanismo muy potente y muy seguro; pero como suele pasar en la gran mayoría de los casos, por seguro que sea, si se hace un uso negligente de los mismos pueden conllevar muchos más riesgos que beneficios. No seamos alarmistas, el objetivo de la guía no es ni mucho menos asustar a la audiencia, sino ayudar a poder emplear estos mecanismos de forma segura y para ello la mejor base es conocer los riesgos a los que nos enfrentamos, pero siempre desde una óptica de confianza. De ese modo los certificados nos podrán ayudar a aprovechar todas las ventajas y servicios que nos ofrece la sociedad de la información en la actualidad con total seguridad.

La “Guía de uso seguro de Certificados Digitales” se encuentra disponible en este enlace, dentro del portal Web de CSIRT-cv, y también desde la sección de descargas de dicho portal.

Personalmente, como siempre agradecido por vuestra atención y recordaros que estamos a vuestra disposición desde Security Art Work.

Un saludo a todos. Os deseo un feliz y seguro verano.

PFsense: firewall perimetral (II)

En esta segunda parte se explican las configuraciones previas a la utilización del firewall.

Recordemos el artículo anterior, donde las configuraciones de las interfaces quedaban de este modo:

Pues ahora hay que cambiar la interfaz de red del Anfitrión (máquina real no virtualizada), para que se pueda acceder vía web a pfsense. En este caso podemos acceder desde una dirección IP perteneciente a la red interna (192.168.1.0/24), quedando así la configuración de la interfaz del anfitrión:

Para acceder solo debemos poner en el navegador http://192.168.1.2 e introducir las credenciales por defecto. Usuario “admin” y Password “pfsense”.

Nos aparecerá una ventana como esta:

La primera vez que se entra, se accede a un “Wizard”, es decir a una configuración paso a paso:

La primera parte es donde se configuran las direcciones de los Servidores DNS, el nombre de la máquina y el nombre del dominio, en este caso se configura con las DNS de Google.

El dominio llamado en este caso “mired”, facilita mucho las cosas a la hora de acceder a un equipo, ya que podemos comunicarnos por ejemplo con un equipo llamado “oficina”, poniendo únicamente oficina.mired, o en este caso para acceder a pfsense en lugar de poner http://192.1681.2 se puede poner http://pfsense.mired.

En esta misma página de configuración existen otras opciones que en este caso no nos hacen falta como es la configuración PPOE. En el caso de que queramos conectar un router en modo “bridge”, es decir que tenga NAT deshabilitado y todo el tráfico vaya directo hacia el firewall pfsense, pero este no es el caso.

Por último la sincronización de la hora y fecha del equipo se hace a través de un servidor ntp, podemos elegir la zona horaria, en este caso la de Madrid:

Seguidamente, una vez que procedemos a dar “next” se pasa a la configuración de las interfaces previamente seleccionadas antes en la configuración.

La primera interfaz (WAN), la interfaz que se conecta a internet (vinculada a la interfaz wlan0 del anfitrión), está configurada por DHCP, siempre se podrá configurar de forma estática, simplemente deberá coincidir con el rango de esta red (192.168.0.0/24).

En la configuración general es importante incluir la dirección MAC de la interfaz WAN, es decir en este caso la MAC de wlan0. Si pfsense estuviera conectado a un router, deberíamos poner la MAC de la boca de red a la que está conectada el router, para evitar posibles ataques de tipo “spoofing”.

En la parte de abajo aparece una opción llamada “Block logonnetworks”, si esta opción está activada, se bloquearán redes a través de la interfaz WAN que sean de tipo privado, es decir, no dejará que una dirección IP de fuera del tipo 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, y 169.254.0.0/16, entre a través de WAN.

Configuración de la red interna:

El último paso es cambiar la clave de acceso web, algo muy recomendable.

Al terminar la configuración, pfsense muestra una “Dashboard”, donde se muestra un resumen de la configuración, de la carga de CPU y memoria utilizada y el estado de las interfaces de red.

En el siguiente artículo se profundizará más en la configuración avanzada de pfsense.

Cuando los clientes son sus propios enemigos

Algunas veces por desconocimiento. Otras por simplicidad. Algunas otras por hacer las cosas rápidamente, pero la mayoría por desconfianza, nos ponemos trabas a nosotros mismos en lo que respecta a la seguridad informática. Y es que lo que para un experto en seguridad puede ser complicado de diseñar y configurar, se hace un mundo para el cliente final.

Para mí hay dos conceptos a tratar en cada situación a estudiar, de hecho, casi es extrapolable a cualquier entorno informático: comunicaciones, sistemas, desarrollo… Una es la relación con el cliente, y otro la situación en la que se encuentra el mismo.

En lo referente a la situación en la que se encuentra, casi nunca trabajamos en el entorno ideal. No disponemos muchas veces de tiempo, de capacidad de reacción, de ventana de disponibilidad para trastear, o incluso de una maqueta de pruebas previa a la intervención. De hecho, casi nunca se tiene toda la información necesaria para poder trabajar, e incluso tenemos que buscar por nuestra cuenta casi todo lo que necesitemos para poder empezar. En este campo poco podemos hacer, es un trabajo de concienciación a todos los niveles, que aunque parece que se va cambiando poco a poco, no depende enteramente de nosotros, pues requiere de un esfuerzo adicional que poca gente está dispuesta a hacer.

Pero lo que respecta al trato con el cliente, podemos hacer más de lo que creemos. Somos capaces de pasar horas auditando, valorando cada situación, estudiando las diferentes posibilidades y buscando una solución final adecuada, pero no de pensar ni 5 minutos en cómo se lo vamos a presentar al cliente. Es casi tan importante saber hacer entender lo que tratamos de conseguir, como el mero hecho de desarrollarlo.

Debemos saber entender lo que realmente se necesita en cada momento, valorando la seguridad para el propio cliente, como el uso que vaya tener en el día a día. Hemos de situarnos en su posición, y desarrollar una solución que entienda, y sea factible a su modo de ver. Que no le complique su trabajo día a día, pero que cumpla con la seguridad necesaria. Quizá de nada le sirva a una empresa de patatas, tener la seguridad de un búnker militar. Esto es primordial para desarrollar una solución, pero también para poder hacerle entender con sus propias palabras, el porqué de la misma, y el por qué ha de emplear recursos, tiempo o dinero en aplicarla.

Nuestra faena no acaba con la implementación de la seguridad. Tenemos que ser capaces de hacer entender a nuestro cliente, que lo que estamos haciendo es ante todo para proteger sus datos. Para garantizar que nadie se apropia de su información sensible. Que aunque añadamos un poco de complejidad a su día a día, siempre el mínimo posible, va a poder tener la confianza de que limitaremos las posibles fugas de datos. Explicándoselo con sus propias palabras, y con su propia mentalidad. Y esto, es harto difícil.

De nada me sirve utilizar cuatro protocolos de seguridad indescifrables, o utilizar casos que nada tienen que ver con el suyo. Tampoco explicarle que me he hecho pasar por un hacker que trabaja desde Uganda para poder acceder a su clave de wifi. Tenemos que hablar su idioma, y valorar sus propias inquietudes.

No nos engañemos, aún tenemos que hacer mucha concienciación. Debemos exponer bien nuestros argumentos, hacer demostraciones, enseñar porque necesitan dicha seguridad. Mostrarles que los amigos de lo ajeno, no llevan antifaz y una bolsa con el símbolo del dólar impreso, muchas veces están detrás de un ordenador. Hacerles entender que no sólo es necesario poner una alarma en las puertas de las empresas, sino asegurar que ponemos sus datos a salvo. En definitiva, ganarnos su confianza. Y hacer eso, es lo más difícil a lo que nos enfrentaremos.

Permisos en Android y malware, el nuevo “He leído las condiciones del contrato”

El malware no es nuevo a día de hoy, y uno de los sectores en los que más está creciendo es en el campo de los dispositivos móviles debido al auge continuo de smartphones y tablets. Un ejemplo de ello es la cifra proporcionada en el reciente Google IO 14 de 1000 millones de dispositivos Android activos actualmente.

Hace unos días aparecía un informe de McAfee donde se destacaba la cantidad de clones del juego Flappy Bird que cuentan con algún tipo de malware en su código. Curioso. Con este dato decidí hacer una revisión rápida a esa colección de clones para centrarme en los permisos solicitados por cada uno de ellos.

Pero claro, ¿cómo saber si son un exceso de permisos o no? Para ello, empecemos con nuestra propia lógica: es un juego sencillo que lo único que hace es guardar una puntuación máxima y de vez en cuando sale algún anuncio, por lo que deberíamos esperar al menos los permisos de conexión a internet y de almacenamiento. Casualmente decidí probar el juego en su momento y aún dispongo de acceso al mismo en mi historial de Google Play, así que pude acceder a ver los permisos que realmente necesitaba la aplicación:


Los permisos originales del juego.

Al final resulta que solo necesita tres permisos, los cuales son aceptables para lo que se espera de la aplicación. Sin embargo, a la hora de ver otras similares, nos encontramos con el siguiente abanico de opciones extra que debemos autorizar o no en función del clon elegido:


Recopilación de los múltiples permisos que pueden solicitar los clones. No es la lista de permisos de una aplicación.

Hasta cierto punto algunos de estos permisos son razonables. Por ejemplo, buscar cuentas en nuestro dispositivo para publicar nuestra última puntuación en la red social correspondiente: no nos garantiza que junto a nuestra marca personal además añada publicidad de otros productos ajenos al juego (un enlace a una web que oferta productos de China). Sin embargo, ¿por qué deberíamos permitir averiguar nuestra localización? ¿Es necesario para el caso anterior de compartir nuestro récord? ¿O realmente tiene otro propósito?

Instalando una de las aplicaciones en un dispositivo limpio (sin tarjeta SIM, formateado de fábrica y sin ningún dato de cuenta introducido) nos encontramos con la siguiente imagen. Referida al compartir lo que suponemos que era la tabla de récords, dado el inconveniente que nos encontramos con el idioma de la misma (coreano, concretamente). Las dos primeras redes sociales no hay problemas en reconocerlas, ¿pero las dos siguientes? ¿Y la opción de compartir por correo? ¿En verdad alguien la usa para enviar ese tipo de información?

No hay duda de que Google trabaja en mantener limpio su mercado de aplicaciones, pero se ve que hace falta mucho más control para evitar ya de base la posibilidad de subir aplicaciones comprometidas, y más aún si logran tener cierto éxito. Otro caso similar relativamente reciente fue el de las aplicaciones del tipo linterna que suscribían a servicios SMS de pago y conseguían ocultarlo hasta que llegaba la factura del mes, con permisos para leer SMS entre otros. ¿Nadie se extraña de eso en una aplicación que lo único que tiene que hacer es encender un LED?

Y es que al final la culpa no es solo de quien proporciona acceso a la descarga de la aplicación, sino también del propio usuario que por no gastar quince segundos mirando los permisos de la aplicación puede acabar pagando hasta 30 euros extra a fin de mes, junto a algún que otro susto.

Como consejo final, decir que si revisáis un contrato o una factura antes de firmarlo, ¿por qué no hacer lo mismo con el móvil y las aplicaciones que instaléis?

Impresiones con Autopsy3

Recientemente he utilizado la versión 3 de Autopsy, la popular interfaz web de The Sleuth Kit, con idea de ver las novedades respecto a la versión anterior (v2). El hecho de estar acostumbrado a la versión 2, que la v3 sólo estuviera para Windows y además fuese basada en Java, habían hecho que hasta ahora no me hubiese decidido a probarla

Finalmente me he decidido y estas son algunas impresiones que he tenido.

La primera impresión que se tiene de la interfaz de usuario es que es bastante más amigable, moderna y usable que su antecesora web, con un acceso mucho más ágil a las diferentes partes de la aplicación. Una característica que he visto muy útil es el módulo de Ingest y la posibilidad de seleccionar los plugins que van a utilizarse; de esta forma, para ganar algo de tiempo, podemos realizar una ingesta de datos con un único plugin para tener algo sobre lo que trabajar y, mientras realizamos un análisis preliminar, podemos dejar cargando y procesando el resto de plugins.

Uno de los plugins que nos puede ahorrar algo de tiempo a la hora de descartar archivos conocidos sin manipular es la base de datos de hashes, que compara el hash de los archivos con dicha base de datos. La base de datos que es de obligada descarga es la NSRL del NIST, National Software Reference Library, con un tamaño actual de 6 GB de software conocido (tanto bueno como “malo”). No obstante, hay que recordar que no contiene entradas de malware sino más bien herramientas consideradas para hacking, desde nmap a herramientas de esteganografía. Otra pega es que, al parecer, sólo contempla versiones de software por defecto sin tener en cuenta las actualizaciones, por lo que puede crear falsos positivos o alertarnos ante archivos sospechosos aunque que se trate de actualizaciones lícitas.

Para utilizar esta base de datos tendremos que descargar la base de datos unificada, o bien las otras opciones más reducidas que también nos ofrece; y la importamos de la siguiente manera:

Tras lo que tendremos que indexar el contenido:

Una vez hecho esto, ya podemos realizar una nueva ingesta con el plugin del hash database activado, seleccionando la base de datos del tipo NSRL. Si queremos utilizar una base de datos de malware, tendremos que recurrir a algunas de pago o utilizar servicios online de consulta de hashes que nos dirá, uno a uno, si se reconoce como malware. Entre esos servicios online tenemos la Hash Database de SANS, OWASP File Hash Repository, Malware Hash Registry de Team Cymru, o VirusTotal, entre muchos otros.

El proceso de ingesta tardará dependiendo del tamaño de la imagen y la potencia del equipo, pero nos mostrará una columna con el resultado del hash y si se encuentra en las bases de datos (known/unknown en la NSRL o bad-known si tuviéramos otras de malware. A partir de ahí, podemos descartar aquellas detectadas como known y, aquellas que sean unknown y tengamos dudas, podemos utilizar dichos servicios online copiando el hash del archivo seleccionado.

Para sacarle un defecto que le he encontrado, aparte del hecho que he tenido que configurar el idioma del sistema al inglés debido a problemas de Java con el Timeline y las fechas, es que, no sé si debido a la diferencia entre el número de eventos entre meses u a otro, han desaparecido los eventos de enero y febrero, sin posibilidad de seleccionarlos en el Timeline, con lo que he tenido que sacarlos a través de búsquedas en esas fechas.

Para poder mostrar los archivos modificados en enero y febrero he tenido que recurrir a búsquedas filtradas por esas fechas. En su defensa diré que está funcionalidad aún se encuentra en estado Beta, por lo que son normales estos errores.

La verdad es que he visto una versión más moderna, completa y ágil de utilizar y, a pesar de algunos pequeños detalles, me ha convencido bastante.