AWS Cloud Hacking - Chapter 4. 서버 & 서버리스 진단 Part 2

A. NoSQL Injection

1. 개요

1-1. NoSQL 개요

• 유연한 수평확장(Scale-Out)
• 빠른 레이턴시
• 유연한 스키마
• 조인(join)이 불가하여 복잡한 로직 수행 시 성능 감소

 

1-2. DynamDB 개요

• AWS 클라우드 기반 NoSQL 솔루션
• INSERT, UPDATES, DELETES, QUERY 및 SCAN 작업 포함 CRUD 지원
• 데이터 검색을 위해 쿼리 및 스캔 사용
• 스캔 함수는 전체 테이블 스캔 후 ScanFilters를 기반으로 결과 리턴

 

2. 시나리오

2-1. DynamoDB 구성

• 테이블
• 기본키(Partition Key) - 무결성 보장
• 데이터 타입 - S(String), N(Number), B(Binary), SET, Bool, Null, L(List), M(Map)
• 아이템 - 저장될 데이터 값
• 인덱스 - 쿼리 성능 향상 도구

 

2-2. 취약성 발생 원인

• 사용자 입력 값 검증 미흡
• 사용자의 입력 값이 필터, 스캔 구문에 직접 실행 가능
• 데이터 타입, 특수문자에 대한 검증 미흡

 

2-3. 위협

• 사용자 정보 테이블 공격 시 사용자 민감 정보 유출

 

3. 진단 방법

3-1 .PartiQL

AWS DynamoDB에 대한 SQL 호환 쿼리 언어

 

SELECT expression [, ...]
FROM table[.index]
[ WHERE condition ] [ [ORDER BY key [DESC|ASC], ...]

 

호환 언어를 사용하는 경우, 기존 SQL injection 진단 방법과 동일하게 진단 수행

 

3-2. NoSQL 사용여부 확인

• 검색 및 쿼리 기능에 비교 연산자("EQ", "GT" 등) 사용 여부 확인
• 요청 및 응답 데이터가 json 형식으로 전송

 

3-3. NoSQL Injection 진단 방법

구분	내용
설명	검증되지 않는 사용자 입력 값이 NoSQL 쿼리 실행에 영향을 주어 개발자가 의도하지 않는 기능 실행
판단기준	개발자가 의도하지 않은 명령어를 실행, 중요 정보 획득 가능
영향	데이터베이스 내 중요 정보 탈취 가능

 

 

4. 실습

4-1. DynamoDB SQL Injection

 

• 사용자가 브라우저에서 파라미터 입력 후 Lambda로 전달
• Lambda는 파라미터를 이용하여 NoSQL 쿼리문 생성 및 실행

 

 

 

4-2. DynamoDB 비교연산자(참고)

기본 파라미터를 이용한 조건 작성

질의문에 조건절 추가하여 쿼리 

 

 

4-3. DynamoDB SQL Injection

파라미터가 그대로 쿼리문에 질의되는 것을 확인

 

• 비교연산자 선택 항목은 속성 변경 못하도록 비활성화 되어있음
• 검색 키워드 "*" 입력하여 검색
• 버프로 인터셉트, 비교 연산자를 EQ에서 GT로 변경하여 전송
• 테이블 내 모든 데이터 출력

 

5. 보안대책

5-1. 비교연산자를 이용한 테이블 조회

• 기존 파라미터를 이용해 질의 조건을 작성하는 경우 
  
  • 질의를 위한 필수 사용자 입력 값을 제외한 값은 변조가 불가능하도록 서버측 코드에 명시

 

5-2. 표현식을 이용한 테이블 조회

• 사용자 입력 값 검증 및 필터링 수행
  • 파라미터 내 "*", " " 문자에 대한 필터링 처리
  • 사용자 입력 값 바인딩하여 쿼리로 실행되지 않도록 함

 

 

B. Command Injection

1. 개요

• 취약한 애플리케이션을 통해 호스트 운영 체제에서 임의 명령을 실행
  • 양식, 쿠키, HTTP 헤더 등의 인자를 조작하여 시스템 쉘에 전달
• 실행되었을 때 명령은 애플리케이션 권한으로 동작
• 불충분한 입력 유효성 검사가 원인

2. 취약점 발생 원리

Faas 환경에서 사용자 관리 범위와 서비스 제공자 관리 범위의 차이 존재

• FaaS 환경에서 사용자는 호스트 운영 체제에 관여할 수 없음
  • AWS에서 가상 환경을 구성하며 Amazon Linux, Amazon Liunx 2 사용
• 사용자가 지정한 런타임 가상환경에서 임의 명령을 실행
  • Node, Python, Ruby, Java, Go 등 런타임 가상환경 사용 가능
• 실행되었을 때 명령은 애플리케이션을 실행한 IAM 권한으로 동작
  • 함수 실행 시점에 IAM 권한을 부여하기 위해 환경 변수에 인증 정보 저장

 

3. 영향

Lambda 인증정보 획득

• lambda 런타임 시 인증정보가 환경변수에 포함되어 업로드되므로 명령 실행을 통해 인증 정보를 가져 올 수 있음
  
  • 인증정보를 이용하여 부여된 권한에 따라 AWS 서비스를 조회, 사용 가능

 

Lambda 함수 소스코드 획득

• lambda 실행 시 쓰기 권한은 부여되지 않음
  • 하지만 코드 내에 포함된 중요 정보(키, 패스워드)를 획득 및 추가 공격 가능

 

4. 진단 방법

격리된 런타임 환경에서 명령어 실행 가능 여부 확인

• Lambda 는 격리된 런타임 환경을 제공하는 실행 환경에서 함수 호출
• 인스턴스에서 코드를 실행하는 것이 아닌, 코드를 컨테이너에 업로드하여 코드 실행

구 분	내 용
설 명	검증되지 않은 사용자 입력 값이 OS 명령어 실행에 영향을 주어 개발자가 의도하지 않은 기능 실행
판단 기준	개발자가 의도하지 않은 명령어를 실행, 중요정보 획득 가능
영 향	IAM 권한 탈취, 다른 서비스 권한 획득 가능

 

Lambda는 웹 어플리케이션과 바로 연결되지 않으며 API Gateway를 통해서 이벤트 객체를 전달받고 결과를 리턴
 

 

사용자의 입력 값이 시스템 명령어로 사용되는 경우

 

파라미터 뒤에 "&", "&&", "|", "||" 등 특수문자를 이용하여 추가 입력 가능

• 실행된 명령어의 결과 값이 출력된다면, & cat /etc/passwd, ifconfig 등 정보출력 시도
  • 결과값을 볼 수 없다면 Time-Delay 방식 사용
  • &ping -c 10 270.0.0.1

 

언어별 OS Command 함수

Lambda 실행 시 예약된 환경변수

 Lambda 실행 시 확장 가능한 환경변수

5. 실습

Lambda Command Injection 취약 코드

• Python, lambda_function.py 실행
• Python, lambda_handler(event, context)
  
  • 이벤트 핸들러
  • API Gateway로부터 파라미터 전달
    
    

시스템 함수 호출 등 취약한 설계로 취약성 발생

 

6. 진단 주의사항

 

Lambda 함수 별 Timeout 존재

• 기본 값 3초, 최대 15분까지 설정 가능
• Timeout 초과 실행 시 500에러 발생
• Time-Delay 방식 진단 시 유의

 

Lambda 실행 권한 존재

• AWS 인증정보 획득 시 전체 권한을 획득한 것이 아님
• 추가로 접근, 사용가능한 인스턴스가 있는지 확인 필요(IAM Role)
• 웹 내엣 어떤 기능을 하는지 파악 후 권한 유추 -> DB접근, 이메일 전송 등

 

7. 보안대책

민감한 작업에 직접 사용되는 사용자 입력 값은 검증 후 사용

• 외부 입력 값을 OS 명령어를 직접 사용하지 않도록 함
  • 외부 입력 값을 OS 명령어의 생성이나 선택이 필요한 경우
• 명렁어 생성에 필요한 값들을 미리 지정해 놓고 외부 입력에 따라 선택
  • 명령어를 직접 호출하는 것이 필요한 경우
• OS 명렁어 해석기에 전달되지 않도록 검증/확인하도록 구현
• 입력 값에 대한 파라미터 데이터의 “&”, “|”, ” “,”, “.” 문자에 대한 필터링 처리

 

특수문자

• &    = 명렁어 해석기에서 첫 번째 명령이 성공했을 경우에만 두 번째 명령어 실행
• |     = 첫 번째 명령어가 성공하는지 여부에 상관없이 두 번째 명령어 실행
• `     = 명령어를 계속 실행하기 전에 역 작은따음표로 둘러쌓인 명령어 우선 실행

 

 

C. XXE

1. XXE 개요

• XML 타입의 데이터를 웹 요청을 통해 전송, 서버에서 XML 외부 엔티티 처리가 가능할 때 발생
  • 사용자가 웹 애플리케이션으로 전달되는 XML 데이터를 직접 업로드/수정 가능
• 파일과 같은 서버 내부의 정보 탈취/SSRF 등 공격 수행

XML 외부 엔티티 선언 형태

• 사용자가 브라우저를 통해 XML 데이터를 입력 후 서버(lambda)로 전송
• 서버의 함수는 XML 데이터를 파싱하며, XXE 공격 발생
• XML 구문 분석기의 입력 값 검증 누락으로 발생

 

2. 시나리오

진단방안

• 전제 조건
  • 서버 요청 시 DTD(Document Type Definiton)를 선언할 수 있어야 함

 

3. 진단방법

XXE 파서 취약성

• XML 구문 분석에 사용되는 python3 모듈의 취약성

 

• XML 구문 분석에 사용되는 PHP XML 파서
  • libxml_entity_loader

 

 

4. 실습

• 입력값 변조를 통한 XXE
  • 정상적인 xml 데이터를 파싱하여 출력하는 것을 확인

 

• 파일을 지정하는 외부 엔티티 선언 후, 태그 값으로 참조하는 페이로드 작성

 

 

5. 보안대책

DTD(외부 엔티티) 비활성화

• XML 외부 객체 공격은 AWS 자체 취약성이 아닌 애플리케이션 소스코드에 의한 Injection 취약점이므로 자체 수정, 조치해야함
• 외부 엔티티 참조 기능이 필요하지 않은 경우
  • DTD 관련 설정을 비활성화
  • DTD를 비활성화할 수 없는 경우 외부 엔티티 및 외부 문서 유형을 각 파서에 고유한 방식으로 비활성화
    • factory.setFeature(http://apache.org/xml/features/disallow-doctype-decl,true);