서버가 해커의 ’심부름꾼’이 되는 순간
택배기사가 건물 안으로 들어섭니다. 경비원은 늘 드나드는 택배기사라 별 의심 없이 통과시키죠. 그런데 건물 밖에 있던 누군가가 그를 붙잡고 부탁합니다. "저 안쪽 사무실에 중요한 서류가 있는데, 그것 좀 대신 가져다 주세요." 정작 자기는 경비원에게 막혀 들어가지도 못하면서 말이죠. 택배기사는 별 생각 없이 안으로 들어가 서류를 들고 나와 건넵니다. 황당한 이야기 같지만, 웹 서버 세계에서는 이런 일이 실제로 벌어집니다. 바로 SSRF 공격입니다.
▲ 서버를 조종해 정보를 빼내는 SSRF
SSRF가 대체 뭔가요?
SSRF(Server-Side Request Forgery, 서버 측 요청 위조)는 공격자가 서버를 속여서 대신 요청을 보내게 만드는 공격입니다.
예를 들어 어떤 사이트에 "이미지 주소를 입력하면 미리보기를 보여주는" 기능이 있다고 합시다. 보통은 https://example.com/cat.jpg 같은 외부 주소를 넣죠. 그런데 공격자가 여기에 외부 주소가 아니라 회사 내부 주소를 몰래 넣습니다. 그러면 서버는 "어, 사용자가 요청했으니까" 하고 순순히 내부 시스템에 접속해서 그 내용을 가져다 보여줍니다.
핵심은 '신뢰'입니다. 방화벽(외부 침입을 막는 보안 장벽)은 외부인은 막지만, 내부 서버끼리의 대화는 막지 않습니다. 마치 경비원이 외부 손님은 일일이 검문해도, 늘 드나드는 택배기사는 그냥 통과시키는 것과 같죠. 공격자는 이 신뢰를 노립니다. 자기가 직접 못 들어가는 곳을, 이미 안에 들어가 있는 서버를 시켜서 털어내는 겁니다.
공격은 '주소 한 줄'에서 시작됩니다
말로만 들으면 막연하니, 실제 요청을 보겠습니다. 앞서 말한 미리보기 기능은 보통 이런 요청을 서버에 보냅니다.
GET /preview?url=https://example.com/cat.jpg
여기서 url= 뒤가 바로 '서버가 대신 접속할 주소'입니다. 공격자는 이 한 줄만 슬쩍 바꿔치기합니다.
GET /preview?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
단 한 글자도 코드를 건드리지 않았습니다. 목적지 주소만 바꿨을 뿐인데 결과는 완전히 달라집니다.
▲ 왼쪽은 정상, 오른쪽은 공격
169.254.169.254는 클라우드 서버 안에서만 통하는 '내부 정보 창구' 주소입니다. 서버는 의심 없이 이곳에 접속해 역할 이름을 받아오고, 공격자가 그 이름을 주소 뒤에 한 번 더 붙이면 이번엔 AccessKey(접속 열쇠)와 비밀키가 그대로 화면에 출력됩니다. 미리보기 칸에 고양이 사진 대신 회사 금고 열쇠가 찍혀 나오는 셈이죠. 전체 과정을 단계로 펼치면 이렇습니다.
▲ SSRF 공격이 진행되는 4단계
실제로 터진 사건 — 캐피털원 해킹
2019년 미국의 대형 은행 캐피털원(Capital One)에서 약 1억 명의 고객 정보가 유출되는 대형 사고가 터졌습니다. 공격의 핵심 무기가 바로 SSRF였습니다.
당시 캐피털원은 아마존 클라우드(AWS)를 쓰고 있었는데, 클라우드 안에는 서버만 접근할 수 있는 '내부 정보 창구'(메타데이터 서버)가 있었습니다. 여기엔 서버의 출입 열쇠에 해당하는 인증 정보가 들어 있었죠. 공격자는 잘못 설정된 방화벽(WAF, 웹 공격을 걸러내는 보안 장비)을 통해 SSRF로 서버를 속여 이 창구에 접근하게 만들었고, 거기서 인증 정보를 빼낸 뒤 고객 데이터가 담긴 저장소를 통째로 가져갔습니다. 직접 들어가지 못하는 공격자가, 서버라는 '믿을 수 있는 심부름꾼'을 시켜 내부를 통째로 털어낸 셈입니다.
그럼 어떻게 막을까요?
SSRF를 막는 원리는 의외로 단순합니다. 서버가 사용자에게 받은 주소로 접속하기 전에, 그 주소가 '가도 되는 곳'인지 한 번 검사하는 겁니다.
특히 아래 같은 내부 전용 주소로 향하는 요청은 무조건 차단해야합니다.
127.0.0.1, localhost (서버 자기 자신)169.254.169.254 (클라우드 메타데이터 서버 — 캐피털원이 털린 바로 그 주소)10.x.x.x, 192.168.x.x 등 내부망 주소
그런데 주소만 막는 건 생각보다 까다롭습니다. 공격자는 같은 169.254.169.254를 0xA9FEA9FE(16진수)나 2852039166(10진수)처럼 똑같은 주소를 다른 모습으로 바꿔 적어 단순 차단을 빠져나가거든요. 게다가 이 주소는 AWS뿐 아니라 구글·마이크로소프트 클라우드도 똑같이 쓰기 때문에, 클라우드를 쓰는 서비스라면 누구나 표적이 될 수 있습니다.
그래서 가장 안전한 방식은 '허용 목록'입니다. 막을 주소를 일일이 적기보다, 접속을 허용할 안전한 주소만 정해두고 나머지는 전부 거부하는 거죠.
혹시 여러분이 자주 쓰는 서비스에 'URL·주소를 입력받는 기능'(이미지 주소 불러오기, 링크 미리보기, 웹훅 등)이 떠오른다면, SSRF가 바로 그런 곳을 노린다는 걸 기억해 두세요. 거창한 해킹이 아니라, 그 작은 입력칸 하나가 큰 사고의 출발점이 될 수 있습니다.
서버가 해커의 ’심부름꾼’이 되는 순간
택배기사가 건물 안으로 들어섭니다. 경비원은 늘 드나드는 택배기사라 별 의심 없이 통과시키죠. 그런데 건물 밖에 있던 누군가가 그를 붙잡고 부탁합니다. "저 안쪽 사무실에 중요한 서류가 있는데, 그것 좀 대신 가져다 주세요." 정작 자기는 경비원에게 막혀 들어가지도 못하면서 말이죠. 택배기사는 별 생각 없이 안으로 들어가 서류를 들고 나와 건넵니다. 황당한 이야기 같지만, 웹 서버 세계에서는 이런 일이 실제로 벌어집니다. 바로 SSRF 공격입니다.
▲ 서버를 조종해 정보를 빼내는 SSRF
SSRF가 대체 뭔가요?
SSRF(Server-Side Request Forgery, 서버 측 요청 위조)는 공격자가 서버를 속여서 대신 요청을 보내게 만드는 공격입니다.
예를 들어 어떤 사이트에 "이미지 주소를 입력하면 미리보기를 보여주는" 기능이 있다고 합시다. 보통은
https://example.com/cat.jpg같은 외부 주소를 넣죠. 그런데 공격자가 여기에 외부 주소가 아니라 회사 내부 주소를 몰래 넣습니다. 그러면 서버는 "어, 사용자가 요청했으니까" 하고 순순히 내부 시스템에 접속해서 그 내용을 가져다 보여줍니다.핵심은 '신뢰'입니다. 방화벽(외부 침입을 막는 보안 장벽)은 외부인은 막지만, 내부 서버끼리의 대화는 막지 않습니다. 마치 경비원이 외부 손님은 일일이 검문해도, 늘 드나드는 택배기사는 그냥 통과시키는 것과 같죠. 공격자는 이 신뢰를 노립니다. 자기가 직접 못 들어가는 곳을, 이미 안에 들어가 있는 서버를 시켜서 털어내는 겁니다.
공격은 '주소 한 줄'에서 시작됩니다
말로만 들으면 막연하니, 실제 요청을 보겠습니다. 앞서 말한 미리보기 기능은 보통 이런 요청을 서버에 보냅니다.
여기서
url=뒤가 바로 '서버가 대신 접속할 주소'입니다. 공격자는 이 한 줄만 슬쩍 바꿔치기합니다.단 한 글자도 코드를 건드리지 않았습니다. 목적지 주소만 바꿨을 뿐인데 결과는 완전히 달라집니다.
▲ 왼쪽은 정상, 오른쪽은 공격
169.254.169.254는 클라우드 서버 안에서만 통하는 '내부 정보 창구' 주소입니다. 서버는 의심 없이 이곳에 접속해 역할 이름을 받아오고, 공격자가 그 이름을 주소 뒤에 한 번 더 붙이면 이번엔 AccessKey(접속 열쇠)와 비밀키가 그대로 화면에 출력됩니다. 미리보기 칸에 고양이 사진 대신 회사 금고 열쇠가 찍혀 나오는 셈이죠. 전체 과정을 단계로 펼치면 이렇습니다.▲ SSRF 공격이 진행되는 4단계
실제로 터진 사건 — 캐피털원 해킹
2019년 미국의 대형 은행 캐피털원(Capital One)에서 약 1억 명의 고객 정보가 유출되는 대형 사고가 터졌습니다. 공격의 핵심 무기가 바로 SSRF였습니다.
당시 캐피털원은 아마존 클라우드(AWS)를 쓰고 있었는데, 클라우드 안에는 서버만 접근할 수 있는 '내부 정보 창구'(메타데이터 서버)가 있었습니다. 여기엔 서버의 출입 열쇠에 해당하는 인증 정보가 들어 있었죠. 공격자는 잘못 설정된 방화벽(WAF, 웹 공격을 걸러내는 보안 장비)을 통해 SSRF로 서버를 속여 이 창구에 접근하게 만들었고, 거기서 인증 정보를 빼낸 뒤 고객 데이터가 담긴 저장소를 통째로 가져갔습니다. 직접 들어가지 못하는 공격자가, 서버라는 '믿을 수 있는 심부름꾼'을 시켜 내부를 통째로 털어낸 셈입니다.
그럼 어떻게 막을까요?
SSRF를 막는 원리는 의외로 단순합니다. 서버가 사용자에게 받은 주소로 접속하기 전에, 그 주소가 '가도 되는 곳'인지 한 번 검사하는 겁니다.
특히 아래 같은 내부 전용 주소로 향하는 요청은 무조건 차단해야합니다.
127.0.0.1,localhost(서버 자기 자신)169.254.169.254(클라우드 메타데이터 서버 — 캐피털원이 털린 바로 그 주소)10.x.x.x,192.168.x.x등 내부망 주소그런데 주소만 막는 건 생각보다 까다롭습니다. 공격자는 같은
169.254.169.254를0xA9FEA9FE(16진수)나2852039166(10진수)처럼 똑같은 주소를 다른 모습으로 바꿔 적어 단순 차단을 빠져나가거든요. 게다가 이 주소는 AWS뿐 아니라 구글·마이크로소프트 클라우드도 똑같이 쓰기 때문에, 클라우드를 쓰는 서비스라면 누구나 표적이 될 수 있습니다.그래서 가장 안전한 방식은 '허용 목록'입니다. 막을 주소를 일일이 적기보다, 접속을 허용할 안전한 주소만 정해두고 나머지는 전부 거부하는 거죠.
혹시 여러분이 자주 쓰는 서비스에 'URL·주소를 입력받는 기능'(이미지 주소 불러오기, 링크 미리보기, 웹훅 등)이 떠오른다면, SSRF가 바로 그런 곳을 노린다는 걸 기억해 두세요. 거창한 해킹이 아니라, 그 작은 입력칸 하나가 큰 사고의 출발점이 될 수 있습니다.
문건호 | mkh@cela.kr