Microsoft 보안팀이 이 글을 본다면 login.microsoftonline.com/XXX/v2.0/adminconsent를 좀 살펴봐 주길 바람. 공격자가 다른 고객의 Azure 테넌트 ID를 알면 이 절차 마지막에 사용자를 리디렉션하는 콜백을 위조할 수 있음.
문서에 “tenant 매개변수의 테넌트 ID 값으로 사용자를 인증하거나 인가하지 말라”고 경고해도, 실제로 사용자를 인증할 방법이 있어야 도움이 됨.
테넌트 간 정보 유출 건수로는 Azure가 경쟁사를 한참 앞서는 듯함. 그런데도 기업들이 계속 몰리는 이유가 궁금함.
2002년과 같은 이유임. “Microsoft를 구매했다는 이유로 해고당한 사람은 없음.”
이미 Intune, Teams 등에 사용자당 월 요금을 Microsoft에 내고 있다면 Azure까지 쓰는 편이 자연스러움. 관리할 공급업체도 하나로 줄고, AWS보다 훨씬 적게 지출해도 전담 지원을 받을 수 있을 것 같음.
우리에게는 자국 내 데이터센터가 있다는 게 큰 이유임. 지연 시간도 줄고, 실제로 타당한지는 별개로 많은 고객이 안심함.
Amazon은 우리나라에 데이터센터가 없고, Google은 의존하던 제품을 언제 중단할지 몰라 다들 꺼림. 결국 선택지가 별로 남지 않음.
내가 참석한 회의에서 보면 Microsoft 영업팀은 최고경영진을 상대하는 데 능숙함. 업종과 향후 예상 지출에 따라 상당한 크레딧을 주고 직접 구축까지 지원함. 특히 다른 클라우드를 쓰는 고객을 데려오려 할 때 적극적임.
앞으로 몇 년 동안 LLM이 이런 유형의 취약점 발굴을 더 많이 수행해도 Microsoft의 플랫폼 설계가 버틸 수 있을지, Microsoft가 제대로 고칠 수 있을지 지켜봐야겠음.
이제 게시물에 날짜 태그를 붙여야 하지 않을까? 가령 2026-10-02처럼 말임. 매일 취약점이 여러 개씩 쏟아지니 이번 달 초가 2년 전처럼 느껴짐.
경로 순회와 IDOR라니, 해당 기능이 처음 생겼을 때부터 존재했을 가능성이 커 보임. “리소스 이름에 무작위성을 추가하라”는 권고가 이것 때문인지 궁금함. 별개 사안이라 해도 결국 숨기는 데 의존하는 보안 아닌가?
Microsoft에 심각한 테넌트 간 침범 취약점이 있었고 신고도 들어갔음. 다른 클라우드에는 이런 취약점이 대체 몇 개나 있었을까?
처음에는 잘못 고쳐서 다시 신고받았고, 이번에는 고치면서 이전 수정 사항을 망가뜨려 다시 취약해짐. 정말 엉망임.