SSRF | Peoplstar’s Note

본 내용 및 실습 환경은 KISEC, 케이쉴드 주니어 교육 과정에 있음을 알려드립니다.

정의

서버 사이트 요청 위조(SSRF)는 사이트 간 요청 위조(CSRF)보다 훨씬 위험하다. 해당 공격은 공격자가 서버를 속여 무단으로 요청을 보내는 수법이다.

일반적으로 외부에서도 접근 가능하도록 웹 서버를 운영하는 조직은 공인 IP 주소를 부여하여 인터넷에 공개한다.

반면 조직 내부에서 사용하는 서버는 방화벽을 통해 외부 접근을 막거나 내부에서만 사용가능한 사설 IP를 할당하도록 한다.

즉, 서버끼리의 요청을 공격자가 위조하는 것이다.

SSRF는 이번 2021 OWASP TOP 10에 새롭게 포함되었다. 기존에 존재했을 취약점이지만 OWASP에 새롭게 등재 되었다는 것을 그 만큼 위험하는 것을 의미 할 것이다.

시뮬레이션

외부에서는 웹 서버(A 서버)만 접근이 가능
- 웹 서버 내에서는 동일한 로컬 네트워크에 속해 있는 내부망(B 서버)들로 접속할 수 있다.

해당 웹서버가 SSRF 취약점이 있다면?

공격자는 웹 서버를 통해 조작된 요청을 내부망으로 보낸다.
- 내부망에서는 신뢰하는 접근이기 때문에 정상적으로 요청에 대한 응답한다.
- 공격자는 취약한 웹 서버를 통해 내부망의 응답 결과를 확인 가능하다.

공격자는 A서버에게 요청하여 다시 B서버로 요청 가야 할 요청을 접근 할 수 없는 C서버로의 요청으로 위조하게 되는 것이다.

실습

외부에서 접속하는 IP(A)	서버(B)
10.200.165.4	10.200.165.8

A가 B의 내부망에 접근하는 것은 불가능하다.
K-Shield에서 제공한 SSRF 테스트로 실습하는 것이다.

1. Port Scan SSRF

A는 B의 접속을 위해 8000번의 포트로 접근하다.

B는 외부에서의 80번의 포트를 8000번으로 포트포워딩 하고 있다. A가 B의 Loopback을 80번으로 접근하면 B는 내부망에서 Loopback을 요청한 것으로 받아들인다.

그 결과로 B의 Loopback을 그대로 받아온다. 여기서 Loopback을 8000번으로 접근하면 어떻게 될까?

내부망에서는 80번 포트가 열려있고, 8000번을 포트포워딩용이기에 내부망에서는 실질적인 8000번 요청은 받아드리지 못한다.

이렇게 외부 A가 서버에게 비정상적인 요청을 했을 때, 서버는 해당 요청을 B가 요청한 것처럼 위조하여 내부망에게 질의한다.

2. File Content

위에서 설명했던 내용을 토대로 이번엔 내부망에 존재하는 파일을 출력해본다.

file:///etc/hosts을 검색해 살아있는 IP대역을 확인 해본다.

hosts 파일은 dns, 내부에서 사용하는 domain 확인 가능하다. 10.0.0.100이 살아있고, 무슨 내용인지 확인해보면 아래와 같은 내용이다.
```
This is secretserver!
Only accessible from 10.0.0.0/24!
```
숨겨진 서버라 하며 10.0.0.0에 subnet 24으로 확인이 되었고, 이후는 10.0.0 대역의 살아있는 IP를 스캔해서 확인 후 포트 스캔을 했다는 시나리오로 진행했습니다.
- 숨겨진 IP로는 10.0.0.200이고, 해당 포트는 9200가 열려있다 !

B의 내부망에 존재하는 locat.txt을 출력하는 것이다.

원리는 위와 같다. 이렇게 내부망의 파일을 불러 올 수도 있다는 것이다.

이처럼 file:///etc/passwd로 알려져선 안될 정보들에 확인할 수 있다.

3. WordPress 정보 수집

이번에는 다른 주소로 들어가서 SSRF 실습을 진행할 것이다.

해당 웹은 WordPress로 제작되었다. WordPress의 플러그인 Elastic Search가 대부분 설치 되어있다. 이런 사이트에 SSRF 취약점이 있다면 무슨일이 벌어지는지 확인해본다.

우선, BurpSuite를 사용할 것 이다.

WordPress가 작동하고 있는 곳으로 이동하여 Proxy를 키고 Burpsuite로 확인한다.

GET 메소드를 통해 Query를 전달하는 것을 알 수 있다. 여기서 우클릭 > Send to Repeater를 클릭하면 상단의 Repeater가 빛이 날 것이다. Repeater로 이동한다.

우리가 패킷을 수정하여 요청할 수 있는 Request와 해당 응답을 보내주는 Response가 존재한다.
Query를 변경하여 SSRF를 진행한다.

http://10.0.0.200:9200/

해당 IP는 2번에서 알아낸 것이므로, 다시 한번 확인해보시면 좋을 듯 합니다!

워드프레스의 엘라스틱 서치의 기본 포트가 9200이므로, 엘라스틱 서치를 사용하고 있다는 것을 유추 할 수 있고, 해당 쿼리는 알고 있다면 쿼리를 변경하여 보내서 정보를 수집할 수 있습니다.

http://10.0.0.200:9200/_cat/indices?v
- 9200은 ElasticSearch DB
- 색인 통계 정보

http://10.0.0.200:9200/bank/?pretty
- 개인 정보 유추

http://10.0.0.200:9200/bank/_search/?size=10
- 저장된 개인정보 유출
- Document

이 처럼 Wordpress의 Elastic Search로 접근하여 정보 수집이 가능하다.

보안 대책

애초에 서버가 file:/// URL을 수락할 이유가 없다. ftp:// 또는 slack:이나 skype:와 같은 애플리케이션별 URI 체계도 마찬가지다. 시스템은 HTTP 및 HTTPS와 같은 극소수의 프로토콜만으로 제한돼야 한다. HTTP나 https를 제외하고 사용하지 않는 URI scheme은 비활성화하거나 필터링한다.
또한, 내부 서버의 대한 사설 IP 접근을 수락할 이유가 없다. 따라서 사설 IP의 대표 3가지 대역을 블랙리스트 적용하는 것이다.
- 10.0.0.0 ~ 10.255.255.255
- 172.16.0.0 ~ 172.31.255.255
- 192.168.0.0 ~ 192.168.255.255