Signature verification bypass vulnerability in some Huawei routers

This blog will describe the discovery of the digital signature bypass on some Huawei routers. 

The idea of digital signature check is simple - you have a piece of code and you calculated the checksum/hash of that file. The hash or checksum can be thought of as a "signature", a mathematical value that is uniquely assigned to the code (in our case the code was a firmware file). As soon as you change anything in the file and recalculate the hash, it should be significantly different from the original value - that is the feature of the hashing algorithm. Even the small change in the code will change the hash significantly.

Vendors in most cases provide the such a pre-calculated hash so that the customer or the system may check if the hash of the image is indeed the same as vendor required.

What was found in this investigation was that the system command on the Huawei AR1220E router does not perform this check properly.

As a consequence, the attacker might be able to craft the image maliciously, and the system would verify the corrupted image and proceed with boot.

The whole procedure described below followed the agreed mechanism with Huawei to make sure responsible disclosure was not violated.

This bug was marked with CVE-2019-5300 and is referenced under 

https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20190320-01-ar-en

Huawei published the security advisory in relation to CVE-2019-5300 on 20th Mar 2019.

The Process

     1.  Download the affected firmware/image 
     2. Check that the firmware is indeed what it’s supposed to be (verify its hash).
     3. Do that by checking that the hash/checksum of the binary file equals the hash/checksum    
         supplied (and encrypted) in the vendor’s digital signature

The Issue

1. The device itself contains the command that is supposed to do that:

     startup system-software <image> signature <signature>

2.  If all goes well, it displays “Info: Succeeded in setting the file for main booting system”

The Corrupting process

Step 1 – we deleted two characters (“iQ” from the original signature file (.asc file) making it corrupted)

Step 2 we ran the same verification again (this time the .asc signature is corrupted).
The result – success. So, here we have first unexpected occurrence of the "success" whereas it should have been failure. Note that the valid image was compared against corrupted signature.

This was the moment that dictated further investigation to determine its root cause. There were two assumptions that came to my mind:

Hypothesis A:  the "startup system-software" command does not perform the integrity check correctly. In other words, signature and firmware are aligned (mathematically dependent), but the command simply does the calculation wrong.

 Hypothesis B:  file integrity and signature are not aligned. In other words, the given signature is really not the hash of the given image. Or the image is not the one for which the signature was made in the first place.

In the meantime, I asked Huawei to explain this behaviours. Below is the quick response they sent which indicates the check should work correctly even though they run some checks against first two bytes for quick invalid signatures.

Initial reply from Huawei

At this time I decided to corrupt some other bytes then the first two. So, let’s change the 4 bytes somewhere in the middle of the signature (in the gray background).

After this alteration of the highlighted 4 bytes, the corrupted signature was saved as .asc Then the verification process was re-run and all was ok. Again.  This should not have happened as we corrupted the signature (again), this time altering 4 bytes at the random location of a digital signature.

The assumption B was that the file integrity and the signature are not aligned. That would simply mean the original signature was not calculated against given image. 

So, how do we do that check?

By using an independent set of GPG utilities running on Linux.

Independent check

In the first step , we downloaded the public key (“KEYS”) from a Huawei site: http://support.huawei.com/enterprise/en/tool/software-digital-signature-validation-tool--pgp-verify--TL1000000054/TV1000000016

In the second step, let us look at the contents of the KEYS.

Then I imported that key. 

I then enforced the trust relationship with the KEY.

In the next step , I checked the integrity of the original file – as you can see, looks ok ("Good signature from...")

After that I edited/corrupted the AR1220E-V200R010C00SPC200.cc.asc. Note that a file contains “corrupt.cc.asc” in its name. Basically, the corruption involved changing two bytes somewhere in the middle of the signature. Then I ran the verification against corrupted signature. It failed. Good so, as we expected that mismatch should show some indication of error.

I also did the other way round- I corrupted the image and ran the check against a valid signature. The check failed, indicating BAD signature. Again, this is good as we expected that the error should be indicated due to corrupted image file (note the "AR1220E-corrupt.cc" filename to indicate the corruption).                                  

So, this procedure indeed validated the integrity and failed once I corrupted either the signature file or the original image. That is good. 

Why the original Huawei embedded command does not fail was not clear.

Obviously, it is not reasonable to expect the end user runs all those commands on linux to make sure they have a valid firmware– the Huawei native command (the one used in our example) should do the check for the customer and indicate the failure once the corrupted signature or image are in place.

Some additional emails followed to Huawei demonstrating the malfunction of the router system command and explaining the consequences. 

The bug has been corrected by Huawei’s patch. A retest from 20-Feb-2019 showed the following results:

Check 1 – Correct firmware, correct signature

<ONB_BLB1_555A eth 0/1/18>startup system-software AR1220E-V200R010C00SPC200.cc signature AR1220E-V200R010C00SPC200.cc.asc

Info: This operation will take several minutes, please wait...............................................................................................................................................................

Info: Succeeded in setting the file for main booting system

Check 2 –correct firmware, corrupted signature (Deleted bytes)

<ONB_BLB1_555A eth 0/1/18>startup system-software AR1220E-V200R010C00SPC200.cc signature AR1220E-V200R010C00SPC200.cc.asc

Info: This operation will take several minutes, please wait....

Error: Wrong package file

<ONB_BLB1_555A eth 0/1/18>

Check 3- correct firmware, corrupted signature (Modified bytes)

<ONB_BLB1_555A eth 0/1/18>startup system-software AR1220E-V200R010C00SPC200.cc signature AR1220E-V200R010C00SPC200.cc.asc

Info: This operation will take several minutes, please wait.....

Error: Wrong package file

Check 4 – corrupted firmware, correct signature

<ONB_BLB1_555A eth 0/1/18>startup system-software ar1220f_V200R006C10SPC121T.cc signature AR1220E-V200R010C00SPC200.cc.asc

Info: This operation will take several minutes, please wait..................................................................................................................

Error: Wrong package file

<ONB_BLB1_555A eth 0/1/18>

After the recheck, Huawei was informed that the bug was not remediated and the following security advisory was issued for this bug , classified as CVE-2019-5300.