WordPress Plugin 'WP Mobile Edition' - LFI Vulnerability

1. 개요

워드프레스 WP Mobile Edition 플러그인에서 LFI와 원격 파일 열람(Remote File Disclosure)취약점이 발견되었다. 해당 취약점에 대한 정보는 www.exploit-db.com/exploits/37244/와  wpvulndb.com/vulnerabilities/7898에 정보가 업로드 되어 있다.

WP Mobile Edition은 모바일 테마를 구성하는 플러그인이기에 플러그인 설치하면 테마도 설치된다. 취약점은 바로 이 테마에서 발생한다. 그리고 이 취약점에는 한가지 문제점이 있다. 2.2.7 버전에서 이 취약점을 패치하여 2.3 버전이 릴리즈 되었음에도 문제가 발생한다. 이 부분에 대해서는 뒤에서 설명한다.

그림 1. https://wordpress.org/support/topic/exploit-not-fixed-in-23

2. LFI 취약점

LFI 취약점은 Local File Inclusion의 약자로 웹 브라우저의 명령을 통해 서버측 언어(Server Side Language - JSP, PHP, ASP 등)에 파일을 포함시켜 내용을 출력한다. 바로 그림 2의 URI 구조에서 uri.php에서 사용하는 변수 url에 웹 서버 시스템의 파일 가리키면 해당 파일의 내용을 볼 수 있는 취약점이다. exploit-db 에서 PoC로 다음과 같이 접속하면 파일 내용을 볼 수 있다.

/wp-content/themes/mTheme-Unus/css/css.php?files=../../../../wp-config.php

그림 2. wp-config.php 열람

조금 디렉터리 경로를 수정하여 /etc/passwd 파일을 열람 할 수 있다.

그림 3. /etc/passwd 열람

2.1. LFI 취약점 실험

LFI 취약점을 응용하여 커맨드 인젝션(Command Injection)을 수행하는 방법에는 여러 가지 공개되어 있지만, 이 중에 아파치2 로그를 이용한 방법에 대해 설명한다.

아파치2 로그는 /var/log/apache2 디렉터리에서 관리하며, 특히, 워드프레스 로그는 wordpress.local_access.log와 wordpress.local_error.log에 작성된다. 여기에 작성되는 이유는 워드프레스 구축하는 과정에서 다음과 같이 wordpress.conf에서 로그 생성 위치를 정의했기 때문이다.

LFI에서 로그를 사용하여 추가적인 공격을 하려면 로그 위치를 추적해야 한다. 그래서 일반적으로 웹 애플리케이션이 설치 했을 때 구성되는 기본 로그 위치는 기억해 두는 것이 좋다. 만약 로그 위치가 바뀌거나 로그 파일명이 변경되었다면 추측 공격(Guessing Attack) 외에는 방법이 없는 것 같다.

<VirtualHost *:80>
        ServerAdmin me@me.local
        ServerName wordpress.local
        DocumentRoot /var/www/wordpress
        <Directory /var/www/wordpress>
                Options -Indexes
                AllowOverride all
                Order allow,deny
                allow from all
        </Directory>

        LogLevel warn
        ErrorLog /var/log/apache2/wordpress.local_error.log
        CustomLog /var/log/apache2/wordpress.local_access.log combined
        ServerSignature Off
</VirtualHost>

Wordpress.local_access.log를 살펴보면 방금 전 진행한 LFI 취약점 로그를 볼 수 있다.

그림 4. LFI 취약점 로그 기록

이렇게 LFI 취약점으로 발생하는 로그를 이용하여 커맨드 인젝션(Command Injection)을 실행할 수 있다. 리눅스 시스템에서 id 명령을 <?system('id')?> 처럼 작성하여 운영한다.

<?system('id')?> 의 삽입은 다양한 방법이 있다. 로그 내용의 구조와 같이 GET 메소드 이후 경로, 통신 방법, HTTP 상태코드, User-Agent 등 볼 수 있다. 버프 스위트(Burp Suite)나 파로스(Paros) 같은 프록시 도구를 이용하여 User-Agent에 <?system('id')?>를 삽입할 수 있다.

URI에 <?system('id')?>를 해보았을 때 기록됨을 확인 할 수 있다. 하지만 추가 진행에 문제가 있는 것을 볼 수 있다.

그림 5. 단순 URI 삽입 후 로그 기록

URI로 삽입한 경우 아스키코드 값으로 저장이 되어 추가적인 공격을 진행이 불가능 한 것을 확인 할 수 있다. User-Agent를 변조하여 로그 기록을 살펴보자.

그림 6. User-Agent 변조 후 로그 기록

이렇게 로그를 기록하였다 하더라도 LFI 취약점을 이용해 로그를 읽도록 실행시켜 보면 동작하지 않는 것을 볼 수 있다.

/wp-content/themes/mTheme-Unus/css/css.php?files=../../../../../../../var/log/apache2/wordpress.local_access.log

그림 7. LFI를 이용하여 wordpress.local_access.log 호출 결과

이러한 원인을 분석 해보니 로그 파일이 저장된 위치와 로그 자체의 퍼미션 문제로 읽어지지 못하는 것을 확인 할 수 있다.

그림 8. 워드프레스 로그 퍼미션과 소유권

또 다른 실험을 해 보았다. Wordpress.conf 파일에서 설정한 로그 위치를 사용자 디렉터리로 옮겨서 퍼미션의 문제가 해결되는지 확인해 보았다. 하지만 다음 그림과 같이 자동으로 생성된 로그 파일의 퍼미션은 쉽게 접근할 수 없는 형태로 생성되고 관리된다.

그림 9. 사용자 디렉터리로 로그 저장 위치 변경과 퍼미션 및 소유권

또 다시 실험적으로 퍼미션을 755 로 수정하여 root가 아닌 사용자가 열람 가능하도록 해보았다. 그러니 LFI 취약점에 의해 내용을 읽었으나 User-Agent로 삽입한 <?system('id')?> 코드가 실행되지 않았음을 확인 할 수 있었다.그 이유는 잘 모르겠다. 아마 아파치 웹 애플리케이션의 최신 버전이 기본으로 이렇게 구성하는 것으로 추측해본다.

3. 대응방안

LFI 취약점 대응방안은 소스코드 수정을 통한 방법 외엔 별다른 방법이 존재하지 않는다고 한다. 우선 이 플러그인을 제작한 제작자의 패치와 비교해 보았다. 비교하기 위해 다운로드 받은 소스코드와 패치를 하고 소스코드 비교를 한다. 분석에 도움을 주는 도구로 meld 가 있다. 이 도구를 이용하여 분석한다.

그림 10. 2.2.7 버전과 2.5 버전의 디렉터리 내부의 파일 비교

소스코드 변경을 통한 대응 방법을 원하는데, 패치하는 버전이 2.2.7에서 2.5 버전으로 급격하게 상승하며 파일 삭제로 마무리 해결 하고 있다. 조금 더 검색해보니 다음 사이트에서 2.2.7 버전에서 발생한 보안 문제점을 2.3버전에서 고쳤다고 이야기 한다.

그림 11. 패치 로그 (https://wordpress.org/plugins/wp-mobile-edition/changelog/)

옛 버전은 https://github.com/wp-plugins/wp-mobile-edition/releases 에서도 구할 수 있다. 이제 2.3 버전을 다운로드 받아 다시 meld 도구를 이용하여 비교해본다.

그림 12. 2.2.7 버전과 2.3 버전의 css.php 소스코드 비교

기존에는 $file 변수에 입력되는 데이터를 검증하지 않아, 리눅스 디렉터리 경로를 추측하여 파일을 열람할 수 있었다. 하지만 패치된 내용에는 입력되는 데이터의 뒤에서 4개의 문자열이 .css 를 가지는지 검증한다. 결국 ../../../../../etc/passwd 와 같이 특정 파일을 열람하는데 끝의 4자리 문자열이 .css가 아니기 때문에 실행되지 않는 것을 볼 수 있다. 이렇게 LFI 취약점은 소스코드에서 URI 파라미터 검증을 통해 문제를 해결한다.

3.1. 문제점

• 문제점 1
  LFI/RFI 취약점은 최근에는 취약함의 범주에서 벗어나려 하고 있다. 최신 시스템의 지원인지, 웹 애플리케이션의 변화인지 그 원인은 잘 모르겠다.

• 문제점 2
  이 플러그인 취약점의 또 다른 문제점이기도 한데, 플러그인 패치를 하더라도 테마에 설치된 부분을 패치하지 않아 LFI 취약점 문제가 해결되지 않는다. 그래서 소스코드 분석을 위해 테마에 설치된 파일을 강제로 삭제 한 후 소스코드를 패치하고 활성화를 한다. (테마 생성/미생성 기준은 플러그인 활성화 유무에 의존한다.) 이러한 문제점은 결국 서두 개요의 그림 1의 내용과 같다.

3.2. 앞으로

• 앞으로 1
  아파치 로그를 이용한 커맨드 인젝션이 가능하다고 한다. 해당 부분을 실습하기 위해 실험적인 연구를 진행할 예정이다. 만약 오래된 시스템에서 이 취약점이 발생하면 그 때 연구한 내용을 바탕으로 진행할 수 있을 것 같다.

• 앞으로 2
  LFI / RFI 가 요즘 왜 취약하지 않은지, 그 이유를 조사 할 필요가 있다.

• 앞으로 3
  .css 확장자를 사용하는 것만 실행하도록 패치 되었을 경우 우회하는 방법에는 어떤 것이 있는지 상상해본다.

4. 참조

• https://t1.daumcdn.net/cfile/tistory/23053A455288D9CA17
• http://pjongy.tistory.com/90