Mitsubishi Stuff (MAC-577IF2-E)

Device: Ameba1
Processor: ARM Little Endian
Arch: Arm Cortex-M-Family (Armv7-M) ---> ARMv7-M: Cortex-M3 (@166MHz)
Newest firmware: 2021/06/07-22:36:47

section 1: RAM
start: 0x10
length: 306 940 (0x4AEFC)
mapped to: 0x10006000
SRAM (code/data)

section 2: ROM
start: 0x4AF1C
length: 1 101 476 (0x10CEA4)
mapped to: 0x30000000
SDRAM (code/data)

ESV:
1. Base 64 decode it
2. AES decrypt it
3. Resulting data should start with a CSV tag

AES:
128 bit (16 bytes, 32 bytes as a string) key. 10 rounds. Likely static IV
code reads 0x21 = 33 bytes (32 bytes + 00 terminator?) from flash memory at position 0xE7

R4 = R1 from input
R8 = 0x100533AC

key from: 10056C10

Flash Memory:
-BA = Device WPA Key
-C4 = melcloud domain name (form addr: 0x10057BCC)
-E7 = AES key (16 bytes, 128 bit)
-EB = active unique cert (only applies when use unique is true) (form addr: 0x10057C40)
-FD = use unique client cert (form addr: 0x100649F2) (might be exactly the reverse with the above)

-Key is send to server (described as HTTPC frameDataGet_fd() decsec_getdata_fi DECSEC_KEYCODE NG)
-Key is likely updated or can be updated by the server (see readAndWriteKeyFromFlash)
-It seems the key is updated only when it already was set to something else
-Seems viable that the key can be sniffed, but then MelCloud connection might need to be blocked forever to avoid key updates (if melcloud even currently does update it since it has no support for it, with extreme luck the key could be factory flashed to 0)
-Key could be leaked by posing as the server with a trusted CA cert (Amazon or Verisign)

Useful links:
https://blog.dest-unreach.be/2022/06/04/mitsubishi-wifi-adapter/
https://github.com/zacharyrs/ha-melview/issues/2

Contains CA certs for Amazon IoT Core (VeriSign and Amazon Root CA 1)

Routes:
Device allows config changes via web forms:
-Debug settings (publishes to /analyze with post)
-Function settings (publishes to /config with post)
-Factory reset (publishes to /default with post)
-Network settings (publishes to /network with post)
-Server settings (publishes to /server with post)
-Service settings (publishes to /service with post)
-Unit Information (gets from /unitinfo)
-Firmware/Application Update (publishes to /update with post)

Debug settings:
-Analyze (debugStatus to off or on, probably enables the logger)

Function settings:
-Connect internet (serverStatus to yes or no)

Factory reset:
-Factory default configuration (Factory Reset or normal Reset)

Server settings is probably secured, but allows interesting changes:
-Server URL (API Url?)
-Polling cycle (1 to 59 seconds secs/mins/hours/days)
-SPMODE timeout (5, 10, 15 or 20 minutes)
-Default client certificate
-Client certificate (unique or default)

Service settings allows to enable echonet!:
-Enable ecomode (Echonet) (Enable, Disable)

Unit Informations:
-Adapter info (name, version, mac, thermal image timestamp etc.)
-Unit info (unit type, IT version, last error)
-Reload button

Firmware Update:
-chkFirmFile(). Allows user to drop a firmware bin file which is uploaded via multipart/form-data

free routes:
/smart
/adapter_image2.gif
/javaScript.js
/common.css
/license

partially free:
/network apparently on first ever use (root also directs to /network probably)
auth, but accessible as user:
/config because the user password is known (username: user and the KEY password printed on the device sticker, 12 chars, only uppercase and numbers)
auth, locked behind root:
/network
/unitinfo
/service (highly desirable)
/apinfo
/ (root maybe)

auth, locked behind super user:
/server (desirable)
/update
/updateFinish
/updateFail
/default

auth, locked behind admin:
/analyze

Server page settings:
url: Server URL
cycle: Polling Cycle
unit: min/sec/hour/day
spmode: SPMODE timeout (5 to 20 min)
DefCliCert: Default client certificate (dynamically populated list of options)
CliCert: Client certificate (unique/default)

If DefCliCert is set, it seemingly always forces CliCert to unique and sets it as the new default cert. CliCert to unique without actually setting a cert does nothing. If DefCliCert is not set, nothing will happen unless CliCert was set to default and differs from the current value on storage, if so it will switch back to default cert


Cipher Suites supported:
Weak:
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA (weak, TLS 1.0 to 1.3)
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA (weak, TLS 1.0 to 1.3)
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256 (weak, TLS 1.2 to 1.3)

Secure:
TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256 (secure, TLS 1.2 to 1.3)

Weak:
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA  (weak, TLS 1.0 to 1.3) (probably weakest total?)
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA (weak, TLS 1.0 to 1.3)
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256 (weak, TLS 1.2 to 1.3)

Secure:
TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256 (secure, TLS 1.2 to 1.3)

Secure:
TLS-RSA-WITH-AES-128-GCM-SHA256 (secure, TLS 1.2 to 1.3)

Weak:
TLS-RSA-WITH-AES-128-CBC-SHA256 (weak, TLS 1.2 to 1.3)
TLS-RSA-WITH-AES-256-CBC-SHA256 (weak, TLS 1.2 to 1.3)
TLS-RSA-WITH-AES-128-CBC-SHA (TLS 1.0 to TLS 1.3)  (probably weakest total?)
TLS-RSA-WITH-AES-256-CBC-SHA (TLS 1.0 to TLS 1.3)

Curves supported:
secp256r1

Signature algorithms supported:
RSA_MD5 (weakest)
RSA_SHA1
RSA_SHA224
RSA_SHA256
ECDSA_SHA1
ECDSA_SHA224
ECDSA_SHA256

Symmetric block cipher algorithms:
AES-256-CBC

Message digest algos:
md5 (weakest)
sha1
sha224
sha256



Possible avenues into the device:
1. Crack the user:admin password, then can enable echonet on the service page for local control. For complete control can also manipulate server page settings. Can possibly switch CA between VeriSign and Amazon with the default/unique option. Amazon might be enabled by default on top of the custom CA. Get a valid signed Amazon cert by hosting on their servers. However can not switch the URL without access to the server page, since dynamic manipulation would break TLS

2. Read out flash memory from NVRAM to read the AES key, then block MelCloud to avoid updates of the key and can use the /smart API with encrypt/decrypt

3. Abuse some vulnerability in the TLS ciphers to decrypt the traffic and obtain the AES key. Since the server still supports http fallback, maybe it also supports some very old insecure ciphers, so you could try something like Logjam: https://github.com/concise/logjam-attack-poc
Also see: https://security.stackexchange.com/questions/197028/how-to-eavesdrop-and-decrypt-the-https-communication-of-an-iot-device


1 in more detail with ideal attack vector:
Crack the user: admin password by ensuring wifi controller is set to factory settings, then connect laptop directly to it. Position laptop as close as possible, eliminate all background processing. Run berkeley sockets in small C visual studio app or maybe a linux system to further reduce timing inconsistencies. Test it out by authing to the /config page with user:KEY scheme and see if you get a 200 success response for a GET. Measure time from upon finishing sending the last block of data before server starts to work to the incoming of the result as precise as possible with the highest accuracy available clock. Do a few tests to the /config page by only getting one base64 character right vs getting all but one right and also test difference between 1 and 2 right. With enough background data begin targeting the /analyze page which will only have one match for the user admin. Try unknown 2 base64 characters (starting from past colon since admin is perfect) at a time (64 * 64 possibilities = 4096 tries) and record each timing for the first character [0-63]. Note which FIRST character to be tested out of the 64 possibilities got the longest avg timing by checking each list all entries. If difference is apparent right away, can try to reduce further loops by detecting early if a character's avg is higher upon finishing the 64 loops than the prior checked character by a significant enough margin. Eventually will get a full match and a 200 success response

With user: admin and the admin password, can access the /service page (that root also can access) and enable echonet (easy API for everyone with existing libraries)
With the admin credentials, can access the /server page (that super user also can access), backup existing server url and cert settings and then set the server url to a AWS IoT Core or API Gateway domain (with matching cert setting), which allows dumping the client-server communication and the device AES key for the /smart route

Mitsubishi uses AWS IoT Core with MQTT for debug/dev. That's why they added the following 2 CAs to their trust store:
VeriSign (legacy so probably no longer the default) (might be 'unique' now) for iot:Data. VeriSign Class 3 Public Primary G5 root CA certificate

Amazon CA (hopefully the default) for iot:Data-ATS. Amazon Trust Services

Device uses RSA-based certificate validation and not ECC because it omits the other Amazon CA certs outside 1:
"If you cannot store all of these certificates on your device and if your devices do not use ECC-based validation, you can omit the Amazon Root CA 3 and Amazon Root CA 4 ECC certificates. If your devices do not implement RSA-based certificate validation omit Amazon Root CA 1"

Could also use the AWS API Gateway: https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started.html


Cracking the admin password info:
-Max password plain text length: 65 characters
-User password comes from flash memory: 0xBA (Wifi Key) (64 chars max, in practice only 12), the other 3 passwords come from a secret store:
secret 0 = decsec_keycode: offset 0, 32 byte length
secret 1-2: 65 byte length max
secret 3 = root pw: offset 0xA2, 65 byte length max
secret 4 = super user pw: offset 0xE3, 65 byte length max
secret 5 = admin pw: offset 0x124, 65 byte length max
secret 6 = offset 0x400, 9216 byte length max (maybe root cert?)
secret 7-8: 3072 byte length max (likely certs?)
This data might get populated from some other non reprogrammable memory set

secretBase = 0x30087AD4

Only reasonable way of attack would be via a timed side channel attack since the password comparison is done using strcmp on base64 hashes.
Use Linux. Use hardware timestamps at the nanosecond level. Directly capture network traffic at the adapter level to get the most accurate timings free from application noise

@166MHz
166 000 000 cycles per second
8-18 instruction difference between matching 0-2 characters
166 000 instructions per ms
0,166 instructions per ns
108 ns difference at max