1. 개요
최근 국내 쇼핑몰을 대상으로 신용카드 결제 페이지 피싱 공격이 자주 발생하고 있다. 신용카드 결제 페이지 피싱 공격은 공격자가 정상적인 사이트를 모방해 이용자의 민감 정보(신용카드 번호, 유효기간, CVC 번호, 카드 비밀번호 등)를 탈취하는 공격이다.
유사한 사고가 급증함에 따라 플레인비트에서 관련 사고 조사를 다수 진행했으며, 사고 조사에서 확인된 공격 기법과 이를 예방할 수 있는 방안을 공유하고자 한다.
2. 사고 개요도
3. 공격 기법
1) 최초 침투: 리버스 셸 연결
공격자는 국내에서 많이 이용하는 쇼핑몰 솔루션의 설계 상 취약점을 악용해 리버스 셸을 연결하면서 웹 서버에 침투했다. 이번 사고에서 특이한 점은 두 페이지의 취약점을 연동 악용해 침투에 성공한 부분이다. 국내에서 많은 수요가 있는 솔루션이기 때문에 공격자가 공격에 악용하기 좋은 공격 대상이고 이전 버전의 소스코드가 공개되어 있어 취약점을 연동 악용하는 부분은 충분히 가능했을 것으로 보인다.
공격자가 최초 침투를 위해 악용한 취약점의 동작 방식은 아래와 같다.
공격자가 악용한 취약점 중 첫 번째 취약점은 요청받은 POST 값을 취약 함수에 별도의 검증 절차 없이 전달해 파일이 생성되는 취약점이다. 공격자는 해당 취약점을 악용해 리버스 셸 연결 코드가 내포된 log 파일을 생성했다.
이후 공격자는 LFI(Local File Inclusion) 취약점을 악용해 무단으로 생성된 .log 파일을 호출했다. 취약 함수에서 특정 파일을 템플릿 파일로 변경할 때 검증 절차 없이 변경된 후 출력되어 리버스 셸 연결 코드 실행이 가능했다.
2) 침해 지속: 공격 환경 구성
공격자는 리버스 셸을 연결한 이후 공격 환경을 구성하기 위해 아래와 같은 작업을 했다.
- 공격 도구 다운로드
공격자는 리버스 셸을 연결한 이후 wget 명령으로 C&C 서버에서 웹셸 파일을 다운로드했다. 웹셸 파일은 ".txt" 파일로 다운로드 받아 ".php" 파일로 변경하는 정황이 확인됐다. 공격자가 다운로드한 웹셸 파일은 다양한 기능 수행할 수 있는 GUI 기반 웹셸과 PHP 기반 데이터베이스 관리 도구인 adminer로 확인됐다.
공격자가 활용한 웹셸 파일은 다음과 같다.
| 파일명 | 파일 경로 | 기능 |
|---|---|---|
| dhgx.php | /app/javascript/plugin/jsGrid | 데이터베이스 관리 도구 |
| jsGridCommon.php | /app/javascript/plugin/jsGrid | GUI 기반 웹셸 |
| lazys.php | /app/javascript/plugin/lazy | GUI 기반 웹셸 |
| test.php | /partner | GUI 기반 웹셸 |
| down.php | /board | GUI 기반 웹셸 |
- 신용카드 결제 피싱 공격 도구 다운로드
공격자는 신용카드 결제 피싱 페이지 공격에 활용되는 파일을 다운로드 했다.
아래 그림을 살펴보면 실제 신용카드 결제 페이지와 유사하게 페이지를 제작해 이용자의 작성을 유도하는 것을 확인할 수 있다.
3) 추가 거점 확보: 웹셸 파일 전파
공격자는 추가 거점 확보를 위해 웹셸 파일을 내부 서버에 Rsync 명령으로 전파했다.
4) 침해 영향: 악성 스크립트 삽입
공격자는 내부 서버에 SSH 접근한 후 권한 상승 취약점(CVE-2021-4034)을 악용하는 정황이 확인되었다. 이로 인해 웹 페이지에 신용카드 결제 피싱 페이지 스크립트를 삽입한 것으로 판단된다.
4. 대응 방안
1) 웹 서버 내 불필요한 모듈 및 자원 삭제
이번 사고는 웹 서비스 운영에 사용되지 않는 페이지의 취약점이 악용되면서 발생했다. 웹 서비스 운영에 사용하지 않는 모듈은 충분한 검토 후 삭제해 추후 발생할 가능성이 있는 취약점을 제거해야 한다.
2) 웹 모듈 취약점 패치
웹 서비스 운영에 솔루션을 사용하는 경우, 솔루션 제작 업체에서는 지속적으로 솔루션 취약점을 패치하고 있다. 패치되는 취약점은 주기적으로 확인이 필요한 번거로움이 있지만 취약점 패치를 위해서는 필수적으로 챙겨야 하는 부분이다. 따라서, 주기적으로 솔루션 취약점이나 웹 서비스에서 사용하는 외부 모듈은 모두 업데이트가 필요하다.
3) 서버 간 접근 제어
분석 당시 서버 간 SSH 접근이나 Rsync 명령 실행이 가능한 환경이었다. 보통 서버에 접근할 때는 유지 보수 목적으로 전용 시스템을 활용하거나 담당자 PC를 통해 접근하는 경우가 대다수다. 따라서, 서버 간 접근을 최소화할 수 있도록 제어하고 주기적으로 이상 징후가 있는지 모니터링이 필요하다.
4) 로그 모니터링으로 위협 탐지
이번 사고는 웹셸이 업로드되거나 악성 스크립트가 삽입되는 등 공격이 표면적으로 확인되어 인지가 가능했다. 보통 공격자는 공격을 하기 전에 공격 대상을 정찰하는 단계가 있기 때문에 침투가 이루어졌다고 해도 바로 영향이 가는 공격을 수행하지 않는다. 웹 서버는 로그 모니터링만으로도 이상 징후 점검이 충분히 가능하기 때문에 주기적으로 점검해 위협을 탐지해야 한다.
5) 로그 저장 정책 강화
사고를 분석하면서 로그 설정이 기본으로 되어있어 덮어씌워진 경우를 많이 마주친다. 로그 서버를 별도로 두지 않는 상황이라면 서버의 데이터 저장 공간을 차지하기 때문에 기본 설정으로 두는 경우가 대다수다.
로그는 침해사고 원인을 규명하기 위해 필수적으로 분석되는 데이터다. syslog는 파일 별로 1개월의 로그를 저장하고, 서버에 최소 6개월의 로그가 보관될 수 있도록 설정이 필요하다. 만약, 데이터 저장 공간 때문에 서버에 6개월의 로그가 보관되기 어려운 환경이라면 백업을 병행하여 문제를 해결할 수 있다.
6) 계정 관리 정책 강화
계정 관리 정책을 강화하는 부분은 대응 방안에 있어 형식적인 얘기처럼 보이지만, 필수적으로 대응해야 하는 부분이다.
공격자가 무차별 대입 공격 등을 통해 계정을 탈취하기도 하지만 계정 관리 정책이 미흡하게 설정되어 있어 탈취되는 경우도 많기 때문이다.
따라서, 시스템 별로 유추할 수 없도록 별도의 비밀번호를 설정하고 영 대/소문자, 숫자, 특수문자를 혼합해 12자리 이상으로 설정하는 것을 권고한다.
