AWS의 Capital One 해킹에 대한 기술적 세부 사항

19년 2019월 106일, Capital One은 모든 현대 기업이 두려워하는 데이터 유출이 발생했다는 메시지를 받았습니다. 이는 140억 000백만 명 이상의 사람들에게 영향을 미쳤습니다. 미국 사회보장번호 80개, 캐나다 사회보장번호 000만개. XNUMX개의 은행 계좌. 불쾌해요, 동의하지 않나요?

안타깝게도 19월 XNUMX일에는 해킹이 발생하지 않았습니다. 결과적으로 Paige Thompson, a.k.a. 이상한 사람, 22년 23월 2019일부터 XNUMX월 XNUMX일 사이에 커밋했습니다. 그건 거의 XNUMX개월 전. 실제로 Capital One이 무슨 일이 일어났는지 발견할 수 있었던 것은 외부 컨설턴트의 도움을 통해서였습니다.

아마존 전직 직원이 체포돼 벌금 250만달러와 징역 XNUMX년을 선고받았다. 하지만 여전히 부정적인 면이 많다. 왜? 해킹 피해를 입은 많은 기업들이 사이버 범죄가 늘어나는 가운데 인프라와 애플리케이션 강화에 대한 책임을 회피하려고 하기 때문이다.

어쨌든, 이 이야기는 쉽게 구글에 검색해 볼 수 있습니다. 우리는 드라마에 들어 가지 않고 이야기를 나눌 것입니다 기술적 인 문제의 측면.

우선, 무슨 일이 일어났나요?

Capital One은 약 700개의 S3 버킷을 실행하고 있었고 Paige Thompson은 이를 복사하여 흡수했습니다.

둘째, 이것은 잘못 구성된 S3 버킷 정책의 또 다른 사례입니까?

아니, 지금은 안돼. 여기에서 그녀는 잘못 구성된 방화벽이 있는 서버에 액세스하여 그곳에서 전체 작업을 수행했습니다.

잠깐, 이게 어떻게 가능해요?

자세한 내용은 없지만 서버에 로그인하는 것부터 시작해 보겠습니다. 우리는 이 일이 "잘못 구성된 방화벽"을 통해 발생했다는 말만 들었습니다. 따라서 잘못된 보안 그룹 설정이나 웹 애플리케이션 방화벽(Imperva) 구성 또는 네트워크 방화벽(iptables, ufw,shorewall 등)과 같은 간단한 문제입니다. Capital One은 자신의 유죄를 인정하고 구멍을 막았다고 말했습니다.

Stone은 Capital One이 처음에는 방화벽 취약점을 인지하지 못했지만 이를 인지한 후 신속하게 조치를 취했다고 말했습니다. Stone은 해커가 주요 식별 정보를 공개 도메인에 남겼다는 사실이 확실히 도움이 되었다고 말했습니다.

왜 이 부분에 대해 더 깊이 들어가지 않는지 궁금하시다면, 제한된 정보로 인해 추측만 할 수 있다는 점을 이해해 주시기 바랍니다. 해킹이 Capital One이 남긴 구멍에 의존했다는 점을 고려하면 이는 말이 되지 않습니다. 그리고 그들이 우리에게 더 많은 것을 말하지 않는 한, 우리는 누군가가 이러한 다양한 옵션 중 하나를 사용할 수 있는 모든 가능한 방법과 함께 Capital One이 서버를 열어둔 가능한 모든 방법을 나열할 것입니다. 이러한 결함과 기술은 매우 어리석은 실수부터 엄청나게 복잡한 패턴까지 다양합니다. 가능성의 범위를 고려할 때, 이것은 실제 결론이 없는 긴 이야기가 될 것입니다. 그러므로 팩트가 있는 부분을 집중적으로 분석해보자.

따라서 첫 번째 요점은 방화벽이 무엇을 허용하는지 파악하는 것입니다.

열어야 할 것만 열 수 있도록 정책이나 적절한 프로세스를 수립합니다. 보안 그룹 또는 네트워크 ACL과 같은 AWS 리소스를 사용하는 경우 당연히 감사할 체크리스트가 길 수 있습니다. 하지만 많은 리소스가 자동으로 생성되는 것처럼(예: CloudFormation) 감사를 자동화하는 것도 가능합니다. 새 객체에 결함이 있는지 검사하는 직접 만든 스크립트이든, CI/CD 프로세스의 보안 감사와 같은 것이든... 이를 방지할 수 있는 쉬운 옵션이 많이 있습니다.

이야기의 "재미있는" 부분은 Capital One이 애초에 구멍을 막았다면... 아무 일도 일어나지 않았을 것이라는 점입니다. 그래서 솔직히 말해서, 어떤 일이 실제로 어떻게 진행되는지 보는 것은 항상 충격적입니다. 꽤 간단하다 회사가 해킹당하는 유일한 이유가 됩니다. 특히 Capital One만큼 큰 회사는요.

그럼 해커가 내부에 있습니다. 그 다음에는 무슨 일이 일어났나요?

글쎄요, EC2 인스턴스에 침입한 후에는... 많은 문제가 발생할 수 있습니다. 누군가를 그렇게 멀리 가게 한다면 사실상 칼날 위를 걷는 것과 같습니다. 그런데 어떻게 S3 버킷에 들어왔나요? 이를 이해하기 위해 IAM 역할에 대해 논의해 보겠습니다.

따라서 AWS 서비스에 액세스하는 한 가지 방법은 사용자가 되는 것입니다. 좋아요, 이건 꽤 분명해요. 하지만 애플리케이션 서버와 같은 다른 AWS 서비스에 S3 버킷에 대한 액세스 권한을 부여하려면 어떻게 해야 할까요? 이것이 바로 IAM 역할의 역할입니다. 이는 두 가지 구성 요소로 구성됩니다.

1. 신뢰 정책 - 이 역할을 사용할 수 있는 서비스 또는 사람은 무엇입니까?
2. 권한 정책 - 이 역할은 무엇을 허용합니까?

예를 들어, EC2 인스턴스가 S3 버킷에 액세스하도록 허용하는 IAM 역할을 생성하려고 합니다. 먼저 역할은 EC2(전체 서비스) 또는 특정 인스턴스가 역할을 "인계"할 수 있는 신뢰 정책을 갖도록 설정됩니다. 역할을 수락한다는 것은 역할의 권한을 사용하여 작업을 수행할 수 있다는 의미입니다. 둘째, 권한 정책은 "역할을 맡은" 서비스/사람/리소스가 하나의 특정 버킷에 액세스하든지 Capital One의 경우처럼 3개 이상의 버킷에 액세스하든 상관없이 S700에서 무엇이든 할 수 있도록 허용합니다.

IAM 역할이 있는 EC2 인스턴스에 있으면 다음과 같은 여러 방법으로 자격 증명을 얻을 수 있습니다.

1. 다음에서 인스턴스 메타데이터를 요청할 수 있습니다. http://169.254.169.254/latest/meta-data

   무엇보다도 이 주소의 액세스 키를 사용하여 IAM 역할을 찾을 수 있습니다. 물론, 인스턴스에 있는 경우에만 해당됩니다.

2. AWS CLI를 사용하세요...

   AWS CLI가 설치된 경우 IAM 역할(있는 경우)의 자격 증명과 함께 로드됩니다. 남은 것은 인스턴스를 통해 작업하는 것뿐입니다. 물론, 신뢰 정책이 공개되어 있다면 Paige는 모든 것을 직접 할 수 있습니다.

따라서 IAM 역할의 핵심은 일부 리소스가 사용자를 대신하여 다른 리소스에 대해 작동하도록 허용하는 것입니다.

이제 IAM의 역할을 이해했으므로 Paige Thompson이 수행한 작업에 대해 이야기할 수 있습니다.

1. 방화벽의 구멍을 통해 서버(EC2 인스턴스)에 접근하게 되었습니다.

   보안 그룹/ACL이든 자체 웹 애플리케이션 방화벽이든 공식 기록에 명시된 대로 구멍을 막는 것은 아마도 매우 쉬웠을 것입니다.

2. 서버에 접속한 후 그녀는 자신이 서버인 것처럼 "마치" 행동할 수 있었습니다.
3. IAM 서버 역할은 S3가 이러한 700개 이상의 버킷에 액세스하도록 허용했기 때문에 해당 버킷에 액세스할 수 있었습니다.

그 순간부터 그녀가 해야 할 일은 명령을 실행하는 것뿐이었습니다. List Buckets그런 다음 명령 Sync AWS CLI에서...

Capital One Bank는 해킹으로 인한 피해를 100억~150억 XNUMX천만 달러로 추산합니다.. 이러한 피해를 방지하기 위해 기업은 클라우드 인프라 보호, DevOps 및 보안 전문가에 많은 투자를 합니다. 클라우드로의 전환이 얼마나 가치 있고 비용 효율적일까요? 점점 더 많은 사이버 보안 문제에 직면하더라도 42년 2019분기 전체 퍼블릭 클라우드 시장은 XNUMX% 성장했습니다.!

이야기의 교훈: 안전을 확인하세요. 정기적인 감사를 실시합니다. 보안 정책에 대한 최소 권한 원칙을 존중합니다.

(여기에 전체 법률 보고서를 볼 수 있습니다.)

출처 : habr.com