Quien más, quien menos ha leído acerca de XCodeGhost. Una reciente bomba informativa que se ha vertido a los medios de comunicación como “App Store Hackeada”, dando a entender que el servicio de compra y descarga de aplicaciones había sido hackeado.

Espera, espera, espera…

[Read more…]

Como era de esperar, en el MWC de Barcelona se han presentado multitud de novedades en el mundo de la tecnología móvil, principalmente. Sin embargo, eventos previos a la apertura del MWC hay otros como es el MobileFocus. No voy a hablar de las últimas novedades de Samsung. Aquí el protagonista es… ¡AVG! Sí, sí, has leído bien, AVG. La compañía antivirus y su departamento de Innovación ha presentado en el MobileFocus unas gafas que te hacen invisible.

Y no, no hablamos de invisibilidad cual capa de Harry Potter. Pero bueno, “it’s something”. Según explican en esta noticia de AVG, es posible gracias a varios materiales utilizados para fabricar estas gafas. Básicamente permite que, a la persona que lleva estas gafas, no se le pueda identificar mediante cámaras y otros sistemas de reconocimiento facial. Bueno, a quien se anime a llevarlas… más que nada porque son un poco feas. Pero, dejando de lado los aspectos estéticos, ¿cómo funcionan? Tal y como explica AVG funcionan gracias a dos principales materiales utilizados para su fabricación.

Por un lado, el uso de LEDs infrarrojos. Estos LEDs, en caso de estar encendidos, hacen que las cámaras sensibles a la longitud de onda de estos LEDs no puedan detectar los rasgos faciales. Claro que con esas gafas, ¿quién puede?

Por otro lado, el uso de material retroreflectante. Básicamente es un material que, en el momento de realizar la fotografía con flash, devuelve la luz tal como llega. Tal y como muestra la imagen:

Vale, muy bien, AVG, ¿y todo esto a santo de qué? Según nos cuentan tienen varios motivos por los que centrarse en el desarrollo de estas fantásticas gafas. Tienen como premisa la preocupación por la privacidad del usuario. Por lo tanto, los motivos que expone AVG son los siguientes:

• Dado el uso masivo de smartphones tomando fotografías en sitios públicos, es (más que) probable que en alguna de ellas podamos salir sin nuestro consentimiento.
• Proyectos como StreetView de Google permitirían identificar a una persona en uno o varios lugares públicos. Punto en el que no estoy muy de acuerdo, ya que Google suele censurar las fotos en las que aparece alguna persona. <mode paranoid on>Otra cosa es el uso interno que haga Google con las fotografías originales…<mode paranoid off>.
• Proyectos como DeepFace de Facebook permiten el reconocimiento facial de las personas. Por tanto, permitiría a organizaciones y compañías hacer uso de esta característica, no solo para identificarnos si no también para cruzar esa información con otros datos encontrados en la Red.

Sin lugar a duda es un proyecto interesante, dado que estamos rodeados de cámaras de seguridad y videovigilancia, además de smartphones que pueden ser utilizados para espionaje (o contraespionaje). Aunque si te ven con eso puesto, lo que está claro es que vas a ser el centro de atención y desapercibido no vas a pasar precisamente :)

¿Qué opináis? ¿Se merece un empujón este proyecto? ¿Qué otras ventajas y/o inconvenientes encontráis? ¿Gafas de marca apostando por esta tecnología? ¿Os imagináis unas Google Glass con esta función?

Ahí dejo mis preguntas al aire para que respondáis. Feel Free!

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?

Hace relativamente poco que han salido varias noticias acerca de securizar conversaciones de Whatsapp, así como otros temas relacionados con el supuesto espionaje de algunas organizaciones. Desde entonces, mi interés por OTR se ha incrementado mucho.

Para los que no lo conozcan, OTR es un protocolo que permite cifrar (y no encriptar) conversaciones, Off-the-record, de modo que terceras partes no puedan leer la conversación que estamos manteniendo con la otra persona. Del mismo modo, se pueden evitar lecturas no autorizadas de nuestra bandeja de mensajes, por ej, de Facebook, entre otras muchas aplicaciones.

El requisito es que ambas partes involucradas en la comunicación tengan esta aplicación instalada.

¿Qué es?

Como bien se ha indicado anteriormente, es un protocolo que permite cifrar las conversaciones. Pero además de esto, nos ofrece:

• Funcionar haciendo uso de sistemas y plataformas de terceros, véase Facebook, Jabber, etc.
• Autenticar cada una de las partes con las que mantenemos una conversación, de modo que se pueda identificar y alertar en caso de un ataque Man-in-the-Middle.
• Cifrar la conversación de modo que sólo las partes involucradas puedan leerlo.
• Negación de la autenticidad. Los mensajes intercambiados no tienen ninguna firma digital, con lo que no hay prueba de que el mensaje lo hayas enviado tú.
• Confidencialidad en caso de pérdida de la clave. En cada conversación se generan unas claves temporales para cifrar los mensajes.

Para los que quieran profundizar en el tema, en este enlace está detallado el funcionamiento del protocolo OTR.

A continuación, vamos a ver las aplicaciones que permiten hacer uso de OTR.

Aplicaciones

Empezamos con la aplicación móvil para Android e iOS.

1. [Móvil] ChatSecure (Gibberbot)

Como alternativa a Hangouts para Android, me recomendaron una aplicación llamada ChatSecure (También conocida como Gibberbot) que implementa el protocolo OTR a través de XMPP. Con esto podremos configurar, por ejemplo, las cuentas de Google y Facebook.

Para descargarlo, se puede buscar ChatSecure en Google Play desde el mismo terminal ó bien lanzar la instalación desde el siguiente enlace.

Para los afines a la manzana (iOS), tenéis el siguiente enlace.

Una vez instalado, es muy intuitivo y fácil de configurar.

Para usar una cuenta de GMAIL, se le indica qué cuenta se quiere usar (de normal la que está configurada en Android).

Para usar la cuenta de Facebook, se le debe indicar que se quiere añadir una cuenta de Jabber (XMPP) e introducir los siguientes datos:

– usuario: usuario@chat.facebook.com
– contraseña: ******

Ahora falta indicarle el servidor chat.facebook.com en el apartado de configuración avanzada.

Nota: el usuario es lo que aparece en http://www.facebook.com/usuario cuando uno accede a su perfil. (Por si alguien aún no lo sabía).

¿Fácil no?

Veamos unos ejemplos de conversación, todo el proceso de autenticación y cifrado y lo que una tercera persona (no autorizada) vería.
Primero, el proceso de autenticación y cifrado desde GibberBot.

En la imagen podemos ver Conversación sin cifrar –> cifrada pero no autenticada –> verificación –> cifrada y autenticada.

A continuación, lo que terceras partes verían en Facebook o Hangouts.

2. [Móvil] IM+

La alternativa a Gibberbot, disponible también para Android e iOS.

Podéis conseguirlo desde el Google Play en el Terminal o bien desde el siguiente enlace.

Para el caso de iOS, aquí tenéis el enlace.

Una vez instalado, podéis comprobar que es un poco más fácil de configurar que GibberBot, pues para añadir una cuenta, sólo es necesario hacer clic en el icono de dicha plataforma y seguir unos pasos, como podéis ver a continuación:

3. [Multiplataforma] Pidgin + OTR

¿Quién no ha usado el famoso Pidgin? Pues tenemos disponible el plugin OTR para llevar a cabo nuestro objetivo de cifrar las conversaciones.

Se puede descargar desde la página de OTR. Una vez instalado, en la lista de complementos (Herramientas -> Complementos) lo activamos y ya podemos configurarlo.

Se nos abre una ventana como la siguiente:

Le damos a Generar y nos aparecerá nuestra huella digital. Ahora ya podemos iniciar sesión en Facebook y empezar a usar el cifrado.

4. [OS X] Adium + OTR

Sin olvidarse de la gente que utiliza OS X habitualmente, también se puede hacer uso de OTR con la aplicación de mensajería Adium. Esta está disponible para su descarga desde la web oficial https://adium.im

Una vez instalado, dentro de las preferencias de la aplicación, en el apartado Encryption se ha de generar un fingerprint para la cuenta que estamos usando.

Para comenzar a cifrar la conversación que vamos a mantener, se ha de hacer clic en el icono del candado, arriba a la izquierda de la ventana:

Imagen extraída de www.encrypteverything.ca

Ya podemos disfrutar del cifrado OTR también para OS X.

Conclusiones

Para terminar, como muchos os habréis dado cuenta, no es fácil conseguir que todas las personas hagan uso de alguna de estas aplicaciones. Sin embargo, no está de más recomendarlo cuando nos pregunten y echarles una mano a instalarlo. Porque si es una de las personas que habla habitualmente con nosotros, saldremos beneficiados.

Y la cuestión es, ¿porqué no ponerle más difícil las cosas a los husmeadores?

Introducción

Hace tiempo que se han puesto de moda las cámaras de videovigilancia conectadas por IP. Estas cámaras permiten su visualización desde cualquier parte del mundo. Esto se traduce en un problema: El Gran Hermano.

Mucha gente adopta esta medida de vigilancia por su facilidad de instalación y uso. Además de esto, la comodidad de estar fuera de casa y poder controlar todo lo que ocurre en el hogar.

Pero, ¿qué ocurre cuando no sólo lo instala un particular en su casa, sino que también lo hacen las compañías? Por poner varios ejemplos; una tienda, un restaurante ó cafetería, el hall de un hotel…

Como bien expresó Antonio Villalón en su post, nos quejamos del tío Sam, nos sorprendemos cuando salen a la luz ciertas noticias… pero no pensamos en que cuando vamos de compras o a una cafetería estamos siendo controlados en todo momento.

[Read more…]

Introducción
Cuando realizamos una auditoría de seguridad de una aplicación Web, en la mayoría de los casos, detectamos muchos fallos que son de libro. Son fallos que se van a reportar y que quedan muy bien en el informe; Inyección SQL (SQLi) y/o Cross-Site Scripting (XSS). Muchos sabéis de lo que hablo.

Estos fallos se suelen cometer generalmente por desconocimiento, es decir, hay desarrolladores que no saben que existen estos problemas. Por otro lado, están los desarrolladores que pese a conocerlos, no aplican correctamente medidas de seguridad para prevenir estos ataques. ¿Motivos? Presupuesto, esfuerzo extra, etc. Generalmente limitado por el cliente.

De todos modos, creo que sería interesante enfocar también nuestra atención en la educación que han recibido. Ya sea en FP o en la Universidad, se debería hacer hincapié en el desarrollo seguro de aplicaciones. Por ejemplo, en mis días de universidad solo he escuchado decir al profesor lo importante que es optimizar recursos (y lo es, pero no es lo único).

Sin embargo, nunca he escuchado nada acerca de la seguridad en otra asignatura que no fuese Seguridad en Sistemas Informáticos. Pese a ser lógico para algunas personas, por ejemplo, ¿por qué no enseñar lo que es un desbordamiento de pila/búfer en la asignatura de programación y lo que esto implica? ¿Por qué no enseñar lo que es una inyección de código SQL?

¿Excesiva confianza?
Algunos problemas surgen cuando se confía en el framework que se está utilizando. Puede ser que en el momento de desarrollar la aplicación no exista ninguna vulnerabilidad conocida que afecte a este framework, pero nada impide que en un periodo de tiempo estas vulnerabilidades sean publicadas. Por lo tanto, si no se lleva un control de actualizaciones y se llevan a cabo las correspondientes modificaciones para que nuestra app no sea vulnerable, habremos fallado.

Por otro lado, y en la mayoría de los casos, ocurre que se desarrolla una aplicación sin pensar en los “casos de abuso”. Es decir, se confía demasiado en que el usuario va a introducir correctamente todos los datos, y se confía en que se producirá el comportamiento esperado. Sin ir más lejos, tenemos el claro ejemplo del síndrome de la comilla con el que se detectan muchas vulnerabilidades de inyección SQL.

Casos prácticos
Para no explayarme mucho, quiero dejar unos ejemplos prácticos para que los nuevos desarrolladores los tengan en cuenta para sus nuevas aplicaciones, sobre todo aplicaciones Web ya que voy a remarcar el problema de las Inyecciones SQL.

Dada una aplicación web que muestra información de comentarios escritos por otros usuarios, vamos a ver dos ejemplos en los que saltarán a simple vista dos errores, SQLi y XSS.

¿Y Si vamos un paso más allá y probamos un Cross-Site? Vamos a ello…

Ahora vamos a echarle un vistazo al código:

< ?
$idAutor = mysql_real_escape_string($_GET['idAutor']);
$con = mysql_connect('localhost','testUser','testPassword');
$db = mysql_select_db("test");
$query = "SELECT * FROM comentarios WHERE autor = " .$idAutor;
$resultado = mysql_query($query, $con);
echo "Id Autor: ".$idAutor;
$row = array();
while ($row = mysql_fetch_array($resultado)) {
  echo "
Comentario: 
".$row['cuerpo'];
}
?>

Como habéis podido observar, se hace uso de la función “mysql_real_escape_string()”. Este error es muy común ya que muchas personas creen que es suficiente para evitar una inyección SQL. Además, se puede ver dónde está la inyección de código HTML/Script cuando se hace el “echo” de idAutor.

Si además seguimos indagando en el código, vemos que tampoco se hace un uso correcto de la conexión a la base de datos, lo que además acarreará problemas de rendimiento.

Conclusiones

Tal como hemos remarcado, muchas personas no conocen los peligros a los que se enfrentan a la hora de publicar una aplicación, en este caso, Web. Es muy importante que a los nuevos desarrolladores se les informe acerca de estos problemas en cursos específicos de un lenguaje de programación concreto, en FP, en la Universidad… Al fin y al cabo, como otras tantas cosas, todo empieza por la educación. ¿No?

No se trata de forzar a que todo el mundo aprenda a evitar este tipo de ataques, sino más bien, que tengan unas nociones mínimas y que sepan a lo que están expuestos. Se trata de tener buenos hábitos, inculcados por los formadores.

Para terminar, decir que este desconocimiento por parte de los desarrolladores, hace que no se traslade al cliente la importancia de implementar mecanismos de seguridad adecuados o de implementarlos en los correspondientes proyectos a desarrollar.

Introducción
Hoy en día se pueden encontrar muchas técnicas para proteger las aplicaciones Web frente a ataques de Inyección SQL. Principalmente, saneando la entrada de texto que proviene del usuario (siempre se debe pensar que es malintencionado).

Pero, ¿qué podemos hacer si queremos tener un control sobre estos ataques? Ya sea para bloquearlos o simplemente avisarnos, podríamos pensar en implementar un WAF (Web Application Firewall) pero existen aplicaciones y dispositivos más específicos: los Database Firewalls.

Funcionamiento
Se podría decir que es similar a cualquier WAF/IPS. Emplea una serie de reglas que permiten identificar las consultas SQL malformadas/malintencionadas y evitar que se lleve a cabo el ataque. Por otro lado, existen en el mercado productos que controlan ataques como desbordamientos de buffer o denegaciones de servicio, entre otros.

Tal como se ha indicado, se hace uso de reglas basadas en expresiones regulares. En caso de coincidir los patrones, saltarán los avisos correspondientes y la consulta será bloqueada/descartada. De esta forma se consigue evitar que el ataque sea efectivo.

Además de las reglas mencionadas, existen distintos modos de filtrado/bloqueo de consultas:

• Restrictivo, mediante una lista blanca donde se especifican las consultas legítimas.

• Permisivo, mediante una lista negra, huelga decir que son las consultas a bloquear.

• Análisis gramatical de las consultas SQL, con lo que se consigue identificar consultas (aunque fuesen legítimas) que pudieran ser aprovechadas, por supuesto, para inyectar código SQL.

Por último, mencionar que una de las características que se ofrece en estos productos es la de funcionar como proxy. Se almacenan en caché los resultados de las consultas y, de este modo, se reduce la carga a los SGBD y a las BBDD correspondientes.

Mercado y compatibilidades
En este punto, mucha gente se pregunta acerca de la compatibilidad de estos productos para ser usados con sus SGBD.

En el mercado existen multitud de fabricantes que ofrecen soluciones de seguridad para sus SGBD como pueden ser Oracle o Microsoft, entre otros. A continuación se va a nombrar, muy por encima, una solución alternativa.

Hace ya años que salió a la luz GreenSQL y continúa ofreciéndose de forma gratuita (GreenSQL Express). También existe la posibilidad de adquirir el producto de pago, GreenSQL Pro, donde además de un soporte nos ofrece más funcionalidades.

La versión gratuita está restringida a proteger sólo una BBDD y sólo protege frente a ataques de inyección SQL. Esto significa que no protege contra desbordamientos de buffer, escalada de privilegios, denegaciones de servicio…

Pero, ¿qué SGDB son compatibles con GreenSQL? A continuación os nombraré los distintos gestores con los que lo podemos usar:

• Microsoft SQL Server

• PostgreSQL

• MySQL

• Microsoft Azure SQL Database

• Amazon RDS

Conclusiones
Personalmente pienso que es una solución a tener en cuenta. No sólo por el hecho de ir un paso más allá en la protección de la información almacenada, sino también por aligerar el uso del resto de dispositivos (WAF, IPS…), sobre todo si están sometidos a una alta carga de transacciones (recordad que los Database Firewall pueden funcionar como proxy).

Desde la aparición de las redes sociales se ha ido concienciando poco a poco a los usuarios del peligro de compartir cierta información con los demás. Una de estas redes sociales, cada vez más popular y que en general y a diferencia de otras, proporciona la información publicada por un usuario a otros sin restricciones de acceso, es Twitter. Esta red ha cumplido 7 años desde su lanzamiento (muchos tweets que contar…) y parece que la mayoría de los usuarios todavía no están concienciados acerca de la privacidad, como suele ser habitual.

Como sabemos Twitter permite dos tipos de cuentas: las protegidas, cuyos tweets son accesibles sólo a las personas “autorizadas”, y las cuentas desprotegidas, cuyos tweets son accesibles a cualquier usuario. Dejando de lado que, tal y como sucede en otras redes sociales, un tweet “protegido” deja de serlo cuando un usuario sin la cuenta protegida lo “retuitea”, ¿qué ocurre con las cuentas de Twitter no protegidas? Éstas no sólo permiten a las personas seguir tu timeline sin necesidad de tu autorización (ie. hacerse “seguidores”), sino que además permite que cualquier usuario de Twitter, seguidor o no de tu timeline, pueda leer tus tweets. Es una ventana abierta pública a todo lo que escribimos. Esto tiene sus ventajas, pero también sus inconvenientes.

Para ver porqué esto puede ser en ciertos casos un problema, vamos a hacer uso de TweetDeck, uno de múltiples clientes que permiten añadir “columnas” según criterios de búsquedas e incluso el timeline de una persona, a la que no tenemos porqué “seguir” y que podemos por tanto “monitorizar” sin su conocimiento. Veamos un ejemplo:

¿Qué información comparte la gente por Twitter?

No es la primera vez, ni será la última, que los usuarios comparten información privada y en ocasiones confidencial a través de medios menos que óptimos. Esto da como resultado, como ya se ha visto a lo largo de otras entradas en este y otros blogs, que información que no debería ser a priori pública, esté al alcance de cualquier persona con un poco de curiosidad y/o maldad. Sólo hay que hacer una búsqueda con ciertas palabras clave e indagar en los tweets obtenidos.

¿7 años después?

No importa los años que lleve Twitter en marcha, los nuevos usuarios se registran y la mayoría de ellos, sin preocuparse en las opciones de seguridad/privacidad que nos ofrece esta red social (muy inferiores, desde luego, por su distinta naturaleza, al caso de Facebook), comienza a enviar Tweets públicamente. Unos comparten fotos (personales, de tarjetas de crédito/débito, comprometidas, etc.), mientras que otros usuarios más “atrevidos” comparten información sensible como su número de teléfono, su correo electrónico o incluso contraseñas. Eso, dejando de lado salidas de tono que a diario cometen personalidades, políticos, deportistas, etc. Aunque parecería que ante este tipo de cosas es suficiente con borrar el Tweet, sólo hay que pasarse, por ejemplo, por topsy y muchos de estos tweets públicos aunque hayan sido borrados todavía estarán cacheados, pudiéndose consultar perfectamente.

Conclusiones

A estas alturas huelga decir que falta concienciación entre muchos usuarios de las redes sociales, y Twitter no es una excepción. Es muy preocupante que los usuarios compartan información tan sensible entre sus contactos, sin ser conscientes de que cualquier persona puede leerlo. En general, el ego representado en el número de followers ha asumido como estándar una configuración abierta, donde un número relativamente bajo de usuarios tienen cuentas protegidas, a diferencia de otras redes sociales donde “parece” que empieza a existir una cierta comprensión de las implicaciones de una cuenta abierta. En este caso, cabe aplicar el sentido común y ser consciente de las implicaciones de nuestras publicaciones. En cualquier caso, siempre es útil rememorar que PLBKAC.

Lanzo una pregunta al aire, ya que muchos usuarios desconocen o no se preocupan por la privacidad: ¿debería establecerse por defecto la cuenta protegida?

(N.d.E. Dejemos aparte las implicaciones que esto tendría para la expansión de Twitter y su modelo de negocio)