BPFDoor 분석 및 실습

2025년 4월 SKT의 초대형 사고가 발생하면서, BPFDoor라는 악성코드에 대해 관심이 커지고 있다.

 

따라서, BPFDoor가 어떤 악성코드인지 간단히 분석해보며, 실제 공인 ip 환경에서 실습까지 진행해보려 한다.

 

이번 포스트에서는 BPFDoor를 실행시켜 시스템의 쉘을 획득하는 과정을 포함합니다.

이번 과정은 BPFDoor의 위험성을 이해하고자 정리된 내용이며 해킹을 장려하기 위한 글이 아님을 명시합니다.

해당 글로 인해 받은 모든 불이익은 당사자에게 모든 책임이 있음을 명심하시길 바랍니다.

 

1. BPF(Berkeley Packet Filter)란?

BPF(Berkeley Packet Filter)는 네트워크 패킷 필터링을 위해 개발된 메커니즘이다. 커널 영역에 설치되어 외부로부터 전달받은 패킷을 사용자 영역으로 넘길 것인지 결정할 수 있다.

1992년경에 개발되었으며 , 2014년에는 eBPF(extended BPF)가 리눅스 커널에 도입되었다. eBPF는 기존의 BPF보다 성능과 유연성이 향상되어 네트워크 패킷 필터링뿐만 아니라 성능, 보안성 및 안정성이 강화되었다. 

 

아래는 BPF 동작 과정을 간단히 그림으로 표현하였다.

출처 : copliot 

 

보통 패킷이 수신되면 커널 모듈 내에서 패킷에 대한 Reject, Accept 처리를 해야되다보니, 서버 내 자원 소모가 높아지며, 오류 발생 시 안정성이 상당히 떨어진다고 볼 수 있다.

 

이를 대안으로 만들어진 것이 BPF 메커니즘인데, 커널 내 가상머신에서 패킷 내부의 매직 바이트(Magic Byte)를 검사하여 수신할 패킷인지 처리한다.

또한, 커널의 모듈을 직접 로드하지 않고도, 모듈을 수정하거나 프로그램을 동작시킬 수 있으므로  서버의 자원을 크게 소모하지 않으며 서버의 안정성이 높아진다.

 

2. BPFDoor 개요

앞서 소개한 BPF의 편리한 기능으로 인해 악성코드로도 사용 되었는데, 내부에서 BPF 악성코드를 실행시키고 외부에서 매직 바이트를 포함한 정상패킷을 송신하면  내부 악성코드가 트리거되어 리버스 쉘, 바인드 쉘 등 공격 행위를 안정적으로 수행할 수 있다.

또한, 매직 바이트는 공격자가 설정할 수 있다보니, 외부 보안장비에서 탐지하기 어려우며, 서버 내부에서도 iptables, netfilter 등 모듈보다 BPF가 먼저 실행되기 때문에, 악성 코드가 실행된 이후로는 보안장비로 탐지하기 어렵다.

 

다만, 서버 내부에서 BPF에 사용되는 RAW_SOCKET 활성화 시 루트 권한이 필요하다. 따라서, BPFDoor는 초기 침투와 전혀 관련이 없으며 서버의 루트 권한 획득 이후 루트킷(rootkit) 툴로 활용되는 도구이다.

 

3. 실습

정확한 실습을 위해 외부의 웹 테스트 환경을 대상으로 수행했다.

 

실습용 악성코드는 아래 github에서 참고하여 사용했다.

https://github.com/gwillgues/BPFDoor 

GitHub - gwillgues/BPFDoor: BPFDoor Source Code. Originally found from Chinese Threat Actor Red Menshen

 

테스트 환경은 간단한 게시판 기능을 가지고 있는 웹 사이트며, 웹 쉘 업로드가 가능하므로 이를 통해 리버스 쉘 환경을 구축하였다.

 

 

서버 버전관리가 미흡한 점을 확인하여 CVE를 활용하여 root권한을 획득했다.

 

이 후 BPFDoor 악성코드를 대상 서버에 실행시키고, 본인 PC에서 매직 바이트가 포함된 패킷을 대상 서버에 전송하여 BPFDoor 악성코드를 통한 쉘 획득을 시도하였다.

(위의 공유드린 Github 코드 중 본인 PC의 IP/포트에 맞게 일부 수정하였으며, Magic Byte 패킷을 보내는 트리거 코드를 따로 구현하여 사용하였습니다.)

 

 

현재 일부 에러사항이 있어 이후 실습은 추후 업데이트 예정입니다.