Coches y ataques

Ya hemos hablado en vidas anteriores de la seguridad y los coches: es el caso típico de una cierta configuración, pensada en un contexto que de pronto (o poco a poco) cambia sin adaptarse a los nuevos riesgos. Esta vez traemos un artículo generalista de divulgación, Car hackers mess with speedos, odometers, alarms and locks.

Control

Por ejemplo, acceso a la red de comunicación interna:

… they gained access to the CAN and began fuzzing against to identitfy which of the arbitration ID packets were sent to particular components of the vehicle such as the speedometre, brakes and dashboard indicators.

Incluso poniendo a disposición de otros una herramienta:

The trio were keen for others to enter the hacking field and have produced a $25 open-modular source hardware tool for reading CANs that has the capability of those worth tens of thousands.

Como decía, hemos hablado más veces de este tipo de ataques a coches:

¿Pueden atacar tu coche?

Más ataques a coches

Seguridad ‘hogareña’

El coche, el mp3 y cosas malas que pueden suceder

Ataques a los sistemas de arranque sin llave en coches

Los sistemas de inmovilización de coches no funcionan bien

Las optimizaciones del compilador y la seguridad

Un compilador no sólo genera código ejecutable a partir de nuestros programas escritos en un lenguaje de alto nivel. Tradicionalmente los compiladores han tratado de mejorar el código desarrollado por los programadores para hacerlo más eficiente (sacando partido de las características de la arquitectura en la que se va a ejecutar, los mecanimos de los procesaores, sus recursos…).

Letras en la terminal

Compilers are great at taking your hand crafted human-readable program, translating it into machine code and, in the process, optimizing it so it runs as efficiently as possible

Los investigadores del MIT Xi Wang, Nickolai Zeldovich, M. Frans Kaashoek y Armando Solar-Lezama han presentado un artículo donde se evalúan las consecuencias de seguridad que puede tener la eliminación de código que puede hacer el compilador por ser considerado innecesario.

… research from MIT points out, in their zeal to optimize your code, compilers can go too far and remove code that they shouldn’t, which can make the system or application more vulnerable.

También han desarrollado una herramienta, que nos avisará del código que es susceptible de tener este tipo de problemas, para que lo podamos arreglar:

The good news is the researchers have developed a model and a static checker for identifying unstable code. Their checker is called STACK, and it currently works for checking C/C++ code. The idea is that it will warn programmers about unstable code in their applications, so they can fix it, rather than have the compiler simply leave it out. They also hope it will encourage compiler writers to rethink how they can optimize code in more secure ways.

En Dude, where’s my code? se pueden ver más ideas y algún ejemplo:

A classic example, explains Xi Wang, a graduate student in EECS and first author on the new paper, is the assumption that if a program attempts to store too large a number at a memory location reserved for an integer, the computer will lop off the bits that don’t fit. “In machines, integers have a limit,” Wang says. “Whenever you exceed that limit, the input value basically wraps around to a smaller value.”

Seasoned C programmers will actually exploit this behavior to verify that program inputs don’t exceed some threshold. Rather than writing a line of code that, say, compares the sum of two numbers to the known threshold for an integer (“if a > int_max - b”), they’ll check to see whether the sum of the numbers is smaller than one of the addends (“if a + b < a”) — whether, that is, the summation causes the integer to wrap around to a smaller value.

Presentación de RSA en Scientific American

En Martin Gardner, RSA y otros pasatiempos matemáticos cuentan una historia sobre la presentación de RSA en la revista Scientific American (traducida como Investigación y Ciencia por aquí). El matemático martin Gardner tenía una columna sobre pasatiempos matemáticos y en agosto de 1977 presentaba los fundamentos de RSA con un reto a los lectores sobre la factorización de números primos, que es una historia que a veces contamos en clase cuando hablamos de la parte algorítmica de estas cosas.

El desafío consistía en factorizar la clave pública en sus dos factores y emplearlos para descifrar el mensaje. El texto llano es una frase inglesa convertida en un número mediante el procedimiento habitual (a=0, b=1…) elevado a 9007 módulo r. Rivest estimaba que usando el mejor algoritmo de factorización conocido y el más rápido de los ordenadores disponibles (del año 77) serían necesario del orden de 40 cuatrillones de años para resolver el reto.

La cosa tiene su gracia porque, al final, el desafío se resolvió 17 años después (utilizando, eso sí) 600 voluntarios con alrededor de 1600 máquinas calculando durante seis meses.

Puede leerse gratis el principio del artículo traducido en Comunicaciones secretas y el artículo original escaneado en A new kind of cipher that would take millions of years to break.

Buena lectura para estos días de navidad.

Consejos para almacenar las claves

En Do any security experts recommend bcrypt for password storage? y, en particular, en la primera respuesta un buen texto sobre el almacenamiento de claves y los algoritmos adecuados para hacerlo. Se discute sobre Bcrypt y PBKDF2 y se comenta sobre alguno más.

Para este tipo de almacenamiento hoy en día hay que tener en cuenta ataques bastante esotéricos con GPU (procesadores gráficos) y FPGA como herramientas de cálculo masivo de manera muy eficiente. Los nuevos algoritmos tienen que tener en cuenta no sólo la velocidad de cálculo, sino también la cantidad de RAM utilizada y otros parámetros.

Se puede completar la lectura con The Theory que es un enlace directo a la primera respuesta de otra pregunta sobre el tema, con un análisis de las necesidades actuales, ventajas en inconvenientes de las principales soluciones…

La conclusión, en este caso es:

Use bcrypt. PBKDF2 is not bad either. If you use scrypt you will be a “slightly early adopter” with the risks that are implied by this expression; but it would be a good move for scientific progress (“crash dummy” is a very honourable profession)

Que es bastante parecida a la del artículo anterior.

Inyección de SQL basada en la evaluación de enteros en expresiones anidadas

En Exploiting Integer Based SQL Injection in Nested SQL Queries una demostración más de que las cosas que pueden ir mal se encuentran en cualuquier parte.

En este caso se trata de una pregunta SQL anidada que evalúa los parmámetros enteros que se le pasan como parámetro. Y también, cuando evaluamos otras cosas que el sistema de gestión de bases de datos sabe evaluar. Es un proceso bastante manual, claro, pero en los casos en los que no se hace validación de los datos puede permitir conocer cosas sobre la base de datos que no debería.