서명은 맞는데 사용자는 아무나 — ownCloud WebDAV 서명 검증이 놓친 조건

이미지 출처: CISA KEV

2023년 11월 말, 파일 공유 서버를 운영하던 관리자들이 한 주 사이에 ownCloud 권고문 세 건을 연달아 받아야 했음. 그중 하나가 오늘 볼 CVE-2023-49105인데, 같은 시기 훨씬 유명해진 graphapi 정보노출(CVE-2023-49103)에 가려 상대적으로 조용히 지나간 감이 있음. 그런데 방어자 입장에서 보면 이쪽이 더 고약함. 설정 파일 하나 읽히는 게 아니라, 남의 계정 파일을 읽고 쓰고 지울 수 있는 문제였기 때문임.

핵심 요약

• ownCloud core의 WebDAV 접근 경로에서, 서명된 URL 검증 로직이 "누가 요청했는가"를 충분히 묶어두지 못해 인증 없이 타인 파일에 접근 가능했던 문제임.
• 공격에 특별한 도구가 필요 없음 — 평범한 WebDAV 요청 형태라 IDS 시그니처보다 웹 접근 로그의 패턴으로 잡는 게 현실적임.
• 대응은 core 업데이트가 정답이고, 그 전까지는 서명 URL 기능 차단과 로그 소급 점검을 병행해야 함.

1. 무슨 일이 있었나

ownCloud는 설치형 파일 동기화·공유 플랫폼임. 웹 UI 뒤에서 실제 파일 입출력을 담당하는 건 대부분 WebDAV 엔드포인트고, 데스크톱 클라이언트나 모바일 앱도 결국 이 경로로 붙음. 문제는 이 WebDAV 경로에 붙어 있던 pre-signed URL 처리 로직이었음.

pre-signed URL은 원래 좋은 아이디어임. "이 사용자가, 이 파일을, 이 시각까지, 이 메서드로" 접근해도 된다는 걸 서버가 서명해두면, 매번 세션을 확인하지 않고도 접근 허용 여부를 판정할 수 있음. 클라우드 스토리지가 흔히 쓰는 방식이기도 함. 그런데 서명 검증이라는 게 "서명이 유효한가"와 "이 서명이 지금 이 요청에 해당하는가"는 완전히 다른 질문이고, 후자를 빠뜨리면 서명은 통행증이 아니라 만능키가 되어버림.

2. 취약점의 성격 — 개념 수준으로만

이 사안의 핵심은 요청에 담긴 사용자 식별자와, 서명을 만들 때 사용된 비밀값·대상 정보가 서로 단단히 결합돼 있지 않았다는 점임. 그래서 다음 조건이 겹치면 인증되지 않은 요청이 통과할 여지가 생김.

• 서명 검증에 쓰이는 비밀값이 예측 가능하거나, 사용자별로 분리되지 않은 상태일 것
• URL에 들어간 사용자 지정 부분을 서버가 그대로 신뢰할 것
• 서명 대상 문자열에 요청 주체·유효기간 같은 결정적 요소가 빠져 있을 것

세 가지가 맞아떨어지면 공격자는 자신에게 정당하게 발급된 형태의 접근 정보를 기준 삼아, 대상만 바꿔치기한 요청을 만들어 볼 수 있음. 여기서 더 구체적인 요청 구성이나 서명 생성 절차를 적을 생각은 없음. 방어자가 알아야 할 건 "무엇을 만들면 뚫리는가"가 아니라 "뚫렸다면 로그에 무엇이 남는가"이기 때문임.

영향 범위도 짚고 갈 필요가 있음. 이 문제는 서명 URL 기능을 실제로 활성화해 쓰는 환경에서 의미가 있음. 즉 "우리도 ownCloud 쓰는데?" 하고 무작정 패닉할 일은 아니고, 설정을 먼저 확인하는 게 순서임. 다만 확인 전까지는 노출됐다고 가정하고 움직이는 편이 안전함.

3. 탐지 — 무엇을 어디서 볼 것인가

이 유형은 익스플로잇 트래픽이 정상 트래픽과 겉모습이 거의 같음. 그래서 페이로드 시그니처보다 맥락 이상을 봐야 함. 실무에서 먼저 열어볼 것들임.

• 웹서버 액세스 로그: /remote.php/dav/ 계열 경로에 대해, 세션 쿠키 없이 쿼리스트링에 서명 파라미터만 달고 들어온 요청. 정상 클라이언트는 대개 인증 헤더나 쿠키를 동반함.
• User-Agent 이상: ownCloud 데스크톱/모바일 클라이언트 UA가 아닌 스크립트성 UA(curl, python-requests 등)가 DAV 경로에 반복 접근한 흔적.
• 계정-IP 조합: 특정 사용자 경로에 대한 접근이 그 사용자가 평소 쓰지 않던 IP·ASN·국가에서 발생했는지. 파일 공유 서버는 사용자별 접속 지점이 의외로 안정적이라 이 신호가 잘 먹힘.
• 메서드 분포: 짧은 시간에 PROPFIND가 몰린 뒤 GET이 이어지는 흐름. 목록을 훑고 원하는 파일을 골라 받아간 전형적 형태임.
• ownCloud 자체 로그와 파일 활동 기록: 삭제·이동 이벤트가 해당 사용자의 웹 로그인 기록 없이 발생했다면 그 자체가 강한 신호임.

개인적으로는 리버스 프록시(nginx, Apache) 단의 로그를 SIEM으로 넘겨 "인증 흔적 없는 DAV 요청 중 200/207 응답을 받은 것"만 따로 뽑아보는 쿼리를 하나 만들어두길 추천함. 이 취약점뿐 아니라 이후에 나올 유사한 인증 우회에도 계속 재사용할 수 있는 자산이 됨.

4. 완화 — 순서대로

패치가 항상 첫 번째지만, 현실에서 파일 서버는 바로 못 내리는 경우가 많으니 단계로 정리함.

• 업데이트: ownCloud가 제공하는 core 보안 릴리스로 올림. 애드온이 아니라 core 쪽 수정이라 앱 비활성화만으로 끝나지 않음.
• 기능 차단: 즉시 패치가 어렵다면 서명 URL 관련 기능을 설정에서 끔. 기능을 실제로 쓰고 있는지부터 확인하고, 안 쓰고 있었다면 그대로 꺼둔 채 유지하는 게 낫음.
• 앞단 차단: 프록시나 WAF에서 인증 컨텍스트 없이 서명 파라미터만 달고 들어오는 DAV 요청을 임시로 거절. 정상 클라이언트 동작을 깨지 않는지 스테이징에서 먼저 확인해야 함.
• 노출면 축소: 관리 콘솔과 DAV 엔드포인트를 인터넷 전면에 열어둘 필요가 있는지 재검토. VPN 뒤로 넣거나 IP 허용목록을 거는 것만으로도 상당 부분이 정리됨.
• 사후 점검: 패치했다고 끝이 아님. 취약했던 기간의 로그를 소급해 위 탐지 항목으로 훑고, 이상 접근이 있었다면 해당 사용자 자격증명 초기화와 공유 링크 회수까지 이어가야 함.

5. 이 사건에서 남는 교훈

서명 기반 인가는 편하지만 조건이 까다로운 설계임. 서명 대상 문자열에 주체·대상·행위·만료가 전부 들어가야 하고, 비밀값은 충분히 예측 불가능해야 하며, 검증할 때 어느 하나라도 생략하면 그 즉시 무너짐. 이건 ownCloud만의 이야기가 아니고, 사내에서 직접 만든 다운로드 링크나 리포트 공유 기능에도 똑같이 적용되는 체크리스트임. 자체 개발한 서명 URL이 있다면 이번 기회에 한 번 열어보는 걸 권함.

그리고 하나 더. 같은 시기 ownCloud에서 나온 다른 취약점이 훨씬 크게 보도되면서, 관리자들이 그쪽만 처리하고 넘어간 사례가 적지 않았음. 권고문이 여러 건 나올 때는 뉴스에 많이 나온 것 하나가 아니라 목록 전체를 체크리스트로 만들어 하나씩 지워가는 습관이 필요함. 이런 게 쌓여서 나중에 큰 차이를 만드는 것 같다.

혹시 ownCloud를 운영 중이라면 오늘 로그 한 번 열어보시길. 위에 적은 쿼리 만드는 과정에서 막히는 부분 있으면 댓글로 남겨주세요, 같이 풀어보아요!