En este caso
El caso en un vistazo
- Problema
- Una descarga expone tráfico de otra sesión del laboratorio.
- Decisión
- Comparar objetos, comprobar la reutilización de credenciales y revisar privilegios efectivos.
- Evidencia
- La guía documenta snapshots distintos, autenticación FTP, acceso SSH y CAP_SETUID en Python.
- Resultado
- Acceso SSH como nathan y cambio a UID 0, según la guía.
- Límite
- Retrospectiva HTB: sin PCAP original ni transcripción independiente; sin remediación verificada.
EXPEDIENTE · RETROSPECTIVA DE LABORATORIO
De la observación a la decisión
Abre una decisión para conectar su razonamiento con la sección concreta de la guía. Las alternativas son análisis editorial de este caso, no intentos adicionales ejecutados. No se recibió evidencia original independiente.
01Comparar objetos antes de buscar exploits
Observación documentada
La guía describe /data/1 como captura propia y vacía; /data/0 contiene una captura anterior con 72 paquetes.
Hipótesis
El identificador podría controlar la descarga sin una comprobación suficiente de autorización por objeto.
Decisión retrospectiva
Interpretar la comparación concreta entre objetos como evidencia documental del control de acceso.
Alternativa de análisis
Buscar primero un exploit genérico habría dejado sin estudiar la función observable de descarga. Esta es una alternativa editorial, no un intento ejecutado.
Resultado descrito
La guía documenta acceso a una captura distinta de la propia.
Qué no demuestra
No prueba acceso a todas las capturas, comportamiento actual ni autorización en una entidad real.
02Correlacionar el dato expuesto con un servicio
Observación documentada
La documentación describe campos USER y PASS de FTP legibles en la captura y un servicio SSH disponible.
Hipótesis
Las credenciales expuestas podrían reutilizarse en el servicio de acceso remoto dentro del laboratorio.
Decisión retrospectiva
Separar la lectura del tráfico de la autenticación posterior; cada salto necesita evidencia propia.
Alternativa de análisis
Tratar las credenciales como compromiso automático de SSH sería una conclusión sin comprobar el salto.
Resultado descrito
La guía describe acceso SSH como nathan tras obtener credenciales en FTP.
Qué no demuestra
El PCAP y una transcripción independiente no están incluidos en el expediente público; se omiten secretos.
03Elegir la escalada por el permiso efectivo
Observación documentada
La guía muestra cap_setuid en /usr/bin/python3.8 y una comprobación final de UID 0.
Hipótesis
Un intérprete con CAP_SETUID puede cambiar la identidad efectiva del proceso.
Decisión retrospectiva
Relacionar el permiso concreto con el cambio de UID y comprobar la identidad final.
Alternativa de análisis
El nombre root por sí solo aporta menos precisión que comprobar también UID 0.
Resultado descrito
La documentación describe escalada a UID 0 mediante la capability del intérprete.
Qué no demuestra
No acredita una remediación aplicada o eficaz; retirar la capability es una propuesta.
Mapa del caso documentado
De una captura distinta a UID 0
Síntesis editorial de mi guía de Cap, capítulos 02 a 05. Cada flecha indica el salto descrito y necesita su evidencia propia; el diagrama no es una ejecución nueva.
01 Captura propia · /data/1
La guía identifica /data/1 como la captura propia y vacía.
02 Captura distinta · /data/0
A · Comparación por cambio de identificador, desde el paso 01 al 02.
La comparación con /data/0 documenta acceso a una captura anterior con tráfico. No demuestra acceso a todas las capturas.
03 Credenciales FTP · en la captura
B · Lectura del tráfico FTP, desde el paso 02 al 03.
El análisis del tráfico describe campos de autenticación FTP legibles. El expediente omite sus valores.
04 SSH como nathan
C · Reutilización comprobada en la guía, desde el paso 03 al 04.
La guía documenta reutilización de esas credenciales y acceso SSH como nathan; leer el PCAP por sí solo no prueba ese acceso.
05 Identidad final · UID 0
D · CAP_SETUID del intérprete, desde el paso 04 al 05.
CAP_SETUID en /usr/bin/python3.8 permite el cambio de identidad. La documentación incluye la comprobación final de UID 0.
Límite del mapa: No se recibió el PCAP original ni una transcripción independiente. Los saltos son resultados históricos documentados; no prueban comportamiento actual, una remediación eficaz ni un retest.
Hipótesis y decisiones
Tres hipótesis guiaron el caso. Cada salto necesitaba su propia evidencia.
Autorización por objeto. La descarga depende de un identificador numérico. Comparar el snapshot de la sesión con otro identificador permite examinar si el servidor autoriza cada objeto. Empecé por la función web con mayor superficie observable y usé esa comparación concreta antes de buscar exploits genéricos.
Correlación entre servicios. Una captura que sí contiene tráfico merece análisis antes de buscar un exploit. Los campos USER y PASS de FTP pueden revelar credenciales; el servicio SSH ya identificado ofrece una forma de comprobar su reutilización dentro del alcance del laboratorio.
Privilegios efectivos. Tras el acceso, revisar las capabilities permite elegir una escalada basada en permisos concretos. CAP_SETUID sobre un intérprete de propósito general permite intentar cambiar la identidad efectiva del proceso: el permiso concreto importa más que el nombre del binario.
Evidencia y resultado documentado
Capturas distintas. El capítulo 02 describe /data/1 como el snapshot propio y vacío; /data/0 contiene 72 paquetes, 69 TCP, de una captura anterior. El cambio de identificador es la evidencia documental del acceso a un objeto distinto. Ver en la guía: IDOR.
Credenciales y acceso. Los capítulos 03 y 04 describen autenticación FTP legible y la reutilización de esas credenciales para acceder por SSH como nathan. Los secretos se omiten en este caso público. Ver: análisis de la captura · acceso por SSH.
Capability y comprobación de identidad. El capítulo 05 documenta la capability del intérprete y las comprobaciones finales. El resultado se expresa mediante UID 0, además del nombre de usuario. Ver: escalada de privilegios.
/usr/bin/python3.8 = cap_setuid,cap_net_bind_service+eip
whoami
# root
id
# uid=0(root) ...Resultado. La guía describe acceso a una captura distinta del snapshot propio, lectura de credenciales FTP, acceso SSH como nathan y una escalada a UID 0 mediante la capability de Python. El impacto surge de la cadena completa: exposición de datos, reutilización de credenciales y exceso de privilegios.
Mitigación y aprendizaje
Propuestas técnicas, no aplicadas ni verificadas en esta entrega.
- P1Cortar la exposición. Comprobar en el servidor la autorización sobre cada snapshot y su descarga; denegar por defecto cuando el usuario no sea propietario o carezca del permiso explícito. Identificadores impredecibles pueden reducir la enumeración, pero no sustituyen esa autorización. Rompe: acceso a capturas por cambio de identificador.
- P1Proteger las credenciales. Eliminar el transporte de credenciales en claro: migrar FTP a SFTP o FTPS bien configurado y limitar el acceso y la retención de capturas. Rotar las credenciales expuestas y revisar dónde se reutilizaron. Rompe: exposición y propagación de las credenciales.
- P1Reducir privilegios. Retirar CAP_SETUID del intérprete de propósito general y revisar las capabilities de los binarios accesibles; conceder solo los privilegios necesarios mediante mecanismos acotados. Rompe: cambio de identidad a UID 0 desde un intérprete arbitrario.
Aprendizaje. Una descarga aparentemente legítima puede iniciar una cadena de compromiso. El análisis gana valor al conectar el dato expuesto con otro servicio y comprobar el permiso local que habilita el salto siguiente. Cada salto necesita evidencia propia.
Fuente: mi guía de Cap (capítulos 02 a 05). Resultado histórico documentado; las mitigaciones son propuestas, no verificadas.