'하드웨어 해킹 및 임베디드'에 해당되는 글 20건

car-hacking · GitHub Topics · GitHub

NVD - CVE-2022-38766 (nist.gov)

GitHub - AUTOCRYPT-IVS-VnV/CVE-2022-38766: PoC for vulnerability in Renault ZOE Keyless System(CVE-2022-38766)

- HackRF One + Portapack H2
- GNURadio
- GQRX
- Universal Radio Hacker
- rtl_433

How I Hacked my Car :: Programming With Style

HackRF / Yard Stick / Ubertooth 

Tag: CarHacking | 腾讯科恩实验室官方博客 (tencent.com)

GitHub - commaai/opendbc: democratize access to car decoder rings

CAN ID 별 서비스 목록

Rolling PWN

UART로 펌웨어 접근해보기 (tistory.com)

장비들의 펌웨어를 얻는 방법은 여러가지가 있다.

1. 제조사가 제공하는 펌웨어 받기

제조사에서는 펌웨어의 주기적인 패치를 내놓고 그것을 자신들의 홈페이지에서 제공하는 경우가 왕왕 있다.

보안적인 측면에서 권장 사항은 자체적으로 업데이트를 하는 것인데, 그 이유로는 낮은 버전의 펌웨어를 사용자 임의로 올려버릴 수 있기 때문이다.

2. 자동/수동 업데이트 시 network packet sniffing

요즘 나오는 기기들을 보면 거의 다 자체 앱이 있고 거기서 업데이트를 지원한다. 업데이트를 눌러놓고 패킷을 스니핑해보자. 사실 이 방법은 요즘에 나온 기기들이라면 거의 다 불가능하다.

제조사마다 업데이트 서버와 통신을 할텐데 암호화 통신을 한다면 우리는 중간에 패킷을 가로채도 펌웨어 파일을 찾을 수 없기 때문

network pacekt capture는 wireshark나 network miner 같은 툴이 있는데, 이 프로그램들에서 파일을 뽑는 방법은 각각 다르다.

wireshark는 File - Export Objects 메뉴에서 가능하고 network miner는 그냥 pack capture만 해도 파일을 뽑을 수 있다.

network miner가 이 부분에서 간편하다고 생각한다.

3. UART나 JTAG 같은 디버깅 포트를 이용한 shell 접근

이 방법을 이용하기 위해서는 장비의 회로 기판을 뜯어봐야 한다. 운이 좋으면 돌출되있고 RX, TX라고 적혀있는 핀을 바로 찾을 수 있을텐데 그게 바로 UART pin이다.

권장 보안 정책은 회로 기판을 구성하고 있는 녀석들의 식별이 불가능하도록 마스킹을 지우고, 돌출되어 있는 핀들을 없애야 한다. 

또 이 핀과 통신하기 위해서는 'USB to TTL'이라는 장비가 필요하다. 장비라고 해서 그렇지 그냥 케이블이다.

실제 장비에서 UART PINUSB to TTL

위에 회로들을 보면 돌출되어 있는 경우도 있고 2번째 사진처럼 돌출된 부분이 없는 경우가 있다. 그 경우에는 'USB to TTL'의 피복을 벗겨서 접촉시키던지 해야한다.

그리고 각 핀마다 전원, 접지, RX, TX 역할을 하기 때문에 회로에서 각각의 핀 식별과 'USB to TTL'에서도 식별을 해야한다.

RX, TX는 아래와 같이 연결해줘야 한다.

A와 B가 연결한다면 A의 TX는 B의 RX에, A의 RX는 B의 TX에 연결해주자.

Receive, Transmit의 약자입니다... 받고..보내는...그런..

UART로 컴퓨터와 통신해보자

만약 RX, TX도 제대로 붙이고 컴퓨터에 연결했다면 putty나 Xshell 같은 프로그램으로 serial 통신을 해봅시다.

serial 통신을 할 경우에는 baudrate라는 것을 맞춰줘야 합니다. baudrate는 초당 보내는 데이터의 수를 의미하고 UART에서는 high/low를 구분할 수 있는 clock 역할을 합니다.

만약 장비의 baudrate와 맞지 않게 설정을 하면 아래와 같이 나옵니다. 알아볼 수 없는 녀석들이 나옵니다.

baudrate를 찍어서 맞췄다면 아래처럼 알아볼 수 있는 글자들이 나옵니다.

운이 좋으면 바로 shell을 얻고 펌웨어 분석이 가능하지만, 제가 분석한 장비는 바로 shell을 얻을 수 없었습니다.

여러분들은 출시된지 오래된 장비를 뜯어보세요..

4. MCU의 TX, RX에 직접 접근해보기

만약 회로 기판에 UART, JTAG가 없다면 어떡하냐... 바로 MCU에 직접 접근해야 합니다. 회로를 보면 MCU(micro control unit)가 보일겁니다. 검정색 등딱지에 다리를 엄청 많이 가진 녀석입니다. 

이 녀석이 머리입니다. 모든 기능을 담당하는데요, 아래는 제가 분석한 장비에 있던 MCU의 data sheet입니다.

MCU를 보면 품명이 적혀있을겁니다. 그것의 data sheet를 얻어내면 각 핀의 역할을 알 수 있고 직접 접근이 가능합니다.

너무 오래된 녀석이면 data sheet 구하기가 쉽지는 않습니다. 근데 오래된 장비면 UART 식별이 쉽게 가능해서 이 단계까지 오지 않을 겁니다.

5. Flash memory desoldering 후 dump

최후의 보루입니다. 회로에서 Flash memory를 납땜을 녹여서 제거해내고 data sheet를 참고해서 아두이노나 라즈베리파이에 연결해서 덤프를 뜨는 겁니다. 

Flash memory 안에 있는 모든 것들을 볼 수 있기 때문에 확실한 방법이긴 한데요, 다시 재조립해서 무사히 동작한다는 보장이 없습니다. 인두기, 땜납 등 특수한 장비가 필요하기도 합니다.

[IoT 기기 진단] UART 디버깅 포트 점검 (소개) (tistory.com)

개인적으로 IoT 기기 진단 또는 IoT 보안 점검을 분류하면 크게 아래처럼 나눌 것 같습니다.

1. Device : IoT 기기의 물리적 보안 조치 (디버깅 포트 제거, 장비 접근 보호 등)

2. Firmware : IoT 기기 펌웨어 암호화, 내부 정보 유출, 바이너리 분석 등 

3. Network : NW단의 트래픽 성능이나 DDoS에 대한 대응 점검 (트래픽 발생기 활용)

4. Service : IoT와 연동되는 웹 또는 모바일 페이지 점검 (OWASP Top10 등 웹, 모바일 취약점)

그 중에 Device 부분은 개발을 위한 디버깅 포트를 통해 공격을 시도해볼 수 있습니다.

이런 취약점 포인트인 디버깅 포트로는 대표적으로 UART와 JTAG가 있습니다.

이 포스트에서 UART 포트를 통한 점검 방법에 대해 전부는 아니지만 실무 경험을 바탕으로 포스팅해볼꼐요.

[UART 란]

Universal asynchronous receiver/transmitter의 약자로 범용 비동기 송수신기 입니다.

병렬 데이터 형태를 직렬 데이터 형태로 전환하여 데이터를 전송하는 시리얼 통신 규격 입니다.

- UART 핀 종류

아래와 같이 4가지 PIN으로 구성되며 해당 전압이 각각 조금씩 다흡니다.

전원을 공급하는 VCC가 존재하며, 전압을 맞추는 GND가 존재합니다. 

보통은 전원 공급은 기기나 PC에서 지원되기 때문에 VCC 포트는 연결하지 않아도 무방합니다.

따라서 아래와 같이 점검도구 쪽의 UART 포트 RX와 점검대상 기기 쪽의 UART 포트 TX를 연결하고

반대로 점검도구 쪽의 TX와 점검대상 기기 쪽의 RX를 연결합니다. 그리고 GND 끼리 연결해 전압을 맞춥니다.

[점검 목적]

UART 디버깅 포트를 통해 중요정보 또는 시스템 정보 획득이 가능하며, 부트로더 접근이 가능할 경우 더 큰 위험에 노출되기 때문에 사전에 점검해야 합니다.

위험에 노출될 경우 디버깅 Root Shell을 통해 관리자 권한이 탈취될 수 있으며, 추가로 덤프를 통한 기기의 펌웨어 획득이나 시스템 변조, 중요 정보 탈취 통해 2차 공격으로 이어질 수 있습니다.

[개선 방법]

UART 포트는 일반적으로 상용에 배포될 때는 제거하고 출시하는 것이 안전하며,

부득이하게 존재할 경우에 1차적으로 물리적인 실링 처리를 하는 조치가 있으며, 2차적으로는 접근하는 디버깅 쉘에 히든키(Magic Key)와 인증키를 적합하게 사용하여 불법적인 접근을 방지하는 것이 안전합니다.

[점검 장비]

먼저, UART 연결을 위한 통신 도구인 AD-USBISP가 필요합니다. (USB 형식이 아닌 도구들도 있는 걸로 알고 있어요.)

그리고 연결을 해줄 점퍼 케이블이 필요합니다. 

- AD-USBISP V03.6

- 점퍼 케이블

위 두가지를 모두 연결 해놓은 세트로 구비하는 것이 좋은 것도 같습니다.

그리고, 기기에서 UART 포트를 탐색하기 위해 멀티 테스터(멀티 미터)가 필요합니다. 육안으로 구별할 수 있다면 필수는 아니지만 보조 도구로 필요합니다.

추가로 IoT 기기를 분해할 수 있는 드라이버나 UART 포트 핀, 점퍼를 고정해야 한다면 인두가 필요할 수도 있습니다.

(허가 되지 않은 점검도구 활용 스캔은 법적 문제 소지가 있으니 주의!)

다음 포스트를 통해 점검하는 기본 시나리오를 포스팅 할께요.

[IoT 기기 진단] UART 디버깅 포트 점검 (시나리오) (tistory.com)

지난 포스트에 이어서 이번에는 UART 디버깅 포트의 점검 시나리오를 알아보겠습니다.

[점검 시나리오]

제 경험상, 일반적으로 점검 시나리오는 아래와 같이 3가지 단계로 나눠볼 수 있습니다.

UART 포트 물리적 탐색 -> UART 포트/장치 연결 -> Serial 포트로 접속

1. UART 포트 물리적 탐색

먼저 IoT 단말에서 UART 의심 포트를 육안으로 확인해야 합니다.

일반적으로 UART 포트의 생김새가 어떤지 알고 있고 경험이 있으면 더 분별하기 쉽습니다. 다양한 UART 포트 케이스가 있기 때문에 확실히 하기 위해서는 멀티 테스터를 사용하여 전압을 측정하는 방법을 사용합니다.

보통 4PIN 포트가 UART 포트인 경우가 많으며, Debug나 UART 등의 문자열이 표시된 경우도 있습니다.

또는 각 PIN의 이름이 TX, RX, GND, VCC 이렇게 각각 표시되어 있는 경우도 있습니다.

또 위에 사진처럼 PIN이 PIN 모양이 아니라, 특이하게 생긴 경우도 볼 수 있습니다.  

문자가 표기되어 있는 경우가 아니라면, UART 포트를 확신하기 힘들기 떄문에 멀티 테스터를 사용하여 확인 합니다.

멀티 테스터의 검은선을 GND에 접촉시키고, 각 PIN을 대보면서 전압을 측정합니다.

(특정 PIN을 GND로 특정하여 가정한 후 진행하며, 반응이 없을 때는 다른 PIN을 GND로 가정하는 것을 반복합니다.)

각 PIN의 전압이 아래 표에 있는 PIN 전압 또는 기타 레퍼런스들을 참고하여 어떤지 확인하고 예측하여 확인합니다.

3.3V(혹은 5v)의 전압이 잡히면 (-) 리드선은 GND / (+) 리드선은 VCC 일 확률이 높으며,

3V의 경우 TX, 모두가 아니라 극히 낮은 전압이라면 RX일 확률이 크니 참고하면 됩니다.

(멀티 테스터가 없는 경우에는 LED 불 장비나 PCB 특성을 이용할 수도 있습니다.)

2. UART 포트/장치 연결 

아래와 같은 USB-ISP 점검 도구를 사용하겠습니다.

USB를 점검 PC나 노트북의 USB 포트에 연결하고, PIN들을 알맞게 점검 대상 장비의 UART 포트에 연결합니다.

TX와 RX를 교차하고 GND끼리 연결 합니다. (잘 이해가 안되시는 분은 앞 포스트 설명 참고 하시면 더 좋을 것 같아요.)

사진에서처럼 USB-ISP 점검 도구에 파란색/빨간색 불이 들어온 것을 보고 전류가 통하고 연결이 된 것을 대충 예상할 수 있습니다.

3. Serial 포트로 접속

물리적 연결을 완료하면, 점검 PC의 장치관리자에서 연결된 COM 포트 번호를 확인할 수 있습니다.

COM3으로 제대로 연결이 되어 인식되고 있습니다.

그 다음은 시리얼 통신을 지원하는 원격 쉘 프로그램을 사용합니다. 가장 간편하게 사용하는 Putty를 사용하겠습니다.

아래와 같이 putty에서 SSH의 Serial 통신 부분을 선택하고 첫 칸에 COM3(장치관리자에서 나타난 USB Serial Port로 입력)를 기입합니다.

그리고 Speed 부분, Baud Rate 부분에는 115200(기본값)으로 연결을 하여 시도합니다.

Baudrate(보레이트)는 1초에 몇 개의 신호를 보낼 것인가를 정하는 것으로 이 값이 맞지 않으면 정상적으로 디버깅 쉘로 진입할 수가 없습니다.

(보레이트는 높을수록 데이터 전송 속도가 빠릅니다.)

보통 115200, 57600, 38400, 19200, 9600 순으로 Brute Force Attack하여 Buad Rate를 맞춥니다.

만약 디버깅 쉘이 내용은 뜨는데 깨져서 알아보기 힘들다면 Baud Rate의 문제일 수도 있습니다. Baud Rate를 점검대상 기기 단말의 Baud Rate와 맞춰주면 해결될 수도 있습니다.

성공한다면 로그인 로그나 메시지들이 뜨기도 하며,

로그인 쉘이 나옵니다. (아무 것도 안나오다가 Magic Key를 눌렀을 떄 나오도록 보안조치된 경우도 존재함)

(허가 되지 않은 점검도구 활용 스캔은 법적 문제 소지가 있으니 주의!)

국내 블로그에서 이런 글을 보는 날이 오다니...

ufo.stealien.com/r&d/2020/10/29/can_bus_1.html