Information disclosure vulnerability
개념
정기적으로 발생할 가능성이 높으며, 효과적으로 악용하는 방법을 알게 되면 테스트 효율성을 높이고 추가로 심각도가 높은 버그를 찾는 데 도움이 될 수 있다.
Information Disclosure, 또는 Information Leakage는 의도하지 않게 사용자에게 민감한 정보를 공개하는 취약점이다. 누출될만한 정보로는 사용자 이름, 금융 정보와 같은 다른 사용자에 대한 데이터, 민감한 상업/비즈니스 데이터, 웹사이트 및 인프라에 대한 기술적 세부사항 등 온갖 종류의 정보가 있다.
일부 정보는 잠재적으로 다른 취약점의 attack surface를 노출할 수 있다. 복잡하고 심각도가 높은 공격을 구성하려고 할 때 정보를 제공할 수 있다.
예시
정보 공개의 기본적인 예는 다음과 같다.
- robots.txt 파일 또는 디렉토리 리스팅을 통해 숨겨진 디렉토리의 이름, 구조 및 내용 공개
- 오류 메시지에서 DB 테이블 또는 열 이름을 명시적으로 언급
- 신용 카드 정보와 같이 매우 민감한 정보를 불필요하게 노출
- 소스코드에서 API 키, IP 주소, DB 자격 증명 등을 하드코딩
- 응용 프로그램 동작의 미묘한 차이를 통해 리소스, 사용자 이름 등의 존재 또는 부재에 대한 힌트를 얻음
취약점이 발생하는 이유
무수히 많은 원인이 있지만 크게 다음과 같이 분류할 수 있다.
- 공개 콘텐츠에서 내부 콘텐츠를 제거하지 못했다.
- 예를 들어 개발자 주석 등이 프로덕션 환경의 사용자에게 표시되는 등
- 웹사이트 및 관련 기술의 안전하지 않은 설정때문
- 프로덕션 서버에서 디버깅이나 진단 기능을 비활성화 하지 않는 등
- 응용 프로그램 설계 및 동작에 결함이 있음
- 웹사이트가 특정 오류가 발생했을 때 고유한 응답을 반환하는 경우, 공격자가 유효한 사용자 자격 증명과 같은 중요한 데이터를 열거할 수도 있다.
취약점을 찾는 방법에 대한 예
다른 취약점을 이것저것 테스트하다보면 종종 민감한 데이터를 찾을 수 있다. 핵심은 이러한 데이터를 봤을 때 흥미로운 데이터라는 것을 인식하는 것이다.
퍼징
흥미로운 매개 변수를 식별하면 여기에 예상치 못한 데이터 타입이나 퍼징 페이로드 등을 넣어본다. 응답은 때때로 명시적으로 정보를 유출하지만, 좀더 미묘하게 암시할 수도 있다. 예를 들어 요청을 처리하는 데 걸리는 시간이 약간 다를 수 있다. 오류 메시지 내용이 없더라도 때로는 새로운 오류 사례를 발견했다는 사실 자체가 유용한 정보일 수 있다.
Burp Intruder와 같은 도구를 사용하여 이 프로세스의 대부분을 자동화할 수 있다. Burp Intruder를 사용하는 이점은 다음과 같다.
- 매개변수에 페이로드의 위치를 추가하고, 사전에 만든 워드리스트를 사용해 대량의 다양한 입력을 빠르게 테스트할 수 있다.
- HTTP 상태 코드, 응답 시간, 길이 등을 비교하여 응답의 차이점을 쉽게 식별할 수 있다.
- grep 일치 규칙을 사용하여 오류, 유효하지 않음, SELECT, SQL 등과 같은 키워드를 잡아낼 수 있다.
- grep 추출 규칙을 사용하여 응답 내에서 관심있는 항목의 내용을 추출하고 비교한다.
Burp Scanner 사용
감사하는 동안 실시간으로 검색을 할 수 있다. 자동 검색을 예약하여 공격자를 대신하여 대상 사이트를 크롤링하고 감사할 수 있다. 응답에서 개인 키, 이메일 주소, 신용 카드 번호와 같은 민감한 정보를 발견하면 경고를 띄운다. 또한 모든 백업 파일, 디렉토리 목록 등을 식별한다.
Burp Engagement tool 사용
- Search
- 이 도구를 사용하면 정규식 등으로 다양한 고급 검색을 할 수 있다. 관심있는 특정 키워드의 발생 또는 부재를 빠르게 찾는 데 유용하다.
- Find comments
- 개발자 주석을 빠르게 추출할 수 있다. 또한 각 주석이 발견된 HTTP 요청/응답에 즉시 액세스할 수 있다.
- Discover content
- 웹 사이트의 가시적 콘텐츠와 링크되지 않은 추가 콘텐츠 및 기능을 식별할 수 있다. 사이트맵에 자동으로 추가되지 않을 추가 디렉토리 및 파일을 찾는 데 유용하다.
정보를 주는 Response를 조사
일반적인 테스트를 진행하는 동안 Verbose 에러 메시지에서 흥미로운 정보를 볼 수 있다. 입력에 따라 오류 메시지가 변경되는 방식을 연구하면 한 단계 더 나아갈 수 있다. 한 가지 일반적인 예는 잘못된 작업을 시도하도록 하는 것이다. 잘못된 매개 변수 값을 제출하면 흥미로운 세부 정보가 포함 된 stack trace 또는 디버그 응답이 발생할 수 있다.
일반적인 Information Disclosure 출처
웹 크롤러를 위한 메타 파일
robots.txt나 sitemap.xml 파일에서 크롤러가 건너 뛰어야하는 특정 디렉토리를 나열하는 경우가 많다. 이러한 파일은 일반적으로 웹사이트 내에서 링크되지 않기 때문에 Burp의 사이트맵에 즉시 나타나지 않을 수 있다.
디렉토리 리스팅
디렉토리 리스팅 자체가 반드시 보안 취약점은 아니다. 하지만 웹 사이트가 적절한 접근 제어를 구현하지 못할 경우 이러한 방식으로 민감한 리소스의 존재와 위치를 유출하는 것은 분명한 문제이다.
개발자의 주석
때때로 주석에는 공격자에게 유용한 정보가 포함된다. 예를 들어 숨겨진 디렉토리의 존재를 암시하거나 응용 프로그램 로직에 대한 단서를 제공할 수 있다.
참고 문제: Portswigger-Unprotected admin functionality with unpredictable URL
에러 메시지
정보 공개의 가장 일반적인 원인 중 하나는 verbose 오류 메시지이다. 일반적으로, 감사 중 발생하는 모든 오류 메시지에 세심한 주의를 기울여야 한다.
오류 메시지의 내용으로는, 주어진 매개 변수를 이용할 때 함께 입력하기를 기대하는 입력 또는 데이터 타입에 대한 정보 등이 있다. 이를 통해 악용 가능한 매개 변수를 식별하여 공격 범위를 좁힐 수 있다. 동작하지 않는 페이로드를 주입하는 데 시간을 낭비하는 것을 막을 수 있다.
또한 오류 메시지는 웹 사이트에서 사용 중인 다양한 기술에 대한 정보를 제공할 수도 있다. 예를 들어 웹 사이트에서 사용 중인 템플릿 엔진, DB 유형 또는 서버의 이름, 버전 번호 등을 명시적으로 표시할 수도 있다. 이 정보를 이용하면 이미 밝혀진 취약점과 익스플로잇을 쉽게 검색할 수 있기 때문에 유용하다. 마찬가지로 악용할 수 있는 일반적인 설정 오류 또는 위험한 디폴트 설정이 있는지 확인할 수 있다. 이들 중 일부는 공식 문서에서 주의 사항으로 강조하는 사항일 수도 있다.
웹사이트가 어떠한 오픈 소스 프레임워크를 사용하는지를 알 수도 있다. 이 경우 공개된 소스 코드를 연구하고 익스플로잇을 짤 수 있다.
오류 메시지 간의 차이는 백그라운드에서 발생하는 다양한 애플리케이션 동작을 나타낼 수도 있다. 오류 메시지의 차이를 관찰하는 것은 SQLi, 사용자 이름 열거 등과 같은 공격을 할 때 중요하다.
참고 문제: Portswigger-Information disclosure in error messages
디버깅 데이터
때때로 웹사이트는 디버깅을 목적으로 애플리케이션 동작에 대한 정보가 포함된 커스텀 에러메시지와 로그를 생성한다. 이것이 프로덕션 환경에 유출된다면 공격자에게 매우 유용하다.
디버그 메시지에는 때때로 다음과 같은 중요 정보가 포함된다.
- 사용자 입력을 통해 조작할 수 있는 주요 키 세션 변수 값
- 백엔드 구성 요소의 호스트네임과 크레덴셜
- 서버의 파일, 디렉토리 이름
- 클라이언트를 통해 전송되는 데이터를 암호화하는 데 사용되는 키
디버깅 정보는 때때로 별도의 파일에 기록될 수 있다. 공격자가 이 파일메 액세스할 수 있는 경우 어플리케이션의 runtime state를 이해하는 데 유용하다. 또한 응용 프로그램에 페이로드를 어떻게 입력할 수 있을지에 대한 몇 가지 단서를 제공한다.
참고 문제: Portswigger-Information disclosure on debug page
유저 계정 페이지
본질적으로 사용자 프로필 또는 “내 계정” 페이지에는 민감한 정보가 포함된다. 사용자는 일반적으로 자신의 계정 페이지에만 액세스할 수 있으므로, 그 자체로 취약점은 아니다. 그러나 일부 웹 사이트는 로직 결함으로 인해 다른 유저의 페이지에 접근에 활용할 수 있다.
예를 들어 사용자가 입력한 파라미터에 따라 사용자의 계정 페이지에 접근하는 웹사이트가 있다. GET /user/personal-info?user=carlos 와 같이 접근할 때, 데이터 각각을 로드하는 논리가 강력하지 않을 수 있다. 예를 들어 공격자가 파라미터를 변경하여 다른 사용자의 계정 페이지를 완전히 로드할 수는 없지만, 사용자의 정보를 가져오고 렌더링하는 로직은 실제 로그인한 사용자와 파라미터에 적힌 사용자가 동일한지 확인하지 않을 수 있다. 이 경우, 단순히 파라미터를 변경하면 다른 유저의 정보를 얻을 수 있다.
참고 문제: Portswigger-User ID controlled by request parameter with data leakage in redirect
백업 파일에서 소스코드 공개
소스 코드 액세스 권한을 얻으면 공격자가 애플리케이션의 동작을 훨씬 쉽게 이해하고 심각도 높은 공격을 만들 수 있다. 민감한 데이터는 때때로 소스 코드 내에 하드코딩 된다. 일반적인 예로 백엔드 구송 요소에 액세스하기 위한 API 키와 크레덴셜 등이 있다.
때때로, 웹사이트가 자신의 소스코드를 노출하도록 할 수도 있다. 웹 사이트를 매핑할 떄, 일부 소스 코드 파일이 명시적으로 참조되는 것을 볼 수 있다. 이것을 요청하는 것이 보통 코드 자체를 드러내지는 않는다. 예를 들어 서버가 .php 파일과 같은 특정 확장자를 가진 파일을 처리할 때, 일반적으로 단순히 이 텍스트파일을 클라이언트에게 보내는 게 아니라 코드를 실행한다. 하지만 일부 상황에서는 웹 사이트가 코드를 실행하는 대신 파일의 내용을 보내도록 할 수 있다.
예를 들어 텍스트 편집기는 원본 파일을 편집하는 동안 임시 백업 파일을 생성하는 경우가 많다. 이러한 임시 파일은 일반적으로 파일 이름에 물결표(~)를 추가하거나 다른 파일 확장자를 추가한다. 백업 파일 확장자를 사용하여 코드 파일을 요청하면 응답에서 파일 내용을 읽을 수 있는 경우가 있다.
참고 문제: Portswigger-Source code disclosure via backup files
공격자가 소스 코드에 액세스할 수 있으면, 소스코드를 보지 못했다면 알기 어려운 취약점을 찾아낼 수 있다.
참고 문제: Portswigger-Arbitrary object injection in PHP
안전하지 않은 설정으로 인한 정보 공개
웹사이트는 때때로 부적절한 설정으로 인해 취약해진다. 일반적으로 서드파티 기술을 잘 이해하지 못 하고 사용하여 발생한다. 또는 개발자가 프로덕션 환경에서 디버깅 옵션을 비활성화하는 것을 잊어서 그럴 수도 있다.
예를 들어 HTTP TRACE 메소드는 진단 목적으로 설계되었다. 활성화된 경우 웹 서버는 수신한 Request를 그대로 돌려준다. 이 동작은 보통 무해하지만, 리버스 프록시를 사용할 때는 정보를 유출할 수도 있다. 리버스 프록시가 내부 인증 헤더를 붙이는 경우 이를 유출할 수 있다.
참고 문제: Portswigger-Authentication bypass via information disclosure
버전 컨트롤 히스토리
거의 모든 웹 사이트는 Git과 같은 버전 제어 시스템을 이용한다. 기본적으로 Git 프로젝트는 모든 버전 제어 데이터를 .git 폴더에 저장한다. 때때로 프로덕션 환경에서 이 디렉토리를 노출한다.
.git 디렉토리를 다운로드하고 Git를 설치하여 웹사이트의 버전 제어 기록에 액세스할 수 있다. 여기에는 커밋 된 변경 사항 및 기타 흥미로운 정보가 포함된 로그가 포함될 수 있다. 전체 소스 코드에 액세스할 수 없을 수도 있지만, diff를 비교하면 작은 소스코드 스니펫을 읽을 수 있다. 일부 변경된 줄에서는 하드코딩된 민감한 데이터를 찾을 수 있기도 하다.
참고 문제: Portswigger-Information disclosure in version control history
Impact
웹사이트의 목적과 공격자가 얻을 수 있는 정보에 따라 다르다. 경우에 따라 민감한 정보를 공개하는 행위만으로 임팩트가 있을 수 있다. 예를 들어 신용 카드 정보 등. 반면에 디렉토리 구조 또는 사용중인 타사 프레임 워크와 같은 기술 정보 유출은 임팩트가 거의 또는 전혀 없을 수 있다. 그러나 여러 다른 공격을 구성하는 데 필요한 핵심 정보가 될 수 있다.
예방법
- QA 또는 빌드 프로세스의 일부로 잠재적 정보 공개에 대한 코드를 감사한다. 개발자 주석 등을 제거하는 등.
- 가능한 한 일반적인 오류 메시지를 사용한다. 불필요하게 애플리케이션 동작에 대한 단서를 제공하지 않는다.
- 프로덕션 환경에서 디버깅 또는 진단 기능이 비활성화되어 있는지 확인한다.
- 사용하고 있는 타사 기술 설정 및 보안 영향을 완전이 이해하고 사용한다. 필요하지 않은 기능은 비활성화한다.