좀비 API의 증가하는 문제와 공격 표면 증가

고객에게 API를 제공하면 수익이 증가하지만 공격 표면도 확대됩니다. 기업에서는 보다 쉽게 개발할 수 있도록 타사 애플리케이션에 내장할 수 있는 API를 제공할 수 있습니다. 예를 들어 애플리케이션에 소셜 미디어를 포함시키면 고객이 개발 팀에 막대한 오버헤드를 추가하지 않고도 제품에 대해 논의할 수 있습니다. 소셜 미디어 회사는 트래픽과 가시성을 확보하고, 고객은 애플리케이션에 기능을 추가하면서 개발을 쉽게 할 수 있습니다.

API는 마케팅과 수익 측면에서 유용하지만 API와 엔드포인트를 추가하면 공격 표면이 확장됩니다. API를 보유하는 것은 관리할 수 있는 추가적인 위험이지만 모든 엔드포인트를 엄격하게 모니터링하고 보호해야 합니다. 대부분의 관리자는 API를 모니터링해야 한다는 데 동의하지만 수많은 업데이트와 배포로 인해 빠르게 변화하는 비즈니스 환경에서는 API 추적을 놓치고 자신도 모르게 "좀비 API"라는 사이버 보안 위험이 추가될 수 있습니다.

좀비 API란 무엇입니까?

좀비 API는 (기본적으로) 계속 사용할 수 있지만 조직은 그 존재를 인식하지 못하는 잊혀지고 간과되는 인프라입니다. Zombie API는 소규모 또는 대규모 환경에서 생성될 수 있지만, 엄격한 프로비저닝 및 문서화 절차 없이 IT 리소스가 구축되는 환경에서 생성되는 경우가 많습니다. 변경 제어는 좀비 API 상황을 방지하는 데 도움이 되지만 특정 심각한 오류를 수정하기 위해 수행되는 긴급 배포 또는 구성도 발생할 수 있습니다.

자동화된 환경에서는 클라우드 리소스가 애플리케이션 코드와 함께 배포되는 경우가 많습니다. 이점은 개발자와 운영 담당자가 더 이상 하드웨어를 배포하고 수동으로 구성하는 것을 기억할 필요가 없다는 것입니다. 소프트웨어 배포 자동화는 잘못된 구성으로 인한 사고를 줄이거나 개발자가 애플리케이션 지원을 위한 리소스 프로비저닝 요청을 포함하는 것을 잊어버리는 문제를 방지합니다.

일부 환경에서는 개발자에게 자체 테스트 서버에 대한 액세스 권한이 부여됩니다. 개발자가 새 코드를 테스트할 수 있도록 이러한 서버는 공용 인터넷에서 액세스할 수 있습니다. API 테스트 서버는 공용 인터넷에서 사용할 수 있으며 개발자는 게시되지 않으면 감지되지 않을 것이라고 생각할 수 있습니다.

좀비 API는 가장 엄격한 변경 제어 절차를 사용하더라도 자체적인 엣지 케이스를 사용하여 다양한 방법으로 생성할 수 있습니다. 실수로 인해 발생하든, 잘못된 안내로 인해 발생하든 좀비 API는 섀도우 IT 이는 데이터 보호에 특히 위험할 수 있습니다. 모니터링하지 않으면 공격자는 제한이나 속도 제한 없이 몇 달 동안 데이터를 검색할 수 있습니다. 취약점을 조사하거나 이를 악용하는 경우 기록되지 않으므로 일반적인 사이버 보안 분석에서는 관리자에게 비정상적인 트래픽을 알리지 않습니다.

해커는 좀비 API를 어떻게 찾나요?

상황에 따라 좀비 API를 만들 수 있는 다양한 방법과 마찬가지로 좀비 API를 찾는 경우에도 마찬가지입니다. 해커는 코드 리버스 엔지니어링, 오픈 소스 저장소 검토 또는 "퍼징"이라는 개념을 통해 엔드포인트를 찾을 수 있습니다. 퍼징은 일반적인 API 엔드포인트 이름에 대해 요청을 작성하기 위해 스크립트가 작성되는 검색 유형입니다. 예를 들어, 인증에 사용되는 API 엔드포인트에는 "/login" 또는 "/authenticate" 또는 유사한 이름의 엔드포인트가 있는 것이 일반적입니다. 엔드포인트를 검색하기 위해 인프라에 대해 다양한 공통 엔드포인트 이름에 대한 요청이 이루어집니다.

오픈 소스 저장소에서 검색하는 것이 일반적입니다. 오픈 소스 리포지토리는 비밀 공개에도 취약합니다. 즉, 개발자가 개인 키, 인증 자격 증명 및 기타 개인 데이터에 대한 참조를 제거하는 것을 잊어버릴 수 있습니다. API 엔드포인트에 대한 참조도 검색에 사용할 수 있으며 모든 취약점이 있는지 조사됩니다. 조직이 코드에서 참조되는 끝점을 인식하지 못하는 경우 완화 또는 속도 제한 없이 프로브될 수 있습니다.

좀비 API가 항상 버그 악용에 취약한 것은 아닙니다. 예를 들어 SQL 주입 취약점을 악용하면 민감한 정보가 데이터에 공개될 수 있지만 일부 엔드포인트는 위협에 대한 복원력을 갖추도록 올바르게 코딩되어 있습니다. 좀비 API 상황에서는 API가 정상적으로 작동할 수도 있지만 아무런 제한 없이 데이터를 수집하는 데 사용할 수 있습니다. 엔드포인트에 악용될 수 있는 비즈니스 논리 오류가 있을 수 있지만 모니터링하지 않으면 의심스러운 활동이 감지되지 않을 수 있습니다.

좀비 API로 인한 실제 데이터 침해

정상적으로 작동하지만 조용히 데이터를 열거하는 데 사용되는 API의 좋은 예는 다음과 같습니다. 저스트다이얼 사건 . JustDial은 1억 명 이상의 사용자를 보유한 인도의 대규모 로컬 디렉터리 중 하나입니다. 2019년에 한 보안 연구원은 JustDial이 모니터링을 구현하지 않은 채 공용 인터넷에 공개된 좀비 API를 가지고 있음을 발견했습니다. API는 엔드포인트에 요청하는 모든 사람에게 이름, 이메일, 휴대폰 번호, 주소, 성별과 같은 정보를 반환했습니다. 인증도 필요하지 않았고, JustDial은 사건을 포착하기 위해 모니터링하지도 않았습니다.

보안 연구원이 좀비 API를 탐지한 후 JustDial은 사건을 해결했다고 주장했지만 2020년에도 동일한 문제가 다시 탐지되었습니다. 보안 연구원 외에 제3자가 있는지는 확실하지 않지만 엔드포인트가 공용 인터넷에 공개되어 있었기 때문입니다. 모니터링이 이루어지지 않아 JustDial은 데이터 유출 정도를 평가할 수 없습니다.

또 다른 예는 시장 최고의 개발자들로 유명한 샌프란시스코의 대형 기술 회사 중 하나인 Facebook입니다. Facebook에는 여러 가지 좀비 API 인스턴스가 있습니다. 2016년에 개발자들은 비밀번호 재설정 기능을 테스트하기 위해 하위 도메인(mbasic.beta.facebook.com)을 배포했습니다. API의 프로덕션 버전에는 속도 제한이 있으므로 공격자는 사용자의 비밀번호를 재설정하기 위해 사용자에게 전송된 6자리 비밀번호를 무차별 대입할 수 없습니다. 베타 버전에는 이러한 제한이 없었기 때문에 6자리 비밀번호는 인터넷 연결, 대역폭 및 API 엔드포인트의 백엔드 처리 속도에 의해서만 제한되며 몇 초 안에 무차별 대입이 가능했습니다.

2018년 페이스북은 또 다른 어려움을 겪었다. 좀비 API 공격 . 이 취약점은 Facebook의 "다음으로 보기" 기능에서 발견되었습니다. 이 기능을 통해 사용자는 다른 사람이 보는 것처럼 자신의 프로필을 볼 수 있습니다. 이 기능의 API 엔드포인트는 잠기거나 모니터링되지 않았으므로 공격자가 다른 사용자 프로필을 보고 액세스 토큰을 훔칠 수 있었습니다. 공격자는 액세스 토큰을 사용하여 사용자의 프로필과 데이터를 훔칠 수 있습니다. Facebook은 4천만 명의 사용자가 영향을 받았으며 9천만 명의 사용자가 액세스 토큰이 도난당하지 않았는지 확인하기 위해 재인증을 받아야 한다고 추정했습니다.

소규모 회사이지만 좀비 API로 인한 심각한 데이터 침해가 2022년 Travis CI의 엔드포인트에서 발생했습니다. Travis CI는 인프라와 코드를 배포하는 데 사용되는 자동화 공급업체입니다. Travis CI의 API 엔드포인트 중 하나는 인증이 필요하지 않으며 고객 로그 이벤트를 얻기 위한 요청이 허용되었습니다. 설상가상으로 로그가 일반 텍스트로 저장되어 액세스 키를 포함한 사용자 로그 데이터를 제한 없이 검색할 수 있었습니다. 이 문제가 보고되었을 때 Travis CI는 액세스 토큰, 키, 클라우드 자격 증명을 포함한 7억 7천만 개의 사용자 로그 기록이 도난당한 것으로 추정했습니다.

좀비 API 발견

이상적으로는 소프트웨어 개발자가 인프라 변경 사항을 문서화하여 변경 제어에 새로운 API 엔드포인트가 포함되도록 합니다. 그런 다음 운영 담당자는 모니터링 에이전트에 엔드포인트를 추가할 수 있으며, 이러한 에이전트는 데이터를 수집하여 사이버 보안 및 분석 모니터를 통해 의심스러운 활동이 감지되면 관리자에게 알릴 수 있습니다. 좀비 API는 엔드포인트가 문서화되지 않아 모니터링 에이전트가 엔드포인트를 인식하지 못할 때 발생합니다. 모니터링하지 않으면 분석 및 관리자 경고 없이 모든 요청이 서버로 전송될 수 있습니다.

잠재적인 좀비 API를 해결하기 위해 관리자는 트래픽을 감지하기 위해 네트워크에 에이전트를 설치하는 경우가 많습니다. 에이전트는 트래픽 데이터를 수집하고 서버 및 기타 네트워크 인프라에서 열려 있는 연결을 감지합니다. 이 전략의 문제는 좀비 API가 발견될 때까지 트래픽이나 요청 없이 휴면 상태로 유지되는 경우가 많다는 것입니다. 개발자, 운영업체 또는 인터넷상의 제3자가 이를 발견할 수 있습니다. 제3자가 엔드포인트를 찾은 후에만 트래픽이 기록되지만 요청이 경고를 트리거한다는 의미는 아닙니다. 좀비 API는 "해킹"이나 잘못된 쿼리 없이 표준 요청을 허용합니다. 이것이 바로 좀비 API가 데이터 공개에 위험한 이유입니다.

인공 지능을 사용하여 좀비 API 발견

좀비 API를 반응적으로 감지하기 위해 에이전트에 의존하는 대신 인공 지능을 사용하고 코드를 스캔하는 것이 더 나은 솔루션입니다. 이 전략에는 내부 API에 대한 참조를 찾기 위해 리포지토리 코드를 스캔하고 이벤트 로그를 사용하여 API가 요청을 수신하는지 확인하는 두 단계가 있습니다.

첫 번째 단계는 API에 대한 참조를 찾기 위해 코드를 스캔하는 것입니다. 이러한 API는 외부 또는 내부일 수 있지만 이 인프라는 자체 데이터에 영향을 미치므로 내부 API에 집중하는 것이 좋습니다. 참조는 활성 저장소와 더 이상 사용되지 않는 저장소 모두에 있을 수 있습니다. 코드에 참조가 있다는 사실조차 인식하지 못할 수도 있지만 스캔하면 해당 참조가 검색되어 인공 지능(AI)에 목록이 전송될 수 있습니다.

다음은 이벤트 로그를 수집하고 분석하는 데 사용되는 LLM(대형 언어 모델)입니다. 이벤트 로그는 잠재적으로 기가바이트 또는 테라바이트의 행별 데이터일 수 있습니다. 이벤트 로그는 사이버 보안 및 인프라 사용량 모니터링에 중요하므로 API를 호스팅하는 서버에 대해 설정해야 합니다. API 엔드포인트가 코드에서 참조되지만 트래픽 이벤트가 거의 또는 전혀 없는 경우 좀비 API가 있을 수 있습니다. 참고자료가 많은 API와 다수의 이벤트 로그를 사용하고 모니터링하고 있으므로 좀비 API로 간주되지 않습니다.

LLM을 사용하여 모든 API 엔드포인트 참조에 대한 분석을 처리하는 데는 시간이 걸리지만 관리자는 해당 환경에서 활성 API를 인식하지 못하는 결과를 얻을 수 있습니다. 예를 들어, Domino's Pizza India 사례 연구 최근 189개의 좀비 API가 발견되었으며, 그 중 11%가 개인 식별 정보(PII)를 연결했습니다. 이 발견은 2063개의 엔드포인트를 스캔하고 전체 Domino's Pizza India 환경에서 이벤트 로그를 분석하는 데 2.2일을 소비한 후에 이루어졌습니다.

좀비 API를 모니터링해야 합니까?

대답은 “예!”입니다. 좀비 API는 고객 데이터, 내부 데이터 또는 기타 중요한 정보를 공개할 수 있습니다. 규정을 준수하는 환경에서는 이러한 감독으로 인해 수백만 달러의 벌금이 부과될 수 있습니다. 소송, 브랜드 손상, 수익 영향 및 기타 여러 가지 부정적인 결과는 모니터링되지 않는 인프라와 관련되어 데이터 유출로 이어집니다.

조직의 환경에 대한 더 나은 가시성을 확보하는 것은 사이버 보안과 더 빠른 사고 대응에 매우 중요합니다. 더 많은 조직이 클라우드에 인프라를 배포함에 따라 좀비 API를 포함하여 느슨한 끝이 없는지 확인하는 것이 그 어느 때보다 중요합니다. 인프라를 문서화하는 것은 훌륭한 첫 번째 단계이지만 일부 API가 균열을 겪을 가능성이 있습니다. 코드를 지속적으로 스캔하면 좀비 API를 식별하는 데 도움이 되며, 이를 비활성화하거나 모니터링 에이전트에 추가할 수 있습니다. 인프라에 대한 가시성이 향상되면 민감한 데이터 노출 위험이 낮아지고 공격 표면이 줄어듭니다.