13. 개인키 공유 여부 확인

 

일단 개인키와 인증서의 추출은 성공을 했는데 
만약 개인키와 인증서를 모든 장치에서 공유하고 있다면 더 큰 문제가 된다. 

이를 확인하기 위해 제품을 추가로 분석해봤다. 

 

RSW-725R 동일한 모델이다. 
기판 색깔이 흰색으로 바뀐걸 제외하면 구성은 모두 동일하다. 

 

 

1. 부팅 메시지 확인

부팅 메시지를 먼저 확인해봤다. 

 

 

 ets Jan  8 2013,rst cause:1, boot mode:(3,1)

load 0x4010f000, len 1392, room 16 
tail 0
chksum 0xd0
csum 0xd0
v3d128e5c
~ld

 

이번에 확인한 부팅 메시지

 

 ets Jan  8 2013,rst cause:1, boot mode:(3,6)

load 0x4010f000, len 1392, room 16 
tail 0
chksum 0xd0
csum 0xd0
v3d128e5c
~ld

 

이건 기존에 분석한 장치의 부팅 메시지

 

부트 모드가 3.1로 뒷 번호가 다르긴 한데 
나머지는 전부 동일하다. 

 

SDK:2.2.2-dev(38a443e)/Core:2.6.3=20603000/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-16-ge23a07e/BearSSL:89454af
Success to open cert file
cert loaded
Success to open private cert file
private key loaded
Success to open ca
ca loaded
uart tx data : 02, 05, FF, FF, 42, 37, FF, FF, FF, FF, FF, FF, FF, 8F, 03
uart rx data : 02, 06, 51, 01, 42, 32, 01, 31, 32, FF, FF, FF, FF, 24, 03
Device ID Received
Device Type : SW1
Device Register
wifi mode : station mode
Reading Data from File:
data : {"pairing_flag":1,"timeturm":32400,"ssid":"{REDACTED}","pwd":"{REDACTED}","thing_name":"{REDACTED}"}
ssid :{REDACTED}
password :{REDACTED}
File Closed

Connecting to iptime5
mode : sta(3c:e9:0e:e4:a9:b8)
add if0
.....scandone
state: 0 -> 2 (b0)
.state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 2
cnt 

connected with iptime5, channel 13
dhcp client start...
..ip:192.168.0.80,mask:255.255.255.0,gw:192.168.0.1
.
WiFi connected
IP address: 
192.168.0.80
time sync success
Attempting MQTT connection...
AWS endpoint : {REDACTED}
connected
sub cmd1 topic : cmd/ramax/SW1-3CE90EE4A9B8
sub cmd2 topic : cmd2/ramax/SW1-3CE90EE4A9B8
uart tx data : 02, 05, 51, 01, 70, FF, FF, 02, 0E, 2D, 21, FF, FF, 25, 03
uart rx data : 02, 05, 51, 01, 70, 00, 07, 02, 0E, 00, 21, 00, 21, 2E, 03
data length : 136
aws tx data : {"knd":"SW1","ctrl":"ff","sts":"","md":"","opt":"7","sw":"0","vol":"","tmp":"33","rssi":"0","send":"{REDACTED}","time":1754631934}
pm open,type:2 0

 

디버깅 메시지

이번에도 와이파이 패스워드가 노출됐다. 
내용은 거의 동일하다. 

 

 

2. 펌웨어 추출

>python -m esptool --port COM3 flash_id
esptool.py v4.9.0
Serial port COM3
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: 3c:e9:0e:e4:a9:b8
Uploading stub...
Running stub...
Stub running...
Manufacturer: a1
Device: 4015
Detected flash size: 2MB
Hard resetting via RTS pin...

 

펌웨어 정보

 

python -m esptool --port COM3 --baud 74880 read_flash 0x00000 0x200000 firmware.bin

펌웨어 추출

 

 

이번에도 혹시 모를 오류에 대비해 여러번 추출 후 비교했다. 

 

 

3. 파일 추출

여기서도 동일한 위치에서 파일 블록이 발견됐다. 

 

굳이 더 확인할 필요 없을 것 같다. 
이전과 동일하게 추출해보자. 

 

 

dd if=firmware.bin of=pk_block0.der bs=1 skip=$(({REDACTED})) count=$((16*16-5))
dd if=firmware.bin of=pk_block1.der bs=1 skip=$(({REDACTED})) count=$((16*16-5))
dd if=firmware.bin of=pk_block2.der bs=1 skip=$(({REDACTED})) count=$((16*16-5))
dd if=firmware.bin of=pk_block3.der bs=1 skip=$(({REDACTED})) count=$((16*16-5))
dd if=firmware.bin of=pk_block4.der bs=1 skip=$(({REDACTED})) count=$((16*16-5))

cat ./pk_block0.der ./pk_block1.der ./pk_block2.der ./pk_block3.der ./pk_block4.der > pk.der

openssl rsa -in ./pk.der -inform DER -out ./pk.der -outform DER
dumpasn1 ./pk.der

인식이 됐다. 

 

심지어 해시값까지 같다. 
이건 정말 문제가 있다. 

 

 

이미 결과는 나왔지만 그래도 나머지 인증서 두개도 마저 비교해보자. 

 

 

dd if=firmware.bin of=ca_block0.der bs=1 skip=$(({REDACTED})) count=$((16*16-5))
dd if=firmware.bin of=ca_block1.der bs=1 skip=$(({REDACTED})) count=$((16*16-5))
dd if=firmware.bin of=ca_block2.der bs=1 skip=$(({REDACTED})) count=$((16*16-5))
dd if=firmware.bin of=ca_block3.der bs=1 skip=$(({REDACTED})) count=$((16*16-5))
dd if=firmware.bin of=cert_block0.der bs=1 skip=$(({REDACTED})) count=$((16*16-5))
dd if=firmware.bin of=cert_block1.der bs=1 skip=$(({REDACTED})) count=$((16*16-5))
dd if=firmware.bin of=cert_block2.der bs=1 skip=$(({REDACTED})) count=$((16*16-5))
dd if=firmware.bin of=cert_block3.der bs=1 skip=$(({REDACTED})) count=$((16*16-5))

cat ./ca_block0.der ./ca_block1.der ./ca_block2.der ./ca_block3.der > ./ca.der
cat ./cert_block0.der ./cert_block1.der ./cert_block2.der ./cert_block3.der > ./cert.der

openssl x509 -in ./cert.der -inform DER -out ./cert.der -outform DER
openssl x509 -in ./ca.der -inform DER -out ./ca.der -outform DER

모두 같다. 
다수의 장치에서 인증서와 개인키를 포함해서 
펌웨어 자체를 통째로 돌려 쓰고 있는거로 봐도 되겠다. 

 

 

$ openssl rsa  -inform DER -in pk.der -noout -modulus | sha256sum
2ffc65064620e76cafb106aa01949cc274f6636d89fa3a738bed32e8f179006f  -

$ openssl x509 -inform DER -in ./cert.der -pubkey -noout | openssl pkey -pubin -outform DER | sha256sum
dcf68f637fb11e1484b193ae97d6b50833c55bc2ea116983998e3aa44857f619  -

$ openssl x509 -inform DER -in ./ca.der -pubkey -noout | openssl pkey -pubin -outform DER | sha256sum
fbe3018031f9586bcbf41727e417b7d1c45c2f47f93be372a17b96b50757d5a2  -

 

해시값 기록

 

동일한 키를 여러 장치가 공유하는걸 확인했으니 
서버가 장치를 구분하는데 사용되는 정보만 확인된다면 

적어도 동일한 키가 공유되고 있는 모든 장치에 대해서는

장치를 가장한 인증 우회 및 제어가 가능할 것이다. 

 

장치 구분에 쓰이는 정보를 찾고 서버를 통해 제어까지 해보고싶지만 

여기부터는 진짜 불법이다. 
이제 정말로 그만해야겠다.