coordinated-disclosure · kibana · elasticsearch · data-exposure · defi · cloud-misconfiguration

Una Kibana abierta expuso el stack de trading de native.org

Durante una investigación de inteligencia de amenazas, Kinryū Labs encontró una Kibana sin autenticación perteneciente a native.org que exponía toda la arquitectura de su stack de trading y registraba claves de API activas en texto plano. native.org ha restringido el acceso y rotado las claves.

Por Davis Zheng·

CWE
CWE-306, CWE-532
Vendor
native.org
Product
Kibana 8.11.1 / Elasticsearch

Divulgación coordinada, reportada de buena fe y sin recompensa ni pago de por medio. native.org ha solucionado el problema y ha autorizado la publicación de este artículo. La dirección del host afectado no se divulga.

Resumen

  • 207patrones de índice expuestos
  • 21claves de API activas recuperadas
  • 8.700+entradas de registro cada 15 min

Una instancia de Kibana de native.org indexaba la infraestructura de trading de la empresa en los entornos de staging y UAT, 207 patrones de índice en total, y la puerta de enlace de API (API gateway) que había detrás registraba claves de API activas en texto plano.

native.org es una plataforma de liquidez DeFi. Su sistema RFQ on-chain obtiene cotizaciones de creadores de mercado privados y las sirve a operadores en varias cadenas, y el flujo resultante se cubre en exchanges centralizados. La instancia expuesta formaba parte de un entorno UAT. native.org confirmó que ninguna de las claves filtradas se usaba en producción, añadió autenticación a la instancia y rotó las claves.

Las Kibana expuestas son habituales. Aquí hay dos cosas que merecen más atención: lo que entrega un stack de observabilidad abierto, y lo ordinario que fue el error detrás de la filtración de claves.

Puntos clave

  • La instancia no requería autenticación alguna. La interfaz de Kibana cargaba, todo índice era consultable y los objetos guardados se enumeraban, todo con cero credenciales.
  • Los 207 nombres de índice eran un mapa de toda la operación: fijación de precios, cobertura, riesgo, liquidación, liquidación de operaciones, monitorización on-chain, integración con exchanges centralizados, anclajes (pegs) entre cadenas y controles de parada de emergencia. Se podía leer la arquitectura sin abrir un solo documento.
  • La puerta de enlace de API registraba claves de API en bruto en su salida, que fluía hacia Elasticsearch. Recuperamos 21 claves del flujo de registros en vivo. En ese momento, un índice recibía más de 8.700 entradas de registro cada 15 minutos, así que el sistema estaba claramente en funcionamiento.

Lo que revela un panel abierto

Los nombres de índice deberían ser fontanería operativa, no una superficie de amenaza. Una lista completa y nombrada de cada servicio le dice a un atacante exactamente cómo está construido un sistema. En el caso de native.org, los nombres describían el stack de trading de principio a fin: quote-order-task y order-manager para el flujo de órdenes, pricer y quote-ticker para la fijación de precios, risk-manager y liquidation-price-task para el riesgo, trade-hedger-task y hedge-signer para la cobertura, cex-monitor y cex-position-monitor para la integración con exchanges centralizados, settlement para la compensación, tareas de anclaje suave (soft-peg) en varias cadenas, y emergency-stop-task y emergency-paused-task para los interruptores de emergencia.

Nada de eso necesitaba un documento ni una credencial. La lista de nombres de índice, por sí sola, es una revisión de diseño. Para quien planee un ataque, eso es la mayor parte del trabajo previo ya hecho.

La filtración va más allá de la arquitectura. Los mismos nombres deletrean la estrategia: índices para arbitraje, trading de pares, estimación de impacto de mercado y anclaje entre cadenas, que le dicen a un competidor cómo intenta ganar dinero la firma, a menudo la mitad más valiosa. El clúster tampoco contenía solo datos de trading. También guardaba la propia telemetría de seguridad de la firma, los registros de auditoría de host, red y endpoints, y las alertas pensadas para atrapar a un intruso. Cualquiera que lea eso puede ver qué pueden detectar los defensores y qué no.

Incluso los detalles operativos más pequeños se filtran a través de la nomenclatura: la región de alojamiento, el proveedor de nube, los componentes a medio reescribir en un nuevo lenguaje y los protocolos internos en uso. Cualquiera de ellos por separado es una trivialidad. Juntos, le entregan a un atacante el reconocimiento que de otro modo tendría que hacer por su cuenta.

Los nombres en sí están bien. Son el tipo de nomenclatura clara y sensata que usaría cualquier equipo. Lo que salió mal es que el panel en el que viven estaba abierto a cualquiera.

Las claves en los registros

El problema más directo estaba en los registros de la puerta de enlace de API. La función de búsqueda de claves de la puerta de enlace registraba el objeto de clave completo en cada búsqueda exitosa, y esas líneas de registro acababan en Elasticsearch como todo lo demás. Abrir el índice de la puerta de enlace y filtrar por esa función devolvía un flujo de entradas como esta:

[refreshApiKey] auth.GetByApiKey success, apiKey:
{"id": 9, "api_key": "faa79a…362f1f", "name": "[redacted]", "rate_limit": 20}

Así recuperamos 21 claves distintas. Este es uno de los errores de registro más comunes que existen: registrar la solicitud o el objeto de autenticación completos durante la depuración, y luego olvidar que se envían a un almacén que otra persona puede leer. La credencial y el lugar donde guardas tus registros pasan a ser la misma cosa.

El impacto, en su justa medida

Esto era un entorno UAT, y native.org confirmó que las claves no se usaban en producción. Eso importa, y no vamos a disfrazarlo como un caso por los pelos en una mesa de trading en vivo. No lo fue.

Aun así, fue grave. Una instancia activa, expuesta a internet y sin autenticación registraba credenciales reales en texto plano y exponía todo el diseño de una plataforma que maneja dinero. Las claves eran de UAT, pero el índice recibía miles de líneas de registro cada pocos minutos, así que el tráfico era real, y la arquitectura que exponía es la misma que ejecuta el sistema de producción. La brecha entre “es solo UAT” y “está en internet público registrando claves activas” es toda la historia.

Prueba de concepto (PoC)

La instancia respondía a solicitudes sin autenticar en su puerto HTTP. Confirmarlo costó tres pasos, ninguno de los cuales necesitó una herramienta más exótica que curl o un navegador:

  • GET /api/status devolvía la versión de Kibana y el nombre del nodo sin credenciales.
  • GET /api/saved_objects/_find?type=index-pattern&per_page=500 devolvía los 207 patrones de índice.
  • Abrir el índice de la puerta de enlace en Discover y filtrar por la función de búsqueda de claves mostraba las claves registradas.

Un certificado TLS en el puerto 443 del host (CN=*.native.org, emitido por Cloudflare Origin CA) confirmó que la instancia pertenecía a native.org.

Cronología de la divulgación

  • 2 de junio de 2026Encontramos la instancia expuesta durante una investigación de inteligencia de amenazas y la reportamos a native.org con el endpoint afectado, la lista de índices, una muestra editada de las claves registradas y los pasos de remediación.
  • 18 de junio de 2026native.org confirmó la exposición. Añadieron autenticación a la instancia, rotaron las claves afectadas, confirmaron que la instancia y las claves pertenecían a un entorno UAT sin claves de producción implicadas, y establecieron las ediciones que querían para la publicación.
  • 19 de junio de 2026Publicado con la aportación de native.org, aplicando las ediciones que solicitaron.

native.org respondió con rapidez, solucionó el problema y trabajó con nosotros en el artículo. Lo señalamos porque la exposición era grave y necesitaban saberlo, no a cambio de nada. Así es como debe funcionar la divulgación coordinada.

Para equipos que usan el mismo stack

  • Pon Kibana y Elasticsearch detrás de autenticación. Activa xpack.security.enabled y mantén el puerto HTTP fuera del internet público. Un stack ELK sin autenticación es una base de datos con una interfaz web abierta al mundo.
  • Trata tu almacén de registros como legible por cualquiera que pueda alcanzarlo. Si una credencial puede acabar en una línea de registro, asume que será leída.
  • No registres objetos de autenticación o de solicitud completos. Registra un identificador, nunca el secreto. La ruta de búsqueda de claves es justo donde esto sale mal.
  • Recuerda que los nombres de tus índices y servicios describen tu sistema. Mantén privado el lugar donde viven.
  • Inventaría tus entornos antiguos. Los nombres aquí llevaban etiquetas como uat-v1, uat-v2, staging y shadow, capas de montajes de prueba acumuladas con el tiempo. El olvidado suele ser el que acaba expuesto.

Agradecimientos

Gracias al equipo de native.org por una respuesta rápida y profesional, y por trabajar con nosotros en lo que podía y lo que no podía entrar en este informe.

How to cite
Kinryū Labs (2026). Una Kibana abierta expuso el stack de trading de native.org. https://kinryu.sh/es/reports/native-org-kibana-exposure/