바이너리 시큐리티(Binary Security)의 보안 연구자가 '애저의 가장 약한 고리(Azure's Weakest Link)' 시리즈를 이어가며 애저 로직 앱(Logic Apps)의 구성 요소인 API 커넥션에서 또 다른 취약점들을 공개했다. 이번에 보고된 결함은 모두 동일한 공격 원시(primitive)를 제공하며, 연구자는 총 5건의 중대한 권한 상승 취약점으로 20만 달러의 포상을 받았다고 밝혔다. 핵심 주장은 단순하면서도 무겁다. API 커넥션을 쓰면 공격자가 전 세계 어떤 테넌트의 커넥션이든 장악해 그에 연결된 백엔드에 접근할 수 있었다는 것이다. 대상에는 애저 키 볼트와 애저 SQL뿐 아니라 지라나 세일즈포스 같은 외부 연동 서비스도 포함된다. 이 글은 공개된 원문을 토대로 그 구조와 실무적 함의를 정리한다.
공유 APIM이라는 설계의 함정
문제의 뿌리는 API 커넥션이 동작하는 방식에 있다. 로직 앱은 공유된 애저 API 매니지먼트(APIM) 인스턴스에 요청을 보내고, APIM은 커넥터 유형의 스웨거(OpenAPI) 정의를 검사해 유효한 동작인지 확인한다. 이후 일종의 키 교환이 일어나 입력된 토큰이 백엔드 서비스용으로 설정된 토큰으로 바뀌고, APIM이 그 새 토큰으로 백엔드 호출을 완료한다. 여기서 연구자가 주목한 지점은, 만약 APIM이 공격자 소유가 아닌 다른 커넥션을 대상으로 동작하도록 속일 수 있다면 피해자 커넥션에 설정된 토큰을 그대로 피해자의 백엔드에 사용할 수 있다는 점이다.
결정적인 통로는 ARM(애저 리소스 매니저)이다. 연구자는 ARM REST API의 DynamicInvoke나 /extensions/proxy/ 엔드포인트를 통해 APIM을 직접 호출할 수 있음을 지적한다. 리소스 매니저인 ARM은 사실상 모든 것에 대한 접근 권한을 갖기 때문에, ARM에서 APIM으로 요청이 발생할 때 그 요청은 대상 커넥션이 무엇이든 모든 커넥션에 대한 권한을 갖게 된다. 더구나 커넥션 설정자가 백엔드 권한을 최소로 좁혀둘 수도 있으나, 연구자는 이것이 실제로는 거의 이뤄지지 않으며 OAuth 커넥션의 경우 언제나 최초 생성자의 토큰이 쓰인다고 본다.
경로 조작에서 숨겨진 함수까지
최초 공격은 전형적인 경로 조작(path traversal)이었다. DynamicInvoke 엔드포인트에 자신의 커넥션으로 요청을 보내면서 경로에 %2e%2e(..) 시퀀스를 끼워 넣어 다른 테넌트의 키 볼트 시크릿 값을 읽어낸 것이다. 마이크로소프트는 수 주 뒤 이를 수정했지만, 연구자가 보기에 그 수정은 근본적인 토큰 문제가 아니라 허용 경로를 제한하는 블랙리스트 방식이어서 우회 여지가 남아 있었다.
연구자는 전용 호스트를 제공하는 스탠다드 로직 앱을 만들어 SSH로 접속한 뒤 리소스 유형 내부에 포함된 코드를 추출했다. 이 과정에서 DynamicInvoke 외에 문서화되지 않은 함수가 네 개 더 존재하며 같은 경로에서 호출 가능하다는 사실을 발견했다. 예컨대 URI의 dynamicInvoke를 DynamicList로 바꾸기만 하면 되는 식이다. 블랙리스트 수정이 DynamicInvoke에만 적용된 탓에, 연구자는 DynamicList로 피해자 SQL 서버에 임의의 INSERT 쿼리를 실행하는 크로스테넌트 쓰기를 시연했다. 다만 마이크로소프트의 대응은 해당 엔드포인트들을 모두 차단하는 것이었고, 다른 완화책은 보이지 않았다고 한다.
로직 앱 자체를 통한 우회
경로 조작이 막히자 연구자는 로직 앱 자체로 눈을 돌렸다. 워크플로가 여러 사용자와 함께 배치되는 컨섬션(Consumption) 로직 앱은 버전 1 커넥션을, 전용 호스트를 쓰는 스탠다드 로직 앱은 버전 2 커넥션을 만든다. 스탠다드 앱은 관리형 ID로 백엔드 접근을 명시적으로 인가받지만, 컨섬션 앱은 인가할 ID 자체가 없다. 연구자는 이것이 곧 모든 컨섬션 로직 앱이 모든 버전 1 API 커넥션에 암묵적으로 접근 가능함을 뜻하며, 이를 막는 것은 입력 검증뿐이라고 추론했다.
커넥터 참조를 피해자 것으로 바꾸는 단순한 방법은 소유권 검증에 걸렸다. 그러나 추출한 코드에서 찾아낸 host.api.RuntimeUrl 파라미터가 열쇠였다. host.connection에 대한 검증을 통과한 뒤, 커넥션에 내장된 runtimeUrl 대신 전혀 다른 값을 지정할 수 있었고, 호스트가 azure-apihub.net으로 끝나기만 하면 필요한 Authorization 헤더까지 함께 붙었다. 마이크로소프트가 런타임 URL이 기대값과 정확히 일치하도록 요구하는 수정을 내놓았지만, 그 검증이 경로 정규화 이전에 수행된 탓에 런타임은 공격자 커넥션을 가리킨다고 판단하는 반면 APIM은 다르게 해석해 다시 공격이 성립했다. 이어진 경로 조작 수정에서는 오히려 원래의 RuntimeUrl 경로 검증이 사라져 또 한 번 같은 공격이 통했다.
실무자에게 남는 교훈
이 사례는 멀티테넌트 클라우드 플랫폼에서 공유 자원이 어떻게 신뢰 경계를 무너뜨리는지 보여준다. 근본 원인이 '어느 커넥션이든 조작하면 그 토큰을 쓸 수 있다'는 권한 모델에 있음에도, 대응이 경로 블랙리스트나 엔드포인트 차단 같은 표면적 입력 검증에 머무르면 우회 경로가 반복적으로 열린다. 특히 검증과 경로 정규화의 순서가 어긋나는 실수는 흔하면서도 치명적이다. 로직 앱 커넥션을 운영하는 조직이라면, 포상 대상 취약점들이 모두 수정되었다는 사실과 별개로, 백엔드 서비스에 연결되는 토큰과 키의 권한을 최소 범위로 좁혀두는 기본 원칙을 점검할 필요가 있다. 연구자가 지적했듯 이 범위 설정이 평소 거의 이뤄지지 않는다는 점이 바로 피해를 키우는 요인이기 때문이다. 연구자는 모든 취약점이 합리적 기간 안에 수정되었으며 MSRC와의 이견은 있었으나 전반적으로 결과에 만족한다고 덧붙였고, 상세 내용은 블루햇 아시아 2026 발표로도 다뤘다.