MOVEit 2,773개 기관: 파일 전송 서버의 SQL 인젝션 하나

아프로·2026년 11월 1일

해외 보안사고 사례

목록 보기

5/13

MOVEit 2,773개 기관 표지

2,773개. 보안 회사 엠시소프트(Emsisoft)가 집계한 MOVEit 사고 피해 조직 수입니다. 연방 기관, 주 정부, 대학, 의료·금융사가 모두 들어 있습니다. 이 조직들을 연 것은 파일 전송 서버 한 제품에 있던 SQL 인젝션 하나였습니다. 피해자 대부분은 MOVEit을 직접 쓰지도 않았습니다. 급여·연금·보험을 처리하는 협력사가 이 제품을 썼고, 그 협력사에 맡긴 데이터가 함께 빠져나갔습니다.

사고 원인: 서드파티·공급망. 인터넷에 직접 노출된 파일 전송 서버에 제로데이 SQL 인젝션이 있었고, 그 서버에 협력사 고객의 파일이 오래 쌓여 있었습니다.

한눈에 보기

항목	내용
제품	프로그레스(Progress)의 MOVEit Transfer. 기업이 대용량 파일을 주고받는 데 쓰는 파일 전송 서버
공격자	CL0P 랜섬웨어 조직(CISA·FBI). TA505로도 불림
공격 시작	2023-05-27, 미국 메모리얼데이 연휴(CISA)
취약점	웹 애플리케이션의 SQL 인젝션 제로데이, CVE-2023-34362
피해	2,773개 조직, 약 9,580만 명(Emsisoft 집계, 2024-06 기준)
방식	랜섬웨어 암호화 없이 데이터만 빼낸 뒤 협박
제재·소송	SEC 조사 종결, 조치 권고 없음(2024-08). 매사추세츠 연방법원 MDL 집단소송 진행 중

피해 규모는 엠시소프트 집계이고, 각 조직이 따로 낸 유출 통지를 모은 숫자입니다. 수치는 2026년 11월 1일 기준 공개 자료입니다.

무슨 일이 있었나

2021년부터: CL0P이 이 취약점을 시험한 정황이 있다는 분석이 나왔습니다 [분석사 의견 — Kroll].
2023-05-27: 미국 연휴 첫날, 인터넷에 열린 MOVEit Transfer 서버를 대상으로 대량 공격이 시작됩니다(CISA).
2023-05-31: 프로그레스가 취약점을 공개하고 패치를 내놓습니다. 공격이 시작되고 나흘 뒤입니다.
2023-06-02: 취약점에 CVE-2023-34362 번호가 붙습니다.
2023-06-07: 미국 사이버보안·인프라보안청(CISA)과 연방수사국(FBI)이 합동 권고(AA23-158A)를 냅니다. 6월 중 추가 취약점 2건이 연달아 공개됩니다.
2024-08: 미국 증권거래위원회(SEC)가 조사를 종결하고 조치를 권고하지 않습니다.

인터넷에 노출된 파일 전송 서버, SQL 인젝션 제로데이, 웹셸, 파일 대량 반출로 이어지는 경로와 막을 수 있었던 네 지점

SQL 인젝션(사용자 입력이 데이터베이스 명령의 일부로 실행되는 취약점)은 교과서 첫 장에 나오는 유형입니다. 이번에는 그 취약점이 제로데이(제조사도 몰라 패치가 아직 없는 취약점) 상태로 쓰였습니다. 공격자는 이 취약점으로 서버에 웹셸(서버에 몰래 심어 원격으로 조종하는 파일)을 심었고, CISA·FBI는 이 웹셸을 LEMURLOOT라고 불렀습니다. 웹셸을 통해 데이터베이스에 있던 파일이 빠져나갔습니다. 서버마다 따로 침입할 필요가 없었습니다. 같은 제품을 쓰는 서버가 인터넷에 열려 있었기 때문에 한 번에 많은 조직이 피해를 입었습니다.

왜 뚫렸나

CISA·FBI 합동 권고와 프로그레스 공지, 분석 자료가 밝힌 원인은 네 가지로 묶입니다.

알려지지 않은 SQL 인젝션. MOVEit Transfer 웹 애플리케이션에 SQL 인젝션 취약점이 있었고, 공격 당시 패치가 없었습니다(CISA·FBI, 프로그레스).
인터넷에 직접 노출된 서버. 파일 전송 서버가 인터넷에 바로 열려 있어, 취약점을 아는 쪽이 전 세계 서버를 한꺼번에 노릴 수 있었습니다.
오래 남은 파일. 전송이 끝난 민감한 파일이 서버에 오래 남아 있었다는 분석이 있습니다 [분석사 의견]. 남은 파일이 많을수록 나간 양도 많았습니다.
내 데이터가 어디 있는지 모름. 고객 조직은 협력사가 쓰는 MOVEit을 거쳐 2차 피해를 입었습니다. 자기 데이터가 어느 협력사의 어떤 제품에 있는지 몰랐습니다.

여기에 공격이 연휴 첫날에 몰려 대응 인력이 적었다는 점도 더해집니다. 1번은 제품을 만든 회사의 문제입니다. 2~4번은 제품을 쓰는 회사가 정할 수 있는 문제였습니다.

개발자 시점: 내 서비스였다면

파일 전송 서버를 직접 만들지 않더라도, 쿼리를 짜는 코드는 대부분의 백엔드에 있습니다. 사고 회사의 코드가 아니라 같은 실수를 보여 주는 일반 예시입니다. 공격 입력은 싣지 않고, 값은 모두 가짜입니다.

# 위험한 모양 · 일반 예시
def find_files(folder_id, name):
    sql = ("SELECT id, path FROM files "
           "WHERE folder_id = " + folder_id +
           " AND name = '" + name + "'")
    return db.execute(sql).fetchall()
# 입력이 쿼리 문장에 그대로 섞인다

이 코드는 사용자가 보낸 값을 쿼리 문장에 그대로 이어 붙입니다. 데이터베이스는 어디까지가 개발자가 쓴 명령이고 어디부터가 사용자 입력인지 구분하지 못합니다. 입력이 명령의 일부로 해석될 여지가 남습니다.

# 고친 모양 · 일반 예시
def find_files(user, folder_id, name):
    sql = ("SELECT id, path FROM files "
           "WHERE folder_id = %s AND name = %s "
           "AND owner_id = %s")
    return db.execute(
        sql, (int(folder_id), name, user.id)
    ).fetchall()
# 쿼리 문장과 값을 따로 보낸다

고친 모양은 세 군데가 다릅니다.

파라미터 바인딩. 쿼리 문장에는 자리(%s)만 두고 값은 따로 넘깁니다. 데이터베이스는 넘어온 값을 언제나 값으로만 다룹니다. 이 유형의 취약점은 이 방식으로 생기지 않습니다.
형 변환. 숫자여야 하는 값은 쿼리에 넣기 전에 숫자로 바꿉니다. 바꿀 수 없으면 거기서 멈춥니다.
소유자 조건. 로그인한 사용자의 파일만 조회되게 조건을 겁니다. 쿼리가 하나 잘못돼도 남의 파일까지 한 번에 나가지 않습니다.

ORM(객체와 데이터베이스 표를 이어 주는 도구)을 쓰더라도 원시 쿼리를 쓰는 부분은 남습니다. 그 부분은 코드 리뷰와 정적 분석(SAST, 소스 코드를 실행하지 않고 위험한 패턴을 찾는 검사)으로 따로 확인합니다.

외부에 여는 서버라면 운영 설정도 함께 봅니다. 아래는 같은 생각을 설정으로 옮긴 일반 예시입니다.

# 파일 전송 경로는 협력사 주소만 · 일반 예시
location /transfer/ {
    allow 192.0.2.0/24;   # 등록된 협력사
    deny  all;
}
# 전송 끝난 파일은 7일 뒤 자동 삭제(배치)
# 웹 루트에 새 실행 파일이 생기면 알림

국내에서도 같은 일이

롯데카드 297만 명(국내편 05편)도 인터넷에 열린 서버의 취약점으로 시작했습니다. 2022년 6월 이후 거래가 없던 결제 서버가 외부에 열려 있었고, 보안관제에서도 빠져 있었습니다. 다른 점은 취약점의 상태입니다. MOVEit은 제로데이였습니다. 공격이 시작된 5월 27일에는 고칠 패치가 세상에 없었습니다. 롯데카드의 WebLogic 취약점은 2017년에 패치가 나와 있었고, 금융보안원이 세 차례 관리 강화를 요구했는데도 8년 동안 적용되지 않았습니다. 패치가 없을 때는 노출을 줄이고 피해를 줄이는 장치가 버팀목이 되고, 패치가 나온 뒤에는 적용 속도가 차이를 만듭니다.

막을 수 있었던 네 지점

위 흐름도의 그린 표시와 같은 번호입니다.

외부 노출 제한. 파일 전송 서버를 VPN이나 IP 허용 목록 뒤에 두었다면, 인터넷 전체가 이 서버를 공격할 수는 없었습니다.
파라미터 바인딩. 모든 데이터베이스 쿼리를 파라미터 바인딩으로 작성했다면, 이 유형의 취약점은 생기지 않았습니다. 제품을 만드는 쪽의 몫입니다.
웹셸 감시. 웹 디렉터리에 새 실행 파일이 생기는 것을 감시했다면, 웹셸이 심긴 순간 알 수 있었습니다.
자동 삭제. 전송이 끝난 파일을 기한을 정해 자동으로 지웠다면, 침해를 당해도 나간 양이 훨씬 적었습니다.

1·3·4번은 패치가 없던 5월 27일부터 31일 사이에도 작동하는 장치입니다. 제로데이를 미리 알 수는 없어도, 열린 문의 수와 서버에 쌓인 데이터의 양은 미리 줄일 수 있습니다.

같은 사고를 막는 점검 5줄

쿼리는 모두 파라미터 바인딩으로 만든다. 원시 쿼리는 코드 리뷰와 정적 분석(SAST)으로 따로 확인한다.
파일 전송·관리 콘솔 서버는 인터넷에 직접 열지 않는다. 열어야 한다면 WAF(웹 공격을 걸러 주는 방화벽)와 IP 제한을 함께 쓴다.
전송·처리가 끝난 파일에 보관 기한을 정하고 자동으로 지운다. 없는 데이터는 유출되지 않는다.
웹 루트의 파일 변경과 새 계정 생성에 알림을 건다.
우리 고객 데이터를 어느 협력사가 어떤 제품으로 다루는지 목록을 만들고, 그 제품의 취약점 공지를 받는다.

제재와 비용

SEC(2024-08): 프로그레스에 대한 조사를 종결했고, 조치를 권고하지 않았습니다.
집단소송: 매사추세츠 연방법원에서 여러 소송을 묶은 MDL(광역 병합 소송)이 진행 중입니다. 프로그레스의 2026 회계연도 분기 보고서(10-Q) 기준으로 33개 청구 중 일부가 기각됐고, 클래스 인증 단계에 있습니다. 회사는 12개월 안에 끝나지 않을 것으로 공시했습니다.
충당금: 프로그레스는 2025년 11월 기준 손실 충당금을 쌓지 않았습니다.
별도 합의: 마이크로소프트 자회사 뉘앙스(Nuance)가 850만 달러(약 119억 원, 1달러 1,400원 기준)에 별도로 합의했습니다.
회사 대책: 긴급 패치와 추가 취약점 수정에 이어 정기 서비스 팩 체계를 도입했습니다 [보도].

2026년 10월 말 기준 집단소송은 진행 중이라 결과는 바뀔 수 있습니다. 위 내용은 공개 보고서·발표를 정리한 것이며 법률 자문이 아닙니다.

정리

파일 전송 서버 MOVEit Transfer의 SQL 인젝션 제로데이로 2,773개 조직, 약 9,580만 명의 데이터가 빠져나갔습니다(Emsisoft 집계).
공격은 패치가 나오기 나흘 전에 시작됐고, 인터넷에 열린 서버와 오래 쌓인 파일이 피해를 키웠습니다.
오래된 취약점 유형도 인터넷에 노출된 서버에 있으면 대량 피해로 번집니다. 밖으로 열린 서버일수록 기본 코딩 규칙과 데이터 보관 기한을 더 엄격히 지켜야 합니다.

더 깊게

인프런 「백엔드 개발자를 위한 서버 보안 실무」 수업

2-3 SQL·NoSQL 인젝션: 공격 재현부터 파라미터 바인딩까지
0-4 공격자처럼 생각하기: 위협 모델링과 공격 표면 지도
6-3 보안 테스트 자동화: SAST·SCA·DAST를 CI에 붙이기
7-1 보안 정보원 구독하기: KISA, CVE, KEV, EPSS
7-2 악용 중인 취약점 공지를 받고 72시간 안에 반영하는 워크플로

관련 velog 글

롯데카드 297만 명: 8년 된 취약점과 잊혀진 결제 서버: 패치가 있었는데 적용하지 않은 경우
Salesloft Drift: 연동 토큰 하나로 700곳의 Salesforce가 열렸다(04편): 서드파티를 거쳐 들어온 또 다른 사고

보안을 더 알고 싶다면

오늘 본 사고의 원인은 대부분 서버와 코드의 기본기에서 막을 수 있는 것들이었습니다. 직접 손으로 막아 보고 싶다면 이런 강의도 있습니다.

백엔드 개발자를 위한 서버 보안 실무: 해킹 방어부터 정보유출 방지까지

서버를 공격하는 흐름을 로그로 보고, 내 서버와 Spring·Express 코드에서 직접 막아 봅니다.
SSH 하드닝, 인젝션, 인증·인가, 시크릿과 개인정보 보호, 침해사고 첫 한 시간까지 8개 섹션 54개 수업입니다.
이 글과 이어지는 수업: 2-3 SQL·NoSQL 인젝션: 공격 재현부터 파라미터 바인딩까지 · 0-4 공격자처럼 생각하기: 위협 모델링과 공격 표면 지도 · 7-2 악용 중인 취약점 공지를 받고 72시간 안에 반영하는 워크플로