2017 OWASP A6 : 잘못된 보안 구성

안녕하세요.

오늘은 OWASP의 6번으로 선정되어진 잘못된 보안 구성에 대해서 포스팅 하겠습니다.

 

잘못된 보안 구성

 

위이이잉~🌼🐝

잘못된 보안 구성, 굉장히 두루뭉실하며 네이밍하기에는 너무 추상적인 단어 조합이다.

그렇기에 예를 들어서 구체적인 상황들로써 좀더 명확한 개념을 알아보도록 하자.

잘못된 보안 구성이란 뭘까, 한마디로 인간적인 실수를 예로 들을 수가 있다.

취약한 버전으로 알려진 버전의 어플리케이션을 사용한다던가 무심코 열어둔 텔넷, 접근 거부 설정을 하지 않아서 나타나는 디렉토리 인덱싱, 우리한테 친절하게 어디가 틀려줬는지 알려주려고 만들어논 에러구문을 역이용한 정보수집등 우리가 초기에 설정할 때 보안상 설정해주어야 하지만 하지 않은 것들을 바로 잘못된 보안 구성이라고 말한다.

 

 

그럼 대충 감이 오기 시작하니 OWASP 문서 번역본을 보며 어떻게 정의하고 기준을 내렸는지 살펴보도록 하자.

 

 

공격 가능성 : 3

확산 정도 : 3

탐지 가능성 : 3

기술 : 2

 

한마디로 큰 기술 없이 공격 가능성이 위험하고 확산되고 취약점 탐지 가능성이 매우 높게 평가되어 있다.

처음 구성할 때 까다롭게 봐야하지만 공격자 입장에서는 찾게되면 쉽게 접근할 수 있는 부분이라는 뜻이다.

 

공격 가능성

공격자는 허가되지 않은 영역으로 접근할 수 있는 권한이나 시스템의 정보를 얻기 위해서 패치가 이루어지지 않은 취약점을 공격하거나 기본 계정, 미사용 페이지, 보호받지 못하는 파일이나 디렉토리에 접근을 시도할 수 있습니다.

 

확산 정도 & 탐지 가능성

잘못된 보안 구성은 제공되어지고 있는 서버, 프로그램, 다양한 서비스들.. 굉장히 많은 범위에서 일어날 수 있으며 탐지가능성이 3인 이유는 다양한 자동화 툴들이 알아서 취약한 부분을 찾아주기 때문입니다.

이 잘못된 보안 구성은 대게 다른 공격으로 넘어가기 위해서 수집되는 정보와도 같은데 대부분 오류메세지(스트링), 버전정보 등이 노출됨에 있어서 시작하는데 아무래도 텍스트출력이기 때문에 툴을 이용하여 발견하고 찾기가 수월한 것같습니다.

기본으로 주어지는 계정이 남아있는지, 불필요하게 실행되고 있는 서비스나 열려있는 포트번호는 없는지, 변경이 필요하지만 이루어지지 않은 예전 옵션들 등을 찾아 낼 수가 있습니다.

 

기술

보안 설정이 이대로 미흡하게 유지될 경우에는 공격자가 일부 인가되지 않은 시스템이나 기능에 접근할 수 있는 빌미를 주게 되며 이 빌미를 통해서 시스템 권한을 얻게되는 경우도 발생할 수 있습니다.

 

 

취약점 확인 방법

- 권한 설정이 정상적인지 확인

- 불필요한 기능(사용중이 아닌 열려있는 포트, 서비스, 페이지, 계정, 특수권한 등)이 활성화 되어 있는지 확인

- default 계정이 사용되어지고 있는지 확인

- 에러처리상황에 스택추적정보 노출이나 다른 정보들이 노출되는지 확인

- 업그레이드되어 보완된 시스템 상에 최신 보안 기능들이 비활성화되어 꺼져있는지 확인

- 애플리케이션 서버, 프레임워크, 라이브러리, 데이터베이스 상에 보안이 설정되어 있는지 확인

- 서버가 보안헤더, 보안강화수단을 보내지 않거나 안전한 값을 설정하고 있는지 확인

- 알려진 취약점이 있는 버전의 소프트웨어를 사용하고 있는지 확인

 

보안 대책

- 반복적인 본안 강화 절차를 적용해야 한다.

- 불필요한 기능, 구성요소, 문서, 샘플 애플리케이션 없이 최소한으로 플랫폼을 유지하고 사용하지 않는 기능과 프레임워크는 꼭 삭제하거나 설치를 하지 말아야 한다.

- 패치 관리 절차의 일부분으로 모든 보안 정보, 업데이트, 패치를 대상으로 설정을 적절히 검토하고 갱신하는 절차가 필요하며, 특히 S3 버킷 권한과 같은 클라우드 스토리지 권한을 검토하는 절차가 중요하다.

- 세분화, 컨테이너화, 클라우드 보안 그룹과 같은 방법으로 구성 요소나 입주자들 간에 효율적이고 안전한 격리를 제공하는 세분화된 애플리케이션 아키텍처를 적용해야 한다.

- 보안 헤더와 같은 보안 강화 수단들 사용자에게 전송해야 한다.

- 모든 영역의 보안 설정이 적절히 반영되어 있는지 검증할 수 있는 자동화된 절차를 수립해야 한다.

 

 

공격 시나리오 예제 

 

시나리오 #1

알려진 취약점을 포함하고 있는 샘플 애플리케이션이 삭제되지 않은 채로 애플리케이션 서버가 운영 환경에서 사용 중이라면, 샘플 애플리케이션은 공격자가 서버를 공격하는데 악용될 수 있습니다. 샘플 애플리케이션 중에 관리 콘솔이 포함되어 있고 디폴트 계정 정보가 변경되지 않았다면, 공격자는 디폴트 패스워드를 사용해 접속에 성공함으로써 권한을 획득할 수도 있습니다. 

 

시나리오 #2

서버 내 디렉토리 리스팅이 비활성화되지 않았다면, 공격자는 디렉토리 목록이 노출됨을 발견하게 되고 자바 클래스 파일을 다운로드하여 디컴파일과 리버스엔지니어링을 통해 애플리케이션 상에 존재하는 심각한 접근 통제 취약점을 찾아낼 수도 있습니다. 

 

시나리오 #3

사용자에게 전달하는 응답 메시지 상에 스택 추적 정보와 같은 상세한 에러 메시지를 노출하도록 애플리케이션 서버가 설정되어 있다면, 구성 요소 버전 정보와 같은 공격에 도움을 줄 수 있는 민감한 정보나 내부적인 결함들이 잠재적으로 노출될 수 있습니다. 

 

시나리오 #4

클라우드 서비스 제공자가 다른 클라우드 서비스 이용자들이 인터넷을 통해 접근 가능한 상태로 디폴트 공유 권한을 열어둔 상태라면, 클라우드 스토리지에 저장되어 있는 민감한 데이터에 대한 접근을 허용할 수도 있습니다.