[AWS][Forensic][WAF] 내 테스트 서버에 공격이 들어오다(1/2)

[Secworkshop] Protecting workloads on AWS :: 평범한 직장인의 평범한 블로그 (tistory.com)

[Secworkshop] Protecting workloads on AWS

AWS Secworkshop로 테스트를 하고 있었는데 어떤 미상의 공격자에게 Web Exploit 공격이 들어왔다!!

 

의도치 않게 공격이 들어왔고, 해당 공격에 대한 공격 식별/공격 모니터링/차단 방안 그리고 향후 계획을 알아보자!!

 

□ 공격 식별

WAF Overview에서 웹서버로 유입되는 트래픽 Header 정보를 볼 수 있다.

보통 /test/index.php와 같이 기록되는데, 아래는 "shell", "rm", "wget" 등과 같은 이상한 URI이다.

WAF에서 이상한 URI를 보았지만, 나는 Test라서 별도의 Rule을 적용하지 않았기때문에 ALLOW 되었다.

즉, WAF에서 차단하지 않고 웹서버까지 그대로 이상한 URI가 전달되었다는 뜻이다.

미상의 공격 URI

 

□ 공격 시나리오(추정)

URI 정보를 나름대로 해석해보면 아래의 Flow 이다.

 1. shell command를 사용해서 /tmp로 이동 rm -rf *를 통해 전체 파일 삭제

 2. wget을 통해 http://60.11.245.1xx:46322/Mozi.a 파일 다운로드

 3. chmod를 통해 2.에서 다운로드 받은 Mozi.a에 Full 권한 부여(777)

 4. /tmp/Mozi.a 실행

 

□ 서버 포렌식

나름대로 포렌식한 결과, 1.의 과정에서 이미 실패한것으로 보인다. /tmp 경로에 파일 삭제가 안되어 있다.

전날 Inspector + Patch Manager를 테스트 한다고 CEV 취약점 등을 모두 패치 했는데, 해당 패치 덕분인지 피해는 없었다.

※ Inspector + Patch Manager 사용 방법은 아래 게시물 참고

[Secworkshop] Protecting workloads on AWS :: 평범한 직장인의 평범한 블로그 (tistory.com)

[Secworkshop] Protecting workloads on AWS

 

1. 실제 이상한 URI 공격 유입 확인(http access log를 통해 확인) : URI 존재

access log

2. 외부 임의 서버 연결 상태 확인 : 이상 없음

netstat -an 결과

3. 최근 3일 이내 생성된 파일 확인 : 이상 없음

 - find / -mtime -3 명령어로 확인 가능

 

4. CPU 또는 MEM 과점유 프로세스 확인 : 이상 없음

 - top → Ctrl+C 또는 M으로 확인 가능

 

5. 현재 실행중인 특이 프로세스 확인 : 이상 없음

 - ps -ef |more로 확인 가능

 - pstree -a를 통해서 프로세스간 호출 관계 확인 가능

 - 특이점이 있을 경우 lsof "프로세스명"으로 해당 프로세스가 물고있는 File 확인 가능

 

6. 각종 이상 유무 확인

명렁어	명렁어 설명	명령어 예시
history	사용자가 입력한 명령어 확인
last	사용자 로그인 확인
lastlog	사용자 마지막 로그인 정보
lastb	사용자 로그인 실패 이력
crontab	특정 시각 실행 설정 된 프로세스 확인	crontab -u root -l : root 권한으로 확인
arp	ARP Table 확인 가능

자세한 내용은 아래 네이버를 참고했다. 정리가 아주 잘되어 있다.

포렌식 - 리눅스 서버 침해 사고 조사 시 사용할 명령어 : 네이버 블로그 (naver.com)

포렌식 - 리눅스 서버 침해 사고 조사 시 사용할 명령어

 

추가로, Mozi.a 파일이 뭔지 PC에서 위 wget 경로를 그대로 입력해서 다운로드 받았는데 아래와 같이 V3에서 차단한다.

차단명에 Linux가 들어가는것을 보아하니, Linux용 악성코드로 추정된다.

Mozi 진단명

그리고 Mozi.a에 대해서 조금 더 조사해보니 Mirai 악성코드라고 한다!!

내 웹 응용 프로그램에 대한 10 악의적 인 요청 - 매튜 킨더스케 (matthewkindzerske.com)

10 Malicious Requests Against My Web Application

 

□ 공격 차단 방법

1. Instance의 Security Group 설정으로 필요 이상 허용되어 있는 정책 삭제

2. Firewall을 통해 필요 이상 허용되어 있는 정책 삭제

3. WAF를 통해 이상 URI 확인 후 차단

 

대략적으로 네트워크단에서 공격을 차단할 수 있는 방법은 크게 위의 3가지가 있을 것 같다.

 

나는 WAF에서 Custom Rule을 설정하여 차단하는 방법을 택하였다.

 

WAF 차단 Rule

공격 URI 중에 "Shell" 이라는 문자가 있었기 때문에, 해당 문구를 차단 Keypoint로 잡았다.

설정 후, 아래 Action을 COUNT/BLOCK/CAPTCHA3가지를 선택할 수 있다.

 

 1. COUTN : 차단은 되나, 아래와 같이 팝업이 발생하여 직접적인 차단 여부를 알려주지 않는다.

COUNT Error Page

2. BLOCK : 403 Error로 직접적인 차단 메시지를 준다.

BLOCK Error Page

하지만, 위와 같이 403 Page를 주는것은 올바르지 않다.

403 Response를 공격자가 받으면 WAF 등 보안솔루션에서 차단되었음을 알 수 있기에 추가적인 정보를 공격자에 제공하는셈이다.

 

AWS AWF에서는 이런 경우를 대비하여 Respons Body를 조정하 수 있다!!

WAF Response 조정

조정 후에는 아래와 같이 403이 뜨는게 아니라 내가 지정한 "access deny가 뜨고, state값도 내가 지정한 값을 받는다.

WAF Response 후, BLOCK Error Page

3. CAPTCHA : CAPTCHA이미지가 뜨고, CAPTCHA에 성공하면 Page 접속이 된다.

CAPTCHA 이미지

 

의도치않게 임시로 만들어놓은 웹서버에 Mirai 악성코드 공겨 시도가 있었고

그에 따른 소소한 Porensic 분석과 WAF 차단 방법을 알아보았다.

 

이론으로 배우고, 짜여져있는 실습보다 실제 공격으로 실습해보니 나름의 현장감을 알 수 있는거 같다ㅋㅋ

 

오늘 아주 보람찬 하루였다.