Un texto interesante en Software defense: mitigating common exploitation techniques sobre diversas técnicas que los sistemas Windows ofrecen para proteger nuestros programas frente a ciertos ataques comunes, en particular relacionadas con la gestión de la memoria y dificultar a un atacante la posibilida de encontrar los datos en lugares predecibles.

De la misma serie también se pueden leer:

• Software Defense: mitigating stack corruption vulnerabilties
• Software Defense: mitigating heap corruption vulnerabilities
• Software defense: safe unlinking and reference count hardening

La criptografía es de mis temas ‘menos’ favoritos en seguridad. Siempre nos avisan de que es algo difícil de hacer bien. Por lo tanto nos relega al papel de meros consumidores, eso sí, tratando de estar al día en los tamaños de claves, algoritmos criptográficos y esas cuestiones.

En A (relatively easy to understand) primer on elliptic curve cryptography se publicaba hace algunos meses justamente lo que dice el título: una introducción a la criptografía de curvas elípticas que puede servirnos como introducción para recordar/ponernos al día en este tema.

Empiezan hablando de RSA y las propiedades que lo hacen interesante (la factorización es costosa -lenta- y la multiplicación es rápida).

The RSA algorithm is the most popular and best understood public key cryptography system. Its security relies on the fact that factoring is slow and multiplication is fast. What follows is a quick walk-through of what a small RSA system looks like and how it works.

Incluso muestran un pequeño ejemplo:

Let’s make this more concrete with an example. Take the prime numbers 13 and 7. Their product gives us our maximum value of 91. Let’s take our public encryption key to be the number 5. Then using the fact that we know 7 and 13 are the factors of 91 and applying an algorithm called the Extended Euclidean Algorithm, we get that the private key is the number >29.

Y sigue…

Luego, entra más a fondo en la criptografía de curvas elípticas:

An elliptic curve cryptosystem can be defined by picking a prime number as a maximum, a curve equation, and a public point on the curve. A private key is a number priv, and a public key is the public point dotted with itself priv times. Computing the private key from the public key in this kind of cryptosystem is called the elliptic curve discrete logarithm function. This turns out to be the trapdoor function we were looking for.

Interesante.

Ya habíamos hablado de ataques dirigidos a personas concretas (por ejemplo: Ataques dirigidos: el caso de Facebook).

En Sharking: High-Rollers in the Crosshairs contaban el caso de un ataque a un jugador profesional de póquer. En su hotel de Barcelona le robaron el portátil y lo infectaron con un troyano que les permitía ver las jugadas cuando se conectaba a sitios de juego en línea. En este caso el ataque dirigido consiste en un robo físico, aprovechando la presencia en un hotel y que el propietario no tomó precauciones al salir de la habitación.

Aunque sólo se trata de una hipotética conversación entre un desarrollador y el experto en seguridad Troy Hunt podemos leer en Introducing the “Secure Account Management Fundamentals” course on Pluralsight un resumen de bastantes de las cuestiones que hay que tener en cuenta a la hora de desarrollar o poner en funcionamiento un sistema de gestión de cuentas para nuestra aplicación web, algunas bastante sutiles.

Avisos, almacenamiento de las contraseñas, recuperación de las mismas, correos de registro, reputación, sesiones, bloqueo ante ataques, cambios,…

En clase solemos decir que parece más fácil de lo que realmente resulta ser al final.

Una de las cosas que nos gustó ver cuando nació PCI Data Security Standards fue su atención al desarrollo seguro de programas. En particular el punto 6 y algunos otros inciden en ese tema. En 2013 se anunció la versión 3.0 y este año debería ser la transición de la versión 2.0 que sigue vigente a la nueva.

Nada más salir, en 2013 PCI Standards se comentaban los cambios y novedades del estándar en el punto relativo al desarrollo de programas.

There is plenty of discussion elsewhere about the new standards, so I thought I would focus on the PCI DSS changes in Requirement 6 (Develop and Maintain Secure Systems and Applications):

• 6.1 & 6.2 Switched the order of requirements 6.1 and 6.2. Requirement 6.1 is now for identifying and risk ranking new vulnerabilities and 6.2 is for patching critical vulnerabilities. Clarified how risk ranking process (6.1) aligns with patching process (6.2) and also clarified that the latter applies to “applicable” patches.
• 6.3 Added a note to clarify that the requirement for written software development processes applies to all internally- developed software and bespoke software, and now mentions “industry standards” as well as “industry best practice”.
• 6.3.1 Added “development/test accounts” to “custom accounts” to clarify intent of requirement
• 6.4 & 6.4.1-6.4.4 Enhanced, more specific, testing procedures to include document reviews for all requirements.
• 6.4.1 Aligned language between requirement and testing procedures to clarify that separation of production/ development environments is enforced with access controls.
• 6.5 Updated developer training to include how to avoid common coding vulnerabilities, and to understand how sensitive data is handled in memory.
• 6.5.x Updated requirements to reflect current and emerging coding vulnerabilities and secure coding guidelines. Updated testing procedures to clarify how the coding techniques address the vulnerabilities.
• 6.5.10 New requirement for coding practices to protect against broken authentication and session management.
• 6.6 Increased flexibility by specifying automated technical solution that detects and prevents web-based attacks rather than “web-application firewall.” Added note to clarify that this assessment is not the same as vulnerability scans required at 11.2.

Se puede descargar de la Sección de documentos de la web de PCI.