공부용

1. AI 모델의 외부 시스템 침입

• 생성형 AI의 발전: 단순히 사용자의 질문에 답하거나 콘텐츠를 생성하는 도구 → 주어진 목표를 달성하기 위해 스스로 계획을 수립하고 필요한 도구를 호출하는 AI 에이전트(AI Agent)로 발전하고 있음.
• 변화의 효과:
  • 장점: AI의 활용 범위 확대.
  • 단점: AI에 부여된 목표와 권한이 적절하게 통제되지 않을 경우 실제 보안 사고로 이어질 수 있음.

가장 주목받은 사례)

• 오픈AI의 모델이 허깅 페이스를 침입한 사건:
  • 배경: 오픈AI가 GPT-5.6 Sol과 내부 연구용 모델의 사이버 공격 역량을 측정하기 위해 취약점을 찾고 공격하도록 설계된 ExploitGym 평가 진행.
  • 평가를 수행하던 AI가 문제를 정상적으로 해결하는 대신 평가 정답이 저장된 시스템에 직접 접근하는 경로 탐색.
  • Artifactory 프록시에서 알려지지 않았던 제로데이 취약점을 발견해 인터넷 연결 경로 확보.
  • 외부 코드 실행 환경을 거쳐 허깅 페이스의 데이터 처리 시스템과 운영 인프라까지 침투.
  • 7월 9일부터 13일까지 약 1만 7600회의 행위 수행, 실패한 경로를 바꿔가며 여러 시스템의 취약점과 인증정보를 연결해 공격 경로 완성.
• 사건 이후:
  • 엔트로픽은 사이버 보안 평가 기론 14만 1006건 재점검.
  • 클로드가 제3자 평가 파트너인 '이레귤러(Irregular)'의 테스트 환경을 통해 인터넷에 접속한 뒤 실제 기업 3곳의 운영 시스템에 무단으로 접근한 사례 확인됨.

2. AI 모델이 통제 범위를 벗어난 이유

1. 목표 달성을 우선하는 AI:
   - AI 모델에는 평가 문제를 해결하라는 목표가 주어졌으나, 어떤 방법을 사용해야 하는지 구체적으로 제한되지X.
   - 인간은 평가의 취지와 암묵적인 규칙을 이해하나, AI는 암묵적인 의도보다 명시적으로 주어진 목표와 환경의 제약을 중심으로 행동함.
   → 허용되는 행동의 범위가 정의되지 않으면 AI는 인간이 예상하지 못한 방법을 찾아낼 수 있음.
   
   
2. 강화학습과 보상 해킹:
   *강화학습: AI가 환경에서 행동하고, 그 결과로 보상이나 벌점으 받으면서 더 높은 누적 보상을 얻는 학습 방식.
   - 강화학습의 문제: 인간이 설계한 보상 기준이 실제 의도를 완전하게 표현하지 못할 수 있음.
   - 이 경우 AI는 인간이 기대한 행동 대신 보상만 높일 수 있는 예상 밖의 방법을 찾아냄.
   → 이를 보상 해킹(Reward Hacking) 또는 명세 악용(Specification Gaming)이라고 함.
   
   
3. 장기적인 계획과 도구 사용 능력의 결합: 
   - 기존 생성형 AI: 사용자의 질문에 답변을 한 뒤 작업을 종료.
   - 에이전틱 AI: 하나의 목표를 여러 단계로 나누고 필요한 도구를 선택해 실행. 그 결과를 바탕으로 다음 행동 결정.
   → 복잡한 보안 업무 자동화에는 유용, 그러나 동시에 공격 행동을 장시간 지속할 수 있게 함. 하나의 공격 방법을 차단하는 것만으로 전체 작업을 중단시키기 어려워짐.
   
   
4. 안전정치 완화와 평가 환경의 경계 실패:
   - 사이버 보안 평가 시 모델의 실제 능력을 확인하기 위해 일부 안전장치를 완화할 수 있음.
   - 안전장치를 완화한 모델에 외부 네트워크와 코드 실행 권한까지 제공하면 위험이 커짐. 실제 서비스와 연결돼 있으면 평가 범위가 현실로 확장될 수 있음.

3. 에이전틱 AI가 바꾸는 보안의 구조

1. 보조 도구에서 행위 주체로 변화하는 AI:
   - 과거: 공격자가 AI를 피싱 문구 작성, 악성코드 생성, 취약점 검색과 같은 보조 도구로 활용.
   - 현재: 에이전틱 AI가 공격 흐름 자체를 수행 가능. 목표가 주어지면 정찰, 취약점 탐색, 공격 코드 작성, 권한 상승, 내부 이동과 데이터 수집을 연속적으로 수행 가능.
   → 방어자가 감시해야 하는 대상도 변화함. 사용자 계정, 악성코드, 네트워크 트래픽 뿐만 아니라 AI 에이전트가 어떤 목표를 부여 받았고, 어떤 도구와 권한을 사용하는지, 어떤 순서로 행동하는지까지 확인해야 함.
   
   
2. AI 모델 외부로 확장되는 공격 표면:
   - 모델 뿐만 아니라 모델과 연결된 메모리, 도구, API, 데이터베이스, 인증 정보, 외부 서비스가 하나의 실행 환경을 구성함.
   - 새로운 공격 경로: 간접 프롬프트 인젝션, 악성 플러그인, MCP(Model Context Protocol) 서버를 통한 정보 탈취, 메모리와 컨텍스트 오염, 과도한 계정 권한 사용 등.
   - 공급망의 한 지점이 침해되면 전체에 영향을 줄 수 있음.
   
   
3. OWASP가 제시한 에이전틱 AI 주요 위험:
   

   

4. 콘텐츠 통제에서 행동 통제로:
   - 기존 생성형 AI 보안: 모델이 유해한 답변을 생성하는지 확인하는 데 초점.
   - 에이전틱 AI: 답변 < 행동. 정상적인 문장을 생성하더라도 그 과정에서 내부 팡리 조회/외부 서버 접속/명령 실행이 가능하기 때문.
   - 보안 통제의 단위: 프롬프트, 응답 → 목표, 계획, 도구 호출, 권한 사용, 네트워크 접속, 실행 결과로 확대할 필요O.

4. 제도 정비와 대응 방향
주요국은 고성능 AI에 대한 안전성 평가와 관리 체계를 강화하고 있음.

• 미국: 26년 6월 첨단 AI 모델의 국가안보 및 사이버 보안 위험을 평가하기 위한 행정명령(Executive Order, EO) 발표.
• 한국: AI 기본법과 시행령을 통해 일정 규모 이상의 고성능 AI에 안정성 확보 의무를 부과.

모델의 규모나 학습 연산량만으로 실제 위험 판단하는 데에 한계 존재.

→ 모델의 성능뿐 아니라 자율적으로 수행할 수 있는 작업의 길이, 외부 시스템 접근 범위, 사용 가능한 도구와 권한, 사람의 승인 없이 실행할 수 있는 행동까지 함께 고려해야 함.

→ 기업: AI 모델에 대한 콘텐츠 필터링에 머무르지 않고 평가 환경과 권한, 도구, 네트워크 공급망을 포함한 시스템 단위의 통제 체계 마련 필요.

본 게시글은 아래의 링크 속 콘텐츠를 기반으로 작성.

https://www.igloo.co.kr/security-information/%ec%9e%90%ec%9c%a8%ed%98%95-ai-%ec%8b%9c%eb%8c%80%ec%9d%98-%eb%b3%b4%ec%95%88%ea%b3%bc-%ed%86%b5%ec%a0%9c/

CTEM 정의

CTEM(지속적 위협 노출 관리): 조직의 공격 표면 전반에서 보안 노출을 지속적으로 식별하고, 실제 위협으로 이어질 가능성을 검증한 뒤, 우선순위에 따라 대응까지 연결하는 선제적 보안 관리 체계.

• 보안 이유 많이 찾아내기 < 조직의 비즈니스와 서비스 환경을 고려한 실제 침해 가능성이 높고 피해 규모가 클 수 있는 노출을 먼저 가려내고 개선

*노출(Exposure): 소프트웨어 취약점 뿐만 아니라 인터넷에 공개된 자산과 서비스/잘못된 클라우드 서비스/불필요하게 유지된 계정/과도한 권한 등 공격자가 침해에 활용할 수 있는 다양한 조건을 포함함.

취약점 관리와 CTEM 차이점

• 취약점 관리(Vulnerability Management): 시스템과 애플리케이션에서 발견된 취약점을 식별하고 기술적 심각도에 따라 패치 또는 설정 변경을 수행하는 데 초점을 둠.
• CTEM: 취약점 관리와 같은 활동을 필요로 하나, 주기적 취약점 점검 및 단발적인 조치에 더해 변화하는 보안 위협을 실시간으로 파악하고 대응하는 체계적인 보안 전략. 개별 취약점의 심각도만으로 대응 순서를 정하는 것이 아니라, 자산 중요도/외부 노출 여부/공격자의 접근 가능성/계정과 권한의 연결 관계/기존 보안 통제의 효과 등을 고려해 실제 위험도 판단.

CTEM 프로세스

조직 환경의 변화에 따라 새롭게 생기는 노출을 확인하고, 실제 위험을 검증하며 개선 결과를 다시 운영에 반영하는 반복 구조.

1. 범위 설정(Scoping): 조직이 보호해야 할 대상과 관리 범위 설정. 침해 사고 발생 시 조직의 비즈니스에 큰 영향을 줄 수 있는 영역이 우선 대상이 됨.
2. 노출 식별(Discovery): 설정된 범위 안에서 공격자가 활용할 수 있는 노출을 찾아내는 단계. 관리 목록에 포함되지 않은 외부 노출 시스템이나 미식별 자산까지 함께 확인.
3. 우선순위화(Prioritization): 식별된 모든 노출을 동일하게 처리하는 것이 아니라, 실제 위험이 큰 항목부터 우선순위를 정함.
4. 검증(Validation): 우선순위가 높은 노출이 실제로 공격에 활용될 수 있는지 확인하는 단계. 조직이 실제로 감수하고 있는 위험을 구체화하고 불필요한 부담을 줄이는 과정.
5. 개선 실행(Mobilization): 패치 적용, 권한 축소, 불필요한 계정 정리, 접근 통제 강화, 네트워크 분리 등 위험을 줄이기 위한 구체적인 조치 수행.

CTEM의 이점

1. 조직이 실제로 줄여야 할 위험을 선별하고 공격자가 활용할 수 있는 노출을 지속적으로 줄여 나가는 데에 이점이 존재.
   → 공격 표면이 넓어지고 보안 경보가 증가하는 환경에서 CTEM은 보안팀이 제한된 자원을 효과적으로 활용할 수 있도록 도움. 보안 사각지대를 줄이고 대응 우선순위를 정할 수 있음.
2. 취약점, 자산, 권한, 위협 정보, 조치 결과를 하나의 흐름으로 연결함으로써 보안 운영을 보다 체계적으로 만듦. 이를 통해 변화하는 IT 환경과 위협에 맞춰 위험을 반복적으로 확인하고 개선할 수 있음.

CTEM 운영에서 SOC

SOC(Security Operations Center, 보안운영센터): 위협 정보를 지속적으로 관찰하고 운영에 반영할 중심 조직.

• 기존: 보안 이벤트를 모니터링하고 침해 여부를 분석/대응하는 역할 수행해옴.
• CTEM 환경: 기존에 더해 공격 표면에서 확인된 노출과 실제 보안 이벤트, 위협 인텔리전스, 자산 정보를 함께 분석해 우선 대응이 필요한 위험을 식별함. 이후 조치가 이루어진 뒤에는 해당 위험이 실제로 줄어들었는지 확인하고, 그 결과를 다시 운영에 반영하는 역할을 맡을 수 있음.

본 게시글은 아래의 링크 속 콘텐츠를 기반으로 작성.

https://www.igloo.co.kr/security-information/ctem%ec%a7%80%ec%86%8d%ec%a0%81-%ec%9c%84%ed%98%91-%eb%85%b8%ec%b6%9c-%ea%b4%80%eb%a6%ac%ec%9d%b4%eb%9e%80-%eb%ac%b4%ec%97%87%ec%9d%b8%ea%b0%80%ec%9a%94/

이 글은 아래의 책을 읽고 공부 목적으로 작성됨.

칼 길버트, 벤자민 카우딜, 「AWS 침투 테스트」

AWS의 IAM 서비스: 사용자의 계정을 인증하는 여러 방법 제공함. 일반적으로 사용자 계정과 역할의 인증 지원.

• IAM 사용자: 환경에 장기적으로 접근해야 할 때 자격증명을 구성하는 방법 제공.
• 역할: 사용자/서비스/애플리케이션에 임시로 필요한 자격증명을 위임하는 방법 제공.
• AWS IAM 그룹: 자주 사용되는 공통 권한을 사용자 그룹에 부여할 수 있음. 사용자는 최대 10개 그룹에 속할 수 있음.

(1) IAM 사용자, 그룹, 역할과 관련 권한 생성

사용자 생성

1. AWS 웹 콘솔에 로그인 후 IAM 서비스 페이지로 이동
2. 사용자 추가 버튼 클릭
3. 액세스 유형:
   - 프로그래밍 방식 액세스: 사용자의 액세스 키 ID와 비밀 액세스 키 생성
   - AWS Management Console 액세스: 사용자가 AWS 웹 콘솔을 접근할 암호를 자동 생성하거나 직접 설정 가능
4. 사용자 이름 적고 다음 버튼
5. 권한 설정 3가지 옵션:
   - IAM 그룹에 사용자 추가
   - 다른 기존 사용자의 권한 복사
   - 기존 IAM 정책을 사용자에게 바로 연결
6. 검색 상자에 AmazonEC2FullAccess 입력 후 체크박스에 체크
   *해당 정책은 사용자에게 EC2 서비스 + EC2와 자주 사용되는 기타 서비스에 대한 전체 액세스 권한 제공
   IAM 정책 2가지 유형:
   - AWS가 관리하는 정책: AWS에서 관리하는 사전에 정의된 권한 집합
   - 고객이 관리하는 정책: 정책을 사용자 맞춤 설정 가능
7. 다음 버튼 - 사용자 추가 버튼
8. 액세스 키 ID와 비밀 액세스 키를 조회하거나 다운하는 옵션 제공됨

역할 또는 그룹 생성 시에도 동일한 과정으로 생성.

• 그룹: 그룹 생성 후 IAM 그룹 페이지에서 '그룹에 사용자 추가' 버튼을 클릭하면 새로운 사용자 추가 가능. 사용자가 속한 그룹 및 적용되는 정책 확인하려면 그룹 탭을 클릭
• 역할: 신뢰 관계라는 중요 기능 존재, 이는 역할을 맡을 수 있는 개체와 어떤 조건에서 발생할 수 있는지 등을 명시함.

(2) IAM 정책으로 API 액션과 접근 가능한 자원 제한

IAM 정책: 계정의 사용자, 역할, 그룹이 권한을 위임하는 방법. 권한이 허용/거부, 권한으로 사용/사용불가 자원, 규칙 적용 조건들이 명시된 JSON 문서.

IAM 정책 구조 예제(JSON)

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "MyGeneralEC2Statement"
			"Effect": "Allow",
			"Action": "ec2:*", "Resource": "*"
		},
        {
			"Effect": "Allow",
			"Action": [
            	"iam:GetUser"
			],
			"Resource": "arn:aws:iam::123456789012:user/TestUser"
		},
        {
			"Effect": "Allow",
			"Action": "sts:AssumeRole",
			"Resource": "*",
			"Condition":
            	{
				"Bool": {
					"aws:MultiFactorAuthPresent": "true"
                    }
				}
		}
	]
}

• Version 키: 사용된 정책 언어의 버전 명시. 최신 버전을 사용하는 것이 권장됨.
• Statement 키: JSON 오브젝트의 statement 목록. Statement는 각 권한의 개별 선언과 관련된 설정. Sid, Effect, Action, NotAction, Principal, Resource, Condition 키로 구성 가능.
  • Sid: 선택적 필드, 정책의 여러 statement를 구분하는 데 도움되도록 사용자가 정한 문자열. 입력 시 읽는 사람의 이해를 도울 수 있음.
  • Effect: 필수적 필드, Allow/Deny로 설정 가능. 열거된 AWS 권한이 허용됐는지, 거부됐는지를 선언함.
  • Action / NotAction: 둘 중 하나는 필수적, AWS 권한 집합 명시. 거의 NotAction보다 Action이 사용됨. 권한은 [AWS 서비스] : [권한] 형식으로 설정됨.
  • Principal: 다른 종류의 IAM 정책에 사용됨. 이 키는 statement가 적용되어야 할 자원을 나타내지만 사용자, 역할, 그룹의 권한 정책에 자동으로 포함됨.
  • Resource: 필수적 필드, Action/NotAction에서 명시된 권한들이 어떤 AWS 자원에 적용되는지에 관한 목록.
  • Condition: 선택적 필드, 어떤 조건에서 statement가 적용되는지 명시.

공격자 입장: IAM 정책이 동작하는 방법을 이해하는 것 중요.

→ 정책을 분석할 수 있으면 현재 환경에서의 정확한 접근 권한, 허용될 거 같은 특정 API 호출이 접근 거부 오류로 실패하는 원인을 파악 가능하기 때문.

키 분석 시, 공격자가 보고 싶은 구문:

{
	"Effect": "Allow",
    "Action": "*",
    "Resource": "*"
}

위의 구문은 관리자 수준의 권한을 제공함.

• * 문자는 와일드카드이고, AWS와 관련한 모든 권한을 허용함을 의미.
• 자원 역시 와일드카드로 명시됐으므로 타깃 계정의 모든 자원에 대해 API 호출 실행 가능.

인라인 정책: 관리형 정책과는 달리 사용자, 역할, 그룹에 직접 생성 가능. 그러나 보안 모범 사례에서는 인라인 정책 사용X를 권장.

(3) IAM 액세스 키 사용

AWS API 호출

1. AWS 명령줄 인터페이스(CLI) 설치:
   pip install awscli --upgrade --user
2. 설치 성공 확인:
   aws --version
3. AWS CLI에 사용자 자격 증명을 추가해 API를 호출하려면, 테스트 프로파일에 자격증명을 저장하도록 함:
   aws configure --profile [사용자명]
4. 액세스 키 ID, 비밀 키 등 값 입력: 앞에서 사용자 생성 시에 표시됐음. 리전 선택, 디폴트 추력 형식=json.
5. 해당 프로파일의 자격증명/설정 업데이트하려면 동일한 명령을 다시 실행. 프로파일 이름은 추가하는 키에 따라 적절하게 변경. 자격증명 사용 시 명심할 것은 API 호출 시 올바른 자격증명이 사용되도록 모든 AWS CLI 명령에 --profile [사용자명] 인자를 포함해야 하는 것.
6. STS(Security Token Service)에서 제공하는 명령어 GetCallerIdentity API: 모든 AWS 사용자 및 역할에서 호출 가능, IAM 정책으로 거부될 수 없음.
   aws sts get-caller-identity --profile [사용자명]
7. 위 명령 후에 출력에는 사용자 ID, 계정 ID, 현재 사용자의 ARN(Amazon 리소스 이름)이 포함됨.
   - 사용자 ID: API의 백엔드에서 사용자를 참조하는 방법.
   - 계정 ID: 사용자가 속한 계정의 ID. 이를 획득한 경우, 타깃 계정에 로그를 남기지 않으면서 계정에 존재하는 사용자와 역할을 열거 가능. 이는 사회 공학 기법에 도움됨.
   
   

서비스 목록 출력 or 참조하는 방법 확인:

#서비스가 인자로 주어지지 않았으므로 이용 가능한 모든 서비스 출력
aws a

#EC2 서비스를 타깃으로 한 실행 가능한 명령어
aws ec2 a

#설명, 제한, 지원되는 인자 등 AWS 서비스/API에 관해 더 많은 정보를 보려면 help 명령 사용
aws ec2 help

#특정 API에 관한 help
aws ec2 describe-instances help

(4) AWS API 요청 서명

대부분의 API는 AWS 서버로 전송 전 포함하고 있는 일부 데이터 서명이 필요. 이는 API 호출자의 신원 확인, 데이터 변조 방지, 재전송 공격을 막는 등의 이유가 존재.

서명은 5분 동안 유효하기 때문에 5분 이내에 요청을 가로채고 다시 전송한다면 재전송 공격은 가능.

대부분의 경우 AWS CLI, AWS SDK가 자동으로 요청 서명을 처리하므로 신경 쓸 필요X. 그러나 수동으로 API 요청을 서명해야 하는 경우가 존재.

→ AWS SDK가 지원되지 않는 프로그래밍 언어 사용하는 경우 / AWS 서버로 전송되는 요청을 완전하기 제어하기를 원하는 경우

AWS API 요청을 서명 v4로 수동 서명하는 프로세스:

1. 표준 요청 생성
2. 서명할 문자열 생성
3. 문자열의 서명 연산
4. HTTP 요청에 서명 추가

자세한 사항은 AWS 문서 확인.

이 글은 아래의 책을 읽고 공부 목적으로 작성됨.

칼 길버트, 벤자민 카우딜, 「AWS 침투 테스트」

해당 장에서는 AWS S3 버킷의 개념, 사용 용도, 구성, 접근 방법을 설명함.

(1) 첫 S3 버킷 구성

1. S3 홈페이지로 이동.
2. 버킷 만들기 클릭.
3. 버킷 이름 입력.
   -고유한 이름 사용, DNS 준수.
   -최소 3글자 ~ 최대 63글자 사이의 길이로 설정.
   -대문자/언더바 문자 허용X.
   -소문자/숫자/하이픈 포함 가능. (.) 문자를 사용해 분리 가능.
   -IP 주소 형태로 설정하지X.
4. 리전은 환경에 맞게 선택.
5. 생성 클릭: 버킷 생성됨.
6. 버킷 활성화 상태에서 오브젝트 업로드 가능.
   *오브젝트: 이미지 파일, 음악 파일, 영상 파일, 문서 등 어떤 파일이든 해당됨.
7. 오브젝트 업로드: 버킷 클릭 후 업로드 선택.
8. 오브젝트 다운로드: 오브젝트의 체크박스 선택 후 다운로드 클릭.

(2) S3 권한과 접근 API

S3 버킷이 가진 두 종류의 권한 시스템:

1. 접근 제어 정책(ACP, Access Control Policies): 웹 UI에서 주로 사용. ACP는 두 번째 권한 시스템의 단순화된 추상화 계층.
2. IAM 접근 정책: 각 권한의 상세 내용을 볼 수 있는 JSON 오브젝트로 저장되어 있음.

권한: 버킷/오브젝트에 적용될 수 있음.

• 버킷 권한: 마스터 키와 유사. 
• 오브젝트 권한: 오브젝트 접근 권한을 부여하기 위해 버킷 권한을 먼저 부여한 뒤, 오브젝트 권한을 추가로 제공해야 함.

S3 버킷 오브젝트에 접근하는 방법: WebGUI / AWS CLI

AWS CLI 사용해 오브젝트를 업로드하고 다운하는 방법:

sudo apt install awscli

▲ awscli 설치

awscli를 새로운 자격증명으로 구성하기 위해 액세스 키 ID와 비밀 액세스 키가 필요.

• AWS Management Console에 로그인.
• 페이지 우측 상단에서 계정 이름 클릭.
• 드롭다운 메뉴에서 내 보안 자격증명 클릭.
• 새 액세스 키 만들기 클릭.
• 액세스 키 표시 링크를 클릭해 액세스 키 ID와 보안 액세스 키를 복사

aws configure

▲ 해당 명령어 입력 후

• 액세스 키 ID와 비밀 액세스 키 입력. 해당 키들이 외부에 유출되지 않아야 함.
• 리전 기본 설정.
• 출력 형식은 설정할 필요X.

aws s3 ls s3://[버킷 이름]

▲ S3 버킷 콘텐츠에 접근.

aws s3 ls s3://[버킷 이름]/[폴더 이름]

▲ 버킷 안 특정 폴더를 탐색.

aws s3 cp [파일 이름] s3://[버킷 이름]/[폴더 이름]/[파일이름]

▲ S3 버킷에 파일 업로드. cp 명령어/복사하려는 파일명/목적지 버킷 전체 경로 입력.

aws s3 rm s3://[버킷 이름]/[폴더 이름]/[파일 이름]

▲ S3 버킷에서 파일 삭제. rm 명렁어/삭제하려는 파일의 전체 경로 입력.

<접근 제어 정책(ACP)/접근 제어 리스트(ACL)>

접근 제어 리스트(ACL): 방화벽 정책과 매우 유사. S3 버킷으로의 접근을 허용하는 데 사용. 각 S3 버킷은 접근 제어 리스트가 적용되어 있음.

4가지 주요 접근 제어 리스트:

• 읽기: 읽기 권한이 부여된 사용자는 버킷 내 오브젝트의 파일명/파일 크기/최근 수정 정보 등을 확인 가능. 접근 권한이 있는 오브젝트 다운 가능.
• 쓰기: 쓰기 권한이 부여된 사용자는 오브젝트를 읽거나 삭제, 업로드 가능. 권한이 없는 오브젝트를 삭제할 가능성 존재(??)
• 읽기-acp: 접근 제어 읽기 권한이 부여된 사용자는 버킷/오브젝트의 접근 제어 리스트를 볼 수 있음.
• 쓰기-acp: 접근 제어 쓰기 권한이 부여된 사용자는 버킷/오브젝트의 접근 제어 리스트를 변경할 수 있음.

오브젝트: 특정 피부여자에 대해 위 4종류 리스트 조합으로 최대 20개 정책을 설정 가능. 피부여자는 AWS 계정이나 사전에 정의된 그룹일 수 있으며, IAM 계정은 피부여자가 될 수 없음.

<버킷 정책>

버킷 정책: 각 S3 버킷에 할당돼 있으며, 버킷/오브젝트에 적용 가능.

+여러 개의 버킷이 있을 때 정책을 복사 가능하며, /data/*처럼 자원을 특정해 개별 폴더에 정책 적용 가능. 버킷 속성 페이지의 권한 탭에 들어가면 웹 UI를 사용해 S3 버킷에 정책 추가 가능.

<IAM 계정 정책>

IAM 계정 정책: 개별 IAM 계정에 접근을 설정하기 위해 사용. 접근 제어 리스트 권한이 특정 IAM 계정에만 적용돼야 하는 상황에 유용.

IAM 사용 vs 버킷 정책 사용: 동일한 권한이 여러 사용자에게 적용돼야 하는지, 여러 사용자에게 다른 권한이 적용돼야 하는지를 기준으로 판단. 후자의 경우 IAM 정책이 더 적합.

<접근 정책>

접근 정책: 사용자에게 부여된 오브젝트/버킷 권한을 상세히 표현한 것으로, JSON 형식으로 저장됨.

접근 정책의 3가지 주요 부분: "Statement", "Action", "Resource"

{
	"Version": "2008-02-27",
    "Statement": [
    {
	"Sid": "Statement",
        "Effect": "Allow",
        "Principal": {
	"AWS": "arn:aws:iam::Account-ID:user/kirit"
        },
	"Action": [
		"s3:GetBucketLocation",
            	"s3:l_istBucket",
            	"s3:GetObject"
		],
		"Resource": [
			"am:aws:s3:::kirit-bucket"
			]
		}
	]
}

▲ JSON 형식의 버킷 정책 예제.

• "Statement" 섹션: "Effect": "Allow" / "Principal" 섹션이 "AWS": "arn:aws:iam::Acount-ID:user/kirit"을 포함. "kirit" 사용자가 오브젝트에 대한 권한을 부여받았음을 의미.
• "Action" 섹션: 어떤 권한이 사용자에게 허용됐는지 보여줌.
  -"s3:ListBucket" 권한: 사용자가 버킷의 오브젝트 목록을 보는 것이 허용됨.
  -"s3:GetObject" 권한: 사용자는 버킷에서 오브젝트를 다운할 수 있음.
• Resource 부분: 어떠한 자원에 권한이 부여됐는지 나타냄.

→ kirit-bucket이라는 버킷에 대해 GetBucketLocation.ListBucket, GetObject 권한을 kirit 사용자 계정에 허용한 정책.

(3) 취약한 S3 버킷 생성

전 세계로 공개된 취약한 S3 버킷에 읽기 및 쓰기 시도하는 실습. 실습을 위해 S3 버킷을 구성하고 공개적으로 읽기/쓰기를 허용해 의도적으로 취약하도록 설정.

S3 홈페이지로 이동해 공개적으로 접근 가능한 취약한 버킷 생성.

1. 새로운 S3 버킷 생성.
2. 선택한 버킷에 대한 퍼블릭 액세스 차단 편집 설정 클릭.
3. 체크박스 모두 해제 후 저장. → 버킷에 적용된 접근 제한을 모두 제거하고자 수행.
4. 확인을 입력한 후 확인 클릭.
5. 버킷 클릭 후 사이드 패널에서 권한 탭 클릭.
6. 액세스 제어 목록으로 이동해 퍼블릭 액세스 밑 Everyone을 클릭. 사이드 패널이 열리면 체크박스 모두 체크. → AWS에게 퍼블릭 액세스를 허용하도록 지시하는 설정.
7. 저장 클릭.

취약한 버킷에 오브젝트 업로드. 예제에서는 작은 크기의 텍스트 파일을 버킷에 업로드 함.

1. 작은 텍스트 문서 생성.
2. 버킷에서 업로드를 클릭.
3. 파일을 선택 후 업로드.
4. 파일이 업로드되면 오브젝트를 클릭해 외부에서 접근이 가능한 URL 확인.

8장에서 S3 버킷을 공격하는 방법 및 공격 도구를 다룸.

1. 사전 준비

(1) IAM 계정 만들기

• 루트 계정으로 콘솔에 로그인
• AWS 화면 맨 위 검색창에 IAM이라고 검색하고 클릭해서 들어감
• 왼쪽 메뉴에서 IAM 사용자를 클릭
• 오른쪽 상단의 주황색 사용자 생성 버튼을 누름

계정 설정

• AWS Management Console에 대한 사용자 액세스 권한 제공'은 체크X (컴퓨터 명령창으로만 쓸 거라 웹 로그인 권한은 필요 없음)
• 권한 설정 방식: 정책 직접 연결
• 권한 검색창: PowerUserAccess / AmazonAthenaFullAccess (아테나 실습 목적) / AWSCloudTrail_FullAccess

(2) 비밀 키 발급

• 생성한 IAM 계정이 보일 텐데, 그 계정을 클릭
• 보안 자격 증명 탭 클릭
• 액세스 키 영역의 액세스 키 만들기 버튼 누름

액세스 키 설정

• 용도 선택: CLI
• 권장 사항 확인 체크박스에 체크
• 설명 작성 불필요
• 이 다음 액세스 키와 비밀 액세스 키 확인 가능 → 비밀 액세스 키는 다시 확인 불가하므로 따로 저장해둘 것

(3) cmd에 키 등록

aws configure

AWS Access Key ID [None]: # 방금 발급받은 액세스 키 입력 후 엔터
AWS Secret Access Key [None]: # 비밀 액세스 키 입력 후 엔터
Default region name [None]: # ap-northeast-2 입력 후 엔터 (서울 리전)
Default output format [None]: # 그냥 엔터

(4) Stratus Red Team 설치

Git 링크: https://github.com/datadog/stratus-red-team/releases

깃허브에서 운영체제에 맞는 zip 파일을 받아 압축 해제 후 stratus.exe 파일 사용 (나의 경우 Windows_x86_64)

(5) AWS 환경 구축

S3 버킷 생성

• AWS 콘솔에서 S3 서비스로 이동
• 버킷 생성 누르고, 이름 설정
• 고급 설정 - 객체 잠금 비활성화 되어있는지 확인 후 생성

CloudTrail 설정

• AWS 콘솔에서 CloudTrail 서비스로 이동
• 추적 생성 버튼 클릭
• 추적 이름 입력
• 저장 위치: 기존 S3 버킷 사용 - 위에서 만든 S3 버킷 설정
• 로그 파일 SSE-KMS 암호화: 비활성화(실습 위한 것이므로)
• 다음 - 관리 이벤트만 체크 후 생성. 데이터 이벤트 체크할 경우 비용 이슈O.

2. 깃 돌려보기

• exe 파일이 있는 폴더에서 cmd 창을 열기
• 공격 명령어 실행(2번 명령어 실행 시 해당 터미널 창에서도 aws configure를 설정해야 함)

#1. 사용 가능한 공격 리스트가 잘 나오는지 확인 (작동 테스트)
.\stratus.exe list

#2. 백도어 공격(리스트 중 있어야 함)
.\stratus.exe detonate aws.exfiltration.s3-backdoor-bucket-policy

2번 실행 과정에서 오류가 나는데, 사용자 이름이 한글인 경우 오류가 날 수 있다고 함. 그래서 임시로 아래와 같이 설정해 준다. (나의 경우에도 오류가 났음)

set AWS_ACCESS_KEY_ID=본인의_액세스_키_ID
set AWS_SECRET_ACCESS_KEY=본인의_비밀_액세스_키
set AWS_REGION=ap-northeast-2

이렇게 설정해 주고 다시 공격 명령어를 입력하면 사진처럼 뜨고 공격 로그 생성 성공

3. Amazon Athena로 공격 흔적 탐색

(1) Athena 테이블 생성

• AWS 콘솔에서 CloudTrail로 이동
• 왼쪽 메뉴에서 이벤트 기록 버튼 
• Athena 테이블 생성 버튼
• 버킷을 처음에 생성했던 버킷으로 선택 후 생성

(2) Athena 기본 세팅

• AWS 콘솔에서 Athena 서비스로 이동
• 데이터 쿼리 시작 박스 - Athena 콘솔에서 데이터 쿼리 버튼 클릭
• Athena 쿼리 편집기 열기

쿼리 편집기 설정

• 데이터 소스: AwsDataCatalog로 되어있는지 확인
• 데이터베이스: CloudTrail 로그를 파싱하기 위해 미리 만들어둔 데이터베이스 이름을 선택
• 테이블: 그 데이터베이스 안에 생성된 로그 테이블 이름이 왼쪽에 잘 보이는지 확인
• 설정 편집 버튼 - 결과 쿼리 위치: s3://[버킷 이름]/athena-results/

(3) Athena에서 쿼리 입력

• 데이터베이스: default / 테이블: cloudtrail_aws_logs 형태로 테이블이 생성된 상태
• 아래 SQL문을 입력하고 실행

SELECT 
    eventtime, 
    eventname, 
    sourceipaddress, 
    useragent,
    useridentity.arn
FROM 
    "default"."테이블_이름"
WHERE 
    eventname = 'PutBucketPolicy'
ORDER BY 
    eventtime DESC;

결과

• eventtime: 공격이 발생한 정확한 시간. 뒤에 붙은 Z는 UTC 기준이라는 뜻. KST는 UTC보다 9시간 빠르므로 한국 기준 공격 일어난 시간은 2026년 5월 20일 오전 10시 18분 16초
• eventname: 해커가 호출한 AWS API 명령어. S3 버킷의 외부 접근 권한을 제어하는 버킷 정책을 강제로 생성하거나 수정했다는 뜻. → 백도어를 심기 위해 API를 조작한 흔적.
• sourceipaddress: 공격 명령을 날린 해커의 실제 IP 주소.
• useragent: 공격자가 어떤 프로그램/도구를 사용해 AWS에 접속했는지 보여주는 식별자. 정상 사용자는 웹 브라우저/AWS CLI 사용, 여기서는 stratus-red-team이라는 시그니처가 찍혀 있음.
• arn: 공격 행위를 수행하는 데 사용된 AWS 계정의 고유 식별 주소. 실습을 위해 발급했던 IAM 계정이 도용되었음을 의미.

워게임을 풀고 공부를 진행했다.

https://hae9-9.tistory.com/125

1. 도메인/S3 구조

S3 주소 구조: https://[버킷이름].s3.amazonaws.com

• 메인 도메인: amazonaws.com
• 1차 서브(하위) 도메인: s3
• 2차 서브 도메인: [버킷 이름]

→ S3 버킷이 해당 형태로 서브도메인을 자동 생성하기 때문에 해당 구조가 나옴.

워게임 버킷 이름인 flaws.cloud를 해당 주소 구조에 넣으면

https://flaws.cloud.s3.amazonaws.com 이 나온다. 

해당 xml 파일은 원래 보안이 잘 된 버킷의 경우, 접근 거부 에러가 나야 함. 그러나 이 워게임은 권한 취약점을 이용한 문제이므로 사진처럼 확인이 가능.

2. 도메인 레코드

nslookup -type=txt flaws.cloud

-type=txt 옵션: 개발자 또는 보안 담당자가 도메인 소유권 인증이나 메모를 위해 등록한 TXT 레코드를 조회하는 명령어. 그런데 사진에서는 도메인의 기본 관리 정보를 제공함. 이는 레코드 내용이 없거나, 결과값을 제대로 찾지 못하여 던져준 값임.

→ 경우에 따라 해당 TXT 레코드에 중요한 내용이 적혀있을 수 있음. 따라서 공격자는 정보 수집 단계에서 DNS 레코드를 확인.

사이트에 들어가면 사진과 같은 화면이 나온다.

우선 별도의 단서가 없는지 f12를 눌러서 확인해 보았으나, 주석으로 html 코드에는 단서가 없다고 안내해 주고 있다.

도전 과제: 첫 번째 서브도메인을 찾기.

+일단 모든과제는 flaws.cloud의 하위 도메인임.

도메인을 잘 모르니 공식 문서를 확인함. 서브 도메인(=하위 도메인)은 도메인 이름 앞에 오는 url 부분.

예시를 들면 blog.naver.com에서

• .com: 탑 레벨 도메인(TLD)
• naver.com: 메인 도메인(Root 도메인)
• blog: 서브 도메인(하위 도메인)

도메인 목록을 조회해야 하나 싶었는데 도통 모르겠어서 힌트1을 봤다..

flaws.cloud 사이트는 S3 버킷에 호스팅되어 있으며, S3 버킷에 사이트를 호스팅할 때 버킷 이름은 도메인 이름과 일치해야 함.

→ flaws.cloud의 버킷 이름도 flaws.cloud

일단 별도의 권한을 가진 계정이 없으므로, --no-sign-request를 통해 프로필 검사를 뛰어넘었다.

aws s3 ls s3://flaws.cloud --no-sign-request

여기 보면 secret-dd02c7c.html 문서가 보인다. 해당 이름을 브라우저 주소인 flaws.cloud 뒤에 붙여 넣어 flaws.cloud/secret-dd02c7c.html으로 접속하였다.

그러면 Level 2로 넘어가는 링크가 나온다.

http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/

Level 1 교훈: S3 버킷을 다양한 권한과 기능으로 설정 가능, 정적 파일 호스팅에도 사용 가능. 그러나 버킷 권한을 너무 느슨하게 설정하는 경우가 있음.

실수를 피하는 방법: 기본적으로 S3 버킷을 생성 시 비공개로 보호됨. 웹 페이지로 접근 가능하게 하려고 정적 웹 호스팅 설정을 활성화하고 버킷 정책을 변경해 모든 사용자에게 s3:GetObject 권한을 부여. 여기서 문제되는 부분은 모든 사용자에게 목록 보기 권한을 추가한 것.

개인 공부 목적으로 작성된 글이며, 틀린 정보나 해석이 있을 수 있음.

http://flaws.cloud/

클로드 미토스(Claude Mythos): 앤트로픽(Anthropic)이 공개한 차세대 AI 모델. 

1. 클로드 미토스의 등장

클로드 미토스는 코딩 능력, 학문적 추론, 사이버 보안 영역에서 기존 모델인 클로드 오퍼스 4.6(Claude Opus 4.6)을 크게 상회하는 기능을 가짐. 현재 일반 사용자에게 개방되지 않고 일부 인프라 기업/기관에만 제한적으로 제공. 

→ 이유: 사이버 보안 위험.

실제로 미토스 공개 후 주요 국가의 정부/금융당국이 즉각 대응에 나섬. → 미토스가 보안 환경에 영향을 미칠 수 있는 변수로 받아들여짐.

클로드 미토스 프리뷰 성능: 기존 모델에 비해 비약적으로 상승했는데, 특히 실제 소프트웨어 버그를 스스로 찾아 고치는 SWE-bench PRO/이미지가 포함된 복합 코딩 문제를 해결하는 SWE-bench Multimodal에서 20%p 이상의 성능 개선을 보인 것으로 나타남. 그 외 추론 능력, 에이전트 역량을 측정하는 벤치마크에서도 기존 모델과 타사 모델을 모두 상회.

→ AI 모델의 스스로 문제를 찾아내고 해결하는 능력이 인간 수준~그 이상으로 올라온 것을 시사.

2. 미토스 프리뷰를 공개하지 못한 이유

공개하지 못한 것은 단순 성능 향상이 아니라 사이버 보안 영역에서 보여준 역량 때문으로, 오픈BSD/FF엠펙/프리BSD 등 오픈소스 소프트웨어에서 아무도 발견하지 못했던 보안 취약점을 스스로 찾아내고 공격 코드까지 작성하였음.

기술적 관점: 기존 보안 분석 도구와 미토스 프리뷰의 접근 방식은 근본적으로 다름.

• 기존 도구: 퍼징/정적 분석으로 개별 취약점을 탐지하는 데 집중.
• 미토스: 코드의 맥락을 이해한 뒤, 취약 가능성이 있는 경로를 스스로 가정하고 이를 검증.

3. 프로젝트 글래스윙 출범

• 장기적 관점: AI 기술은 공격자보다 방어자에게 더 큰 이점 제공, 전체 보안 수준 끌어올릴 가능성 O.
• 단기적 관점: 새로운 기술은 대개 공격자에 의해 먼저 활용되는 경향. 앤트로픽은 이런 변화를 사이버 보안 환경의 구조를 뒤흔드는 전환점으로 인식.

앤트로픽이 핵심 소프트웨어 인프라를 보호로 목표로 하는 프로젝트 글래스윙(Project Glasswing)을 공식 발표.

→ 구글, AWS, 애플, 리눅스재단, 마이크로소프트, 엔비디아 등을 포함한 기업들이 참여. 이들은 공동으로 AI를 활용해 주요 소프트웨어 시스템의 취약점을 사전에 식별하고 대응.

AI 보안 위협 → 국가와 금융 시스템 전반으로 확산될 수 있음.

보안 환경의 변화:

• 기존: 취약점이 발견된 이후 대응
• 전환: AI를 활용해 사전에 취약점을 탐지하고 예방하는 구조, 그리고 이를 자동화할 수 있는가에 보안 경쟁력이 달려 있음.

미토스 논란: 사이버보안 패러다임이 근본적으로 변환하고 있음을 보여주는 사례, 정부와 기업은 AI 기반 위협에 대응하기 위해 기존 체계를 재정비하고 대응 구조를 강화할 필요가 O.

본 게시글은 아래의 링크 속 콘텐츠를 기반으로 작성.

https://www.igloo.co.kr/security-information/%ED%95%B4%EC%BB%A4%EB%A5%BC-%EB%8C%80%EC%B2%B4%ED%95%A0-ai-%ED%81%B4%EB%A1%9C%EB%93%9C-%EB%AF%B8%ED%86%A0%EC%8A%A4/

워게임을 풀고 공부를 진행했다.

https://hae9-9.tistory.com/122

이전의 이미지 파일을 추출해 보고, 그 파일을 분석해 보는 실습을 진행.

추출 명령어

docker save 653711331788.dkr.ecr.us-east-1.amazonaws.com/level2:latest -o level2.tar

명령어 실행 결과:

추출한 파일을 바탕화면으로 옮긴 뒤, 압축을 풀었다.

압축 해제 후 level2/blobs/sha256 폴더에 들어가면

사진과 같은 파일이 뜬다. 이는 문제를 풀 당시에 확인했던 manifest에 나왔던 항목들과 일치하는데, 확장자가 없는 파일로 뜬다. 이 중 사이즈가 213으로 가장 작아 의심스러웠던 파일인 4fbdf...를 바탕화면에 복사한다.

후에 이름 변경으로 맨끝에 .tar.gz를 추가하여 확장자를 변경한다. 이것이 가능한 이유는 도커의 레이어가 실제로는 Gzip으로 압축된 Tar 파일이기 때문이다.

압축을 풀고 폴더를 타고 들어가면 파일이 하나 나온다.

start.sh라는 제목의 파일명이다. 의심한 파일에 기대하던 값이 나오진 않았으나, 이런 식으로 반복하면 파일을 하나하나 확인할 수 있음을 배웠다.

파일 해석:

• #!/bin/bash: 이 파일을 /bin/bash를 통해 해석하라고 운영체제에 알리는 선언문.
• &: 백그라운드 실행을 의미.
• nginx: 웹서버인 Nginx를 실행.

<학습 내용 정리>

도커 이미지 구조:

• Content Addressable Storage(내용 주소 지정 저장소): 도커는 파일 이름이 아니라 파일의 내용을 해시한 값으로 이름을 붙임.
• Immutable Layers(불변의 레이어): 한 번 만들어진 레이어는 절대 변하지 않음. 도커는 각 레이어들을 합쳐서 하나의 파일 시스템처럼 보여줌.

포렌식 관점의 주의사항:

• 데이터 영속성: 실습에서처럼, 개발자가 다음 레이어에서 비밀번호 파일을 지웠다고 하더라도 이전 레이어에는 그 파일이 그대로 남아있음.

레벨2 문제 사이트: http://container.target.flaws2.cloud/

컨테이너로 실행된다고 함. S3 버킷과 마찬가지로 AWS의 다른 리소스도 개방형 권한을 가질 수 있음.

주어진 힌트: ECR(Elastic Container Registry)의 이름이 level2

주어진 사이트에 들어가니 로그인 팝업 창이 뜨는 것을 확인할 수 있음. 아무 정보나 무작위로 넣어 로그인을 시도하니 다시 같은 팝업 창이 뜸.

취소 버튼을 누르니

사진과 같은 화면이 뜸. 401 에러는 단순 로그인 시, 제공된 정보가 없거나 잘못되어 접근이 거부되었음을 의미하는 오류이므로 정상적 에러임.

ngnix: 웹 서버, 프록시 서버, 캐싱, 분산 처리 등의 기능을 제공.

버프 스위트로 분석해본 것(로그인 시도 패킷)

메소드가 GET이고, 웹서버의 루트 경로(/)에 데이터를 요청 중.

호스트: container.target.flaws2.cloud

인증 방식: 기본 인증을 사용 중. 이는 로그인 팝업창을 통해 아이디와 비밀번호를 입력했을 때 생성되는 방식. Basic 뒤의 인코딩된 내용은 디코딩 시 내가 입력했던 값인 aaa와 bbb가 나옴.

일단 주어진 힌트라도 확인함.

ECR: 가벼운 컨테이너 런타임 실행환경을 위해 빌드된 이미지들을 저장하는 곳. → 문제 사이트 이미지가 이 컨테이너에 들어가 있는 듯함.

AWS 공식 문서: https://docs.aws.amazon.com/cli/v1/userguide/cli_ecr_code_examples.html

위의 문서에서 ECR 저장소에 있는 이미지 목록을 보기 위한 명령어가 주어짐. 여기서 저장소 이름도 주어졌으니 해당 명령어를 이름에 맞게 변형하면 아래의 명령어가 나옴.

aws ecr list-images --repository-name level2

근데 그냥 명령어를 터미널에 입력하면 aws configure를 안 했기 때문에 에러가 남. 일단 이전 단계에서 얻었던 정보를 토대로 aws configure를 시도함. (그런데 그대로 입력하면 토큰 만료가 되어 오류가 나므로, 1단계에서 사용했던 과정을 반복해서 다시 시도해봄.)

• "AWS_ACCESS_KEY_ID":"ASIAZQNB3KHGOJCB6BA5"
• "AWS_SECRET_ACCESS_KEY":"FjKkia36em5d9zzVaZeY1Vu22BlDTLoi8x1puIw1"
• "AWS_DEFAULT_REGION":"us-east-1"
• "AWS_SESSION_TOKEN":"IQoJb3JpZ2luX2VjEGUaCXVzLWVhc3QtMSJHMEUCIQCNkJ7mlX0aNNpTXf+g/RlXRz2B1LrRxW+D2vae+RKxgwIgScyir3qjyAqjtRLpB9PH0R/3sFdz/dgCBQvJ41ydPBAqywMILhADGgw2NTM3MTEzMzE3ODgiDCK+1dsvVWgd6VUk8SqoAyf70LPnog59o9R+cywl0ifncjp8fk1DQlaVq/R2WQccx6wgoD9XRMhdDpRhsI+Nke1PoKynoP9jTM71k3CSGAhJdqHYfwbJnmR3/YZScCWfwcDwPForxDGBl7JxFQgq9ucG0/3laYneExegZfJql/pmv2NT/ca+zu/Qj/5kwttjN5J9BHgqaX6SLUTflMczvgpcAGRaKa1Hokqc4Vb4TEfX9LsyhvcrI2xehyoDslH17e68cV/4HnbVxWXXCfnq7W4OgR0BlBHwphwQy4Smqfl76UfvXzq9Vyd5y5F02/bitzcLx+xJtIYjEGOYJXy63nn31TTyTpQD2QKATppi0fFGqL9r+obPMIY0XLuKnWsC+8hVmq2ykG6aWygNerOqcskFqelZhvRX+KVIdRoPb+E5aYQkbtAG3ektuRVxrJBmwkG86Z7so2zJcar4MM3dKsZ/4DHLZyrt8H3md7QWAhjcZ2/2tKPvb64hs851urrj0/fThjVHxgfeX95+tEhlnXIbBsqqLmPWoy3AVm+eV50k7sC/PqNH52npjDgbA/j7zgKgg8Rci3AwiLeM0AY6oQG8f79L9AxmckRXBkgBRw1xKQpiRu0Ai7YHN16SHr35U6SuLLCYPaRCrjVok8cZWIgfI/yqjYnhK+pP7iVn0elUPbOc14xRlz6c7F200Gzlc/u8xlzKonMl8e0ywUyE6pdO3sO9IJTVHeqNQCceIQcLsRdMWa6W8+pRYdnCp59wghhXutWA2JfxAoHwXZ3of0WNTVjq0Y3CWGnZ/1s3xGtXHA=="

→ 이전에 level1에서 구한 값을 현재 구한 값과 비교하면, 액세스 키와 시크릿 액세스 키 값만 변경된 것을 확인할 수 있음. 만일 다음에도 사용한다면 해당 값만 확인하면 될 듯하다.

아까 만든 프로필을 덧붙여서 명령어를 수정.

aws ecr list-images --repository-name level2 --profile flaws2

사진과 같이 imageDigest와 imageTag를 확인 가능. 서치해보면

imageDigest: 변경 불가능한 컨테이너 이미지의 특정 버전을 고유하게 식별하는 암호화 해시.

imageTag: 변경 가능.

구한 태그를 이용해 이미지의 Manifest를 확인.

aws ecr batch-get-image --repository-name level2 --image-ids imageTag=latest --profile flaws2

사진에서

registryId: 653711331788

해당 정보를 이용해 ECR에 로그인.

aws ecr get-login-password --region us-east-1 --profile flaws2 | docker login --username AWS --password-stdin 653711331788.dkr.ecr.us-east-1.amazonaws.com

로그인 후 이미지 내려받기(도커 실행 필요).

docker pull 653711331788.dkr.ecr.us-east-1.amazonaws.com/level2:latestdocker pull 653711331788.dkr.ecr.us-east-1.amazonaws.com/level2:latest

내려받은 이미지의 히스토리를 확인. → 실행됐던 쉘 명령어들이 나옴.

docker history --no-trunc 653711331788.dkr.ecr.us-east-1.amazonaws.com/level2:latest
IMAGE

사진처럼 결과가 나오는데 사진의 내용보다 긴 내용이 나옴.

이 중 의심스러운 내용:

/bin/sh -c htpasswd -b -c /etc/nginx/.htpasswd flaws2 secret_password

키워드에 대놓고 password가 있어서 의심스러웠음. 보니까 이게 하드코딩된 로그인 정보.

명령어 분석.

• /bin/sh -c: 뒤에 오는 문자열을 쉘 명령어로 실행하라는 의미.
• htpasswd: 아까 Nginx와 같은 웹 서버의 기본 인증(Basic Authentication)에 사용할 사용자 이름과 비밀번호를 관리하는 유틸리티.
• -b: Batch(배치) 모드. 비밀번호를 명령어 뒤에 직접 적겠다는 뜻.
• -c: Create(생성) 모드. 지정한 경로에 새로운 .htpasswd 파일을 만듦.
• /etc/nginx/.htpasswd: 생성한 비밀번호가 저장될 경로. Nginx 설정 파일에서 이 경로를 참조해 사용자를 인증함.
• flaws2: 로그인 시 사용할 아이디
• secret_password: 로그인 시 사용할 비밀번호

로그인 정보대로 팝업 창에 입력해 주면

사진과 같이 다음 레벨의 주소가 나온다.

http://level3-oc6ou6dnkw8sszwvdrraxc5t5udrsw3s.flaws2.cloud/

나온 교훈:

AWS에는 공개할 수 있는 리소스가 많이 있고, 이러한 리소스에 이름 뿐만 아니라 계정 ID, 리전까지 포함해야 하므로 무차별 대입 공격은 어려움. 그러나 공개 리소스를 사용하는 것은 가급적 피하는 것이 좋다.

개인 공부 목적으로 작성된 글이며, 틀린 정보나 해석이 있을 수 있음.

http://level2-g9785tw8478k4awxtbox9kk3c5ka8iiz.flaws2.cloud/