열린 Kibana가 노출시킨 native.org의 트레이딩 스택

선의로 수행된 협력적 공개이며, 어떠한 포상금이나 대가도 관련되어 있지 않다. native.org는 문제를 해결했고 이 글의 공개를 승인했다. 영향을 받은 호스트의 주소는 공개하지 않는다.

요약

• 207노출된 인덱스 패턴
• 21복구한 활성 API 키
• 8,700+15분마다 쌓이는 로그 항목

native.org의 Kibana 인스턴스는 스테이징과 UAT에 걸친 회사의 트레이딩 인프라를, 총 207개의 인덱스 패턴으로 색인하고 있었고, 그 뒤의 API 게이트웨이는 활성 API 키를 평문으로 로그에 기록하고 있었다.

native.org는 DeFi 유동성 플랫폼이다. 온체인 RFQ 시스템이 사설 마켓 메이커로부터 호가를 받아 여러 체인의 트레이더에게 제공하고, 그 결과로 발생하는 흐름은 중앙화 거래소에서 헤지된다. 노출된 인스턴스는 UAT 환경의 일부였다. native.org는 유출된 키 중 어느 것도 프로덕션에서 사용되지 않았음을 확인했고, 인스턴스에 인증을 추가했으며 키를 교체했다.

노출된 Kibana는 흔하다. 여기서 더 주목할 가치가 있는 것은 두 가지다. 열린 관측성(observability) 스택이 무엇을 내주는가, 그리고 키 유출의 배경에 있던 실수가 얼마나 평범했는가.

핵심 요점

• 인스턴스는 어떠한 인증도 요구하지 않았다. Kibana UI가 로드되었고, 모든 인덱스를 조회할 수 있었으며, 저장된 객체가 열거되었다. 모두 자격 증명 없이.
• 207개의 인덱스 이름은 운영 전체의 지도였다. 가격 책정, 헤징, 리스크, 청산, 정산, 온체인 모니터링, 중앙화 거래소 연동, 크로스체인 페그, 그리고 비상 정지 제어. 단 한 건의 문서도 열지 않고 아키텍처를 읽어낼 수 있었다.
• API 게이트웨이는 원시 API 키를 자신의 출력으로 기록했고, 그것이 Elasticsearch로 흘러들어갔다. 우리는 활성 로그 스트림에서 21개의 키를 복구했다. 당시 한 인덱스는 15분마다 8,700건이 넘는 로그 항목을 받고 있었으므로, 시스템은 분명히 가동 중이었다.

열린 대시보드가 내주는 것

인덱스 이름은 위협 표면이 아니라 운영상의 배관으로 여겨진다. 모든 서비스의 완전한 이름 목록은 공격자에게 시스템이 정확히 어떻게 구성되어 있는지를 알려준다. native.org의 경우, 그 이름들은 트레이딩 스택을 처음부터 끝까지 묘사했다. 주문 흐름을 위한 quote-order-task와 order-manager, 가격 책정을 위한 pricer와 quote-ticker, 리스크를 위한 risk-manager와 liquidation-price-task, 헤징을 위한 trade-hedger-task와 hedge-signer, 중앙화 거래소 연동을 위한 cex-monitor와 cex-position-monitor, 청산을 위한 settlement, 여러 체인에 걸친 소프트 페그 작업, 그리고 킬 스위치를 위한 emergency-stop-task와 emergency-paused-task.

그 어느 것도 문서나 자격 증명을 필요로 하지 않았다. 인덱스 이름 목록 그 자체만으로 하나의 설계 검토다. 공격을 계획하는 사람에게 이것은 사전 조사의 대부분을 끝내 주는 셈이다.

유출은 아키텍처를 넘어선다. 같은 이름들이 전략까지 철자처럼 드러낸다. 차익 거래, 페어 트레이딩, 시장 충격 추정, 크로스체인 페깅을 위한 인덱스들은, 이 회사가 어떻게 돈을 벌려 하는지를 경쟁자에게 일러 준다. 종종 더 가치 있는 쪽이다. 클러스터에는 트레이딩 데이터만 있었던 것도 아니다. 회사 자체의 보안 텔레메트리, 즉 호스트·네트워크·엔드포인트 감사 로그와 침입자를 잡기 위한 경보까지 들어 있었다. 그것을 읽는 사람은 방어자가 무엇을 탐지할 수 있고 무엇을 탐지할 수 없는지 알 수 있다.

더 작은 운영 세부 사항조차 이름 짓기를 통해 배어 나온다. 호스팅 리전, 클라우드 제공자, 새 언어로 다시 작성되던 도중의 구성 요소들, 그리고 사용 중인 내부 프로토콜. 그중 하나하나는 사소한 정보다. 하지만 합쳐지면, 공격자가 직접 해야 했을 정찰을 그대로 건네준다.

이름 자체는 괜찮다. 어느 팀이든 사용할 법한, 명료하고 분별 있는 이름 짓기다. 잘못된 것은 그 이름들이 사는 대시보드가 누구에게나 열려 있었다는 점이다.

로그 속의 키

더 직접적인 문제는 API 게이트웨이 로그에 있었다. 게이트웨이의 키 조회 함수는 조회가 성공할 때마다 전체 키 객체를 로그에 기록했고, 그 로그 줄들은 다른 모든 것과 마찬가지로 Elasticsearch에 떨어졌다. 게이트웨이 인덱스를 열고 그 함수로 필터링하면 다음과 같은 항목의 스트림이 나왔다.

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

이런 식으로 우리는 21개의 고유한 키를 복구했다. 이것은 존재하는 로깅 실수 중 가장 흔한 것 하나다. 디버깅 중에 요청 전체나 인증 객체 전체를 로그에 남기고, 그것이 다른 누군가가 읽을 수 있는 저장소로 간다는 사실을 잊는 것. 자격 증명과, 당신이 로그를 보관하는 장소가 같은 것이 되어 버린다.

영향, 과장 없이

이것은 UAT 환경이었고, native.org는 키가 프로덕션에서 사용되지 않았음을 확인했다. 그 점은 중요하며, 우리는 이를 가동 중인 트레이딩 데스크에서의 아슬아슬한 사고였던 것처럼 꾸미지 않을 것이다. 그런 것이 아니었다.

그럼에도 여전히 심각했다. 인증 없이 인터넷에 노출되어 가동 중이던 인스턴스가 실제 자격 증명을 평문으로 로그에 남기고 있었고, 자금을 다루는 플랫폼의 전체 설계를 드러내고 있었다. 키는 UAT 키였지만, 인덱스는 몇 분마다 수천 줄의 로그를 받고 있었으므로 트래픽은 실제였으며, 그것이 드러낸 아키텍처는 프로덕션 시스템이 돌아가는 바로 그 아키텍처다. “그저 UAT일 뿐”과 “공개 인터넷에서 활성 키를 로그에 남기고 있다” 사이의 간극, 그것이 이야기의 전부다.

개념 증명 (PoC)

인스턴스는 HTTP 포트에서 인증 없는 요청에 응답했다. 확인에는 세 단계가 걸렸고, 그 어느 것도 curl이나 브라우저보다 더 별난 도구를 필요로 하지 않았다.

• GET /api/status는 자격 증명 없이 Kibana 버전과 노드 이름을 반환했다.
• GET /api/saved_objects/_find?type=index-pattern&per_page=500은 207개의 인덱스 패턴 전부를 반환했다.
• Discover에서 게이트웨이 인덱스를 열고 키 조회 함수로 필터링하면 로그에 남은 키가 보였다.

호스트의 443 포트에 있던 TLS 인증서(CN=*.native.org, Cloudflare Origin CA 발급)는 그 인스턴스가 native.org의 것임을 확인해 주었다.

공개 타임라인

• 2026년 6월 2일위협 인텔리전스 연구 중 노출된 인스턴스를 발견하고, 영향을 받은 엔드포인트, 인덱스 목록, 로그에 남은 키의 편집된 샘플, 그리고 해결 단계를 담아 native.org에 보고했다.
• 2026년 6월 18일native.org가 노출을 확인했다. 그들은 인스턴스에 인증을 추가하고, 영향을 받은 키를 교체했으며, 인스턴스와 키가 UAT 환경에 속하고 프로덕션 키는 관련되지 않았음을 확인했고, 공개에 앞서 원하는 편집 사항을 제시했다.
• 2026년 6월 19일native.org의 의견을 반영하고 그들이 요청한 편집을 적용하여 공개했다.

native.org는 신속하게 대응했고, 문제를 해결했으며, 글 작성에 우리와 함께해 주었다. 우리가 이를 알린 것은 노출이 심각했고 그들이 알아야 했기 때문이지, 대가를 바라서가 아니었다. 협력적 공개는 바로 이렇게 이루어져야 한다.

같은 스택을 운영하는 팀을 위해

• Kibana와 Elasticsearch를 인증 뒤에 두라. xpack.security.enabled를 켜고 HTTP 포트를 공개 인터넷에서 떼어 놓으라. 인증 없는 ELK 스택은 웹 UI가 전 세계에 열린 데이터베이스다.
• 당신의 로그 저장소는 거기에 닿을 수 있는 누구에게나 읽힐 수 있다고 여기라. 자격 증명이 로그 줄에 들어갈 수 있다면, 읽힐 것이라고 가정하라.
• 인증 객체나 요청 객체 전체를 로그에 남기지 말라. 식별자를 기록하되, 비밀은 결코 기록하지 말라. 키 조회 경로가 바로 이것이 잘못되는 지점이다.
• 당신의 인덱스와 서비스 이름이 당신의 시스템을 묘사한다는 점을 기억하라. 그것들이 사는 장소를 비공개로 유지하라.
• 오래된 환경을 점검하라. 여기 이름들에는 uat-v1, uat-v2, staging, shadow 같은 태그가 붙어 있었다. 시간에 걸쳐 쌓인 테스트 설정의 층들이다. 잊힌 것이 결국 공개되는 그것인 경우가 많다.

감사의 말

빠르고 전문적인 대응에, 그리고 이 보고서에 무엇이 들어갈 수 있고 무엇이 들어갈 수 없는지를 함께 고민해 준 데 대해 native.org 팀에 감사한다.