인증을 묻지 않는 PeopleSoft, 무엇을 어떻게 막을까

이미지 출처: 재시도

기업 인사·급여 시스템의 뒤편에는 생각보다 오래된 코드가 돌고 있음. Oracle PeopleSoft Enterprise는 대학, 공공기관, 대기업의 인사관리(HCM)와 재무 업무를 떠받치는 플랫폼이고, 그 토대가 되는 미들웨어가 바로 PeopleTools임. 이번에 공개된 CVE-2026-35273은 그 PeopleTools에서 중요 기능에 대한 인증 누락(Missing Authentication for Critical Function) 유형으로 분류된 취약점임. 쉽게 말해, 원래라면 로그인을 거쳐야 닿을 수 있는 어떤 기능이 인증 절차를 건너뛴 채 노출될 수 있다는 뜻임.

핵심 요약

• CVE-2026-35273은 Oracle PeopleSoft PeopleTools의 '중요 기능 인증 누락' 취약점으로, 인증되지 않은 접근이 핵심임.
• 위험의 본질은 코드 한 줄이 아니라 '관리·점검용 엔드포인트가 외부에 노출된 구조'에 있음.
• 방어는 패치 적용을 기본으로, 노출면 축소·접근통제·로그 기반 탐지를 함께 묶어야 함.

'인증 누락'이라는 결함이 실제로 의미하는 것

인증 누락 취약점은 화려한 메모리 손상 버그처럼 보이지 않음. 오히려 너무 단순해서 무서운 쪽임. 개발자가 어떤 기능을 만들면서 "이건 내부에서만 호출되니까"라고 가정하고 인증 검사를 빼두면, 그 가정이 깨지는 순간 누구나 그 기능을 부를 수 있게 됨. PeopleTools처럼 서블릿·서비스 엔드포인트가 많은 거대한 웹 미들웨어에서는 이런 '점검용', '진단용', '상태 조회용' 경로가 의외로 많고, 그중 하나라도 인증 게이트 밖에 놓이면 공격자는 비밀번호를 추측할 필요조차 없음.

이 취약점이 위험한 이유는 전제 조건이 거의 없다는 점임. 사용자 계정도, 사회공학도, 복잡한 익스플로잇 체인도 필요 없이 네트워크에서 해당 엔드포인트에 도달할 수만 있으면 됨. 그래서 인터넷에 직접 노출된 PeopleSoft 포털일수록 위험도가 급격히 올라감. 개인적으로는 이런 부류의 취약점을 만날 때마다, 패치보다 먼저 "이게 대체 왜 인터넷에서 보이지?"를 묻는 습관을 권하고 싶음.

방어자 관점에서 먼저 할 일: 노출면 파악

공격 재현을 고민하기 전에, 내가 지킬 자산이 어디까지 노출돼 있는지를 그리는 게 우선임. 순서를 정리하면 이렇게 됨.

• 자산 식별: 조직 내 PeopleSoft/PeopleTools 인스턴스를 전수 조사함. WebLogic 위에 올라간 PIA(PeopleSoft Internet Architecture) 포털, 관리 콘솔, 통합 게이트웨이까지 포함해야 누락이 없음.
• 외부 노출 점검: 해당 포털이 인터넷에서 직접 접근 가능한지 확인함. 검색엔진이나 자산 인벤토리로 외부 표면을 먼저 보고, 불필요하게 열린 경로는 즉시 줄임.
• 버전·패치 수준 확인: 운영 중인 PeopleTools 릴리스와 적용된 Critical Patch Update 수준을 대조함. Oracle은 분기별 CPU로 이런 결함을 묶어 배포하므로, 패치 적용 이력이 곧 방어 상태표가 됨.

탐지: 무엇을 로그에서 찾아야 하나

인증 누락 계열은 '비정상 로그인'이 아니라 '로그인 자체가 없는 정상 응답'으로 보이기 때문에 탐지가 까다로움. 그래서 인증 성공/실패 로그만 보면 놓치기 쉽고, 웹 계층의 접근 로그를 함께 봐야 함. 점검 포인트를 정리하면 다음과 같음.

• 인증 세션 없이 관리·진단성 경로에 200 응답이 돌아간 요청 패턴.
• 로그인 흐름을 거치지 않은 단일 클라이언트가 짧은 시간에 여러 내부 엔드포인트를 훑는 열거(enumeration) 흔적.
• 평소 트래픽이 거의 없던 서블릿 경로에 갑자기 발생한 외부 IP의 접근.
• WebLogic·WAF·리버스 프록시 로그의 상호 대조 — 한쪽에만 남는 요청이 곧 우회 신호일 수 있음.

여기서 핵심은 개별 페이로드를 잡으려 하기보다, '인증 경계를 통과하지 않은 접근'이라는 행동 자체를 룰로 만드는 것임. 시그니처는 변형에 약하지만, 인증 상태와 접근 경로를 엮은 룰은 훨씬 오래 버팀.

완화: 패치를 중심에 두되, 한 겹으로 끝내지 말 것

가장 확실한 조치는 당연히 Oracle이 배포하는 Critical Patch Update를 적용하는 것임. 다만 인사·재무 시스템은 정지 시간을 잡기 어려운 경우가 많아 패치까지 시차가 생기기 마련임. 그 틈을 메우는 보완 통제를 같이 깔아두길 권함.

• 네트워크 분리: 관리·통합 엔드포인트는 인터넷에서 떼어내고, VPN이나 내부망 뒤로 옮김. '필요 없는 노출을 없애는 것'이 단일 취약점 한 개를 막는 것보다 효과가 큼.
• 리버스 프록시·WAF에서 경로 차단: 외부 사용자에게 필요 없는 진단·관리 경로는 게이트웨이 단에서 막아 임시 가상 패치로 활용함.
• 최소 권한·세그먼테이션: 설령 한 기능이 뚫려도 데이터베이스나 인접 서버로 번지지 않도록 권한과 망을 잘게 나눔.
• 변경 후 검증: 패치·차단을 적용한 뒤에는 같은 경로가 정말 인증을 요구하는지 직접 확인함. 조치했다는 믿음과 실제로 막혔다는 증거는 다른 이야기임.

마무리

CVE-2026-35273은 기술적으로 화려하지 않지만, 그래서 더 현실적인 위협임. 결국 우리가 배워야 할 교훈은 단순함. "이 기능은 내부에서만 쓰니까 괜찮다"는 가정은 언젠가 깨진다는 것, 그리고 인증 경계는 코드뿐 아니라 네트워크·프록시·로그까지 여러 겹으로 지켜야 한다는 것임. 운영 중인 PeopleSoft가 있다면 오늘 당장 외부 노출 여부부터 한번 확인해보길 권함. 점검하다 막히거나 흥미로운 로그 패턴을 발견하면 댓글로 같이 이야기 나눠봐요.