Home

IoT 헬스케어 기기는 일반적으로 사용자의 생체신호를 측정하고 이를 게이트웨이에 전송하는 것을 목적으로 한다. 그림 1에서 보듯이 게이트웨이는 IoT 헬스케어 기기에서 측정한 정보를 가공하고 환자 정보 등 기타 정보를 추가하여 개인 건강 기록 형태로 서버나 클라우드에 저장한다. IoT 헬스케어 기기가 측정한 사용자의 생체 신호 전송은 일반적으로 블루투스나 WiFi 등 근거리 무선 통신을 통해 이루어진다. IoT 헬스케어 기기는 휴대형, 착용형, 삽입형 등 다양한 형태로 사용자와 가까운 거리를 유지하며 사용 편의성을 위해 소형화 및 경량화를 지향하게 되고, 이 과정에서 기기는 게이트웨이에 비해 비교적 작은 컴퓨팅 자원을 가지게 된다. 일반적으로 이 모델에서 IoT 헬스케어 기기는 필요성과 성능상의 한계를 고려하여 그 자체가 환자의 개인 정보나 인증서 등 민감한 정보를 가지지 않고 게이트웨이에서 민감 정보를 관리하게 된다. 따라서 IoT 헬스케어 기기에서 게이트웨이를 거쳐 서버 쪽으로 갈수록 정보의 중요성이 커지고 기기의 성능도 증가하며, 그 결과 더 강한 보안과 개인 정보보호가 요구 및 적용 되고 있다.

Fig. 1. 
IoT healthcare service model

IoT 헬스케어 기기의 소형화 과정에서 USB 포트 등 외부 기기와 연결하는 유선 인터페이스는 제거될 가능성이 크고, 디스플레이나 버튼과 같은 사용자와의 상호 작용을 위한 인터페이스 역시 최소화된다. 이러한 이유로 IoT 헬스케어 기기의 소프트웨어를 업데이트하거나 설정 변경 등을 수행할 때는 외부 기기에서 무선 통신으로 연결되어 원격에서 유지 보수 작업이 이루어지는 경우가 많으며, 이 방식은 비교적 작지만 다수의 전문화된 센서나 기기들이 상위 기기에 연결되어 동작하는 IoT 헬스케어 서비스에 특히 유용하다.

표 1은 업데이트 방법에 따른 주요 차이점과 장단점을 보인다.

버그 수정, 기능 개선을 위해 IoT 헬스케어 기기의 소프트웨어를 업데이트하는 방법은 크게 유선 인터페이스 또는 무선 인터페이스를 이용하는 방법으로 구분할 수 있으며, 경우에 따라서는 유지 보수를 위한 인터페이스가 존재하지 않을 수도 있다.

USB나 Serial 등 유선 인터페이스를 사용하는 경우에는 주로 전문가에 의해 업데이트가 이루어지며 많은 기기를 일일이 업데이트해야 하기 때문에 많은 시간과 비용이 소모되고 사용자가 업데이트를 위해 서비스 센터에 기기를 위탁하는 절차가 필요하므로 업데이트 적용률이 낮은 편이다. 그러나 내부자가 소프트웨어를 유출 시키지 않는다면 비교적 보안성이 높고 해킹 공격 역시 개별 기기에 한정되기 때문에 안정성도 높다는 장점이 있다.

반면에 Bluetooth, WiFi 등 무선 인터페이스로 OTA 프로그래밍 업데이트 방식을 사용하는 경우에는 중앙 관리 시스템 또는 중앙 관리 시스템의 요청을 받은 게이트웨이에서 개별 기기에 새로운 소프트웨어를 자동으로 업데이트할 수 있다.

그림 2는 OTA 업데이트 개요를 설명하고 있으며 IoT 헬스케어 기기에 네트워크로 연결된 중앙 관리 시스템이 직접 업데이트를 수행하거나 게이트웨이에 업데이트할 소프트웨어를 전달하고 명령하여 대신 수행하게 할 수도 있다. OTA 업데이트 방식을 사용할 경우 업데이트에 적은 비용과 시간이 소모되며 편의성도 높고 업데이트 적용률도 높다. 특히 IoT 헬스케어 기기는 사용자로부터 수집한 건강 관련 기록들을 게이트웨이를 통해 서버에 전송하기 때문에 구조상 OTA 업데이트 모델을 적용하기 쉽다.

Fig. 2. 
OTA update model

그러나 IoT 헬스케어 기기와 중앙 관리 시스템 또는 게이트웨이 간 보안 정책에 따라 상이한 보안성을 가지며 소프트웨어나 업데이트 프로토콜이 유출될 경우 이를 악용하여 다수의 기기들이 공격받을 수 있다.

상황에 따라 IoT 헬스케어 기기가 업데이트를 위한 인터페이스 및 기능을 지원하지 않을 수도 있는데, 이 경우 소프트웨어가 유출될 가능성이 매우 적고 기기에 악성 소프트웨어를 설치하기가 사실상 불가능해 보안성은 매우 뛰어나지만 기기의 오류 수정이나 새로운 기능을 제공할 수 없어서 유연성이 떨어진다.

무선 인터페이스를 통해 보안이 적용되지 않은 네트워크에 연결하여 OTA 업데이트를 수행하는 과정에서 네트워크 스니핑(Sniffing) 공격으로 업데이트 프로토콜이 유출될 수 있다. 특히 비교적 시스템 자원이 부족하고 컴퓨팅 성능이 떨어지는 IoT 헬스케어 기기의 경우 간단한 프로토콜을 사용하여 OTA 업데이트가 이루어질 가능성이 크기 때문에 더욱더 쉽게 분석 당할 수 있다. 그 결과 업데이트를 수행하는 중앙 관리 시스템 및 게이트웨이의 네트워크 특성 정보와 업데이트 과정에서 기기 간에 송수신하는 메시지 등이 유출될 수 있다.

공격자는 유출된 업데이트 프로토콜을 모방함으로써 악성 소프트웨어를 IoT 헬스케어 기기에 설치할 수 있으며 그 결과 기기의 기능을 무력화하여 사용자에게 피해를 입히거나 기기의 통신 기능을 악용하여 IoT 헬스케어 기기와 연결된 다른 시스템에도 2차적인 피해를 입힐 수 있다. 실제로 IoT 기기를 분산 서비스 거부 공격(Distributed Denial of Service attack, DDoS)에 활용하거나[11], 특정 동작 수행을 반복시켜 해당 기기 또는 해당 기기와 연결된 주변 기기의 배터리를 방전 시키는 공격(Battery exhaustion attack) 등이 가능하다[12]. 이러한 공격은 같은 OTA 업데이트 프로토콜을 사용하는 다수의 IoT 헬스케어 기기에 동시다발적으로 수행할 수 있기 때문에 피해가 쉽게 확산된다.

네트워크 스니핑으로 OTA 업데이트 과정에서 소프트웨어의 이진 코드가 유출되는 경우에는 역공학을 통해 다음과 같은 추가 정보가 유출될 수 있다.

첫째로는 기기나 사용자 인증 관련 정보 또는 IoT 헬스케어 기기와 게이트웨이 간 연결 및 통신에 사용되는 정보들이 유출될 수 있다. 이러한 정보들이 유출된다면 정상 IoT 헬스케어 기기를 흉내 내 게이트웨이와 연결하거나 정상 게이트웨이를 흉내 내어 IoT 헬스케어 기기의 연결을 유도하는 비인증 기기 공격(Rogue device attack)[13], IoT 헬스케어 기기와 게이트웨이 간 연결에 끼어들어 전송 데이터를 가로채거나 조작하는 중간자 공격(Man-in-the-middle attack, MITM)에 활용될 수 있다[14].

둘째, IoT 헬스케어 기기가 사용자로부터 수집한 건강 관련 정보를 게이트웨이에 전송할 때 사용하는 데이터 전송 양식이 유출될 수 있다. 데이터 전송 양식이 유출될 경우 인가받지 않은 제3자가 정상 사용자의 건강 관련 데이터를 열람할 수 있으며 비인증 기기나 중간자 공격을 통해 사용자의 건강 상태를 임의로 조작하여 전송할 수 있게 된다. 이 경우 IoT 헬스케어 기기의 특성상 기기가 전송하는 데이터에 사용자의 신상정보와 같은 민감한 정보가 포함되어 있지 않은 비교적 보안 요구 수준이 낮은 기기임에도 불구하고 건강에 직접적인 위해를 가하게 된다. 공격자가 악의적인 목적을 가지고 게이트웨이에 지속적으로 사용자의 정상적인 생체 신호를 전송하는 경우 헬스케어 서비스 제공자가 사용자의 응급 상황을 적시에 파악할 수 없으며 반대로 비정상적인 생체 신호를 전송하여 응급 상황으로 오인하도록 만들 수 있다. 그 결과 서비스의 품질과 데이터 저장소의 신뢰성을 파괴할 뿐만 아니라 사용자의 건강에 심각한 악영향을 초래할 수도 있다.

셋째, 제어 명령어 및 개발자가 디버그를 위해 남겨둔 명령어가 유출될 수 있다. 이러한 기기 제어 명령어들은 해커의 주요 공격 수단 중 하나이며 IoT 헬스케어 기기를 원격에서 임의로 동작시킬 수 있기 때문에 사용자에게 직접적인 피해를 유발할 수 있다.

스니핑 공격을 위해 Kali Linux 32-Bit를 설치한 Raspberry Pi 4 Model B와 시중에서 판매되고 있는 I사의 무선 네트워크 어댑터를 사용해 네트워크 모니터를 구성하고 Arduino MKR1000 WiFi 보드와 심박 센서를 결합하여 모의 IoT 헬스케어 기기를 제작하였다. 모의 IoT 헬스케어 기기는 무선 인터페이스로 PC와 연결하여 측정한 사용자의 심박 수치를 PC로 전송하거나 PC로부터 OTA 업데이트를 받는다. IoT 헬스케어 기기와 PC는 보안이 적용되지 않은 WiFi로 연결되도록 설정했으며 네트워크 모니터는 이를 탐지 가능한 물리적 거리에 위치하였다. 네트워크 모니터는 아직 IoT 헬스케어 기기와 게이트웨이의 아이피나 송수신 포트 등 네트워크 특성을 알 수 없기 때문에 수집한 패킷들 중에서 OTA 업데이트에 사용된 패킷들을 선별하는 과정이 필요하다.

패킷 스니핑 및 OTA 업데이트 패킷 선별 알고리즘은 다음과 같다.

• 1. 네트워크 모니터는 주변의 모든 네트워크 패킷 수집.
• 2. 수집된 패킷들 중 같은 무선 네트워크에 연결된 기기들 간에 송수신한 패킷 선별.
• 3. 데이터 전송 빈도수가 적고 전송 데이터 사이즈가 작은 기기 선별.
• 4. 짧은 시간 동안 비교적 큰 패킷을 수신한 기기 선별.
• 5. 패킷에서 어셈블리 명령어 검색.

두 번째 과정에서 패킷의 출발지와 도착지를 확인하고 같은 서브넷에 속해 있다면 두 기기는 동일 네트워크에 연결되어 있음을 알 수 있다. IoT 헬스케어 기기와 게이트웨이는 같은 네트워크에 연결되어 있으므로 이 과정을 통해 목표 기기와 패킷들을 선별할 수 있다.

세 번째 과정은 IoT 헬스케어 기기가 일반적으로 배터리 제한이나 기기 성능의 제한으로 지속적으로 패킷을 보내지 않고 측정 데이터 전송과 같이 이벤트가 발생했을 때만 메시지를 전송한다는 특징을 이용하는 것이다. 반대로 송수신 빈도수가 높은 기기는 PC나 스마트폰 등의 기기일 가능성이 높기 때문에 목표 기기 및 목표 패킷에서 제외한다.

네 번째 과정은 프로그램 업데이트에 수 킬로바이트에서 수십 킬로바이트 이상의 데이터 전송이 필요하고 크기가 큰 데이터는 여러 윈도로 나누어진 연속적인 패킷의 형태로 네트워크에서 전달된다는 것을 이용한 것이다. 따라서 비교적 패킷 송수신량이 많지 않은 기기에서 순간적으로 대량의 패킷을 수신한다면 IoT 헬스케어 기기가 OTA 방식으로 업데이트 패킷을 전달 받았다고 가정할 수 있다.

다섯 번째 과정은 위 과정에서 선별한 패킷에서 어셈블리 명령어를 찾아 OTA 업데이트 패킷임을 확인하는 과정이다. 이때 레지스터를 사용하지 않아서 항상 고정된 명령 코드(Operation code, Opcode)를 가지는 어셈블리 명령어들이 유효하다. 이러한 명령 코드로는 ret(Return from subroutine), clt(Clear T flag), ijmp(Indirect jump) 등이 있고, 특히 ret 명령코드는 프로그램을 구성하는 서브루틴 별로 하나씩 존재하기 때문에 사용 빈도가 매우 높다. 연속된 패킷들에서 명령 코드와 일치하는 값들이 높은 빈도로 존재한다면 해당 패킷들은 프로그램의 일부일 확률이 높기 때문에 업데이트 패킷으로 간주한다.

상기한 과정을 통해 IoT 헬스케어 기기와 PC 게이트웨이를 특정하고 두 기기 간 OTA 업데이트 스니핑 시도를 총 10회 수행하였으며 그 결과는 다음과 같다. 업데이트 한 프로그램은 35개의 패킷으로 나뉘어 전송되었으며 1회 공격을 통해 평균 29.2개, 83.4%의 패킷을 스니핑 할 수 있었다. 최소 손실 회차에서는 1개의 패킷만 손실되었고 최대 손실 회차에서는 12개의 패킷이 손실되었다. 3회차 시도 때 소프트웨어 전송 전후로 전송되는 OTA 업데이트 포로토콜 패킷과 OTA 업데이트로 전송되는 소프트웨어 전체의 이진 코드를 확보할 수 있었다. 실험을 위해 구성한 네트워크 모니터를 일반인들도 시중에서 쉽게 구입할 수 있는 제품들로만 구성한 것을 감안하면 전문 네트워크 모니터를 사용하거나 동일한 네트워크 모니터를 다수 사용함으로써 스니핑 신뢰도와 정확성을 더욱 높일 수 있을 것으로 예상된다.

모의실험으로 확보한 OTA 업데이트 패킷을 분석한 결과 업데이트할 프로그램의 바이너리 코드는 HTTP로 전송된다는 것을 알 수 있었다. 특히 HTTP 메시지의 헤더 속성 중 권한 인증에 사용되는 Authorization 속성에 ID와 password의 쌍으로 추정할 수 있는 HBSens:0800200c9a66 문자열이 Base 64로 인코딩되어 존재하는 것을 확인하였다. 이 밖에도 IoT 헬스케어 기기와 PC 게이트웨이의 IP, 포트 번호 등 네트워크 특성 및 업데이트 요청 URI, IoT 헬스케어 기기가 업데이트 프로그램 수신 후 게이트웨이에 전송하는 응답 메시지 등을 확인할 수 있었다.

스니핑 공격으로 획득한 소프트웨어 이진 코드는 소프트웨어 동작 시 사용되는 문자열들을 찾는 방식으로 분석을 수행하였다. 이러한 방식은 소프트웨어 전체의 동작 방식을 모두 파악할 필요가 없고 문자열은 이진 코드 상에서 연속된 형태로 나타나므로 분석 난도가 낮다. 바이너리 코드에서 추출한 문자열은 기기 간 통신 인증 과정에서 사용되는 아이디나 비밀번호 후보군으로써 무차별 대입 공격의 성공률을 높이거나 통신 프로토콜 및 데이터 전송 양식을 이해하는데 사용한다.

프로그램 동작 과정에서 문자열을 사용하는 방식은 프로그래밍 방법에 따라 결정되기 때문에 역공학을 통해 문자열을 식별하는 방법도 상이하다.

프로그램 영역에서 문자열을 읽고 쓰는 경우에 대한 이진코드 분석 알고리즘은 다음과 같다.

• 1. 4개의 연속된 ldi(Load immediate) 명령어 찾기.
• 2. 연속된 cp(Compare), cpc(Compare with carry) 명령어 찾기.
• 3. breq(Branch if equal) 명령어 찾기.
• 4. movw(Copy register word) 명령어 찾기.

첫 번째 과정에서 찾는 ldi 명령어는 8비트 상수를 레지스터에 저장하는 명령어이며 프로그램이 문자열의 시작과 끝 메모리 주솟값을 레지스터에 저장할 때도 사용되기 때문에 문자열 식별의 시작으로 활용한다. 각 주솟값은 16비트이므로 하나의 주솟값을 레지스터에 저장하기 위해서는 하위 주솟값과 상위 주솟값으로 나누어 레지스터에 저장해야 하기 때문에 두 개의 ldi 명령어가 필요하다. 따라서 문자열의 시작 메모리 주솟값과 끝 메모리 주솟값을 다루기 위해서는 4개의 연속된 ldi 명령어가 바이너리 코드 상에서 나타나게 된다.

두 번째 과정은 프로그램이 문자열을 활용하기 위해서는 문자열의 시작 주솟값부터 데이터를 읽고 주솟값을 하나씩 증가시키며 문자열 끝 주솟값까지 데이터 읽는 과정이 필요하다는 것을 이용한 것이다. 따라서 현재 데이터를 읽고 있는 주솟값이 끝 주솟값과 동일한지 확인하고 데이터 읽기를 종료할지 판단하기 위해서는 두 주솟값을 비교하는 연산이 필요하고, 이때 사용되는 것이 cp 명령어와 cpc 명령어이다. cp 명령어는 두 개의 레지스터를 비교하는 명령어이고 cpc는 올림 값(carry)을 포함하여 두 개의 레지스터를 비교하는 명령어이다. 두 주솟값을 비교하기 위해서는 하위 주솟값을 비교하기 위한 cp 명령어와, cp 명령어의 결과로 생성되는 올림 값을 포함하여 상위 주솟값을 비교하기 위한 cpc 명령어가 반드시 뒤따른다.

세 번째 과정에서 찾는 breq 명령어는 비교 연산인 cp 또는 cpc 명령어와 함께 사용되며 비교 연산의 결과에 따라 프로그램의 실행 부분을 분기하는 역할을 한다. 문자열 읽기 과정에서 아직 문자열 읽기를 마치지 못했다면 프로그램을 순차적으로 수행하여 문자열 읽기를 계속하고, 문자열 읽기를 마쳤다면 다음 서브루틴을 실행하기 위해 프로그램 실행 위치를 변경하는 목적으로 breq가 사용된다.

네 번째 과정의 movw 명령어는 두 개의 레지스터에 저장된 값을 다른 두 레지스터에 복사하는 명령어다. 문자열 읽기 과정에서는 레지스터에 저장된 문자열 주솟값을 포인터 레지스터로 옮기기 위해 사용된다. 프로그램 영역에 저장된 문자열을 읽기 위해서는 메모리 주솟값을 저장한 포인터 레지스터를 통해 문자열이 위치한 메모리에 접근해야 하기 때문에 반드시 필요한 과정이다.

다섯 번째 과정에서 찾는 lpm 명령어는 포인터 레지스터에 저장된 주솟값이 가리키는 메모리 영역에서 1 바이트를 읽는다. 문자열 읽기 과정에서 최종적으로 하나의 문자를 읽는데 사용된다.

정리하면 바이너리 코드 상에서 일련의 ldi, ldi, ldi, ldi, cp, cpc, breq, movw, lpm 명령어가 나타나면 프로그램 영역에서 문자열을 순차적으로 읽어서 사용하는 부분이라고 추정할 수 있다. 따라서 ldi 명령어들이 불러오는 메모리 주소에 저장된 값들을 확인함으로써 프로그램 안의 문자열을 추출할 수 있다.

표 3은 이진 코드 분석 과정에서 확인할 수 있었던 문자열의 예이다. 문자열은 메모리 주소 0x68~0x74에 있으며 주로 통신 제어에 사용되는 문자인 STX(\0x02)와 NULL(\0x00), 특수 문자인 ‘!’를 포함하여 \x02\0x00SN205315! 이다.

이러한 과정들을 거쳐 추출한 문자열들과 각 문자열 별 실제 프로그램에서의 역할을 정리하면 표 4와 같다. 추출한 문자열들 중 HBSens와 \x02\0x00SN205315!는 OTA 업데이트 과정에서 권한 인증에 사용되는 주요 정보이며, 이 밖에도 측정 데이터 요청 메시지 식별자, 측정 데이터 전송 메시지를 구성하는 문자열, 접속할 WiFi 식별자 기본값, 디버그에 사용되는 문자열 등을 획득할 수 있었다.

본 논문에서는 스니핑 과정에서 확보한 OTA 프로토콜과 이진 코드 분석으로 추출한 문자열들을 사용하여 모든 기능이 제거된 더미 프로그램(Dummy program)을 IoT 헬스케어 기기에 설치하였다.

더미 프로그램을 설치하는 절차는 다음과 같이 수행하였다.

• 1. OTA 업데이트 프로토콜인 HTTP 메시지 생성.
• 2. 모의 IoT 헬스케어 기기에 생성한 HTTP 메시지 전송.
• 3. IoT 헬스케어 기기로부터 HTTP 응답 메시지 수신.
• 4. 수신한 응답 메시지의 상태 코드가 200 OK인 경우 더미 프로그램 설치 완료.
• 5. 수신한 응답 메시지의 상태 코드가 401 Unauthorized인 경우 이진코드에서 추출한 문자열을 바탕으로 권한 인증 정보 변경 및 HTTP 메시지 재생성.
• 6. 200 OK 응답 메시지가 수신 될 때 까지 2~5번 과정 반복.

첫 번째 과정에서 생성하는 HTTP 메시지는 스니핑 과정에서 획득한 HTTP 헤더 속성 중 권한 인증에 사용되는 Authorization 속성을 포함한 모든 헤더 속성과 동일하게 설정한다. 더미 프로그램은 HTTP의 바디에 싣는다.

두 번째 과정에서 HTTP 메시지 전송은 스니핑 과정에서 획득한 전송 URI와 포트 번호 등의 네트워크 정보를 사용한다.

세 번째 과정에서 401 Unauthorized 응답 메시지가 수신되었다면 이전 업데이트 과정에서 보안 목적으로 권한 인증 정보가 변경된 것을 의미한다. 이 경우 다섯 번째 과정을 따라 이진코드 분석 과정에서 획득한 문자열들을 권한 인증에 사용되는 ID와 password의 후보군으로 사용하여 HTTP 헤더의 Authorization 속성 값을 변경한 메시지를 다시 생성한다.

다섯 번째 과정과 여섯 번째 과정은 인증 권한을 얻고 더미 프로그램을 설치하기 위한 무차별 대입 공격 과정이다.

모의실험에서는 업데이트 과정에서 업데이트 권한 인증 password가 변경되었기 때문에 5번 및 6번 과정도 수행하였고, 그 결과 변경된 password인 \x02\0x00SN205315!을 찾아 더미 프로그램 설치를 완료할 수 있었다. 더미 프로그램이 설치된 모의 IoT 헬스케어 디바이스는 심박 측정 및 측정 데이터 전송이 중지되고 OTA 업데이트를 담당하는 기능도 제거되어서 더 이상 무선 인터페이스로 프로그램을 업데이트할 수 없었다. 따라서 기기에 유선 인터페이스 등 유지 보수를 위한 다른 수단이 없다면 기기의 사용이 영구적으로 불가능해졌다.