접근 제어 솔루션 원로그인에서 API 관리 부실 취약점 나와

접근 제어 솔루션 원로그인에서 API 관리 부실 취약점 나와
Photo by Vizito Visitor Management / Unsplash
💡
Editor's Pick
- 원로그인에서 발견된 CVE-2025-59363
- client_secret이라는 민감 정보 노출시켜
- API 관리 개념 부족해서 생긴 취약점

인기 높은 아이덴티티 및 접근 관리 솔루션인 원로그인(OneLogin)에서 심각한 보안 취약점이 발견됐다. 이를 익스플로잇 하는 데 성공한 공격자는 민감한 정보를 가져갈 수 있게 된다고 한다. 해당 취약점에는 CVE-2025-59363이라는 관리 번호가 부여됐으며, CVSS 기준 7.7점이 부여됐다. 고위험군에 속하나 초고위험군은 아니다. CWE-669로 분류되기도 한다. 

보안 업체 클러치시큐리티(Clutch Security)가 찾아내 원아이덴티티(One Identity, 원로그인의 개발사)에 제보했다고 한다. 제보된 내용은 “유요한 API 크리덴셜을 확보하는 데 성공한 공격자가 피해 기업 및 기관에서 사용하는 원로그인 테넌트 내 모든 OIDC 애플리케이션에 저장된(혹은 그러한 애플리케이션과 연결된) 기밀을 검색해 찾아낼 수 있다”는 것이었다. 

💡
여기서 잠깐!
OIDC는 일종의 ‘인증 기능’이다. 오오스2.0(OAuth 2.0) 프로토콜을 기반으로 하고 있다. 구글이나 페이스북, 네이버 등 유명 서비스의 ID를 가지고 다른 서비스나 웹사이트에 로그인 해본 적이 있는가? 그런 식으로 로그인을 할 때 OIDC가 사용된다. 단순히 특정 리소스에 대한 접근 권한을 부여하는 게 아니라, 접근하려는 사람이 누구인지까지 파악한다. 그러므로 “OIDC 애플리케이션에 저장된 기밀을 공격자가 열람할 수 있다”는 건, 공격자가 OIDC 기반 애플리케이션의 사용자 신분 증명용 데이터를 가져갈 수 있게 된다는 의미다.

왜 이런 문제가 발생한 걸까? 애플리케이션 목록 엔드포인트인 /api/2/apps가 대단히 많은 데이터를 반환하도록 설계되어 있기 때문이다. 과도하게 데이터를 처리해 제공한다는 의미로, 그 데이터 중에 client_secret 값이 포함돼 있다고 클러치시큐리티는 설명한다.

💡
여기서 잠깐!
client_secret은 애플리케이션이 스스로의 신분(“난 가짜/악성 앱이 아니야!”)을 증명할 때 사용하는 값으로, 사람으로 치면 비밀번호라고 할 수 있다. 토큰 발급 기능을 가진 엔드포인트들은 바로 이 값을 이용해 토큰을 안전하게 발급한다. 즉, 공격자가 client_secret을 획득하면 악성 애플리케이션을 다른 정상 애플리케이션으로 위장할 수 있게 된다.

이 취약점을 통한 공격 시나리오는 다음과 같다.
1) 공격자는 먼저 별도의 해킹 공격 등을 통해 피해자 기업/기관의 원로그인 API 크리덴셜을 획득한다.
2) 그리고 이 정보를 가지고 인증 단계를 거친다.
3) 로그인 상태에서 접근 토큰을 요청해 발급 받는다.
4) /api/2/apps 엔드포인트를 호출한 후 관련된 모든 애플리케이션이 포함된 목록을 확보한다.
5) 이 목록을 바탕으로 모든 OIDC 애플리케이션의 client_secret을 추출한다.
6) 추출한 정보를 활용해 애플리케이션인 것처럼 위장해 추가 악성 행위를 실시한다.
7) 애플리케이션으로 위장하면서 특정 사용자를 사칭할 수도 있게 된다.
8) 그렇다는 건 피해자 네트워크 내에서 횡적 이동을 할 수 있다는 의미다.

클러치시큐리티는 이것이 매우 위험한 상황으로 이어질 수 있다고 경고한다. “원로그인은 역할을 기반으로 한 접근 제어 기능을 API 키에 부여합니다. 그렇기 때문에 원로그인의 크리덴셜이 유출되면, 플랫폼에 연결된 모든 민감 엔드포인트가 위험에 노출됩니다. 거기에다가 연결이 허용된 IP 주소가 무한정이라면(즉 화이트리스트 처리가 되어 있지 않다면), 전 세계 어디서든 공격이 가능해집니다.”

원아이덴티티 측은 7월 18일 관련 보고서를 접수 받고 지난 8월 새 버전을 공개 및 배포했다고 밝혔다. “OIDC의 client_secret 값이 더 이상 외부에 노출되지 않도록 수정했습니다. 버전만 최신화 한다면 클러치시큐리티가 우려한 공격 시나리오는 통하지 않습니다. 또한 이 취약점과 관련된 실제 피해 사례는 발굴되지 않았습니다.” 사용자들은 버전 확인 후 2025.3.0으로 업그레이드 해야 안전하다. 

API 보안
이 사건은 “전형적인 API 보안 문제”로 분류된다. 왜냐하면 원로그인의 API 엔드포인트가 과도하게 많은 정보를 반환하는 게 문제의 뿌리이기 때문이다. “원래는 앱 메타데이터만 반환해야 하는데, client_secret까지 반환하니 문제였던 것이죠. 어떻게 보면, 클라우드 스토리지를 전체 공개로 해둔 채 비밀을 잔뜩 저장하는 것과 같습니다. API 관리에 대한 인식이 부족해 생기는 문제라고도 볼 수 있습니다.” 클러치시큐리티 측의 설명이다.

그렇다는 건 API 엔드포인트를 그런 방식으로 구현한 개발사 측의 잘못이 크다는 의미가 된다. 민감한 정보가 나가지 않도록 백엔드에서 필터링을 한 번 더 했다거나, 검사를 좀 더 꼼꼼히 했다면 나타나지 않았을 문제다. 사용자 편에서는 API 엔드포인트 설정을 제어할 방법이 없으므로, 만약 실제 피해가 있었다면 대단히 억울할 뻔했다.

하지만 공격 시나리오 중 전제 조건이 하나 있음을 잊으면 안 된다. 바로 “유효한 API 크리덴셜을 확보한 공격자”라는 것이다. 애초에 사용자가 API 크리덴셜을 잘 관리한다면, 개발사가 아무리 엔드포인트를 엉성하게 설정해 두었더라도, 취약점 익스플로잇 자체가 불가능하다는 의미가 된다. 따라서 이 사건은 개발사와 사용자 모두에게 경종을 울린다.


도커 API 독차지 하려는 움직임, 진짜 의도는 아직 미스터리
💡Editor’s Pick - 도커 API에 침투 후 다른 공격자 접근 차단 - 연결된 서버 통해 감염 확산 시도 - 결국 봇넷 만들려는 것...그 이유는 아직 몰라 공개되어 있는 도커 API(Docker API)를 겨냥한 사이버 공격 행위가 발견됐다. 이전에도 존재했던 수법이긴 하지만, 공격의 목적이 달라졌다고 보안 업체 아카마이(Akamai)
점점 다가오는 API 보안 규제의 압박, 쉽게 혹은 어렵게?
💡Editor’s Pick - API는 현대 기술, 그걸 보호하는 보안은 구식 기술 - API 보호 위한 현대 기술 도입 필요 - 보다 적극적인 보안 인식 제고와 태도도 중요 소프트웨어 시대가 되면서 API의 활용도가 높아졌다. 그에 따라 API를 통한 보안 사고도 잦아지고 있다. 보안 업체 라이디엄(Raidiam)은 최근 ’API 보안의 전환점(

Read more

[TE머묾] AI 시대에, 혐오 직업 보유자로 버티기

[TE머묾] AI 시대에, 혐오 직업 보유자로 버티기

💡Editor's Pick - 텍스트로 둘러싸인 더테크엣지 기자의 현장 - 인공지능 덕 좀 보려했지만, 퇴근 시간은 제자리걸음 - 인공지능과의 경쟁에서 기자가 앞서는 건 무엇일까 며칠 어지럼증이 심해졌다. 눈앞이 핑 돈다는 게 뭔지 살면서 처음 경험했다. 그건 비유가 아니었다. 사실에 충실한 표현이었다. 이미 수백 년 전 폐기된 천동설이 아직 살아남아

By 문가용 기자
제프리 엡스타인은 스캔들이 아니라 구조였다

제프리 엡스타인은 스캔들이 아니라 구조였다

💡Editor Pick - 2019년 사건은 개인을 향했고 2026년 문서 공개는 구조를 드러냄 - 국가는 어디까지 네트워크를 활용할 수 있으며, 감시 책임 주제는? - 정보가 소유되고 축적될 때 권력으로 발전 2019년의 사건, 2026년의 문서 공개, 그리고 ‘정보의 민영화’라는 질문 2019년 7월, 뉴욕에서 체포된 제프리 엡스타인(Jeffrey Epstein)은 미성년자 성착취

By Donghwi Shin, Jin Kwak