[AWS, 보안] 클라우드 환경에서 MITM 공격 분석

 

네트워크 보안 수업에서 진행한 과제입니다.

 

 

클라우드 환경은 현대 기업 및 기관에서 IT 인프라를 구축하고 운영하는 주요 방법 중 하나로 AWS, NHN 클라우드 등 많이 사용되고 있습니다. 하지만 클라우드 환경은 구조가 복잡하며 암호화되지 않은 API 키, 잘못 구성된 네트워크 액세스 권한 등은 MITM 공격의 통로가 될 수 있습니다. 클라우드 환경에서의 네트워크 통신은 인터넷을 통해 이루어지며, 이로 인해 중간자 공격(MITM) 과 같은 공격이 발생하여 공격자는 중간에 위치하여 통신을 가로채거나 조작하여 민감한 정보를 탈취하거나 변조할 수 있습니다. 따라서 현재 상용화되어있는 클라우드 환경에서의 MITM 공격 과정을 살펴보고, 여러가지 실제 환경의 조건이 공격에 미치는 영향을 분석합니다.

 

실험 AWS 환경 세팅

- 공격자 PC: AWS 내부의 Kali Linux EC2 인스턴스

- 공격 대상 PC: AWS 내부의 Ubuntu Linux EC2 인스턴스

- 가상 환경: AWS EC2 VPC(Virtual Private Cloud) 내부

 

1. AWS 계정 생성 및 사용자 생성하여 정책(AdministratorAccess)을 연결 해줍니다.

2. VPC (network-security-vpc) 생성 후에 VPC 안에 한 개의 퍼블릭 서브넷 (가용영역 A)을 생성 해줍니다.

3. 라우팅 테이블에 2번에서 생성한 서브넷을 연결해줍니다.

4. 인터넷 통신을 위해 인터넷 게이트웨이를 생성하여 라우팅 테이블에 연결해줍니다.

5. 공격자와 공격 대상의 EC2 인스턴스를 생성해줍니다.

• A. 공격자 AMI 이미지는 칼리, 공격 대상 AMI 이미지는 우분투를 선택해서 생성합니다.
• B. 인스턴스 생성 시에는 위에서 설정해준 서브넷1에 각각 연결을 해줍니다.
• C. 인스턴스 실행을 위한 RSA 키 페어를 생성해줍니다.

6. 각각 인스턴스의 SSH 접속을 위해 키 페어가 있는 곳으로 이동하여

$ chmod 400 “network-security-key-pair.pem” 을 실행 후에 ssh 접속으로 칼리 EC2 내부에 들 어갑니다. (우분투도 마찬가지로 접속)

7. 설정한 VPC, 서브넷, 라우팅 테이블 구성도입니다.

 

 

공격 과정

공격대상 : 우분투 EC2 환경

 

1.     공격 대상인 우분투 EC2 인스턴스 내부로 접근한 후에 아파치 서버를 설치합니다.

2.     Openssl을 통해 ssl인증서를 발급받습니다.

• A.     $ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt
  
  

3.     /etc/apache2/sites-avilable.dafult-ssl.conf 에 다음 명령어 세 줄을 추가해주고 SSL 모듈 활성화 및 apache를 재실행해줍니다.

• A.     SSLEngine on
  SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt
  SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key
  
  
• B.     $ sudo a2enmod ssl
  $ sudo a2ensite default-ssl
  $ sudo systemctl restart apache2

4.     보안그룹 설정

• A.     공격대상 서버가 외부 인터넷에 접근하기 위해서는 AWS 인스턴스 내의 보안그룹을 지정해줘야합니다.
• B.     인바운드 규칙에서  80번 HTTP 포트와 443번 HTTPS 포트를 열어주면
  퍼블릭 IP로 외부에서 접근이 가능한 것을 확인할 수 있습니다.
  
  

공격자 : 칼리 EC2 환경

1.     칼리 리눅스에 Bettercap을 설치해줍니다. $ sudo apt install bettercap

2.     Bettercap을 실행해줍니다.

• A.     $ sudo bettercap -iface eth0
• B.     >> net.probe on: 네트워크 스캐닝을 활성화합니다. 이는 Bettercap이 네트워크 내에서 사용 가능한 호스트를 탐지하도록 합니다.
• C.     >> set arp.spoof.targets 10.0.1.31: ARP 스푸핑 대상을 설정합니다. 여기서는 10.0.1. 31 IP 주소를 가진 우분투 호스트를 공격 대상으로 합니다. ARP 스푸핑으로 공격자가 피해자의 IP 주소로의 트래픽을 자신의 MAC 주소로 라우팅할 수 있도록 합니다.
• D.     >> arp.spoof on: ARP 스푸핑을 활성화하고 Bettercap을 사용하여 ARP 스푸핑을 실제로 실행하도록 해줍니다. 이제 공격자는 피해자로부터의 트래픽을 중간에서 가로챌 수 있는 상황이 되었습니다.
• E.     >> set https.proxy.sslstrip true: HTTPS 트래픽에서 SSL 스트립을 사용하여 SSL 연결을 해제하도록 설정합니다. SSL 스트립으로 HTTPS 트래픽에서 SSL을 제거하여 피해자가 보안된 연결로 인식하는 것을 방지합니다.
• F.      >> https.proxy on: HTTPS 프록시를 활성화합니다. 이 명령으로 Bettercap을 사용하여 HTTPS 프록시를 실행하도록 합니다. 이제 공격자는 피해자와 서버 간의 HTTPS 통신 을 가로챌 수 있는 상황이 되었습니다.

3.     공격 대상인 우분투의 HTTPS 가 적용된 퍼블릭 IP로 접근해보면, 보안 연결이 되지 않음을 확인할 수 있고, 우분투 IP에서 작업을 수행하면, 칼리가 데이터를 엿 볼 수 있습니다.

 

결과 분석

 

위의 과정을 통해 클라우드 환경에서 SSL MITM 공격을 수행했습니다. 공격자는 Bettercap을 사용하여 피해자의 HTTPS 트래픽을 가로채고, SSL 스트립을 통해 암호화를 해제하여 피해자가 웹 서버와 통신하는 내용을 확인할 수 있었습니다.

실험 과정에서 AWS 구성에 따라 ARP 스푸핑 문제, 외부 서버에 접근하지 못하는 문제가 있었습니다.

 

1번 AWS 구성 방식

초기 AWS 구성은 다음 그림과 같이 한 개의 VPC안에 두 개의 퍼블릭 서브넷을 두고 각각 칼리 리눅스와 우분투 리눅스를 배치한 후에 MITM 공격을 수행했습니다.

 

 

하지만 이 구성으로 설정 후 공격자인 칼리 리눅스에서 ARP 스푸핑 과정에서 공격 대상을 찾지 못한다는 문제를 발견했고, 동일한 vpc와 서브넷에 배치하여 공격을 제대로 수행할 수 있게 되었습니다.

또한 두 인스턴스 간의 트래픽을 허용해야 하므로 보안그룹의 인바운드 규칙으로 22포트, 80포트, 443 포트를 허용해줌으로 공격을 성공적으로 수행할 수 있었습니다.

2번 AWS 구성 방식

따라서 최종적으로 같은 VCP안에 한 개의 퍼블릭 서브넷에 공격자인 칼리 인스턴스와 공격 대상인 우분투 인스턴스를 배치하고, 인터넷 게이트웨이를 라우팅 테이블로 설정해주어서 외부 인터넷 접근도 허용해줌으로써 MITM 공격을 AWS환경에서 수행할 수 있었습니다.

 

 

참고문헌

-       AWS 공식 문서 : https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/what-is-amazon-vpc.html

-       AWS 구축 방법 및 칼리 리눅스 설정 :

n  https://velog.io/@osmdark/1.AWS%EC%84%9C%EB%B2%84-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0

n  https://aws.amazon.com/marketplace/pp/prodview-fznsw3f7mq7to

-       MITM 참고 블로그 :

n  https://jennana.tistory.com/472

n  https://hsm-racoon.tistory.com/62