Postura crítica

Universidad del Tolima

Organos Autonomos · Sector educacion · Universidad pública

ResumenRiesgo CRÍTICO

U. Tolima presenta riesgo crítico: tiene 9 hallazgos activos publicados, de los cuales 3 requieren atención prioritaria (2 críticos y 1 alto). Además, 2 hallazgos están pendientes de revisión antes de decidir si se publica o se descarta. La prioridad es parchar o aislar la tecnología vulnerable y confirmar el cierre con una verificación posterior. Los temas que más inciden son vulnerabilidades usadas en ataques reales, tecnología vulnerable o fuera de soporte y suplantación institucional.

Siguiente paso: asignar responsable, fecha de corrección y evidencia de cierre; si un riesgo no se corrige, aceptarlo formalmente con dueño y fecha de revisión.

Descripción técnica

Se registran 9 hallazgos activos publicados: 2 críticos, 1 alto y 6 medios. Hay 2 hallazgos pendientes de revisión que todavía no deben tratarse como publicados.

Señales técnicas principales: CISA KEV CVE-2024-4577: php 7.1 en univ-ut (explotación activa documentada; en uso por ransomware activo): La versión detectada php 7.1 corresponde a vendor='php group' product='php' con 1 CVE en el catálogo CISA KEV. Esta CVE específica (CVE-2024-4577: PHP-CGI OS Command Injection Vulnerability) está documentada como... Stack tecnologico fuera de soporte: PHP 7.1 (EOL): Apex ut.edu.co reporta: PHP 7.1 (EOL), PHP EOL (PHP/7.1.30). U. Tolima: Dominio con riesgo de suplantación por correo: El riesgo de suplantación por correo sigue visible en 1 dominio: ut.edu.co.

Focos técnicos dominantes: vulnerabilidad con explotación activa, software fuera de soporte y autenticación de correo.

Publicados: 9Críticos: 2Altos: 1Medios: 6Sistémicos: 1CISA KEV: 1Pendientes: 2
Cobertura60
Postura de seguridad5
Divulgación responsable0
Consistencia operativa10

Hallazgos (9)

CISA KEV CVE-2024-4577: php 7.1 en univ-ut (explotación activa documentada; en uso por ransomware activo)

Critica

La versión detectada php 7.1 corresponde a vendor='php group' product='php' con 1 CVE en el catálogo CISA KEV. Esta CVE específica (CVE-2024-4577: PHP-CGI OS Command Injection Vulnerability) está documentada como explotada activamente por atacantes en producción (catalog dateAdded=2024-06-12, dueDate gov US=2024-07-03; en uso por ransomware activo).

El catálogo CISA Known Exploited Vulnerabilities lista solamente CVEs con evidencia confirmada de explotación en ataques reales. Esto no es un riesgo teórico: equivalente a saber que la cerradura específica de tu casa está publicada en un foro de criminales. La US Federal Government tiene fechas obligatorias de remediación (dueDate) — para entidades del Estado colombiano el estándar mínimo es el mismo. Si la CVE es de uso conocido en ransomware, el riesgo escala a interrupción operacional crítica.

Stack tecnologico fuera de soporte: PHP 7.1 (EOL)

Critica

Apex ut.edu.co reporta: PHP 7.1 (EOL), PHP EOL (PHP/7.1.30).

Software fuera de soporte no recibe parches de seguridad. Cualquier vulnerabilidad descubierta despues del EOL queda sin remediar.

U. Tolima: Dominio con riesgo de suplantacion por correo

Alta

Email spoofing risk is still visible for 1 domain(s): ut.edu.co.

SPF/DMARC debil permite suplantacion de correo institucional y fraude dirigido.

Headers exponen versiones de stack en 2 hosts

Media

Ejemplos: ut.edu.co: X-Powered-By=PHP/7.1.30; www.ut.edu.co: X-Powered-By=PHP/7.1.30.

Cada header de version acelera la explotacion de vulnerabilidades especificas. Buena practica: ocultar Server, X-Powered-By, X-Generator en respuestas externas.

Joomla manifest XML accesible en ut.edu.co

Media

GET https://ut.edu.co/administrator/manifests/files/joomla.xml retorna joomla.xml con versión.

Manifest revela versión exacta — facilita CVE matching.

Joomla manifest XML accesible en www.ut.edu.co

Media

GET https://www.ut.edu.co/administrator/manifests/files/joomla.xml retorna joomla.xml con versión.

Manifest revela versión exacta — facilita CVE matching.

Sin canal estandar de divulgacion responsable

Media

Ninguno de los 4 subdominios alcanzables publica /.well-known/security.txt (RFC 9116).

Un investigador que descubra una vulnerabilidad no tiene canal estandarizado para reportar antes de publicar. Crisis va a prensa antes que a la entidad.

Cookies sin Secure o SameSite en 2 hosts

Media

Hosts afectados: ut.edu.co, www.ut.edu.co.

Sin Secure las cookies viajan en HTTP plano si HSTS no aplica. Sin SameSite quedan expuestas a CSRF.

Headers de seguridad insuficientes (0/8)

Media

Apex ut.edu.co solo presenta 0 de 8 headers de seguridad esperados (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-XSS-Protection, COOP).

Headers de seguridad activan protecciones del navegador del usuario contra inyeccion, clickjacking y mixed content. Bajos = exposicion al usuario final.

Soluciones recomendadas

Qué necesita U. Tolima

Acciones derivadas directamente de los hallazgos observados en esta entidad.

Inmediatas

Firewall y protección perimetral

  • Implementar o fortalecer un WAF (firewall de aplicaciones web).
  • Bloquear tráfico sospechoso.
  • Limitar acceso a rutas sensibles como /admin, /administrator, /api, /dev, /intranet.
  • Aplicar reglas contra inyección, scraping agresivo, fuerza bruta y escaneo automatizado.

Headers de seguridad

  • Activar Content-Security-Policy.
  • Activar X-Frame-Options o frame-ancestors.
  • Activar X-Content-Type-Options, Referrer-Policy y Permissions-Policy.
  • Eliminar headers que revelan tecnología, como X-Powered-By.

Mantenimiento técnico

Actualizar software obsoleto

  • Migrar PHP 5 y PHP 7.4 a versiones soportadas.
  • Actualizar Joomla, plugins, plantillas y extensiones.
  • Retirar librerías JavaScript vulnerables.
  • Establecer ventanas mensuales de parcheo.

Gestión de vulnerabilidades

  • Escanear periódicamente dominios y subdominios.
  • Clasificar hallazgos por severidad.
  • Asignar responsables y fechas de cierre.
  • Verificar que cada corrección haya sido aplicada.

Canal de divulgación responsable

  • Publicar security.txt (RFC 9116).
  • Definir un correo oficial para reportes de seguridad.
  • Crear un procedimiento interno para recibir, validar y corregir vulnerabilidades.

Hardening institucional

  • Configuraciones seguras por defecto y plantillas web endurecidas.
  • Revisión de seguridad antes de publicar nuevos portales.
  • Separación clara entre producción, pruebas, desarrollo e intranet.

Cómo sostenerlo

  • Política de mínimos de seguridad web. Estándar obligatorio para todos los portales (HTTPS, HSTS, DMARC, headers, backups, logs, actualizaciones, monitoreo), exigible a proveedores.
  • Cláusulas de ciberseguridad en contratos. Obligar mínimos técnicos, SLA de corrección por severidad, evidencias de parcheo y derecho de auditoría.
  • Monitoreo continuo. No una revisión anual: alertar ante cada nuevo subdominio, certificado, API o tecnología vulnerable, y medir la postura por entidad y proveedor.
  • Modelo de remediación coordinada. Cuando un hallazgo se repite en muchas entidades, corregir la causa raíz (proveedor, plantilla o configuración común) para cerrar el riesgo en bloque.
  • Indicadores para la alta dirección. Tiempo promedio de corrección, hallazgos críticos abiertos, % de entidades con DMARC y HSTS, activos expuestos sin responsable, riesgo por proveedor.
  • EstadoSeguro no solo detecta vulnerabilidades; permite priorizar soluciones.
  • No reemplaza a su equipo de TI: le da visibilidad, evidencia y orden.
  • No es una auditoría anual: es monitoreo continuo de la superficie pública.
  • No busca señalar culpables: busca cerrar brechas antes de que se conviertan en incidentes.
  • Convierte el riesgo técnico en decisiones ejecutivas: qué corregir, quién responde y qué hacer primero.
Solicitar diagnóstico

Cronología de hallazgos

2026-05-022026-07-03

Nuevos

12

Activos

9

Pendientes

2

Solucionados

1

Revisión de hallazgos pendientes

Revisado: 2026-07-05

Conservado en revisión

Hay 2 hallazgos pendientes con revisión conservadora: se mantienen fuera de publicación hasta cerrar evidencia suficiente. Esta decisión no los marca como solucionados ni como falsos positivos.

2 pendientes

candidate-univ-ut-configuracion_ssl-7324d06615

requiere nuevo chequeo pasivo · Configuración SSL

AltaConservado en revisión

f-univ-ut-03

requiere método seguro de validación · Datos personales

AltaConservado en revisión

Activos públicos (4)

portal.ut.edu.co

subdominio

0/8
HTTPS
Certificado
HSTS
CSP
X-Frame-Options
X-Content-Type
Referrer-Policy
security.txt

Targeted passive refresh for univ-ut. Server: unknown.

Observado: 2026-07-03

ut.edu.co

portal principal

0/8
HTTPS
Certificado
HSTS
CSP
X-Frame-Options
X-Content-Type
Referrer-Policy
security.txt

Targeted passive refresh for univ-ut. Server: unknown.

Observado: 2026-07-03

docs.ut.edu.co

subdominio

0/8
HTTPS
Certificado
HSTS
CSP
X-Frame-Options
X-Content-Type
Referrer-Policy
security.txt

Targeted passive refresh for univ-ut. Server: unknown.

Observado: 2026-07-03

www.ut.edu.co

portal principal

0/8
HTTPS
Certificado
HSTS
CSP
X-Frame-Options
X-Content-Type
Referrer-Policy
security.txt

Server: nginx/1.12.2

Tech: Joomla, Nginx, PHP 7.1 (EOL). Title: Inicio

Observado: 2026-05-02