variant 파라미터 하나가 서버 권한을 넘긴다 — Rails Active Storage 결함 대응 정리

이미지 출처: BleepingComputer

Rails로 서비스를 만들어 본 사람이라면 Active Storage를 안 써본 경우가 드물음. 프로필 사진 업로드, 첨부파일 다운로드, 썸네일 자동 생성까지 몇 줄이면 끝나니까 기본값처럼 쓰게 되는 컴포넌트임. 그런데 그 편리함의 뒷면, 즉 "이미지 변환 옵션을 URL로 전달한다"는 구조에서 심각한 결함이 나왔고, Rails 팀이 이를 긴급 패치로 막았음. 방어자 입장에서 이 건이 왜 무서운지, 그리고 무엇을 봐야 하는지 정리해 봄.

핵심 요약

• Active Storage의 이미지 variant 처리 경로에서 검증이 충분치 않아, 조작된 요청이 서버 측 코드 실행(RCE)까지 이어질 수 있는 결함이 패치됨
• 위험도가 높게 평가된 이유는 인증 없이 접근 가능한 첨부파일 URL이 공격 표면이 되기 때문임 — 로그인 벽 뒤가 아님
• 대응은 단순함: Rails·Active Storage를 패치 버전으로 올리고, 이미지 처리 프로세스를 최소 권한으로 격리하며, 변환 요청 로그에서 비정상 파라미터를 찾음

1. 이 결함의 구조 — 왜 "이미지"에서 코드 실행이 나오나

Active Storage는 원본 파일을 그대로 내려주기도 하지만, variant를 붙이면 리사이즈·포맷 변환 같은 가공본을 만들어 줌. 이때 실제 변환 작업은 Rails가 직접 하는 게 아니라 image_processing 젬을 거쳐 ImageMagick(또는 libvips) 같은 외부 바이너리에 넘김. 여기가 핵심임.

• 클라이언트가 보내는 것은 "이 이미지를 이렇게 변환해 달라"는 변환 지시(transformation) 값임
• Rails는 그 지시를 서명(signed blob key)으로 보호하지만, 검증이 우회되거나 허용 목록이 느슨하면 의도하지 않은 변환 옵션이 외부 이미지 처리기로 흘러감
• ImageMagick 계열은 옵션 자체가 매우 강력해서, 특정 옵션이 파일 경로나 외부 리소스 참조로 해석되면 사용자 입력이 명령 실행 문맥에 도달하게 됨

즉 "이미지 파일을 악성으로 만든다"가 아니라 "이미지 처리 지시를 악성으로 만든다"는 게 이 유형의 본질임. 파일 확장자 검사, 매직바이트 검사, 안티바이러스 스캔 — 전통적인 업로드 방어가 전부 무력한 이유가 여기 있음. 검사할 파일 자체가 문제가 아니기 때문임.

2. 우리 서비스가 영향권인지 30분 안에 확인하기

사고 대응은 범위 확정이 먼저임. 순서대로 보면 됨.

• 버전 확인: bundle list | grep -i rails, Rails.version으로 현재 버전을 뽑고, 릴리스 노트에 명시된 패치 버전과 대조함. Gemfile.lock이 실제 배포본과 같은지도 같이 확인해야 함 — 스테이징만 올리고 프로덕션이 남는 사고가 은근히 많음
• 사용 여부 확인: grep -rn "variant\|has_one_attached\|has_many_attached" app/로 variant 호출 지점을 찾음. Active Storage를 붙여만 두고 variant를 안 쓴다면 노출 면이 훨씬 좁아짐
• 경로 노출 확인: rails routes | grep -i active_storage로 /rails/active_storage/representations/... 같은 엔드포인트가 외부에 열려 있는지 봄. CDN이나 리버스 프록시 앞단에서 이 경로가 그대로 통과되는지도 확인 대상임
• 처리기 확인: ImageMagick을 쓰는지 libvips를 쓰는지에 따라 위험 성격이 달라짐. 개인적으로는 이참에 libvips로 넘어가는 것을 추천함. 성능도 낫고 옵션 표면이 훨씬 좁음

3. 탐지 — 로그에서 무엇을 찾을 것인가

패치를 올렸다고 끝이 아님. 패치 이전에 이미 들어왔는지를 봐야 함. 웹 서버 액세스 로그와 Rails 로그를 같이 놓고 보면 신호가 잡힘.

• Active Storage 표현(representation) 경로에 대한 요청 중 비정상적으로 긴 파라미터나 인코딩이 중첩된 값 — 정상 트래픽의 variant 키는 길이 분포가 상당히 일정함. 이 분포에서 벗어나는 값이 1차 후보임
• 같은 blob에 대해 짧은 시간에 수십~수백 번 다른 변환 파라미터로 들어오는 요청 — 정상 사용자는 썸네일 사이즈를 몇 종류만 요청함. 파라미터 브루트포싱의 전형적 패턴임
• 500 에러의 급증 — 익스플로잇 시도는 대개 실패를 먼저 남김. 이미지 변환 관련 예외(ImageProcessing::Error, MiniMagick 관련 스택트레이스)가 평소보다 늘었다면 반드시 원 요청까지 역추적해야 함
• 웹 서버 프로세스에서 파생된 예상 밖 자식 프로세스 — convert, magick은 정상이지만 그 밑에서 sh, curl, wget, bash가 뜬다면 그건 사고임. EDR이 있다면 이 부모-자식 관계를 룰로 박아두는 게 가장 확실한 탐지 지점임
• 애플리케이션 서버에서 나가는 예상치 못한 아웃바운드 연결 — 이미지 처리 서버가 외부로 먼저 말을 걸 이유는 거의 없음

4. 완화 — 패치 외에 겹쳐 둘 방어층

패치가 1순위인 건 당연하지만, 다음에 또 비슷한 결함이 나와도 버틸 수 있게 구조를 바꿔 두는 게 진짜 소득임.

• 변환 옵션 허용 목록 고정: Rails에는 처리 가능한 변환 메서드를 제한하는 설정이 있음. 서비스가 실제로 쓰는 리사이즈·포맷 변환 몇 가지만 남기고 나머지는 전부 막아 두면, 미지의 옵션 악용은 대부분 문턱에서 끊김
• 사전 정의된 variant만 허용: URL로 임의 변환을 받지 말고, 서버가 정한 프리셋(thumb, medium, large)만 이름으로 받게 설계하면 공격자가 조작할 값 자체가 사라짐. 개인적으로 가장 효과 좋은 구조 변경이라고 봄
• 이미지 처리 격리: 변환 작업을 별도 워커·별도 컨테이너로 빼고, 네트워크 아웃바운드를 차단하고, 읽기 전용 파일시스템에 비특권 계정으로 돌림. RCE가 나더라도 얻는 게 없는 환경을 만드는 것임
• ImageMagick 정책 파일 손보기: policy.xml에서 쓰지 않는 코더(MSL, MVG, HTTPS, EPHEMERAL, URL 등)를 막아 두는 것은 오래전부터 정석이었고 지금도 유효함
• WAF는 보조 수단으로: Active Storage 경로에 대해 파라미터 길이 상한을 거는 정도는 시간을 벌어 줌. 다만 서명값 형태를 흉내 낸 우회는 얼마든지 가능하니 WAF만 믿고 패치를 미루는 건 금물임

5. 이 사건에서 남길 교훈

업로드 보안이라고 하면 대개 "악성 파일을 어떻게 걸러낼까"부터 떠올리게 되는데, 실제로 크게 터지는 건 파일을 처리하는 과정인 경우가 많음. ImageMagick의 ImageTragick, 각종 문서 변환기 결함, 썸네일 생성기 취약점 — 계보가 꽤 긺. 공통점은 하나임. 신뢰할 수 없는 입력이 강력한 외부 도구에 전달되는 지점이 있다는 것.

그래서 점검 관점도 바꿔 잡는 게 좋음. "우리가 어떤 파일을 받는가"가 아니라 "사용자 입력이 최종적으로 어떤 프로그램의 인자로 도착하는가"를 그려 보는 것임. 이 지도를 한 번 그려 두면 Active Storage뿐 아니라 PDF 변환, 동영상 인코딩, 오피스 문서 미리보기까지 같은 눈으로 볼 수 있게 됨. 프레임워크가 편의 기능으로 감싸 둔 부분일수록 그 안에서 무슨 일이 벌어지는지 모르고 지나가기 쉬운데, 그런 곳이 결국 사고 지점이 되는 것 같음.

주말에 시간 내서 우리 서비스의 rails routes 한 번 뽑아 보시면 좋겠음. 생각보다 열려 있는 경로가 많아서 놀랄 수도 있음. 점검해 보시고 의외의 발견이 있었다면 댓글로 공유해 주세요. 같이 챙겨 보아요!