Fastjson 1.x RCE, 패치가 아니라 이관이 답인 이유

이미지 출처: The Hacker News

사내 자산 목록을 훑다가 fastjson 1.2.x 문자열을 발견하는 순간이 있다. 몇 년 전에 만든 정산 API, 아무도 손대지 않아서 잘 돌아가던 그 모듈이다. 이번에 문제가 된 Fastjson 1.x 역직렬화 RCE는 정확히 그런 코드를 노린다. 그리고 이 취약점의 진짜 곤란한 지점은 심각도가 아니라, 올려 붙일 패치 버전이 존재하지 않는다는 것이다.

핵심 요약

• Fastjson 1.x의 autoType 계열 역직렬화 결함이 실제 공격에 쓰이고 있으나, 1.x 라인은 이미 수명이 끝나 보안 패치가 제공되지 않음
• 당장의 대응은 safeMode 강제, JNDI 원격 코드베이스 차단, 아웃바운드 이그레스 통제 세 가지가 핵심
• 탐지는 요청 본문의 타입 지정 키와 자바 프로세스의 자식 프로세스·외부 LDAP/RMI 연결을 함께 보는 방식이 가장 정확함

무슨 일이 벌어지고 있나

Fastjson은 국내외 자바 프로젝트에서 오래 쓰인 JSON 라이브러리인데, 문제는 편의 기능으로 넣어둔 autoType에서 시작함. JSON 안에 "이 데이터를 어떤 클래스로 만들어라"는 타입 정보를 담을 수 있게 한 기능임. 서버는 그 지시대로 클래스를 찾아 인스턴스를 만들고 setter를 호출함.

• 공격자는 데이터가 아니라 어떤 클래스를 만들지를 조종함
• 인스턴스화 과정에서 외부 자원을 조회하는 클래스를 고르면, 역직렬화가 곧 원격 조회가 됨
• 그 조회 결과가 코드로 실행되는 순간 인증 없는 RCE가 성립함

과거 여러 차례 블랙리스트로 막고, 우회 클래스가 발견되고, 다시 막는 공방이 반복됐음. 이번 건도 그 연장선에서 기존 차단 목록을 비껴가는 경로가 다시 발견된 형태임. 개념 수준에서만 짚자면 "타입을 지정할 수 있다"는 설계 자체가 뿌리이고, 개별 클래스를 아무리 지워도 근본은 남음.

왜 이번엔 패치를 기다릴 수 없나

Fastjson 1.x는 이미 유지보수 종료 선언이 난 라인임. 개발 측은 새로 설계한 2.x로 옮기라는 입장이고, 1.x에는 더 이상 보안 수정이 올라오지 않음. 즉 버전 올리기로 끝나는 문제가 아님. 라이브러리를 바꾸거나, 바꿀 때까지 기능을 강제로 잠가두는 것 말고 선택지가 없음.

이게 방어자 입장에서 꽤 성가신 이유는, 취약한 코드가 대개 오래된 모듈에 박혀 있어서 담당자가 퇴사했거나 테스트 코드가 없는 경우가 많기 때문임. "잘 돌아가니까 그냥 두자"가 통하던 영역에 갑자기 마감 시한이 생긴 셈.

1단계: 우리 환경에 있는지부터 확정하기

• 빌드 도구로 의존성 트리를 전부 뽑아보기. 직접 선언하지 않아도 다른 라이브러리가 끌고 온 전이 의존성으로 들어와 있는 경우가 흔함
• 운영 서버의 배포 산출물에서 fastjson 계열 JAR 파일명을 직접 검색. 빌드 스크립트와 실제 배포물이 다른 경우가 생각보다 많음
• SBOM을 관리 중이라면 컴포넌트 목록에서 버전대까지 확인하고, 없다면 이번 기회에 한 번 만들어두길 개인적으로는 추천함
• 컨테이너 이미지 레이어 안에 들어간 것도 스캔 대상에 포함. 이미지 캐시에 옛날 JAR이 남아 있는 사례가 많음

2단계: 완화 — 당장 할 것과 결국 할 것

지금 바로 적용할 수 있는 것들부터 정리함.

• safeMode 강제: 1.x 후기 버전에는 autoType을 전면 차단하는 안전 모드가 있음. 블랙리스트 방식과 달리 타입 지정 자체를 무시하므로 우회 공방에서 벗어남. 다만 @type 표기에 의존하던 기능이 있다면 깨질 수 있으니 스테이징에서 회귀 테스트 먼저
• JNDI 원격 코드베이스 신뢰 해제: 원격에서 받아온 객체를 코드로 신뢰하지 않도록 JVM 옵션을 명시적으로 끄기. 최신 JDK는 기본 차단이지만 오래된 런타임을 쓰는 환경이라면 반드시 확인
• 아웃바운드 이그레스 통제: 애플리케이션 서버가 임의의 외부 주소로 LDAP·RMI·HTTP를 나가지 못하게 막기. 이 계열 공격은 대부분 외부 조회 한 번을 반드시 거치므로, 나가는 길만 끊어도 체인이 끊김
• 입력 경계 좁히기: 외부에서 들어온 JSON을 그대로 역직렬화하는 엔드포인트가 인증 없이 열려 있는지 점검. 특히 웹훅 수신, 콜백, 배치 연동 API가 사각지대

그리고 결국 해야 할 것은 하나임. Fastjson 2로 이관하거나 Jackson·Gson 같은 대체로 옮기는 것. 위 완화책들은 이관까지 버티는 시간을 벌어주는 장치이지 종착점이 아님.

3단계: 탐지 — 어디를 보면 걸리나

단일 지표만 보면 오탐이 많아서, 요청 계층과 호스트 계층을 겹쳐 보는 게 좋음.

• 요청 본문: JSON 본문에 클래스 타입을 지정하는 키가 등장하는 요청을 WAF나 프록시 로그에서 별도 태깅. 정상 트래픽에 이런 키가 거의 없는 서비스라면 그 자체로 강한 신호임
• 프로세스 계보: 자바 프로세스가 셸이나 명령 해석기를 자식으로 생성하는 이벤트. 역직렬화 공격의 사후 단계에서 가장 선명하게 남는 흔적이라 EDR 룰로 잡기 좋음
• 네트워크: 애플리케이션 서버에서 나가는 LDAP·RMI 계열 연결, 그리고 평소 통신 이력이 없던 외부 IP로의 신규 아웃바운드 세션
• 파일 생성: 임시 디렉터리나 웹 루트에 클래스·JAR 파일이 새로 떨어지는 경우
• 응답 코드 패턴: 같은 엔드포인트에 형식 오류 응답이 짧은 시간에 반복되다가 어느 순간 정상 응답으로 바뀌는 흐름. 우회 클래스를 갈아 끼우며 시도하는 정황일 수 있음

탐지 룰을 만들 때는 정상 트래픽 기준선을 먼저 며칠 쌓아두는 편이 낫다고 봄. 기준선 없이 룰부터 올리면 알람에 지쳐서 결국 꺼버리게 되더라.

정리하며

이번 사안이 주는 교훈은 취약점 자체보다 "패치가 나오지 않는 상황"에 대한 대비에 가깝다고 생각함. 우리가 쓰는 라이브러리 중에 이미 수명이 끝났는데 아직 운영에 남아 있는 것이 무엇인지, 목록으로 답할 수 있는 조직은 의외로 적음. 이번 주말에 의존성 트리 한 번 뽑아보고 EOL 표시가 붙은 것들만 따로 모아두면, 다음에 비슷한 소식이 왔을 때 대응 시간이 확연히 줄어들 거예요.

혹시 safeMode를 켰다가 깨진 기능을 어떻게 우회했는지, 이관 과정에서 걸린 부분이 있다면 댓글로 공유해 주세요. 저도 정리해서 다음 글에 반영해 보겠습니다. 같이 안전하게 버텨봐요.