소스공유 사이트 깃허브, 최대 DDOS공격 당해

멤캐시드 UDP 반사 공격…권한설정 없이 인터넷 노출된 서버포트 악용 기법

소스코드 공유사이트 깃허브(Github)가 2월말 사상 최대규모로 기록된 분산서비스거부(DDoS) 공격을 받은 것으로 알려졌다. 이번 공격은 깃허브 사이트에 10분가량 운영 장애를 유발했다. 공격은 일반적으로 알려진 DDoS 공격 기법이나 대규모 봇넷과는 다른 방식을 통해 이뤄졌다.

깃허브는 지난 1일자 공식 엔지니어링 블로그 포스팅을 통해 지난 2월 28일 발생한 DDoS 공격 사례가 발생한 배경을 설명했다. [☞원문보기] 미국 지디넷은 이를 인용한 1일자 보도에서 깃허브를 겨냥한 DDoS 공격이 이전까지 최대로 기록됐던 1.1Tbps 규모의 DDoS 공격 사례를 넘어섰다고 지적했다. [☞원문보기]

깃허브는 이날 1차로 초당 1.35테라비트(Tbps) 규모 DDoS 공격을 받았고, 이어 초당 400기가비트(Gbps) 규모의 추가 DDoS 공격을 받았다고 밝혔다. 공격 여파로 협정세계시(UTC) 기준 2월 28일 17시 21분부터 26분까지 깃허브 사이트가 마비됐고, 26분부터 30분까지 간헐적으로 동작하지 못했다. 한국시간으로는 3월 1일 2시 21~30분 사이에 벌어진 일이다.

수많은 오픈소스 프로젝트와 IT업체의 SW개발 협력 프로젝트를 호스팅하는 깃허브가 2018년 2월말 사상최대로 기록된 1.35Tbps 규모 DDoS 공격을 받아 일시 운영장애를 일으켰다. [사진=Pixabay]

깃허브는 수많은 개발자들이 소스코드를 공유하고 오픈소스 프로젝트를 호스팅하는 곳이다. 해당 시점에 깃허브에 의존해 동작하는 수많은 소프트웨어 및 서비스가 운영상 차질을 빚었을 수 있는데, 깃허브는 "공격에 데이터의 기밀성이나 무결성에 문제가 발생한 지점은 없었다"고 밝혔다.

깃허브 설명에 따르면 대규모 DDoS 공격은 수만 곳의 고유 엔드포인트를 포함하는 1천여개 자동화 시스템을 통해 발생했다. 누군가 초당 1억2천690만패킷을 통해 최대시점에 1.35Tbps 트래픽을 발생시키는 멤캐시드(memcached) 기반 증폭(Amplification) 공격, 또는 '멤캐시드 UDP 반사(reflection)' 공격을 수행했다는 설명이다.

2018년 2월말 깃허브 사이트에 운영장애를 유발한 DDoS 공격 트래픽 규모.

멤캐시드는 디스크스토리지나 데이터베이스같은 대규모 데이터저장소의 부하를 줄이기 위해 캐시를 저장해 두는 툴이다. 통상 캐시가 필요한 시스템에만 사용되고, 인터넷에 노출되지 않기 때문에, 별도 권한설정을 요구하지 않는다. 하지만 현실은 인터넷에 노출된 멤캐시드 서버가 적지 않고, 이들은 DDoS 공격 수단으로 전락할 수 있다.

이미 콘텐츠전송네트워크(CDN) 전문업체 클라우드플레어는 2월 27일자 블로그 포스팅을 통해 공격자가 이런 멤캐시드 서버 가운데 보안관리가 허술한 시스템을 악용할 경우 그 UDP 11211번 포트를 통해 트래픽 증폭형 DDoS 공격을 시도할 수 있음을 지적했다. 클라우드플레어는 이를 '멤크래시드(Memcrashed)'라고 표현하기도 했다.

클라우드플레어에 따르면, UDP 지원 기능이 켜진 채 외부 인터넷을 통해 관리자가 의도하지 않게 접근 가능한 멤캐시드 인스턴스를 통해 증폭 공격이 수행된다. 공격자는 멤캐시드의 UDP 동작을 악용해 깃허브같은 표적 사이트에 문제가 될만큼 많은 데이터 트래픽을 한꺼번에 몰아넣을 수 있도록 함으로써 DDoS를 유발할 수 있다.

이를 위해 공격자는 IP주소를 위조(Spoofing)한다. 주소 위조는 멤캐시드의 응답 대상을 원래 요청 위치가 아니라 깃허브같은 서비스를 운영하는 쪽에 쓰이는 주소로 바꿀 수 있다. 또 주소 위조를 통해 정상적인 요청을 보낸 쪽에 필요한 것 이상으로 많은 데이터를 공격 표적으로 보낼 수 있다.

멤캐시드 서버가 공격자의 요청에 엉뚱한 주소로 응답을 돌려보낼 때 증폭효과는 얼마나 발생할까. 클라우드플레어는 잘못된 환경설정때문에 취약한 상태에 있는 멤캐시드 서버는 최고 5만1천배 가량의 증폭계수를 띨 수 있다고 지적했다. 이는 공격자가 보낸 데이터 1바이트당, 표적 시스템으로 51킬로바이트(KB) 수준의 데이터를 퍼부을 수 있다는 뜻이다. [☞원문보기]

멤캐시드(memcached) 공식 홈페이지.

이런 식으로 악용될 수 있는 시스템이 적지 않다.

IT미디어 와이어드 보도에 따르면 대부분 기업이나 기관에서 운영하는 멤캐시드 서버 가운데 사용 권한 보호 없이 온라인에 노출된 시스템이 10만대에 달하는 것으로 추정됐다. [☞원문보기] 또다른 CDN 아카마이에 따르면, 2월말 기준으로 보안이 취약한 상태로 방치된 멤캐시드 시스템이 5만대 이상 존재한다. 향후 이같은 공격 방식이 확산될 우려가 있다는 지적이다. [☞원문보기]

아카마이는 클라우드플레어가 지적한 보안이 허술한 멤캐시드 서버의 특성을 이렇게 설명했다. 멤캐시드는 TCP의 로컬호스트와 대다수 리눅스 버전의 UDP 11211번 포트를 수신하는 게 기본 설정값이지만, 일부 배포 환경은 이 포트를 모든 인터페이스에서 수신하는 구성을 기본 설정값으로 쓴다.

이 멤캐시드 서버가 'get' 요청을 받으면, 요청된 메모리의 값을 모아 응답 내용을 구성한 다음 무중단(uninterrupted) 스트림으로 이를 돌려보낸다. 이 응답은 각각 최장 1천400바이트 길이의 여러 UDP 패킷으로 대상에 전달된다. 공격자는 허술한 멤캐시드 서버를 대상으로 표적 사이트에서 보낸 것처럼 위조한 get 요청을 대량 생성해, DDoS 공격 트래픽을 유발할 수 있다.

아카마이는 이렇게 UDP 패킷으로 수행되는 멤캐시드 서버의 get 응답 동작에 따른 트래픽 발생 현상을 '반사(reflection)'라고 표현했다.

클라우드플레어와 달리 아카마이는 "멤캐시드의 정확한 증폭 계수(배수)을 판정하기는 어렵다"며 단정하지 않았다. 다만 "아카마이가 목격한 공격은 반사 횟수당 1Gbps에 달했고, 다른 조직에서는 멤캐시드 반사를 사용해 500Gbps를 넘어선 공격 사례를 보고했다"고 밝혔다.

아카마이 측은 "대규모 공격은 데이터센터 기반 솔루션으로 쉽게 방어할 수 없다"며 "클라우드 기반의 DDoS 방어 솔루션을 통해 공격을 분산시켜야 한다"고 지적했다.

깃허브는 "현재와 미래 인터넷 환경에 맞춰 깃허브의 엣지 인프라를 더 탄력적으로 만들고 인간의 개입에 덜 의존하게 만들려면 개선된 자동화 조정(intervention)이 필요하다"며 "우리의 모니터링 인프라를 조사해 DDoS 대응수단 공급자를 자동화하고 장애시 복구시간(MTTR)을 단축키 위해 사고대응 시간을 지속 측정할 것"이라고 밝혔다. 이어 "더 나은 탐지 시스템을 구축하고 대응을 간소화하겠다"고 덧붙였다.