데이터인질극, 아마존웹서비스 사용자 노렸다

허술한 보안설정이 문제…유사 공격 확산

아마존웹서비스(AWS) 사용자들의 클라우드 기반 서버가 랜섬웨어 공격을 모방한 서버털이 범죄의 손쉬운 표적으로 떠올랐다. 일반 개인보다 다수 사용자의 정보를 다루는 클라우드 서버 시스템의 관리자들에게 보안 측면에서 주의가 필요한 상황이다.

랜섬웨어는 표적 시스템을 감염시켜 피해자 데이터를 빼앗거나 망가뜨리고, 되살리기 위해 공격자에게 금품을 넘기도록 유도하는 악성코드다. 랜섬웨어의 피해를 주요 사이버위협으로 꼽은 보안솔루션 회사들이 적지 않았다.

이런 예측과 달리 연초 IT업계의 이목을 사로잡은 사이버위협은 따로 있었다. 랜섬웨어 공격을 모방한 '서버털이' 범죄였다. 데이터를 빼앗고 금품을 요구하는 행태는 랜섬웨어 공격을 닮았지만, 그 방식은 단지 보안 조치가 허술한 시스템을 노렸을 뿐이었다. 정상 시스템을 악성코드로 감염시키는 랜섬웨어와 차이를 보였다.

서버털이 공격의 피해 확산 양상은 랜섬웨어 못잖았다. 1월 2일부터 닷새간 세계각지 오픈소스 NoSQL 시스템 '몽고DB' 서버를 노린 데이터파괴 공격이 빠르게 퍼졌다. 공격자는 데이터를 되찾고 싶다면 0.1~1비트코인(BTC)을 달라고 요구했다. 표적이 된 서버는 3만3천대 이상에 달했다.

데이터를 볼모로 기기 데이터를 빼앗거나 망가뜨리고 그걸 되찾게 해주는 대가로 금품을 요구하는 유형의 사이버위협이 성행하고 있다. 실제 악성코드를 동원한 '랜섬웨어' 공격과, 보안설정의 빈틈을 악용해 '랜섬웨어를 흉내낸' 공격으로 구별된다. [사진=Pixabay]

이어 13일부터 19일까지 비슷한 공격이 3개 그룹에 의해 오픈소스 검색시스템 '엘라스틱서치(ElasticSearch)' 서버를 대상으로 발생했다. 공격은 인터넷에 노출된 서버 3만5천대를 표적 삼았고, 실제 4천700대 가까이 피해를 입혔다. 역시 데이터 복구 비용을 요구했다.

엘라스틱서치 서버털이 공격은, 보안 설정이 허술한 서버에 접근해 데이터를 망가뜨리는 방식 자체는 몽고DB를 노린 공격과 닮았다. 주목할 지점은 엘라스틱서치 서버가 표적이 된 방식에 있었다.

■AWS에 집중된 표적…AWS 문제는 아니다

공격자는 AWS 사용자들의 시스템을 손쉬운 표적으로 삼았을 공산이 크다. 사고를 분석한 보안 전문가들이 파악한 잠재적 표적 대다수가 AWS 기반 시스템이었다. 사물인터넷(IoT) 검색엔진 '쇼단' 설립자 존 매덜리는 지난 12일 트위터 메시지로 공격에 노출된 엘라스틱서치 서버 3만5천대 중 다수가 AWS에서 운영되고 있다고 지적했다.

[☞참조링크: John Matherly의 트윗]

국내에서 나름대로 인지도가 있는 커뮤니티의 웹사이트를 관리하는 개발자 A씨가 지난 20일 제보한 피해 경험도 이런 추정을 뒷받침한다. 그는 웹서버와 별도로 AWS기반 엘라스틱서치 서버를 통해 로그를 분석해 왔다. 그의 서버 데이터도 올초 글로벌 공격이 발생할 무렵 피해를 입었다. 외부 접근이 허용된 방화벽 포트를 통해 인스턴스에 접근한 공격자가 데이터를 날려버린 것으로 추정됐다.

A씨는 운 좋게 백업 데이터를 통해 복구할 수 있었던 사례에 속했다. 그는 공격이 "주로 AWS (퍼블릭클라우드) 기반 환경을 겨냥한 것 같다"고 말했다.

이런 정황을 바탕으로 AWS라는 퍼블릭 클라우드 서비스 또는 엘라스틱서치 서버라는 오픈소스 기술에 보안 문제가 있다는 결론을 내릴 수는 없다. 랜섬웨어를 모방한 공격은 AWS나 엘라스틱서치의 어떤 기술적인 보호장치를 뚫고 시도된 게 아니었다. 비유하자면 그저 인터넷에서 접근할 수 있는 엘라스틱서치 서버 가운데, 문을 잠그지 않고 있는 시스템에 들어간 것뿐이다.

비슷한 공격 사례가 전혀 다른 기술로 운영되는 서버 대상으로 번지고 있다. 사고 원인이 특정 기술이나 시스템의 보안 결함에 있지 않다는 점을 방증한다. IT컨설팅업체 캡제미니의 컨설턴트 나이얼 메리건은 몽고DB와 엘라스틱서치 대상의 공격 피해를 초기부터 집계해 알려 왔는데, 지난 19일에는 카우치(CouchDB)와 하둡(Hadoop) 등에도 비슷한 사이버위협이 발생 중이라 알렸다.

[☞참조링크: Niall Merrigan의 트윗]

■각 기술마다 권장된 '최소 보안조치' 적용돼야

4천700대 서버가 일정한 보안 조치를 적용했다면 지금처럼 세계적인 사이버위협으로 회자되지 않았을지도 모른다. 엘라스틱서치를 비롯한 오픈소스 프로젝트를 지원하는 회사 '엘라스틱(elastic)'가 지난 13일 공격직후 알린 보안 조치 요령에서도 이런 메시지가 느껴진다.

엘라스틱의 마이크 파케트(Mike Paquette)는 공식 블로그를 통해 "이 사건을 인터넷을 통해 접근할 수 있는 모든 엘라스틱서치 인스턴스에 보안 설정을 적용하는 방법이 얼마나 중요한지 상기할 때 활용하자"며 "보안 조치가 적용되지 않은 엘라스틱서치 인스턴스는 인터넷에 직접 노출돼선 안 된다"고 지적했다. 엘라스틱은 이미 지난 2013년 12월 블로그 포스팅에 이런 주의사항을 밝혀 뒀다.

[☞참조링크: Protecting Against Attacks that Hold Your Data for Ransom]

[☞참조링크: Securing Your Elasticsearch Cluster]

그는 블로그에서 엘라스틱서치 서버 인스턴스를 운영하는 사람들에게 데이터를 보호할 방법으로 다음 3단계 설정을 시행하라고 강조했다.

첫째, 안전한 장소에 모든 데이터를 백업해 놓고, 그 수단으로 '큐레이터 스냅샷'이라는 기능 도입을 검토해 볼 것. 둘째, 엘라스틱서치 구동 환경을 별도의 라우팅되지 않는(isolated non-routable) 네트워크로 재설정할 것. 셋째, 서버에 인터넷을 통해 접근해야 한다면 방화벽, 가상사설망(VPN), 리버스프록시(reverse proxy), 이밖에 다른 기술로 그 접근 통로를 제한할 것.

그는 이런 기본적인 조치에 더해 3가지를 추가 실행하라고 권했다. 첫째, 엘라스틱스택(Elastic Stack) 최신버전으로 업그레이드할 것. 둘째, 만일 2버전대(v2.x) 시스템을 구동하고 있다면 스크립팅 설정을 점검하거나, 5버전대(v5.x) 신형 스크립팅 언어 페인리스(Painless) 도입을 검토해 볼 것. 셋째, 엘라스틱서치 인스턴스에 전송계층보안(TLS) 암호화, 인증, 인가, IP필터링 기능을 추가하는 'X-Pack시큐리티'를 쓸 것.