Skip to content
KitploitKITPLOIT
HerramientasExploitsBlog
Log in
Enviar
HerramientasExploitsBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
cloudfoundry_uaa — CVE-2016-4468 | Kitploit
Herramientas/GitHubGitHub/shanika04/cloudfoundry_uaa
Autenticación y AutorizaciónSeguridad de Infraestructura en la NubeSeguridad en la NubeDevSecOpsGestión de Identidad y Acceso (IAM)Seguridad de APIs
GitHubshanika04/cloudfoundry_uaa

cloudfoundry_uaa

CVE-2016-4468

Ver Repositorio
14hace 5 añosAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir
# Servidor de Autenticación y Cuentas de Usuario (UAA) de CloudFoundry

Build Status Coverage Status

El UAA es un servicio de gestión de identidades multi-inquilino, utilizado en Cloud Foundry, pero también disponible como un servidor OAuth2 independiente. Su función principal es la de proveedor OAuth2, emitiendo tokens para que las aplicaciones cliente los usen cuando actúan en nombre de los usuarios de Cloud Foundry. También puede autenticar usuarios con sus credenciales de Cloud Foundry, y puede actuar como un servicio SSO utilizando esas credenciales (u otras). Tiene endpoints para gestionar cuentas de usuario y para registrar clientes OAuth2, así como varias otras funciones de gestión.

Coordenadas

  • Tokens: Una nota sobre tokens, ámbitos y autoridades
  • Foro técnico: Lista de correo cf-dev
  • Documentación: docs/
  • Documentación de la API: UAA-APIs.rst
  • Especificación: El Marco de Autorización OAuth 2
  • LDAP: Integración LDAP del UAA

Inicio Rápido

Requisitos:

  • Java 8

Si esto funciona, estás listo:

$ git clone git://github.com/cloudfoundry/uaa.git
$ cd uaa
$ ./gradlew run

Todas las aplicaciones funcionan juntas ejecutándose en el mismo puerto (8080) como /uaa, /app y /api.

UAA registrará en un archivo llamado uaa.log que se puede encontrar usando el siguiente comando:

$ sudo find / -name uaa.log

que deberías encontrar bajo algo como:

/private/var/folders/7v/518b18d97_3f4c8fzxphy6f8zcm51c/T/cargo/conf/logs/

Desplegar en Cloud Foundry

También puedes construir la aplicación y enviarla a Cloud Foundry, p.ej. Nuestra forma recomendada es usar un archivo de manifiesto, pero puedes hacer todo desde la línea de comandos.

$ ./gradlew :cloudfoundry-identity-uaa:war
$ cf push myuaa --no-start -m 512M -p uaa/build/libs/cloudfoundry-identity-uaa-2.3.2-SNAPSHOT.war 
$ cf set-env myuaa SPRING_PROFILES_ACTIVE default,hsqldb
$ cf set-env myuaa UAA_URL http://myuaa.<dominio>
$ cf set-env myuaa LOGIN_URL http://myuaa.<dominio>
$ cf set-env myuaa JBP_CONFIG_SPRING_AUTO_RECONFIGURATION '[enabled: false]'
$ cf set-env myuaa JBP_CONFIG_TOMCAT '{tomcat: { version: 7.0.+ }}'
$ cf start myuaa

En los pasos anteriores, reemplaza:

  • myuaa con un nombre de aplicación único
  • 2.3.2-SNAPSHOT con la etiqueta de versión correspondiente de tu compilación
  • <dominio> es el dominio de tu aplicación. En el futuro lo analizaremos desde el entorno del sistema
  • También puedes proporcionar un manifiesto de configuración donde la variable de entorno UAA_CONFIG_YAML contenga el yaml de configuración completo.

Demostración de uso desde línea de comandos en el servidor local

Primero ejecuta el servidor UAA como se describió anteriormente:

$ ./gradlew run

Luego abre otro terminal y desde el directorio base del proyecto, pide al endpoint de inicio de sesión que te informe sobre el sistema:

$ curl -H "Accept: application/json" localhost:8080/uaa/login
{
  "timestamp":"2012-03-28T18:25:49+0100",
  "commit_id":"111274e",
  "prompts":{"username":["text","Username"],
    "password":["password","Password"]
  }
}

Luego puedes intentar iniciar sesión con la gema ruby de UAA. Asegúrate de tener ruby 1.9, luego

$ gem install cf-uaac
$ uaac target http://localhost:8080/uaa
$ uaac token get marissa koala

(o omite el nombre de usuario/contraseña para que te lo soliciten).

Esto autentica y obtiene un token de acceso del servidor utilizando la concesión implícita de OAuth2, similar al enfoque previsto para un cliente como CF. El token se almacena en ~/.uaac.yml, así que revisa ese archivo y extrae el token de acceso para tu destino cf (o usa --verbose en la línea de comandos de inicio de sesión anterior para verlo registrado en tu consola).

Luego puedes iniciar sesión como servidor de recursos y recuperar los detalles del token:

$ uaac target http://localhost:8080/uaa
$ uaac token decode

Deberías ver tu nombre de usuario y el id del cliente de la concesión original del token en la salida estándar, p.ej.

  exp: 1355348409
  user_name: marissa
  scope: cloud_controller.read openid password.write scim.userids tokens.read tokens.write
  email: [email protected]
  aud: scim tokens openid cloud_controller password
  jti: ea2fac72-3f51-4c8f-a7a6-5ffc117af542
  user_id: ba14fea0-9d87-4f0c-b59e-32aaa8eb1434
  client_id: cf

Ejecutar sistema local con configuraciones predeterminadas de MySQL y PostgreSQL (e información del script de migración Flyway)

$ ./gradlew -Dspring.profiles.active=default,mysql run

Este comando asumirá que hay una base de datos MySQL disponible con la configuración predeterminada para el acceso y responderá a la siguiente configuración JDBC.

driver = 'org.mariadb.jdbc.Driver'
url = 'jdbc:mysql://localhost:3306/uaa'
user = 'root'
password = 'changeme'
schemas = ['uaa']

De manera similar, si ejecutas el comando

$ ./gradlew -Dspring.profiles.active=default,postgresql run

Utiliza la configuración definida como

driver = 'org.postgresql.Driver'
url = 'jdbc:postgresql:uaa'
user = 'root'
password = 'changeme'

Esta configuración se duplica en dos lugares para la integración con Gradle. Se definen como valores predeterminados en los archivos de configuración XML de Spring y también se definen en el archivo build.gradle principal. La razón por la que están en el archivo de compilación de Gradle es para que Gradle ejecute siempre la tarea flywayClean antes de lanzar la aplicación UAA. Si no deseas limpiar la base de datos, puedes definir la variable

-Dflyway.clean=false

como parte de tu línea de comandos. Esto deshabilita la tarea flywayClean en el script de gradle. Otra forma de deshabilitar flywayClean es no especificar los perfiles de Spring en la línea de comandos, sino configurar los perfiles en los archivos uaa.yml y login.yml.

Demostración de uso desde línea de comandos en run.pivotal.io

El mismo ejemplo de línea de comandos debería funcionar contra un UAA ejecutándose en run.pivotal.io (excepto por la parte de decodificación del token porque no tendrás el secreto del cliente). En este caso, no es necesario ejecutar un servidor uaa local, así que simplemente pide al endpoint externo de inicio de sesión que te informe sobre el sistema:

$ curl -H "Accept: application/json" login.run.pivotal.io
{
  "prompts":{"username":["text","Username"],
    "password":["password","Password"]
  }
}

Luego puedes intentar iniciar sesión con la gema ruby de UAA. Asegúrate de tener ruby 1.9, luego

$ gem install cf-uaac
$ uaac target uaa.run.pivotal.io
$ uaac token get [tunombredeusuario] [tucontraseña]

(o omite el nombre de usuario/contraseña para que te los soliciten).

Esto autentica y obtiene un token de acceso del servidor utilizando la concesión implícita de OAuth2, la misma que usa un cliente como CF.

Pruebas de integración

Puedes ejecutar las pruebas de integración con

Descargar herramienta