측면 이동 공격에 취약한 Linux

이 블로그 게시물은 Linux 해킹 방법을 알리는 것이 아닌, 네트워크 보안팀 직원에게 네트워크에 영향을 미칠 수 있는 잠재적 위협에 대한 정보를 제공하는 데 목적이 있습니다.

이 포스트에서 다루는 모든 프로토콜은 아니지만 대부분의 프로토콜은 바로 사용할 수 없고, 특정 방식으로 설정해야 측면 이동이 가능합니다. 본 게시물에서 다루는 프로토콜을 남용하는 방법에 대해서는 설명하지 않습니다.

기타 프로토콜은 공격자가 악용할 수 있는 취약한 하부 구조의 역할을 할 수 있기에, 이에 대한 경각심을 높이고자 합니다. 집요한 해커라면 이 게시물에서 다루는 프로토콜을 찾아내 악용할 수 있기 때문에, Akamai는 방어자가 이에 대비할 수 있기를 바랍니다.

보안팀 직원에 더욱 강력한 지원을 제공하기 위해 Akamai는 Infection Monkey 팀과 협력했습니다. Infection Monkey는 오픈 소스 자동 유출 및 공격 플랫폼으로서 사용자의 네트워크를 대상으로 여러 가지 일반적인 측면 이동 및 네트워크 전파 기법을 테스트합니다. 

개발 팀은 Akamai의 리서치 결과를 바탕으로 이를 새로운 악용 기법으로서 툴에 반영했습니다. 보안팀 직원은 네트워크를 대상으로 Infection Monkey를 사용해 이 게시물에서 언급된 원격 실행 기법을 테스트할 수 있습니다.

[참고: 이 섹션에서는 흥미로운 측면 이동 표적을 찾는 데 사용한 방법을 설명합니다. 방법론보다는 바로 실행하는 데 관심이 있다면 즉시 코드 실행을 허용하는 프로토콜로 건너뛰세요.]

Akamai는 측면 이동 프로토콜과 서비스를 찾고 있었던 만큼, 잠재 후보를 찾는 데 있어 OS 측면과 네트워크 측면을 모두 고려할 수 있습니다. 즉, Linux 머신에서 가장 일반적인 프로세스나 가장 일반적인 수신 포트를 살펴볼 수 있습니다. 동일한 프로토콜이 다르게 구축되거나(다른 프로세스 이름, 동일한 포트), 포트가 여러 개인 혹은 변경되는 단일 프로세스(예: RPC의 임시 포트)가 있을 수 있으므로 어느 한 쪽을 무시하고 다른 쪽에만 집중해서는 안 됩니다.

Linux 머신과의 통신에 가장 많이 사용되는 포트를 살펴봤더니 결과적으로는 SSH(포트 22)가 가장 많이 사용되었지만 FTP (포트 21), SNMP (포트 161), Sun RPC (포트 111) 등 조사해 볼만한 다른 유망한 후보들도 있었습니다. 

또한 SSH와 관련이 없는데도 sshd (SSH 데몬 프로세스)가 처리하는 포트가 몇 개 있습니다. 이러한 포트는 SSH 터널에서 사용되므로 조사 범위를 벗어난다고 가정합니다. 

예를 들어 Windows에서 각각 RPC와 WinRM에 사용되는 포트 135와 포트 5985를 살펴보겠습니다. 특히 sshd 가 수신 대기 중인 Linux 머신에서는 이러한 포트를 사용할 수 없습니다. 외부에서 내부 머신에 접속하는 데 사용할 수 있는 Linux 머신에는 SSH 터널이 열려 있을 가능성이 높습니다. SSH 터널은 트래픽을 다른 수신자에게만 리디렉션하므로 터널 호스트로의 측면 이동을 고려할 때 별로 중요하지 않습니다.

조사 결과 중 두 가지 흥미로운 프로세스가 눈에 띄었는데, 바로 xinetd 와 rpcbind입니다. 이 프로세스는 많은 기능을 제공하지 않기 때문에 측면 이동 표적으로는 사용될 수 없으며, 주로 통신과 포트를 다른 프로세스에 매핑하기 위한 조회 작업에 사용됩니다. 대신, 다른 흥미로운 서비스를 찾는 데 사용할 수 있습니다.

xinetd (및 이전 모델인 inetd)는 데몬을 제어하고 관리하는 데 사용됩니다. 이것이 관리하는 데몬의 기본 목록을 보면 rexec는 물론 rlogin 과 rsh도 있으며 이들은 모두 Berkeley r-명령 에 포함되어 있습니다. 또한 다양한 FTP 데몬, VNC , Telnet도 찾을 수 있습니다.

rpcbind 는 Sun RPC용 RPC 포트매퍼 프로세스입니다. RPC 서버는 포트매퍼에 등록되며 클라이언트는 포트매퍼에 쿼리해 서버의 임시 포트를 찾을 수 있습니다. MS-RPC와 달리 Sun RPC는 특정 RPC 서버를 식별하기 위해 프로그램 번호를 사용하며, 이 번호는 IANA (Internet Assigned Numbers Authority)에 등록되어 있습니다. 등록된 프로그램을 보면 rexec 와 NFS도 있는 것을 알 수 있습니다.

테스트 대상 Linux 머신 중 24%

SNMP의 기본 제공 기능에 관계없이 일부 공격자는 라우터와 IoT 디바이스의 SNMP 구현 취약점을 활용해 네트워크를 침해하기 때문에 공격자의 표적이 되기도 합니다. SNMP의 남용은 CISA(Cybersecurity & Infrastructure Security Agency)가 프로토콜에 대한 권고안을발표할 정도로 상당한 수준에 이르렀습니다.

이 위협에 대한 테스트를 돕기 위해 Akamai는 Infection Monkey 팀과 협력해 SNMP 원격 EXTEND 플러그인용 악용 플러그인을 개발했습니다. Infection Monkey를 실행하면 사용자 환경 내에서 이 공격이 어떻게 보이는지 확인하고 보안 체계가 공격을 방어하기에 충분한지 확인할 수 있습니다. SNMP 공격은 최신 Infection Monkey 릴리스 v2.2.1에서 확인 가능합니다.

테스트 대상 Linux 환경 중 10%

이번에는 Microsoft 독점 원격 데스크톱 프로토콜인 RDP에 대해서는 구체적으로 언급하지 않겠지만, 곧 다룰 예정이니 걱정하실 필요는 없습니다. Linux 머신에서는 그밖에 다른 원격 데스크톱 프로토콜도 실행할 수 있습니다. 그러나 이는 그래픽 데스크톱을 공유하기 위한 것이며 대부분의 Linux 서버는 데스크톱 환경 없이 설치되기 때문에, Windows 환경에 있을 때보다 훨씬 찾아보기 힘듭니다. 

그렇지만 몇몇 네트워크에서 이러한 프로토콜이 사용되는 것을 확인했기 때문에 목록에 포함시켰습니다.

• X Window 시스템은 Unix에서 사용할 수 있는 데스크톱 Window 시스템으로, 원격 연결을 수신 대기할 수도 있습니다. TCP 포트는 6000+를 사용합니다. 포트 6000부타 시작하지만, 이후에 실행되는 각 데스크톱 서버마다 포트 번호가 증가합니다.

• VNC는 RFB(Remote framebuffer) 프로토콜을 기반으로 하며 TCP 포트 5900+를 사용합니다(포트 번호는 X와 마찬가지로 데스크톱 서버가 실행될 때마다 증가).

• Xrdp는 Windows가 아닌 머신에서 사용할 수 있는 Microsoft RDP 프로토콜을 구축한 것입니다. RDP를 구축했으므로 포트 3389를 사용합니다.

원격 데스크톱 프로토콜 중에는 다른 프로토콜보다 더 안전한 것들도 있지만, 모두가 공격자에게 악용될 가능성이 있습니다. 또한 Linux에는 여러 개의 프로토콜이 구축되어 있으므로 여기서는 프로그램 이름 대신 포트 번호를 포함시켰습니다.

테스트 대상 Linux 환경 중 4%

SSH 및 rlogin과 마찬가지로 Telnet도 원격 콘솔 및 제어용 프로토콜입니다. 또한 rlogin처럼 안전하지 않고 암호화되지 않았으며 가로채기나 패킷 스니핑 공격에 취약합니다. 이는 조사 대상 네트워크 중 약 4%에서만 발견되었으나 여전히 사용되고 있으며 네트워크에 영향을 미칠 수 있습니다. 프로토콜은 TCP 포트 23이나 2323을 사용합니다.

테스트 대상 Linux 환경 중 1%

Berkeley r-명령은 네트워크의 여러 머신에서 원격 작업을 수행할 수 있는 프로그램 모음입니다. 원래 BSD의 일부로 개발되었지만, 대부분 해당 프로토콜의 보안 문제(암호화 및 최소한의 인증이 없거나 아예 없음)로 인해 SSH로 대체되었습니다. 

하지만 여러 곳에서 몇 가지 데몬이 발견되었기 때문에 완전히 배제하기는 아직 이릅니다. 다음과 같은 세 가지 데몬을 주로 살펴보려 합니다.

1. rexec — 원격 명령 실행을 제공하고 TCP 포트 512를 사용합니다

2. rlogin — 원격 로그인 및 콘솔을 제공하고 TCP 포트 513을 사용합니다

3. rsh — rexec과 비슷하지만 인증이 필요하지 않으며 TCP 포트 514를 사용합니다

원격 제어나 실행을 직접 허용하지 않더라도, 표적 머신으로 파일을 전송하는 기능만 있으면 공격 개발에 큰 도움이 됩니다. 일례로 Windows 기반이면서도 일반적인 측면 이동 기법이자 툴인 PsExec을 살펴보겠습니다.

먼저 SMB를 통해 서비스 바이너리를 표적 머신에 복사한 다음, 서비스 관리자와 원격으로 통신해 서비스를 실행합니다. 따라서 공격자 툴과 바이너리가 표적 머신에 배치될 수 있도록 다양한 방법을 매핑하는 것도 중요하다고 생각합니다. 또한 원격 실행을 위해 툴 전송을 악용하는 몇 가지 방법에 대해 이론을 정립했으며, 이에 대해서는 게시물의 뒷부분에서 자세히 설명하겠습니다.

테스트 대상 Linux 환경 중 31%

FTP(File Transfer Protocol)는 가장 고전적인 프로토콜 중 하나입니다. 네트워킹 수업에서 가장 먼저 배우는 애플리케이션 계층 프로토콜이기도 하죠. 파일 전송에 사용되는 이 프로토콜은 텍스트 기반 프로토콜로, 평문을 사용하기 때문에 안전하지 않습니다.

테스트 대상 Linux 환경 중 20%

테스트 대상 Linux 환경 중 18%

NFS(Network File System)는 파일 서버를 생성하는 또 다른 방법입니다. Sun RPC(TCP 포트 111)를 통해 구축됩니다. 살펴볼 수 있는 RPC 함수는 많지만, 이를 통해 원격 명령을 실행할 수 있는 즉각적인 방법은 찾지 못했습니다.

테스트 대상 Linux 환경 중 16%

rsync는 네트워크의 머신 간 파일 전송과 동기화를 위한 유틸리티입니다. 서비스 또는 데몬으로 실행할 수 있으며 전용 프로토콜(TCP 포트 873), rsh 또는 SSH를 통해 파일을 지원할 수 있습니다.

파일 전송에 대해서도 충분히 논의할 수 있지만, 공격자가 전송된 파일을 어떻게든 실행할 수 없다면 그다지 유용하지 않습니다. 사용자가 직접 파일을 실행하도록 속이는 것 외에 생각해볼 수 있는 두 가지 실행 방법이 있는데, 이를 위해서는 일종의 잘못된 설정 또는 심각하게 느슨한 보안 설정이 필요합니다.

Linux 파일 시스템에는 지속성을 확보할 수 있는 정상적인 위치가 여럿 있지만, 측면 이동의 경우 /etc/cron.hourly에 집중하겠습니다. 공격자가 일단 이곳에 실행 권한이 있는 파일을 업로드할 수 있다면, 다음에는 파일 실행을 유도하여 오랫동안 원하던 측면 이동에 성공할 수 있습니다.

그러나 이를 위해서는 공격자가 쉽게 얻을 수 없는 sudo나 root 권한이 필요합니다. 안타깝게도 파일 서버를 안전하지 않은 방식으로 설정할 경우, 이러한 상황이 발생할 수 있습니다(예: rsync참조). 보안 기능이 거의 없는 서비스를 설정하는 이유는 무엇일까요? 여러모로 간편하기 때문입니다. 간편한 방법에 집중하기보다는 스스로 보호하는 게 중요합니다.

/etc에 접속하는 대신, 활성 웹 서버의 웹 루트 폴더에 원격으로 접속하는 것이 훨씬 더 그럴듯해 보입니다. 이 경우 사용자 지정 웹 셸을 업로드하고 이를 사용해 원격 명령을 실행할 수 있어야 합니다. 온라인에서는 웹 쉘의 예 를 쉽게 찾아 볼 수 있어, 공격자가 직접 개발할 필요도 없습니다.

최근 몇 년 동안 점점 인기를 끌고 있는 또 다른 측면은 컨테이너입니다. Akamai 리서치에서는 컨테이너 프로그램이 연결을 수신하고 수락하는 여러 사례가 관찰되었으며, 이는 설계를 통해서도 허용되는 것으로 보입니다. 공격자가 원격 컨테이너 관리자에 접속할 수 있다면 악성 이미지를 업로드하고 이를 사용해 네트워크 내부로 전파할 수 있습니다.

이와 같이 공격자가 머신에 침입할 수 있는 잠재적인 방법들을 살펴봤습니다. 이제 이를 차단하는 방법에 대해 논의해 보겠습니다.

이미 언급했듯이, 여기서 설명한 프로토콜 중 어느 것도 Linux와 함께 설치되고 설정되어 바로 사용할 수 있는 것은 없습니다. 누군가 직접 설치하는 과정이 필요합니다. 따라서 ‘적을 알고 나를 알지 못하면 전투에서 승리할 수 없다’는 손자의 말처럼, 먼저 네트워크에서 무엇이 실행 중이고 통신 중인지(또는 통신을 위해 수신 중인지) 파악해야 합니다.

네트워크 인벤토리를 작성하고 여기에서 설명한 서비스 중 하나를 확인했다면 해당 서비스의 설정을 확인해야 합니다. 예를 들어, Kerberos 인증과 함께 SNMPv3를 사용하도록 설정된 최신 SNMP 에이전트는 아무런 문제 없이 완벽하게 작동합니다. 쉽게 추측할 수 있는 커뮤니티 스트링이 포함된 SNMPv2는 어떨까요? 그렇지 않습니다.

다른 프로토콜이나 서비스는 r-명령이나 Telnet 대신 SSH를 사용하는 것처럼 보다 안전한 최신 프로토콜로 대체할 수 있을 것입니다. FTP나 rsync 같은 일부 프로토콜도 SSH를 통해 캡슐화하여 SSH가 제공하는 암호화 기능의 추가적인 장점을 누릴 수 있습니다. 물론 쉽게 해독할 수 없는 PKI나 강력한 비밀번호를 사용해 SSH가 올바르게 설정되었는지 확인하는 것도 중요합니다.