침해사고사례분석 - Sisense

개요 

1. 사고배경 

Sisense는 뉴욕, 텔아비브, 런던에 사무소를 둔 비즈니스 인텔리전스 및 데이터 분석 플랫폼이다. Sisense의 제품은 고객사가 Salesforce, Snowflake 등 여러 서드파티 온라인 서비스의 상태를 단일 대시보드에서 조회할 수 있도록 설계돼 있다. 이 구조 자체가 이번 사고의 위험성을 키웠다. Sisense가 수백 개 고객사의 자격증명을 한 곳에서 관리하는 구조였기 때문에 Sisense 침해 하나가 고객사 전체에 대한 공급망 공격으로 이어졌다.

근본 원인은 개발자가 AWS S3 버킷 자격증명을 GitLab 저장소에 하드코딩한 것이었다. 이는 시크릿 스캐닝 도구가 있었다면 사전에 차단할 수 있었던 실수였다.

2. 사고 요약 

발생 일자	2024년 4월 10일
초기 접근 벡터	GitLab 저장소에 하드코딩된 AWS S3 자격증명
피해 데이터	수백만 개의 액세스 토큰, 이메일 패스워드, SSL 인증서
피해 규모	수 테라바이트 분량의 고객 데이터 탈취
영향 조직	금융, 통신, 의료, 고등교육 등
공격 유형	공급망 공격

 

공격 분석 

1. 공격흐름 

[GitLab 저장소 접근]
Sisense 자체 운영 GitLab 저장소 침투
        ↓
[AWS 자격증명 탈취]
저장소 내 하드코딩된 AWS S3 버킷 토큰/자격증명 획득
        ↓
[S3 버킷 접근 및 데이터 탈취]
수 테라바이트 분량의 고객 데이터 복사 및 외부 반출
        ↓
[고객 자격증명 확보]
Sisense 대시보드에 저장된 수백만 개의 고객사
액세스 토큰, 패스워드, SSL 인증서 획득
        ↓
[공급망 침해]
확보한 자격증명으로 고객사 서드파티 서비스에 무단 접근 가능
(Salesforce, Snowflake 등)

 

2. 단계별 공격 프로세스 

1)  GitLab 저장소 침투

공격자는 Sisense가 자체 운영하는 GitLab 인스턴스에 접근하는 데 성공했다. Sisense는 GitLab.com의 클라우드 버전이 아닌 자체 배포 버전을 사용하고 있었기에  Sisense가 직접 보안을 책임져야 했다.

 

2) 하드코딩된 AWS 자격증명 획득 

GitLab 저장소 내에 AWS S3 버킷에 접근할 수 있는 토큰 또는 자격증명이 평문으로 존재했고 공격자는 이를 이용해 Sisense의 AWS S3 버킷에 접근했다.

 

3) S3 버킷 대규모 데이터 탈취

공격자는 S3 버킷의 내용을 복사해 수 테라바이트 분량의 Sisense 고객 데이터를 외부로 반출했다. 탈취된 데이터에는 수백만 개의 액세스 토큰, 이메일 계정 패스워드, SSL 인증서가 포함됐다.  

 

4) 공급망 공격으로 확산 

액세스 토큰은 장기간 혹은 경우에 따라 무기한으로 로그인 상태를 유지할 수 있는 텍스트 파일이다. 공격자는 이 토큰을 재사용해 유효한 자격증명 없이도 피해 조직인척 하여 인증할 수 있다. 

대응방안 

이 사고는 Sisense가 고객사를 대신해 취할 수 있는 정리 조치가 제한적이다. 각 고객사는 자신들이 Sisense에 위탁했던 서드파티 서비스의 패스워드를 직접 변경해야하기 때문이다. 

1. 즉각 대응 절차 

1) 노출된 AWS 자격증명 즉시 비활성화 및 교체 (Sisense 에서 해야할 것)

# 의심 Access Key 비활성화
aws iam update-access-key \
  --access-key-id <KEY_ID> \
  --status Inactive \
  --user-name <USER_NAME>

# 새 Access Key 발급 후 기존 키 삭제
aws iam create-access-key --user-name <USER_NAME>
aws iam delete-access-key \
  --access-key-id <OLD_KEY_ID> \
  --user-name <USER_NAME>

 

 

2) cloudtrail로 S3 접근 범위 파악  (Sisense 에서 해야할 것)

탈취된 자격증명을 이용해서 어떤 버킷과 파일에 접근했는지, 접근한게 언제인지 확인한다. 

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=GetObject \
  --start-time <의심 시점> \
  --end-time <현재> \
  --query 'Events[*].{Time:EventTime,User:Username,Resource:Resources}'

 

3) 고객사 전체 자격증명 초기화 요청

Sisense CISO가 고객에게 요청한 초기화 항목은 Sisense 관련 패스워드, Active Directory/LDAP 자격증명, GIT HTTP 인증 자격증명, 웹 액세스 토큰, SSO JWTSAML/OpenID 시크릿, SSL 인증서, 커스텀 코드 내 시크릿, 데이터 베이스 자격증명등이 있다. 

 

2. 사후 조치 및 재발 방지 

1) GitLab/GitHub 저장소 시크릿 스캐닝 의무화

Sisense 사고의 시작은 개발자가 AWS S3 버킷 자격증명을 저장소에 커밋한 것이었다. 모든 커밋을 시크릿 스캐닝 도구로 검사했다면 사전에 차단할 수 있었기에 사전에 자격증명과 같은 민감정보를 스캐닝하여 삭제한다. 

도구 예시

• GitLeaks - 오픈소스로 CI/CD 파이프라인에 통합 가능하다.
• GitHub Advanced Security Secret Scanning - Github 저장소 내 시크릿을 자동으로 탐지한다. 
• AWS의 자동 감지 - GitHub 공개 저장소에 노출된 AWS 키를 감지하면서 자동으로 격리 조치한다.

# GitHub Actions에 GitLeaks 통합 예시
- name: Gitleaks
  uses: gitleaks/gitleaks-action@v2
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

2) 하드코딩 자격증명을 AWS Secrets Manager로 전환 

코드에 자격증명을 직접 넣는 대신 런타임에 Secrets Manager에서 동적으로 가져오는 구조로 전환한다. 

import boto3

client = boto3.client('secretsmanager', region_name='ap-northeast-2')
secret = client.get_secret_value(SecretId='prod/db/credentials')

 

3) S3 데이터 암호화 및 접근 로깅 활성화

이번 사고에서 s3에 저장된 고객 데이터가 암호화되어 있었는지 여부가 핵심이었다. s3 버킷에는 SSE-KMS 암호화를 기본 적용하고 S3 Server Access Logging 및 Cloutrail S3 이벤트 활성화를 설정하여 비정상적인 접근을 탐지하는 체계를 갖춰야 한다. 

 

4) SaaS 플랫폼 벤더 보안 검토 

공급망 관점에서 벤더 계약시 사이버 보안 요구사항을 명시하고 공급업체의 보안 수준을 지속적으로 감사하는 체계를 갖춰야한다. 

 

ex) 실무 적용 체크리스트

• 벤더 계약서에 데이터 암호화 요구사항 명시
• 벤더가 보유하는 자사 자격증명 목록 주기적 검토
• 벤더 침해 발생 시 즉각 자격증명 교체 절차 사전 수립
• 벤더에 위탁하는 자격증명은 최소 권한 원칙 적용

[참고자료]

https://www.cisa.gov/news-events/alerts/2024/04/11/compromise-sisense-customer-data

https://krebsonsecurity.com/2024/04/why-cisa-is-warning-cisos-about-a-breach-at-sisense/