사용자 삽입 이미지

Last Update : 2008.04.02.


웹 애플리케이션 진단을 하다 보면 백업 파일을 통해서 유용한 정보를 얻는 경우가 종종 있다.

이러한 백업 파일은 개발자나 관리자에게 위급한 상황에서 매우 유용하게 쓰이기도 하지만 보안 적인 측면에서 문제가 되기도 한다.

물론 백업 파일 생성 자체가 보안상 문제가 된다고 할 수는 없다. 백업은 보안상 꼭 필요한 수단이며 어떤 종류이건 장애 발생시에 가장 확실한 복구 수단 중의 하나이다.

문제는 백업 파일 저장 방식에서 발생한다. 웹 애플리케이션을 통해서 백업 파일 또는 데이터가 노출된 경우는 백업 데이터나 파일을 운영중인 서버 내에 보관해서 발생하며 그 중 웹 다큐먼트의 드렉토리 내에 저장해서 발생한다.



■ 웹 애플리케이션에서 발생하는 백업의 종류

웹 애플리케이션 서버에서 발생하는 백업의 형태는 크게 세가지 분류할 수 있다.


첫째는, 소스
전체 백업(Full Backup)

풀 백업은 보통 압축 파일을 이용하여 생성하며 웹 애플리케이션 루트와 또는 날짜로 구성된 드렉토리 내에 보관하는 경우가 많으며 유추에 성공하여 해당 백업 파일을 내려 받을 수 있을 경우 소스를 분석하여 공격에 활용 할 수 있다.

이러한 전체 백업 파일은 이름을 복잡하게 생성하여 노출되지 않는 경우도 많지만 Directory Listing, FTP 서비스 외부망에 Open, Web Server의 취약점 발생 등등의 취약점이 발생할 경우 이름의 복잡성과는 무관하게 모두 노출되게 된다.


둘째는, 파일 단위 백업 파일 생성

문서 편집기 또는 FTP 등등을 소프트웨어에서 파일에 수정을 가하였을 경우 백업파일이 생성되는 경우와 관리자 또는 유지보수시에 수작업으로 생성하는 백업 파일이 여기에 해당된다.

이미 개발이 완료된 웹 애플리케이션에서도 많은 유지보수가 발생하며 유지보수시에 사용한 툴로 인하여 자동으로 백업파일 생성되는 경우가 있으며 이러한 경우에는 주로 프로그램에서 자동으로 생성하므로 "파일명.확장자"에 .bak가 붙어 생성되는 경우가 대부분이다.

관리자 또는 유지보수시 수정 이전에 복구를 위해 임시적으로 생성하는 경우에는 사람이 생성하는 것으로 다양한 방식이 존재하나 대부분 백업 파일을 명시하기 위한 표기이므로 "파일명.확장자"를 "파일명.bak", "파일명.화장자_", "_파일명.확장자" 등등 다양하다. 만약 담당자가 "_파일명.확장자" 형태의 파일로 백업 파일을 생성할 경우 보안 상 문제가 되지는 않는다.


셋째는, 구 홈페이지를 디렉토리 변경을 이용한 백업

신규 홈페이지 또는 홈페이지 개편시에 구 홈페이지를 별도의 경로 또는 해당 웹 서버에 index에서 포워딩만 설정하고 그대로 두는 경우가 있다.

웹 애플리케이션 테스트를 하다 보면 종종 발견되며 old, backup, 해당 년도 등등의 드렉토리 이용 또는 신규 페이지를 new, newpage 등등의 드렉토리 생성하여 구 애플리케이션은 그대로 보관(방치)되어 있는 경우가 있다. 이것 또한 백업의 형태일 수도 있고 또는 아닐 수 도 있으나 본 주제와 연관성이 높으며 중요 보안 문제점 중의 하나이다.

예로 신규 홈페이지에서는 보안 모듈을 적용하여 문제가 없었으나 구 홈페이지가 발견되어 시스템이 장악되는 경우도 있다.


백업 파일로 자주 발생되는 취약점 예시이다.

사용자 삽입 이미지

< 그림1. DB 연결 정보가 노출 화면 >


웹 애플리케이션 서버에서 발생되는 백업 파일의 종류에 대해서 알아 보았다. 이러한 백업 파일은 대응 방안으로 기본적으로 삭제하거나 별도의 장소에 보관하는 것이 가장 확실하고 누구나 쉽게 할 수 있는 방법이다. 그럼에도 많이 발견되는걸 보면 관심 부족이나 관리상의 문제점이 더 크다고 할 수 있다.



■ 백업파일 대응방안

그럼 구체적으로 백업 파일에서 발생되는 보안 취약점을 제거하기 위한 대응 방안을 살펴보자.


첫번째, 모든 백업 파일을 웹 다큐먼트에서 삭제

풀 소스 백업이 아닌 경우는 대부분 수정 완료시에 더 이상 필요하지 않는 경우가 많다. 이러한 경우에는 해당 파일을 모두 찾아서 삭제를 하면 백업 파일로 인한 정보 노출을 차단할 수 있다.

꼭 필요한 경우에는 웹 서비스를 통해 접근이 불가한 별도의 위치에 저장을 하거나 꼭 해당 위치에 있어야 할 경우 확장자 대신 파일 이름을 변경하는 것이 좋다.


다음은 백업 파일 삭제 예시이다.

del /s *.bak

윈도우 시스템일 경우 웹 다큐먼트 루트에서 실행한다. 해당 /s 옵션은 현재 위치에서 하위의 모든 파일을 검사하여 확장자가 *.BAK인 파일을 삭제하라는 의미이다.


두번째, 백업 파일의 확장자를 파서에 등록

파일 단위 백업 파일을 파서에 등록하여 소스코드가 노출되지 않게 하는 방법도 매우 유용한 방법이다. 공격자가 .BAK나 .TMP 등등 백업 파일을 획득해도 HTML로 파싱된 정보만을 획득할 수 있으므로 관리자 또는 유지보수 측면에서 매우 유용하다.

하지만 이 방법은 파일 업로드 문제가 발생 할 수 있다. 파일 업로드 취약점을 제거하기 위해 블랙 리스트로 작성 하였을 경우 새로 등록한 백업 파일 확장자를 이용할 경우 정상 적으로 업로드와 실행이 가능하여 문제가 된다.

백업 파일 확장자를 파서에 등록할 경우 블랙 리스트 방식을 경우 필수적으로 파일 업로드 필터링 규칙을 수정하여 새로 등록된 확장자도 검증이 되도록 애플리케이션을 수정해야 한다.

세번째, 별도의 저장 매체를 이용하여 저장

외장형 하드 디스크나, CD-ROM 등등의 별도의 저장 매체에 저장을 하는 것이 좋다. 동일 서버에 저장하게 될 경우 물리적인 고장이나 데이터 손실이 발생하였을 경우 백업 파일 또한 손실되게 된다.

별도의 저장 매체 이용이 불가한 경우는 웹 다큐먼트의 경로를 제외한 별도의 위치에 저장하여 웹 애플리케이션을 통하여 노출되지 않도록 해야 한다.

웹 애플리케이션 서버에서 올바른 백업 파일 관리를 통해 보안성을 강화하기 바란다.

Posted by n3015m
:
BLOG main image
'네오이즘'의 보안LAB 블로그입니다........... n3oism@gmail.com by n3015m

카테고리

분류 전체보기 (228)
[ HappyDevTool ] (29)
[ HappyToolRelease ] (4)
[Book] (6)
[ Security Studies ] (0)
- CII (2)
- BigData (2)
- Web Hacking (10)
- SQL Injection (25)
- Mobile Security (9)
- Network (6)
- OperatingSystem (4)
- Malware & Reversing (4)
- Phishing (5)
- Compliance (0)
- Programming (13)
- Tools (13)
- IoT (6)
- etc (21)
[Pentration Testing] (3)
[OS X] (4)
[ Security Trends ] (16)
[ Fixing Guideline ] (7)
My Way, My Life (34)
About Me (2)

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

Total :
Today : Yesterday :