이 연구는 클라우드 애플리케이션이 제공자 운영 메일 계정으로 알림을 보낼 때, 알림 매개변수를 넣는 행위자와 실제 발신 서비스 주체가 분리되면서 발생하는 '신뢰된 워크플로 릴레이' 취약점을 세 건의 실제 사례로 분석했다. 첫 사례는 UI 길이 제한을 우회한 백엔드 요청으로 원본 HTML·CSS가 전달 메시지에 그대로 남아 공격자 링크가 렌더링되고 CSS로 서비스 텍스트를 숨길 수 있었다. 두 번째는 수신자-테넌트 검증 누락과 공격자 제어 가능한 제목·HTML 필드가 결합됐고, 세 번째 승인 애플리케이션은 취약한 접근제어·순차적 객체 식별자·행위 인가 누락·불완전한 토큰 검증이 겹쳐 있었다. SPF·DKIM·DMARC는 메시지 발신처를 인증할 뿐 애플리케이션 수준의 발송 인가 여부는 보장하지 못한다는 점을 지적하며, 테넌트 바인딩·타입 템플릿·객체별 인가·토큰 대상 검증 등의 대응책을 제시했다.
- •알림 매개변수 제공자와 실제 발신 서비스 주체 분리에서 발생하는 신뢰 릴레이 취약점
- •책임 공개된 3개 실제 사례: HTML·CSS 삽입, 테넌트 검증 누락, 승인 앱 인가 오류
- •SPF·DKIM·DMARC는 발신처만 인증, 애플리케이션 수준 발송 인가는 별개 문제
- •테넌트 바인딩·타입 템플릿·객체별 인가·토큰 대상 검증 등 대응책 제시
0단 자동
AI가 규칙대로 쓰고 그대로 게시했습니다. 사람이 따로 보지 않았습니다.
- 규칙 판
- 규칙 판 도입 이전 기사입니다.
- 남기는 것
- 규칙 판 · 모델 · 시각
- 판 기록
- 아직 없습니다.
Trusted Workflow Relays:Cross-Tenant Email Abuse and Composable Red Team Initial-Access Primitives in Multi-Tenant Clouds
- 1.클라우드 제공자의 알림 발송 기능을 악용한 '신뢰된 워크플로 릴레이' 공격 3건을 책임있게 공개·수정 완료
- 2.첫 사례는 UI 길이제한을 우회해 원시 HTML·CSS가 그대로 전달되며 공격자 링크가 렌더링됨
- 3.두 번째는 수신자 테넌트 검증 누락과 제목·HTML 필드 조작이 결합된 취약점
- 4.SPF·DKIM·DMARC는 발신자만 인증할 뿐, 애플리케이션 레벨 발송 승인 여부는 검증못함을 지적
왜 중요한가?
정상 인증된 사용자가 클라우드 제공자의 신뢰받는 발신 계정을 통해 테넌트 경계를 넘어 피싱성 메시지를 보낼 수 있다는 새로운 공격 패턴으로, 첨부파일 없는 피싱 탐지의 사각지대를 드러낸다.
본문 미리보기
arXiv:2608.17361v1 Announce Type: new Abstract: Cloud applications routinely send notifications through provider-operated mail identities, which improves deliverability but separates the actor who supplies notification parameters from the service principal that originates the message. In three responsibly disclosed and remediated cross-tenant notification workflows, an authenticated actor could reach recipients across tenant boundaries and, to varying degrees, control content that a trusted pro
전체 내용이 궁금하다면?
원문을 직접 읽어보세요
이 글이 만들어진 과정
- 11:02AI 초안
