SKT 유심 해킹 분석

 

01. 사고 타임라인

 이 과정에서 SKT 해킹 정황을 인지하고도 신고를 늦게 하였는데 해킹 인지 시점으로 41시간이 지난 뒤에야 정부 당국에 침해 사실을 신고했다. 정보통신망법에 따라 정보통신 서비스 제공자는 침해 사고의 발생을 아렉 된 떄부터 24시간 이내에 과학기술 통신부 장관 또는 KISA에 신고해야 하므로 법 위반에 해당한다. 

 

02. 정부 조사 결과 

 과학기술정보통신부(이하 과기정통부)는 4월 29일 민관합동조사단의 1차 조사 결과를 발표했다. 공격 정황이 있는 3종, 5대 서버를 조사한 결과, 유출된 정보는 전화번호, IMSI 등 유심 복제에 활용될 수 있는 정보 4종과 유심 정보 처리 등에 필요한 SKT 관리용 정보 21종이었다. 일단 IMEI가 유출되지 않은 것으로 확인되면서 유심을 복제해 다른 휴대전화에 꽂아 불법 행위를 하는 ‘심 스와핑(SIM Swapping)’ 공격 가능성은 현저히 낮아졌다.

조사단은 침투에 사용된 BPF도어(BPFDoor) 계열의 악성코드 4종도 발견했다.또한 추가 조사 과정에서 추가로 드러난 8종의 악성코드 역시 기존 공격받은 서버에서 발견된 것으로 파악됐다.
그러나 지난 19일 발표된 2차 조사 결과에 따르면 당초 예상보다 피해 규모가 더 커질 가능성도 있다. 우선 악성코드에 감염된 서버는 5대에서 18대가 늘어난 총 23대로 집계됐다. 조사단은 이 중 15대에 대한 정밀 분석을 완료했으며 나머지 8대에 대한 분석을 진행 중이다. 서버에서 발견된 악성코드도 25종까지 늘어났다. 현재까지 발견된 악성코드는 BPF도어 계열 24종과 웹 셸 1종이다. 유출된 유심 정보의 규모는 9.82기가 바이트(GB)로, IMSI 기준 2,695만 7,749건이다. 이는 SKT 이용자와 알뜰폰 이용자 수를 합친 2,500만 명을 웃도는 수치로, 여기에는 스마트 워치 등 각종 단말기에 탑재된 유심 정보와 유효하지 않은 유심 정보까지 포함된 것으로 추정된다.

정밀 분석을 완료한 서버 가운데 IMEI와 개인정보를 저장한 서버 2대가 확인되면서 2차 피해에 대한 우려가 커지고 있다. 이 서버는 통합고객인증 서버와 연동되어, 고객 인증을 목적으로 호출된 IMEI와 이름, 생년월일, 전화번호, 이메일 등 다수의 개인정보를 저장한다. 조사단은 해당 서버에서 일정 기간 임시 저장되는 파일에 총 29만 1,831건의 IMEI가 포함된 사실을 확인했다. 방화벽 로그 기록이 남아 있는 지난해 12월 3일부터 올해 4월 24일까지는 자료 유출이 없었다.

 

03. BPFDoor 악성코드 분석

 

3.1. BPF(Berkeley Packet Filter)

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

 

3.2. BPFDoor

 BPFDoor는 앞서 설명한 BPF, 그 중 과거 버전의 cBPF 기술을 악용하는 리눅스 백도어 악성코드다. BPFDoor는 패킷 필터링 규칙을 추가하여 매직 패킷이라 불리는 공격을 위해 조작된 특정 패킷이 수신되었는지 검사한 후에 상응하는 행위를 수행한다. 이 악성코드는 포트를 열지 않고도 외부명령을 수신할 수 있도록 BPF를 활용하며 일반적인 네트워크 보안 솔루션으로는 쉽게 탐지 되지 ㅇ낳는다

BPFDoor는 서버 방화벽과 보안 시스템을 우회하며, 외부 공격자가 직접 시스템에 명령을 전달할 수 있는 리버스 쉘, 바인드 쉘 등의 기능을 제공한다.

• 바인드 쉘: 공격 대상 시스템이 특정 포트를 열고 외부로부터 연결을 기다리는 형식으로 공격자가 열린포트로 직접 연결하여 쉘을 얻는다.
• 리버스 쉘: 클라이언트가 서버를 열고, 서버에서 클라이언트 쪽으로 접속하는 형태이다. 리버스 쉘을 사용하는 이유는 방화벽 떄문인데, 주로 방화벽은 외부에서 내부로 들어가는 연결(인바운드)은 막지만 내부에서 외부로 나가는 연결(아웃바운드)은 막지 않기 때문이다. 

 

3.3. 주요 특징

• 리스닝 포트 없음: 외부에 노출되는 포트 없이 통신
• 파일리스(fileless) 실행: 디스크에 흔적 없이 실행
• BPF 기반 패킷 필터링: 커널 수준에서 특정 패킷만 수신
• RC4 암호화 통신
• iptables 규칙 조작으로 포트 리디렉션
• 시스템 데몬 이름으로 프로세스 위장

 

3.4. 내부 동작 원리

1. 설치 및 은폐
   • 루트 권한 획득 후 /dev/shm 경로에 자신을 복사하고 실행
   • 원본 바이너리는 즉시 삭제
   • 프로세스 이름은 systemd, dbus-daemon, hald-runner 등으로 위장
   • var/run/haldrund.pid 파일을 생성하여 중복 실행 방지
   • 파일 타임 스탬프를 2008년 등 과거로 설정
2. 패킷 필터링 및 대기
   • 커널에 BPF 필터를 등록해 매직 패킷만 수신
   • PF_PACKET 소켓을 통해 raw 패킷 캡쳐
   • 매직 패킷 식별자
     • TCP: 0x5293
     • UDP/ICMP: 0x7255
3. 명령어 처리 로직
   • 매직 패킷 내에는 암호, 명령, 코드, 포트 등이 포함 됨
   • 명령 유형
     • 0: reverse shell (공격자 IP로 연결)
     • 1: bind shell + iptables 리디렉션
     • 2: 감염 여부 확인 (응답으로 1 전송)
4. RC4 암호화
   • 모든 명령와 셸 세션은 RC4 알고리즘으로 암호화
   • 키는 매직 패킷내 암호값으로 초기화 됨
5. iptables 조작
   • 공격자 접속을 위해 임시로 PREROUTING 및 INPUT 체인에 규칙 추가
   • 세션 종료후 자동으로 규칙 제거

 

3.5. 탐지 기법

1. 호스트 기반 탐지
   • /dev/shm 경로에서 실행중인 바이너리 확인
   • /proc/<pid>/exe 링크가 deleted 상태이거나 환경 변수가 비어있는 경우
   • ss -af packet 또는 lsof 를 이용한 패킷 소켓 탐지
   • /proc/<pid>/stack에서 packet_recvmsg등 커널 함수 확인
   • 메모리에서 justforfun, socket, haldrund.pid 등의 문자열 탐색
2. 네트워크 기반 탐지
   • 매직 패킷을 보냈을 때 1 응답을 받는지 여부로 감염 테스트
   • 비정상적인 1 byte UDP 응답 트래픽
   • 특정 IP 에서만 접속 가능한 포트 리디렉션 패턴
   • snort/suricata 로 커스텀 룰 작성 가능
3. 기타 아티펙트
   • /var/run/haldrund.pid 파일 존재 여부
   • iptables -t nat -L -n 출력에 공격자 IP 기반의 리디렉션 규칙
   • audit 로그에서 /dev/shm 경로 실행, unlink, execve, prctl 호출 추적

 

3.6 대응 및 방어 전략

1.  사전 차단
   • 커널 설정: kernel, unprivileged_bpf_disabled=1
   • SELinux/AppArmor로 raw socket. bpf 호출 제한
   • seccomp profile로 setsockopt, socket 제한
2. 시스템 하드닝
   • 불필요한 BPF 사용 차단
   • auditd 활성화 및 /dev/shm, iptables 조작 syscall 기록
   • etc/rc.local, systemd 등에서 자동 실행 설정 여부 점검
3. EDR/XDR 솔루션 활용
   • AnnLab, Qualys 등 EDR에서 관련 행위 탐지 룰 제공
   • EDR에서 /dev/shm 경로 실행 및 iptables 삽입 시 경고 설정

 

 

 

출처 https://www.igloo.co.kr/security-information/skt-%EC%9C%A0%EC%8B%AC-%ED%95%B4%ED%82%B9-%EC%82%AC%EA%B3%A0-%EB%B0%9C%EC%83%9D-%EC%9B%90%EC%9D%B8%EA%B3%BC-%ED%8C%8C%EC%9E%A5%EC%9D%80/ https://www.ahnlab.com/ko/contents/content-center/35830