Defective code IV. Exposición de datos sensibles

Continuando con la serie de vulnerabilidades más frecuentes en aplicaciones WEB, las cuales están en el top 10 de riesgos OWASP en este caso de 2017, vamos a tratar la exposición no intencionada de datos sensibles en nuestras aplicaciones WEB, dichos datos podrían ser identitarios tanto de trabajadores o clientes como datos relevantes de otra índole, estos podrían ser información médica o incluso datos bancarios. Se ha escogido este tema además en un momento en el que están muy de actualidad los datos manejados por la empresas, ya que hoy es 25 de mayo y se hace de obligado cumplimiento el nuevo Reglamento General de Protección de Datos (RGPD).

¿Qué es la Exposición de datos sensibles?

Sería la exposición o facilidad con la que un usuario malintencionado o ciberdelincuente pudiera comprometer estos datos robando o modificandolos para su propio beneficio, en perjuicio a una persona o empresa, como podrían ser fraudes en tarjetas de crédito, suplantación de identidad etc. Estos datos sensibles ni que decir tiene que requieren una protección adicional en su almacenaje y manejo de ellos por parte de las aplicaciones, como podrían ser el cifrado, no solo en el almacenamiento si no que tan importante o más lo es en el tránsito de dichos datos por la red.

Para un atacante es más fácil atacar y robar los datos en tránsito, que atacar la criptografía en el almacenaje, puesto que muchísimas veces se observa como esto viajan en texto plano, ya sea desde el cliente al servidor como viceversa. Este ataque se llevaría a cabo utilizando la técnica conocida como MITM (Man In The Midle), la cual trata de interceptar el tráfico colocándose el atacante en medio entre el cliente y el servidor, esta técnica se realiza de una forma bastante manual aunque en ocasiones pueden utilizarse hashes hechos públicos que facilitan la obtención de las contraseñas.

El error más común es la falta en el uso de cifrado y aunque se utilice dicho cifrado, se asignen protocolos y técnicas poco seguras y débiles, vulnerables a ataques del tipo de fuerza bruta, como por ejemplo algoritmos de hashing con explotación conocida para el almacenamiento de credenciales y el tránsito de las mismas.

¿Cómo puedo saber si mi aplicación es vulnerable?

La primera señal sería la transmisión de datos con protocolos como HTTP, SMTP, TELNET, FTP en su concepción poco seguros ya que funcionan en texto claro, en ello no solo hay que incluir el tráfico que se lanza a Internet si no también el interno como por ejemplo el que se genera en el sistema backend.

Hay que tener especial cuidado en los algoritmos de cifrado que se eligen para no escoger aquellos que puedan ser débiles por estar obsoletos o rotos como SHA1 y MD5 tanto en código por defecto como heredado.

Se eligen claves criptográficas por defecto, falta de rotación de claves, se reutilizan y son débiles.

¿Cómo prevenir las vulnerabilidades?

Lo primero sería clasificar los datos a procesar, almacenar y transmitir por el sistema. Se debe identificar qué información es sensible a los reglamentos y leyes en materia de protección de datos en los estados en los cuales se establezca el negocio. Aplicando controles adecuados en la clasificación.

No se deben almacenar datos sensibles que no sean imprescindibles o necesarios, puesto que los datos que no están almacenados no se puede robar.

Realizar cifrado seguro de los datos almacenados y utilizar protocolos seguros en su transmisión como es TLS, priorizando algoritmos en el servidor. Aplicar mecanismos de seguridad y cifrado como HSTS en el protocolo HTTP para obligar a los navegadores a utilizar conexiones cifradas por defecto.

Utilizar algoritmos estándar y fuertes, con una implementación adecuada de claves y deshabilitar el almacenamiento sensible en caché.

En el almacenamiento de contraseñas se deben de utilizar mecanismos de hashing adaptables como son scrypt y bcrypt.

¿Cómo sería un posible ataque?

No es la intención explicar cómo se realiza un ataque, si no de la forma que puede ser realizado por un posible atacante, de una manera más gráfica y representativa..

En definitiva como se puede observar en la imagen anterior el ataque más usual trata de envenenar los protocolos de comunicación para situarse en medio y adquirir o manipular las comunicaciones entre el cliente y servidor.

El mayor problema que podríamos tener sería que lo comunicación fuera en texto claro como se expuso en líneas anteriores, puesto que el atacante lo tendría muy fácil, pero también es un gran problema la adquisición o manipulación de cookies de sesión y otros datos. De ello la importancia de que las comunicaciones estén cifradas con un algoritmo de cifrado fuerte y utilizar protocolos de comunicación robustos.

Conclusión.

En conclusión tenemos que ser cuidadosos a la hora de elegir los algoritmos de criptografía que utilicemos en nuestras aplicaciones, así como implementar de la forma más adecuada y cuidadosa posible los protocolos de red, a la vez de tenerlos debidamente actualizados, si no queremos tener filtraciones y por lo tanto problemas graves por las grandes sanciones que promulga el nuevo RGPD.

Piensa mal y acertarás codificando de una manera más segura, aunque la seguridad completa no existe.

Referencias.

https://www.owasp.org/index.php/Spain