by Toff
개요 |
실습 순서 |
이번 실습(3)에서는 기존에 진행했던 실습과는 다르게 조금의 환경 구성이 필요하다. 해당 실습 환경에서는 apache 2.4.18 버전을 사용하고 있다. 해당 버전에서는 웹 페이지의 접근 로그는 /var/log/apache2/access.log 경로에 저장된다. 그림 1-1 과 같이 /var/log/apache2/ 디렉터리의 디폴트 권한은 750으로 설정되어 있으며 소유권/그룹은 각각 root 와 adm 이다.
그림 1-1 apache2 디렉터리 권한, 소유자/그룹 확인
그림 1-2 access.log 접근 실패
LFI 취약점을 이용해 apache2 디렉터리 내의 파일을 출력하면 웹 권한(www-data)으로 접근하기에 other 권한으로 접근하게 된다. 여기서 other 의 권한은 0 이므로 그림 1-2와 같이 접근할 수 없다.
그림 1-2 access.log 접근 실패
해당 실습에서는 access.log 에 접근해야 하므로 chmod 751 /var/log/apache2/ 명령어를 삽입해 other에 접근 권한을 주도록 하자. access.log 를 이용하는 이유는 결과 분석에서 자세히 살펴보도록 하자.
권한을 준 후, access.log 에 다시 접근하면 그림 1-9와 같이 접근이 가능하며 HOST, 시간, URL, User-Agent 등의 로그가 출력된다.
그림 1-3 access.log 접근 성공
이제 프록시 툴을 사용해 access.log 에 접근할 때 요청 패킷을 가로챈 후에 그림 1-4 와 같이 User-Agent 값을 <?php system('id'); ?> 값으로 변경하고 패킷을 전송한다.
그림 1-4 요청 패킷 User-Agent 값 변조
access.log에 다시 접속하면 그림 1-5 와 같이 php 코드가 실행되면서 id 값이 출력된다. 이를 통해 Access.log 를 이용하면 php 코드를 실행할 수 있음을 알 수 있다.
그림 1-5 php 명령어 실행
위와 동일한 방법으로 그림 1-6 과 같이 공격자 PC 에서 미리 준비해둔 웹쉘을 wget 명령어를 사용해 다운로드하는 명령어를 삽입한다.
그림 1-6 11.txt(=shell.php로 저장) 웹쉘 다운로드
웹쉘은 LFI 취약점을 이용한 소스 코드가 있는 디렉터리에 다운로드(/mail-masta/inc/campaign/ 된다. 그림 1-7 과 같이 해당 경로에 접근하면 웹쉘을 실행할 수 있다.
그림 1-7 웹쉘 실행
결과 분석 |
하지만 LFI 취약점 자체의 대응 방안이 굉장히 간단해 많이 발생하지 않는 편이다. LFI 취약점이 발생한다고 해도 위에서도 말했듯이 apache2 디렉터리는 기본적으로 other 권한이 0 으로 주어져 있기에 로그에 접근조차 할 수 없어 이번 실습(3)과 같은 쉘 코드를 삽입할 수 있는 취약점은 더더욱 성공하기 힘들다.
쉘 코드를 삽입을 하기 위해 이용하는 것은 access.log 외에도 access.log와 동일하게 /proc/self/environ 의 User-Agent 값을 변경하는 방법과 PHP Wrapper 의 또 다른 기능인 input을 사용하는 방법이 있다. /proc/self/environ 도 그림 1-8 와 같이 access.log 와 동일하게 권한 문제로 인해 other 권한으로는 접근할 수 없다.
그림 1-8 environ 접근 실패
PHP Wrapper 기능인 input의 정확한 이유는 더 분석해봐야 알겠지만 사용할 수 없었다. 결론적으로 실습(3)은 관리자가 불필요한 권한을 부여했거나 www-data가 속한 소유(그룹)권을 가지고 있을 경우 노출되기 쉬운 취약점이기에 access.log 와 같은 디렉터리에 권한과 소유(그룹)권을 반드시 신경써야 한다.