퍼즈 테스트가 IoT 장치 보안을 강화하는 방법

퍼즈 테스트는 엔지니어가 임베디드의 약점을 찾는 데 사용할 수 있는 중요한 장소입니다. IoT 장치 인터페이스를 강화하기 위해 고려해야 합니다.

IoT 장치의 확산으로 임베디드 보안 공격이 증가하고 있습니다. 역사적으로 임베디드 시스템 엔지니어는 버그에 취약한 임베디드 장치의 많은 영역에도 불구하고 장치 계층 보안을 무시했습니다. 직렬 포트, 무선 인터페이스, 프로그래밍/디버깅 인터페이스까지 모두 해커가 악용할 수 있습니다. Fuzz 테스트는 엔지니어가 임베디드 장치의 약점을 찾는 데 사용할 수 있는 중요한 장소이며 IoT 장치 인터페이스를 강화하기 위해 고려해야 합니다.

퍼즈 테스팅이란 무엇입니까?

퍼즈 테스팅은 셰익스피어를 쓰기 위해 무작위로 타이핑하는 신화 속의 백만 원숭이와 같습니다. 실제로 픽션 작품은 간단한 구문을 생성하기 위해 많은 무작위 조합이 필요하지만 임베디드 시스템의 경우 알려진 좋은 문장에서 몇 글자만 변경하면 됩니다.

퍼즈 공격을 구현하기 위해 수많은 상용 및 오픈 소스 도구를 사용할 수 있습니다. 이러한 도구는 퍼즈 벡터 또는 공격 벡터라고도 하는 임의의 바이트 문자열을 생성하고 테스트 중인 인터페이스에 제출하여 버그를 나타낼 수 있는 결과 동작을 추적합니다.

퍼지 테스트는 숫자 게임이지만 가능한 입력을 무한대로 시도할 수는 없습니다. 대신 퍼즈 벡터 제출 속도, 퍼즈 벡터의 효율성, 버그 탐지 알고리즘을 극대화하여 테스트 시간을 최적화하는 데 중점을 둡니다.

퍼즈 테스트 개념

많은 퍼즈 테스트 도구가 PC 응용 프로그램을 테스트하도록 설계되었기 때문에 내장 코드를 기본적으로 컴파일된 PC 응용 프로그램으로 실행하면 더 쉽게 적용할 수 있습니다. PC에서 임베디드 코드를 실행하면 성능이 크게 향상되지만 두 가지 단점이 있습니다. 첫째, PC 마이크로프로세서는 임베디드 마이크로컨트롤러와 동일하게 반응하지 않습니다. 둘째, 하드웨어와 관련된 모든 코드를 다시 작성해야 합니다. 그러나 실제로는 PC에서 실행하는 것의 장점이 단점보다 큽니다. 진짜 장벽은 PC에서 기본적으로 컴파일하기 위해 코드를 이식하는 것의 어려움입니다.

퍼즈 벡터가 버그를 유발하는지 어떻게 알 수 있습니까? 충돌은 발견하기 쉽지만 재설정을 유발하는 퍼즈 벡터를 식별하는 것은 더 어렵습니다. 메모리 오버플로 버그 또는 스트레이 포인터 쓰기(해커에게 가장 중요한 버그 유형)는 일반적으로 충돌이나 재설정을 일으키지 않기 때문에 시스템 외부에서 식별하는 것이 거의 불가능합니다.

GCC 및 Clang과 같은 많은 최신 컴파일러에는 메모리 삭제라는 기능이 있습니다. 이것은 사용 여부에 따라 메모리 블록을 깨끗하거나 더티로 표시하고 더티 메모리에 액세스하려는 모든 시도에 플래그를 지정합니다. 그러나 메모리 삭제는 플래시, RAM 및 CPU 주기를 소모하므로 임베디드 장치에서 실행하기 어렵습니다. 따라서 대신 코드의 하위 집합을 테스트하거나 더 많은 리소스가 포함된 기기 버전을 구축하거나 PC를 사용할 수 있습니다.

테스트의 효율성은 실행된 코드의 양으로 평가할 수 있습니다. 여기에서도 컴파일러는 빵 부스러기 서브루틴 호출을 사용하여 메모리 사용량을 추적할 수 있습니다. 코드 커버리지 라이브러리는 각 코드 경로에 대한 사용 값 테이블을 유지하며, 빵 부스러기가 실행될 때 값을 증가시킵니다.

그러나 코드의 대부분이 퍼즈 벡터에 액세스할 수 없기 때문에 코드 커버리지 번호는 임베디드 퍼즈 테스트를 위해 해석하기 까다롭습니다. 예를 들어 인터페이스와 독립적으로 실행되는 주변 장치용 장치 드라이버. 따라서 임베디드 시스템에 대한 "완벽한 코드 적용 범위"를 정의하기는 어렵습니다. 아마도 임베디드 코드의 20%만 액세스할 수 있습니다. 또한 코드 적용 범위는 많은 양의 플래시, RAM 및 CPU 주기를 소모하며 실행하려면 특수 하드웨어 또는 PC 대상이 필요합니다.

버그 보고

퍼지 테스트가 원하지 않는 동작을 일으키는 벡터를 찾으면 자세한 정보가 필요합니다. 버그는 어디에서 발생했습니까? 호출 스택의 상태는 무엇입니까? 특정 유형의 버그는 무엇입니까? 이 모든 정보는 버그를 분류하고 결국 수정하는 데 도움이 됩니다.

버그 분류는 퍼즈 테스트에서 중요합니다. 새로운 fuzz 프로젝트는 종종 많은 버그를 발견하며 심각도를 자동으로 결정할 수 있는 방법이 필요합니다. 또한 퍼즈 버그는 종종 코드 경로 아래에서 추가 버그를 마스킹하기 때문에 버그를 차단하는 경향이 있습니다. 퍼지 테스트 중에 문제가 발생하면 빠른 해결 방법이 필요합니다.

임베디드 클라이언트는 PC만큼 자신의 정보를 공개하지 않습니다. 일반적으로 충돌로 인해 장치가 재설정되고 다시 시작됩니다. 현장에서는 이것이 바람직하지만 장치의 상태를 지우므로 충돌이 발생했는지, 어디서 또는 왜 발생했는지, 사용된 코드 경로를 파악하기 어렵습니다. 엔지니어는 일관된 재생 벡터를 찾은 다음 디버거를 사용하여 잘못된 동작을 추적하고 버그를 찾아야 합니다.

퍼지 테스트에서 테스트는 몇 가지 버그에 대해 수천 개의 충돌 벡터를 생성하여 버그가 있는 시스템에 대한 잘못된 인상을 줄 수 있습니다. 동일한 기본 버그와 관련된 벡터를 신속하게 결정하는 것이 중요합니다. 임베디드 장치의 경우 충돌 자체의 위치는 일반적으로 버그에 대해 고유하며 일반적으로 전체 호출 스택 추적을 찾을 필요가 없습니다.

지속적인 퍼지 테스트

퍼즈 테스트의 확률론적 특성으로 인해 더 오랜 기간 동안 실행하면 문제를 찾을 가능성이 높아집니다. 그러나 어떤 프로젝트 계획도 개발이 끝날 때 긴 퍼즈 테스트 주기로 인한 지연을 흡수할 수 없습니다.

실제로 퍼즈 테스트는 릴리스 프로세스 후에 자체 분기에서 시작됩니다. 새로 발견된 모든 버그는 로컬 분기에서 수정되어 추가 버그 발견을 차단하는 새로운 버그 없이 테스트를 계속할 수 있습니다. 릴리스 주기의 일부로 퍼즈 테스트 이전 릴리스에서 발견된 버그는 새 릴리스에 포함되도록 평가됩니다. 마지막으로 버그를 발견한 퍼즈 벡터를 일반 품질 보증 프로세스에 추가하여 수정 사항을 확인하고 이러한 버그가 코드에 실수로 다시 도입되지 않도록 해야 합니다.

다양한 시나리오에서 장치의 퍼지 테스트를 실행해야 합니다. 예를 들어, 장치는 네트워크로 연결된 경우 연결 요청에 다르게 응답합니다. 가능한 모든 시나리오에서 퍼지 테스트를 실행하는 것은 비현실적이지만 가능한 상태의 각 값에 대해 퍼지 테스트를 포함할 수 있습니다. 예를 들어, 다른 변수를 동일하게 유지하면서 각기 다른 장치 유형으로 퍼지 테스트를 실행합니다. 그런 다음 한 장치 유형에 대해 네트워크 연결 상태와 같은 다른 변수에 대해 다른 값을 실행합니다.

퍼즈 테스트 아키텍처

두 가지 두드러진 퍼즈 테스팅 아키텍처는 테스트 전에 엔지니어가 퍼즈 벡터를 지정하는 방향성 퍼징(directed fuzzing)과 퍼즈 도구가 테스트 벡터의 초기 세트로 시작하여 패킷이 얼마나 잘 침투하는지에 따라 자동으로 변경하는 커버리지 기반 퍼즈 테스팅(coverage-guided fuzz testing)입니다. 코드.

또한 모든 코드가 PC에서 실행되는 것은 아니며 임베디드 애플리케이션용 PC 시뮬레이터를 개발하는 것은 테스트 대상에 따라 비실용적일 수 있습니다.

다음은 4가지 퍼지 테스트 아키텍처를 요약한 것입니다.

• 임베디드 하드웨어에서 직접 인터페이스 테스트 - 인터페이스를 통해 주입된 퍼즈 패킷을 사용하여 임베디드 장치에서 일반 프로덕션 이미지 실행
• 패킷(스택) 주입 테스트 - 무선으로 인터페이스를 실행할 필요 없이 들어오는 패킷 루틴을 직접 호출
• 임베디드 코드 개발 및 테스트를 위한 PC 기반 시뮬레이션 기술 사용
• 시뮬레이터를 사용한 커버리지 기반 퍼징(아래 Libfuzz로 표시)

여러 퍼지 테스터

디버그 인터페이스 잠금 및 보안 부팅으로 임베디드 장치를 잠근 후 장치 인터페이스의 퍼지 테스트를 고려해야 합니다. 웹 서버를 보호하는 데 사용되는 동일한 도구와 개념을 임베디드 장치와 함께 사용할 수 있습니다.

작업에 적합한 도구를 사용하십시오. Coverage-guided fuzzing은 지속적인 퍼즈 테스트를 위해 필요하지만 코드가 임베디드 하드웨어에서만 실행되는 경우 Directed fuzzer는 어느 정도의 퍼즈 테스트 커버리지를 제공하기 위한 좋은 선택이 될 수 있습니다.

마지막으로, 가능한 한 많은 시나리오에서 여러 퍼즈 테스터를 사용해야 합니다. 각각은 장치를 약간 다르게 테스트하여 적용 범위를 최대화하고 따라서 임베디드 장치의 보안을 극대화하기 때문입니다.

>> 이 기사는 원래 다음 날짜에 게시되었습니다. 자매 사이트인 EDN.