조믈라(Joomla)는 훌륭한 커뮤니티 지원을 바탕으로 한 매우 안정적인 CMS입니다. 개인 블로그부터 정부 기관 사이트까지 폭넓게 활용될 만큼 확장성과 커스터마이징 자유도가 높고, 90개 이상의 언어를 지원해 전 세계적으로 널리 사용되고 있습니다. 하지만 인기가 많다는 것은 곧 스패머와 해커들의 주요 공격 대상이 된다는 의미이기도 합니다. 실제로 조믈라 사용자 포럼에는 "내 조믈라 사이트가 해킹당해 스팸 메일을 발송하고 있다"는 문의가 꾸준히 올라옵니다. 이러한 공격은 피해 사용자가 워낙 많아 상당히 흔하며, 스팸 메일 대부분은 비아그라 등 의약품 광고로 이루어져 있습니다.
조믈라 해킹 후 스팸 메일 발송 시 나타나는 징후
스팸 메일 공격은 보통 몇 시간에서 며칠에 걸쳐서야 발견됩니다. 이메일이 실제로 전파되고 수신자에게 도달하기까지 시간이 걸리기 때문입니다. 따라서 대부분은 수신자가 "스팸 메일을 받았다"고 알려줄 때 문제를 인지하게 됩니다. 다만 일부 관리자는 발송 전 온라인 서비스로 스팸 여부를 점검하는 경우, 해당 도메인이 스팸 블랙리스트에 등재되었다는 통보를 받기도 합니다. 또한 일부 온라인 보안 솔루션은 이러한 위협을 미리 감지해 경고해 주기도 합니다.
경우에 따라서는 스팸 발송으로 인해 대역폭이 포화 상태에 빠지기도 하며, 이 경우 인터넷 서비스 제공업체(ISP)로부터 스팸 메일 발송 통보를 받을 수 있습니다. 인터넷에는 다양한 온라인 스팸 목록(RBL)이 운영되고 있으며, 조믈라가 해킹당해 스팸을 발송 중이라면 서버 IP가 블랙리스트에 오르게 됩니다. 한 곳에서 차단되면 그 정보가 다른 모든 블랙리스트로 확산되고, 결국 구글 같은 검색 엔진까지 해당 사이트를 스팸 사이트로 분류합니다. 그 결과 사용자가 방문하면 아래와 같은 경고 화면을 마주하게 됩니다.
대량의 스팸 메일이 사이트에서 발송된 사실이 확인되면 구글은 해당 페이지를 공격 페이지로 지정합니다. 이 경고 화면은 사용자에게 더 이상 사이트에 진입하지 말라고 안내하는 역할을 합니다. 이러한 증상이 나타난다면 조믈라가 해킹당해 스팸을 발송 중일 가능성이 높습니다!
실제 사례
조믈라 해킹 후 스팸 메일 발송 문제는 매우 광범위하게 퍼져 있습니다. 커뮤니티 포럼에는 여러 사용자가 이 문제를 호소하고 있으며, 심지어 재감염을 겪는 사례도 있습니다. 아래는 조믈라 커뮤니티 포럼에서 확인할 수 있는 실제 사례들입니다.
원인
SQL 인젝션(SQL Injection)
조믈라 데이터베이스는 자주 공격 대상이 됩니다. SQL 인젝션이 웹 전반에서 매우 흔한 공격 기법이며, OWASP Top 10 취약점에도 포함되어 있기 때문입니다. 공격자가 데이터베이스 장악에 성공하면 SQL문을 활용해 회원가입 이메일이 저장된 테이블을 찾아낼 수 있습니다. 목록을 확보한 공격자는 이를 이용해 대량의 사용자에게 스팸을 발송합니다. 따라서 데이터베이스 보안 유지가 무엇보다 중요합니다.
예를 들어, 조믈라에는 Jimtawl이라는 익스텐션이 있습니다. 웹에서 라디오 방송국을 운영할 수 있게 해주는 컴포넌트인데, 이 컴포넌트에서 SQL 인젝션(SQLi) 취약점이 발견된 바 있습니다. 취약한 파라미터는 id였으며, 전체 URL은 다음과 같습니다.
https://localhost/[PATH]/index.php?option=com_jimtawl&view=user&task=user.edit&id=[SQL]
이 컴포넌트는 사용자 입력값을 검증 없이 그대로 처리했기 때문에 SQLi가 가능했습니다. 즉, id 파라미터 뒤에 SQL문을 덧붙여 데이터베이스 내용을 열람할 수 있었던 것입니다. 예를 들어 다음 쿼리를 실행하면 데이터베이스 버전과 사용자 정보가 노출됩니다.
' AND EXTRACTVALUE(66,CONCAT(0x5c,(SELECT (ELT(66=66,1))),CONCAT_WS(0x203a20,USER(),DATABASE(),VERSION())))-- VerAyari
앞의 작은따옴표(')가 기존 입력 구문을 종료시키고, 이후 OR 절이 다음 SQL문을 실행하여 사용자 및 DB 버전 정보를 가져옵니다. 이 취약점의 익스플로잇 코드는 이미 공개되어 있으며, 공격자는 자동화 도구를 활용해 공격 속도를 더욱 높일 수 있습니다. 이후 공격자는 데이터베이스에 저장된 모든 이메일 주소를 수집할 수 있습니다.
사이트가 Stack Based SQLi에 취약한 경우, 공격자는 명령어 실행까지 가능합니다. 이 명령들은 로컬 서버에서 구동 중인 데이터베이스 서비스를 통해 수행되며, 이를 통해 조믈라 스팸 메일 발송 문제가 발생할 수 있습니다. 즉, 스팸이 로컬 SMTP 서버 자체에서 시작될 수 있는 것입니다. 게다가 공격자는 데이터베이스 정보를 활용해 사이트에 대한 다른 공격도 감행할 수 있습니다!
취약한 계정 자격 증명
공격자가 SMTP 서버 로그인을 무차별 대입(brute force) 공격으로 뚫었을 가능성도 있습니다. 기본 비밀번호나 약한 비밀번호를 사용하면 이런 공격에 쉽게 노출됩니다. SMTP 서버가 공격자에게 넘어가면 조믈라 사이트를 통해 스팸 메일이 발송되는 결과로 이어집니다.
열려 있는 포트
포트가 열려 있으면 사이트가 공격자에게 노출됩니다. SMTP는 기본적으로 25번 포트를 사용하지만, 이 포트는 스패머들이 집중적으로 노리는 대상이므로 사용을 피해야 합니다. 일부 ISP는 아예 25번 포트를 차단하기도 합니다. 587번 포트가 더 나은 대안입니다. TLS 암호화를 지원하기 때문입니다. 25번 포트는 악성코드와 스팸의 주요 표적이며, 공격자는 열린 포트를 통해 침입해 조믈라 스팸 발송 문제를 일으킬 수 있습니다. 25번 포트를 인터넷에 그대로 노출하면 대량의 인바운드 스팸이 유입되는 결과를 낳습니다!
스크립트 업로드
공격자는 대개 위에서 언급한 기법으로 서버를 장악한 뒤, 스팸 발송을 자동화하여 효율을 극대화합니다. PHP 스크립트는 이 작업에 매우 적합합니다. 이런 스크립트는 SMTP 서버나 경우에 따라 MX 서버에 직접 연결하는 데 사용됩니다. 전형적인 스크립트는 다음과 같은 형태입니다.
보다시피 코드 난독화 기법이 적용되어 있습니다. 하지만 이 스크립트를 디코딩하면 대략 다음과 같은 내용이 드러납니다.
코드에서 볼 수 있듯이 이 스크립트는 eval() 구문을 사용합니다. eval()은 입력 문자열을 PHP 코드로 실행하는 함수로, 안전한 코딩 관행에서는 사용을 피해야 합니다. 공격자가 서버에서 임의의 코드를 실행할 수 있게 해주기 때문입니다. 또한 eval()을 이용하면 코드를 데이터베이스에 저장해 두었다가 나중에 실행함으로써 조믈라 스팸 발송을 지속할 수도 있습니다. 이러한 스크립트는 두 가지 방식으로 대량 스팸을 퍼뜨립니다.
- MTA 큐 스팸(MTA Queue Spam): MTA(Message Transfer Agent)는 조믈라 사이트의 메일을 수신자에게 전달하는 역할을 담당합니다. 공격 스크립트가 MTA 큐에 대량의 스팸 메일을 주입하는 경우가 많으며, 이때 "MTA Queue is too large!(MTA 큐가 너무 큽니다!)" 같은 경고 메시지가 나타날 수 있습니다. 일정 한도를 초과하면 ISP가 메일을 차단하기 때문에, 스크립트는 때때로 MX 서버에 직접 연결하는 방식을 씁니다.
- Direct to MX 스팸(Direct to MX Spam): Direct to MX 방식은 ISP라는 중개자를 우회할 수 있게 해 줍니다. Direct to MX는 원래 수신자의 Mail eXchange 서버로 메일을 직접 전달하는 정당한 서비스이며, 이 과정에서 메일이 ISP의 SMTP 서버를 거치지 않습니다. 스크립트는 이 특성을 악용해 MTA 큐 검사를 회피하면서 수신자에게 직접 스팸을 주입합니다.
웹 호스팅 공간 공유
저렴한 호스팅이 결국 큰 비용을 부르는 경우가 많습니다. 여러 사이트가 동일한 공간을 공유하면 감염이 빠르게 번집니다. 따라서 조믈라 스팸 발송 문제가 같은 서버에 있는 다른 사이트의 감염에서 비롯되었을 수도 있습니다. 이 경우 어떤 사이트가 스팸을 생성하는지 파악하기가 무척 어려워집니다!
조믈라 스팸 메일 문제로 서버 보안 전문가의 도움이 필요하신가요? 지금 채팅 위젯으로 문의해 주세요. 즉시 스팸 문제를 해결해 드립니다.
스팸 메일 수신 문제
회원가입 스팸(Registration Spam)
지금까지는 해킹 후 스팸을 발송하는 사례를 살펴봤지만, 때로는 사이트 자체가 스팸의 표적이 되기도 합니다. 대량의 가짜 회원가입이 사이트로 향하는 경우가 그렇습니다. 조믈라에는 폼이 비활성화된 상태에서도 이메일을 제출할 수 있는 취약점이 존재했는데, 이는 com_contact라는 컴포넌트의 결함 때문이었으며 CVE-2018-17859로 명명되었습니다. 이 취약점을 악용하면 공격자가 대량의 스팸 이메일을 제출할 수 있습니다. 적절한 검증 절차가 없으면 봇이 회원가입 테이블을 자동으로 도배해 결국 정상 가입자와 봇을 구분하기 어려운 상황이 벌어집니다!
또한 일부 사이트는 새 회원가입마다 알림을 받도록 설정해 두기도 합니다. 이 경우 회원가입 스팸으로 인해 알림이 폭증할 수 있습니다. 알림 수가 일정 한도를 넘으면 서비스 제공업체가 이를 스팸으로 판단해 계정을 차단하고 신규 가입 알림을 막아버립니다. 회원가입 외에도 사이트가 공격받는 동안에도 알림이 생성되므로, 한도 초과 시 동일한 문제가 발생합니다.
NDR(전송 실패 보고서) 스팸
SMTP 프로토콜은 설계상 "From"과 "To" 필드를 누구든 조작할 수 있도록 되어 있습니다. 일반 사용자조차 가능합니다. 스패머들은 이를 악용해 "From" 필드에 여러분의 도메인을 넣곤 합니다. 진행 과정은 다음과 같습니다.
- 1단계: 봇이 존재하지 않는 가짜 이메일 주소 목록을 생성합니다.
- 2단계: "From" 항목에 여러분의 이메일(admin@wsxdn.com)을 발신자로 지정합니다.
- 3단계: 봇이 존재하지 않는 계정으로 메일을 발송합니다.
- 4단계: 메일 전송이 실패합니다.
- 5단계: 전송 실패 보고서(NDR)가 여러분의 계정(admin@wsxdn.com)으로 되돌아옵니다. 그 결과 대량의 스팸 메일이 쏟아져 들어옵니다.
조믈라에서 스팸 메일을 막는 방법: 해결책
인바운드 스팸 차단
SPF(Sender Policy Framework)
SMTP 프로토콜에는 고유한 한계가 있습니다. 임의의 사람이 "From" 항목에 여러분의 도메인을 사용하는 것 자체를 막을 수 없다는 점입니다. 하지만 대응 방법이 있습니다. 여러분 도메인을 대신해 메일을 보낼 수 있는 IP를 메일 서버에 알려주는 것입니다. 이 역할을 하는 것이 바로 DNS TXT 레코드 형태의 SPF입니다. SPF 설정 절차는 다음과 같습니다.
- 먼저 DNS 관리(DNS Management) 페이지로 이동합니다.
- 레코드(Records) 섹션으로 이동한 뒤, 추가(Add)를 클릭하고 메뉴에서 TXT를 선택합니다.
- 다음 항목들을 작성합니다.
- Host: 호스트명을 입력합니다. 예를 들어 @를 입력하면 레코드가 도메인 이름에 바로 매핑됩니다.
- TXT 값(TXT Value): 할당하려는 값을 입력합니다.
- 마지막으로 저장(Save)을 클릭합니다.
완성되면 YourDomain.com. IN TXT "v=spf1 mx ip4:123.123.123.123 -all"과 같은 형태가 됩니다.
이 레코드는 YourDomain.com의 유효한 메일 발송 출처가 단 두 곳임을 의미합니다. 하나는 Mail Exchange(MX) 서버이고(수신 도메인을 정의하는 서버), 다른 하나는 123.123.123.123 서버입니다. 그 외 모든 이메일은 스팸으로 간주됩니다. 다만 robots.txt와 마찬가지로 이것은 하나의 '규약'일 뿐이라는 점에 유의하세요. 대부분의 메일 서버가 이를 준수하지만, 그렇지 않은 곳도 존재합니다!
Astra 보안 전문가와 상담하고 즉각적인 악성코드 제거를 받아보세요. 강력한 방화벽이 XSS, LFI, RFI, SQL 인젝션, 악성 봇, 자동화 취약점 스캐너 등 80가지 이상의 보안 위협으로부터 웹사이트를 보호합니다.
아웃바운드 스팸 차단
스팸 스크립트 식별 및 제거
1단계: 먼저 스팸을 생성하는 스크립트를 식별해야 합니다. 관리자(SUDO) 권한으로 메일 서버에 로그인합니다.
2단계: 스크립트가 발송하는 아웃바운드 메일을 추적하려면 PHP.ini 파일에 다음 설정이 있는지 확인합니다: mail.add_x_header = On. 설정 후 메일 큐를 점검합니다.
3단계: mailq 명령어를 실행하면 큐에 쌓인 모든 메일이 나열됩니다. 여기서 출처를 추적하고자 하는 메일의 ID를 확인합니다.
4단계: 이제 "grep"과 "postcat" 명령어가 유용합니다. 다음 명령을 실행합니다: postcat -q <mailq에서 얻은 ID> | grep X-PHP-Originating-Script
5단계: 이 명령은 X-PHP-Originating-Script: 45:SPAMmailer.php와 같은 출력을 반환합니다. 여기서 45는 SPAMmailer.php 스크립트의 UID입니다. 이 명령으로 조믈라 스팸 발송 스크립트와 서버 내 위치를 성공적으로 찾아냈습니다. 해당 스크립트를 삭제하고 설치 환경을 청소하세요.
단, 4단계에서 아무런 출력이 없다면 계정 자체가 탈취되었을 가능성이 높습니다. 조믈라 스팸 발송을 막으려면 즉시 안전한 비밀번호로 변경하세요!
기타 예방 조치
- 구글에 블랙리스트로 등재된 경우, 사이트를 정화한 뒤 재검토 요청을 제출하세요.
- 꼭 필요한 경우가 아니라면 Direct to MX를 차단하세요.
- SMTP에 25번 포트를 사용하지 말고, 대신 587번 포트를 사용하세요.
- 가능하면 전용 VPS 호스팅을 사용하세요. 조믈라 스팸 감염이 확산될 가능성을 줄여줍니다.
- 폴더의 읽기·쓰기·실행 권한을 신중하게 관리하세요. 스팸 메일러 스크립트가 업로드되더라도 코드 실행 자체를 막을 수 있습니다.
- 신뢰할 수 있는 익스텐션만 설치하고, 출처 불명 또는 불법 복제(null) 익스텐션은 피하세요.
- SMTP 서버의 인증 시도 횟수를 제한하세요. 무차별 대입 공격을 예방할 수 있습니다.
- 그리고 무엇보다, 업데이트! 업데이트! 업데이트!
결론
조믈라 해킹으로 인한 스팸 발송은 사이트 평판에 심각한 타격을 줄 수 있습니다. 최선의 예방책은 보안 솔루션을 활용하는 것입니다. 요즘은 방화벽과 IDS를 갖춘 다양한 보안 솔루션이 온라인에서 제공되고 있으며, Astra 같은 솔루션은 뛰어난 확장성을 바탕으로 개인 블로그부터 대형 기업까지 다양한 요구를 충족시켜 줍니다.