CC2640: Vulnerabilities CVE-2020-13593 ?

Hello Albert,

I am working to find the appropriate expert to help you. This may take some time to reach the right person depending on availability. Please expect an update by 7/24. I appreciate your patience.

Regards,

Luis

Hello Albert,

I'm gathering information. Thank you for your patience.

-Luis

Hi Luis,

A customer tried to verify the vulnerability patch by using the script (github.com/.../sweyntooth_bluetooth_low_energy_attacks)

The customer got the below result when they run the script with "CC2640 SDK 2.2.4 " and  "CC2640R2 SDK 4.10"

Could you please check if these results are Okay or not ?

if these test result are not expected one, please let me know how to test these correctly.

-  "CC2640 SDK 2.2.4 " test result

<Device log>

DBUG ProcessState: 2

DBUG ProcessState: 6

CONS,1

DBUG PairStateEvt: 0x00, 0x00

DBUG ProcessState: 5

<"CC2640R2 SDK 4.10"> test result

- 

[     0.049 ] >>> STARTED

[     0.053 ] MyAddr(A4:34:F1:DF:D0:FE)

[     0.059 ] >>> ADVERTISING

[    11.742 ] >>> CONNECTED: PeerAddr(5D:36:AC:90:0B:20) Type(0) Handle(0)

[    12.043 ] >>> PAIRING_STARTED, 0x00

[    42.244 ] >>> PAIRING_COMPLETE, 0x17

[    52.345 ] >>> WAITING

[    52.348 ] TERM(0x22)

Albert,

I'll have to talk to my experts in the dev team. Please stand by.

-Luis

Albert,

Can you please confirm that you are using CC2640 with BLE-STACK v2.2.4, and CC2640R2 with SDK v4.10? Or are there any other devices involved?

Thanks,

Luis

Hi Luis,

I'm the customer of Mr.Albert, who asked the original question.

Currently, I'm using CC2640 with BLE-STACK v2.2.2, and CC2640R2 with SDK v3.40 for two products.

We received inquiries about this vulnerability for our products from overseas MFDS, and we must prove that the problem is solved when we apply the SDKs that fixes this vulnerability to our products.

So I applied 2.2.4 and 4.20 to each product to verify the vulnerability patch and I test with the script file provided by sweyntooth, but It doesn't seem to work gracefully.

1. Could you provide a modified script file for your SDKs ?

2. If not, how can we prove the vulnerability fixed for our products? We must explain that how we test and what the results are to the overseas MFDS.

Thanks,

Calvin

Calvin,

First, I wanted to re-emphasize that the defect was fixed in the two version that we discussed, BLE-STACK v2.2.4 for CC2640, and SDK v4.10 for CC2640R2.

Earlier this year our team followed the resolution process: identified the root cause of the issue (I'm talking about the vulnerability), modified the code to resolve it, a team of engineers peer-reviewed it and performed the necessary tests. These tests were performed using internal tools and devices that used a specially modified firmware.

Just for some background, according to the spec 'Secure Connections' goes like this:

1. Phase 1 – Pairing Feature Exchange. 
2. Phase 2 – Authentication and Encryption, For Secure connections:

1. 1. Public Key Exchange.
   2. Authentication stage 1.
   3. Long Term Key (LTK) Calculation. 
   4. Authentication stage 2 -  DHKey checks. 

While we have logs that I cannot share, I am showing below an image of the them; before the fix (left) and after the fix (right):

You can see how, on the left before the fix, the link is encrypted without performing the DH Key Check phase. On the right, after the fix, the same peer device (i.e. the attacker) now causes an authentication failure on the peripheral.

In regards to the script results you shared, the team believes that the "failure" is not related to the attack itself, but that somehow the peripheral times out. The reason is unknown. It might be a setup error (for example, that the peripheral code has secure connections disabled), or also a script error.

Can you please verify if the peripheral has secure connections when performing the test? And the logic of the script itself?

I hope this is helpful.

-Luis

Hi Luis,

I verified my peripheral has secure connections when performing the test.

In case of the CC2640 with SDK2.2.4, it does not send public key to the master.

It is same when I change the pairing method to justworks.

Do you have any idea about this?

There is nothing to analyze between 'pairing response' and 'random key' in the script.

Thanks,

Calvin

Calvin,

Thanks for confirming that you have secure connections enabled.

However, the issue you are observing seems something different. Can you please check your settings for the GAP Bond Manager? Maybe the IO Capabilities? See the User's Guide (SWRU393) under C:\ti\simplelink\ble_sdk_2_02_04_06\docs\. See section 5.4, and in particular 5.4.2. Also, while not exactly applicable to this device, you could take a look at our lab on Security Fundamentals on the SimpleLink Academy. 

Also, maybe using a packet sniffer could help.

Thanks,

Luis

Hi Luis,

I tested passkey entry and justworks with below settings and same results.

case PAIR_METHOD_PASSKEY:
  pairMode = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ;
  scMode = GAPBOND_SECURE_CONNECTION_ONLY;
  ioCap = GAPBOND_IO_CAP_DISPLAY_ONLY;
  mitm = TRUE;
  bonding = TRUE;
break;

case PAIR_METHOD_JUSTWORKS:
  pairMode = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ;
  scMode = GAPBOND_SECURE_CONNECTION_ONLY;
  ioCap = GAPBOND_IO_CAP_NO_INPUT_NO_OUTPUT;
  mitm = FALSE;
  bonding = TRUE;
break;

Could you review the code for the condition that peripheral does not send public key to master?

I think it will be very helpful. Also I attached a sniff log.

nosendpublickey.zip

Thanks,

Calvin

Hi Luis,

I figured out what the problem was.

The script works well after enabled length extension feature in the peripheral's firmware.

I test again and the results are:

1. CC2640 with SDK 2.2.2 : Failed as expected.

2. CC2640 with SDK 2.2.4 : Success as expected.

3. CC2640R2F with SDK 4.20.00.04 : Failed unexpectedly. The result is just same with #1's picture.

So I think the 13593 vulnerability is not patched in the SDK 4.20.00.04.

Please confirm this.

Thanks,

Calvin.

Calvin,

I'm certain that this was fixed since SDK 4.10.

Can you please try with that version? Otherwise, there has to be another reason why it is failing. Did you enable the length extension, too?

Thanks,

Luis

Hi Luis,

The DLE is enabled.

I test our product with SDK4.10(4_10_00_10) and the result is just same with #1's picture.

I test with "simple peripheral" example hex file of SDK 4.10 and 4.20 and the results are also same.

I guess the 13593 is not patched on 4.10 and 4.20 both.

Thanks,

Calvin

Calvin,

I'm in the process of escalating the issue. I believe that the issue was resolved in the SDK, but in any case I'm involving more members of the team.

Thanks,

Luis