블루투스의 취약점들

1. Introduction

블루투스는 수많은 기기들이 근거리 통신을 위해 사용하는 프로토콜입니다. 컴퓨터와 연관이 있는 키보드, 마우스, 스피커 등의 입출력장치는 물론이고 심장박동수 측정 기기와 같은 의료기기들도 무선으로 정보를 송/수신해야할 필요가 있을 경우 블루투스를 사용합니다.

블루투스 통신에서 오가는 정보는 반드시 기밀이 유지되어야 하고 송/수신자가 아닌 외부의 공격자가 내용을 감청하거나 변조하는 일이 없어야 합니다. 그렇기 때문에 블루투스의 통신 규약을 보면 내용은 암호화가 되고 다양한 공격들에 대한 대비책을 미리 마련해두고 있습니다.

그러나 현존하는 모든 시스템이 그러하듯 블루투스 프로토콜도 다양한 취약점이 종종 발견됩니다. 특히 요즘들어 메이저한 취약점이 여러 개 발견되어서 큰 위협이 되고 있습니다.

이번 글에서는 지금까지 나온 블루투스의 메이저한 취약점들을 알아보는 시간을 가져보도록 하겠습니다.

2. Basic Information

먼저 블루투스 프로토콜에 대해서 간단하게 설명을 드리겠습니다. 블루투스에는 BLE, BR/EDR라는 두 가지 모드가 있습니다. BLE는 최근에 도입된 저전력 통신 모드이고 BR/EDR은 예전부터 써오던 통신 모드입니다. 저전력 환경이거나 송수신하는 데이터의 양이 많지 않을 경우에는 BLE를, 그렇지 않을 경우에는 BR/EDR을 사용할 수 있습니다.

블루투스에서 두 기기 A, B가 통신을 하기 위해서는 페어링이라는 절차가 먼저 수행되어야 합니다. 페어링은 두 기기가 서로에 대한 정보를 교환하고 키를 공유해 향후 통신을 이어갈 수 있도록 하는 절차입니다.

페어링에는 4가지 모델이 있고 기기의 상황에 따라 이들 중에서 하나를 선택합니다.

i) Numeric Comparison

Numeric Comparison은 두 기기가 모두 6자리 수를 보여줄 수 있고 또 yes or no를 입력할 수 있을 때 사용하는 모델입니다. 예를 들어 두 휴대폰끼리 연결하는 상황을 상상해보면 됩니다. 양쪽에 뜬 6자리 수가 동일할 경우 두 기기에서 모두 yes를 누릅니다. 이러한 방식 덕분에 Man In The Middle 공격으로부터 안전합니다.

ii) Just Works

Just Works는 어느 한 기기가 6자리를 보여줄 수도 없고 yes or no도 입력할 수 없을 때 사용하는 모델입니다. 컴퓨터와 헤드폰을 연결한다면 헤드폰은 6자리를 보여줄 수도 없고 yes or no도 입력할 수 없으니 Just Works 모델을 사용하게 될 것입니다. 이 모델은 Man In The Middle 공격으로부터 안전하지 않습니다.

iii) Out of Band

Out of Band는 말 그대로 두 기기가 블루투스 프로토콜을 통하지 않고 와이파이나 NFC등 기타 다른 채널로 암호학적 수를 교환할 수 있을 때 사용하는 방법입니다. 이 바깥의 채널에서 수를 교환한 후 Numeric Comparison과 비슷하게 yes를 누르는 방식으로 진행됩니다.

iv) Passkey Entry

Passkey Entry는 한 기기는 입력만 가능하고 다른 기기는 출력이 가능한 상황을 의미합니다. 예를 들어 PC와 키보드를 연결한 것과 같은 상황을 의미합니다. 이 때 출력이 가능한 기기에서 6자리의 수를 보여주고 입력이 가능한 기기에서 그 수를 입력하도록 해 수가 일치하는지를 확인합니다.

이 4가지 과정 중에서 Just Works는 다소 취약함을 알 수 있습니다. 그러나 연결을 하고자 하는 기기가 6자리 수를 보여줄 수도 없고 yes or no도 입력할 수 없는 장치라면 어쩔 수 없이 Just Works 방식을 사용해야 하는데, 나중에 공격 부분을 살펴보면 이 부분이 하나의 맹점으로 작용합니다.

이렇게 4가지 모델 중 하나로 서로의 연결 의사를 확인한 후에는 타원 P-256에서 Elliptic Curve Diffie Hellman(ECDH)으로 키교환을 한 후 AES-CCM으로 암호화 통신을 진행합니다. ECDH, AES-CCM 모두 암호학적으로 충분히 안전하다고 보여지는 알고리즘들입니다.

3. Attacks

A. Blueborne(Sep. 2017)

첫 번째로 소개할 취약점은 Blueborne입니다.

Blueborne Logo

Blueborne은 보안 회사 Armis에서 2017년 찾아낸 취약점으로, 무려 8개의 제로 데이를 엮어서 만들었습니다. 8개 취약점 목록은 아래와 같습니다.

Linux kernel RCE vulnerability - CVE-2017-1000251
Linux Bluetooth stack (BlueZ) information Leak vulnerability - CVE-2017-1000250
Android information Leak vulnerability - CVE-2017-0785
Android RCE vulnerability #1 - CVE-2017-0781
Android RCE vulnerability #2 - CVE-2017-0782
The Bluetooth Pineapple in Android - Logical Flaw CVE-2017-0783
The Bluetooth Pineapple in Windows - Logical Flaw CVE-2017-8628
Apple Low Energy Audio Protocol RCE vulnerability - CVE-2017-14315

보다시피 특정 OS과 관련된 취약점만 있는게 아니라 리눅스, 안드로이드, 윈도우 등이 전부 영향을 받았습니다. 당시 기준으로 Amazon Echo, Google Home, Windows, iOS를 포함한 현존하는 거의 모든 기기가 이 취약점에 영향을 받았습니다.

더 놀라운 것은 이 취약점은 zero-click vulnerability였습니다. zero-click vulnerability는 말 그대로 victim이 아무런 행동을 하지 않아도 실행되는 취약점을 말합니다. 예를 들어 공격자가 victim에게 블루투스 연결 요청을 보내고 victim이 이를 승인할 경우 취약점이 실행된다면 이는 victim의 추가적인 행동이 필요하기 때문에 zero-click vulnerability가 아닙니다. 하지만 Blueborne은 victim이 블루투스를 활성화해두기만 하면 취약점이 실행되기 때문에 더욱 파급력이 큰 취약점입니다.

Armis에서 제공한 Blueborne 백서를 확인해보면 취약점들이 어떤 코드에서 발생하는지 상세한 설명과 함께 확인할 수 있습니다. 깊은 원리를 이해하고 싶은 분은 백서를 확인하시고 이 글에서는 시스템 해킹에 익숙하지 않은 분들을 대상으로 하는 간략한 설명만 드리겠습니다.

시스템 해킹을 해본 적이 없다고 하더라도 버퍼 오버플로우는 어디선가 들어본 적이 있을 것입니다. 블루투스 통신에서 운영체제에는 날아온 패킷을 파싱하는 코드가 존재하는데 이 코드에 결함이 있다면 공격자가 패킷을 보내 victim의 기기를 장악할 수 있게 됩니다. 백서에 있는 다양한 예시 중에서 한 가지만 가지고 설명을 해보겠습니다.

// l2cap_parse_conf_rsp (net/bluetooth/l2cap_core.c)
static int l2cap_parse_conf_rsp(struct l2cap_chan *chan, void *rsp, int len, void *data, u16 *result)
{
  struct l2cap_conf_req *req = data;
  void *ptr = req->data;
  // ...
  while (len >= L2CAP_CONF_OPT_SIZE) {
    len -= l2cap_get_conf_opt(&rsp, &type, &olen, &val);

    switch (type) {
    case L2CAP_CONF_MTU:
      // Validate MTU...
      l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, chan->imtu);
      break;
    case L2CAP_CONF_FLUSH_TO:
      chan->flush_to = val;
      l2cap_add_conf_opt(&ptr, L2CAP_CONF_FLUSH_TO, 2, chan->flush_to);
      break;
  // ...
   }
  }
  // ...
  return ptr - data;
}

L2CAP은 마치 네트워크 7-Layer에서의 Physical Layer와 같이 블루투스에서 가장 낮은 계층입니다. 그 계층에서 쓰이는 함수 중 l2cap_parse_conf_rsp라는 함수에서는 변수 rsp에서 값을 파싱해서 data로 넣어주는 과정을 진행합니다. 그런데 rsp의 크기는 인자 len으로 들어오지만 data의 크기는 인자로 들어오지 않기 때문에 버퍼를 넘어서 값이 쓰일 여지가 있고 실제로 l2cap_parse_conf_rsp가 호출되는 상황을 보면 64바이트 크기의 배열에 임의 길이 만큼의 값을 쓰게 할 수 있습니다.

Blueborne 취약점은 대중에게 공개되기 전에 각 제조사들에게 미리 공개되어서 그럭저럭 빠르게 패치가 이루어지긴 했지만 그럼에도 불구하고 대략 한 달 정도 동안은 패치가 적용되지 않은 채로 있었습니다. 그리고 만약 2017년 이전에 만들어졌고 이후 보안 패치를 따로 하지 않은 기기라고 하면 지금도 이 취약점으로부터 안전하지 않을 것입니다.

B. Low Entropy Key Negotiation Attacks

두 번째는 low Entropy Key Negotiation Attack입니다. 이 취약점을 발견한 그룹은 취약점을 Key Negotiation of Bluetooth(KNOB) Attack으로 부르고 있습니다.

블루투스를 사용하는 기기들 중에는 다소 연산 능력이 부족한 기기도 있을 수 있으므로 블루투스 백서에서는 이를 충분히 감안한 처리들을 해두었습니다.

그 중에서 키의 Entropy라고 하는 인자가 있는데, 말 그대로 두 기기가 페어링 과정에서 키를 정할 때 키의 복잡도에 관여하는 인자입니다. 만약 키의 Entropy가 1 byte = 8 bit라고 한다면 키는 $2^8$개의 가능성을 가지고 16 byte = 128 bit라고 한다면 $2^{128}$개의 가능성을 가집니다.

이 Entropy는 마치 페어링 모델을 정하는 것과 같이 두 기기끼리의 합의 하에 정해집니다.

예를 들어 Alice와 Bob이 통신할 때 Alice가 Bob에게 Entropy를 16 byte로 할 것을 제안하고 Bob이 이를 받아들인다면 Entropy는 16이 됩니다. 그리고 Entropy는 이 공격이 나올 당시에 1에서 16 사이의 값을 가질 수 있다고 표준에 명시되어 있었습니다.

Entropy가 1이면 키의 후보가 256개 밖에 없기 때문에 공격자 입장에서 너무나 간단하게 두 기기 사이의 통신을 들여다볼 수 있게 됩니다.

그래서 공격자는 Man in The Middle 공격을 통해 Alice가 Bob에게 보내는 요청을 중간에 낚아채서 Entropy를 1로 제안하게 해서 Entropy를 강제로 1로 떨굽니다.

설명을 보면 정말 너무나도 간단한 공격이고 왜 아무도 이런 공격을 찾지 못헀는가 하는 생각이 듭니다.

이 공격은 2019년 8월에 제보되었고 키 Entropy를 1에서 16이 아닌, 7에서 16으로 변경하는 방식으로 패치가 이루어졌습니다.

자세한 정보와 관련 논문은 공식 사이트에서 확인할 수 있습니다.

C. BLURtooth

세 번째는 BLURtooth라는 이름의 공격입니다. 이 취약점은 올해 5월에 제보되었습니다.

이 취약점을 이해하기 위해서는 위에서 언급한, BLE, BR/EDR라는 두 가지 모드에 대해 다시 짚고 넘어가야 합니다.

예를 들어 블루투스 키보드/마우스와 같이 저전력이고 시간당 보내야 하는 정보의 양이 적은 상황이라면 BLE 모드를 이용할 것이고 스피커 혹은 두 기기 사이의 파일 전송과 같이 시간당 보내야 하는 정보의 양이 많은 상황이라면 BR/EDR을 사용할 것입니다.

그런데 동일한 두 기기에서 맨 처음 BLE로 통신을 시작했지만 이후 BR/EDR로 통신을 하고 싶은 상황이라거나, 반대로 맨 처음 BR/EDR로 통신을 시작했지만 이후 BLE로 통신을 하고 싶은 상황이 있을 수 있습니다.

이런 경우 페어링을 2번 진행하는 대신 어느 한쪽의 키를 이용해 다른 쪽의 키를 만들 수 있습니다. 이러한 절차는 Cross-Transsport Key Derivation(CTKD)라는 이름이 붙어있고 Bluetooth v4.2에 추가되었습니다.

CTKD는 크게 이론적으로 복잡한 것은 없고 어느 한 쪽의 키를 AES-CMAC을 이용해 16 byte 결과를 만들어내고, 그 결과를 다른 쪽의 키로 사용합니다.

그런데 공격자가 CTKD를 이용해 키를 임의로 조작할 수 있습니다. 아래의 예시를 생각해봅시다.

Fig.3 in BLURtooth paper

Alice와 Bob은 BR/EDR(그림에서는 BT) 통신을 진행하고 있습니다.

그리고 공격자 Charlie는 Alice인척 Spoofing을 해 Bob과 BLE 통신을 진행합니다. 그리고 Charlie는 CTKD를 이용해 BT 통신의 키를 자신이 아는 키로 조작합니다.

이렇게 되면 Charlie는 Alice와 Bob 사이의 키를 자신이 아는 키로 overwrite할 수 있고 이후 통신을 들여다볼 수 있게 됩니다.

D. BLESA

마지막 공격은 BLESA(BLE Spoofing Attack)입니다. 이 공격 또한 올해 제시되었고 아직까지 보안 패치가 이루어지지 않았습니다.

BLE에서는 이전에 연결된 기기와 재연결을 할 때 인증 절차를 생략하는 경우가 종종 있습니다.

이 취약점을 이용해 특정 기기 A에 대해 공격자가 A와 이전에 연결된 기기로 위장할 경우 A는 아무런 의심없이 공격자를 이전에 연결된 기기로 생각합니다. 이를 이용해 공격자는 기기 A에서 민감한 정보를 탈취할 수 있습니다.

4. Conclusion

이와 같이 최근에 제시된 블루투스 취약점 4개를 살펴보았습니다. Blueborne은 상당한 분석 능력이 필요해보이지만 나머지는 원리만 놓고 봤을 땐 그렇게 복잡하지 않고 충분히 떠올릴만 했다는 생각이 듭니다.

취약점 자체를 이해하는 것도 중요하지만 연구자의 입장에서 이런 취약점들을 어떻게 발견할 수 있었는지도 신기했습니다. 위의 취약점들을 공부하기 위해 논문들을 살펴보면서 팁들을 조금 얻을 수 있었는데,

최신에 도입된 기술일수록
아직 연구가 덜 이루어져 안전한 정도에 대한 자료가 없을수록

취약점이 나올 여지가 많아보았습니다. 저는 아직 초보연구자로서 연구다운 연구를 시작해보지는 못했지만 블루투스를 들여다보며 콜럼버스의 달걀을 찾아내보고자 합니다.