Huawei B593

During the quest of hacking my u-12, Mr. Ronkainen from blog.asiantuntijakaveri.fi insisted, that the certificate files in /etc/ are actually used. My personal belief was, that the purpose of having those would be something not-so-important. It turned out, that I badly misjudged the situation.

My firmware has these files:

# cd /etc/
# ls -l *pem
-rwxrwxrwx    1 0        0             963 privkey.pem
-rwxrwxrwx    1 0        0             963 privkey.b593pem
-rwxrwxrwx    1 0        0            3700 cachain.pem
-rwxrwxrwx    1 0        0            1751 b593cpekey.pem

Please note, that the files are in a Read-Only -partition. They are not unique to my device! Your u-12 should have the exactly same files like I do. Also note, that pre-SP100 firmwares are using different encryptions and may not have those (I didn't bother to check).

The cachain.pem is the trivial one. It contains two CA-certificates issued by Huawei expiring 2040 or so. That is a very common PKI-procedure to have the public certificates in a device to make sure, that the actual certificate being used can be verified to a trusted root-CA. There is very little interesting about that file.

However, the remaining PEM-files are more interesting. The exact purpose of b593cpekey.pem is yet unknown. It is an 3-DES encrypted private key to something. If you want to take a peek into the file, the encryption password is CPE-B593-12 as Mr. Ronkainen dug out of the libraries. A command like this will tell us more:

# openssl rsa -in b593cpekey.pem -noout -text -passin pass:CPE-B593-12
Private-Key: (2048 bit)
...

It is a 2048-bit RSA key. If you know what the key is used for, please tell us.

The remaining files privkey.pem and privkey.b593pem are exactly the same. To me it looks like poor engineering. Libraries seem to be using the latter filename, but my guess is, that somebody is using the first one too. The password for this private key was also recovered by Mr. Ronkainen, it is lteb593. Basic information recovery:

# openssl rsa -in privkey.pem -noout -text -passin pass:lteb593
Private-Key: (1024 bit)
...

Hm. handy, but the really interesting part is where this file is actually used. This information was recovered by Mr. Ronkainen with looking at the GUI admin traffic via Wireshark.

If you go change the admin password at System -> Password change (the frame source would be http://-the-IP-here-/html/management/account.asp), you can see the HTML containing tags for loading a number of JavaScript files, the most interesting ones are /js/account.js and /js/rsa.js. The actual password change code from account.js is:

function AddSubmitParam(SubmitForm,type)
{
  var cfgUsername = ADMIN_USER_NAME;

  SubmitForm.addParameter('cfgUsername',cfgUsername);
  SubmitForm.addParameter('Userpassword',MyRSAEncryptB64(getValue('id_cfmPassword')));
  //SubmitForm.addParameter('Username',ADMIN_USER_NAME);
  SubmitForm.addParameter('OldPassword',MyRSAEncryptB64(getValue('id_oldPassword')));

  SubmitForm.setAction('chgacount.cgi?RequestFile=/html/management/account.asp');

It RSA-encrypts the value from form field with id id_cfmPassword! Wow! They really beefed up their security. The RSA-code is at /js/rsa.js and it contains:

// Return the PKCS#1 RSA encryption of "text" as a Base64-encoded string
function RSAEncryptB64(text) {
  var h = this.encrypt(text);
  if(h) return hex2b64(h); else return null;
}

...

//my encrypt function, using fixed mudulus
var modulus = "BEB90F8AF5D8A7C7DA8CA74AC43E1EE8A48E6860C0D46A5D690BEA082E3A74E1"
             +"571F2C58E94EE339862A49A811A31BB4A48F41B3BCDFD054C3443BB610B5418B"
             +"3CBAFAE7936E1BE2AFD2E0DF865A6E59C2B8DF1E8D5702567D0A9650CB07A43D"
             +"E39020969DF0997FCA587D9A8AE4627CF18477EC06765DF3AA8FB459DD4C9AF3";
var publicExponent = "10001";
function MyRSAEncryptB64(text)
{
    var rsa = new RSAKey();
    rsa.setPublic(modulus, publicExponent);
    return rsa.encrypt_b64(text);
}

It surely is RSA PKCS#1 encryption implemented with JavaScript. That's really cool! A complete PKCS#1 library implemented with a completely wrong language. I didn't realize, that having a fully functional RSA-library with JavaScript was even possible, but there it is.

Next I took the public key modulo and exponent from the above JavaScript-code and used Per Olesen's tool from https://gist.github.com/polesen/2855098 to re-create an actual PEM-file from those ingredients. Mr. Olesen has a nice article Converting RSA public key Modulus and Exponent into PEM file about that.

The resulting PEM-file is:

-----BEGIN PUBLIC KEY-----
MIGeMA0GCSqGSIb3DQEBAQUAA4GMADCBiAKBgQC+uQ+K9dinx9qMp0rEPh7opI5o
YMDUal1pC+oILjp04VcfLFjpTuM5hipJqBGjG7Skj0GzvN/QVMNEO7YQtUGLPLr6
55NuG+Kv0uDfhlpuWcK43x6NVwJWfQqWUMsHpD3jkCCWnfCZf8pYfZqK5GJ88YR3
7AZ2XfOqj7RZ3Uya8wICJxE=
-----END PUBLIC KEY-----

and a simple verify run with OpenSSL for both the private and public keys confirm, that we have a pair:

# openssl rsa -pubin -in privkey.pub.pem -noout -modulus | md5sum
92e88d0b38fe93cd41a000b3c0b1928e  -
# openssl rsa -in privkey.pem -noout -modulus -passin pass:lteb593 | md5sum
92e88d0b38fe93cd41a000b3c0b1928e  -

Both keys have the same modulo in them, thus, they are the private and public parts of the same key. Excellent!

Credits go (as usual) to Mr. Ronkainen for his hard work in hacking the B593. Also Mr. Olesen deserves thanks for his ready-made tool (which btw. builds in my Linux easily) for putting the PEM-parts back together.

Final credits go to Huawei engineers, this time they took data encryption really seriously. However, when you're in a leaking boat, it really doesn't matter if you have the best motor or not, your boat still leaks. In this case the critical information (like encryption keys) are hard-coded, used in every device they manufacture and recoverable in plain-text format. It looks like Huawei is suffering from the weakest-link-in-your-security -syndrom. If your FTP is flakey, you store your SSH-passwords in plain-text format and let people in as they please, they are likely to find this stuff out!

... More to follow about SSH and web-GUI user password encryption. This was a very critical find in the path of full disclosure.

A fellow B593 hacker Mr. Ronkainen from blog.asiantuntijakaveri.fi informed me about his findings regarding /var/curcfg.xml password encryption. This is something I did already spit-ball with him in comments, but this time he had something concrete to show.

This is for decrypting an FTP-password. Since you can set your own, you definitely know what the plaintext password is. His findings are:

exe->Data_DbDecrypt(nil, "llxYjYnY:\021\003\2324\275\241\233Wu\353$Vx;\333#", "", "" <unfinished ...>
exe->strncpy(0x7facddd8, "llxYjYnY", 8)          = 0x7facddd8        (Data_DbDecrypt)
exe->strcpy(0x7facdaf8, "12345678")              = 0x7facdaf8        (Data_getProductInfo)
exe->strncpy(0x7facdb01, "12345678", 9)          = 0x7facdb01        (Data_getKey)
exe->strncat("12345678", "llxYjYnY")             = "12345678llxYjYnY"    (Data_getKey)
<... Data_DbDecrypt resumed> )                   = nil
exe->strcpy(0x4ce009, "BBBB")                    = 0x4ce009

The first call is for the raw input data. It clearly contains 8 characters, a colon (:) and something encrypted after it. Then there is a surprising part, call to a function named Data_getProductInfo() returning hard-coded 12345678 every time. Based on the code, the "product info" is simply concatenated into the Base64-decoded 8 char prefix, forming a 16 byte encryption key.

I've already speculated, that they changed encryption in SP100+ from 3-DES to AES. Based on the function names in firmware libries, combine that with knowledge of block ciphers and give it a go with AES-128 ECB with the above keying. Hey presto! It works!

I wrote a public tool for doing password encryptions/decryptions: http://blog.hqcodeshop.fi/B593/password_recover.php The sources for my web-thing are also there, if you want to use that by yourself.

As you can see from the form, I cannot work with the previous 3-DES stuff. It's simply because I don't know what the key/IV are. There is also another thing with web-GUI and SSH-passwords. They are not using the above keying mechanism. My speculation is, that they are using AES-256 (possibly in ECB-mode) for those, but I have no details about the key.

If you want to test the password recovery, you'll need your /var/curcfg.xml at hand. Pick an encrypted password from that, for example:

<X_FTPServiceInstance InstanceID="1" Username="test" Password="bU50RkQ1T2o6UNkuA7Bdj40/TiNehA6fDw==" FtpUserEnable="1" Privilege="2" Path="usb2_1/../.."/>
or
<WEPKeyInstance InstanceID="4" WEPKey="bU50RkQ1T2o69goRBo2nWOh00YDVCHLGDw=="/>

Select web-form Target as FTP-user, copy/paste the value from XML Password-field into Base64-encoded and klick decrypt. It should give you "test" as Plain-text value. There is another example for Wi-Fi WPA-key, it says WEP in the XML-file, but we can ignore that.

I'll keep investigating the other passwords too. Mr. Ronkainen suggested, that something in the box could be encrypted with PKCS#1, but the block size is off, at least in passwords. Stay tuned for more updates.