여행하는 IT쟁이의 보안사건 노트 - 1.SKT USIM 정보 유출사건
안녕하세요, 이번에 새로 블로그 에디터로 시작하게 된 여행하는 it쟁이입니다. 대학생 이후로 줄글은 처음 쓰는 것 같네요. 오랜만에 쓴 글을 어떤 주제로 하면 좋을지 고민하다가 요즘 하루가 멀다하고 계속 뜨는 여러 기업들의 보안 사고에 대해서 자세히 공부해보며 정리해보면 좋을 것 같아 첫 주제는 보안 사고에 대한 글로 결정했습니다.
저는 보안/인프라 쪽 제품을 담당하는 엔지니어로서 일을 하고 있습니다. 직업 특성상 고객분들이 요즘 어떤 분야에 관심이 많은지가 체감이 빠르게 되는데, 요즘 고객분들은 확실히 보안쪽, 보안이라는 분야내에서도 정말 넓고 다양하게 관심을 가지시는게 느껴집니다. 그리고 관심을 가지시게되는 주요한 원인은 당연한 말이지만 사고가 났을 때 인 것 같습니다. 그래서 저도 다양한 보안 사고들이 왜 일어났고, 어떤 부분에서 일어났는지를 조금 더 공부해 어떤 부분에 있어서 걱정하시는지에 대해 파악해보고 싶어서 주제를 이렇게 정하게 되었습니다. 결국 일이랑 일맥상통하게 되는 주제네요..ㅎㅎ
첫번째 알아보고 싶은 사례는 올해 가장 많은 관심(negative..)을 받았던 SKT의 USIM 정보 유출 사건입니다. 처음에 SKT보안 사고가 났을 때 가장 언급이 많이 되었던 악성코드는 “BPFDoor”라는 악성코드입니다. BPFDoor는 이름에서도 알 수 있듯 BPF + Door, 즉 BPF를 통해 백도어를 만들어서 리눅스 시스템에 침투 할 수 있게 하는 악성코드입니다.
여기서 간단하게 BPF란 Berkely Packet Filter, 말그대로 커널 내에서 패킷을 걸러내는 필터입니다. 초기에는 주로 패킷 필터링만 했었는데 확장된 기술인 eBPF(extended BPF)를 통해 네트워크 뿐만 아니라 보안이나 모니터링 등 다양한 작업을 수행할 수 있게 확장되었습니다. BPF는 Linux커널의 일부로 공식적으로 도입되어있습니다.
BPF Door의 특징은 정상적인 프로그램인것처럼 이름을 바꿔서 잠복해있다가 매직 패킷이라는 특별한 신호가 오면 그때 활동을 시작합니다. 정상적인 프로그램인 것 처럼 이름을 바꿔서 하는게 굉장히 골때립니다. ‘kdmtmpflush’라는 파일이 BPFDoor의 복사본 파일 명인데, 리눅스 커널에 있는 가상화 관리 서비스 시스템인 kdm에서 사용되는 프로세스인 ‘kdmflush’파일처럼 위장을 합니다. 전 알고 봐도 뭐가 잘못된 이름인지 모를 것 같습니다. 그마저도 최신 변종은 이름하고 흔적도 제거한다고 합니다.
일반적인 악성코드는 방화벽을 통과하지 못하지만 BPFDoor는 커널레벨에서 직접 패킷을 확인하기 때문에 방화벽을 회피할 수 있습니다. 활성화가 되면, 감염된 컴퓨터에서 해커의 컴퓨터로 먼저 연결을 시도해서 문을 열어놓고(Reverse Shell), 그 문을 통해 해커가 들어오는 방식(Bind Shell)을 통해 들어오게 됩니다.
설명이 길었는데, 처음에는 사람들이 BPFDoor에 대한 관심이 엄청 많았습니다. BPFDoor는 어떻게 막아야 하는거지?하면서 엔드포인트 보안을 통해 커널 호출이나 파일접근 같은 행위를 바탕으로 이상행위를 탐지하는 방법들을 많이 이야기 했습니다. 근데 조금 더 거슬러 올라가면서 생각을 해보면 보다 더 근본적인 문제가 있습니다. 도대체 공격자는 저 서버에 어떻게 BPFdoor를 설치한걸까?
시간이 흐르고 SKT 공격자 침투 경로가 공개가 되었습니다.
외부 인터넷이 연결된 시스템 관리망 내의 한 서버가 CrossC2라는 악성코드에 감염됩니다. 감염된 서버 안에서 공격자가 여기저기 살펴보니 다른 서버들의 ID/PW정보들이 평문으로 저장이 되어있습니다. 이 계정정보를 가지고 공격자는 다른 서버로 접근합니다. 다른 서버로 가보니 음성통화인증 관리 서버에 대한 정보까지 있습니다. 공격자는 이렇게 서버를 타고 타고 핵심 시스템까지 접근해서 BPFDoor를 심었습니다.
결국 이 경로를 보게 되면, 몇가지 자세히 봐야할 점들이 있습니다.
- ID/PW정보들이 평문으로 저장되어 있었다.
도둑이 집에 들어와서 무언가를 훔치려고 하는걸 cctv로 보면서 잡아서 경찰에 신고할 수 있는 것도 중요합니다. 그런데 우리집 문 비밀번호 옆에 포스트잇으로 “우리집 비밀번호 1234임” 이렇게 붙어있어서 아무나 들어올 수 있다면 포스트잇을 먼저 떼야 되겠죠.
- Id/pw를 통해 서버들에 접근할 때 접근 통제가 이루어지지 않았다.
포스트잇을 제거했는데도 도둑이 집 비밀번호를 어찌저찌 알아내서 비밀번호를 치고 들어옵니다. 이때 만약에 우리가 지문인식을 같이 해야 들어오는 구조라던가, 아니면 가지고있는 스마트폰을 통해 코드를 입력해야 들어갈 수 있다던가 하면 비밀번호를 알아도 들어갈 수 없겠죠? 또한 비밀번호를 들어오는 사람들을 다 감시하고 녹화할 수 있는 인터폰같은게 있으면 최소한 누가 들어오려고 시도를 하고있는지 알 수 있습니다.
이러한 점들 말고도 다양한 부분들이 있겠지만, 과기부도 비슷하게 본 것 같습니다. 과기부에서도 SKT의 계정 관리 부실, 침해사고 대응 미흡, 정보 암호화 조치 부족 등을 주요 원인으로 지목했습니다.
결론은 보안사고를 자세히 보면 한가지 이유만으로 일어난 사고는 없는 것 같습니다. 악성코드 자체, 악성코드를 어떻게 심었는지, 어떻게 서버간을 왔다갔다 했는지 등등 모두가 원인입니다.
또한 한번 더 생각해 볼 부분은 보안은 해킹 사건 전 투자하는것이 사건 후 대응 및 복구에 드는 비용보다 저렴하다는 것입니다… 과징금만 1348억..
원래는 다른 사례들도 같이 써보려고했는데 생각보다 글이 길어져서 한가지 사례만 정리하는걸로 마무리하겠습니다. 기회가 되면 다른 사례들과 함께 돌아와 보겠습니다.