PCI y desarrollo seguro

Donde vive el dinero

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.

Extraer enlaces de una página web

Enlaces en Página de Facebook

Hace algunas semanas hablábamos de Publicar en Twitter las entradas de este sitio usando Python y prometíamos hacer lo mismo con Facebook.

Echando un vistazo al API de Facebook y haciendo algunas pruebas me encontré con que no podía publicar enlaces con su texto (Facebook los transforma para que podamos pinchar en ellos, pero no permite -o no encontré la forma- que los pongamos con su texto y esas cosas). Por otro lado, quería experimentar con la posibilidad de publicar las entradas de esta bitácora completas allí; Facebook no favorece que introduzcamos textos largos porque nos muestra un trocito y permite abrir ‘el resto’.

Siempre me ha llamado la atención la ‘netiqueta’ de algunas listas de correo donde suele ponerse al lado del texto de los enlaces un número y al final del mensaje la lista de esos enlaces, cada uno asociado al número correspondiente.

Esto fue lo que decidí hacer para publicar en la página de Facebook de fernand0.github.io (y otras, claro). El programa que traemos hoy hace justamente eso, como paso previo a la publicación en la página de Facebook (y, tal vez, ¿para poder enviar las entradas por correo a los interesados?).

El programa puede verse en rssToLinks.py (apuntamos, como siempre, la versión actual por si hubiera cambios en algún momento).

Algunas formas de extraer los enlaces serían: buscarlos con expresiones regulares, o también con algún parser de HTML (en el Blogómetro hace años utilizábamos el Simple SGML parser. Buscando un poco encontré el proyecto Beautiful Soup que presume de ser una manera rápida de recorrer el contenido de una página web y decidí darle una oportunidad.

Para utilizarlo incluímos los módulos necesarios. Para obtener el contenido utilizamos la fuente RSS, así que también necesitaremos feedparser:

import feedparser
from bs4 import BeautifulSoup
from bs4 import NavigableString
from bs4 import Tag

Leemos la fuente RSS y vamos recorriendo las entradas:

feed = feedparser.parse(url)

for i in range(len(feed.entries)):

Y empieza la ‘magia’ de Beautiful Soup:

        soup = BeautifulSoup(feed.entries[i].summary)
        links = soup("a")

Esto es, le pasamos los datos al analizador, y lanzamos la pregunta de lo que queremos extraer. En este caso tenemos una entrada en el summary y queremos obtener los enlaces (etiqueta a) para la entrada que ocupa la posición i. Nos devolverá una lista de elementos html que incluyen dicha etiqueta.

En algunas entradas ponemos imágenes, que no queremos que aparezcan en el texto, así que utilizamos isinstance para comprobar si dentro del contenido del enlace hay otra etiqueta para evitarla (¿es posible que encontremos algún caso más adelante que sea problemático?). Recorremos la lista de enlaces (que vienen con las etiquetas y todo, claro). Ademas utilizamos el contador j para ir asociándoles números a los sucesivos enlaces (en el HTML original, todavía no lo hemos eliminado):

	j = 0
	linksTxt = ""
	for link in links:
		if not isinstance(link.contents[0], Tag):
			# We want to avoid embdeded tags (mainly <img ... )
			link.append(" ["+str(j)+"]")
			j =  j + 1

El contenido del enlace (ahora que ya sabemos que no es una etiqueta HTML) estará en link.contents[0] (puede haber más contenido, nuestros enlaces suelen ser ‘sencillos’).

	linksTxt = linksTxt + "["+str(j)+"] " + link.contents[0] + "\n"

El enlace está en link['href'].

	linksTxt = linksTxt + "    " + link['href'] + "\n"

Ahora necesitamos el texto del HTML:

	print soup.get_text()

En algunos casos el texto puede tener muchos saltos de línea, espacios, … Se podrían eliminar. Nuestras entradas suelen estar bien estructuradas y no aparece ese problema.

Ahora, si había algún enlace (¿publicaremos alguna vez una entrada sin ningún enlace?), lo añadimos al final:

	if linksTxt != "":
		print
		print "Links :"
		print linksTxt

Números aleatorios seguros en Java

Azar

El tema de los números aleatorios de calidad para aplicaciones con requerimientos de seguridad no aparece habitualmente más que en los comentarios más técnicos. En Proper use of Java’s SecureRandom hay un texto donde se comenta el uso del generador de números seudo aleatorios seguro de Java.

When generating random numbers in Java for cryptographic purposes, many developers often use the java.security.SecureRandom class. And while the java.security.SecureRandom class is designed to generate cryptographically secure random numbers, there are a few subtleties in the API, and if it is used improperly the output can become predictable. At Cigital we have witnessed a number of cases where this is true. The following is a guide to the proper use of Java’s java.security.SecureRandom class.

Los consejos:

  • Always specify the exact PRNG and provider that you wish to use. If you just use the default PRNG, you may end up with different PRNGs on different installations of your application that may need to be called differently in order to work properly. Using the following code to get a PRNG instance is appropriate: SecureRandom sr = SecureRandom.getInstance(“SHA1PRNG”, “SUN”);
  • When using the SHA1PRNG, always call java.security.SecureRandom.nextBytes(byte[]) immediately after creating a new instance of the PRNG. This will force the PRNG to seed itself securely. If for testing purposes, you need predictable output, ignoring this rule and seeding the PRNG with hard-coded/predictable values may be appropriate.
  • Use at least JRE 1.4.1 on Windows and at least JRE 1.4.2 on Solaris and Linux. Earlier versions do not seed the SHA1PRNG securely.
  • Periodically reseed your PRNG as observing a large amount of PRNG output generated using one seed may allow the attacker to determine the seed and thus predict all future outputs.

Esto es, especificar el generador que se va a utilizar explícitamente (para evitar terminar utilizando diferentes generadores en diferentes configuraciones e instalaciones); cuidado con que la incialización se haga de manera correcta (e imprendecible); las versiones recomendadas eran en aquel momento JRE 1.4.1 para Windows y JRE 1.4.2 para Solaris y Linux por lo menos; reinicializar la semilla del PRNG para reducir la utilidad de la información generada.

El otro día hablábamos del Generador de números aleatorios de Intel y allí se pueden encontrar un par de enlaces más sobre el tema.

Una introducción a la autentificación basada en riesgos

Acciones posibles en Facebook

La autentificación parece ser el gran problema de los últimos tiempos: elegimos malas contraseñas, picamos con facilidad en muchos sitios que nos engañan para que las divulguemos ….

Las soluciones tecnológicas existen, y se pueden utilizar: pero en muchas ocasiones estaremos consiguiendo molestar a nuestros usuarios, que reutilicen contraseñas o que hagan todo lo posible para no seguir nuestras directrices (o peor: irse con la competencia).

Por eso me gustó Risk-based Authentication: A Primer donde se introduce la idea de mezclar la autentificación con una estimación del riesgo (que es, por otra parte, lo que creo que están haciendo últimamente muchos sistemas de uso masivo): se asocia a la sesión una ‘puntuación’ que determina si nuestros parámtros son ‘normales’.

Esto es, mira la localización geográfica, datos de conexión, pautas de comportamiento… Se trata, en definitiva, de ver si todo parece razonable o hay algo que no se ajusta a lo habitual y en caso de que haya motivos para desconfiar se toman medidas adicionales:

If the risk score for a user’s access attempt exceeds the system’s risk threshold, authentication controls are automatically elevated, and the user may be required to provide a higher level of authentication, such as a PIN or token. If the risk score is too high, it may be rejected outright.

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.

Cuidado con la gestión de nombres

Dar un curso de desarrollo seguro (y de seguridad en general) es bastante ‘agradecido’ desde el punto de vista de encontrar ejemplos, porque la actualidad siempre nos trae sorpresas.

Estábamos hablando en clase sobre los problemas de los nombres y de tomar decisiones sobre ellos y justo aparece el fallo en git: Vulnerability announced: update your Git clients

The vulnerability concerns Git and Git-compatible clients that access Git repositories in a case-insensitive or case-normalizing filesystem. An attacker can craft a malicious Git tree that will cause Git to overwrite its own .git/config file when cloning or checking out a repository, leading to arbitrary command execution in the client machine. Git clients running on OS X (HFS+) or any version of Microsoft Windows (NTFS, FAT) are exploitable through this vulnerability. Linux clients are not affected if they run in a case-sensitive filesystem.

La negrita la he puesto yo.

Se puede leer también el anuncio en la lista de desarrollo de git, [ANNOUNCE] Git v2.2.1 (and updates to older maintenance tracks) y Git 1.8.5.6, 1.9.5, 2.0.5, 2.1.4 and 2.2.1 and thanking friends in Mercurial land.

Si nos interesa ver el código, al menos a una parte, podemos echarle un vistazo a path: add is_ntfs_dotgit() helper, donde hablan de:

On NTFS (and FAT32), there exist so-called “short names” for backwards-compatibility: 8.3 compliant names that refer to the same files as their long names. As “.git” is not an 8.3 compliant name, a short name is generated automatically, typically “git~1”

Y también a: read-cache: optionally disallow HFS+ .git variants donde se ven las invocaciones a la función añadida y alguna cosa más.

Esta entrada se ha publicado orginalmente en Cuidado con la gestión de nombres.