API 온 휠: 위험한 취약점이 가득한 로드 트립

마지막으로 로드 트립을 한 게 언제였나요?여러분이 세계 어디에 있느냐에 따라 최근 일정으로 돌아온 것일 수도 있지만, 사실 탁 트인 도로에서 경치를 바꾸는 것보다 더 좋은 것은 없습니다.

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

우리는 자동차 산업의 느슨한 사이버 보안 조치로 인한 위험에 대해 다음과 같이 길게 이야기했습니다. 테슬라 과 지프 이미 보안 연구원들과 협력하여 조기에 발견하고 즉시 수정하지 않으면 심각한 안전 문제를 일으킬 수 있는 악용 가능한 버그를 발견했습니다.또한 소프트웨어 보안이 일반적으로 어떻게 이루어지는지에 대해서도 말씀드렸습니다. 여전히 와일드 웨스트에서.소프트웨어는 우리가 사용하는 모든 곳에 있으며, 연결된 많은 장치, 차량 및 주변 장치에 필요한 보안 조치는 최종 사용자의 교육과 경계를 훨씬 뛰어 넘습니다.

API 취약점은 특히 심각해지고 있습니다. 악성 API 트래픽이 300% 이상 증가 지난 6개월 동안만.현대 자동차가 기본적으로 바퀴가 달린 API라는 점을 고려하면 이는 다소 우려스러운 일입니다.이들은 서로 연결되어 있고 다른 애플리케이션과 매우 혼잡하며 여러 취약한 엔드포인트 중 하나로서 표적 공격에 휘말릴 수 있습니다.

EV 충전기의 내용이 너무 많을 때

커넥티드 카의 소프트웨어 안전에 대한 정밀 검사가 진행되고 있습니다. 그런데 액세서리는 어떨까요?펜 테스트 파트너스의 천재 제작진 몇 가지 코드 수준의 취약점을 발견했습니다. 6개의 가정용 전기 자동차 충전 브랜드와 광범위한 공공 EV 충전 네트워크에 있습니다.

누가 충전기를 신경 쓰나요?공격자는 무엇을 얻을 수 있을까요?안타깝게도 야근을 하는 강력하고 심층적인 기술의 단점 중 하나는 일반적으로 이러한 기기는 TMI가 좋지 않다는 것입니다.EV 충전기는 클라우드 기반 환경에서 API를 통해 보조 모바일 앱과 통신하며, 안전하게 코딩 및 구성하지 않으면 이 모든 것이 악용에 취약할 수 있습니다.API는 앱 간 통신의 수문을 열도록 설계되어 있습니다. 이러한 엔드포인트를 세심하게 구성하지 않으면 취약한 앱 백도어를 통해 너무 많은 항목이 공유되거나 더 나쁜 경우에는 액세스될 수 있습니다.

Pen Test Partners는 수백만 대의 EV 충전기가 하이재킹될 수 있는 매우 위험한 취약점, 계정 탈취 및 계정에 대한 원격 제어/액세스를 허용하는 API 인증 문제의 여러 사례, 심지어 여러 EV 장치의 동기화된 제어를 통해 전력망을 방해할 수 있는 가능성을 발견했습니다.이러한 문제는 모두 패치되었지만, 단 몇 줄의 코드만으로 공격자가 핵심 기능 및 서비스 인프라를 완전히 파괴할 수 있다는 사실은 매우 우려스러운 일입니다.

마스터마인드 같은 것도 아니에요.예를 들어 월박스의 API에는 안전하지 않은 직접 객체 참조 (IDOR) 가 두 개 있어서 악용될 경우 계정 탈취를 허용했을 것입니다.IDOR은 인증 실패에 해당하며, 이는 인증에서 두 번째입니다. OWASP 상위 10개 API 취약성.이는 품질 코드의 학습과 구현에 실패를 초래하는 먼지만큼이나 흔합니다.무수히 많은 버그가 있는 통신 경로를 통해 민감한 기기와 앱을 계속 연결할 수는 없습니다. 제대로 구성되지 않은 API가 바로 그 원인입니다.

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

API 보안의 실망스러운 점은 이를 완화하기 위한 새로운 사이버 보안 재앙으로 선전되고 있다는 것입니다. 하지만 실제로는 웹 개발에서 수십 년 동안 보아왔던 것과 같은 오래된 문제를 새로운 환경으로 옮긴 것에 불과합니다.크로스 사이트 스크립팅, 인젝션, 잘못된 구성: 익숙하게 들리나요?

NIST와 같은 조직의 최근 지표는 유망하며 소프트웨어 보안이 점점 더 규제되고 표준화되고 있음을 보여줍니다.그러나 우리는 매일 작성되는 코드의 홍수 속에서 필요한 보호 조치의 양을 줄이는 데 필요한 전문가에 비해 여전히 부족한 실정입니다.개발자의 보안 지식과 책임은 높아져야 하는데, 주도권을 쥐는 것은 개발자의 몫이 아닙니다.어플라이언스의 임베디드 시스템이나 자동차를 원격 제어 장난감으로 탈바꿈시킬 수 있는 API를 개발하는 팀이 있다면 일반적인 취약점의 유입을 막는 데 필요한 기능을 갖추고 있는지 확인해야 합니다.

예를 들어 보안 API와 XSS로 인한 취약한 API 간의 차이는 미미하지만 개발자는 잘못된 코딩 패턴과 좋은 코딩 패턴을 구별하는 뉘앙스를 보여주어야 합니다.그뿐만 아니라 API 구성에서는 지연 개발 프로세스가 평소와 다름없이 업무를 수행하는 경우가 많으며, 대부분의 경우 설정된 작업을 수행하는 데 필요한 최소 요구 사항을 넘어서는 방대한 권한이 부여되어 위협이 가중되고 데이터 도난이 발생할 수 있습니다.이러한 요소는 빌드 과정에서 고려해야 하지만, 수용 가능한 개발 관행에 반영되지 않을 경우 프로세스는 계속해서 위험 요소로 작용할 수 있습니다.

새로운 위협 행위자의 놀이터 피하기

위협 행위자의 표적이 되는 API의 급격한 증가는 관심이 낮은 것으로 인식되고 있음을 보여줍니다. 이 경우 잠재적 차량 탈취의 형태로 생명에 대한 잠재적 위협뿐만 아니라 상당한 보수를 받을 수 있는 파이프라인이 될 수 있습니다.

API 보안을 운에 맡기는 것은 나중에 문제를 야기할 수 있는 확실한 방법이며, 최악의 경우 잠재적으로 치명적인 결과를 초래할 수 있고, 재작업과 기껏해야 성능 저하를 야기할 수 있습니다.이는 소프트웨어 통신 에코시스템의 일부로서 반드시 고려해야 할 사항이며, 업계 최고의 보안 프로그램 목록에서 상위에 오를 수 있습니다.이를 위한 핵심은 각 API를 마치 사람인 것처럼 취급하고 어떤 액세스 권한을 가져야 하는지를 평가하는 것입니다.회계 담당 Jim이 회사 전체의 민감한 법률 문서에 모두 액세스할 수 있어야 할까요?아마도 실제 직원의 경우 액세스 제어가 올바르게 결정되지 않을 수 있으며 일반적으로 액세스 제어가 올바르게 결정됩니다.API의 경우도 마찬가지입니다. API는 다른 모든 것과 동일한 제로 트러스트 방식으로 구성되지 않은 경우 모든 사람에게 비밀을 알려주는 강력한 대화 상자라는 점을 기억해야 합니다.

조직은 경계를 늦추지 않아야 하며, 개발자들은 이러한 취약한 포털이 절망에 빠지지 않는 양질의 코드를 만들기 위해 현장에서 눈을 떼지 않아야 합니다.이제는 이러한 목표에 대한 올바른 사고방식과 개발의 중요한 단계에서 올바른 결정을 내릴 수 있는 실무 기술을 갖춘 보안 인식 엔지니어로 성장하고 성장할 기회를 제공해야 할 때입니다.