버프슈트를 이용한 웹 해킹, 서버 측 취약점: 서버 측 요청 위조(SSRF, Server-side request forgery)

서버 측 요청 위조(SSRF)는 공격자가 서버 측 애플리케이션이 의도하지 않은 위치로 요청을 보내도록 유도하는 웹 보안 취약점입니다.

일반적인 SSRF 공격에서 공격자는 서버가 조직 인프라 내의 내부 전용 서비스에만 연결하도록 만들 수 있습니다. 또는 서버가 임의의 외부 시스템에 연결하도록 강제할 수도 있습니다. 이로 인해 인증 자격 증명과 같은 민감한 데이터가 유출될 수 있습니다.

SSRF의 핵심은 서버가 가진 '내부 자원 접근 권한'을 탈취하는 것입니다. 현대의 인프라는 외부로 노출된 '웹 서버'와 외부 접근이 차단된 '내부 DB 서버'나 '클라우드 메타데이터 서버'로 나뉘어 있습니다.

- 신뢰 구조의 맹점: 내부 네트워크에 있는 서버들은 서로 "우리는 같은 식구니까 인증 없이 데이터를 줘도 되겠지?"라는 신뢰 관계를 맺고 있는 경우가 많습니다.
- 공격 매커니즘: 공격자는 웹 애플리케이션이 외부 URL로부터 데이터를 가져오는 파라미터(예: URL 미리보기, 파일 업로드 등)를 조작합니다. 여기에 외부 주소가 아닌 127.0.0.1(로컬)이나 내부 사설 IP를 주입합니다.
- 결과: 방화벽 뒤에 숨겨진 내부 서비스들은 웹 서버가 보낸 요청을 '정당한 요청'으로 인식하고 민감한 정보(AWS 설정 값, 데이터베이스 내용 등)를 반환합니다. 결과적으로 공격자는 직접 접근할 수 없는 내부망을 웹 서버를 프록시(Proxy)처럼 활용하여 장악하게 됩니다.

SSRF(Server-Side Request Forgery)는 웹 애플리케이션이 사용자가 제공한 URL을 검증 없이 서버의 권한으로 호출할 때 발생하는 취약점입니다. 핵심은 '공격자가 직접 갈 수 없는 곳을 서버의 이름표를 빌려 방문하는 것'에 있습니다.

대부분의 기업 인프라는 **DMZ(외부망)**와 **Internal(내부망)**로 분리되어 있습니다.
- 외부망: 웹 서버가 위치하며, 전 세계 누구나 접속 가능합니다. (보안 엄격)
- 내부망: 데이터베이스(DB), 백엔드 API, 사설 클라우드 메타데이터 서버가 위치합니다. (외부 차단)
- 문제점: 내부망 서비스들은 같은 네트워크 안에 있는 웹 서버를 **'신뢰할 수 있는 소스'**로 간주하여, 별도의 인증 없이 민감한 데이터를 넘겨주는 경우가 많습니다.

서버에 대한 SSRF 공격

In an SSRF attack against the server,

서버를 대상으로 하는 SSRF 공격에서 

the attacker causes the application to make an HTTP request

공격자는 애플리케이션(웹 사이트 등)이 HTTP 요청을 생성하도록 유도합니다.

→ 공격자가 직접 서버에 접속하는 것이 아니라, 서버 안에 돌아가고 있는 프로그램이 스스로 요청을 보내게끔 조종

back to the server that is hosting the application,

(그 요청이) 애플리케이션을 호스팅하고 있는 서버로 다시 돌아오게끔

via its loopback network interface

서버의 루프백(loopback) 네트워크 인터페이스를 통해서 말입니다

This typically involves supplying a URL with a hostname like 127.0.0.1 (a reserved IP address that points to the loopback adapter) or localhost (a commonly used name for the same adapter).

이것은 보통 127.0.0.1(루프백 어댑터를 가리키는 예약된 IP 주소)이나 localhost(같은 어댑터를 가리키는 흔한 이름)와 같은 호스트 이름을 가진 URL을 제공하는 방식을 포함합니다.

 

예를 들어, 사용자가 특정 매장에서 상품의 재고 여부를 확인할 수 있는 쇼핑 애플리케이션을 생각해 보세요. 재고 정보를 제공하기 위해 애플리케이션은 다양한 백엔드 REST API에 쿼리(질의. 요청)를 보내야 합니다. 이를 위해 애플리케이션은 프론트엔드 HTTP 요청을 통해 관련 백엔드 API 엔드포인트의 URL을 전달함으로써 이 작업을 수행합니다. 사용자가 상품의 재고 상태를 확인할 때, 사용자의 브라우저는 다음과 같은 요청을 보냅니다.

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118 stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

이 요청은 서버가 지정된 URL로 요청을 보내고, 재고 상태를 가져와서, 이를 사용자에게 반환하게 만듭니다.

이 예시에서, 공격자는 서버의 로컬 URL을 지정하도록 요청을 수정할 수 있습니다.

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin

서버는 /admin URL의 콘텐츠를 가져와 사용자(공격자)에게 반환합니다.

공격자는 해당 /admin URL에 접속할 수도 있지만, 관리자 기능은 보통 인증된 사용자만 접근할 수 있습니다. 즉, 공격자는 흥미로운 정보를 볼 수 없다는 의미입니다. 그러나 만약 /admin URL에 대한 요청이 로컬 기기(서버 자신)에서 온 것인 경우, 일반적인 접근 제어(보안통제)가 우회됩니다. 애플리케이션은 관리 기능에 대한 모든 권한을 부여하는데, 왜냐하면 그 요청이 신뢰할 수 있는 위치에서 시작된 것처럼 보이기 때문입니다.

 

애플리케이션이 이런 식으로 동작하고 로컬 머신에서 오는 요청을 암묵적으로 신뢰하는 이유는 무엇일까요? 이러한 현상은 여러 가지 이유로 발생할 수 있습니다.

• 접근 제어 검사는 애플리케이션 서버 앞에 있는 다른 구성 요소에 구현될 수 있습니다. 서버로 다시 연결이 이루어질 때 해당 검사는 건너뛰어집니다.
• 재해 복구 목적으로, 애플리케이션은 로컬 컴퓨터에서 접속하는 모든 사용자에게 로그인 없이 관리자 접근 권한을 허용할 수 있습니다. 이는 관리자가 자격 증명을 분실했을 경우 시스템을 복구할 수 있는 방법을 제공합니다. 단, 이는 서버에서 직접 접속하는 사용자는 완전히 신뢰받는 사용자여야 한다는 전제하에 구현됩니다.
• 관리자 인터페이스는 메인 애플리케이션과 다른 포트 번호를 사용할 수 있으며, 사용자가 직접 접근할 수 없을 수도 있습니다.

로컬 머신에서 발생하는 요청이 일반 요청과 다르게 처리되는 이러한 종류의 신뢰 관계는 SSRF를 심각한 취약점으로 만드는 경우가 많습니다.

 

1. 해당 페이지로 이동하여 /admin관리자 페이지에 직접 접근할 수 없는지 확인해 보세요.

관리자 인터페이스는 관리자로 로그인했거나, 루프백(loopback)으로부터 요청된 경우에만 사용할 수 있습니다.

-> 당연히 안됨..ㅎ..ㅋ

 

2. 버프슈트->프록시 -> 오픈 브라우저 -> 인터셉트 오프 -> 연구실 페이지를 버프 슈트 브라우저로 연다.

 

3. 제품 페이지를 방문하여 "재고 확인"을 클릭한 다음, Burp Suite에서 해당 요청을 가로채서 Burp Repeater로 보냅니다.

4. 매개변수 stockApi의 URL을 http://localhost/admin으로 변경하세요. 그러면 관리자 인터페이스가 표시됩니다.

5. HTML을 읽어 대상 사용자를 삭제할 URL을 확인합니다. 해당 URL은 다음과 같습니다.

http://localhost/admin/delete?username=carlos

6. stockApiSSRF 공격을 수행하려면 이 URL을 매개변수에 입력하세요 .

7. 성공~

-> 관리자 페이지에서도 사라진 걸 볼 수 있다.

SSRF 공격은 다른 백엔드 시스템을 대상으로 합니다.

경우에 따라 애플리케이션 서버는 사용자가 직접 접근할 수 없는 백엔드 시스템과 상호 작용할 수 있습니다. 이러한 시스템은 종종 라우팅 불가능한 사설 IP 주소를 사용합니다. 백엔드 시스템은 일반적으로 네트워크 토폴로지에 의해 보호되므로 보안 수준이 상대적으로 취약한 경우가 많습니다. 또한 많은 경우 내부 백엔드 시스템에는 시스템에 접근할 수 있는 사용자라면 누구나 인증 없이 접근할 수 있는 민감한 기능이 포함되어 있습니다.

앞의 예시에서 백엔드 URL에 관리 인터페이스가 있다고 가정해 보겠습니다 https://192.168.0.68/admin. 공격자는 다음과 같은 요청을 제출하여 SSRF 취약점을 악용하고 관리 인터페이스에 접근할 수 있습니다.

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://192.168.0.68/admin

 

이 실습 문제를 해결하려면 재고 확인 기능을 사용하여 내부 192.168.0.X범위에서 8080포트의 관리자 인터페이스를 검색한 다음 이를 사용하여 사용자carlos를 삭제하십시오.

 

1. 버프슈트 -> 프록시 -> 오픈 브라우저 -> 인터셉트는 오프 상태, 연구실 페이지를 버프 슈트 브라우저로 연다

2. 제품을 클릭하고 "재고 확인"을 클릭한 다음 , Burp Suite에서 요청을 가로채서 Burp Intruder로 보냅니다.

3. stockApi매개변수를 http://192.168.0.1:8080/admin로 변경한 다음 IP 주소의 마지막 옥텟(숫자 1)을 강조 표시하고 추가 §를 클릭합니다 .

4. 페이로드 측면 패널 에서 페이로드 유형을 숫자 로 변경하고 시작 , 종료 및 단계 상자 에 각각 1, 255, 1을 입력 합니다 .

5. 공격을 시작하세요 .

6. 상태 열을 클릭하여 상태 코드 오름차순으로 정렬하세요. 그러면 상태가 200인 항목 하나가 표시되고 관리자 인터페이스가 나타납니다.

7. 이 요청을 클릭하고 Burp Repeater로 전송한 다음  stockApi경로를 다음으로 변경하세요. /admin/delete?username=carlos