Conseguir que tus aplicaciones sean seguras (o al menos, intentarlo) 2

Si limitar las aplicaciones que tus usuarios pueden utilizar te parece divertido, posiblemente no hayas pensado en lo que se te viene encima. Ahora tienes un conjunto de aplicaciones en las que centrarte y te toca hacerlo. Para empezar, tendrás que monitorizar los problemas de seguridad que pudieran afectar a cada instalación particular que tengas de cada software.

¿De dónde pueden venir los problemas? Poca cosa:

• Vulnerabilidades del propio software.
• Dependencias. Por ejemplo: que el software sólo funcione con una versión obsoleta de Java o de Flash. O que utilice una librería a la que se han encontrado fallos, como el reciente problema de Imagemagick.
• Software mal configurado.
• Fallos del software que obliguen a utilizar una configuración insegura. Como que no funcione correctamente el uso de contraseñas a la hora de acceder a carpetas compartidas y haya que establecer en éstas permisos del tipo "acceso total para todo el mundo".
• Interrelaciones entre software que supongan merma para la seguridad. Por poner un caso: quizá nuestro software tenga que conectarse con un servicio web. Si éste no funciona sobre HTTPS, el uso de HTTP supondría el correspondiente riesgo de intercepción y/o modificación de peticiones y respuestas
• etc.

Pero si conocer dónde puede estar el problema es importante, no lo es menos enterarse de que existe. Y aquí también tenemos distintas opciones. Ten en cuenta que no son excluyentes entre sí, de modo que tienes que ir preparando unos cuantos canales. Entre ellos:

• Pruebas realizadas por tu organización: análisis de vulnerabilidades, tests de intrusión internos, etc.
• Repaso de logs que pudieran encontrar ataques, ya fueran estos exitosos o no.
• Información proporcionada por los distintos CERT.
• Boletines de seguridad de los desarrolladores.
• Repositorios de vulnerabilidades tipo CVE.
• Otras organizaciones y fuentes de información (blogs, foros,...) relacionadas con la seguridad de la información.
• Notificaciones por parte de profesionales de, y aficionados a, la seguridad que pudieran encontrar las vulnerabilidades. Dado que por este conducto puede llegarnos información muy cualificada (al menos, a veces) es muy importante cuidarlo y asegurarnos de que existan dos cosas y de que estén claras desde el principio:
• Un cauce para que estas personas puedan realizar las comunicaciones.
• Un marco en el que se deje claro qué se les permite y qué no hacer y cómo se va a tratar la información proporcionada.

A este respecto se me viene a la cabeza un antiguo artículo de Chema Alonso sobre la propuesta de un archivo "hackers.txt". Algo similar al "robots.txt", pero para gente de este mundillo.
 
Por no acabar este post sin poner otro par de listas, un elemento que puede complicarte la vida es lo variado de los tipos de software con los que puedes terminar trabajando. Una posible clasificación sería:

• Software libre, en distribuciones originales o modifados por terceros.
• Software libre modificado por tu organización. 
• Software hecho a medida, bien por tu organización o por terceros.
• Otro software propietario.

Dependiendo de en cuál puedas catalogar el sistema que presenta la vulnerabilidad, y de la naturaleza de ésta, tendrás una serie de opciones para corregir la situación:

• Modificar la configuración del software. Posiblemente estés deseando que sea esto lo que haya que hacer.
• Obtener una nueva versión del producto, o de las dependencias afectadas, y aplicarla. En este caso, la fuente de esta nueva versión podría ser:
• El desarrollador del software afectado. Esta solución suele ser la mejor pues ofrece mayores garantías de continuidad en el futuro. Téngase en cuenta que el resto de opciones puede suponer tener que seguir manteniendo el software en el futuro sin el soporte de su desarrollador, quizá con medios propios. Y medios no siempre sobran...
• Un tercero que ofrezca modificaciones del software (forks). En este caso, mejor que elijas algo fiable y con garantías de futuro.
• Una modificación o desarrollo propio. O una modificación o desarrollo contratada a un tercero. Ya sabes que ésta te seguirá dando qué hacer durante mucho tiempo...
• Plantearte la sustitución del producto afectado por otro que proporcione las mismas funcionalidades, pero que sea más seguro.

Tanto si obtienes una nueva versión y la aplicas como si cambias de software tendrás que actualizar la lista de software aprobado.

Eso, como se comentaba en el post anterior, tenía necesariamente su complejidad admistrativa. Pero no nos olvidemos de la parte técnica: ¿cómo elegir o, en su caso, desarrollar el software?

¡Qué poco dura la alegría en la casa del pobre!

Quizá te haya pasado: Tienes un blog o un sitio web que apenas recibe visitas y un día, de pronto, cuando, de puro aburrido, compruebas si alguien ha visualizado alguna de sus páginas... ¡guau! ¡los contadores se han disparado y parece que comienzas a tener toda esa relevancia que siempre creíste merecer!

Bueno, sí, puede que sea eso. Pero es más probable que hayas sido víctima de un ataque de "SPAM de Rererer". Alguien ha puesto un programita a hacerte visitas incluyendo una cabecera "Referer" con una determinada URL. Una URL cuyo documento, por supuesto, no incluye ninguna referencia a tu sitio web.

¿Para qué?

Para empezar, si tu sitio tiene alguna página de estadísticas de acceso, en ella podría aparecer la URL que te enviaron como Referer. Y, si los bots de los buscadores la ven... ya sabes cómo interesa a cierta gente que haya enlaces a sus páginas y qué son capaces de hacer para conseguirlos.

Pero lo más probable es que se trate de una técnica de Ingeniería Social. Si, al revisar tus estadísticas, ves que recibes muchas visitas desde una URL, quizá te pique la curiosidad y quieras saber qué dicen de ti. Si te recomiendan o te critican. Si se trata de otra web con una temática similar a la tuya que podría interesarte. Si...

Y vas y visitas esa URL para comprobarlo.

A partir de ahí puede pasar cualquier cosa: que te intenten vender algo, que te traten de colar malware, que recopilen de ti toda la información que tu navegador proporciona (que no es poca) y la procesen para preparar un posterior ataque "más grave"... ¡cualquier cosa que pudiera ocurrírsete y alguna otra más!

Por supuesto, si tienes un sitio web popular posiblemente no repares en el Referer que te envían como SPAM. Quizá ni siquiera aparezca en las estadísticas de acceo. Quedará relegado a un puesto poco visible entre tantas visitas legítimas.

Pero si, como comenzaba planteando al principio, apenas tienes quien te lea... ¡entonces sí que aparecerá en lugar destacado en tus estadísticas, tentador e insinuante!

Lo dicho: ¡Qué poco dura la alegría en la casa del pobre!

Conseguir que tus aplicaciones sean seguras (o al menos, intentarlo) 1

La petición no presagiaba nada bueno:
- Tú que haces cosas de hacking y eso... ¿podrías decirnos cómo conseguir que nuestras aplicaciones sean completamente seguras?

Menos mal que esta vez tenía una respuesta:
-No podéis. Decir "completamente seguras" es como decir "perfecto". Y no existe nada perfecto.

- Vaya. Pero, al menos, podrías hacernos un listado de pruebas a realizar a los programas y cosas así.

Otra vez lo mismo. ¡empezar la casa por el tejado! Al final quedé en mandarles un documento con recomendaciones. No era la primera vez que me encontraba con esta situación ni que trataba el tema, de modo que tengo claro qué proponer. Y también que no es lo que esperan de mí, porque porque los consejos que suelo dar no tienen demasiado que ver con el hacking y sí con el sentido común y la gestión.

Eso sí, que nadie espere que vaya a ser fácil.

Para empezar, unas preguntas: ¿perteneces a una organización que te da recursos ilimitados para hacer tu trabajo? ¿todo el personal que le pidas? ¿todo el equipamiento que solicites? ¿todo el dinero que digas necesitar? ¿sin restricciones de tiempo ni de ningún otro tipo?

Si respondiste "no" a alguna de estas cuestiones (y, no sé por qué, creo que será el caso) entonces no puedes dedicar esfuerzos a gestionar y mantener todas las aplicaciones pasadas, presentes y futuras.

Haz, por tanto una lista blanca de aplicaciones, con indicación de las versiones, que tu organización puede utilizar y consigue que la alta dirección firme un documento en el que se prohíba el uso de todo programa o versión que no figure en la lista.

Por supuesto, habrá programas que todo el mundo podrá utilizar y otros restringidos a aquellas personas que desarrollan determinadas tareas.

Y, también por supuesto, tendrás que arbitrar procedimientos para actualizar la lista. Dar de baja aquellos programas que ya no se usan, han quedado obsoletos o han dejado de recibir soporte por su desarrollador, incluir nuevas aplicaciones que cubren necesidades no satisfechas con el software disponible y reemplazar elementos por otros que presten mejor servicio u ofrezcan un mayor grado de seguridad.

Mi siguiente consejo es que las modificaciones de la lista requieran también la firma de la alta dirección. Puedes tratar de embaucar a la misma persona que puso su rúbrica al documento que daba oficialidad a la creación de la lista blanca de software. Y que, en ningún caso, se añada una aplicación si existe otra u otras en la lista que cubra satisfactoriamente sus funcionalidades.

Ahora viene lo bueno: hacer que la lista no sea papel mojado. Utiliza herramientas que te digan qué software hay instalado en cada equipo de tu organización y comprueben que no hay nada que no figure en la lista.

Deja claro desde el principio, si es posible por escrito, que si encuentras algo raro lo reportarás al jefe de la unidad en que aparezca y a la alta dirección. Yo incluso lo incluiría en el documento que crea la lista blanca de aplicaciones, de modo que la firma de la alta dirección suponga una orden para tí.

Y cumple tu palabra. Amigos, lo que es amigos, no te va a ayudar a hacer, pero es lo que tiene esto de la seguridad.

Para acabar por hoy, una última recomendación. Piensa en qué harías tú si fueras ellos. En qué haces cuando el antivirus no te deja utilizar tranquilo uno de esos programas que hacen cosas "graciosas". ¿Creas, quizá, una máquina virtual?

Pues, llegado el caso, a alguien más se le ocurrirá. De modo que controla expresamente a quién se le permite utilizar software de virtualización y haz un listado de máquinas virtuales autorizadas. Si alguien se crea una "de estranjis", trátalo igual que si hubiera instalado un software no permitido. Y, por supuesto, controla lo que corre en los equipos virtualizados como si de máquinas físicas se tratara.

¿Te parece mucho lío? ¿Muchos quebraderos de cabeza? ¿Muchos posibles conflictos?

Pues la cosa no ha hecho más que comenzar.

Go, go, go

Lo de Pokemon Go está dando que hablar. Hoy leo que un individuo se puso a trepar por la fachada del hotel Arts de Barcelona, el edificio más alto de la ciudad, en medio de una peculiar partida.

Que se indique que el protagonista de la historia es un experto en parkour y que grabó la gesta en video me hace pensar en una búsqueda de publicidad y notoriedad. Pero no es la primera persona que se mete en líos: ha habido incluso casos en los que los jugadores se han introducido en una propiedad privada buscando monstruos que capturar y los propietarios han disparado sobre ellos. Y también se han dado caso de ladrones que, sabiendo que la gente iba a buscar a un pokemon en un determinado lugar, se han colocado por las inmediaciones a la espera de un incauto al que asaltar.

En el futuro, es probable que Niantic, la desarrolladora del juego, busque formas de hacer caja. Una que se me ocurre es la "aparición esponsorizada": que restaurantes, cines, parques de ocio y otros establecimientos paguen para que en sus instalaciones aparezcan una serie de monstruos u objetos virtuales. Esto no debería ser demasiado preocupante... a no ser que caiga en malas manos.

Se me ocurren varias formas en que algo así podría ser explotado con fines perversos. Desde "simpáticos" ataques de denegación de servicio, llenando una oficina de jovenzuelos, y no tan jovenzuelos, que anden por allí mirando el móvil o colpasando de forma parecida el tráfico hasta deleznables intentos de engañar a menores para que se acerquen a un lugar, pasando por reventar manifestaciones haciéndolas coincidir con una multitudinaria partida de entrenadores. El futuro dirá...

Pero el pasado ya habló y me preocupó lo que oí. En particular la noticia de que la aplicación requería inicialmente, en su versión para iOS, permisos completos de acceso a la cuenta de Google.

 Ciertamente, no tardó mucho en aparecer una nueva versión con muchos menos requisistos, pero... ¿para qué tanto acceso? Porque una cuenta Google es búsquedas, calendario, correo y mucho más. A bote pronto, encuentro tres explicaciones:

1.- Que se hiciera todo el desarrollo de forma correcta, pero que, en el último momento y por error, se hubiera configurado unos permisos inadecuados. Que en la nota del enlace anterior se indique que "en cuanto supimos de este error, empezamos a trabajar para encontrar una solución" y que ésta no estuviera disponible cuando se publicó el aviso me hace pensar que hay algo más. Que el problema radicaba en otro sitio y no tenía una solución tan obvia.

2.- Esta es más conspiranoica y vaya por delante que la considero errónea: Que la empresa quisisera acceder a toda esa información para crear perfiles para rastreo, publicidad personalizada y tantas otras cosas que hoy día tanto se estilan. Eso, desde luego, sería preocupante. Pero parece que no es el caso.

3.- Que, para acelerar el desarrollo, alguien dijera "vamos a quitarnos una preocupación de encima" y
los permisos o bien no hubieran sido establecidos desde el princio o bien hubieran sido ampliados de forma descontrolada para solucionar algún problema de funcionamiento. Espero que no sea eso porque lo de "permiso total y así seguro que funciona todo" es un mal principio de diseño. Un síntoma de sistema en cuyo ciclo de vida la seguridad se dejó para más adelante y en el que, por tanto, ésta tendrá poca cabida y no terminará de encajar.

Si a alguien se le ocurre otra...

Biometría: Identificación, Autenticación o Autorización

El otro día hablábamos sobre esos sistemas que te permiten elegir una pregunta y una respuesta para restablecer tu contraseña en caso de olvido. De cómo muchos sistemas, aunque almacenan cifrada la contraseña, guardan en texto claro la respuesta secreta. Y alguien me dijo: "cuando se generalicen los sistemas de autenticación biométricos, eso ya dejará de ser un problema".

Es verdad que, con la velocidad con la que cambia todo, predecir cómo serán las cosas dentro de diez años es complicado pero, por ahora, a mí la idea no termina de convencerme. No sólo por las implicaciones que pudiera tener para nuestra privacidad, que ya de por si pueden ser preocupantes, sino por el estado actual de la tecnología.

El año pasado, Yulong Zhang y Tao Wei presentaron en Black Hat la ponencia "Fingerprints on Mobile Devices: Abusing and Leaking". En ella nos hablaban, entre otros temas, de la diferencia entre Autenticación y Autorización y lo ilustraban con algunos ejemplos. Como que un Documento Nacional de Identidad puede ser un mecanismo de Autenticación mientras que una VISA puede serlo de Autorización en el momento de disponer de dinero para realizar una compra. En otras palabras, la diferencia entre "Quién eres" y "Qué puedes hacer".

La diferencia llega a ser sutil en algunos casos en los que no sabemos realmente qué estamos haciendo. Depende del contexto. Un mismo gesto puede servir para desbloquear el teléfono o para autorizar un pago. El mecanismo es parecido, pero el objetivo puede ser muy distinto.

A partir de ahí la ponencia trata sobre formas en que se puede engañar a los sensores de huella y cómo robar los datos biométricos y replicarlos para suplantar la identidad e ideas parecidas.

Pueden "robarte la huella" y falsificarla. Y lo peor es que tu huella dactilar no es algo que puedas cambiar fácilmente. Te dura toda la vida. Y me quejo yo de que la gente no renueve las contraseñas con frecuencia...

Se me vienen a la cabeza otros casos relacionados. Como el del engaño al mecanismo de desbloqueo facial de Android mediante fotos o videos. O la de aquel antiguo caso en que se utilizó cinta adhesiva para engañar el sistema de control de acceso mediante huella dactilar a los aeropuertos.

O un producto llamado Identity que encontré referenciado en el blog de MalwareBytes: Una especie de "tirita" o "curita" que te pones en el dedo y que lleva una huella dactilar falsa (cada "tirita" lleva una distinta).

Como medida de protección de tu intimidad o como forma de tener una "contraseña" que puedas cambiar, vale. Pero lo que en definitiva se está haciendo es acabar con la componente biométrica. Cambiar lo de "algo que forma parte de tu cuerpo" por un tradicional "algo que tienes".

Y es una tendencia que, para salvaguardar la intimidad, creo que irá al alza. Y que no deja de poner más en duda, si cabe, la validez de la huella dactilar como mecanismo de autenticación. Por no hablar del "no repudio".

Por no hablar de una de las cosas que aparecen en un artículo relacionado:

"Courts have also recently ruled that fingerprints aren't covered under the Fifth Amendment's protections against self-incrimination: Unlike with a passcode, police can force suspects to unlock a phone with a fingerprint if arrested, without a warrant.".

Traduciendo: que un juez no puede obligarte en los EEUU a darle tu contraseña, pero sí a poner el dedo en un sensor.

Y es que, tal y como están las cosas, viendo estos mecanismos biométricos "de andar por casa", tengo la impresión de que son más válidos como sistemas de identificación que como de autenticación o autorización. Más para indicar quién eres que para establecer una seguridad razonable acerca de tu identidad o dejarte hacer algo.

Más como el identificador o la cuenta de usuario que como la contraseña.

Adivinanza

Estaba yo esperando que me prepararan una pizza para llevar cuando alguien aparcó el coche en doble fila y salió a la calle.

Aunque no le conocía de nada, ni siquiera me hizo falta mirarle a la cara para saber su nombre.

Y no: no lo llevaba escrito en la ropa ni el coche lo anunciaba en modo alguno ni nada por el estilo.

No. Lo que pasó es que yo andaba jugando con mi móvil y, por accidente, le había dado al botón de "Buscar dispositivos Bluetooth". El coche paró y, en menos de un segundo, me aparecieron dos dispositivos. Uno con un nombre curioso, que me callo y que supongo que sería el equipo de audio del vehículo y otro que se llamaba "Javier".

En el paseo de vuelta a casa, mi cacharro siguió encontrando cosas con nombres como:
[TV]Samsung LED46
Nokia C2-01
BLACKBERRY-C140
Juan (Galaxy A5)
CRISTINA-PC

Y muchos más. Realmente, me sorprendió el número de personas que llevan activado y visible el Bluetooth de su smartphone.

Lo interesante en este caso es que el alcance de Bluetooth es bastante limitado con lo que se puede determinar con relativa precisión dónde se encuentra cada dispositivo hallado. En el caso de un móvil, que suele tener un adaptador de Clase 2 (haz clic aquí si quieres más información sobre el tema), estaríamos hablando de entre 5 y 10 metros.

En pocas palabras, puedes enterarte de que el vecino compró ya su nueva tele y saber qué modelo o qué tamaño tiene. Y si la tiene encendida o no. O "adivinar" el terminal telefónico que alguien tiene en el bolsillo. Nno olvidemos que, en última instancia, cada adapatador Bluetooth tiene una MAC y ésta nos identifica a su fabricante y éste, a su vez, puede ser indicio de la marca y modelo del equipo en que está instalado.

O, como antes, el nombre de una persona.

O, si de hablar de los vecinos se trata, moverte por las habitaciones de tu piso e ir haciendo un "mapa" de qué cacharro hay en cada habitación de los pisos de arriba o abajo. Con un poco de trabajo y suerte puedes terminar sabiendo de quién es cada dispositivo y si en el dormitorio hay un teléfono o dos.

Y si alguno de ellos no es de los habituales.

En definitiva, que si tu privacidad te importa... ya sabes: desactiva el Bluetooth, hazlo no detectable o, mejor aún, ambas cosas. Y, por otro lado, que durante una prueba de intrusión puede ser interesante saber qué dispositivos hay por ahí sueltos, aunque no llegues a verlos. Y que, desde el punto de vista de un ataque de Ingeniería Social, saber cómo se llama y qué teléfono tiene el vigilante de la entrada, por decir algo, puede darte un poquito de ventaja.

Para quien quiera jugar un rato desde su PC, hay dos herramientas de Nirsoft gratuitas y sencillas con las que entretenerse. La primera, BluetoothView, muestra los dispositivos que va detectando:

Y la otra es BluetoothLogView. No es muy distinta de la anterior, pero va indicando cuándo encuentra y cuándo deja de detectar cada dispositivo. Vaya por delante el aviso de que tarda un ratito en actualizar los datos:

Las preguntas para restablecer la contraseña

Un día, hace ya mucho tiempo, alguien inventó eso de que los usuarios tengan una pregunta secreta (y su correspondiente respuesta) para restablecer su contraseña en caso de olvido. Y debió entender que era una buena idea. Al menos, puede parecerlo para los administradores de sistemas, sobre todo cuando el número de cuentas implicadas es elevado.
Pero la comodidad no suele llevarse bien con la seguridad.

Para empezar, como he escrito alguna otra vez, está el tema de los nombres: es importante cómo llamamos a cada cosa. Porque si decimos que es una "contraseña" la gente tiene claro que debe ser algo secreto y difícil de adivinar pero si hablamos de "recordatorio"... la cosa cambia. Ahora es algo que tenemos que recordar o nos tiene que recordar la contraseña. Y si le ponemos sólo "pregunta", ya no pasa de algo que hay que saber responder.

Por no hablar de aquellos sistemas en los que lo que se nos pide es nuestra fecha de nacimiento o un dato similar.

Que todo esto no es una buena práctica es algo que nadie debería poner en duda. Abusando de estos mecanismos es como en su día cayeron en malas manos cuentas de correo como la de Sarah Palin.


Hace poco detecté y comuniqué un caso en el que podían obtenerse los datos de las cuentas de usuario de un sistema y utilizaban este procedimiento para restablecer credenciales. Y, como casi siempre, me dio en qué pensar.

Al fin y al cabo, estas preguntas y sus correspondientes respuestas terminan no siendo más que otra contraseña. Pero no una "contraseña adicional", sino una "contraseña alternativa". No una condición de tipo AND, sino OR.

Y lo malo de tener dos contraseñas alternativas es que basta con saber una cualquiera de ellas para hacerse con el control de la cuenta. Ya se sabe: lo del eslabón más débil...

Pero, con todo lo grave que esto pueda ser, hay algo que, a largo plazo, puede ser aún más preocupante: la gente, consciente de que si olvida la respuesta no podrá restablecer sus claves de acceso, suele poner preguntas relacionadas con su vida privada.

Cuando esas respuestas están en Internet, como ocurrió con la por entonces candidata a la presidencia de los EE.UU., la cuenta queda comprometida al primer intento.

Pero... ¿Y si no lo están? Pongamos que alguien pone una pregunta del tipo "¿Cómo se llama mi esposa?" y que ese dato no está publicado en ningún sitio. Entonces, un atacante podría empezar a realizar pruebas, realizando un ataque de diccionario y, con algo de suerte, podría obtener una información que le ayude a realizar un perfil más completo de su víctima.

Pienso en qué pasaría si hubiera sido alguien con malas intenciones, y no yo, quien hubiera encontrado aquella base de datos de usuarios. Imaginad, preguntas como:

• ¿Cómo se llama mi pareja?
• ¿Cómo se llama mi abuela paterna?
• ¿Cómo se llama mi hijo?
• ¿Cómo se llama mi jefa?
• ¿De dónde es mi pareja? 
• ¿Cuándo se me declaró mi pareja?
• ¿Cuál es mi número de teléfono?
• ¿Cómo se llama mi perro?
• ¿Dónde vivo?
• ¿Dónde nací?
• ¿Cuál es mi apodo?

Y muchas otras sobre gustos, hobbies y aficiones.

Imaginad estas preguntas con sus correspondientes respuestas. Pensad en lo útiles que pueden ser para preparar un ataque de ingeniería social.

Pensad en las implicaciones para la privacidad.