지난 2019년, 미국의 한 은행에서 고객정보가 대량으로 유출되는 사고가 발생했습니다. 방화벽 설정이 미흡했던 것을 이용해 ‘SSRF(Server Side Request Forgery)’ 공격을 시도한 것입니다. 이로 인해 1억 600만 명의 고객 정보가 해킹돼 유출됐습니다. 이 개인정보 중 일부가 인터넷에 공개되었으며, 이를 복구하기 위한 비용은 1,772억 원으로 추산되고 있습니다. 이런 엄청난 피해를 일으킨 SSRF에 대해서 알아보겠습니다.

SSRF란?

SSRF는 취약한 서버를 이용하여 공격자가 내부 서버에 원하는 요청을 보내도록 하는 방법입니다. 보통 공격자가 과도한 정보나 기능을 요청할 경우, 방화벽에서 필터링하거나 웹 서버에서 원하는 정보를 보내주지 않습니다. 하지만 인터넷 앞단의 웹서버가 입력된 URL 값을 충분하게 검사하지 않고 내부 서버로 전달한다면 이야기가 달라집니다. 이것을 이용해서 내부 서버의 정보를 노출시키거나 서비스 거부 공격할 수 있는 것입니다. 이처럼 SSRF는 웹페이지 번역 서비스, PDF 문서 생성기의 잘못된 구현이나, 퍼블릭 클라우드 환경에서 메타서버 접근통제가 미흡한 경우 발생할 수 있습니다.

공격자가 SSRF를 이용하는 이유는 많은 권한을 가진 서버의 요청을 이용할 수 있기 때문입니다. 일반 사용자가 웹서버를 공격하여 수집할 수 있는 정보는 많지 않습니다. 하지만 웹서버의 권한을 이용하여 내부 서버를 공격한다면 내부 정보에 접근할 수 있을 뿐만 아니라, 시스템의 기능이나 설정에도 접근할 수 있습니다. 방화벽 안의 내부는 안전하다는 생각에, 보안 설정이 미흡하거나, 보안 모니터링이 미흡한 경우가 있습니다. 공격자는 이러한 맹점을 이용하여 손쉽게 공격할 수 있게 됩니다.

SSRF는 ‘CSRF(Cross Site Request Forgery)’와 비슷한 이름을 가지고 있습니다. 이 두 공격은 비슷한 방식을 사용하지만 이용하는 매개체가 다릅니다. 원하는 정보를 얻을 때 SSRF가 서버의 요청을 이용한다면, CSRF는 사용자의 요청을 이용하는 것이죠. 두 공격 모두 공격자가 접근할 수 없는 정보나 시스템에 접근할 수 있도록 만들어줍니다. 하지만 공통적으로 내부에서는 ‘정상 요청’이라고 인식하게 됩니다.

이번엔 SSRF 취약점을 예제를 통해 살펴보겠습니다. 다음의 샘플 웹사이트에서는 이미지 링크를 상대경로가 아닌 절대 경로 형태로 코딩한 부분이 있습니다.

프록시 도구를 이용하여 패킷을 확인해 보면 사이트가 이미지를 로딩하기 위해 GET Method가 호출되는 것을 알 수 있습니다.

공격자는 이 부분을 내부 서버 주소로 변경합니다. 퍼블릭 클라우드 환경에서 웹 애플리케이션이 실행되고 있으므로 해당 메타데이터 서버 주소인 http://169.254.169.254를 입력해 보겠습니다.

이미지 로딩 구문의 실행이 메타 서버에 접근할 수 있는 프론트 웹서버에서 실행되므로 결과가 리턴됩니다. 그리고 이미지 대신에 메타 파일 정보가 공격자에게 전송됩니다. 이 방식으로 메타 서버의 하위 경로를 반복적으로 탐색하여 인스턴스의 토큰을 찾아낼 수 있습니다.

일단 확보된 토큰을 공격자 PC에 다운로드한 후에 이를 퍼블릭 클라우드 CLI 프로그램을 이용하여 프로파일을 설정했습니다. 그 후, 클라우드 스토리지의 목록을 읽어 보았습니다. 만약 토큰에 해당하는 IAM 권한 목록에 클라우드 스토리지의 엑세스 권한이 포함되어 있다면 아래 화면과 같이 버킷 목록을 조회할 수 있습니다.

버킷 목록을 확인 후에는 파일 다운로드를 실행해 봅니다. IAM 권한 목록에 다운로드 권한까지 포함되어 있다면 공격자는 개인정보와 계정정보(중요정보)를 다운로드할 수 있습니다.

이와 같은 방식으로 SSRF의 취약점을 이용한 정보유출 사고가 발생할 수 있습니다.

SSRF를 방지하려면?

1.입력값 검사
먼저 사용자의 입력값을 그대로 사용하지 않아야 합니다. 공격의 시작은 사용자의 입력값이기 때문입니다. 그래서 사용자의 입력값을 검사하여, 서버에서 제공하는 서비스만 이용하도록 해야 합니다. 화이트리스트 방식이나 블랙 리스트 방식을 통해 사용자 입력값을 검사하면 보안사고를 방지하는 데에 도움이 될 수 있습니다.

SSRF는 http 프로토콜만 이용하는 것이 아니라, 잘 알려지지 않았거나 잘 사용되지 않는 file://, dict://와 같은 URL schema도 이용합니다. 요청 값의 데이터 값에서 http 요청을 보내면 되기 때문에, http 요청이 아니라고 해도 SSRF 공격이 있을 수 있습니다. 따라서 사용하는 URL schema에 대해서만 허용하고, 사용하지 않는 schema에 대해서는 입력값을 받지 않도록 해야 합니다.

2.최소 권한의 사용
DMZ 구간의 퍼블릭 클라우드 인스턴스에는 IAM 권한을 최소한으로 부여하고 철저히 관리해야 합니다. 웹서버 인스턴스, 웹방화벽 인스턴스, 방화벽 인스턴스, 관리자웹 인스턴스와 같이 프론트에 위치한 인스턴스 모두 IAM 권한 점검 대상이 돼야 합니다. 개발 후 운영으로 이관되는 시점에 인스턴스의 권한이 결정될 수 있으므로, 운영 준비 단계에서 IAM 권한에 대한 점검이 필수로 수행돼야 합니다.

3.접속 기록 및 알람
SSRF 공격 징후를 탐지할 수 있는 접속 기록을 남겨야 합니다. 또한, 탐지 룰을 이벤트로 등록하여 담당자에게 알람을 전송할 수 있도록 구성해야 합니다.

4.개발 보안 라이프사이클
개발 초기 단계부터 보안을 고려하며 설계하고, 개발이 완료된 후에 취약점 진단을 받아야 합니다. 개발 초기부터 보안을 고려하면 예상하지 못했던 부분에서 보안 사고가 일어나는 것을 막을 수 있습니다. 하지만, 이렇게 보안을 고려해도 누락되는 부분이 있을 수 있습니다. 그래서 개발을 완료한 후에도 취약점 진단을 통해서 미흡한 설정값이나, 과도하게 권한 설정이 된 부분, 입력값 검증이 누락된 부분 등을 찾는 것이 중요합니다. SSRF의 취약점 역시 취약점 진단 서비스를 통해서 취약점이 존재하는지 확인할 수 있습니다. 이를 통해서 보안 사고가 일어나지 않도록 방지할 수 있습니다.

글 ㅣ LG CNS RED팀