PortSwigger - Web LLM attacks (5)

원문을 확인하려면 아래의 더보기란을 클릭하세요. 

Exploiting routing-based SSRF to bypass restrictions

Even if high-risk APIs are restricted and sensitive data is protected, AI-powered scanners can still be manipulated into making unintended internal requests. This is because scanners typically run inside the internal network and can construct arbitrary HTTP requests, effectively making them a programmable Server-Side Request Forgery (SSRF) vector.

One way to exploit this is through routing-based SSRF. This can occur via several mechanisms, including open redirects, URL interpretation discrepancies between components, and Host header manipulation. In each case, the attacker exploits a flaw in how the application or its infrastructure handles request routing to redirect the scanner to an unintended destination.

Host header manipulation is a particularly powerful technique in this context. Web applications often use the Host header to route requests to the correct internal service. By modifying this header, an attacker can redirect the scanner's requests to internal services that would normally be inaccessible from the public internet.

The attack typically follows this sequence:

1. The attacker injects a prompt instructing the scanner to send a request to an internal path, such as /admin, with a modified Host header pointing to an internal IP address.
2. The scanner executes the request from its privileged position inside the internal network.
3. The response is processed by the scanner and can be exfiltrated back to the attacker, for example by posting it as a comment.

This chains three elements that individually pose significant risk, but together enable a potentially even more severe attack:

 

 

AI Powered Scanner에서 위험도가 높은 API의 사용을 제한하고 민감한 데이터를 보호하더라도 공격자는 Scanner가 의도하지 않은 내부 Request를 전송하도록 조작할 수 있다. 이러한 문제가 발생하는 이유는 AI Powered Scanner가 일반적으로 내부 네트워크에서 실행되며 보안 테스트를 위해 다양한 HTTP Request를 직접 구성하고 전송할 수 있기 때문이다.

 

외부 공격자는 일반적으로 내부 네트워크의 서비스에 직접 Request를 보낼 수 없다. 하지만 내부에서 실행되는 Scanner는 해당 서비스에 접근할 수 있을 가능성이 있다. 따라서 공격자가 Prompt Injection을 통해 Scanner가 전송할 HTTP Request를 조작할 수 있다면 Scanner를 일종의 프로그래밍 가능한 SSRF 도구처럼 악용할 수 있다.

SSRF는 Server Side Request Forgery의 약자로 공격자가 서버를 이용하여 원래 공격자가 직접 접근할 수 없는 시스템에 Request를 보내도록 만드는 공격이다.

 

여기에서는 Routing Based SSRF를 이용할 수 있다. Routing Based SSRF는 애플리케이션이나 인프라가 HTTP Request를 어떤 목적지로 전달할지 결정하는 Routing 과정의 문제를 이용한다. 대표적으로 Open Redirect, 여러 Component 사이의 URL 해석 차이, Host Header Manipulation 등을 이용할 수 있다.

 

이들의 공통점은 Request Routing 과정의 허점을 이용하여 Scanner가 원래 의도했던 곳이 아닌 다른 목적지로 Request를 전송하도록 만드는 것이다. 이 중 Host Header Manipulation은 AI Powered Scanner 환경에서 특히 강력하게 사용될 수 있다.

 

HTTP Request의 Host Header는 요청의 대상 Host를 나타낸다. 하나의 서버나 인프라가 여러 서비스 또는 도메인을 처리하는 환경에서는 Host Header를 이용하여 Request를 어떤 서비스로 전달할지 결정하기도 한다. 공격자가 이 Host Header를 조작할 수 있다면 Scanner가 보내는 Request를 원래 목적지가 아닌 내부 서비스로 Routing하도록 유도할 수 있다.

 

예를 들어 공격자는 Indirect Prompt Injection을 통해 Scanner가 admin과 같은 내부 Path로 Request를 보내면서 Host Header에는 내부 IP 주소를 사용하도록 지시할 수 있다. Scanner가 이 명령을 실행하면 Request는 Scanner가 위치한 내부 네트워크에서 전송된다. 외부 공격자는 해당 내부 IP에 직접 접근하지 못하더라도 Scanner는 내부 네트워크에 존재하기 때문에 접근할 수 있을 가능성이 있다. 이후 내부 서비스의 Response가 Scanner에게 반환된다.

 

여기에 앞에서 살펴본 Data Exfiltration을 연결할 수도 있다. Scanner가 받은 내부 Response를 공격자가 볼 수 있는 댓글이나 다른 공개 영역에 작성하도록 Prompt Injection을 통해 유도하는 것이다.

 

전체적인 공격 흐름은 다음과 같다.

1. 공격자가 Scanner가 읽는 콘텐츠에 Indirect Prompt Injection을 삽입한다.

2. Prompt를 통해 Scanner가 특정 내부 Path로 HTTP Request를 보내도록 유도한다. 이 과정에서 Host Header를 내부 IP 주소나 내부 서비스로 변경하도록 유도한다.

3. Scanner는 내부 네트워크에서 Request를 실행한다. Routing 과정에서 조작된 Host Header에 따라 Request가 내부 서비스로 전달된다.

4. Scanner가 내부 서비스의 Response를 받는다. Response를 공격자가 확인할 수 있는 댓글이나 공개 영역에 작성하도록 유도한다.

5. 결과적으로 외부에서는 직접 접근할 수 없었던 내부 서비스의 데이터가 공격자에게 전달될 수 있다.

이 공격이 강력한 이유는 Prompt Injection, Host Header Manipulation, Scanner의 Network Privilege라는 세 가지 요소가 연결되기 때문이다.

 

Prompt Injection은 Scanner의 LLM이 무엇을 해야 하는지에 대한 판단을 공격자가 조작할 수 있게 한다. Host Header Manipulation은 Scanner가 생성한 Request가 어디로 Routing될지를 조작하는 역할을 한다. Scanner의 Privileged Network Position은 외부 공격자가 직접 접근할 수 없는 내부 Resource에 접근할 수 있게 한다.

 

Prompt Injection - Scanner의 행동 조작 - Host Header Manipulation - Request의 목적지 조작 - Scanner의 내부 네트워크 권한 - Internal Resource 접근 - Data Exfiltration - 공격자에게 결과 전달

 

이러한 상황에서 AI Powered Scanner는 단순히 공격받는 대상에 그치지 않는다. 공격자가 외부에서는 가질 수 없는 신뢰된 위치에서 기존 Web Vulnerability를 공격하기 위한 도구로 Scanner 자체를 이용하게 된다. 따라서 AI Powered Scanner를 설계할 때는 LLM의 Reasoning Engine이 공격자에게 영향을 받을 수 있다는 것을 전제로 보안을 설계해야 한다.

 

설계 방법 1. Scanner의 Credential과 Access Control을 제한해야 한다. Principle of Least Privilege 즉 최소 권한 원칙을 적용하여 현재 보안 테스트에 필요한 권한만 Scanner에 제공해야 한다.

 

설계 방법 2. Scanner의 Identity와 실제 Administrator의 Identity도 분리해야 한다. AI Powered Scanner에는 실제 관리자 계정을 제공하기보다 보안 테스트를 위한 별도의 계정을 사용하는 것이 좋다. Scanner가 Prompt Injection에 의해 조작되더라도 실제 관리자와 동일한 권한을 사용하지 못하도록 하는 것이다.

 

설계 방법 3. Scanner에 대한 보안 통제는 Server Side에서도 적용해야 한다.

LLM이 악성 명령을 알아서 거부할 것이라고 가정하면 안 된다. Prompt를 통해 특정 행동을 금지하더라도 공격자가 LLM의 판단을 우회할 가능성이 있기 때문이다. 따라서 어떤 사용자 또는 Scanner가 특정 Resource에 접근할 수 있는지는 LLM의 판단이 아니라 실제 Application이나 API의 Access Control을 통해 검증해야 한다.

 

설계 방법 4. 사용자가 수정할 수 있는 모든 콘텐츠를 신뢰할 수 없는 Input으로 취급해야 한다. 댓글, 게시글, Product Review, Profile Field처럼 Database에서 가져오는 일반적인 텍스트도 AI Scanner의 관점에서는 Indirect Prompt Injection의 입력이 될 수 있다. 기존 웹 보안에서는 이러한 데이터를 XSS나 SQL Injection 등의 관점에서 검사했다면 AI Agent를 사용하는 환경에서는 해당 텍스트가 LLM의 판단과 행동을 변경할 수 있는 Instruction으로 해석될 가능성까지 고려해야 한다.

 

결국 핵심적인 방어 원칙은 LLM이 공격자의 Prompt Injection에 영향을 받더라도 피해가 제한되도록 만드는 것이다. LLM 자체가 모든 악성 Prompt를 정확하게 구분할 것이라고 기대하기보다는 Scanner의 계정 권한, 네트워크 접근 범위, API 권한, Server Side Access Control 등을 제한하여 LLM의 잘못된 판단이 실제 시스템 침해로 이어지지 않도록 설계해야 한다.