La detección participativa en acción: corrección de una vulnerabilidad crítica en el sitio web de la SIC

El 10 de marzo del 2026 nos escribió un representante de la empresa colombiana Mejor Llama A Cris! (“soluciones digitales de alto impacto”) para señalarnos que habían detectado una vulnerabilidad crítica en la plataforma web de la Superintendencia de Industria y Comercio y nos mandó un reporte detallado de sus hallazgos. En este momento, y gracias a la actitud responsable de esta empresa, nuestro laboratorio de seguridad digital y privacidad (K+Lab) pudo verificar el reporte. Después de confirmar el riesgo generado por esta vulnerabilidad, e incluso de encontrar otra, contactamos a la SIC, a través de su Delegatura para la Protección de Datos Personales. Ambas vulnerabilidades se pudieron corregir.

Detectar vulnerabilidades e incidentes desde la sociedad civil

Desde el primer análisis de un sitio web del Gobierno por parte de Karisma en 2016, nuestro laboratorio de seguridad digital y privacidad siempre ha intentado mostrar que la sociedad civil es un actor importante que el Estado debe tener en cuenta para mejorar la seguridad digital de sus sistemas en beneficio de todos los ciudadanos. Lo hemos hecho a través de análisis y reportes de vulnerabilidades e incidentes concretos, de incidencia, de conferencias y de publicaciones. Sin ser exhaustivos, podemos mencionar estas publicaciones que esbozan este largo camino:

Análisis de IMEI Colombia. Cronología de un diálogo con el Gobierno en 2017. Aquí narramos cómo el Gobierno Colombiano pasó de una actitud amenazante, justo después de nuestro reporte de vulnerabilidad, a una actitud de diálogo que permitió corregir los problemas.
La Corresponsabilidad en acción en 2017. Cuando el Gobierno Colombiano aceptó reconocer públicamente en el IV Foro de Seguridad Digital 2017, la ayuda de Fundación Karisma para detectar y corregir una vulnerabilidad crítica en el sitio web de la Unidad de atención y reparación integral a las víctimas.
Estudio sobre las rutas de divulgación en seguridad digital de 2019. Un informe que explica todas las barreras que enfrentan los investigadores en seguridad digital y plantea porque es “necesario implementar rutas de divulgaciones responsables, coordinadas y efectivas”.
El informe de la OCDE Encouraging Vulnerability Treatment – Responsible management, handling and disclosure of vulnerabilities en 2020, al cuál contribuyó Fundación Karisma (p. 71).
La seguridad de un Estado digital, Hacia una detección participativa en 2023. Documento que sostiene que “la capacidad de detección de los riesgos digitales tiene que apoyarse en toda la sociedad, incluyendo las universidades, la sociedad civil, los usuarios, los expertos técnicos e incluso lo que los medios de comunicación llaman de manera confusa los «hackers»”.
Varios análisis de privacidad y seguridad digital de sitios webs y aplicaciones del Estado, el último siendo el de la Cédula Digital.

En particular esta es la segunda vez que se detectan vulnerabilidades en sistemas de la SIC. En el 2021, habíamos mandado un reporte de análisis sobre la aplicación SIC a la Mano. Esto permitió corregir una vulnerabilidad cuya explotación también permitía acceder a datos personales de las personas usuarias.

El ejemplo que analizamos en este artículo es muy interesante porque involucró:

una empresa de consultoría en soluciones digitales (Mejor Llama A Cris!). Al inicio la empresa prefería guardar el anonimato, esperando cuál iba a ser la actitud de la SIC y la resolución de la vulnerabilidad,
Fundación Karisma, quien sirvió como intermediario en el proceso y revisor de la falla de seguridad detectada,
la Delegatura para la Protección de Datos Personales quien fue nuestro punto de contacto en la SIC.

Al final, esta colaboración permitió corregir prontamente una vulnerabilidad crítica que hubiera podido exponer datos personales de muchas personas.

Una vulnerabilidad que permitía acceder a expedientes y datos personales de cualquier persona

La vulnerabilidad, detectada inicialmente por Mejor LLama a Cris, afectaba la plataforma de servicios en línea de la SIC. El reporte que nos mandó mencionaba que “La vulnerabilidad permite a cualquier usuario autenticado de la plataforma enumerar y acceder a expedientes jurisdiccionales de terceros”. Después de verificar el reporte y analizar la plataforma, nos dimos cuenta de que efectivamente era algo serio y de que, además, existía otra vulnerabilidad similar que permitía acceder a los datos personales de las personas registradas en la plataforma.

Las vulnerabilidades se localizaban en estas URL (endpoints), que hoy en día ya no se usan:

Las vulnerabilidades se debían a que cuando se iba a buscar un documento o los datos de la persona usuaria, el sistema no verificaba que este documento o estos datos pertenecieran a quien estaba conectada y autenticada. Esto permitía a cualquier persona usuaria autenticada (con conocimientos técnicos) acceder a expedientes jurisdiccionales de terceros. El sistema validaba correctamente que el usuario tuviera sesión activa, pero no verificaba que el objeto solicitado le pertenecía. Lo mismo ocurría con los datos personales asociados a un perfil, cualquier persona con un acceso a la plataforma (no había restricción para crear un perfil ) podía acceder a expedientes, nombres, cédulas y documentos privados de otros ciudadanos y empresas simplemente modificando el identificador en la petición. Se trata de vulnerabilidades del tipo Broken Object Level Authorization (BOLA) e Insecure Direct Object Reference (IDOR).

Técnicamente, en este caso, funcionaba así:

En el primer caso (expedientes), una modificación del contenido de la solicitud HTTPS/POST con otro identificador de documento, mandando un paquete HTTPS como el que sigue, podría generar una respuesta del servidor con el documento correspondiente al ID.

Ejemplo de solicitud HTTPS mandada por un atacante potencial	Respuesta del servidor
`POST /api-sajur-partes/expediente/consultar Authorization: Bearer TOKEN_VÁLIDO [se entrega al conectarse] Content-Type: applicatio` `{"id": [ID_SECUENCIAL]}`	El servidor podía responder con un link de acceso al documento (expediente jurisdiccional) asociado a este ID.

2. En el segundo caso (datos de la persona usuaria), sólo hacía falta modificar el contenido de una solicitud HTTPS/POST cambiando el número de cédula por otro.

Ejemplo de solicitud HTTPS mandada por un atacante potencial	Respuesta del servidor
`POST /api-sajur-partes/persona/consulta Authorization: Bearer TOKEN_VÁLIDO [se entrega al conectarse] Content-Type: application/json {"persona":{"tipoDocumento":"CC","numeroDocumento":"XXXX","retornarSoloUltimosDatos":true}}`	El servidor podía responder con los datos de la persona que corresponde al número de documento.

En el caso de los expedientes, se usaban identificadores incrementales, y en el caso de personas, su número de cédula. De esta manera, cambiando el identificador del documento o el número de cédula de la persona se podía acceder a documentos o datos de otra persona, sólo teniendo el token de acceso y las cookies de sesión ya entregadas por el sistema.

Unas recomendaciones y una conclusión

En su reporte detallado, la empresa Mejor Llama A Cris! también envió recomendaciones de mitigación que fueron transmitidas a la SIC, a las que añadimos solo una. Son recomendaciones importantes, algunas de alcance general, que pueden ayudar a otras entidades a proteger sus sistemas y corregir vulnerabilidades como estas:

Implementar validación de autorización a nivel de objeto en cada consulta al API.
Verificar que la vulnerabilidad no esté presente en otras partes (endpoints).
Reemplazar IDs secuenciales o predecibles como el de la cédula por UUIDs no enumerables.
Implementar autenticación obligatoria para acceso a expedientes y datos personales.
Agregar rate limiting y detección de enumeración automatizada.
Implementar procesos de detección y de análisis de logs.

Aún hace falta proteger a quienes encuentran vulnerabilidades

Estos procesos coordinados de divulgación de vulnerabilidades (Coordinated Vulnerability Disclosure) , de fugas de datos y de otros tipos de incidentes digitales tienen tres objetivos principales:

Permitir una resolución pronta del problema por la entidad responsable del sistema afectado.
Avisar a las personas potencialmente afectadas cuando haya incidentes.
Una vez resueltos, hacer avanzar el conocimiento en seguridad digital con la publicación y difusión de conocimiento, incluyendo recomendaciones como las que aquí compartimos.

Nos alegra que, en este caso, la actitud responsable del descubridor y la confianza que depositó en Karisma, junto con el canal que teníamos con la Delegatura de Protección de Datos de la SIC, hayan permitido la solución oportuna del problema. Esto evita que una vulnerabilidad se convierta en una filtración de información y datos personales sensibles.

Este caso demuestra que los canales de comunicación entre la sociedad civil y las entidades del Estado son fundamentales para resolver vulnerabilidades antes de que se conviertan en filtraciones. Sin embargo, su existencia no puede depender de relaciones informales o de la suerte; todas las entidades del Estado deberían contar con canales formales y políticas claras para recibir reportes de vulnerabilidades, fugas de datos e incidentes digitales. Ahora bien, los canales no son suficientes si quienes los usan enfrentan riesgos legales, por eso consideramos necesario que la legislación reconozca el hacking ético y la investigación responsable en seguridad digital como excepciones a las leyes de delitos informáticos, para que de esta manera investigadores y sociedad civil puedan contribuir a la seguridad digital del Estado sin temor a consecuencias jurídicas.

Finalmente, reiteramos que, mientras no exista una ruta institucional de divulgación de vulnerabilidades que garantice la protección de quienes encuentran estos problemas de seguridad, Karisma seguirá actuando como intermediario de confianza en procesos de divulgación responsable de vulnerabilidades, fugas de datos e incidentes digitales que puedan afectar a la sociedad civil y a los ciudadanos.

Puede contactar el K+Lab por Signal o por correo electrónico, preferiblemente cifrado (ver nuestra llave PGP abajo):

Signal: k_lab.08
Correo electrónico: klab[at]karisma.org.co