ssrf(server-side request forgery) 는 서버 측 요청 위조 공격으로, 공격자가 웹 서버를 속여 무단 공격 요청을 보내도록 유도하는 수법을 이용한 공격입니다.
웹 서버가 외부에서 직접 접근할 수 없는 내부망 서비스(관리자 권한이 위치한 곳)와 통신할 수 있음을 이용하여, 공격자는 웹 서버의 권한으로 악의적인 요청을 보내 외부에서 간접적으로 내부망 서비스를 이용할 수 있습니다.
ssrf 공격 유형에는 대표적으로 2가지가 있는데요, 이용자가 입력한 url에 요청을 보내는 공격 유형과 이용자가 입력한 값이 http body에 포함되는 공격 유형이 있습니다.
이번에 풀어볼 문제는 'Basic SSRF against another back-end system' 문제로, 응용 프로그램 서버가 사용자가 직접 도달할 수 없는 다른 백엔드 시스템과 상호 작용할 수 있는 것을 이용한 문제입니다. 응용 프로그램 서버가 접근할 수 있는 백엔드 시스템에는 라우팅할 수 없는 개인 IP 주소가 있는 경우가 많습니다. 백엔드 시스템은 일반적으로 네트워크 토폴로지(network topology)에 의해 보호되므로 보안 상태가 약한 경우가 많습니다. 대부분의 경우 내부 백엔드 시스템에는 시스템과 상호작용할 수 있는 중요한 기능을 수행할 수 있는 관리자 서비스가 존재합니다.
이 문제는 백엔드에 존재하는 관리자 시스템에 공격자가 ssrf 취약성을 이용하여 웹 서버가 무단 요청을 보내도록 유도하고, 요청을 통해 관리자 시스템에 접근하여 관리자 기능을 이용하는 문제입니다. 이 문제를 풀기 위해, portswigger ssrf lecture의 SSRF attacks against other back-end systems 부분과 michael rosome 의 문제풀이를 참고하였습니다.
일단 문제 사이트에 들어가 봅시다😎
취약 사이트에 들어가 봅니다.
버프 슈트를 켜서 패킷을 잡아 봅시다.
잡은 패킷을 인트루더로 보낸 후, clear를 눌러 payload가 들어갈 위치를 초기화 해줍니다.😎
여기서부터 중요한데요, stock api의 값을 변경합니다.
그리고 위의 '1'부분을 드래그하고, add를 눌러 payload 공격을 수행할 부분을 지정합니다.
그리고 payload창으로 들어가서, 공격 수단을 설정해 줍니다.
payload type을 numbers(지정된 범위에서 지정된 형식에 맞는 숫자 형태의 페이로드를 생성하는 유형)로 설정하고, 수의 범위를 1부터 255까지 지정해 줍니다. 그런 다음 start attack을 눌러, 공격을 수행해 봅시다.
(오래 걸려요.....😭)
공격이 끝나고, status 값이 다른 payload를 찾았습니다. 188을 대입했을 때, 공격이 성공한 것을 확인할 수 있습니다.
사이트 패킷을 새로 잡아봅시다.
여기서, stock api의 값을 변경합니다.
변경한 후, forward를 누른 후에, 다시 사이트에 돌아가 보면,
관리자 권한에 접근하는 데 성공하였습니다.😊 이제부터 관리자의 권한을 이용하여, 시스템을 변경해 봅시다😎
개발자 모드에 들어가 보면, 사용자 carlos를 삭제할 수 있는 기능을 가진 스크립트가 보입니다.
버프 슈트에서 새로 패킷을 잡은 후에, stock api의 값을 위의 개발자 모드에서 찾아낸 스크립트로 변경해 줍니다.
forward를 눌러줍니다.
?? 사이트에 아무런 변화가 없습니다....😅forward를 한번 더 눌러본 후, 사이트에 돌아가 봅시다.
carlos가 성공적으로 삭제된건지 문제가 해결되었다고 뜹니다.😊
버프 슈트를 이용하여 공격을 수행할 백엔드 시스템의 개인 ip를 찾아내고, 찾아낸 ip를 기반으로 관리자 시스템에 접근하여 관리자 기능을 간접적으로 이용해 보는 문제였습니다.