남의 달력·문의 폼이 침입 통로가 됐다 — Joomla 확장기능 두 개를 노린 제로데이, 방어자 대응법

이미지 출처: The Hacker News

이벤트 달력을 붙이는 iCagenda, 문의·신청 폼을 만드는 Balbooa Forms. 둘 다 Joomla 사이트라면 흔히 깔려 있는, 말하자면 '있는 줄도 모르고 쓰는' 확장기능임. 그런데 이 조용한 부품 두 개가 패치가 나오기도 전에 실제 공격에 쓰였다는 보고가 나왔음. 코어(Joomla 본체)는 멀쩡한데 곁다리로 붙인 플러그인이 문을 열어준 전형적인 사례라, 방어하는 입장에서 뜯어볼 값어치가 충분함.

핵심 요약

• Joomla 확장기능 iCagenda(이벤트 달력)와 Balbooa Forms(폼 빌더)의 결함이 패치 이전에 악용된 정황이 보고됨 — 이른바 제로데이 상황.
• 코어가 아니라 서드파티 확장기능이 진입점이라는 점이 핵심. 관리자가 설치 사실조차 잊고 방치하기 쉬운 부품임.
• 대응은 단순명료함 — 확장기능 최신화, 안 쓰면 삭제, 웹서버·DB 로그에서 비정상 요청 흔적 뒤지기.

왜 '확장기능'이 매번 문제인가

Joomla, 워드프레스 같은 CMS는 본체보다 그 위에 얹는 플러그인·컴포넌트가 더 위험한 경우가 많음. 이유가 뻔한데, 코어는 전 세계 눈이 지켜보며 감사하지만 개별 확장기능은 소수 개발자가 만들고 업데이트도 뜸함. 사용자 역시 코어 업데이트 알림은 챙겨도 '3년 전에 깔아둔 이벤트 달력'까지는 손이 안 감. 공격자 입장에선 딱 노리기 좋은 사각지대인 셈임.

이번에 지목된 두 부품의 성격을 보면 어디가 급소인지 짐작이 됨. 이벤트 달력은 날짜·카테고리·검색어 같은 파라미터를 받아 DB를 조회하고, 폼 빌더는 사용자가 보낸 값을 저장하거나 파일 첨부를 처리함. 즉 외부 입력이 그대로 서버 내부(데이터베이스·파일시스템)에 닿는 통로라는 뜻임. 입력 검증이 한 군데라도 헐겁다면 SQL 인젝션이나 임의 파일 업로드로 이어질 여지가 생김.

공격은 대략 어떤 그림인가 (개념 수준)

구체적 페이로드를 늘어놓을 생각은 없고, 방어에 필요한 만큼만 개념을 정리함. 이런 부류의 확장기능 취약점은 보통 두 갈래로 나뉨.

• 파라미터를 통한 DB 조작: 달력의 카테고리 ID나 검색 파라미터처럼 겉보기엔 숫자·문자에 불과한 값을, 공격자가 쿼리 구조를 비트는 문자열로 바꿔 보내는 방식. 성공하면 회원 정보나 관리자 계정 해시가 빠져나갈 수 있음.
• 폼을 통한 파일·데이터 밀반입: 첨부 기능이 허용 확장자·MIME 검사를 제대로 안 하면, 이미지인 척한 스크립트 파일이 웹 접근 가능한 경로에 올라감. 그걸 브라우저로 다시 호출하면 서버에서 코드가 실행되는 웹셸이 되는 것임.

'제로데이로 악용됐다'는 말의 무게가 여기 있음. 패치가 배포되기 전, 방어자가 존재조차 모르던 구멍으로 이미 누군가 드나들었다는 뜻이라 단순히 업데이트만 한다고 끝이 아니라 이미 뚫렸을 가능성까지 점검해야 함.

방어자가 지금 할 일 — 순서대로

• 버전 확인과 패치: Joomla 관리자 화면의 확장기능 관리자에서 iCagenda·Balbooa Forms 설치 여부와 버전을 확인하고, 개발사 공지의 최신 버전으로 올림. 자동 업데이트를 꺼뒀다면 이참에 켜두는 걸 개인적으로 추천함.
• 안 쓰면 삭제: '언젠가 쓸까 봐' 남겨둔 비활성 확장기능이 제일 위험함. 비활성 상태여도 파일이 서버에 남아 있으면 직접 URL 호출로 취약 코드에 닿을 수 있음. 미련 없이 지우는 게 낫다.
• 로그부터 뒤지기: 웹서버 액세스 로그에서 해당 컴포넌트 경로(option=com_icagenda, 폼 처리 엔드포인트 등)로 몰린 비정상 요청, 특히 파라미터에 인용부호·UNION·SELECT 같은 SQL 조각이나 이상한 확장자 업로드 흔적이 있는지 훑음. DB 오류 로그가 갑자기 늘었다면 인젝션 시도의 신호일 수 있음.
• 업로드 폴더 점검: 폼 첨부가 저장되는 디렉터리에 최근 생성된 .php, .phtml 등 스크립트 파일이 있는지, 이미지 폴더에 실행 가능한 파일이 섞여 있는지 확인함. 이런 경로는 애초에 웹서버 설정에서 실행 권한을 막아두는 게 정석임.
• WAF·가상 패치: 당장 패치를 못 올리는 상황이라면 웹방화벽 규칙으로 해당 파라미터의 위험 패턴을 임시 차단하는 것도 방법임. 근본 해결은 아니지만 시간을 벌어줌.

한 발 더 — 재발을 줄이는 습관

이번 건은 특정 두 제품 이야기지만 교훈은 일반적임. CMS를 운영한다면 설치한 확장기능 목록을 문서로 관리하고, 분기에 한 번쯤은 '이거 아직 쓰나?'를 스스로 물어보는 게 좋음. 관리자 로그인은 2단계 인증과 IP 제한을 걸어 두고, DB 계정 권한도 웹앱이 꼭 필요한 만큼만 주면 인젝션이 터져도 피해 범위가 줄어듬. 결국 공격 표면을 좁히는 일상적 정리정돈이 화려한 탐지 도구보다 먼저임.

내 사이트엔 저 두 확장기능이 없다고 안심하긴 이름. 오늘 확장기능 목록 한 번 열어보고, 마지막 업데이트가 언제였는지 날짜만 확인해도 절반은 한 거임. 점검하다 애매한 부분 있으면 댓글로 남겨 주세요 — 같이 짚어봅시다.