Los sensores de movimiento son usados habitualmente en los móviles para determinar el comportamiento de la pantalla y programas según la posición y el movimiento del dispostivo físico. Consisten en acelerómetros, giroscopios y sensores de orientación. En principio, parece que esta información recopilada por el teléfono (velocidad, movimientos…) no puede llegar a ser relevante, y por eso actualmente no existe en Android ningún tipo de control de medida de seguridad sobre los datos que pueden ser obtenidos mediante estos métodos. Esto es lo que ha motivado la idea de crear un troyano basado en ellos. Además, en el caso de que este troyano fuese llevado a la práctica, los permisos requeridos a la hora de instalarse no levantarían apenas sospechas.

Es un montaje experimental, necesita cierto entrenamiento … Pero, ¿quién nos dice que no hay alguien dispuesto a ‘escucharnos’?

Si se puede programar, se puede comprometer. Si puede comprometerse alguien lo hará. Alguna prueba ya hay hecha por ahí:

The TV was connected by ethernet cable to a home network, so Auriemma thought it would be funny to use a computer connected to the same network to send it a message that contained a series of custom headers. Without warning, the TV spiraled into an endless loop of restarts. For about five seconds, the device would appear to work correctly, but then would stop responding to commands entered by remote control or through the panel. A few seconds later, the TV would restart and repeat the process. Unplugging the power cord or ethernet cable did nothing. Auriemma had just stumbled upon a crippling denial-of-service attack.

En Seguridad ‘hogareña’ recopilamos en su día enlaces sobre el tema.

Sigan vigilantes.

Cookies and other stored HTTP headers should be treated by developers as another form of user input and be subjected to the same validation routines.

Ya hablamos hace algún tiempo del tema de forma un poco más técnica, en:

Polución de parámetros del protocolo HTTP
PAPAS: ¿Somos vulnerables a la polución de parámetros HTTP?
Contaminación de parámetros Http
Contaminación de parámetros HTTP (HPP)

Vamos a hablar de un mini-proyecto que consiste en tener una Raspberry Pi conectada a la WiFi de casa y cómo controlarla desde el exterior (el trabajo, con un móvil, …) y aprovechar sus prestaciones.

Para ello, he estado preparando un pequeño montaje que tiene un sensor de temperatura, y además es capaz de hacer un par de cosas (pequeñas) más.

Para la parte del sensor seguí el tutorial que publicó Pablo Murillo en Tutorial Arduino # 0005 – Sensor de temperatura NTC:

En este proyecto vamos a aprender a implementar un sensor de temperatura a nuestros proyectos Arduino, en este proyecto simularemos cinco estados de aviso de exceso de temperatura, sobre los cuales los cuales podríamos conectar cualquier elemento que quisiéramos que actuara llegado dicho nivel, podríamos conectar circuitos de ventilación de manera que si no consiguieran mitigar el exceso de calor llegara un punto que desconectara el sistema que estemos monitorizando, en resumen, en cualquier lugar donde un control de exceso de temperatura sea necesario.

Como no tenemos un Arduino, sino que tenemos una Raspberry Pi, necesitamos algo que sirva para hablar con los sensores analógicos. En mi caso (por cercanía física y también por simpatía con el proyecto) lo que he utilizado es el Raspberry Pi to Arduino shields connection bridge de la gente de Cooking Hacks.
Con la biblioteca que proporcionan ellos, podemos utilizar las ideas (y los programas, casi tal cual) de los proyectos de Arduino en nuestra ‘raspi’ con bastante facilidad. Sirven los mismos esquemas de conexiones y todos los documentos disponibles para esta plataforma.

Una imagen del montaje:

.

Y un vídeo de la ‘cosa’ en acción.

Se pueden ver algunos elementos más (hay un sensor de luz que se ve a la derecha del de temperatura), pero básicamente allí está el proyecto propuesto por Pablo Murillo.

Aunque el tema de los LEDs es bastante llamativo (a mi me lo parece, siendo una persona más de programas que de cacharros) lo que más me atrae del cacharrito es que se trata de un ordenador completo.
Uno no se siente a gusto si no mete internet por enmedio y algo de interacción con el aparato.

Buscando un poco por ahí encontré el proyecto SleekXMPP que nos permitiría interactuar con nuestro ordenadorcito a través del protocolo XMPP. Este protocolo nos permite comunicarnos en tiempo real y ha sido utlizado, entre otras cosas, por algunos sistemas de mensajería instantánea (por ejemplo el GTalk de Google -aunque últimamente parece que podrían estar pensando en cambiar-, Jabber, …).

En los ejemplos del proyecto hay un ‘bot’ que repite las instrucciones que le envíamos y programé una modificación para poder preguntarle a la raspi sobre la temperatura de la habitación en la que se encontraba.

Podemos ver la interacción en este vídeo:

Pero el bot de ejemplo no está pensado para este tipo de comportamiento y necesitábamos alguna arquitectura que hiciera sencillo extender el proyecto, añadirle instrucciones e interactuar remotamente (¿la meta podría ser poder añadirle instrucciones por GTalk?) así que me puse a buscar.

El amigo Javier Candeira me sugirió probar phenny, que es un bot extensible, diseñado para recibir instrucciones remotamente y con solo una diferencia con mi proyecto inicial: está pensado para ser controlado desde una canal de IRC.

El proyecto se convierte (por ahora) en un bot de IRC que es capaz de proporcionarme información del entorno de la raspi que tengo en una estantería de mi casa.

Como primer paso, modifiqué el programa que había generado a partir del tutorial de Arduteka.
En lugar de encender más o menos luces, lo que quería era saber la temperatura así que lo que hace el programita es (además de encender las luces si se dan las condiciones adecuadas), escribir en la salida estándar el mensaje:

Temperatura:

seguido de la temperatura que se haya medido.
Para eso se toman medidas 5 veces con una separación de 0.5 segundos y después se calcula la media.

El código puede verse (y descargarse) en temperatura.cpp y se compila y ejecuta de la misma forma que en el tutorial antes referido.

Para invocar remotamente este programa entra en juego phenny.
Lo primero que hay que hacer es ejecutarlo, se generará un fichero de configuración (en ~/.phenny/default.py) que hay que editar para ponerle nuestro servidor de IRC favorito, canal y algunas cosillas más y ya lo tenemos listo para funcionar.
Por defecto viene ya con un buen montón de instrucciones que podemos probar.

Pero el proyecto sigue. Queremos añadir nuestras propias instrucciones y las elegidas han sido de momento tres:

• .temp: devuelve la temperatura que mide en ese momento el sensor instalado.
• .ip: devuelve la ip (interna) de la raspi, que se conecta a internet a través de un router WiFi hogareño normal y corriente.
• .ls: devuelve un listado de ficheros del directorio actual donde se haya ejecutado phenny.

El código de esta parte puede verse (y descargarse) de: testing.py y copio aquí un trozo de código de la primera de esas tres acciones para que cada uno se haga idea de lo fácil (o difícil) que es prepararlo.

def temp(phenny, input):
   arg='sudo /home/pi/usr/src/pruebas/temperatura'
   p=subprocess.Popen(arg,shell=True,stdout=subprocess.PIPE)
   data = p.communicate()
   split_data = data[0].split()
   tempC = split_data[0]
   my_ip = 'La temperatura es %s' % tempC

   phenny.say(input.nick + '!' + ' ' + my_ip)
temp.priority = 'high'
temp.commands = ['temp']

También puede verse en Código para llamar al programa que nos dice la temperatura.

Como puede verse, invocamos al programa (lo he puesto con el path completo) lanzando un proceso con Popen.
Le pedimos el resultado, lo procesamos y creamos una cadena de caracteres my_ip que luego le pasamos al bot para que la escriba en el canal de IRC.

Nótese que phenny permite asignarle un nombre (o varios) a la instrucción (temp.commands = ['temp']) y también asignarle una prioridad, que hemos puesto en los tres casos como alta (‘high’).

Una vez hecho esto podemos volver a lanzar phenny (en realidad el bot puede cargar nuevas instrucciones de manera dinámica pero eso no importa ahora) y responderá a las instrucciones que ya ‘conocía’ y a estas tres que acabamos de añadir.

Podemos verlo en acción en:

Como decía arriba, el uso del canal de IRC ha sido un hito intermedio:

Siempre podemos establecer expectativas más bajas para alcanzar los hitos.

— fernand0 (@fernand0) March 28, 2013

El objetivo ahora tiene varias líneas de avance:

• Modificar phenny para que también acepte instrucciones desde un cliente
  de mensajería instantánea.
• Añadir instrucciones a phenny (¿añadirle una webcam y poder ver una foto de la habitación desde nuestro teléfono móvil?, ¿descargar un documento cuya dirección le pasemos? ¿avisarnos si la temperatura alcanza determinados umbrales? …).
• Añadir/utilizar capacidades de administración para que algunas instrucciones sólo puedan ejecutarse por personas autorizadas
• …

Trataremos de seguir informando.
Si alguien ve mejoras a lo que ya hay publicado (las bondades del código existente son debidas a sus respectivos autores; los defectos me corresponden a mi) o necesita alguna aclaración no tiene más que decirlo.
También si alguien conoce otros proyectos que se puedan utilizar de forma similar o de los que obtener inspiración.

This article doesn’t attempt to suggest the addition of an until statement to Python. Although I think such a statement would make some code clearer, and this article displays how easy it is to add, I completely respect Python’s philosophy of minimalism. All I’m trying to do here, really, is gain some insight into the inner workings of Python.

Típicamente, cuando se copia y pega el código en un sistema se considera una mala práctica. Sin embargo, los autores consideran que hay que analizarlo mejor y ver cuando puede tener sentido y cuando no.

This paper describes several patterns of cloning that we have observed in our case studies and discusses the advantages and disadvantages associated with using them. We also examine through a case study the frequencies of these clones in two medium-sized open source software systems, the Apache web server and the Gnumeric spreadsheet application. In this study, we found that as many as 71% of the clones could be considered to have a positive impact on the maintainability of the software system.

Por ejemplo, podría aportar estabilidad en zonas ya probadas y que
funcinonan, mientras se experimenta en otras partes más novedosas:

There is no doubt that code cloning is sometimes an indication of sloppy design and in such cases should be considered to be a kind of development “bad smell” (Fowler et al. 1999). However, we have found that there are many instances where this is simply not the case. For example, cloning may be used to introduce experimental optimizations to core subsystems without negatively affecting the stability of the main code. Thus, a variety of concerns such as stability, code ownership, and design clarity need to be considered before any refactoring is attempted; a manager should try to understand the reason behind the duplication before deciding what action (if any) to take.
This paper introduces eleven cloning patterns that we have uncovered during
case studies on large software systems,…

Interesante.

Según nos cuentan se ha tratado de un ataque dirigido a algunos ingenieros de Facebook:

Rather than using typical targeted approaches like “spear phishing” with e-mails to individuals, the attackers used a “watering hole” attack—compromising the server of a popular mobile developer Web forum and using it to spring the zero-day Java exploit on site visitors.

“The attack was injected into the site’s HTML, so any engineer who visited the site and had Java enabled in their browser would have been affected,” Sullivan told Ars, “regardless of how patched their machine was.”

Esto es, aprovechar un fallo de Java en un sitio web que esperas que visiten tus víctimas y luego aprovechar para obtener otro tipo de ventajas.

Ya habíamos hablado en el pasado de ataques a medida:

Ataques a medida con hojas de cálculo.
Vigilancia en el Tíbet.

Actualización (2013/02/21): Ahora le ha pasado algo parecido a
Apple a través de un portal que visitarían sus desarrolladores y parece que
el fallo de Twitter de hace unos días también tenía que ver con lo mismo.
Lo cuentan en Java detrás de los ataques a Apple, Facebook y Twitter.

Recuerden: no visitar sitios ‘delicados’ con la máquina del trabajo.

In a talk at the Black Hat Europe security conference in Amsterdam later this week, security researcher and chief technology officer of bug-hunting firm Veracode Chris Wysopal plans to give a talk breaking down the company’s analysis of 9,910 software applications over the second half of 2010 and 2011, automatically scanning them for errors that a hacker can be use to compromise a website or a user’s PC. And one result of that analysis is that government software developers are allowing significantly more hackable security flaws to find their way into their code than their private industry counterparts.

E inmediatamente:

According to Veracode’s analysis across industry and government, fully
eight out of ten apps failed to fully live up to the company’s security
criteria. But breaking down the results between U.S. government and private
sector software, the government programs, 80% of which were built for
federal agencies rather than state or local, came out worse. Measuring its
collection of apps against the standards of the Open Web Application
Security Project or OWASP, Veracode found that only 16% of government web
applications were secure, compared with 24% of finance industry software
and 28% of commercial software. And using criteria of the security-focused
education group SANS to gauge offline applications, the study found that
18% of government apps passed, compared with 28% of finance industry apps
and 34% of commercial software.

Como casi siempre, el diablo está en los incentivos (quién hace qué, por qué y cuáles son sus motivaciones):

Those incentives have led to government bugs persisting even as the rest of the industry starts to clean up its act, says Veracode’s Wysopal. While SQL injection and cross-site scripting vulnerabilities have have dropped off in private industry over the last two years, they’ve remained statistically flat for governments.

A mi me recuerda los estudios aquellos sober las políticas de claves en los sitios web que comentamos en Contraseñas, usabilidad y uso: los sitios web gubernamentales eran los que tenían políticas más restrictivas, sin mucha evidencia de que eso mejorara la seguridad.