국내 업체 리눅스 서버 공격하는 리쿠베 악성코드 주의!
리쿠베(Rekoobe)는 중국의 APT31 공격 그룹이 사용 중인 것으로 알려진 백도어 악성코드로, 2015년 최초로 발견됐다. 2018년에는 리쿠베의 업데이트된 버전이 공격에 사용되기도 했었다. 안랩 ASEC 분석팀에 따르면, 리쿠베 악성코드는 수년 전부터 국내 고객사들로부터 꾸준히 접수되고 있다. 국내 업체를 겨냥한 리쿠베 악성코드에 대해 알아보자.
ELF 파일 형식인 리쿠베는 아키텍처가 x86, x64, 스팍(SPARC, 확장형 프로세서 아키텍처)인 것으로 보아, 주로 리눅스 서버를 공격 대상으로 삼는 것으로 추정된다. 하지만 공격자가 리눅스 시스템에 어떤 방식으로 리쿠베를 설치하고 있고, 공격 대상이 누군지에 대한 정보는 아직 정확히 알려진 바 없다.
깃허브(GitHub)에 공개된 오픈 소스인 타이니 쉘(Tiny SHell)의 소스 코드를 기반으로 제작된 리쿠베는 ‘타이니(Tiny)’라는 이름에 걸맞게 기본적인 기능만 지원한다. 프로세스 이름 변경과 같은 보조적인 기능을 제외하면 C&C 서버의 명령을 받아 다운로드, 업로드, 명령 실행 이 3가지 기능만 수행한다. 이 글에서는 일반적으로 알려진 리쿠베 유형들을 위주로 분석했다.
일반적으로 리눅스 서버를 노린 악성코드들은 부적절하게 관리되고 있는 서버나 최신 버전으로 업데이트하지 않아 취약한 서버를 대상으로 한다. 참고로 리쿠베의 공격자가 다수의 리눅스 서버에 스캐닝 및 브루트 포스(Brute Force) 공격을 한 사례는 확인되고 있지 않다.
이에 따라 취약한 계정 정보를 사용 중인 시스템보다도 주로 최신 업데이트를 하지 않았거나 부적절한 설정으로 서비스 중인 리눅스 서버가 공격 대상일 것으로 추정된다. 물론 유명 워드프레스 플러그인을 공격한 공격자가 감염 대상 시스템을 제어하기 위해 리쿠베를 설치하는 공급망 공격 사례도 확인된다.
리쿠베 분석
안랩 ASEC 분석팀은 국내에서 확인된 리쿠베 악성코드 중 하나를 분석했는데, 그 정보는 아래와 같다.
MD5: 8921942fb40a4d417700cfe37cce1ce7
C&C 서버: resolv.ctmailer[.]net:80 (103.140.186.32)
다운로드 주소: hxxp://103.140.186[.]32/mails
리쿠베는 실행 시 프로세스 이름을 정상 프로세스와 동일한 “/bin/bash”로 변경함으로써 사용자가 쉽게 알아채지 못하도록 한다. 이는 strcpy() 함수를 이용해 프로그램 실행 시 전달받는 인자를 변경하는 방식으로 구현돼 있다. 참고로 해당 부분은 타이니 쉘에서는 존재하지 않는 부분이다.
[그림 1] 변경된 프로세스 이름
타이니 쉘과 또다른 차이점이 있다면, C&C 서버의 주소나 비밀번호를 전달받는 커맨드 라인 옵션이 존재하지 않는다는 점이다. 해당 옵션이 존재하지 않기 때문에 C&C 서버의 주소는 [표 1]과 같이 하드코딩된 주소가 사용된다.
[표 1] 타이니 쉘의 실행 인자
[그림 2] 타이니 쉘과 리쿠베 간 비교
타이니 쉘 또는 리쿠베는 HMAC SHA1 알고리즘을 이용해 AES-128 키를 생성하며, 해당 키를 이용해 C&C 서버와의 통신 데이터를 암호화한다. 다음은 C&C 서버와의 통신 과정을 간략하게 정리한 내용이다.
A. C&C -> 클라이언트: HMAC SHA1 생성
먼저 C&C 서버로부터 0x28 사이즈의 데이터를 전달받는다. 이것은 2개의 0x14 바이트로 나뉘어 HMAC SHA1 컨텍스트 초기화 시 IV로 사용된다. 참고로 초기화 과정에서는 전달받은 각각의 0x14 바이트인 IV 외에도 하드코딩된 비밀번호 문자열인 “0p;/9ol.”도 함께 사용된다.
[그림 3] 키 생성에 사용되는 하드코딩된 비밀번호
생성된 HMAC SHA1 값들은 AES-128 키로써 각각 C&C 서버로 데이터를 전달할 때 암호화와 C&C 서버로부터 전달받은 데이터를 복호화하는데 사용된다.
B. C&C -> REKOOBE: 무결성 데이터
다음으로 C&C 서버로부터 0x10 바이트의 무결성 검증을 위한 데이터를 전달받는다. 리쿠베는 전달받은 데이터를 AES-128 키로 디코딩하며, 추가적으로 Xor 과정을 거치면 이후 전달받을 데이터의 사이즈를 얻을 수 있다. 이후 전달받을 데이터는 무결성 검증에 사용되는데, 0x10 바이트이면서 [그림 4]와 동일한 값을 가져야 한다. 참고로 해당 값은 타이니 쉘의 소스 코드에서 지정한 값과 동일하다.
[그림 4] 무결성 검증에 사용되는 데이터
C. REKOOBE -> C&C: 무결성 데이터
무결성 검증 과정이 끝나면 반대로 C&C 서버에 0x10 바이트의 동일한 무결성 데이터를 전송한다. 데이터를 보낼 때도 위에서 생성한 HMAC SHA1 값으로 생성한 AES128 키를 사용해 암호화해 전송한다.
[그림 5] 무결성 데이터를 C&C 서버로 전송
D. C&C -> REKOOBE: C&C 명령
E. C&C -> REKOOBE: 명령 별 추가 데이터
여기까지의 과정이 끝나면 C&C 서버로부터 1바이트의 명령을 전달받는다. 1바이트의 값에 따라 [표 2]처럼 파일 업로드, 파일 다운로드, 리버스 쉘(Reverse Shell) 3개의 명령을 수행할 수 있다.
[표 2] C&C 명령
[그림 6] C&C 서버와의 연결 및 명령 수행 루틴
명령 개수도 3개밖에 되지 않지만, 각각의 명령들 자체도 단순한 형태이다. 예를 들어, 파일 다운로드 명령, 즉 0x02를 전달받은 경우 다음으로 전달받는 패킷은 다운로드한 파일을 사용할 경로로, 해당 경로에 파일을 생성하고 파일의 실제 데이터를 쓰는 행위가 전부이다. 리버스 쉘 명령도 [그림 7]과 같이 표준 입출력을 C&C 서버에 대한 소켓으로 리다이렉트 시키고 /bin/sh을 실행하는 단순한 형태이다.
[그림 7] 리버스 쉘 명령
리쿠베 샘플의 특성
리쿠베는 최근에도 다수의 샘플들이 확인되고 있다. 안랩 분석팀은 최근 수집된 리쿠베 샘플들의 공통점과 차이점, 특징을 정리했다. HMAC SHA1을 기반으로 하는 AES128 암호화 알고리즘이 C&C 서버와의 통신에 사용된다는 점이나 파일 다운로드 및 업로드, 리버스 쉘 등을 지원한다는 점 등 기본적인 형태는 동일하다.
차이점으로는 대표적으로 C&C 서버와의 통신 방식이 있다. 위에서 다룬 리쿠베는 하드코딩된 C&C 서버에 먼저 접속하는 형태이지만, 바인드 쉘(Bind Shell) 형태로 포트를 오픈하고 C&C 서버의 접속을 기다리는 형태도 존재한다. 이는 타이니 쉘에서 2가지를 모두 지원하기 때문이다.
[[그림 8] 바인드 쉘 C&C 통신
리쿠베는 빌더가 따로 존재하는 것으로 추정된다. 위에서는 랜덤한 형태의 비밀번호 문자열이 사용됐지만, 디폴트 문자열로 보이는 “replace with your password”를 사용하는 악성코드들이 자주 보이는 것이 그 이유 중 하나이다. 즉, 각 악성코드들은 공격자가 공격을 수행할 때마다 비밀번호를 지정해 빌더로 생성한 것으로 추정된다. 매번 다른 문자열이 사용되는 비밀번호와 다르게, 무결성 검증에 사용되는 데이터는 반대로 대부분 소스 코드와 동일한 “58 90 AE 86 F1 B9 1C F6 29 83 95 71 1D DE 58 0D”이 사용된다는 점이 특징이다.
국내 업체 공격에 사용된 리쿠베 악성코드
다음은 국내 시스템들을 대상으로 하는 공격에 사용된 리쿠베 악성코드이다. 모두 x64 아키텍처인 것을 보면 리눅스 서버를 노린 것으로 보이며, 리버스 쉘 형태이다. [표 3]에서 mails와 service는 상대적으로 유사한 시기에 수집됐으며, 공격자가 지정한 비밀번호가 거의 동일한 것으로 보아 똑같은 공격자가 사용한 것으로 추정된다.
[표 3] 공격에 사용된 리쿠베 악성코드
정리하면, 리쿠베는 C&C 서버로부터 명령을 받아 악성 파일 다운로드, 시스템 내부 파일 탈취, 리버스 쉘과 같은 기능을 수행할 수 있는 백도어 악성코드로 정의할 수 있다. 리쿠베는 단순한 형태이지만 네트워크 패킷 탐지를 우회하기 위해 암호화를 사용하며, 공격자의 명령을 받아 다양한 악성 행위를 수행할 수 있다.
오픈 소스를 기반으로 하는 리쿠베는 이미 알려진 APT31 외에도 다른 다수의 공격자에 의해 사용될 수 있다. 최근까지도 국내 시스템의 리눅스 서버를 대상으로 한 공격 사례도 지속적으로 확인되고 있다.
이와 같은 보안 위협을 방지하기 위해서는 취약한 환경 설정이나 인증 정보를 검사하고, 관련 시스템들을 항상 최신 버전으로 업데이트해 공격으로부터 보호해야 한다. 또한, V3를 최신 버전으로 유지함으로써 악성코드 감염을 사전에 차단할 수 있도록 신경 써야 한다.
출처 : AhnLab
