Sun 사 보안 취약점 버그 리포트에 알렸는데, 3주 내에 답변을 주겠다고 하고는 전혀 답변이 없네요. 보안 취약점에 대해 벤더랑 실갱이하기도 이제 지쳤고, impact 가 큰 취약점도 아니라서 '비공개' 상태로 적었던 글을 '공개'로 전환하고, 이글루스 등록시간도 변경하고자 합니다.
얼마전의 Sun telnet 취약점도 그렇고, 이 취약점도 그렇고 Sun 마이크로시스템이 최근 보안에 대한 관심이 약해진 듯...
이 취약점은 아직 Sun 에서 공식적으로 대응하지 않고 있는 Zero-day 취약점이므로 문서 하단에 나온 대응방안에 따라 적절히 조치하시는 것이 좋겠습니다. 주로 Java 개발자분들에게 해당하는 문제겠지만...
------------------------------------------------------------------------
[2007년 1월 22일 새벽 2시 30분 작성]
우연히 실수로 Sun Java Application Server 의 패스워드 암호화 취약점을 발견하게 되었습니다. 발견하게 된 복잡한 사정은 나중에 술사주시는 분들에게만 살짝 공개하도록 하고...
Java EE 5 Platform 설치 시 함께 설치되는 Sun Java Applcation Server 는 초기 설치 시 웹 관리자 암호를 묻습니다. 이 암호는 Administrator 권한으로 설치한 경우라면 놀랍게도 C:\Documents and Settings\Administrator\.asadminpass 이라는 파일에 저장됩니다. 이 파일을 열어보면 안에 Base64 인코딩 기법을 이용해 저장된 Application Server 관리자 패스워드가 나옵니다.
"아니, 사용자 자신이 자신의 암호가 적힌 파일을 열어보는 것이 무슨 취약점이냐?" 라고 물으신다면, 초점이 약간 어긋난 것입니다. "암호가 적힌 파일을 열어볼 수 있는 것"이 취약점이 아니라 "Base64 인코딩을 사용한 것"이 취약점입니다.
실환경을 가정하도록 해보죠. Application Server 의 관리자는 Sun Application Server 를 설치하면서 '귀찮거나, 기억하기 어렵다'는 이유로 Administrator 의 암호화 동일한 암호로 웹 관리자 암호를 설정해놓았을 확률이 높습니다. 그리고 J2EE 기반의 Applcation Server 는 대부분 Default 로 관리자 권한으로 설치, 운영됩니다. 이 Application Server 와 연동된 웹 애플리케이션에 Download 취약점(예: file_download.jsp?filename=../../../../../../etc/passwd 같은 경우)이 있다거나, Directory Indexing 취약점, Upload 취약점 등이 있다면 공격자는 손쉽게 해당 파일의 내용을 열람할 수 있게 되는데, 내용이 base64 encoding 으로 보호되어 있기 때문에 base64 decode 함수를 이용해 1초도 안되어 본래의 패스워드를 파악할 수 있습니다. 그리고 이 패스워드는 시스템의 Administrator 패스워드와 동일하기 때문에 터미널 서비스나 VNC 등의 원격 관리 기능을 이용해 서버를 점령할 수 있습니다.
매우 단순해서 무시해도 좋을만큼 가벼운 취약점 같지만 다른 취약점과 결합하자마자 무시무시한 상황이 되어버렸죠? 당분간은 Sun Java System Application Server Platform Edition 9.0 Update 1 Patch 1 을 설치하지 않는 것이 좋겠습니다. Sun 홈페이지에서 대대적으로 광고하고 있는 "Java EE 5 SDK Update 2"는 "J2EE 5 SDK"와는 약간 다른 제품이니 설치하지 않도록 주의하시는 것도 잊지 마시구요. 굳이 해당 제품들을 설치하신다면 시스템 관리자 계정의 패스워드와 다른 패스워드로 설정하시도록 하구요. 그리고 이 서버는 웹 애플리케이션의 취약점으로 인해 공격당하지 않도록 보호 레벨을 높이는 것이 좋겠습니다.
------------------------------------------------------------------------
흠... 새벽에 발견하고 졸면서 버그 리포트를 제출해서, 영어가 이상해 안받아주는 건지 뭔지...
얼마전의 Sun telnet 취약점도 그렇고, 이 취약점도 그렇고 Sun 마이크로시스템이 최근 보안에 대한 관심이 약해진 듯...
이 취약점은 아직 Sun 에서 공식적으로 대응하지 않고 있는 Zero-day 취약점이므로 문서 하단에 나온 대응방안에 따라 적절히 조치하시는 것이 좋겠습니다. 주로 Java 개발자분들에게 해당하는 문제겠지만...
------------------------------------------------------------------------
[2007년 1월 22일 새벽 2시 30분 작성]
우연히 실수로 Sun Java Application Server 의 패스워드 암호화 취약점을 발견하게 되었습니다. 발견하게 된 복잡한 사정은 나중에 술사주시는 분들에게만 살짝 공개하도록 하고...
Java EE 5 Platform 설치 시 함께 설치되는 Sun Java Applcation Server 는 초기 설치 시 웹 관리자 암호를 묻습니다. 이 암호는 Administrator 권한으로 설치한 경우라면 놀랍게도 C:\Documents and Settings\Administrator\.asadminpass 이라는 파일에 저장됩니다. 이 파일을 열어보면 안에 Base64 인코딩 기법을 이용해 저장된 Application Server 관리자 패스워드가 나옵니다.
"아니, 사용자 자신이 자신의 암호가 적힌 파일을 열어보는 것이 무슨 취약점이냐?" 라고 물으신다면, 초점이 약간 어긋난 것입니다. "암호가 적힌 파일을 열어볼 수 있는 것"이 취약점이 아니라 "Base64 인코딩을 사용한 것"이 취약점입니다.
실환경을 가정하도록 해보죠. Application Server 의 관리자는 Sun Application Server 를 설치하면서 '귀찮거나, 기억하기 어렵다'는 이유로 Administrator 의 암호화 동일한 암호로 웹 관리자 암호를 설정해놓았을 확률이 높습니다. 그리고 J2EE 기반의 Applcation Server 는 대부분 Default 로 관리자 권한으로 설치, 운영됩니다. 이 Application Server 와 연동된 웹 애플리케이션에 Download 취약점(예: file_download.jsp?filename=../../../../../../etc/passwd 같은 경우)이 있다거나, Directory Indexing 취약점, Upload 취약점 등이 있다면 공격자는 손쉽게 해당 파일의 내용을 열람할 수 있게 되는데, 내용이 base64 encoding 으로 보호되어 있기 때문에 base64 decode 함수를 이용해 1초도 안되어 본래의 패스워드를 파악할 수 있습니다. 그리고 이 패스워드는 시스템의 Administrator 패스워드와 동일하기 때문에 터미널 서비스나 VNC 등의 원격 관리 기능을 이용해 서버를 점령할 수 있습니다.
매우 단순해서 무시해도 좋을만큼 가벼운 취약점 같지만 다른 취약점과 결합하자마자 무시무시한 상황이 되어버렸죠? 당분간은 Sun Java System Application Server Platform Edition 9.0 Update 1 Patch 1 을 설치하지 않는 것이 좋겠습니다. Sun 홈페이지에서 대대적으로 광고하고 있는 "Java EE 5 SDK Update 2"는 "J2EE 5 SDK"와는 약간 다른 제품이니 설치하지 않도록 주의하시는 것도 잊지 마시구요. 굳이 해당 제품들을 설치하신다면 시스템 관리자 계정의 패스워드와 다른 패스워드로 설정하시도록 하구요. 그리고 이 서버는 웹 애플리케이션의 취약점으로 인해 공격당하지 않도록 보호 레벨을 높이는 것이 좋겠습니다.
------------------------------------------------------------------------
흠... 새벽에 발견하고 졸면서 버그 리포트를 제출해서, 영어가 이상해 안받아주는 건지 뭔지...
덧글
니키 2007/03/04 23:13 # 삭제 답글
잘 보고 있습니다(-_-..정말로 이런 문제까지 볼 수 있는 관찰력에 존경입니다.
헐랭이 2007/03/05 11:11 # 답글
관찰력은 별 관계가 없구요... 보통 해킹을 할 때 이렇게들 하더라구요.초보시절 : 이 매커니즘이 어떻게 될까? 얘는 어떻게 구현한걸까?
탐험의 시기, 호기심의 시기죠.
숙련자 : 이 플랫폼에서 이거 구현할 때 이러 이러한 방법이 있는데, 이 회사 프로그래머는 어느 방법을 선택했을까?
이렇게 되면 가설->검증 형태로 가게 됩니다. 초보 때에 비해 시간 단축도 많이 되죠.
이번 취약점은 Install 과정 보면서 머리에 떠오른 가설을 검증하는 과정에서 다른 건 시도해보지도 않고 첫번째에 걸렸습니다. 제일 취약한 구현법이었던 거죠.
니키 2007/03/05 16:55 # 삭제 답글
그렇군요(_ _) 쌓인 경험과 연구는 앞선 도리가 없습니다.로직과 프로그래머의 논리적인 생각 등을 하면서 취약점 분석을 수행해야 하는데...아직은 내공이 없네요^_^;
선배님의 말씀 감사합니다.