OWASP Top 10 2021

La versión 2021 del Top 10 de vulnerabilidades en aplicaciones web de OWASP ha sido liberada oficialmente.

Esta lista de vulnerabilidades es una referencia clave en la industria de seguridad informática y conlleva una actualización que es importante que conozcamos quienes estamos involucrados en ella.

Particularmente una de las cosas que llama la atención es la inclusión de una categoría denominada A02: Cryptographic Failures. Esta categoría incluye los debilidades ( CWE ) asociadas a fallas criptográficas ya sea por problemas en las configuraciones o en las implementaciones de la criptografía en las aplicaciones. Entre ellas destacan:

  • Debilidad en las contraseñas.
  • Intercambio de llaves criptográficas sin autenticación.
  • Nivel de entropía insuficiente.
  • Problemas en la generación de datos pseudoaleatorios.
  • Transmisión de información sensible en claro.
  • entre muchos otros.

… seguramente estaré platicando de algunas en el transcurso de los días.

La lista actualizada de vulnerabilidades quedó de la siguiente forma:

  • A01:2021-Broken Access Control
  • A02:2021-Cryptographic Failures
  • A03:2021-Injection
  • A04:2021-Insecure Design
  • A05:2021-Security Misconfiguration
  • A06:2021-Vulnerable and Outdated Components
  • A07:2021-Identification and Authentication Failures
  • A08:2021-Software and Data Integrity Failures
  • A09:2021-Security Logging and Monitoring Failures
  • A10:2021-Server-Side Request Forgery

El enlace oficial y toda la documentación la encuentran directamente en el portal de OWASP.org Top 10.

OpenSSL Cheat Sheet v1.2

OpenSSL reference by Alberto Gonzalez

A new version of the OpenSSL reference has been released.

Version 1.2

These are the changes:

  • Asymmetric encryption: Changes in how to export the public key to be consistent with the encryption command using RSA public key.
  • Asymmetric encryption: Encrypt a file using RSA public key.
  • Asymmetric encryption: Decryption of the previously encrypted file was included.
  • Symmetric encryption: Changes in the decryption of a file using another file as the key, instead of a password.
  • Digital Signatures: Signing a file using SHA-256 and RSA private key.
  • Digital Signatures: Verifying the signature previously generated using the RSA public key file.
  • Working with TLS protocol: Extract the domain certificate from an HTTPS/TLS connection.
  • Working with TLS protocol: nmap command: Display enabled cipher-suites over an HTTPS/TLS Connection.
  • Working with TLS protocol: nmap command: Display enabled cipher-suites over a TLS (HTTPS) Connection using SNI.

OpenSSL Cheat Sheet v1.1

I have released a new OpenSSL Cheat Sheet version. The version 1.1.

You can download the PDF here: https://albertx.mx/wp-content/uploads/2020/07/The-OpenSSL-Cheat-Sheet-v1.1.pdf

or access the online version, here: https://cheatography.com/albertx/cheat-sheets/openssl/

Release notes for version 1.1:

  • Inclusion of openssl command for generating random bytes specifying bytes of length for random data, in “Basics” section.
  • Added the command for displaying digital certificates information in Abstract Sintax Notation One, in “Digital Certificates” section.
  • Inclusion of command for generating a hash with its output in bytes, instead of hex encoding. This command is under “working with hashes” section.

Digital Certificates: new maximum lifetime of 398 days starting on September.

A friendly reminder just to make sure you are ready for the new lifetime on TLS digital certificates of a maximum of 398 days starting september this year.

What does it mean?

  • Every certificate issued by a public CA on or after September 1st, 2020, must have a maximum lifetime of 398 days to be trusted by web browsers.
  • The number of days will be taken from two attributes already present on all certificates: notBefore and notAfter.
  • All major browsers are preparing and releasing their new versions to support this change.

What are the benefits ?

  • The first benefit is in fact an increase on the security for web resources served under HTTPS decreasing the number of active days a cryptographic private key will have.
  • A second benefit is the one regarding crypto agility. A new fancy way to describe how prepared you are to change cryptographic algorithms, schemes or protocols when there is a major vulnerability which forces to deprecate rapidly any of them.

What impact could I have ?

  • If you already have valid Digital Certificates with an expiration date on September after September or even next year, you will have no impact on them, everything will continue to function as normal, but starting September 1st 2020, if you request a new certificate, renew or reissue an existing certificate, the new maximum expiration date will be of 398 days beginning on the day the certificate is issued (or reissued). So you will not be able to have a valid certificate for 18 months or 2-3 years as before when the validation period starts on of after September.
  • If for any reason a public CA issues a certificate with an expiration date of more than 398 days and you install it on your servers, all users or customers will receive an error saying the website is not secure and there is an error trying to access the website. Similar to when you are trying to access a website with a self-signed certificate installed or with a different common name in it.

A few official links:

TLS Server Certificate Management NIST Publication

Yesterday The National Institute of Standards and Technology released a new Special Publication ( SP 1800 – 16 ), guideline style, addressing security best practices and recommendations for managing almost everything around TLS and digital certificates.

This extraordinary guideline was written in collaboration with Digicert, Venafi, Thales, F5, MITRE, Symantec. All of them well known technology and security companies around the world.

The document has 4 different parts:

  1. An Executive Summary
  2. Security Risks and Recommended Best Practices
  3. Approach, Architecture and Security Characteristics
  4. How-to Guides.

This is a must for the administration of large-scale TLS server certificates, how to establish a formal TLS certificate management program and it also enumerates all elements that should be considered for inclusion in such a program.

It addresses some specific challenges like: The automatic renewal of digital certificates in production environments, working with DevOps and TLS certificates, implementing an architecture to be protected of attacks hidden in TLS connection tunnels, recommendations for key-lenght, signing algorithms, validity periods in digital certificates, recommendation for crypto-agility (a very popular topic in cryptography these days) and much more.

You can download the complete document directly from its site:


OpenSSL Cheat Sheet v1.0.5

Today I released the 1.0.5 version of the OpenSSL Cheat Sheet.

Change Control:

  • New additions:
    • Added the Java keytool command to generate Java Key Store files in PERSONAL SECURITY ENVIRONMENTS section.
    • Added two commands to generate CSR files using Elliptic Curve keys instead of RSA keys in DIGITAL CERTIFICATES section.
    • Added the command to generate a CSR file using an existing private key file. Useful when you need to renew your certificate but preserve the private key. DIGITAL CERTIFICATES section.
  • Corrections:
    • A few typo corrections in DIGITAL SIGNATURES.

You can download the PDF version here or access the online version.

The new OpenSSL Cheat Sheet

Enjoy this openssl cheatsheet to apply in symmectric and asymmetric encryption, digital signatures and certificates, create your own CA, sign files, use hashes.

Feel free to post any comments or recommendations for a future version.

You can download the latest PDF version from the website or by clicking here.

openssl cheatsheet

New iPhone biometric control (Touch ID) and its "vulnerabilities"

Touch ID
Recently Apple added the Touch ID Sensor to the new iPhone device. It is a biometric control that claimed to be pretty secure, after all it’s a biometric control. Biometrics are usually harder to break than other types of mechanisms and they are harder not just because how they are implemented but because of the difficulty in acquiring the required material to spoof it. In a recent post by The Hacher News (http://thehackernews.com/2013/09/finally-iphones-fingerprint-scanner.html) a group of infosec specialist found a way to fool the biometric control giving it a fake fingerprint (watch the video). While this is not actually hacking the system but it’s a way to unlock the device.

I am sure there will be more post and news doing the same thing. Even that’s one of the first things I think when I saw the new feature. There are a lot of ways to fake fingerprints: jelly, glue, stickers and more. I prefer glue it’s the easiest way and if you use a fake fingerprint to bypass a biometric mechanism you are not actually hacking the system. The security of these controls is based, as I previously said, on the difficulty in acquiring the real fingerprint. Sure, you are leaving your fingerprints everywhere in everything you touch but getting a good one that could work can be really hard.

To hack the system you would have to give the system another fingerprint and force the system to authenticate with that fingerprint. Because it is a very difficult process it is usually easier to obtain the victim fingerprint.

Would you trust in the Touch ID security system ?

PassMark en la banca por Internet de Santander

Recientemente Santander comenzó a liberar una actualización en su banca por Internet llamada Supernet. La actualización se enfoca específicamente en el modelo de seguridad que utiliza para proporcionar acceso a los usuarios a su cuenta. De qué trata este nuevo modelo de seguridad? Originalmente con las credenciales fortalecidas que nos solicitan ahora los bancos para acceder a nuestras cuentas + los tokens que nos proporcionan para teclear el número que nos arroja + algún número de cuenta, número de cliente, num de tarjeta, etc etc etc, lo que los bancos quieren lograr es garantizar que el usuario correcto, en este caso nosotros, estamos accediendo a nuestra cuenta y no que cualquier otra persona, un hacker por ejemplo, pueda acceder a nuestra cuenta, es decir, esos mecanismos garantizan hasta cierto punto que el cliente o usuario es quien dice ser. Pero, quien nos garantiza a nosotros que la aplicación es a la que realmente queremos acceder ? No por el hecho de que en nuestra barra de direcciones aparezca el dominio completo y correcto de la aplicación implica que es la aplicación real del banco. Existen ataques como el pharming o algunos tipos de Man In the Middle que podrían falsificar la aplicación y enviarla al usuario aparentando ser la aplicación real cuando realmente es otra preparada específicamente para obtener nuestros datos confidenciales. Bueno, esa actualización de seguridad que se liberó es precisamente para garantizar, hasta cierto punto, eso.

Este método de seguridad surgió hace ya varios años e irónicamente se supuso que no iba a dar los resultados esperados ya que tiende a ser muy sencillo (sin tanta criptografía o mecanismos complejos de por medio). Se le llamó PassMark y poco a poco las instituciones bancarias lo fueron adoptando hasta ahora llegar a México.
Continue reading PassMark en la banca por Internet de Santander

The Google Chrome Netbooks security

Recently Google announced its Google Chrome netbooks aka Chromebooks. They have great features like 3G support, boot time of seconds, automatic updates, review of core files integrity on every boot and more. With all these new functionalities on netbooks the security is extremely important because they have no experience with this set of technologies and they don’t know how people will take these changes and how “hackers” will take this new challenge.

Let’s review some of the security concepts and possible cons within the Chromebook.
Continue reading The Google Chrome Netbooks security