JSON 한 조각에 타입 이름이 붙어 있을 때 — Ajax.NET Professional이 놓친 경계선

이미지 출처: CISA KEV

웹 애플리케이션에서 브라우저가 서버로 보내는 값은 기본적으로 "데이터"여야 함. 그런데 그 데이터 안에 "이걸 어떤 클래스로 만들어라"라는 지시가 섞여 들어갈 수 있다면, 그 순간부터 그건 데이터가 아니라 명령이 됨. CVE-2021-23758은 바로 그 경계선이 흐려졌을 때 무슨 일이 벌어지는지 보여주는 사례임.

핵심 요약

• Ajax.NET Professional(AjaxPro)이 클라이언트가 보낸 JSON을 신뢰하지 않는 상태로 역직렬화하면서, 공격자가 지정한 타입까지 만들어지는 문제임.
• 핵심 위험은 원격 코드 실행으로, 인증이 필요 없는 AjaxPro 엔드포인트가 외부에 열려 있으면 위험도가 급격히 올라감.
• 방어는 세 가지 — 최신 버전 반영, AjaxPro 핸들러 경로 노출 통제, 그리고 요청 본문에 타입 지시자가 섞여 들어오는지 탐지하는 것.

AjaxPro가 하던 일

Ajax.NET Professional은 꽤 오래된 .NET 라이브러리임. AJAX라는 말이 유행하던 시절, 브라우저 자바스크립트에서 서버의 C# 메서드를 거의 직접 호출하는 것처럼 쓰게 해주는 게 목적이었음. 개발자는 메서드에 특성(attribute) 하나만 붙이면 되고, 나머지 배관 작업 — 요청을 받아서 파라미터를 파싱하고 실제 메서드에 넘겨주는 일 — 은 라이브러리가 알아서 해줬음.

편의성 자체는 훌륭했음. 문제는 그 "파라미터를 파싱하는" 단계에 있었음. C# 메서드의 인자는 문자열이나 숫자만 있는 게 아니라 임의의 객체일 수도 있음. 그래서 라이브러리는 들어온 JSON을 적당한 .NET 객체로 되살려내는 기능을 갖고 있어야 했고, 이때 어떤 타입으로 되살릴지를 요청 쪽 정보로 판단하는 구조가 만들어졌음. 여기서 신뢰 경계가 무너짐.

역직렬화가 위험해지는 지점

역직렬화 자체는 죄가 없음. 위험한 건 "바이트 뭉치를 객체로 되돌리는 과정에서 코드가 실행된다"는 특성임. .NET이든 자바든 파이썬이든, 객체를 복원할 때는 생성자·세터·콜백 같은 것들이 자동으로 돌아감. 공격자가 복원될 타입을 고를 수 있게 되면, 이야기는 이렇게 흘러감.

• 애플리케이션이 로드한 모든 어셈블리에서 "복원되는 순간 뭔가를 실행하는" 클래스를 뒤짐. 이런 걸 가젯(gadget)이라 부름.
• 그 가젯의 프로퍼티를 원하는 값으로 채운 JSON을 만들어 보냄.
• 서버가 그 JSON을 객체로 되살리는 순간, 개발자가 의도한 적 없는 코드 경로가 발동됨.

개념적으로만 짚자면 이게 전부임. 실제 가젯 체인은 프레임워크 버전과 로드된 어셈블리 구성에 따라 달라지므로 여기선 다루지 않음. 중요한 건 "공격자가 타입을 지정할 수 있는가"라는 질문 하나가 취약/안전을 가른다는 사실임.

내 환경에 이게 있는지부터

이 취약점이 까다로운 이유는 AjaxPro가 요즘 새로 도입되는 라이브러리가 아니라는 데 있음. 오래된 사내 시스템, 인수합병으로 넘어온 레거시 포털, 몇 년째 아무도 손대지 않는 관리자 화면 같은 곳에 조용히 박혀 있을 확률이 높음. 그래서 점검 순서는 이렇게 잡는 게 현실적임.

• 파일 흔적: 배포 디렉터리에서 AjaxPro 관련 DLL이 있는지 확인. bin 폴더를 뒤지는 게 가장 빠름.
• 설정 흔적: web.config의 httpHandlers 또는 handlers 섹션에 ajaxpro 경로가 등록되어 있는지 확인. 등록돼 있다면 그 경로가 곧 공격 표면임.
• 트래픽 흔적: 웹 서버 액세스 로그에서 /ajaxpro/ 형태의 경로가 찍히는지 검색. 개발자도 잊은 기능이 로그에는 남아 있는 경우가 많음.
• 참조 흔적: 소스가 있다면 프로젝트 파일과 패키지 목록에서 참조를 확인. 직접 넣은 게 아니라 다른 컴포넌트가 끌고 들어온 경우도 있음.

개인적으로는 세 번째 항목을 제일 먼저 해보는 걸 추천함. 자산 목록이 부정확한 조직일수록, 사람 기억보다 로그가 정직하기 때문임.

탐지 규칙을 어디에 걸 것인가

이 부류의 취약점은 "요청 본문 안에 타입 이름이 섞여 있다"는 아주 특징적인 신호를 남김. 정상적인 애플리케이션 데이터에는 .NET 타입의 정규화된 이름이나 어셈블리 정보가 들어갈 이유가 거의 없음. 그래서 탐지는 다음 축으로 세우면 됨.

• 본문 패턴: POST 본문에 __type, $type 같은 타입 지시 키나 System.으로 시작하는 정규화 타입 문자열, Assembly·Culture=·PublicKeyToken= 같은 어셈블리 식별 문자열이 섞여 들어오는 경우.
• 경로 결합: 위 패턴이 AjaxPro 핸들러 경로로 향하는 요청에서 발생하면 우선순위를 크게 올림. 경로와 본문을 함께 보는 게 오탐을 줄이는 핵심임.
• 후행 행위: w3wp.exe 같은 IIS 워커 프로세스가 cmd.exe나 powershell.exe를 자식으로 띄우는 순간. 역직렬화 공격의 성공 여부는 사실 이 지점에서 가장 확실하게 드러남.
• 나가는 연결: 웹 서버가 갑자기 외부로 아웃바운드 연결을 시도하는 패턴. 페이로드 다운로드나 리버스 셸의 전형적인 모습임.

앞의 두 축은 앞단(WAF·프록시)에서, 뒤의 두 축은 뒷단(EDR·프로세스 로그)에서 봐야 함. 한쪽만 걸어두면 우회 한 번에 그대로 뚫림.

실제로 막는 순서

순서를 정할 때는 "제일 빨리 위험을 떨어뜨리는 것"부터 가는 게 맞음.

• 1. 노출 차단: AjaxPro 핸들러 경로를 인터넷에서 접근 못 하게 막음. 내부 업무용 기능이라면 애초에 외부에 열려 있을 이유가 없음. 패치보다 이게 먼저 되는 경우가 많음.
• 2. 버전 정리: 이 문제를 해결한 릴리스로 올림. 라이브러리 교체가 곧바로 어렵다면 최소한 어떤 버전이 어디에 깔려 있는지 목록부터 만들어 둠.
• 3. 제거 검토: 솔직히 가장 확실한 해법임. AjaxPro가 담당하던 기능이 요즘 기준으로 보면 일반적인 REST 엔드포인트 몇 개로 대체 가능한 경우가 대부분이고, 그렇게 바꾸면 이 취약점 계열 전체가 사라짐.
• 4. 권한 축소: 애플리케이션 풀 계정 권한을 최소화. 코드 실행이 일어나더라도 그 다음 단계로 못 가게 막는 층임.
• 5. 로그 보존: 이미 당했는지 확인하려면 과거 로그가 필요함. 조치하기 전에 액세스 로그와 프로세스 로그 보존 기간부터 확인해두는 걸 권함.

이 사건이 남기는 것

역직렬화 취약점은 새로운 게 아님. 그런데도 계속 나오는 이유는, 개발할 때 "받은 데이터를 그대로 객체로 만들어주면 편하다"는 유혹이 워낙 강하기 때문인 것 같음. 편의 기능이 하나 늘어날 때마다 신뢰 경계가 한 칸씩 안쪽으로 밀려 들어오는데, 그게 밀려 들어온 자리에 코드 실행이 놓여 있으면 사고가 됨.

그래서 방어자 입장에서 기억할 원칙은 단순함. 입력이 타입을 고르게 하지 말 것. 서버가 기대하는 타입을 서버가 먼저 정해놓고, 들어온 데이터를 그 틀에 맞춰 검증하며 채우는 방향이어야 함. 요즘 라이브러리들이 타입 정보 포함 역직렬화를 기본으로 끄고, 켜려면 명시적으로 허용 목록을 요구하는 것도 같은 이유임.

혹시 사내에 AjaxPro가 남아 있는 걸 발견했다면, 그건 나쁜 소식이 아니라 좋은 소식이라고 생각함. 모르는 것보다 아는 게 언제나 나으니까. 오늘 bin 폴더 한 번, web.config 한 번만 열어보아요. 비슷한 레거시 라이브러리 정리하다 겪은 이야기 있으면 댓글로 나눠주면 좋겠습니다!