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.
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.
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:
An Executive Summary
Security Risks and Recommended Best Practices
Approach, Architecture and Security Characteristics
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:
There are many new technologies, controls, mechanisms, modules, libraries for protecting and securing assets and information. Usually these new technologies were created and developed by people with good skills in the field, however, one of the main problems is the implementation phase.
Believe it or not, most of the vulnerabilities, either published or zero-day, exist because of a bad or terrible implementation of something that is secure in escense.
Think about cryptography. In general, cryptographic standard algorithms are approved and validated by many cryptographers around the world but when it comes the implementation phase, the standard or algorithm is implemented by a group of peole working at the same company or sometimes by only one developer with limited training in security and/or cryptography.
One of these examples is WEP Security Protocol for Wireless communications. It has different vulnerabilities but particularly the vulnerability of the key stream is a consequence of a weakness in the implementation of the RC4 stream cipher, not the RC4 algorithm by itself.
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.
On Internet, when protecting sensitive data, in transit you must use the security protocols you’ve heard of, like HTTPS, SSH, SFTP, FTP/S, TLS, VPN, IPSec and more, however, using only these protocols is not enough when following methodologies like “defense at depth”, where you need more security layers to tackle most of the threats and risks regarding data exposure when sending or receiving data.
In this post I will talk about recommendations you can follow to increase the level of security of critical and sensitive data while transmiting data anywhere, from internal networks to public or insecure networks.
Desde hace un par de años al día de hoy ha habido una fuerte apoyo de parte de las grandes empresas de tecnología para la adopción de HTTPS por todo Internet. Google, Microsoft, Mozilla, Cloudflare, Akamai, entre muchas otras, han decidido habilitar el protocolo para sus clientes o facilitar el acceso a este protocolo, sin embargo como profesionales en seguridad es necesario estar atento a cualquier cambio fuerte de cualquier índole, no nada más tecnológico. Sabemos que cualquier cambio, tendencia, adopción masiva, situaciones insólitas, etc. pueden potencialmente ser un foco de infección o punto compromiso para los sistemas informáticos y la rápida adopción de HTTPS no ha sido la excepción a esta regla.
Algo que he estado viendo en la red es el incremento de ataques a aplicaciones web utilizando HTTPS como transporte para el ataque, lo cual es, hasta cierto punto, obvio ya que los mismos atacantes están cifrando los comandos o exploits por HTTP bajo el protocolo TLS que evita que el ataque sea visualizado durante el transporte y, peor aún, si la entidad atacada tiene mal configurada su infraestructura de seguridad, este ataque también será invisible a sus herramientas de seguridad.
Un caso muy común es cuando herramientas como UTMs, NGFWs, WAFs o cualquier otra herramienta con protección a nivel aplicación web es instalada y los ingenieros desean visualizar HTTPS y proteger las aplicaciones bajo ese protocolo también. En la mayoría de los casos, y por facilidad en la implementación, configurarán el protocolo e instalarán los certificados para que la herramienta pueda “abrir” el tunel HTTPS y visualizar las peticiones de entrada, sin embargo, la configuración correcta va mucho más allá de eso. Para que la herramienta funcione correctamente y cubra todo el tráfico HTTPS es necesario configurala como punto de negociación HTTPS para la infraestructura, de no ser así, como atacante, uno puede forzar a utilizar ciertos algoritmos criptográficos y suites de cifrado, al momento de la negociación HTTPS, para que la herramienta no pueda visualizar las peticiones.
UN POCO DE TECNICISMO:
En términos generales tenemos dos formas de establecer un tunel TLS para HTTP (HTTPS): En el protocolo handshake de TLS podemos utilizar algoritmo RSA para el intercambio de llaves criptográficas cuya llave pública está en el certificado y la privada instalada en la herramienta de seguridad o servidor, y algoritmo Diffie-Hellman y variantes (ECDHE, DHE, etc) cuya negociación se hace directamente en la memoria RAM del punto de negociación de HTTPS en el lado server y el user-agent del lado cliente. Las suites de cifrado más “fuertes” están hechas para que ni obteniendo la llave privada puedas descifrar el contenido que pasa por el tunel TLS y mejor aún, si logras tener una llave privada podrás descifrar contenido por pocos segundos ya que las llaves de cifrado de mensaje están cambiando frecuentemente.
La forma de realizar un ataque sobre una infraestructura mal configurada para HTTPS es utilizar una suite de cifrado suficientemente robusta que realice el intercambio de llaves durante la negociación TLS utilizando el algoritmo Diffie-Hellman, ya sea efímera o con curvas elípticas. Cuando ocurre esta negociación el mensaje client-key-exchange del protocolo TLS handshake no utiliza la llave pública que recibió del certificado para enviar los bytes “pre-master secret”, si no que las memorias RAM de ambos entidades (punto de negociación server y user-agent) serán las únicas que tendrán los datos para generar la llave de cifrado principal de los mensajes y en las herramientas, aún teniendo el certificado y llave privada correspondiente, no serán capaces de llegar a la misma llave criptográfica, por ende no serán capaces de visualizar el tráfico en claro y proteger las infraestructura.
Usualmente estas herramientas mostrarán un mensaje del tipo “Unable to decrypt HTTPS” y, a pesar de que verán pasar el tráfico no verán su contenido.
La forma en la cual podemos forzar a utilizar una suite de cifrado en particular es:
Al realizar eso tendremos el escenario como el siguiente:
Por lo que lo recomendable es que la mejor solución de seguridad para aplicaciones que tenga su infraestructura sea el punto de negociación HTTPS. Con esto, independientemente de la suite de cifrado que utilicemos para negociar TLS, la herramienta podrá visualizar por completo todo el contenido bajo ese protocolo y proteger las aplicaciones de forma correcta.
Every day a new e-commerce application is published on Internet and more people are using these applications to acquire any kind of products, at the end that is the goal, but to get there you need to introduce some of your information, from personal information to payment information. You need to type in your address, your name, your age sometimes and your credit card (CC) information of course.
In Card Not Present transactions the information must be protected in a different way than card present transactions, that is because the information processed is in fact different.
Many of these web and mobile applications don’t follow protocols and rules to protect the customer information, not even moderately. In this post I will focus on the best practices for protecting this kind of critical information. Continue reading Security in payment data for e-commerce applications
La idea de escribir este post nace de haber conversado con diversos fabricantes de herramientas de prevención ante ataques informáticos principalmente perimetrales y a nivel de mensajes de aplicación que, después de recibir cierto feedback de su parte, me hace pensar que las implementaciones de la infraestructura no se están haciendo adecuadamente con este tipo de tecnologías.
En la actualidad existe infraestructura de protección que, con ciertas configuraciones, te permite protegerte ante algunos ataques enfocados en aplicaciones web: XSS, CSRF, Injection, session manipulation, DoS, etc. Además existe infraestructura que permite analizar la información, a nivel de aplicación, que fluye por las redes para detectar anomalías. En general tenemos una gran variedad de equipos e infraestructura tanto física como lógica que se basa en el análisis del tráfico de las redes para realizar su trabajo y proteger los activos, por ejemplo: Next Generation Firewalls, Web Application Firewalls, UTMs, Advanced Threat Protection, entre otros.
Con la infraestructura anterior se está teniendo un problema que está evitando que las herramientas hagan su labor de protección de manera adecuada y este problema es el cifrado de los canales de comunicación que evita que se pueda visualizar la información que fluye por el canal cifrado. Esto puede ser tanto bueno, cuando se trata de proteger la información sensible que viaja por canales no seguros, como malo, cuando un atacante envía algún script malicioso o payload por ese mismo canal cifrado. Continue reading Infraestructura de seguridad y HTTPS
Quizá uno de los temas más delicados en la configuración de sitios web es la implementación correcta de un dominio bajo HTTPS ya sea porque requiere cierto conocimiento criptográfico o una serie de pasos muy bien definidos para que no tenga ninguna falla.
Independientemente del tipo de tecnología de servidor que se utilice (IIS, Apache, Nginx, etc.) la configuración de certificados para HTTPS junto con el formato adecuado de ellos, el orden correcto, configuración de OCSP y de más, pueden derivar en cualquier cantidad de problemas para los clientes (user-agents) o más específicamente para su biblioteca PKI que utilice para comunicarse con el servicio HTTPS expuesto.
Por mencionar algunos problemas tenemos:
Cadena de confianza incompleta o incorrecta
Suites de cifrado (cipher-suites) no soportadas por los clientes esperados
Versiones del protocolo SSL/TLS inseguras
Vulnerabilidades como BEAST, POODLE, HEARTBLEED activas
HSTS mal configurado
entre otros.
Existe un sin fin de literatura para la instalación correcta de certificados y configuración HTTPS, de acuerdo a la tecnología involucrada, que podemos encontrar con una buena búsqueda en Google pero una vez realizada la instalación siempre es bueno validarla de forma externa para asegurarnos que nuestra implementación es adecuada y soportada por los clientes esperados.
