Seguridad por oscuridad
La seguridad por oscuridad u ocultación, es una metodología que intenta plantear la seguridad de un sistema a partir del secreto de sus técnicas, utilizando procedimientos que no están documentados o se han desarrollado internamente. En otros casos, simplemente se confía en que los delincuentes no encuentren nuestra información.
Y por si alguien lo pensaba, no es algo que yo me invente, tiene hasta definición en la Wikipedia.
Tiempo atrás, nos ocurría mucho con sistemas criptográficos. La propuesta era siempre igual: “vamos a inventar nuestro propio sistema de criptografía”. La idea era que como el sistema utilizado para cifrar usaba algoritmos desconocidos nadie lo podría descifrar.
La idea es mala. Muy mala. Si algo tienen de bueno los sistemas de criptografía reconocidos, es que pasan por un proceso de auditoría constante, conocemos sus vulnerabilidades teóricas y prácticas y podemos actuar ante esas vulnerabilidades bien cambiando de sistema o bien aplicando parches y recomendaciones.
Un par de ejemplos: en julio de 2007, Richard Doherty decía sobre el sistema criptográfico anticopia de los discos BlueRay:
BD+, unlike AACS which suffered a partial hack last year, won’t likely be breached for 10 years.
Ocho meses después, el grupo Slysoft, anunció que podía eliminar la protección BD+ de cualquier disco. Según ellos, les costó ocho meses de trabajo de dos programadores a horas sueltas.
Otro caso: en 2011, GeoHot publicó la forma de acceder como root a la Playstation 3, con un mensaje mítico en su web (todo un dechado de técnica): “the keys open doors”.
No busquéis el mensaje en su Web, Sony, tras una larga lucha, le obligó a quitarlo y a prometer que no lo volvería a hacer más. La canción que le dedicó a Sony, también es mítica:
En realidad, las hazañas de GeoHot no comenzaron con la PS3, en 2007 fue el responsable del primer Jailbreak para iOS, famoso hasta hace muy poco por no dar ninguna información sobre los sistemas de seguridad de su sistema operativo. De hecho, todo lo que sabíamos de la seguridad del sistema era mediante técnicas de ingeniería inversa.
Volviendo a Sony y a la PS3: a raíz del juicio contra GeoHot comenzó a recibir una serie de ataques DoS y se filtraron 77 millones de cuentas de usuario con información sensible como los números de tarjetas de crédito. La respuesta de Sony, también es memorable:
Sony de hecho, tiene un largo historial de fallos de seguridad por su afán de ocultar e inventar. Por ejemplo, en 2005 Mark Russinovich les afeaba su afán de introducir rootkits en sus CD, reproduciendo declaraciones como ésta:
Perhaps the biggest news in the story last week is Sony’s first public response since one of their executives stated in a National Public Radio interview, “users don’t know what a rootkit is, and therefore, don’t care.”
Puede que os parezca extraño este tipo de afirmaciones, pero son más comunes de lo que pensaba. Por ejemplo, Troy Hunt también tuvo alguna experiencia de este tipo con Fiddler:
Ultimamente parece que andemos algo escarmentados con la implementación de sistemas criptográficos, pero aparece otra modalidad de la seguridad por oscuridad que podríamos denominar seguridad entre la multitud.
El concepto es algo así como “nadie me va a atacar porque hay muchos objetivos en Internet ¿quién se va a fijar en mí?” o “como mi sistema está en la nube, nadie encontrará las url de mis archivos entre la inmensidad de sitios web”. Otra mala idea.
Y es una mala idea por algo que los programadores y los ciberdelincuentes hacemos muy a menudo: automatizar.
No os equivoquéis, no es necesario que os busquen directamente a vosotros. Un ciberdelincuente encontrará un fallo y lanzará un ataque a ciegas, simplemente a ver qué encuentra. Y os encontrará.
Tenéis que considerar que una gran parte del tráfico que se origina en Internet es tráfico de ataque automatizado. De hecho, podemos seguirlo en tiempo real con mapas como los de Kaspersky:
¿Os habéis preguntado, por ejemplo, cuánto tiempo tarda un dispositivo IoT en caer en las redes de una botnet? Rob Graham hizo la prueba (spoiler: un minuto y cuarenta segundos):
¿Aún no me creeis? ¿Recordáis las []({ href = “Artículos\Seguridad\Hallazgos Shodan” } impresoras 3D y Shodan)?
Hace unos meses, preparando una charla sobre seguridad, me pasé un rato en Shodan buscando servidores MongoDB. El primero que encontré estaba completamente abierto y parece que no fui el único en tener la idea de conectarse:
Que viene a decir algo así como: “he encontrado tu base de datos, te la he robado porque me los has puesto en bandeja, si la quieres paga un rescate”.
Puede parecer curioso que para dos veces que entro en Shodan por casualidad encuentro un dispositivo vulnerable y una base de datos secuestrada. Me da por pensar que quizá no sea una casualidad.
Y no, no es una buena idea deducir que ninguno de vuestros clientes utiliza Shodan o Scans.io o no saben programar un script Python para buscar puertos abiertos porque puede que sepan cómo buscar por Google esas contraseñas que os empeñáis en guardar en proyectos públicos de Trello:
Pero bueno, eso seguro que no os pasa porque vuestros archivos están en carpetas de AWS que aunque sean públicas tienen un nombre que sólo conocen los miembros de nuestra empresa y no existe ninguna forma de automatizar estas cosas. No sé algo que se llame así como Bucket finder o S3 Scanner y que podamos encontrar en GitHub, por ejemplo. Por cierto, no son los únicos, los encontré en el artículo How to find unsecured S3 buckets: some useful tools, que podéis imaginar de qué trata.
En resumen, no es que la seguridad por ocultación sea mala seguridad, simplemente no es seguridad: es esperanza y la esperanza, en seguridad, nunca ha sido una buena estrategia.