TL;DR — 클라이언트가 자기 코드의 해시를 manifest와 대조하는 방식은, 공격자가 코드와 manifest를 함께 고치면 그대로 통과한다. 검사 주체와 검사 대상이 같은 쪽에 있기 때문이다. 최종 대조 기준을 서버가 들고 있게 바꿔, 로컬 검사를 통과해도 서버에서 걸리게 했다.

배경

• 프로젝트/기능: KC License Server — 게이트웨이에 배포되는 클라이언트의 코드 변조 탐지
• 환경: Java 21, Spring Boot 3.x, MySQL 8
• 전제: 장비가 현장에 있어 공격자가 클라이언트 파일을 자유롭게 읽고 고칠 수 있다

문제 (증상)

• 클라이언트가 실행 전에 자기 파일들의 해시를 계산해 manifest.json과 대조하는 로컬 무결성 검사를 두었다
• 그런데 공격자가 코드를 고치고 manifest의 해시도 같이 고치면 검사는 정상 통과한다
• 검사 로직 자체를 들어내는 것도 가능하다 — 검사하는 쪽과 검사받는 쪽이 모두 공격자 손에 있다

원인 분석

• 로컬 무결성 검사는 실수로 깨진 파일은 잡지만 의도적 변조는 잡지 못한다. 기준값이 공격자가 닿을 수 있는 곳에 있기 때문이다
• 대조 기준을 공격자가 바꿀 수 없는 곳 — 즉 서버 — 에 두지 않으면 이 계열의 공격은 원천적으로 막히지 않는다

해결

로컬 검사를 남겨 두되(실수로 깨진 배포본은 여기서 걸린다), 최종 판정은 서버가 한다.

• manifest를 정규화해 단일 해시(file_hash)로 만들고, 서버가 알고 있는 기대값과 대조
• 정규화 규칙을 명세로 고정 — 경로 정렬 순서, 널 구분자, 필드 순서가 하나라도 어긋나면 다른 값이 된다
• 이 규칙을 KAT 벡터 6종으로 박아두고, 그중 일부는 정렬·구분자·필드 순서를 일부러 어긋뜨린 negative 케이스로 넣었다 — 규칙이 느슨해지면 테스트가 먼저 깨진다
• 결과적으로 방어선이 둘이 된다: 로컬 검사(사고 탐지) → 서버 대조(변조 탐지)

결과

• 코드와 manifest를 함께 고쳐도 서버 대조에서 걸린다 — 공격자가 바꿀 수 없는 기준이 생겼다