요약
Azure Logic Apps의 API Connections에서 다른 고객 자원까지 장악할 수 있는 취약점 5건이 나왔습니다.
바이너리 시큐리티 블로그에 호콘 비크 굴브란스루드가 올린 글입니다. API Connections(Logic Apps가 다른 서비스에 접속할 때 쓰는 연결 기능)의 구조적 결함을 다룬 세 번째 글이며, 이번 취약점들로 포상금 약 20만 달러를 받았다고 밝혔습니다.
왜 중요한가
- 공격자가 다른 테넌트(Azure 안의 고객별 독립 공간)의 Key Vault와 Azure SQL 데이터베이스에 손댈 수 있었습니다.
- Jira나 Salesforce처럼 Azure 밖의 서비스에 맺은 연결도 같은 위험에 놓입니다.
- 고칠 때마다 새 우회로가 나온 것은 입력 검증만으로 이 구조를 지키기 어렵다는 뜻이라고 글쓴이는 봅니다.
핵심 내용
- 뿌리는 여러 고객이 함께 쓰는 API Management 인스턴스가 모든 연결에 접근할 수 있는 구조입니다.
- 첫 공격은 DynamicInvoke의 경로 순회(
..로 다른 경로를 가리키는 기법)로 다른 테넌트의 Key Vault 시크릿을 읽었습니다. - 마이크로소프트가 경로를 제한하자, 문서에 없는 DynamicList로 피해자의 SQL 서버에 쓰기까지 해냈습니다.
- Consumption Logic App의 RuntimeUrl 매개변수를 바꿔 피해자 연결의 시크릿도 받아 냈습니다.
- RuntimeUrl 검증은 경로 순회로 뚫렸고, 그 수정 뒤에는 원래 공격이 다시 통했습니다.
HN 반응
- 사고가 잦은데도 Azure를 쓰는 이유로 일부 이용자는 기존 계약과의 묶음, 무난한 선택이라는 인식, FedRAMP 요건을 꼽았습니다.
- 계약이 하나로 묶여도 지원은 부실하다는 경험담이 이어졌지만, 기업 계약이면 하루 안에 엔지니어와 통화할 수 있어 쓸 만하다는 반론도 나왔습니다.
마이크로소프트 보안팀에서 이 글을 보시는 분이 계시다면, login.microsoftonline.com/XXX/v2.0/adminconsent를 어떻게든 해 주실 수 있습니까?
그 흐름이 끝날 때 사용자를 리디렉션하는 콜백은, 공격자가 다른 고객의 Azure 테넌트 ID를 알고 있으면 위조할 수 있습니다. 그리고 문서에 "테넌트 매개변수의 테넌트 ID 값을 사용자 인증이나 권한 부여에 절대 사용하지 마십시오"라는 경고를 적어 두는 것은, 사용자를 인증할 방법이 존재할 때에나 도움이 됩니다.
보고 나면 매니저한테 전달하겠죠. 그러면 이번 달 이니셔티브 아래, 직원 제안 에픽 밑에 있는 Azure Devops 보드에 티켓으로 등록될 거예요. 그 티켓은 Copilot이 검토하고 우선순위를 매겨서 다른 중간 관리자에게 주간 요약 메일로 보내질 거고, 석 달 동안 사람이 한 번도 건드리지 않으면 자동으로 닫히겠죠.
마이크로소프트 정직원(FTE)으로서 말하는데... 맞아요, 딱 그래요.
하이퍼스케일러 사이에도 '얼어붙은 중간층'이 있다니 반갑네요. 경영진을 통째로 갈아치워도 아무것도 안 바뀐다는 데 높은 확신이 있어요.
몇 달 만에 배운 말 중에 최고예요!
"방어적 관료주의(defensive bureaucracy)"도 참고하세요.
시카고 일대 MS 데이터센터에서 계약직으로 6개월 일했습니다. 제대로 돌아가는 게 하나도 없었습니다. 벽에 걸린 전화기는 윈도로 돌아가는데 발신음이 나오지 않았습니다. 보안 시스템은 윈도 업데이트 때문에 작동하지 못했습니다. 직원들은 자기 일보다 의무적으로 해야 하는 LinkedIn 업데이트를 더 신경 썼습니다. 자기 역할을 좋아하는 정직원은 한 명도 없었고, 다들 한 발은 이미 문밖에 내놓고 있었습니다.
정직원 전환을 제안받았을 때 거절하고 떠났습니다. 누가 봐도 완전히 엉망진창이었으니까요.
지금 MS에 다니시는 분들께는 죄송합니다.
나쁜 것만 있는 건 아니에요. 제가 있을 땐 워싱턴 캠퍼스에 시애틀 유명 셰프가 구성한 3코스 메뉴를 15달러에 파는 식당이 있었어요.
저희 쪽에는 자판기가 있었는데, 앱으로 토큰을 사야 자판기 음식을 꺼낼 수 있었습니다. 그 앱은 다크 패턴의 걸작이었습니다. 돈을 넣으면, 운이 좋을 경우에, 음식이 나옵니다. 어쩌면요.
월급 보고 와서... 밥 때문에 눌러앉는 거죠!
접니다. 그런데 댓글이 무슨 뜻인지 잘 모르겠습니다. 답글로든, 가능하면 이메일이나 MSRC 케이스로든 좀 더 설명해 주시겠습니까? 취약점 번호를 답글로 남겨 주시면 빠르게 처리되도록 하겠습니다.
redirect_uri는 앱 등록 정보와 대조해 검증합니다. 여기에는 "open registration redirects"라는 일반적인 OAuth 문제가 해당되는데, 이에 대해서는 블로그에 글을 올린 적이 있습니다. 다만 솔직히 업계 어디도 이 문제를 제대로 풀지 못하고 있습니다.
일반적으로 "X 엔드포인트를 거쳐 악성코드로 가는 링크를 만들 수 있다"는 얘기는 별로 흥미롭지 않습니다. 악성코드로 바로 가는 링크를 만들면 그만이니까요. 어차피 웹 브라우저는 링크의 실제 목적지를 믿을 만하게 보여 주지도 않고, 보여 준다 해도 URL을 이해하는 사람은 대개 우리 같은 해커뿐입니다.
무슨 말씀인지 모르겠습니다. Entra는 인증에 OpenID Connect를 지원합니다. 관리자 동의를 노출하는 대부분의 포털은 관리자 동의 요청 직전이나 직후에 OpenID Connect 요청으로 사용자를 인증합니다.
"이제 여기서 일 안 하셔도 됩니다"라는 말을 들은 직원 6만 명 중 누군가는 분명 그 일을 하겠다고 안달이 나 있겠네요. 그래프는 끝없이 우상향해야 하니까요.
테넌트 간 유출 건수로는 Azure가 경쟁사를 훨씬 앞서 있는 것 같네요. 그런데도 기업들이 왜 계속 몰려가는지 모르겠어요.
글쎄요, Intune, Teams 같은 것 때문에 이미 마이크로소프트에 사용자당 월 요금을 내고 있다면 Azure도 그냥 쓰는 게 낫죠.
관리할 벤더 관계가 하나뿐이고, AWS보다 훨씬 적은 돈을 쓰고도 개별 관리를 받을 수 있을 거예요.
마이크로소프트를 상대해 본 사람이라면 그게 아무 의미 없다고 말할 겁니다.
누군가의 관심이라도 받을 수 있다면 다행이고, 보통은 자기가 "지원"하는 제품을 거의 모르는 팀과 사람들 사이를 돌려 보내집니다.
Azure와 O365 관리 포털 얘기는 꺼내지도 마세요.
이보다 더 나빴던 지원 경험은 오라클뿐이었습니다. Sev1 이슈인데도, 첫 티켓에 로그를 이미 첨부했는데도 "로그를 보내 주세요"라는 판에 박힌 답을 받는 데만 며칠이 걸릴 수 있습니다.
두 경우 모두 수백만 달러어치 라이선스 소프트웨어와 프리미엄 지원 계약을 갖춘 F100 기업에서 겪은 일입니다.
벤더 관계를 관리한다는 건 라이선스 사용량을 사람들에게 배분하고, 계약을 검토하고, 소프트웨어가 계속 돌아가도록 언제 어디로 돈을 보내야 하는지 아는 사람을 두고, 계약에 어긋나는 일을 하고 있지 않은지 확인하는 일입니다.
마이크로소프트의 경우 그 일에 여러 명이 전업으로 매달려야 합니다. 기업들은 그런 관계를 더 늘리고 싶어 하지 않는 경향이 있고요.
"누군가의 관심이라도 받을 수 있다면"이라니 무슨 뜻입니까? 엔터프라이즈 계약에는 지원이 포함되어 있습니다. 24시간 안에 엔지니어와 통화할 수 있습니다. 질문에 답할 만큼만 능숙하다면, 제 경험상 지원은 꽤 괜찮았습니다.
처음 응대하는 지원 담당자는 보통 외주 인력이고, 이렇게 답합니다. "네, 고장 났네요... 설계상 그렇습니다."
여기서 말하는 관심은 문제를 실제로 고칠 수 있는 엔지니어의 관심입니다. 조용히 물러나게 만들려고 돈 받고 앉아 있는 해외 콜센터 직원이 아니라요.
네, 분류(triage) 단계죠. 기본 절차를 밟고, 관련 정보를 모으고, 어느 팀에 넘겨야 할지 파악하려는 거예요. 어디서나 지원은 그렇게 돌아가요.
O365 조직의 엔지니어는 전부 콜센터 직원이 변장한 거라고 확신해요.
보안 버그를 전부 한 벤더에서 받을 수 있으니 편하겠네요...
2002년이나 지금이나 이유는 같아요. "마이크로소프트를 샀다고 잘린 사람은 없다."
클라우드를 사자고요... 10년째 Teams에 화면 정지 기능 하나 못 만든 그 사람들한테서요... 그건 해고 사유가 돼야 하는데요...
무슨 말씀이세요? Teams는 제 화면을 맨날 얼려 주는데요!
네, 그건 기능이죠.
제가 말하는 건 Webex나 GotoMeeting, Zoom에 있는 것처럼 전문 프레젠테이션 도구라면 갖춰야 할 가장 기본적인 기능이에요. 그리고 요청도 이미...
https://learn.microsoft.com/en-us/answers/questions/4410610/pausing-screenshare-in-teams-meeting
여러 마이크로소프트 게시판에 걸쳐 2000건이 넘게 올라왔고, 요청 하나에만 1044건이 달렸어요....
와, 10년 넘게 Teams를 억지로 써 왔는데.. 다른 프레젠테이션 도구에 그렇게 유용한 기능이 있는 줄도 몰랐네요. 소프트웨어가 정말로 내 삶을 편하게 해 주는 세상이 있다고요!?
Teams로 발표해야 할 때마다 제가 Zoom에서 그 기능에 얼마나 기대고 있었는지 깨달아요. 그게 기능으로 없다는 게 정말 기가 막혀요.
2026년에는 이런 이유도 붙죠. "FedRAMP가 있고, 어떤 '사이버' 담당자가 감사를 통과하려면 GCC-High가 필요하다고 했어요."
거의 모든 일에 해당되는 얘기죠. 흐름을 따라가는 쪽이 늘 더 쉬우니까요.