28. 침해대응&CERT (6) : 웹 취약점 실습_1

앞으로 구글링을 통한 웹 취약점에 대해 다루어볼 예정이다.

 

구글링을 통해서 얻을 수 있는 취약점은 다양하게 존재하는데,

실제 실무에서 중요하게 다루는 취약점들에 대해 알아볼 예정이다.

 

 

---

 

 

관리자 페이지 노출 취약점

 

 

정의
웹 애플리케이션, 사이트의 관리자 페이지가 접근이 차단되는 형식이 아닌

인터넷을 통해 일반 사용자에게 접근 가능하게 노출된 경우를 의미한다. 

이러한 관리자 페이지가 노출된 것만으로도, Brute Force(무차별 대입 공격), 

SQL Injection 공격 등 다양한 형태의 공격의 빌미를 제공하게 되는 취약점이다.

 

점검방안

1. /admin, /manager, /master, /system, /adm 등의 일반적으로 많이 사용하는 
   관리자 페이지 명을 입력하여 관리자 페이지가 존재하는지 점검한다.
2. /admin/board_list.jsp 등의 관리자 페이지 하위 페이지(웹서버 내부 파일명)를 알고 있을 경우,
   웹 브라우저를 통해 직접 접속을 시도한다.
3. 구글링을 통해 관리자 페이지를 직접 검색해 본다

 

대응방안

1. 관리자 페이지에 접근할 수 있는 IP 주소를 특정 네트워크 대역으로 제한한다.
   임의의 사용자가 접근할 수 없도록 접근권한을 가진 단말기만 접근 가능하도록 설정한다.
2. URL을 유추하기 어려운 복잡한 이름으로 만든다. 
3. 인증과정 없이 접속하지 못하도록, 관리자 페이지 각각에 대하여 관리자 인증을 위한 세션 검증을 필요하게 한다.
4. 관리자 페이지는 관리용으로 지정된 디렉터리에만 보관하여 운영한다.
5. 구글링에 노출된 경우에는 ‘robots.txt’ 파일을 사용하여, 관리자 페이지를 인덱싱 하지 않도록 한다.

 

 

관리자 페이지 노출 취약점 - 실습

 

 

inurl:admin intitle:login

inurl:admin intitle:로그인

1

 

 

inurl:master intitle:관리자

 

 

---

 

 

디렉터리 나열 취약점

 

 

정의
취약한 웹 서버 설정으로 인해 디렉터리 인덱싱이 활성화되어, 

아래와 같이 서버 내의 파일 목록이 노출되는 경우를 의미한다. 

이러한 서버 내의 파일 목록이 노출되는 경우, 웹 서버 구조, 백업 파일, 소스코드 등 민감한 정보가 노출될 수 있다.

점검방안

1. 점검 대상 웹 사이트의 하위 디렉터리 정보를 사전에 확인하고, 
2. 웹 브라우저에 모든 하위 디렉터리에 대해서 해당 주소를 입력하여 취약점 존재 여부를 점검한다.
3. 구글링을 통해서 디렉터리 목록이 저장된 페이지를 검색한다.

 

대응방안

1. 웹 서버 내에서 디렉터리 인덱싱을 비활성화한다.
   Apache : httpd.conf 설정 파일을 열어 Options의 indexes 설정을 제거하거나, -indexes로 변경한다.
   Windows IIS : 설정 > 제어판 > 관리도구 > 인터넷 서비스 관리자(웹 사이트 우클릭 후 등록 정보 선택) 
   > 홈 디렉터리 > 디렉터리 검색 체크박스 해제 or IIS 관리자 > 해당 웹 사이트 > IIS > 디렉터리 검색 사용 안 함 선택
   Nginx : ‘nginx.conf’ 파일에서 ‘autoindex off;’ 설정
   
   위와 같이 웹 서버에 따라 알맞은 디렉터리 인덱싱 비활성화 과정을 거칠 수 있다.
   
   
2. 각 디렉터리에 ‘index.html’ 또는 ‘index.php’와 같은 인덱스 파일을 추가하여,
   지정된 인덱스 파일의 내용만 보여주고, 전체 디렉터리 목록이 노출되지 않도록 한다.

디렉터리 나열 취약점 - 실습

 

intitle:Index of “/venv”
“venv”는 Python의 가상 환경을 의미하는 디렉터리 이름으로,

 

이러한 페이지는 가상 환경 디렉터리 내의 파일 목록이 노출되어,

설정 파일, 설치된 패키지 등 민감한 정보가 포함될 수 있다.

 

 

intitle:"index of" "/.vscode" 
이러한 페이지는 Visual Studio Code의 설정 파일 및 프로젝트 구성 파일을 포함할 수 있다.

위와 같이 원격 서버 호스트 주소, 포트 번호, 비밀번호, 사용자 이름, 경로 정보 등

매우 민감한 정보를 포함하고 있는 것을 볼 수 있다.

 

 

---

 

 

시스템 관리 취약점

 

 

정의
응용 프로그램(Apache 등) 설치 중에 생성되는 설치 파일, 임시 파일, 압축 파일이 웹 서버에 그대로 존재하거나, 

웹 상에서 윈도우 로그인 창이 노출되는 등 시스템 관리 미비로 인해 발생하는 취약점을 의미한다.

해당 취약점은 시스템 설정에 관련된 취약점이므로 범위가 방대하고, 

응용 프로그램 별로 기본 설치 경로가 상이하므로 각 환경에 맞는 취약점 진단이 필요하다.

점검방안

1. 응용 프로그램 설치 시 생성되는 기본 경로(fckeditor, Apache, phpMyAdmin 등)를 검색하여,
   불필요한 설치 파일이 존재하는지 확인한다.
2. 디렉터리 요청 시 윈도우 원격 로그인 페이지 등이 노출되는지 확인한다.
3. SQL 로그 파일(sqlnet.log)이 웹 서버에 존재하는지 검색한다.

 

대응방안

1. 웹 서버에 응용프로그램 설치 시 임시 생성되는 파일은 설치가 완료되면 즉시 삭제한다.
2. 웹 서버 소스상에 설정이 잘못된 것은 없는지, 시스템 보안 설정이
   미비한 지 점검하여 해당 시스템에 가장 알맞게 설정한다.
3. 정기적으로 웹서버의 불필요 파일을 검색하여 제거한다.

해당 취약점 같은 경우는 말 그대로 관리를 잘해야지만 발생되지 않는 취약점이다 보니,
명확한 기술적 조치 방안은 사실상은 없다고 볼 수 있다.

즉, 점검 관련 관리 프로세스를 마련하여 관리를 강화하는 식으로 조치할 수 있다. 

 

그래서 불필요한 파일에 대한 범위는 나름대로 검토를 하여,

어느 범위까지 불필요한 파일로 볼 건지에 대한 정립이 필요한 것이다.

 

보통 웹 서버에 불필요한 파일은 설치 파일, 임시로 생성된 임시 파일, 로그 파일,

압축파일, 문서파일 등을 불필요한 파일로 볼 수 있다.

 

 

시스템 관리 취약점 - 실습

 

 

intitle:"Index of" phpinfo.php
phpinfo.php 파일은 php 환경 설정과 관련된 매우 상세한 정보를 제공하기 때문에, 

공격자가 이 정보를 활용하여 시스템의 취약점을 찾거나 공격을 시도할 수 있다.

 

 

intitle:"index of" " *admin-login.php ”
웹 서버의 디렉터리 목록 중에서 로그인 페이지를 포함하는 디렉터리나 관리자 전용 영역을 찾는다.

위의 php 확장자 디렉터리가 모두 아래와 같은 로그인 페이지로 연결되는 것을 확인할 수 있다.

 

 

intitle:index of "sqlnet.log”
웹 서버의 디렉터리 목록 중에서 SQL 로그 파일을 찾는다.

 

 

---

 

 

불필요한 Method 허용 취약점

 

 

정의
HTTP의 경우 클라이언트가 서버에게 요청의 목적을 알리기 위해 목적에 따라

Method(GET, POST, PUT, DELETE, TRACE, OPTIONS 등)라는 수단을 알맞게 사용한다. 

 

- GET : 서버에서 데이터를 가져오기 위한 메소드로, 보통 웹 페이지를 가져오는 데 사용된다.
- POST : 서버에 데이터를 제출하기 위한 메소드로, 폼 제출 등에 사용된다.
- PUT : 서버에 데이터를 업로드하거나 기존 데이터를 수정하는 데 사용된다.
- DELETE : 서버에서 데이터를 삭제하는 데 사용된다.
- TRACE : 서버가 클라이언트 요청을 어떻게 처리하는지 추적하기 위해 사용됩니다.

- OPTIONS : 서버가 지원하는 메소드를 조회하기 위해 사용된다.

 

이 중 PUT, DELETE Method의 경우 임의로 서버 내 파일의 생성 및 삭제가 가능하기 때문에, 

공격자에 의해 악성파일을 업로드하거나 삭제가 가능해질 수 있다.

즉, 사용자에게 필요하지 않은 Method까지 모두 허용해 놓아 발생하는 취약점을 의미한다.

이외에 TRACE Method의 경우 요청과 응답을 그대로 반환하여, 

크로스 사이트 트레이싱(Cross-Site Tracing, XST) 공격에 악용될 수 있다.

점검방안

1. OPTIONS Method를 사용하여 홈페이지 운영에 불필요한
   Method(PUT, DELETE, OPTIONS 등)가 활성화되어 있는지 확인한다.

대응방안

1. 웹 서비스 제공 시 필요한 GET, POST Method를 제외한 모든 Method에 대한 접근을 거부하거나, 
   필요한 경우 접근을 허용하는 등 리소스 별 Method를 제한하여 관리한다.
   
   GET, POST Method의 경우 상태값을 변경하거나 삭제하는 등의 기능은 수행하지 않는다.
   
   
2. PUT, DELETE Method 차단이 불가능한 경우에는 사용자 별로 권한을 부여하여 사용자 권한 검증을 통해 관리한다.

 

 

불필요한 Method 허용 취약점 - 실습

 

 

intitle:"index of" intext:"web.config.txt” (IIS 사용의 경우)

IIS의 경우 불필요한 Method를 비활성화하기 위해서 ‘requestFiltering’ 설정을 추가해야 한다.
하지만 해당 웹 서버 설정의 경우 Method 제한이 이루어지지 않았으므로, 취약한 경우에 해당된다.

 

 

intitle:"index of" "ngnix.conf.txt" (ngnix 사용의 경우)

ngnix의 경우 불필요한 Method를 비활성화하기 위해서 ‘limit_except’ 설정을 추가해야 한다.
하지만 해당 웹 서버 설정의 경우 Method 제한이 이루어지지 않았으므로, 취약한 경우에 해당된다.

 

 

intitle:"index of" intext:"web.xml” (Apache Tomcat 사용의 경우)

해당 웹 서버는 ‘security-constraint’ 항목을 추가하여, part1에서는 특정 사용자에게만 권한을 부여하고,

DELETE, GET, POST, PUT Method 접근을 허용하여 조치하였고,

 

part2에서는 DELETE, GET, POST, PUT Method 접근을 완전히 차단해 놓은 것을 볼 수 있다.

 

 

---

 

 

인용 : 한국교육학술정보원 KERIS 『웹 서버 및 홈페이지 취약점 점검 가이드』