2019.09.17

"IoT 기기 보안, 쉬운데도 안 한다" CITL 조사

J.M. Porup | CSO
IoT 기기의 컴파일 시간 보안 기능을 쉽게 활성화할 수 있다. 그런데 보안 기능을 활성화하는 IoT 기기 제조업체가 늘지 않는 이유는 무엇일까?

IoT 펌웨어 바이너리를 구축할 때 보안 기능에 대한 플래그를 추가하면 IoT 기기 보안을 크게 개선할 수 있다. 그런데 대부분이 이렇게 하지 않는다. 게다가 CITL(Cyber Independent Testing Lab) 매스 퍼징 프로젝트의 새로운 조사 결과에 따르면, 상황이 나아지는 것이 아니라 오히려 악화되고 있다.

보안 활성화는 매우 쉬운 일이다. 이렇게 하지 않을 이유가 없다. 그런데 이렇게 하지 않는다. 

CITL은 컨슈머 리포트 같은 비영리 보안 연구소다. 현재까지 지난 15년간 발표된 300여만 개의 IoT 펌웨어 바이너리 퍼징을 자동화했다. 그 결과는 실망스럽다.

CITL의 최고 과학자인 사라 자트코는 “매우 쉬운 일이다. 그런데 IoT 업체들은 기본적인 컴파일 시간 보안 기능을 활성화하지 않고 있다. 기능을 활성화하지 않을 이유가 없는데도 그렇게 하지 않고 있다”고 말했다.

이어서 자트코는 “의도적으로 무시했으리라 생각하지는 않는다. 진짜로 누군가 이 보안 기능을 제외하기로 의도적으로 결정을 내린 경우가 아니라면 말이다. 이는 선의의 무시라고 봐야 한다. 자신이 반드시 해야 할 일, 자신의 직업이라면 이런 일이 일어나지 않았을 것이다”라고 덧붙였다.
 
ⓒGetty Images Bank

빌드 후 확인할 시기?
IoT 업체들은 쉽게 이런 컴파일 시간 보안 플래그를 활성화하고, 이를 릴리스 관리 프로세스의 일부로 확인할 수 있다. 더 최신 버전의 컴파일러가 있는지 확인하고, ASLR과 DEP, 스택 가드 같은 기본적인 보안 플래그를 활성화하는 것 등이 빌드에서 권장되는 ‘보안’ 조치이다. 마법 같은 보안 경감책은 존재하지 않지만, 그래도 IoT 환경에서 에어백과 안전벨트 같은 역할을 한다. 충돌 자체를 방지하지는 못하더라도 생명을 구하는 역할을 한다는 이야기다.

하루 최대 몇 시간의 엔지니어링 작업이 필요한 일이다. 자트코는 “무슨 이유이든 특정 운영 체제와 칩이 조합된 예외적인 문제가 있을 경우 조금 더 복잡한 문제가 될 수 있다. 그러나 대부분은 단순한 문제다”라고 지적했다.

우리가 계속 안전하지 못한 IoT 기기를 배포하면서 취약한 빌드 보안으로 초래되는 결과가 가중될 것이다. 따라서 업체들은 빌드 후 QA 테스팅을 시작하고, 이에 대해 확인하며, 점검해야 한다. 그렇지 않으면 규제의 대상이 될 수도 있다.

지금까지 업체들이 이런 책임 있는 행동을 하도록 유도하는 데 실패했다. 브루스 슈나이어가 걱정하고 있듯, 동일한 보안 침해를 계속 초래하는 새로운 보안 침해인 ‘클래스 브레이크’가 판에 박힌 나쁜 규제를 초래할 수 있다.

IoT 보안, 자율이냐 규제냐 
시장은 업체들이 사이버보안이 견고한 제품을 출하하도록 유도하는 데 실패했다. 그러나 자트코는 구매력 있는 대기업이 차이를 만들 수 있다고 강조했다. 자트코는 “시장 자체는 이렇다 할 성과를 내지 못하고 있다. 15년 동안 변화가 없었다. 그렇지만 대량 구매에 대한 결정을 내리는 사람들이 빌드 안전성에 대해 질문을 하기 시작하면, 이는 업체의 관행에 영향을 줄 수 있다. 많은 IoT 제품을 구매하는 대기업, 정부기관을 예로 들 수 있다”라고 설명했다.

자트코는 “이런 대기업이 통상 새로운 계약을 체결하기 전에 체크리스트를 바탕으로 보안에 관해 질문하고, 확인한다”라고 설명했다. 이런 체크리스트에 빌드 안전성에 관한 질문을 포함해야 한다. 그러면 업체가 실제로 확인하도록 유도하고, 대기업이 빌드 안전성을 중시한다는 점을 알려줄 수 있다.

IoT 펌웨어 보안 시사점
CITL은 놀라운 사실 하나를 밝혀냈다. IoT 업체들이 알아야 할 일련의 ‘실패 지점’에 대해서다. buildroot 같은 컴파일러 및 펌웨어 툴체인은 컴파일 시기에 개발자를 위해 더 효과적으로 보안 문제를 표시해 알려주는 중요한 업스트림 종속물이다. 또한 MIPS는 아직 효과가 있으며, 특별한 취급 및 처리가 필요하다.

많은 이들이 MIPS가 사라지는 추세라고 잘못 생각한다. 그러나 IoT 환경에서 하드웨어 아키텍처가 다시 사용되고 있다. CITL이 매스 퍼징을 하면서 가장 많이 사용되고 있는 것으로 확인한 아키텍처이다. 문제는 보안 관점에서 봤을 때, 모든 아키텍처가 동일하게 만들어지지 않는다는 점이다.

CITL의 디렉터 대행 팀 카스텐스는 “많은 사람이 동일한 소스 코드를 다른 칩이나 아키텍처에 적용해도 보안 및 안전 측면의 특징과 기능이 그대로 유지되리라고 생각한다. 그러나 실제로는 그렇지 않다. 보안의 경우, 전체 그림을 고려해야 한다”라고 설명했다.

리눅스 MIPS에 대해 ASLR 및 DEP 컴파일 시간 플래그를 사용할 경우 적절히 작동하지 않는 것으로 밝혀졌다. 문제를 찾아 해결한 후, (가능할지 모르지만)광범위하게 패치를 하기까지 몇 년이 소요될 수 있다. “10년 넘게 전통적인 스택 오버플로우 공격이 쉽게 MIPS 바이너리를 익스플로잇 공격하는 데 사용됐다. 우리가 툴체인 패치를 조사한 결과에 따르면, 이는 앞으로도 계속될 것이다”라고 CITL 보고서는 설명하고 있다.

더 나쁜 부분은 IoT 펌웨어와 관련, 무분별하게 코드를 재사용하는 사례가 매우 많다는 것이다. 모든 사람이 누군가 보안 감사를 했을 것으로 가정하기 때문에 이런 일이 일어나고 있다. 카스텐스는 <CSO>에 “여러 제품을 봤을 때, 일정 수준 동일한 바이너리 세트를 가진 제품이 많았다. IoT 플랫폼을 만들면서 동일한 프레임워크를 사용하는 업체가 많다는 것을 알려주는 부분이다”라고 말했다.

컴파일러와 펌웨어 빌드 툴체인 모두의 개발자 사용자 인터페이스에 합리적인 수준의 안전성을 기본 구현하면 이런 제품을 사용하는 업체, 이후 단계에서 이런 업체가 만든 기기를 사용하게 될 수많은 사람에게 영향을 줄 수 있다.

자트코는 “컴파일러 자체가 구현된 안전 기능에 대해 더 효과적으로 정보를 제공하도록 만들 수 있다. 컴파일 프로세스의 끝에 가서 ‘성분표’ 역할을 한다. 컴파일러가 이런 투명성을 제공하게 만들기는 매우 쉽다. 개발자에게 생산한 제품에 대해 더 나은 피드백을 제공하도록 만들 수 있다”라고 말했다. ciokr@idg.co.kr


2019.09.17

"IoT 기기 보안, 쉬운데도 안 한다" CITL 조사

J.M. Porup | CSO
IoT 기기의 컴파일 시간 보안 기능을 쉽게 활성화할 수 있다. 그런데 보안 기능을 활성화하는 IoT 기기 제조업체가 늘지 않는 이유는 무엇일까?

IoT 펌웨어 바이너리를 구축할 때 보안 기능에 대한 플래그를 추가하면 IoT 기기 보안을 크게 개선할 수 있다. 그런데 대부분이 이렇게 하지 않는다. 게다가 CITL(Cyber Independent Testing Lab) 매스 퍼징 프로젝트의 새로운 조사 결과에 따르면, 상황이 나아지는 것이 아니라 오히려 악화되고 있다.

보안 활성화는 매우 쉬운 일이다. 이렇게 하지 않을 이유가 없다. 그런데 이렇게 하지 않는다. 

CITL은 컨슈머 리포트 같은 비영리 보안 연구소다. 현재까지 지난 15년간 발표된 300여만 개의 IoT 펌웨어 바이너리 퍼징을 자동화했다. 그 결과는 실망스럽다.

CITL의 최고 과학자인 사라 자트코는 “매우 쉬운 일이다. 그런데 IoT 업체들은 기본적인 컴파일 시간 보안 기능을 활성화하지 않고 있다. 기능을 활성화하지 않을 이유가 없는데도 그렇게 하지 않고 있다”고 말했다.

이어서 자트코는 “의도적으로 무시했으리라 생각하지는 않는다. 진짜로 누군가 이 보안 기능을 제외하기로 의도적으로 결정을 내린 경우가 아니라면 말이다. 이는 선의의 무시라고 봐야 한다. 자신이 반드시 해야 할 일, 자신의 직업이라면 이런 일이 일어나지 않았을 것이다”라고 덧붙였다.
 
ⓒGetty Images Bank

빌드 후 확인할 시기?
IoT 업체들은 쉽게 이런 컴파일 시간 보안 플래그를 활성화하고, 이를 릴리스 관리 프로세스의 일부로 확인할 수 있다. 더 최신 버전의 컴파일러가 있는지 확인하고, ASLR과 DEP, 스택 가드 같은 기본적인 보안 플래그를 활성화하는 것 등이 빌드에서 권장되는 ‘보안’ 조치이다. 마법 같은 보안 경감책은 존재하지 않지만, 그래도 IoT 환경에서 에어백과 안전벨트 같은 역할을 한다. 충돌 자체를 방지하지는 못하더라도 생명을 구하는 역할을 한다는 이야기다.

하루 최대 몇 시간의 엔지니어링 작업이 필요한 일이다. 자트코는 “무슨 이유이든 특정 운영 체제와 칩이 조합된 예외적인 문제가 있을 경우 조금 더 복잡한 문제가 될 수 있다. 그러나 대부분은 단순한 문제다”라고 지적했다.

우리가 계속 안전하지 못한 IoT 기기를 배포하면서 취약한 빌드 보안으로 초래되는 결과가 가중될 것이다. 따라서 업체들은 빌드 후 QA 테스팅을 시작하고, 이에 대해 확인하며, 점검해야 한다. 그렇지 않으면 규제의 대상이 될 수도 있다.

지금까지 업체들이 이런 책임 있는 행동을 하도록 유도하는 데 실패했다. 브루스 슈나이어가 걱정하고 있듯, 동일한 보안 침해를 계속 초래하는 새로운 보안 침해인 ‘클래스 브레이크’가 판에 박힌 나쁜 규제를 초래할 수 있다.

IoT 보안, 자율이냐 규제냐 
시장은 업체들이 사이버보안이 견고한 제품을 출하하도록 유도하는 데 실패했다. 그러나 자트코는 구매력 있는 대기업이 차이를 만들 수 있다고 강조했다. 자트코는 “시장 자체는 이렇다 할 성과를 내지 못하고 있다. 15년 동안 변화가 없었다. 그렇지만 대량 구매에 대한 결정을 내리는 사람들이 빌드 안전성에 대해 질문을 하기 시작하면, 이는 업체의 관행에 영향을 줄 수 있다. 많은 IoT 제품을 구매하는 대기업, 정부기관을 예로 들 수 있다”라고 설명했다.

자트코는 “이런 대기업이 통상 새로운 계약을 체결하기 전에 체크리스트를 바탕으로 보안에 관해 질문하고, 확인한다”라고 설명했다. 이런 체크리스트에 빌드 안전성에 관한 질문을 포함해야 한다. 그러면 업체가 실제로 확인하도록 유도하고, 대기업이 빌드 안전성을 중시한다는 점을 알려줄 수 있다.

IoT 펌웨어 보안 시사점
CITL은 놀라운 사실 하나를 밝혀냈다. IoT 업체들이 알아야 할 일련의 ‘실패 지점’에 대해서다. buildroot 같은 컴파일러 및 펌웨어 툴체인은 컴파일 시기에 개발자를 위해 더 효과적으로 보안 문제를 표시해 알려주는 중요한 업스트림 종속물이다. 또한 MIPS는 아직 효과가 있으며, 특별한 취급 및 처리가 필요하다.

많은 이들이 MIPS가 사라지는 추세라고 잘못 생각한다. 그러나 IoT 환경에서 하드웨어 아키텍처가 다시 사용되고 있다. CITL이 매스 퍼징을 하면서 가장 많이 사용되고 있는 것으로 확인한 아키텍처이다. 문제는 보안 관점에서 봤을 때, 모든 아키텍처가 동일하게 만들어지지 않는다는 점이다.

CITL의 디렉터 대행 팀 카스텐스는 “많은 사람이 동일한 소스 코드를 다른 칩이나 아키텍처에 적용해도 보안 및 안전 측면의 특징과 기능이 그대로 유지되리라고 생각한다. 그러나 실제로는 그렇지 않다. 보안의 경우, 전체 그림을 고려해야 한다”라고 설명했다.

리눅스 MIPS에 대해 ASLR 및 DEP 컴파일 시간 플래그를 사용할 경우 적절히 작동하지 않는 것으로 밝혀졌다. 문제를 찾아 해결한 후, (가능할지 모르지만)광범위하게 패치를 하기까지 몇 년이 소요될 수 있다. “10년 넘게 전통적인 스택 오버플로우 공격이 쉽게 MIPS 바이너리를 익스플로잇 공격하는 데 사용됐다. 우리가 툴체인 패치를 조사한 결과에 따르면, 이는 앞으로도 계속될 것이다”라고 CITL 보고서는 설명하고 있다.

더 나쁜 부분은 IoT 펌웨어와 관련, 무분별하게 코드를 재사용하는 사례가 매우 많다는 것이다. 모든 사람이 누군가 보안 감사를 했을 것으로 가정하기 때문에 이런 일이 일어나고 있다. 카스텐스는 <CSO>에 “여러 제품을 봤을 때, 일정 수준 동일한 바이너리 세트를 가진 제품이 많았다. IoT 플랫폼을 만들면서 동일한 프레임워크를 사용하는 업체가 많다는 것을 알려주는 부분이다”라고 말했다.

컴파일러와 펌웨어 빌드 툴체인 모두의 개발자 사용자 인터페이스에 합리적인 수준의 안전성을 기본 구현하면 이런 제품을 사용하는 업체, 이후 단계에서 이런 업체가 만든 기기를 사용하게 될 수많은 사람에게 영향을 줄 수 있다.

자트코는 “컴파일러 자체가 구현된 안전 기능에 대해 더 효과적으로 정보를 제공하도록 만들 수 있다. 컴파일 프로세스의 끝에 가서 ‘성분표’ 역할을 한다. 컴파일러가 이런 투명성을 제공하게 만들기는 매우 쉽다. 개발자에게 생산한 제품에 대해 더 나은 피드백을 제공하도록 만들 수 있다”라고 말했다. ciokr@idg.co.kr


X