작년의 IoT(Internet of Things) 보안에 대한 기고에서는 일반적인 IoT 보안의 문제점에 대해서 알아보고, 그 대책에 대해서 생각해 보는 시간을 가졌습니다.

이번 시간에는 최근의 IoT 보안 취약점 보고 사례를 살펴보고, 보안 진단으로 출시 전 대응하는 방법을 소개해 드리겠습니다.

IoT 보안 취약점 보고 사례

2015년 화이트해커의 컨퍼런스인 BlackHat에서 한 연구원이 지그비(ZigBee)1 보안 결함을 발표하였습니다. 당시 해킹 대상이 된 IoT 디바이스로는 도어락, Smart 기기, 전구였고, 지그비라는 근거리 무선 프로토콜을 재접속 시에 암호화키 교환을 평문(Plaintext)2으로 하는 경우 짧은 시간이지만 키가 노출됐다고 합니다.

전파 방해 공격(Jamming)을 하게 되면 사용자가 다시 접속을 위해 페어링을 시도하게 되어 평문으로 키 교환 과정이 반복되므로 원할 때마다 공격을 시도할 수 있으며, 침입을 탐지했을 때 울려야 할 알람이 전파 방해 도구(Jammer)3로 인해 동작하지 않게 될 가능성도 있다고 설명했습니다.

2016년 2월에는 동일한 보안 결함이 포브스(Forbes) 지면에 게재되었습니다. 2015년 당시 발표된 Smart 기기의 결함을 수정하겠다고 한 기한이 넘어도 수정되지 않고 있어, 제조사의 패치를 촉구하기 위해 기사화한 것입니다. 언론의 주목을 받게 되자 제조사는 공식적인 대응에 들어갔습니다.

해당 이슈는 2015년부터 알고 있는 것이었으며 사용자가 Insecure Join(안전하지 않은 연결을 의미하는 지그비 프로토콜의 용어)이라는 기능을 On•Off 할 수 있게 선택권을 주었고, 전파 방해는 일반적인 상황으로 볼 수 없는 것이라고 약관에 명시해 놓았다는 것이었습니다. 덧붙여, 제조사는 지그비 표준화에 적극적으로 참여하고 있다고 강조했습니다.

다른 사례를 살펴보겠습니다. 가정에서 사용되는 홈 CCTV가 해킹되어 해커가 원격에서 이용자의 사생활을 감시할 수도 있다는 것입니다.

인증 과정 없이 서버에 접근하여 펌웨어(Firmware)를 다운로드하고, 스크립트를 변경 및 팩키징하여 감염된 공유기를 통해 댁내 홈 CCTV를 업데이트하면 원격에서 디바이스를 제어할 수 있다는 것입니다. 펌웨어는 Shift 연산 방식으로 암호화됐고(암호화 키가 사용되지 않고 암호문의 패턴이 노출되는 취약점이 있음), 위변조를 판별하기 위해 사용한 MD5(Message Digest 5의 약자로 취약한 알고리즘)가 사용되었습니다.

기밀성, 무결성, 가용성, 인증의 네 가지 요소 중 기밀성, 무결성, 인증에 허점이 있어 디바이스가 해킹될 수 있다는 것입니다.

① 출시 전 보안 진단

보안 취약점이 조기에 패치되지 않는다면 서비스를 제공하는 회사는 제품 출시일을 연기해야 하거나 이후 사고 발생 시 손해배상 등으로 금전적인 손실이 발생할 수 있습니다. 사고의 영향이 막대하거나 고의나 중과실이 있는 경우 CEO가 책임져야 할 수도 있습니다. 따라서, IoT 제품 및 서비스를 제공하는 회사는 출시 전부터 보안에 대한 대비를 하여 사고를 미연 방지 해야 합니다. 출시 가능한 수준으로 보안이 고려되었는지 확인하는 방법으로 IoT 보안 취약점 진단이 있습니다.

IoT 보안 취약점 진단은 디바이스에 대한 특화 진단이 포함됩니다. 그렇다고 해서 디바이스만 진단한다는 것은 아닙니다. 아래 그림과 같이 디바이스, 앱, 게이트웨이•네트워크, 서비스가 모두 진단 대상이 됩니다. 위협과 공격은 서비스 전 영역에서 발생할 수 있기 때문입니다.

각 영역의 상세한 체크 항목은 아래 표와 같이 IoT 보안, 스마트폰 앱 보안, Client•Server 보안, 클라우드 서버 보안으로 분류할 수 있습니다. 스마트폰 앱 보안, Client•Server보안, 서버 보안은 기존 IT 보안의 진단과 유사하므로, IoT 보안을 위주로 중요한 점검 과정을 설명하겠습니다.

② 서비스 영역 보안

서비스 영역에서는 디바이스 등록, 디바이스 및 사용자 인증, 권한 설정, 환경 설정의 이슈를 진단합니다. 디바이스에는 고유한 식별자가 부여되며 서비스 개통 전에 서버에 등록되어야 하고, 디바이스가 통신 시 인증과 권한 체크를 하게 됩니다. 진단 시에 이러한 일련의 흐름에 허점이 없는지 체크하는데, 앱과 서버 간, 서버와 디바이스 간, 앱과 디바이스 간 인증과 권한 관리 체계를 점검합니다.

전송 구간에 대한 암호화도 필요한데, 대표적으로 사용되는 SSL 암호화 적용 시 자주 발견되는 문제는 안전하지 않은 프로토콜의 사용, 상호인증 부재가 있습니다. 이러한 문제는 중간자 공격이나 암호문의 해독으로 중요한 정보가 해커에게 유출될 수 있는 위험이 있으므로, SSL 프로토콜 중 안전하지 않은 버전을 제거했는지 확인해야 하고, SSL 통신 시 클라이언트 역할을 하는 peer가 서버 역할을 하는 peer의 인증서를 검증하는지 확인해야 합니다.

③ 네트워크 보안

네트워크는 TCP•IP뿐 아니라 근거리 무선 네트워크도 포함됩니다. 다시 말해 블루투스, 지그비, Z-Wave, NFC가 사용되는 네트워크 보안도 점검 대상이라는 것입니다.

아래 그림은 블루투스 4.0(블루투스 저전력 에너지 표준) 방식의 패킷을 해커의 무선 장치가 수집하여 분석한 것으로, 블루투스 헤더에 포함되는 MAC 주소를 이용하여 개인의 위치를 추적할 수 있는지를 점검한 사례입니다.

블루투스 4.0 표준 프로토콜에는 고정 MAC 주소 외에 개인 정보 보호를 위하여 가변 MAC주소를 제공하는데, 대부분의 제조사에서는 고정 MAC 주소 방식으로만 진행하고 있어 프라이버시 보호에 미흡합니다.

④ 안전한 펌웨어 관리

디바이스에 탑재된 소프트웨어에 취약점이 발견될 경우 패치하기 위하여 제조사는 펌웨어 업데이트를 제공해야 하며, 펌웨어는 안전한 방식으로 업데이트 될 수 있어야 합니다. 진단자는 펌웨어 파일의 암호화 여부, 펌웨어 변조를 탐지하기 위해 전자서명이 추가되었는지 체크합니다.

전자서명이 누락된 경우 해커는 변조된 펌웨어를 디바이스에 업데이트하여 제어권을 획득할 수 있고, 디바이스가 해킹되면 사생활 침해(감시), 정보 유출, 2차 공격이나 심지어는 범죄(도어락 해제 후 도난 등)로 연결될 수 있습니다.

⑤ 소프트웨어 보안

디바이스의 소프트웨어는 부트로더, OS커널, 파일시스템, 데이터파일 등으로 구성되며, IoT 보안 진단에서는 부트로더 보안부터 점검하는 것이 특징입니다. 부트로더는 디바이스의 초기화와 커널 로딩을 담당하는데, 초기화 과정을 변조할 수 없도록 설정해야 하며, 아래 그림은 U-Boot라는 부트로더의 환경변수를 임의로 변조할 수 있는지 확인하는 것을 보여줍니다.

⑥ 암호화 저장

암호화는 기밀성을 달성하는 데 중요한 역할을 합니다. 진단은 암호화 키를 안전하게 생성하여 이용하는지, 저장 시 안전한 암호화를 적용했는지 저장소가 안전한지를 봅니다. 암호화 키가 안전하게 관리되지 않는다면 암호문이 해독될 수 있습니다.

아래의 화면은 디바이스에 저장된 RSA(Rivest Shamir Adleman)4 개인키가 평문으로 노출되어 이를 이용한 기밀성, 무결성, 인증 체계가 안전하지 않다는 것을 보여준 사례입니다.

⑦ 하드웨어 설계•제조 보안

디바이스의 하드웨어 안전성 점검은 하드웨어 분해의 용이성과 디버그 포트의 접근 가능성을 기준으로 점검합니다. 디버그 포트의 예로는 UART(범용 비동기화 송수신기)5와 JTAG(Joint Test Action Group, 임베디드 시스템 개발 시에 사용하는 디버깅 장비)가 있습니다.

이 포트가 물리적으로 노출되었는지, 송수신 신호가 활성화되어 있지는 않은지, 활성화되어 있다면 중요한 정보를 획득할 수 있는지, 특권 명령어를 실행하거나 펌웨어 획득이 가능한지 점검합니다. UART의 허점을 악용하면 중요 정보가 해커에게 노출될 수 있습니다.

최근 취약점 보고 사례 및 IoT 보안 진단의 중요 항목을 살펴보았습니다. IoT 보안은 디바이스, 앱, 네트워크, 서버를 범위로 하는 융합보안으로 전 영역의 점검이 되어야 합니다.

이 중 디바이스 영역은 서비스 보안, 네트워크 보안, 펌웨어 관리, 소프트웨어 보안, 암호화, 하드웨어 설계•제조 상의 보안을 점검합니다.

점검 및 발견된 취약점이 출시 전에 패치된다면 안전한 IoT 서비스가 운영되어 고객의 신뢰를 받을 수 있을 뿐 아니라 국가•사회적인 실패 비용 지출도 감소할 것입니다.

글 | LG CNS 보안컨설팅팀

[‘보안, 이렇게 하면 된다’ 연재 현황]

• [1편] ISMS 의무인증 대상 확대! 어떻게 대응해야 할까?
• [2편] ISMS 인증을 위한 보안솔루션 구성 방안
• [3편] ISMS 인증 주요 결함사항 및 대응방안
• [4편] 정보보호 관련 인증 및 평가 제도
• [5편] 스마트폰의 보안 위협과 대응 방안
• [6편] IoT 보안 취약점 사례 소재 및 취약점 진단
• [7편] 스마트폰 앱 서비스 보안의 현재와 미래
• [8편] 중국 개인정보 보호법 제도 동향 및 대응방향
• [9편] 출입 보안을 위한 보안 설계
• [10편] 소프트웨어 개발 보안 – 시큐어 코딩
• [11편] 당신의 출입카드는 안녕하십니까?
• [12편] 통합 보안 관리 동향 및 활용 방안
• [13편] 비대면 실명인증이란 무엇인가?
• [14편] 프로젝트에서 소스 코드 보안 점검하기
• [15편] 차세대 행위 기반 위협 탐지 방식에 관하여
• [16편] 핀테크 보안 위협과 대응 방안
• [17편] 인공지능과 보안
• [18편] ‘보안은 제품이 아니라 절차다!’라는 말의 의미
• [19-1편] 인증의 완성판 생체인증에서 다중 생체인증까지 ①
• [19-2편] 인증의 완성판 생체인증에서 다중 생체인증까지 ②
• [20-1편] 중국 네트워크 안전법 분석 및 대응 방안 ①
• [20-2편] 중국 네트워크 안전법 분석 및 대응 방안 ②
• [21편] 유전자 정보 보안 안전한가?