웹호스팅 환경에서의 그누보드 보안 권고 사항(2) 정보
웹호스팅 환경에서의 그누보드 보안 권고 사항(2)
본문
짧은 시간에 많은 분들이 관심을 보여주셨네요
앞의 권고사항 1이 강도가 좀 약하게 느껴지셨나보네요?
이번에는 좀 더 강한 것이며, 제가 보기에는 웹호스팅 환경에서는 방어책이 없어보입니다.
만약 이글이 문제가 된다면 삭제하셔도 좋습니다.
이하 경어체는 생략합니다.
2. index.php에서 include "./dbconfig.php"; 문제
앞글에서도 설명했듯이 index.php는 공통 처리부분을 처리하고 하부 처리를한다.
그중 디비 환경설정파일을 인클루드하여 디비연결을 미리 해놓는다.
같은 서버내의 두개의 계정사용자가 각각 동일한 그누보드를 설치하였다.
편의상 1번 유저, 2번 유저라고 하고
2번 유저는 1번유저의 도메인, 계정, 그누보드의 설치 경로를 알고 있다.
1번유저의 자료를 2번 유저가 훔쳐오거나 변조할려고 한다.
2번유저는 자신의 계정에 설치된 그누보드의 index.php를 수정함으로서 그것이 가능하다.
즉 include "1번유저의 절대경로 + 그누보드 설치 경로/dbconfig.php";
라고 수정하면 2번 유저의 그누보드는
자신의 디비로 돌아가는 것이 아니라 1번 유저의 디비로 돌아가게 된다.
즉 일반 게시판의 경우에는 스킨이 없다거나 하는 문제로 안돌아갈수 있지만
관리자모드는 백프로 돌아간다.
1번유저 디비 회원에게 메일링, 회원정보 삭제 변경 모두 가능하며
디비의존적인 정보는 모두 변조 처리가능하다.
이것의 해결방법은 내가 보기에는 웹호스팅 환경에서는 없다.
앞의 권고사항 1이 강도가 좀 약하게 느껴지셨나보네요?
이번에는 좀 더 강한 것이며, 제가 보기에는 웹호스팅 환경에서는 방어책이 없어보입니다.
만약 이글이 문제가 된다면 삭제하셔도 좋습니다.
이하 경어체는 생략합니다.
2. index.php에서 include "./dbconfig.php"; 문제
앞글에서도 설명했듯이 index.php는 공통 처리부분을 처리하고 하부 처리를한다.
그중 디비 환경설정파일을 인클루드하여 디비연결을 미리 해놓는다.
같은 서버내의 두개의 계정사용자가 각각 동일한 그누보드를 설치하였다.
편의상 1번 유저, 2번 유저라고 하고
2번 유저는 1번유저의 도메인, 계정, 그누보드의 설치 경로를 알고 있다.
1번유저의 자료를 2번 유저가 훔쳐오거나 변조할려고 한다.
2번유저는 자신의 계정에 설치된 그누보드의 index.php를 수정함으로서 그것이 가능하다.
즉 include "1번유저의 절대경로 + 그누보드 설치 경로/dbconfig.php";
라고 수정하면 2번 유저의 그누보드는
자신의 디비로 돌아가는 것이 아니라 1번 유저의 디비로 돌아가게 된다.
즉 일반 게시판의 경우에는 스킨이 없다거나 하는 문제로 안돌아갈수 있지만
관리자모드는 백프로 돌아간다.
1번유저 디비 회원에게 메일링, 회원정보 삭제 변경 모두 가능하며
디비의존적인 정보는 모두 변조 처리가능하다.
이것의 해결방법은 내가 보기에는 웹호스팅 환경에서는 없다.
추천
0
0
댓글 전체
어느 공개형 웹솔루션이든 웹호스팅 환경에서는 백프로 뚫릴수 있습니다.
웹에서 서비스 되는 모든 페이지는 아무리 보안을 강화한다고 해도
최소한 웹서버가 읽을수 있는 퍼미션을 줘야하므로
같은 서버내의 계정 사용자라면 저런 방법을 사용하지 않고도 간단한 프로그램 만으로도
다른 계정사용자의 정보를 모두 볼수 있습니다.
특히나 내부경로가 노출된 공개형 웹솔루션이라면 두말할 나위가 없습니다.
하지만 이러한 형태는 실력이 조금 있으면 가능하지만
위의 권고사항들 같은 경우는 간단하게 한줄만 바꿔주면 가능한 일이므로 올린것입니다.
백프로 막을 수는 없지만 dbconfig.php의 경로를 자신만의 경로로 바꿔주는 것과
그누보드 설치 루트의 퍼미션을 설치후 711이나 701로 변경해주는것이
피해를 줄이는 가장 빠르고 최선의 방법처럼 보입니다.
하지만 의도적으로 접근한다면 막을 수 있는 방법은 없습니다.
웹에서 서비스 되는 모든 페이지는 아무리 보안을 강화한다고 해도
최소한 웹서버가 읽을수 있는 퍼미션을 줘야하므로
같은 서버내의 계정 사용자라면 저런 방법을 사용하지 않고도 간단한 프로그램 만으로도
다른 계정사용자의 정보를 모두 볼수 있습니다.
특히나 내부경로가 노출된 공개형 웹솔루션이라면 두말할 나위가 없습니다.
하지만 이러한 형태는 실력이 조금 있으면 가능하지만
위의 권고사항들 같은 경우는 간단하게 한줄만 바꿔주면 가능한 일이므로 올린것입니다.
백프로 막을 수는 없지만 dbconfig.php의 경로를 자신만의 경로로 바꿔주는 것과
그누보드 설치 루트의 퍼미션을 설치후 711이나 701로 변경해주는것이
피해를 줄이는 가장 빠르고 최선의 방법처럼 보입니다.
하지만 의도적으로 접근한다면 막을 수 있는 방법은 없습니다.
좋은글 잘 읽었습니다. 보안에 대하여 신경은 쓰고있지만...
아는게 없어서 고민입니다...
앞으로도 많은 부분 부탁드립니다.
아는게 없어서 고민입니다...
앞으로도 많은 부분 부탁드립니다.
보안에는 문외한입니다.
말씀하신...
2번유저는 자신의 계정에 설치된 그누보드의 index.php를 수정함으로서 그것이 가능하다.
즉 include "1번유저의 절대경로 + 그누보드 설치 경로/dbconfig.php";
라고 수정하면 2번 유저의 그누보드는
자신의 디비로 돌아가는 것이 아니라 1번 유저의 디비로 돌아가게 된다.
........
........
위 경우...만약..그누보드의 폴더명을 바꿔주면 되지 않을런지요?
기본적으로 gnu를 설치하게 되면..g4의경우, gnuboard4라는 폴더가 생성되지만..g3라 하더라도
현재 '테스트'를 위해서 그누를 설치하고 사용중인경우는 제외하고,
대부분 이 'gnuboard'폴더명을 자신에게 맞는 폴더명으로 변경해서 쓰는것으로 알고있습니다.
그리고 이전에 질답란에 있던글인걸로 기억하는데
dbconfig.php 파일을 다른 파일명으로 바꿔서 사용하라고 권장한 내용도 있구요.
그리고 같은 호스팅이라도 서버가 다르면 ??? ...
물론 같은 서버에 gnuboard4라는 형식으로 그누를 설치한 홈피가 여러개 있을수 있지만,
호스팅관리자가 아니고, 위처럼 그누폴더명을 달리 적용해서 사용중이라면..
자신과 같은 서버에 어떤 홈피가 그누보드를 적용해서 사용중인지를 일일히 확인할수 있을지도 조금은 의문...
따라서...
'이것의 해결방법은 내가 보기에는 웹호스팅 환경에서는 없다'....라는 부분은
전혀 해결방법이 없지 않은것은 아니지 않을까 하는 짧은 생각이 드는군요.
말씀하신...
2번유저는 자신의 계정에 설치된 그누보드의 index.php를 수정함으로서 그것이 가능하다.
즉 include "1번유저의 절대경로 + 그누보드 설치 경로/dbconfig.php";
라고 수정하면 2번 유저의 그누보드는
자신의 디비로 돌아가는 것이 아니라 1번 유저의 디비로 돌아가게 된다.
........
........
위 경우...만약..그누보드의 폴더명을 바꿔주면 되지 않을런지요?
기본적으로 gnu를 설치하게 되면..g4의경우, gnuboard4라는 폴더가 생성되지만..g3라 하더라도
현재 '테스트'를 위해서 그누를 설치하고 사용중인경우는 제외하고,
대부분 이 'gnuboard'폴더명을 자신에게 맞는 폴더명으로 변경해서 쓰는것으로 알고있습니다.
그리고 이전에 질답란에 있던글인걸로 기억하는데
dbconfig.php 파일을 다른 파일명으로 바꿔서 사용하라고 권장한 내용도 있구요.
그리고 같은 호스팅이라도 서버가 다르면 ??? ...
물론 같은 서버에 gnuboard4라는 형식으로 그누를 설치한 홈피가 여러개 있을수 있지만,
호스팅관리자가 아니고, 위처럼 그누폴더명을 달리 적용해서 사용중이라면..
자신과 같은 서버에 어떤 홈피가 그누보드를 적용해서 사용중인지를 일일히 확인할수 있을지도 조금은 의문...
따라서...
'이것의 해결방법은 내가 보기에는 웹호스팅 환경에서는 없다'....라는 부분은
전혀 해결방법이 없지 않은것은 아니지 않을까 하는 짧은 생각이 드는군요.
-. 의문점 하나
관련 동일한 웹호스팅(즉, 동일한 서버환경)의 계정 사용자들이라고 한다면,
일반적으로 계정경로(/home/계정이름 과 같은 형태)에 접근할 수 있는 권한이 없습니다.
뭐... 특정 사용자가 자신의 계정 접근권한을 777 또는 755로 설정해 놓지 않은 이상은...
-. 의문점 둘
동일한 서버의 각기 다른 사용자이며, 동일한 DB서버를 사용중이라고 해서,
타 사용자의 DB에 접근할 수 있을까요?
계정 및 DB서버 환경 설정시 최고관리자(서버관리자, root, admin ...)가
각각의 계정 사용자의 정보가 동일하지 않은 경우는,
아예 접근할 수 없도록 설정하는 것이 일반적이라고 알고 있습니다만...
관련 동일한 웹호스팅(즉, 동일한 서버환경)의 계정 사용자들이라고 한다면,
일반적으로 계정경로(/home/계정이름 과 같은 형태)에 접근할 수 있는 권한이 없습니다.
뭐... 특정 사용자가 자신의 계정 접근권한을 777 또는 755로 설정해 놓지 않은 이상은...
-. 의문점 둘
동일한 서버의 각기 다른 사용자이며, 동일한 DB서버를 사용중이라고 해서,
타 사용자의 DB에 접근할 수 있을까요?
계정 및 DB서버 환경 설정시 최고관리자(서버관리자, root, admin ...)가
각각의 계정 사용자의 정보가 동일하지 않은 경우는,
아예 접근할 수 없도록 설정하는 것이 일반적이라고 알고 있습니다만...
나스카님 에 대한 답변입니다
-의문점 하나
퍼미션에 대해 이해를 잘 못하시고 계신듯합니다.
디렉토리의 퍼미션이 701이라고 했을때 다른 계정 사용자는 디렉토리 하부의 내용을 하나도 볼수 없습니다.
하지만 하부의 것을 실행 시킬수는 있습니다.
701의 1은 어떤 사용자건 간에 해당디렉토리 하위 파일의 경로를 알고
어떤 행위를 하면 그 하위 파일의 퍼미션에 따라 실행이 되라라는 의미입니다.
1은 실행권한, 2는 쓰고, 수정하고 삭제하는 권한, 4는 파일 내용을 읽을수 있는 권한입니다.
즉 디렉토리 의 권한은 701이나 601이라하더라고
웹서비스가 가능할려면 웹서버가 읽을수 있는 권한이 있어야 하므로 이하의 파일들은
604이상의 퍼미션을 줘야 합니다.
따라서 다른 계정 사용자 역시 파일 까지의 경로를 알면 그파일의 내용을 읽어올수 있습니다.
읽어올수 있다는 것은 인클루드도 가능하다는 것입니다.
경로를 알아내는 부분은 여러가지가 있을수 있으나
/etc/passwd나 몇가지 중요 환경설정 파일들의 소유권은 root지만,
누구나 읽을수 있는 권한으로 될수 밖에 없는 경우가 많습니다.
이파일들을 읽으면, 계정 경로는 금방 알게 됩니다.
해당 계정이 사용하는 도메인만 알아도 그누보드가 어느 디렉토리에 어떻게 설치 되어있는지 알수 있습니다.
서비스를 위해 그누보드의 경로가 노출되어 있기 때문입니다.
-의문점 둘
이것도 잘 못알고 있는 것 같습니다.
mysql 디비서버의 경우 같은 locahost인 경우에는, 즉 웹서버와 디비서버가 같은 서버일 경우에는, mysql자체를 위의것이 가능하도록 수정하여 컴파일 하고 그것을 사용한다면, 나스카님의 말처럼 될수도 있을거 같습니다. 그런데 그게 만만하지는 않을겁니다.
하지만 소규모 웹호스팅회사를 제외하곤 대부분의 웹호스팅 회사들은 보안상의 이유와 성능상의 이유로
웹서버와 디비서버를 분리합니다.
그말은 웹서버에 있는 계정사용자와는 무관하다는 것입니다.
웹서버와 디비 서버가 다른 서버일경우에는 시스템 계정권한으로 접근하는 것이 아니라
소켓으로 접속을 시도하며 접속 호스트나, 디비사용자로서 사용을 허용합니다.
즉, 같은 웹서버의 다른 사용자가 같은 디비사용자명, 패스워드, 디비명으로 접속한다면
접속이 된다는 얘기입니다.
실제로 의문이 많이 나시면 자신의 서버에 동일하게 테스트 해보시면
금방 알수 있습니다.
-의문점 하나
퍼미션에 대해 이해를 잘 못하시고 계신듯합니다.
디렉토리의 퍼미션이 701이라고 했을때 다른 계정 사용자는 디렉토리 하부의 내용을 하나도 볼수 없습니다.
하지만 하부의 것을 실행 시킬수는 있습니다.
701의 1은 어떤 사용자건 간에 해당디렉토리 하위 파일의 경로를 알고
어떤 행위를 하면 그 하위 파일의 퍼미션에 따라 실행이 되라라는 의미입니다.
1은 실행권한, 2는 쓰고, 수정하고 삭제하는 권한, 4는 파일 내용을 읽을수 있는 권한입니다.
즉 디렉토리 의 권한은 701이나 601이라하더라고
웹서비스가 가능할려면 웹서버가 읽을수 있는 권한이 있어야 하므로 이하의 파일들은
604이상의 퍼미션을 줘야 합니다.
따라서 다른 계정 사용자 역시 파일 까지의 경로를 알면 그파일의 내용을 읽어올수 있습니다.
읽어올수 있다는 것은 인클루드도 가능하다는 것입니다.
경로를 알아내는 부분은 여러가지가 있을수 있으나
/etc/passwd나 몇가지 중요 환경설정 파일들의 소유권은 root지만,
누구나 읽을수 있는 권한으로 될수 밖에 없는 경우가 많습니다.
이파일들을 읽으면, 계정 경로는 금방 알게 됩니다.
해당 계정이 사용하는 도메인만 알아도 그누보드가 어느 디렉토리에 어떻게 설치 되어있는지 알수 있습니다.
서비스를 위해 그누보드의 경로가 노출되어 있기 때문입니다.
-의문점 둘
이것도 잘 못알고 있는 것 같습니다.
mysql 디비서버의 경우 같은 locahost인 경우에는, 즉 웹서버와 디비서버가 같은 서버일 경우에는, mysql자체를 위의것이 가능하도록 수정하여 컴파일 하고 그것을 사용한다면, 나스카님의 말처럼 될수도 있을거 같습니다. 그런데 그게 만만하지는 않을겁니다.
하지만 소규모 웹호스팅회사를 제외하곤 대부분의 웹호스팅 회사들은 보안상의 이유와 성능상의 이유로
웹서버와 디비서버를 분리합니다.
그말은 웹서버에 있는 계정사용자와는 무관하다는 것입니다.
웹서버와 디비 서버가 다른 서버일경우에는 시스템 계정권한으로 접근하는 것이 아니라
소켓으로 접속을 시도하며 접속 호스트나, 디비사용자로서 사용을 허용합니다.
즉, 같은 웹서버의 다른 사용자가 같은 디비사용자명, 패스워드, 디비명으로 접속한다면
접속이 된다는 얘기입니다.
실제로 의문이 많이 나시면 자신의 서버에 동일하게 테스트 해보시면
금방 알수 있습니다.
좀 전에 '혹시나' 싶어서 테스트 해 본 결과는 하단과 같습니다.
코멘트 달기 전에, 먼저 자세한 답변을 주셔서 감사드립니다.
두개의 서버에서 테스트 해 보다가 말씀하신 문제점을 체크했습니다.
A 서버의 경우,
타 계정의 정보를 끌어오지 못하는 반면,
B 라는 서버의 경우,
말씀하신 내용처럼 모조리 끌어오는 문제점을 확인했습니다.
다시 한번 유용한 정보를 알려 주셔서 '유창화'님께
감사를 드립니다.
계정 사용자의 입장에서 그나마 가장 손쉽게 제어할 수 있는 부분은,
아마도 기본설치 경로를 수정하는 방법과 아울러, DB 환경설정의 수정,
동일서버내의 타 사용자가 직접적으로 자신의 계정공간에 접근할 수 없도록,
퍼미션의 적절한 수정작업(701) 외에는 별달리 뾰족한 방법은 없을 듯 합니다.
코멘트 달기 전에, 먼저 자세한 답변을 주셔서 감사드립니다.
두개의 서버에서 테스트 해 보다가 말씀하신 문제점을 체크했습니다.
A 서버의 경우,
타 계정의 정보를 끌어오지 못하는 반면,
B 라는 서버의 경우,
말씀하신 내용처럼 모조리 끌어오는 문제점을 확인했습니다.
다시 한번 유용한 정보를 알려 주셔서 '유창화'님께
감사를 드립니다.
계정 사용자의 입장에서 그나마 가장 손쉽게 제어할 수 있는 부분은,
아마도 기본설치 경로를 수정하는 방법과 아울러, DB 환경설정의 수정,
동일서버내의 타 사용자가 직접적으로 자신의 계정공간에 접근할 수 없도록,
퍼미션의 적절한 수정작업(701) 외에는 별달리 뾰족한 방법은 없을 듯 합니다.
yesmoa님에 대한 답변입니다.
중요파일의 경로를 바꾸어 주는 것은 공개 웹솔루션을 사용할때 반드시 해야 할 내용입니다.
하지만 같은 서버내의 사용자가 의도적으로 접근하고자 한다면
그 변경한 파일의 경로도 알수 있습니다.
위에서 언급햇듯인 도메인만 알아도 그누보드가 어디에 어떤이름으로 설치되어있는지는 쉽게 알수 있습니다.
그러면 계정의 절대경로를 알고, 그누보드의 상대경로를 안다면
index.php의 경로가 나옵니다.
중요 환경설정 파일의 이름을 바꾸엇다 하더라도
index.php를 읽어서 내 계정에 다른 이름으로 저장하고 그것을 열어보면
환경설정파일이 어떤경로로 어떻게 인클루드 되는지를 쉽게 알수 있습니다.
즉, 그누보드의 구조를 공개된 버젼과 완전히 다르게 만든다면 모를까
그 상태로서 환경설정 파일의 경로만을 바꾸는 것으로는 해결될수 없습니다.
그누보드의 구조전체를 바꾸면되지 라고 한다면, 그 시간과 노력으로 그누보드를 쓸 필요없이 자신의 솔루션을
만들어서 사용하면 됩니다
중요파일의 경로를 바꾸어 주는 것은 공개 웹솔루션을 사용할때 반드시 해야 할 내용입니다.
하지만 같은 서버내의 사용자가 의도적으로 접근하고자 한다면
그 변경한 파일의 경로도 알수 있습니다.
위에서 언급햇듯인 도메인만 알아도 그누보드가 어디에 어떤이름으로 설치되어있는지는 쉽게 알수 있습니다.
그러면 계정의 절대경로를 알고, 그누보드의 상대경로를 안다면
index.php의 경로가 나옵니다.
중요 환경설정 파일의 이름을 바꾸엇다 하더라도
index.php를 읽어서 내 계정에 다른 이름으로 저장하고 그것을 열어보면
환경설정파일이 어떤경로로 어떻게 인클루드 되는지를 쉽게 알수 있습니다.
즉, 그누보드의 구조를 공개된 버젼과 완전히 다르게 만든다면 모를까
그 상태로서 환경설정 파일의 경로만을 바꾸는 것으로는 해결될수 없습니다.
그누보드의 구조전체를 바꾸면되지 라고 한다면, 그 시간과 노력으로 그누보드를 쓸 필요없이 자신의 솔루션을
만들어서 사용하면 됩니다
위의 글을 보면서 느낀점은 보안과 해킹에 대해서 다소 왜곡적으로 생각하시는것 같습니다.
또한 dbconfig.php 파일의 정보유출로인한 해킹사고는 리모트어택이 아닌 로컬어택이라는 점입니다.
또한 PT(Pen-Test Pricing:모의해킹)에서도 로컬계정을 확보만하면 거의 다 뚤리는것으로 알고있습니다.
보안수립이 잘되어있다면 뚫리지 않을수도있습니다 (정정한부분 100%라고 말한부분입니다)
예전처럼 Root 획득이 최종목적이 아닌경우가 다수 있으므로, 100% 완전한것은 있을수 없습니다만,
보안은 그러한 사고에대하여 확률을 줄이는데 있습니다.
해당 mysql 로그며 .bash_history 로그하며, apache 억세스나 에러로그하며,
시스템로그, dmesge나 security관련된 로그등 제가 알고있는 것만 수십개에 달합니다.
또한 어설프게 같은 호스팅내의 계정에서 말씀하신 내용으로 웹변조또는 DB변조를 할 경우 콩밥 먹습니다.
과연 정말 해커라면 그렇게 할까요?
뛰어난 해커의 경우 로그등 흔적을 안남기면서 말씀하신 내용을 이용하여 해킹할수도있습니다.
그러나 그러한 경우는 극소수에 지나지 않을꺼 같습니다.
따라서
방어책이 없다는말씀은 인터넷에서 웹서비스를 하지 말자는것과 같습니다.
항상문제는 발생할수 있으며, 이때 얼만큼 빠르게 대처하느냐가 관건이지,
절대 안전하지 않다고 말하는것은 잘못된 생각이라고 봅니다.
또한 일부 웹호스팅 업체중에는 chroot나 개별 그룹권한을 적용하거나,
버추얼 웹계정을 이용하여 마치 독립된 서버를 이용하는것처럼
사용자의 상호 접근을 차단하는경우도 있습니다.
물론 보안정책을 높이면 그만큼 보안사고에 대한 확률이 낮아집니다만
반대로 사용자의 불편은 더욱 가중된다고 말씀드리고 싶습니다.
보안에 대한 이슈를 일으키는 생각은 좋으나, 좀더 신중하게 글을 적었더라면 어땠을까 하는생각이 듭니다.
여기서부터는 보안또는 해킹관련된 저의 글또는 회원들의 글들입니다.
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=46845
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=48189
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=48196
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=49920
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=50242
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=52423
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=52433
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=52510
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=56145
=> dbconfig.php 파일정보 유출에 관한 포럼내용
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=57143
=> MD5 크랙에관련된 내용
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=57172
=> dbconfig.php 유출에관련된 질문과 phpschool의 정보링크
http://sir.co.kr/bbs/board.php?bo_table=g3_qa&wr_id=18897
=> dbconfig.php에 관련된 나스카님의 글
http://sir.co.kr/bbs/board.php?bo_table=g3_qa&wr_id=10490
=> dbconfig.php로 인한 정보유출에 관한 비비킹님의 글
http://sir.co.kr/bbs/board.php?bo_table=g4_qa&wr_id=3927
또한 dbconfig.php 파일의 정보유출로인한 해킹사고는 리모트어택이 아닌 로컬어택이라는 점입니다.
또한 PT(Pen-Test Pricing:모의해킹)에서도 로컬계정을 확보만하면 거의 다 뚤리는것으로 알고있습니다.
보안수립이 잘되어있다면 뚫리지 않을수도있습니다 (정정한부분 100%라고 말한부분입니다)
예전처럼 Root 획득이 최종목적이 아닌경우가 다수 있으므로, 100% 완전한것은 있을수 없습니다만,
보안은 그러한 사고에대하여 확률을 줄이는데 있습니다.
해당 mysql 로그며 .bash_history 로그하며, apache 억세스나 에러로그하며,
시스템로그, dmesge나 security관련된 로그등 제가 알고있는 것만 수십개에 달합니다.
또한 어설프게 같은 호스팅내의 계정에서 말씀하신 내용으로 웹변조또는 DB변조를 할 경우 콩밥 먹습니다.
과연 정말 해커라면 그렇게 할까요?
뛰어난 해커의 경우 로그등 흔적을 안남기면서 말씀하신 내용을 이용하여 해킹할수도있습니다.
그러나 그러한 경우는 극소수에 지나지 않을꺼 같습니다.
따라서
방어책이 없다는말씀은 인터넷에서 웹서비스를 하지 말자는것과 같습니다.
항상문제는 발생할수 있으며, 이때 얼만큼 빠르게 대처하느냐가 관건이지,
절대 안전하지 않다고 말하는것은 잘못된 생각이라고 봅니다.
또한 일부 웹호스팅 업체중에는 chroot나 개별 그룹권한을 적용하거나,
버추얼 웹계정을 이용하여 마치 독립된 서버를 이용하는것처럼
사용자의 상호 접근을 차단하는경우도 있습니다.
물론 보안정책을 높이면 그만큼 보안사고에 대한 확률이 낮아집니다만
반대로 사용자의 불편은 더욱 가중된다고 말씀드리고 싶습니다.
보안에 대한 이슈를 일으키는 생각은 좋으나, 좀더 신중하게 글을 적었더라면 어땠을까 하는생각이 듭니다.
여기서부터는 보안또는 해킹관련된 저의 글또는 회원들의 글들입니다.
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=46845
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=48189
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=48196
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=49920
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=50242
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=52423
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=52433
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=52510
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=56145
=> dbconfig.php 파일정보 유출에 관한 포럼내용
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=57143
=> MD5 크랙에관련된 내용
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=57172
=> dbconfig.php 유출에관련된 질문과 phpschool의 정보링크
http://sir.co.kr/bbs/board.php?bo_table=g3_qa&wr_id=18897
=> dbconfig.php에 관련된 나스카님의 글
http://sir.co.kr/bbs/board.php?bo_table=g3_qa&wr_id=10490
=> dbconfig.php로 인한 정보유출에 관한 비비킹님의 글
http://sir.co.kr/bbs/board.php?bo_table=g4_qa&wr_id=3927
prosper 님 답글 잘 보았습니다.
제가 다루고자 했던 부분은 해킹이 아닙니다.
안전하지 않다라는 것이며, 왜 그런일이 일어나는지에 대해 얘기 하고 싶었습니다.
그러나 이전에 많은 분들이 관련 부분에 대해 말씀을 나누셨는지에 대해서는 제가 미처 살펴 보지 못했습니다.
그러나 prosper 님 역시 잘 못 알고 있는 부분이 있는 것 같습니다.
위의 내용은 다른 계정 사용자가 쉘상이나 다른 프로그램으로 어떤 일을 한것이 아니라
자신의 계정에 설치된 그누보드를 웹에서 실행시켰을 뿐이라는 것입니다.
chroot나 개별 그룹 적용이 웹서버의 접근을 막을 수 있는 방법인가요?
그리고 디비로그나 많은 로그들이 공개되고 많이 설치된 그누보드를 웹에서 실행한것에 대해서 어떤 로그가 남는 다는 것이죠?
공인된 사용자 웹서버가 실행됨으로서 남기는 로그에는 웹서버가 어떤일을 했는지에 대한 것은 기록될수 있어도 어느 계정사용자의 어느 파일이 웹서버를 통해서 어떤일을 했느지에 대한 것은 기록되지 않는 것으로 알고 있습니다.
만약 제가 부족하여 잘 모르는 부분이 있다면 리플로서 답글 부탁드립니다.
그리고 prosper님의 말로서 그런 위험성이 없어지는 것이 아니라,
간단히 한줄 수정으로 많은 것이 일어날수 있다는 점과
변조는 아니더라도 디비백업 정도는 항상 일어날 수 있는일입니다.
누군가 가져간 그 정보가 어느날 나에게 스팸메일로서 돌아올수 도 있는 것이고
내 사이트의 회원들에게도 스팸메일이나 악성 전화로 시달리게 하는 정보가 될수도 있는 것입니다.
(물론 스팸메일 보내는 사람이나 악성 전화, 문자 보내는 사람도 기천만원 이상의 벌금과 콩밥을 먹는 경우가 있습니다.
하지만 무수히 일어나죠)
공개된 웹프로그램을 자신의 입맛데로 수정하는 것과 추가, 삭제하는 것 에 대한 것은 누구도 이상하게 생각하지 않습니다.
위와같은 부분은 모든 웹프로그램이 공통적으로 가지는 문제점이지만
제로보드나 그누보드와 같이 사용자층이 넓은 공개 프로그램은 사이트 내에나 설치 메뉴얼 정도에
해당 내용에 대한 부분이 들어가 있어야 한다고 생각합니다.
제가 다루고자 했던 부분은 해킹이 아닙니다.
안전하지 않다라는 것이며, 왜 그런일이 일어나는지에 대해 얘기 하고 싶었습니다.
그러나 이전에 많은 분들이 관련 부분에 대해 말씀을 나누셨는지에 대해서는 제가 미처 살펴 보지 못했습니다.
그러나 prosper 님 역시 잘 못 알고 있는 부분이 있는 것 같습니다.
위의 내용은 다른 계정 사용자가 쉘상이나 다른 프로그램으로 어떤 일을 한것이 아니라
자신의 계정에 설치된 그누보드를 웹에서 실행시켰을 뿐이라는 것입니다.
chroot나 개별 그룹 적용이 웹서버의 접근을 막을 수 있는 방법인가요?
그리고 디비로그나 많은 로그들이 공개되고 많이 설치된 그누보드를 웹에서 실행한것에 대해서 어떤 로그가 남는 다는 것이죠?
공인된 사용자 웹서버가 실행됨으로서 남기는 로그에는 웹서버가 어떤일을 했는지에 대한 것은 기록될수 있어도 어느 계정사용자의 어느 파일이 웹서버를 통해서 어떤일을 했느지에 대한 것은 기록되지 않는 것으로 알고 있습니다.
만약 제가 부족하여 잘 모르는 부분이 있다면 리플로서 답글 부탁드립니다.
그리고 prosper님의 말로서 그런 위험성이 없어지는 것이 아니라,
간단히 한줄 수정으로 많은 것이 일어날수 있다는 점과
변조는 아니더라도 디비백업 정도는 항상 일어날 수 있는일입니다.
누군가 가져간 그 정보가 어느날 나에게 스팸메일로서 돌아올수 도 있는 것이고
내 사이트의 회원들에게도 스팸메일이나 악성 전화로 시달리게 하는 정보가 될수도 있는 것입니다.
(물론 스팸메일 보내는 사람이나 악성 전화, 문자 보내는 사람도 기천만원 이상의 벌금과 콩밥을 먹는 경우가 있습니다.
하지만 무수히 일어나죠)
공개된 웹프로그램을 자신의 입맛데로 수정하는 것과 추가, 삭제하는 것 에 대한 것은 누구도 이상하게 생각하지 않습니다.
위와같은 부분은 모든 웹프로그램이 공통적으로 가지는 문제점이지만
제로보드나 그누보드와 같이 사용자층이 넓은 공개 프로그램은 사이트 내에나 설치 메뉴얼 정도에
해당 내용에 대한 부분이 들어가 있어야 한다고 생각합니다.
참고로 말씀 드리자면
디비컨피그 파일만의 인코딩, 암호화등등은 모두 의미가 없습니다.
모두 웹서버가 해석가능하기 때문입니다.
또한 그것을 해독할 수 있는 키나 함수 같은 것을 그누보드내에서 제공하여 하므로 의미가 없습니다.
풀리지 않는 암호화는 디비 커넥팅 정보로는 의미가 없습니다.
또 idex.php를 인코딩 한다고 해도
자신의 계정에 설치후 간단한 파일조작만으로 어떤 파일이 어떻게 인클루드 되어서 사용되어진다는 것을
알수 있습니다.
따라서 웹설치는 없어져야 하고, 중요파일의 경로는 수정할 수 있어야 하며, 쉘상에서 사용할수 있는 인코더를 같이 배포한다거나 호스팅사에서 제공하여야만 문제가 해결될수 있다고 생각합니다.
물론 인코딩된 내용은 아파치 웹서버 자체가 해독할수 있어야 겠죠
그누보드에 포함된 것이 해독하고 실행시킨다면 의미가 없습니다.
한가지더 제가 다른 계정의 파일을 읽어온다는 것은 쉘을 통해 읽어온다는 얘기가 아닙니다.
그누보드 구성 파일중 아무거나 하나 수정하여 읽어온다는 것입니다.
남는 로그는 그누보드의 구성파일중 하나가 웹에서 실행 된것 뿐입니다
디비컨피그 파일만의 인코딩, 암호화등등은 모두 의미가 없습니다.
모두 웹서버가 해석가능하기 때문입니다.
또한 그것을 해독할 수 있는 키나 함수 같은 것을 그누보드내에서 제공하여 하므로 의미가 없습니다.
풀리지 않는 암호화는 디비 커넥팅 정보로는 의미가 없습니다.
또 idex.php를 인코딩 한다고 해도
자신의 계정에 설치후 간단한 파일조작만으로 어떤 파일이 어떻게 인클루드 되어서 사용되어진다는 것을
알수 있습니다.
따라서 웹설치는 없어져야 하고, 중요파일의 경로는 수정할 수 있어야 하며, 쉘상에서 사용할수 있는 인코더를 같이 배포한다거나 호스팅사에서 제공하여야만 문제가 해결될수 있다고 생각합니다.
물론 인코딩된 내용은 아파치 웹서버 자체가 해독할수 있어야 겠죠
그누보드에 포함된 것이 해독하고 실행시킨다면 의미가 없습니다.
한가지더 제가 다른 계정의 파일을 읽어온다는 것은 쉘을 통해 읽어온다는 얘기가 아닙니다.
그누보드 구성 파일중 아무거나 하나 수정하여 읽어온다는 것입니다.
남는 로그는 그누보드의 구성파일중 하나가 웹에서 실행 된것 뿐입니다
유창화님께서 이글에서 알리고자 하는 의도가 무엇인가요?
80포트는 열려있는것 만으로도 위험하니까 서비스를 중단해라? 라는 뜻인가요?
원론적인 이야기를 하신다면 아마 끝이 안날뜻 싶네요.
저의 반박글 중 로그와 관련된부분은 다소 복합적이며,
말씀하신대로 계정에서 인클르드의 경우는 불가능할수도 있습니다
하지만 님께서는 100%라고 확신하시는군요..
나름대로 보안과 해킹에 관한 지식을 보유하고 있다고 생각하고 있으며,
관심사에 대한 많은 습득을 위해 노력하고있는 사람입니다만
보안관련 업을 하는 사람중에 100% 확신하는 사람은 아직 보질 못했습니다.
예를 들어 aaa 계정과 bbb의 계정이 있으며
각각 소유권과 그룹설정이 다음과 같다면 말씀하신 서버내 타계정 디비커넥팅이 가능할까요?
drwxr-x--- aaa aaa public_html
drwxr-x--- bbb bbb public_html
이때 그룹 aaa와 bbb는 버추얼 계정으로 각각 apache 실행권한을 가지고 있습니다.
즉! 아파치 데몬이 2개가 다른계정으로 동작하고 있다고 표현하면 이해가되실런지요?
하지만 실제로는 하나의 데몬이 버추얼계정으로 동작하고 있는거지요
따라서 위와 같은경우 웹에서 엑세스는 가능하지만 로컬내의 include는 불가능하게 됩니다.
그렇다면, 웹에서 php 인젝션만 남게 되는데
이때는 어태커의 URL이 apache의 억세스로그에 고스란히 기록되게 됩니다.
웹에서 접근의 경우는 웹경로에서 접근못하는 DMZ로서 어느정도 방비가 가능합니다.
여러가지 보안기법이 있으나 언급은 피하겠습니다.
또한 접속자의 암호화역시 복호화 해야된다는 이유로 100% 보안에 안전하다고 말할수 없으나
단순히 노바디쉘 또는 로컬의 타계정에서 평문화된 db접속자 정보를 쉽게 볼수없게 하는 하나의 수단은 될수 있습니다.
얼마나 보안에 대해서 심도있는 스킬을 가지고 계신지는 모르겠으나,
원글에서는 마치 그누보드가 보안에 취약한것처럼 위화감을 조성하셨는데..
자신을 제외한 모두가 잘못생각하고 있다고 판단하는 사고방식이야 말로 자가당착에 빠진것이라 생각됩니다.
원글의 내용과 저의 반박글로 인해 적으신 댓글의 내용이 다소 모순되어 보입니다.
또한 그러한 지식이라면 KISA 또는 krcert에 관련된 내용을 질의 해보심이 어떨까 합니다.
저의 미천한 지식으로 님께서 반박하신 내용에 대해서 답변하기가 힘이 듭니다.
이와 관련하여 국내 언더해커그룹과 보안관련 커뮤니티에 이와 관련한 주제를 올려보도록 하겠습니다.
어떤 답변들이 쏟아져 나올찌 저도 기대가 큽니다.
잘 알지 못하는 지식으로 글을 단것에 대해서 사과드립니다.
이와 관련하여 더이상은 답변 달지 않도록 하겠습니다.
ps. 님께 쪽지나 메일로 위의 주제를 Post한 URL을 알려드리도록 하겠습니다.
피드백되는 내용을 보시는게 중요할꺼 같다고 생각되어서입니다.
80포트는 열려있는것 만으로도 위험하니까 서비스를 중단해라? 라는 뜻인가요?
원론적인 이야기를 하신다면 아마 끝이 안날뜻 싶네요.
저의 반박글 중 로그와 관련된부분은 다소 복합적이며,
말씀하신대로 계정에서 인클르드의 경우는 불가능할수도 있습니다
하지만 님께서는 100%라고 확신하시는군요..
나름대로 보안과 해킹에 관한 지식을 보유하고 있다고 생각하고 있으며,
관심사에 대한 많은 습득을 위해 노력하고있는 사람입니다만
보안관련 업을 하는 사람중에 100% 확신하는 사람은 아직 보질 못했습니다.
예를 들어 aaa 계정과 bbb의 계정이 있으며
각각 소유권과 그룹설정이 다음과 같다면 말씀하신 서버내 타계정 디비커넥팅이 가능할까요?
drwxr-x--- aaa aaa public_html
drwxr-x--- bbb bbb public_html
이때 그룹 aaa와 bbb는 버추얼 계정으로 각각 apache 실행권한을 가지고 있습니다.
즉! 아파치 데몬이 2개가 다른계정으로 동작하고 있다고 표현하면 이해가되실런지요?
하지만 실제로는 하나의 데몬이 버추얼계정으로 동작하고 있는거지요
따라서 위와 같은경우 웹에서 엑세스는 가능하지만 로컬내의 include는 불가능하게 됩니다.
그렇다면, 웹에서 php 인젝션만 남게 되는데
이때는 어태커의 URL이 apache의 억세스로그에 고스란히 기록되게 됩니다.
웹에서 접근의 경우는 웹경로에서 접근못하는 DMZ로서 어느정도 방비가 가능합니다.
여러가지 보안기법이 있으나 언급은 피하겠습니다.
또한 접속자의 암호화역시 복호화 해야된다는 이유로 100% 보안에 안전하다고 말할수 없으나
단순히 노바디쉘 또는 로컬의 타계정에서 평문화된 db접속자 정보를 쉽게 볼수없게 하는 하나의 수단은 될수 있습니다.
얼마나 보안에 대해서 심도있는 스킬을 가지고 계신지는 모르겠으나,
원글에서는 마치 그누보드가 보안에 취약한것처럼 위화감을 조성하셨는데..
자신을 제외한 모두가 잘못생각하고 있다고 판단하는 사고방식이야 말로 자가당착에 빠진것이라 생각됩니다.
원글의 내용과 저의 반박글로 인해 적으신 댓글의 내용이 다소 모순되어 보입니다.
또한 그러한 지식이라면 KISA 또는 krcert에 관련된 내용을 질의 해보심이 어떨까 합니다.
저의 미천한 지식으로 님께서 반박하신 내용에 대해서 답변하기가 힘이 듭니다.
이와 관련하여 국내 언더해커그룹과 보안관련 커뮤니티에 이와 관련한 주제를 올려보도록 하겠습니다.
어떤 답변들이 쏟아져 나올찌 저도 기대가 큽니다.
잘 알지 못하는 지식으로 글을 단것에 대해서 사과드립니다.
이와 관련하여 더이상은 답변 달지 않도록 하겠습니다.
ps. 님께 쪽지나 메일로 위의 주제를 Post한 URL을 알려드리도록 하겠습니다.
피드백되는 내용을 보시는게 중요할꺼 같다고 생각되어서입니다.
간단히 생각해도 무리일꺼 같다는 생각이 드는데요.
1. dbconfig.php 위치를 알아 상대방 DB에 커넥트가 된다고 해도 mysql 관리자 아이디/비번을 알 수 없는게
아닌가요. php 파일은 서버에서 해석하고 나온 결과물인 걸로 알고 있습니다만.
2. 상대편 디비를 쓰니깐 상대편 그누보드 관리자 아이디/비번을 알아야 관리자 권한을 얻을 수 있으므로
관리자 로그인이 안되지 않나요? 간단히 생각해도 무리일꺼 같다는 생각이 드는데요.
1. dbconfig.php 위치를 알아 상대방 DB에 커넥트가 된다고 해도 mysql 관리자 아이디/비번을 알 수 없는게
아닌가요. php 파일은 서버에서 해석하고 나온 결과물인 걸로 알고 있습니다만.
2. 상대편 디비를 쓰니깐 상대편 그누보드 관리자 아이디/비번을 알아야 관리자 권한을 얻을 수 있으므로
관리자 로그인이 안되지 않나요? 간단히 생각해도 무리일꺼 같다는 생각이 드는데요.
prosper 님 늦은 시간에 답글 달아주셔서 감사합니다.
본의 아니게 심기가 불편하게 해드린점에 대해 양해를 구합니다.
저역시 미천하며 현재도 진행중인 발전적인 기술에 대해 언급할 정도로 잘 알지 못합니다.
글제주가 짧아서 제생각을 제대로 잘 전달하지 못한점 이해부탁드립니다.
그리고 말씀하신 주제들에 대해서도 쪽지나 메일을 통해 들어오는 정보로서 제가 아는 한도내에서 토론해볼것이며
제가 아는 부분을 넘어선다면 받아들이는 자세로 임하겠습니다.
제글은 그누보드에 일관된 얘기가 아니라 공개웹프로그램 전반적인 얘기를 그누보드를 예로써
풀어나간것입니다.
제 글중 100%로나 확신한다등의 표현은 제경험상의 부분으로 정정합니다.
그리고 제가 님을 깍아내리려고 답글을 단것은 아닙니다.
저도 항상 배우고 있는 사람으로서 제가 모르는 부분은 배우고 넓혀나가고 싶습니다.
그러나 제목이나 내용에서도 나오듯이 제글 두개는 웹호스팅 환경과 공개된 웹프로그램(그누보드)의 전제 하에 쓰여진 것이며, 그 예를 그누보들 통해서 풀어나가자 한것이지
웹서비스를 하지 말라는 얘기는 아닙니다.
제목 그대로 웹호스팅환경에서의 그누보드의 보안 권고 사항입니다.
권고 사항이라는 의미는 제가 사전을 잘 보지 못해서 잘 못 썼는지는 모르지만 이러이러한 부분이 있으니 이렇게
하라고 권한다는 의미로 사용했습니다.
그리고 절대 이글은 이슈를 일으켜 볼려고 쓴글이 아닙니다.
제가 이글을 통해 이쪽 계통에 포커스를 받는 인물이 되고 싶어서 쓴글이 아님을 다시 한번 밝힙니다
본의 아니게 심기가 불편하게 해드린점에 대해 양해를 구합니다.
저역시 미천하며 현재도 진행중인 발전적인 기술에 대해 언급할 정도로 잘 알지 못합니다.
글제주가 짧아서 제생각을 제대로 잘 전달하지 못한점 이해부탁드립니다.
그리고 말씀하신 주제들에 대해서도 쪽지나 메일을 통해 들어오는 정보로서 제가 아는 한도내에서 토론해볼것이며
제가 아는 부분을 넘어선다면 받아들이는 자세로 임하겠습니다.
제글은 그누보드에 일관된 얘기가 아니라 공개웹프로그램 전반적인 얘기를 그누보드를 예로써
풀어나간것입니다.
제 글중 100%로나 확신한다등의 표현은 제경험상의 부분으로 정정합니다.
그리고 제가 님을 깍아내리려고 답글을 단것은 아닙니다.
저도 항상 배우고 있는 사람으로서 제가 모르는 부분은 배우고 넓혀나가고 싶습니다.
그러나 제목이나 내용에서도 나오듯이 제글 두개는 웹호스팅 환경과 공개된 웹프로그램(그누보드)의 전제 하에 쓰여진 것이며, 그 예를 그누보들 통해서 풀어나가자 한것이지
웹서비스를 하지 말라는 얘기는 아닙니다.
제목 그대로 웹호스팅환경에서의 그누보드의 보안 권고 사항입니다.
권고 사항이라는 의미는 제가 사전을 잘 보지 못해서 잘 못 썼는지는 모르지만 이러이러한 부분이 있으니 이렇게
하라고 권한다는 의미로 사용했습니다.
그리고 절대 이글은 이슈를 일으켜 볼려고 쓴글이 아닙니다.
제가 이글을 통해 이쪽 계통에 포커스를 받는 인물이 되고 싶어서 쓴글이 아님을 다시 한번 밝힙니다
보안. 신경안쓰면 그만이지만 신경쓰기 시작하면 끝이없죠.
유창화님 글의 논지가 무엇인지는 아주 잘 이해가 되네요..
그러나 공교롭게 그럴 가능성이 그리 높지많은 않다는게 다행스럽구요.
제가 볼때도 말씀하신 경우 해석기를 통한뒤의 정보 인클루드(소스긁기)일뿐일것 같습니다
물론 계정마다 틀리겠지만 상식의 선에서 권한을 설정해두고 보안을 한다면야 큰 무리는 없을것 같네요
유창화님 글의 논지가 무엇인지는 아주 잘 이해가 되네요..
그러나 공교롭게 그럴 가능성이 그리 높지많은 않다는게 다행스럽구요.
제가 볼때도 말씀하신 경우 해석기를 통한뒤의 정보 인클루드(소스긁기)일뿐일것 같습니다
물론 계정마다 틀리겠지만 상식의 선에서 권한을 설정해두고 보안을 한다면야 큰 무리는 없을것 같네요
고맙습니다.
읽어서 손해보지 않을 내용을 한방에 건져 올립니다.
강태공?! *^^*
강태공?! *^^*
고수들의 선문 선답이로다!
