'Salesbleed' Exploits Salesforce Agents to Enable Slack Phishing
Salesbleed, Salesforce 에이전트를 악용해 Slack 피싱 유도
Salesforce Agentforce의 취약점 ‘Salesbleed’를 악용하면 Web-to-Lead 폼에 심은 지시문으로 에이전트를 조종해 내부 Slack 스레드에 피싱 메시지를 보낼 수 있습니다. Salesforce는 Slack 메시지 전송에 사용자 확인을 기본 적용하고 URL 검사 방식을 강화했습니다.
- 주제
AI 요약
Zenity 연구진은 Salesforce Agentforce의 취약점 세 가지를 ‘Salesbleed’라고 이름 붙였습니다. 공격자는 공개 Web-to-Lead 폼에 악성 지시문을 넣어 에이전트가 회사 내부 데이터를 외부로 보내게 하거나, 내부 Slack 대화에 피싱 메시지를 올리게 할 수 있습니다. Salesforce는 Slack 메시지 전송에 사용자 확인을 요구하도록 기본 설정을 바꾸고 URL 검사 체계도 강화했습니다.
Web-to-Lead 폼에 악성 지시문 삽입
Web-to-Lead는 잠재 고객이 제출한 정보를 Salesforce로 가져오는 양식입니다. 누구나 데이터를 보낼 수 있는 이 경로를 이용하면 공격자가 AI 에이전트가 처리할 악성 지시문을 심을 수 있습니다. 예를 들어 공격자 제어 URL로 데이터를 빼내라는 지시를 넣으면, 에이전트가 피해 회사 환경에서 이를 실행할 수 있습니다.
Salesforce는 1년 전 Noma Security가 비슷한 위험을 공개하자 공격에 쓰일 수 있는 URL을 걸러내는 규칙을 손봤습니다. 하지만 Zenity 연구진은 URL 필터링을 우회해 유사한 공격을 재현했습니다. Web-to-Lead 폼을 이용하는 공격자는 신원을 확인하거나 차단하기 어렵고, 에이전트가 가진 권한을 빌려 행동할 수 있습니다.
Slack 내부 대화에 피싱 메시지 게시
Web-to-Lead를 통한 데이터 유출은 한 번에 보낼 수 있는 양이 하위 도메인 문자열 크기로 제한됩니다. 연구진은 데이터 읽기와 전송에 그치지 않고 Agentforce가 가진 다른 기능도 악용할 수 있는지 살폈습니다.
Salesforce 에이전트는 Slack에 배치할 수 있으며, 하위 에이전트에 읽기·쓰기 권한을 부여할 수 있습니다. 일부 작업은 사용자 확인을 요구하도록 설정할 수 있고, 에이전트가 수행한 작업에는 담당 사용자 정보가 표시됩니다. 그러나 Slack 스레드에 답글을 다는 작업에는 이런 확인과 출처 표시가 빠져 있었습니다.
공격자는 Web-to-Lead 폼에 넣은 지시문으로 에이전트가 내부 Slack 스레드에 답하게 만들 수 있습니다. 답글에 피싱 링크와 사회공학 문구를 넣으면, 메시지가 직원이나 IT 지원 담당자가 보낸 것처럼 보일 수 있습니다. URL 보호의 허점까지 악용하면 신뢰받는 내부 채널에서 공격이 이뤄집니다.
Salesforce의 대응과 남은 과제
Salesforce는 취약점을 인정했지만 실제 공격에 악용된 증거는 없다고 밝혔습니다. 회사는 Slack에서 일부 Agentforce 작업의 기본 설정을 바꿔 메시지를 보내기 전에 사용자 확인을 요구하고, 고객에게 설정 검토를 안내하고 있습니다.
기존 URL 차단은 정규식(regex)으로 문자열이 URL처럼 보이는지 판별했습니다. 연구진은 URL을 예상 밖의 형식으로 숨겨 이 검사를 피했습니다. Salesforce는 이제 URL 표준에 맞는 파싱을 적용해 주소가 실제로 어디를 가리키는지 해석합니다. 또 에이전트 작업의 여러 지점에서 따로 이뤄지던 URL 검사를 단일 게이트웨이로 모아 일관된 규칙을 적용합니다.
Zenity의 Tamir Ishay Sharbat은 에이전트에 더 많은 권한을 주면 악용 위험도 커진다고 지적합니다. 민감한 정보와 외부 입력 경로에 동시에 접근하고, 여러 채널에 메시지를 보낼 수 있는 에이전트는 위험한 조합이 됩니다. Zenity CTO Michael Bargury는 에이전트가 내부에서 어떤 판단과 작업을 했는지 확인하기 어렵고 요약만 제공되는 경우가 많다고 말합니다. 이런 가시성 부족은 Salesforce만의 문제가 아니라 업계 전반에 퍼져 있다고 설명합니다.
Reddit 반응
- @DDelphinus — Salesforce가 비교적 복잡한 이 취약점들을 신속히 해결했습니다. 기본부터 살펴보세요. 연결 애플리케이션, API, 권한이 높은 사용자, 피싱을 가능한 한 제한하세요. 대부분의 공격은 여기서 시작합니다. 그다음은 IP 허용 목록입니다. 설정이 복잡하지만 가장 좋은 통제 수단입니다. Shield의 이벤트 모니터링도 고려하세요. 가격은 비쌉니다. 트랜잭션 보안 정책도 살펴보세요. Agentforce 같은 새 기술에는 취약점이 생기겠지만, 지금 사람들을 해킹당하게 만드는 건 기본적인 보안 문제입니다.
- @GryffinLoL — Salesforce 보안 질문이 나올 때마다 이 댓글을 고정할 수 있다면 그렇게 하겠습니다. 하이파이브.
- @kittrcz — IP 허용 목록이라는 생각을 좀 더 설명해 주실 수 있나요? 어떻게 구현하고 배포하나요?
- @Guilty_Mastodon5432 — AI 콘퍼런스에 참석했는데, 현실은 AI를 쓰거나 서비스에 AI를 넣은 사람 대부분이 다양한 데이터 흐름을 완전히 파악하지 못한다는 겁니다. 그래서 이 서비스를 보호하기가 정말 복잡합니다. 데이터 관리는 지금도 대부분 기업에 어려운 주제입니다. 어떤 데이터가 필요한가요? 누가 이 데이터에 접근해야 하나요? 접근 권한은 어느 수준이어야 하나요? 데이터를 사용하기 전과 후에는 어디에 있나요? 어떤 통제 수단이 있고, 그 통제가 효과적이라는 증거는 있나요? 데이터를 사용한 뒤에는 무엇을 하나요? 데이터 폐기 정책은 무엇인가요? 재미있네요 ㅋㅋ.
- @GryffinLoL — 여기 참고하세요: https://help.salesforce.com/s/articleView?id=000384438&type=1 그리고 관련 링크도 확인해 보세요.
원문: Dark Reading / 번역·요약: Trawling