SSRF URL Filtering Bypass

 

웹은 알면 알수록 이상한게 정말 많은 것 같다.

어떠한 형태로 딱 Align된게 아니라 돌연변이 같은 친구들이 여기저기 존재한다.

완벽한 보안은 없다지만 웹은 더더욱 그런 것 같다.

 

이번에 다룰 내용도 돌연변이같은 것들 중에 하나인데, SSRF 우회기법에서는 보편적으로 사용되는 방법이다.

 

---

Encoding URL

http://0xDF82C3C8 (Hex Encoding)

http://3749888968 (Decimal Encoding)

http://0337.0202.0303.0310 (Octet Encoding)

http://0xDF.0202.195.200 (Mixed Encoding)

 

신기하게도 저 이상한 4개의 주소 모두 네이버로 연결된다.

 

어떻게 이런게 가능한가 싶어서 이리저리 찾아보니까 위키피디아에서 그 이유를 찾을 수 있었다.

간단히 말하자면, 오래전에 사용하다가 Legacy로 남아서 현재는 비공식적인 표현이지만 계속해서 지원해주고 있는 모양이다.

공격자들은 이런걸 놓치지 않고 필터링을 우회하는데 사용하고 있는 것이고..

 

이러한 필터링 우회기법은 SSRF에 많이 사용되는데, SSRF란 서버를 통해 내부망 자원에 접근하는 공격을 말한다.

보통 내부망 자원들의 접근제어는 엄격하게 잡아놓지 않기 때문에, 신뢰되는 서버 요청을 통해 내부 자원에 접근할 수 있게 된다.

 

예를 들어, 사용자가 입력한 URL로 서버가 요청을 보내는 구조의 서비스와 내부에서만 접근할 수 있는 포인트 지급 API가 있다고 해보자

공격자가 URL을 포인트 지급 API로 설정해서 요청을 보내면, 서버는 해당 URL에 접근하면서 유저에게 포인트를 지급하게 될 것이다.

 

이렇게 어떤 내부 자원에 접근하느냐에 따라 그 파급력도 상당한 공격인데, 이를 블랙리스트 방식으로 검증하게 되면 우회포인트가 상당히 많아진다.

 

HackerOne SSRF Bypass Report: https://hackerone.com/reports/303378

 

 

---

SSRF 방어로직에 대한 생각

 

화이트리스트 기반의 필터링이 정답이다.

답은 심플하게 정해져 있지만, 비즈니스 로직을 고려한다면 무작정 화이트리스트 정책을 가져갈 수 없는 상황이 발생할 수 있다.

여기서부터 고민이 시작된다.

 

예를들어, 사용자가 입력한 URL에서 이미지 데이터를 가져와서 저장해주는 서비스가 있다고 해보자

서버가 URL에 접속해야 하니까 SSRF공격을 생각해야 하는 상황인데, 여기에 무작정 화이트리스트 정책을 적용한다?

사용자가 어떤 URL을 요청할 줄 알고? 그때 그때마다 확인해서 화이트리스트에 추가해준다? 이건 말도 안된다. 그럼 이 서비스는 망한다.

 

이렇게 어쩔 수 없이 블랙리스트 정책을 가져가야 한다면, 요청 서버와 내부망을 분리해주면 된다.

어차피 SSRF는 내부망 자원을 접근하는게 목적이기 때문에, 요청 서버를 내부망에서 분리해버리면 SSRF공격은 의미가 없어진다.

(얘도 내부망에 접근 못하니까!)

 

더 나아가 내부망의 서버들도 각 각의 접근제어를 적용해주면 더 좋다.

Credential 기반이 됐던, 시스템 로직 기반 됐던 내부 서비스에 인가된 사용자만 접근할 수 있도록 설정해주면 된다.

 

그 중 mtls라는 암호화 통신을 예로 들 수 있는데, 기존 TLS통신에서 클라이언트 인증서 검증 과정이 추가된 프로토콜이다.

요건 나중에 정리해서 포스팅할 수 있으면 올리도록 하겠다.

 

MTLS(Mutual TLS) 참고: https://blog.jeann.net/cloudflare/access/2020/06/07/mtls-implementation-ko.html