서버가 남이 보낸 객체를 의심 없이 '되살릴' 때 — SharePoint 역직렬화 결함 CVE-2026-58644를 방어자 손에서 읽는 법

이미지 출처: CISA KEV

웹 애플리케이션은 생각보다 많은 것을 객체로 저장했다가 다시 꺼내 쓴다. 세션 상태, 뷰의 구성 값, 컨트롤의 속성 같은 것들을 문자열이나 바이트 뭉치로 납작하게 눌러 두었다가(직렬화), 요청이 들어오면 그걸 원래 형태의 객체로 부풀려 되살린다(역직렬화). 여기서 조용히 어긋나는 전제가 하나 있음. "되살릴 데이터는 우리가 만든 것"이라는 믿음. CVE-2026-58644는 바로 그 믿음이 깨지는 지점, 즉 Microsoft SharePoint가 신뢰할 수 없는 데이터를 역직렬화하는 경로에서 생긴 문제임.

핵심 요약

• SharePoint가 외부에서 온 직렬화 데이터를 검증 없이 되살리는 과정에서 발생한 역직렬화 취약점으로, 성공 시 서버 측 코드 실행으로 이어질 수 있음.
• 온프레미스 SharePoint Server 운영 환경이 특히 신경 쓸 대상이며, 핵심 방어는 '패치 + 노출면 축소 + 요청 로그 관찰'의 조합임.
• 공격 재현보다 탐지·완화 관점이 실전에 더 유용하므로, 페이로드가 아니라 '어떤 요청이 이상한가'를 보는 눈을 먼저 기르는 게 낫다고 봄.

역직렬화가 왜 그렇게 위험한가

역직렬화 취약점을 처음 접하면 "데이터를 다시 객체로 만드는 게 뭐가 그렇게 위험하냐"고 갸웃하게 됨. 핵심은 객체를 복원하는 과정 자체가 코드를 부른다는 데 있음. 특정 타입의 객체는 되살아나는 순간 생성자, 속성 설정자, 정리 로직 같은 메서드가 자동으로 실행됨. 공격자가 "복원되면 원하는 동작을 트리거하는" 객체 사슬(가젯 체인)을 정교하게 조립해 보내면, 서버는 그걸 데이터로만 여기고 순순히 되살리다가 남의 의도대로 움직이게 됨.

• 입력은 평범한 데이터처럼 보이는 문자열·바이트여서 단순 필터로 걸러내기 어려움.
• 실행 지점이 애플리케이션 깊숙한 라이브러리 내부라 개발자 코드에는 흔적이 잘 안 남음.
• 인증·권한 검사 전에 데이터가 파싱되면, 로그인 없이도 트리거되는 경우가 생김.

CVE-2026-58644에서 문제가 된 흐름

이 건은 SharePoint가 사용자·클라이언트로부터 받은 직렬화 형태의 값을 충분히 검증하지 않고 역직렬화하는 경로에서 비롯됨. SharePoint는 컨트롤 상태나 요청 파라미터를 직렬화된 형태로 주고받는 지점이 많은데, 그중 신뢰 경계를 넘어온 값이 안전한 타입인지 확인하는 절차가 헐겁게 뚫려 있으면, 되살리는 순간이 곧 공격 표면이 됨. 결과적으로 성공한 공격자는 서버 컨텍스트에서 코드를 실행하는 발판을 얻을 수 있고, 이는 온프레미스 문서 협업 서버라는 자산의 성격상 파장이 큼.

구체적 버전 표기나 점수는 배포 채널마다 갱신되니 벤더 고지를 기준으로 확인하는 게 맞음. 다만 방어자 입장에서 외워둘 한 줄은 이것임 — "외부에서 온 직렬화 데이터를 되살리는 곳은 전부 잠재적 실행 지점이다."

공격자는 어떤 순서로 접근하나 (개념 수준)

실제 페이로드는 다루지 않되, 방어를 설계하려면 상대의 큰 그림은 알아야 함. 대체로 이런 단계를 밟음.

• 노출 확인: 인터넷에 열린 SharePoint 엔드포인트와 버전 흔적을 수집함.
• 진입점 탐색: 직렬화된 값을 받는 파라미터·헤더·폼 필드를 찾음.
• 객체 사슬 주입: 되살아날 때 특정 동작을 부르는 형태의 데이터를 실어 보냄.
• 실행 확인·확장: 짧은 신호(예: 지연·외부 통신)로 성공 여부를 재고, 그다음 지속성·측면 이동으로 넘어감.

방어자가 볼 신호는 마지막 단계가 아니라 두 번째·세 번째 단계의 흔적임. 완성된 침해를 보고 막는 건 늦고, 이상한 직렬화 입력이 오가는 순간을 보는 게 빠름.

방어자 관점의 탐지 포인트

• 요청 본문·파라미터의 비정상 패턴: 인코딩된 대형 직렬화 blob, 예상보다 긴 상태 값, 흔치 않은 타입 이름이 담긴 요청을 WAF·프록시 로그에서 관찰함.
• 서버 프로세스의 이상 자식 프로세스: IIS/SharePoint 워커 프로세스가 갑자기 셸이나 스크립트 인터프리터를 띄우는지 EDR로 감시함. 역직렬화 RCE의 전형적 후속 신호임.
• 예상 밖 아웃바운드 통신: 문서 서버가 낯선 목적지로 나가는 연결을 만드는지 봄. 성공 확인용 콜백일 수 있음.
• 인증 이전 단계의 오류·예외 급증: 파싱 실패 로그가 특정 엔드포인트에 몰리면 탐색 시도의 흔적일 수 있음.

완화·대응 체크리스트

• 패치가 1순위: 벤더 보안 업데이트를 최우선으로 적용함. 역직렬화 결함은 우회가 어려운 근본 수정이 대개 코드 레벨에 있어, 임시 방어만으로 안심하기 어려움.
• 노출면 줄이기: 온프레미스 SharePoint를 굳이 인터넷에 직접 열어둘 필요가 없다면 VPN·리버스 프록시·IP 제한 뒤로 넣음.
• 입력 검증·모니터링 강화: WAF 룰로 알려진 역직렬화 패턴을 차단하고, 위 탐지 포인트를 알림으로 연결함. 완벽 차단보다 '빨리 알아채기'가 현실적 목표임.
• 최소 권한: SharePoint 서비스 계정 권한을 조이고, 측면 이동을 늦추도록 네트워크 분할을 확인함.
• 사후 대비: 침해 가정하에 로그 보존 기간과 백업 복구 절차를 미리 점검함. 터진 뒤에 로그가 없으면 조사 자체가 막힘.

역직렬화 취약점은 매년 이름만 바꿔 다시 찾아오는 단골 유형인데, 그만큼 방어 원칙도 크게 안 변함. "신뢰 경계를 넘어온 데이터는 코드로 취급하라"는 문장 하나만 몸에 배어 있어도 새 CVE 번호를 만날 때마다 덜 당황하게 됨. 개인적으로는 이번 건을 계기로 자기 조직의 SharePoint가 외부에 어떻게 노출돼 있는지, 워커 프로세스의 자식 프로세스를 실제로 보고 있는지부터 점검해 보길 권함. 이미 적용해 둔 탐지 룰이나 겪은 오탐이 있다면 댓글로 공유해 주시면 같이 다듬어 봐요.