Saber lo que tecleas por como mueves el dispositivo

Eso nos contaban en Nuevo keylogger para Android basado en el movimiento del teléfono .

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’?

Una botnet de televisores

Otra más para el tema de cacharritos programables que nos pueden causar problemas: TV-based botnets? DoS attacks on your fridge? More plausible than you think.

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.

Inyección de SQL a través de cabeceras HTTP

Todo lo que viene del exterior es (potencialmente) inseguro. En SQL Injection through HTTP Headers nos recuerdan que las cabeceras del protocolo HTTP las proporciona el visitante y que pueden venir con ‘regalos’:

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)

Integración de la seguridad en el ciclo de desarrollo

En [PDF] Integrating Software Security Into The. Software Development Lifecycle un artículo con ideas generales sobre el tema. Puede ser valioso para ordenar ideas o como introducción preliminar donde no se haya pensado mucho aún en estas cosas.

Datos sensibles en nuestros programas

Un sistema informático moderno es una pesadilla desde el punto de vista de dónde están realmente nuestros datos (cachés, swaps, páginas, memorias, discos …). Por eso conviene recordarlo: de cara a que nuestros datos sensibles estén el menor tiempo posible por ahí en claro; y también por tratar de evitar mediante las facilidades que tengamos disponibles que esos datos terminen escritos donde no conventa. De eso hablaban en

Ataques dirigidos: el caso de Facebook

Rompemos varias costumbres de esta bitácora (además de la de volver a publicar, hacerlo varias veces la misma semana) hablando de algo de bastante actualidad: en Facebook computers compromised by zero-day Java exploit.

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.

Prevención de problemas con las sesiones en Java

En Session Fixation Prevention in Java algunas pistas sobre el tema: el atacante obtiene un identificador de sesión válido, hace que nosotros lo utilicemos y consigue acceso a nuestra cuenta.

Para evitarlo:

1. Recibir las credenciales del usuario
2. Autentificarlo
3. La información de sesión necesaria se copia
4. Se invalida la sesión
5. Se crea una nueva
6. Se recuperan los datos temporales
7. Seguir…

Se pueden hacer más cosas y hay código de ejemplo. Interesante.

Por cierto, la primera semana del año de seguridad en Java que nombrábamos el otro día hablaba era justamente esta entrada, se puede ver también en Year Of Security for Java – Week 1 – Session Fixation Prevention.

Lo que no te enseñarán sobre el enemigo

El título sería más largo pero creo que la idea está clara. En What They Don’t Teach You in “Thinking Like the Enemy” Classes hablan de ese estilo de aprender seguridad basado en pensar como lo haría un atacante, a cargo de Peter Herzog.

Me llamó la atención:

El valor de nuestros conocimientos es relativo:

For a little perspective on how hard it is to value something the same as someone else, how often have you been asked by a friend or neighbor to check out their computer because they think it’s infected. They say, “Come on, it’ll just take you ten minutes and I’ll buy you a drink.” But what they don’t realize is that it actually took you at least ten years to be able to analyze and diagnose the problem in “just ten minutes” and no drink will compensate you for ten years and ten minutes worth of work. So if even your friends and neighbors can’t extend their reasoning into how much effort it took you to do what you can do, why it’s more valuable than a drink, then maybe you can consider it’s just as hard for you to extend yours to think about what the enemy values and the amount of effort they will make?

Y la forma correcta de abordar el problema: no pienses como un ‘malo’, sigue buenas prácticas preventivas:

You can also see that in some cases, we are exploited in many ways by ourselves the same way the enemy exploits us. We have seen the enemy and they are us! Dun DUN dun! So think about that the next time you want to assess your security the old fashioned way (in movies) to use a thief to catch a thief. Or a psycho to catch a psycho. Or a… never mind, you get the idea. Your best recourse is stop trying to guess what the attacker is going to do next and practice good preventative security. But you can find the details from this in Chapter 14 of the OSSTMM 3:

1. Make separations between your assets and what shouldn’t be interacting with them.
2. Lock down and control those interactions which are allowed.
3. Actively manage all trusts.

El año de seguridad en Java

John Melton comenzó a principios de este año su serie sobre seguridad para Java. Aunque los ejemplos son con este lenguaje, lo cierto es que casi siempre la prsentación es suficientemente general como para aprender/recordar algunas cosas aunque Java no sea nuestro lenguaje favorito. Comenzó con Year Of Security for Java – Introduction y lleva hasta ahora más de cuarenta entradas, todas muy interesantes.

Por poner una pega, no hay un índice. La búsqueda por Java Security en el blog debería ayudar.

Considero su lectura muy recomendable para cualquier persona interesada en estos temas, como recordatorio, temas en los que no habíamos pensado tanto …

Actualización: la serie ha terminado y pueden verse todos los enlaces en

Year Of Security for Java – Conclusion and Links y también descargar un pdf con todo, tal y como se anuncia en Year of Security for Java – PDF

Las claves como cadenas de caracteres

Un ordenador es una máquina muy compleja. Por sus propias características electrónicas, pero también por las capas que lleva encima: sistema operativo, programas y más…
En Don’t use Strings to hold Passwords! un recordatorio de cómo trata Java las cadenas de caracteres:

The essence of it is that strings in Java (and also in C#) are immutable. When you modify them it creates a new copy leaving the old one behind until garbage collected.

Eso sin contar que el Sistema Operativo puede decidir hacer ‘swapping’ y que estas claves terminen escritas en el disco duro.

Hace referencia Why is char[] preferred over String for passwords?.