바퀴 달린 API: 위험한 취약점을 찾아 떠나는 로드 트립

마지막으로 자동차 여행을 떠난 게 언제인가요? 세계 어느 곳에 있느냐에 따라 최근에야 다시 여행을 계획할 수 있게 되었을지 모르지만, 탁 트인 도로를 달리며 풍경을 바꾸는 것만큼 좋은 것은 없습니다.

물론, 당신이 소프트웨어 취약점이 아니라면 말이죠.

우리는 자동차 산업의 허술한 사이버 보안 조치가 초래하는 위험에 대해 자세히 이야기해 왔습니다. 테슬라(Tesla)와 지프(Jeep) 같은 기업들은 이미 보안 연구원들과 협력하여, 조기에 발견하고 신속하게 수정하지 않았다면 심각한 안전 문제로 이어질 수 있었던 악용 가능한 버그들을 찾아냈습니다. 또한 우리는 전반적으로 소프트웨어 보안이 여전히 무법지대와 다름없다는 점에 대해서도 언급했습니다. 소프트웨어는 우리 주변 어디에나 존재하며, 많은 커넥티드 디바이스, 차량 및 주변 기기의 경우 필요한 보안 조치는 단순히 최종 사용자를 교육하고 주의를 당부하는 수준을 훨씬 넘어섭니다.

API 취약점은 특히 교묘해지고 있으며, 지난 6개월 동안만 해도 악성 API 트래픽이 300% 이상 증가했습니다 . 현대의 차량은 본질적으로 '바퀴 달린 API'나 다름없다는 점을 고려하면 이는 매우 우려스러운 일입니다. 차량은 서로 연결되어 있고 다른 애플리케이션과 끊임없이 데이터를 주고받기 때문에, 수많은 취약한 엔드포인트 중 하나로서 표적 공격의 대상이 될 수 있습니다.

전기차 충전기가 너무 많은 정보를 누설할 때

커넥티드 차량은 소프트웨어 안전성 문제로 면밀한 조사를 받아왔지만, 그 부속품들은 어떨까요? Pen Test Partners의 뛰어난 팀은 6개 가정용 전기차 충전 브랜드와 광범위한 공공 전기차 충전 네트워크에서 여러 코드 수준의 취약점을 발견했습니다.

충전기가 무슨 상관이냐고요? 공격자가 무엇을 얻을 수 있을까요? 안타깝게도 우리를 위해 쉼 없이 작동하는 강력하고 심층적인 기술의 단점 중 하나는, 이러한 기기들이 대체로 '과도한 정보 공유(TMI)' 문제를 겪고 있다는 것입니다. 전기차 충전기는 클라우드 기반 환경에서 API를 통해 모바일 앱과 통신하는데, 보안이 철저하게 코딩되고 구성되지 않으면 이러한 모든 과정이 공격에 취약해질 수 있습니다. API는 설계상 앱 간의 통신을 위한 통로를 열어주는데, 이러한 엔드포인트가 세심하게 구성되지 않으면 너무 많은 정보가 공유되거나, 더 나아가 취약한 앱 백도어를 통해 시스템에 침입당할 수 있습니다.

Pen Test Partners는 수백만 대의 전기차 충전기를 탈취할 수 있는 매우 위험한 취약점, 계정 탈취 및 원격 제어/접근을 허용하는 API 권한 문제, 심지어 여러 전기차 기기를 동기화하여 전력망을 교란할 가능성까지 발견했습니다. 이러한 문제들은 모두 패치되었지만, 단 몇 줄의 코드가 공격자와 핵심 기능 및 서비스 인프라의 완전한 마비 사이를 가로막고 있었다는 사실은 매우 우려스럽습니다.

그렇다고 아주 고도의 기술이 필요한 것도 아닙니다. 예를 들어, Wallbox의 API에는 두 개의 안전하지 않은 직접 객체 참조(IDOR) 취약점이 있었는데, 이를 악용하면 계정 탈취가 가능했습니다. IDOR는 OWASP 상위 10대 API 취약점 중 2위에 해당하는 인증 파괴(Broken Authentication) 범주에 속합니다. 이는 매우 흔한 문제로, 양질의 코드를 학습하고 구현하는 과정에 결함이 있음을 보여줍니다. 수많은 버그가 있는 통신 경로를 통해 민감한 기기와 앱을 계속 연결할 수는 없으며, 잘못 구성된 API가 바로 그런 위험 요소입니다.

자동차 API를 안전하게 다루려면 교육과 인내가 필요합니다

API 보안의 답답한 점은, 이것이 마치 새로운 사이버 보안 재앙인 것처럼 과장되지만 실제로는 수십 년간 웹 개발 분야에서 봐왔던 고질적인 문제들의 새로운 환경일 뿐이라는 것입니다. 크로스 사이트 스크립팅(XSS), 인젝션, 잘못된 구성... 익숙하지 않나요?

최근 NIST와 같은 기관들의 움직임은 고무적이며, 소프트웨어 보안이 더욱 규제되고 표준화되고 있음을 보여줍니다. 하지만 매일 쏟아져 나오는 방대한 코드에 필요한 보호 조치를 취하기에는 여전히 전문가가 턱없이 부족합니다. 개발자들의 보안 지식과 책임을 높여야 하며, 이는 개발자 개인의 노력에만 맡길 일이 아닙니다. 가전제품의 임베디드 시스템이나 자동차를 원격 조종 장난감으로 만들 수 있는 API를 다루는 팀이 있다면, 그들이 흔한 취약점을 만들지 않도록 필요한 역량을 갖추게 해야 합니다.

예를 들어, 안전한 API와 XSS에 취약한 API의 차이는 미미하지만, 개발자들에게는 나쁜 코딩 패턴과 좋은 코딩 패턴을 구분하는 미묘한 차이를 알려주어야 합니다. 게다가 API 구성 시 안일한 개발 프로세스가 관행처럼 굳어져, 작업 수행에 필요한 최소한의 권한을 넘어선 과도한 권한을 부여하는 경우가 많습니다. 이는 공격 표면을 넓히고 데이터 도난의 위험을 초래합니다. 이러한 요소들은 구축 단계에서 고려되어야 하며, 올바른 개발 관행으로 정착되지 않으면 프로세스는 계속해서 위험 요소로 남을 것입니다.

새로운 위협 행위자들의 놀이터를 피하는 법

위협 행위자들의 표적으로서 API가 급격히 증가하는 것은 그들의 관심이 '손쉬운 먹잇감'으로 옮겨가고 있음을 보여줍니다. 이 경우, API는 차량 탈취와 같은 잠재적인 생명 위협은 물론, 상당한 금전적 이득을 얻을 수 있는 통로가 될 수 있습니다.

API 보안을 운에 맡기는 것은 나중에 반드시 문제를 일으키는 지름길입니다. 최악의 경우 치명적인 결과를 초래할 수 있으며, 최선의 경우에도 번거로운 재작업과 성능 저하를 피할 수 없습니다. API 보안은 소프트웨어 통신 생태계의 핵심 고려 사항이자, 최고 수준의 보안 프로그램에서 최우선 순위에 두어야 합니다. 이를 위한 핵심은 각 API를 마치 사람처럼 대우하고 어떤 접근 권한을 가져야 할지 평가하는 것입니다. 회계팀의 김 대리가 회사 전체의 모든 민감한 법률 문서에 접근할 수 있어야 할까요? 아마 아닐 것입니다. 현실 세계의 인력에 대해서는 접근 제어가 적절히 결정되는 편입니다. 하지만 API는 그렇지 않습니다. API는 강력한 '수다쟁이'이며, 다른 모든 것과 마찬가지로 제로 트러스트(Zero-trust) 방식으로 구성하지 않으면 당신의 비밀을 모두에게 알릴 수 있다는 점을 기억해야 합니다.

조직은 높은 경계 태세를 유지해야 하며, 개발자는 이러한 취약한 통로를 차단하고 양질의 코드를 작성하기 위해 현장에서 눈을 크게 뜨고 있어야 합니다. 이제 개발자들이 보안을 인식하는 엔지니어로 성장하고, 올바른 목표 의식과 핵심 개발 단계에서 올바른 결정을 내릴 수 있는 실무 능력을 갖출 기회를 제공해야 할 때입니다.