결재선 밖에서 결재가 승인됐다 — Oracle EBS 권한 관리 결함(CVE-2026-46817)을 방어자 눈으로 뜯어보기

이미지 출처: CISA KEV

ERP는 회사에서 가장 지루하면서 가장 무서운 시스템임. 지루한 이유는 화면이 90년대에서 멈춰 있어서고, 무서운 이유는 그 안에 급여·거래처 계좌·발주 승인이 전부 들어 있어서임. 그런 Oracle E-Business Suite에서 권한 관리(Improper Privilege Management) 문제로 분류된 CVE-2026-46817이 올라왔음. 코드 실행도, 메모리 손상도 아님. 그냥 "하면 안 되는 사람이 할 수 있었다"는 유형임. 그래서 더 조용하고, 그래서 더 오래 안 들킴.

핵심 요약

• CVE-2026-46817은 Oracle E-Business Suite의 부적절한 권한 관리 결함으로, 인가 경계 밖의 기능·데이터에 손이 닿는 유형임
• 익스플로잇 코드가 없어도 위험함 — 정상 로그인·정상 HTTP 요청처럼 보이기 때문에 WAF·IDS 시그니처로는 거의 안 걸림
• 방어의 축은 세 개: Oracle 분기 패치 적용, EBS를 인터넷에서 떼어내기, 그리고 권한 변경·민감 폼 접근 로그를 사람이 읽는 형태로 만들기

1. Improper Privilege Management가 뭔지부터

CWE로 치면 269 계열임. 쉽게 말하면 "권한을 주고, 뺏고, 확인하는 로직이 어긋난 상태"임. 몇 가지 얼굴로 나타남.

• 낮은 권한 계정이 높은 권한 기능의 엔드포인트를 직접 호출할 때, 화면에는 메뉴가 안 보이는데 서버가 요청은 받아줌
• 책임(Responsibility)이나 역할을 바꾸는 과정에서 이전 권한이 세션에 남아 있음
• 내부 서비스 계정이 필요 이상으로 강한 권한을 들고 다니다가, 그 계정을 경유하면 검증이 통째로 생략됨

공통점은 하나임. "UI가 곧 접근제어"라고 착각한 지점에서 터짐.

메뉴를 숨기는 건 접근제어가 아니고 그냥 인테리어임. 진짜 검사는 서버가 요청을 받은 그 순간에 "이 세션이 이 오브젝트에 이 동작을 할 권리가 있나"를 물어보는 데서 이뤄져야 함. 그 물음이 빠지거나, 한 번만 묻고 이후엔 캐시된 답을 믿는 순간이 이 CVE 계열의 서식지임.

2. EBS라서 더 아픈 이유

Oracle EBS는 구조가 좀 특이함. Responsibility라는 개념으로 사용자에게 기능 묶음을 붙이고, 그 아래 Function·Menu·Data Group이 층층이 얹힘. 여기에 커스터마이징 20년치가 쌓여 있음. 그래서 이런 일이 벌어짐.

• 권한 모델이 사람 머리로 추적이 안 됨. "이 사람이 왜 이 화면이 되지?"를 설명할 수 있는 담당자가 회사에 한 명 있거나, 이미 퇴사했음
• 패치를 미룸. ERP는 멈추면 월급이 안 나가는 시스템이라 다들 분기 패치를 다음 분기로 미룸. 그러다 1년이 감
• 인터넷에 노출된 EBS가 의외로 많음. 협력사 포털, 셀프서비스 HR, 아이서포트 같은 모듈을 열어두느라 웹 계층이 밖에 나와 있음

작년 EBS 관련 사건들이 남긴 교훈이 딱 이거였음. 취약점 자체보다 "밖에 있고, 패치가 늦고, 로그를 아무도 안 봄"이라는 세 조건이 겹칠 때 피해가 커졌음.

3. 개념 수준에서, 이런 결함은 어떻게 쓰이나

재현 코드는 안 씀. 대신 공격자 머릿속 순서만 적음. 방어를 설계하려면 이 순서를 알아야 함.

• 지도 그리기 — 로그인 후 자기 권한으로 보이는 화면을 다 훑고, 응답에 섞여 나오는 함수명·페이지 경로·파라미터 이름을 수집함
• 경계 찾기 — 수집한 이름 중 자기 메뉴에 없는 걸 골라 직접 호출해 봄. 여기서 서버가 403 대신 화면을 내주면 게임 끝임
• 권한 굳히기 — 얻은 기능으로 자기 계정에 Responsibility를 붙이거나, 다른 계정을 만들거나, 승인 규칙을 손봄
• 조용히 쓰기 — 데이터를 한 번에 퍼가지 않음. 정상 업무 시간에, 정상 화면으로, 조금씩 봄

이 흐름의 무서운 점은 모든 단계가 정상 트래픽처럼 생겼다는 것임. 셸코드도 없고 SQL 인젝션 문자열도 없음. 그냥 인증된 사용자의 평범한 HTTP 요청임. 그래서 시그니처 기반 탐지가 무력함.

4. 그럼 뭘 보고 잡나 — 탐지 관점

시그니처가 안 먹히면 "권한의 변화"와 "행동의 이질감"을 봐야 함. 실제로 볼 만한 것들임.

• 권한 부여 이벤트를 이벤트로 취급하기 — 사용자에게 Responsibility가 붙거나 떨어지는 순간, 계정이 생성·활성화되는 순간을 감사 로그에서 뽑아 매일 사람이 읽는 리포트로 만듦. 하루 몇 줄밖에 안 나옴. 그 몇 줄에 이상한 게 섞이면 바로 보임
• 403/401의 급증 — 정상 사용자는 권한 없는 화면을 거의 두드리지 않음. 한 계정에서 접근 거부가 뭉치로 나오면 그건 경계를 더듬고 있다는 뜻임
• 메뉴에 없는 경로 호출 — 그 사용자의 Responsibility로 도달 가능한 화면 목록을 뽑아두고, 웹 로그의 실제 호출 경로와 대조함. 이 대조가 이 취약점 계열에 가장 잘 듣는 탐지임
• 시간·위치의 이질감 — 경리팀 계정이 새벽 3시에 발주 승인 화면을 보는 건 기술적으로 정상 요청이지만 업무적으로 비정상임
• 결과물 쪽 감시 — 거래처 은행계좌 변경, 승인 한도 조정, 급여 계좌 수정 같은 최종 이득 지점에 별도 알림을 걸어둠. 침투 경로는 다양해도 목적지는 몇 개 안 됨

5. 완화 — 오늘 할 수 있는 순서대로

• 분기 패치 적용 계획을 문서로 만들기. Oracle은 정해진 주기로 패치를 냄. "언제 적용할지"를 정해두지 않으면 영원히 안 함. 검증 환경이 없어서 못 하는 거면, 그 검증 환경 만드는 게 이번 분기 과제임
• 노출면 줄이기. EBS 웹 계층이 인터넷에서 바로 보일 이유가 있는지 다시 물어봄. 협력사·재택 접근은 VPN이나 리버스 프록시 + 인증 게이트웨이 뒤로 넣고, 관리 화면은 내부망에서만 열리게 함
• 권한 대청소. 사용하지 않는 계정 비활성화, 퇴사자 잔여 권한 회수, 한 사람이 여러 Responsibility를 겸하고 있는 조합(예: 거래처 등록과 대금 지급을 같은 사람이) 찾아내기. 이건 CVE와 무관하게 항상 이득임
• 서비스 계정 손보기. 배치·연동용 계정이 왜 그 권한을 갖고 있는지 설명 못 하면 그건 줄여야 하는 권한임
• 감사 로그 켜져 있는지 확인. 의외로 꺼져 있음. 사고 나고 나서 "로그가 없네요"가 제일 아픔. 최소한 로그인·권한변경·민감 폼 접근은 남기고, 원본과 분리된 곳으로 보내둠

6. 정리하면

이런 유형의 취약점은 화려하지 않음. 뉴스에 나올 만한 데모 영상도 없음. 대신 조용히 오래 남고, 발견될 때는 이미 계좌가 바뀐 뒤임. 그래서 대응도 화려할 필요가 없음. 패치 일정 정하기, 밖에 열어둔 거 닫기, 권한 목록 한 번 읽기, 로그 켜기. 이 네 개가 전부고, 이 네 개를 실제로 하는 조직이 생각보다 적음.

개인적으로는 EBS 같은 오래된 ERP를 맡고 있다면 "권한 부여 이벤트 일일 리포트" 하나 만드는 걸 제일 먼저 추천함. 코드 한 줄 안 고치고, 쿼리 하나로 끝나고, 이 CVE뿐 아니라 내부자 사고까지 같이 걸림. 가성비가 압도적임.

여러분 회사 EBS는 지금 인터넷에서 보이나요? 마지막 분기 패치는 언제 올렸나요? 이 두 질문에 바로 답이 안 나오면 오늘 확인해 볼 만함. 확인해 보시고 결과가 어땠는지 댓글로 나눠주면 좋겠음. 같이 점검해보아요!