Hacking ético con Andrej Šebeň — pódcast
Me invitaron al pódcast Buzzworld a hablar de hacking ético y salió una conversación distinta de la habitual. En vez del intercambio técnico y algo seco al que el tema suele dar pie, tiramos de humor: entrar en sistemas ajenos con permiso es un oficio serio, pero eso no obliga a contarlo con cara de funeral durante una hora.
El episodio está grabado en eslovaco. Lo que viene a continuación no es una transcripción, sino un resumen en español de los tres temas que ocuparon la mayor parte de la conversación.
De qué hablamos
1. Las CVE, y por qué se repiten
No hay forma de hablar de este oficio sin pasar por las CVE. Repasé algunas de las vulnerabilidades más entretenidas que me he encontrado en proyectos reales: cómo funcionan, cómo las encadena un atacante y, sobre todo, por qué los mismos fallos vuelven año tras año. La respuesta cabe en una frase: el código lo escriben personas con una fecha de entrega encima, y la fecha de entrega no ha cambiado nunca.
Quien quiera seguir ese goteo en español lo tiene fácil. INCIBE-CERT publica avisos de seguridad casi a diario sobre productos de uso corriente, con su identificador CVE y su nivel de gravedad. Es la misma lista que miramos antes de empezar un proyecto, y la que conviene tener enganchada a algún proceso interno en lugar de leerla cuando ya ha pasado algo.
2. Hackear en el sector bancario
La banca es un terreno de observación privilegiado, porque es de los pocos sectores donde atacante y defensor invierten en serio. Hablamos de fallos vistos de verdad, de cómo se rodean protecciones que parecían suficientes y de lo que una entidad financiera tiene que montar para no ir siempre por detrás.
Lo que más sorprende a quien escucha es el asunto del segundo factor. La autenticación reforzada de cliente que impone la PSD2, desarrollada en el Reglamento Delegado (UE) 2018/389, obliga a combinar dos elementos de categorías distintas; ahora bien, «dos factores» no equivale de forma automática a «seguro». Depende de cuáles sean y de cómo se verifiquen. Un código de un solo uso por SMS, una recuperación de contraseña mal pensada o una sesión que nadie revalida antes de una transferencia convierten un requisito cumplido sobre el papel en un camino abierto.
3. El hacking ético no es el del cine
Olvídate del encapuchado que aporrea el teclado mientras caen letras verdes por la pantalla. Un test de intrusión consiste en leer documentación, tener paciencia, tomar muchísimas notas y, de vez en cuando, comprobar que una idea funciona. Conté algunas cosas de detrás de la cámara: proyectos de ingeniería social, momentos en los que el guion previsto se cae a la primera y otros en los que la puerta se abre justo donde nadie miraba.
Lo que separa ese trabajo de un delito no es la técnica, que es exactamente la misma. Es el encargo. En España, acceder sin autorización a un sistema de información se castiga por el art. 197 bis del Código Penal, y borrar o dañar datos ajenos por el art. 264; la buena intención no exime de nada. Por eso todo empieza por un encargo firmado, con un alcance escrito y unas fechas cerradas. Esa parte la desarrollamos en cómo se hackea de forma legal.
¿Quieres escucharlo?
El episodio está ahí arriba, entero y en eslovaco. Si no entiendes el idioma, lo que has leído es lo que te llevarías de esa hora. Gracias al equipo de Buzzworld por la invitación; repetimos cuando queráis.
¿Y si lo que buscas es la versión aplicada a tu propia organización? Eso es justamente un test de intrusión: el mismo trabajo del episodio, con un alcance acordado, un informe de hallazgos priorizados y una comprobación posterior de las correcciones. El art. 32.1.d) del RGPD pide precisamente eso, «un proceso de verificación, evaluación y valoración regulares de la eficacia» de las medidas de seguridad, y una grabación divertida no sirve de evidencia; un informe fechado, sí.
Si todavía estás en el paso anterior, el de decidir a quién se lo encargas, aquí tienes las preguntas que conviene hacer antes de firmar.
