3. 동적 분석

제품을 대상으로 동적 분석을 시도해보자. 
뭔가 단서가 될만한게 나올지도 모른다. 

 

 

1. 개방된 포트 확인

이 제품은 외부 와이파이에 연결해서 서버와 통신하는 방식으로 동작한다. 
장치에 열려있는 포트가 있다면 뭔가를 시도해볼 수 있을지도 모른다. 

 

방금 연결된 이게 분석 중인 IoT장치다. 

 

 

일단 ping은 받는다. 

장치에 포트 하나 쯤은 열려있을 줄 알았는데 
스캔을 해봤지만 열려있는게 아무것도 없다. 

 

ip를 잘못 잡았나 싶어 다시 확인해봤지만 주소는 확실히 맞다. 

패킷 캡쳐를 할 수 있으면 좋을텐데 모바일 환경이라 제한이 많다. 

 

 

그래도 아직 시도할 수 있는게 하나 더 있다. 

 

장치를 어플에 등록하기 위해서는 

먼저 장치가 임시로 생성하는 와이파이에 연결을 해서, 
장치가 사용하게 될 공유기 정보를 입력해야한다. 

 

와이파이가 생성됐을 때 어떤 포트가 개방되는지를 확인해봐야겠다. 

 

 

장치에서 와이파이 생성 후 연결

 

기본 게이트웨이 10.0.0.1

 

포트 스캔

 

9999딱 하나 나왔다.

근데 저게 무슨 포트인지를 모르겠다. 
저걸 어떻게 건들 수 있을지도 펌웨어 코드를 봐야 정확히 알 수 있을 것 같다. 

 

일단 넘어가자. 

 

 

2. 통신 대상 확인

장치가 어디랑 통신하는지 확인해봐야겠다. 

 

 

셸을 따놓은 공유기에 장치를 연결시키고 NAT 정보를 확인했다. 

MAC 주소가 69:7c로 끝나는 192.168.1.101이 장치에 할당된 주소다. 

시간 동기화로 추정되는 요청을 제외하면 전부 54.xx.xx.xx 주소로 요청을 보냈다. 

이게 서버의 주소일 것이다. 

 

서버 포트는 8883이 사용됐다. 
secure-MQTT로 예약된 포트다. 
인증서가 쓰였을테니 패킷 캡쳐는 현실적으로 힘들 것 같다. 

그래도 장치에 민감한 정보가 들어있다는 것은 확인했다. 

 

 

$ curl https://{REDACTED}
curl: (60) SSL: no alternative certificate subject name matches target host name '{REDACTED}'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

 

https로 요청을 보내봤지만 인증서 문제인지 secure connection이 안된다. 
insecure 허용하고 다시 해보자. 

 

 

$ curl -k https://{REDACTED}
{"message":"Not Found","traceId":"{REDACTED}"}

 

그렇지! 뭔가 넘어왔다. 

not found면 서버는 살아있고 요청 경로가 문제였을거다. 

 

근데.. 여기서 더 파면 문제가 될 수 있을 것 같으니 뭔가를 더 시도하지는 말자. 

 

 

2.1 브라우저로 접속 테스트

일단 443 포트는 curl로 본 것과 똑같이 응답이 온다. 

 

 

아까 봤던 8883으로 가보자. 

 

이동을 누르면 인증서를 선택하라고 나온다. 
클라이언트 인증을 요구하는 모양이다. 

 

지난번에 펌웨어에 장치가 쓰는 인증서가 있지 않았나?

 

한번 추출을 해보자. 

 

 

2.2 인증서 추출 시도

$ binwalk esp_backup.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
402130        0x622D2         AES Inverse S-Box
402386        0x623D2         AES S-Box
411384        0x646F8         SHA256 hash constants, little endian
1049093       0x100205        Certificate in DER format (x509 v3), header length: 4, sequence length: 833
1051141       0x100A05        Certificate in DER format (x509 v3), header length: 4, sequence length: 857
1053189       0x101205        Private key in DER format (PKCS header length: 4, sequence length: 1188

 

지난번에 확인한 binwalk 결과다. 
MQTT 통신에 사용하는 것으로 추정되는 개인키와 인증서 두개가 들어있다. 

 

 

dd if=esp_backup.bin of=cert1.der bs=1 skip=1049093 count=837
dd if=esp_backup.bin of=cert2.der bs=1 skip=1051141 count=861

 

인증서 두개 추출

 

 

$ openssl x509 -in cert1.der -inform DER -text -noout
Could not read certificate from cert1.der
Unable to load certificate

 

..을 했는데 인식이 안된다

 

추출을 잘못했나? 

뒤에 널바이트가 왜 이렇게 많지?

 

 

정상적인 인증서를 받아와서 비교해봤는데 
앞부분이 멀쩡한걸 보면 추출 위치를 잘못 잡은 건 아니다. 

 

 

0x0341이면 833이니까 헤더 포함 837이 맞다. 
크기를 잘못 잡은 것도 아니다. 

 

 

펌웨어가 추출 과정에서 일부 손상됐을 가능성을 생각해서 
여러번 다시 추출해서 비교해봤지만 펌웨어에도 이상은 없었다. 

 

 

$ openssl asn1parse -in ./cert2.der -inform DER
    0:d=0  hl=4 l= 857 cons: SEQUENCE
    4:d=1  hl=4 l= 577 cons: SEQUENCE
    8:d=2  hl=2 l=   3 cons: cont [ 0 ]
   10:d=3  hl=2 l=   1 prim: INTEGER           :{REDACTED}
   13:d=2  hl=2 l=  20 prim: INTEGER           :{REDACTED}
   35:d=2  hl=2 l=  13 cons: SEQUENCE
   37:d=3  hl=2 l=   9 prim: OBJECT            :{REDACTED}
   48:d=3  hl=2 l=   0 prim: NULL
   50:d=2  hl=2 l=  77 cons: SEQUENCE
   52:d=3  hl=2 l=  75 cons: SET
   54:d=4  hl=2 l=  73 cons: SEQUENCE
   56:d=5  hl=2 l=   3 prim: OBJECT            :{REDACTED}
   61:d=5  hl=2 l=  66 prim: UTF8STRING        :{REDACTED}
  129:d=2  hl=2 l=  30 cons: SEQUENCE
  131:d=3  hl=2 l=  13 prim: UTCTIME           :{REDACTED}
  146:d=3  hl=2 l=  13 prim: UTCTIME           :{REDACTED}
  161:d=2  hl=2 l=  30 cons: SEQUENCE
  163:d=3  hl=2 l=  28 cons: SET
  165:d=4  hl=2 l=  26 cons: SEQUENCE
  167:d=5  hl=2 l=   3 prim: OBJECT            :{REDACTED}
  172:d=5  hl=2 l=  19 prim: UTF8STRING        :{REDACTED}
  193:d=2  hl=4 l= 290 cons: SEQUENCE
  197:d=3  hl=2 l=  13 cons: SEQUENCE
  199:d=4  hl=2 l=   9 prim: OBJECT            :{REDACTED}
  210:d=4  hl=2 l=   0 prim: NULL
  212:d=3  hl=4 l= 271 prim: BIT STRING
  487:d=2  hl=2 l=   3 prim: INTEGER           :{REDACTED}
Error in encoding
808B124DAA7D0000:error:0680009B:asn1 encoding routines:ASN1_get_object:too long:../crypto/asn1/asn1_lib.c:95:

 

인코딩 에러다. 

 

 

2.3 개인키 추출 시도

dd if=esp_backup.bin of=private_key.der bs=1 skip=1053189 count=1188

 

개인키도 추출해보자. 

같은 문제가 생기는지 확인해야겠다. 

 

 

$ openssl rsa -inform DER -in private_key.der -out private_key.pem
Could not open file or uri for loading private key from private_key.der
80CBDD5C177B0000:error:16000069:STORE routines:ossl_store_get0_loader_int:unregistered scheme:../crypto/store/store_register.c:237:scheme=file
80CBDD5C177B0000:error:1608010C:STORE routines:inner_loader_fetch:unsupported:../crypto/store/store_meth.c:359:No store loader found. For standard store loaders you need at least one of the default or base providers available. Did you forget to load them? Info: Global default library context, Scheme (file : 0), Properties (<null>)

 

pem 파일 생성 실패다. 

 

얘도 인증서랑 비슷한 상황인 것 같다. 

 

 

$ dumpasn1 private_key.der
   0 1188: SEQUENCE {
   4    1:   INTEGER 0
   7  257:   INTEGER
         :     {REDACTED}
         :             [ Another 129 bytes skipped ]
 268    9:   [PRIVATE 23] {
 270  119:     [0]
         :       {REDACTED}
Error: Inconsistent object length, 112 bytes difference.
         :     }
 391   83:   [APPLICATION 6]
         :     {REDACTED}

Error: Invalid data encountered at position 478: CC F7.

 

앞이 멀쩡한데 뒤만 깨져있다. 

 

 

생각해보니 바보짓을 했다.

개인키같은걸 평문으로 넣어놨을리가 없는데 그냥 파싱이 될리가 없지. 

암호화까지는 아니더라도 추출을 어렵게 하려고 제조사에서 뭔가 조치를 해놨을 거다. 

 

펌웨어에서 키를 한번 꺼내봐야겠다.