IKKO Activebuds "AI 기반" 이어버드 취약점 악용 사례

 (blog.mgdproductions.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 화면 달린 이어버드 케이스가 실제로는 Android 기기에 가까웠고, ADB가 켜진 상태라 앱 추출·사이드로드·API 분석까지 이어졌음
  • ChatGPT 연동은 기기에서 OpenAI API로 직접 통신했으며, 런처 앱의 SecurityStringsAPI와 난독화된 네이티브 라이브러리 우회로 API 키와 시스템 프롬프트가 노출됐음
  • 동반 앱과 서버 API는 device id/IMEI만으로 채팅 기록을 조회할 수 있어, 튜토리얼 영상에 노출된 데모 기기 ID로 전체 데모 채팅 기록을 가져올 수 있었음
  • 임의 IMEI로 QR 코드를 만들면 미바인딩 기기를 앱에 연결할 수 있었고, 이미 바인딩된 기기는 오류 응답에서 계정의 이름 조합이 드러났음
  • IKKO는 점검과 앱·기기 업데이트로 채팅 조회에 서명 헤더를 추가했지만, 2025년 1월 13일 업데이트 기준 프록시 API는 okhttp/4.9.0 User-Agent만 요구했고 이전 ChatGPT API 키는 그때서야 교체됐음

화면 달린 이어버드 케이스의 정체

  • IKKO Activebuds는 케이스 화면에 시간과 ChatGPT를 전면 배치한 이어버드형 기기임
  • 번역 같은 AI 기능도 제공하며, IKKO 스토어에서 앱을 설치할 수 있음
  • Google Play Store는 없고, CEO는 ActiveBuds 화면에 맞게 앱들이 수정됐기 때문이라고 설명함
  • 스토어에는 Spotify 같은 음악 앱과 Subway Surfers 같은 게임 앱이 있었지만, 작은 화면 탓에 탐색이 불편했음
  • 앱 존재와 동작을 통해 기기가 Android를 실행한다는 점이 확인됨
  • 기본 EQ 프로필의 음질은 좋지 않았고, EQ 곡선을 직접 조정하면 사용 가능한 수준까지 올릴 수 있었다고 평가됨

ADB 활성화로 열린 분석 경로

  • 기기에는 브라우저가 없어 다른 앱을 직접 내려받기 어려웠고, Android 설정 앱은 열 수 있었지만 빌드 번호를 7번 눌러도 개발자 모드가 켜지지 않았음
  • PC에 연결하자 ADB가 활성화된 상태였고, 이를 통해 앱 사이드로드가 가능해짐
  • DOOM을 사이드로드한 뒤 ChatGPT 통합이 백엔드에서 어떻게 동작하는지 확인하기 시작함
  • 루팅 없이 시스템 인증서를 설치할 수 없어 HTTP 검사만으로 정확한 URL을 보기 어려웠지만, 앱 추출과 디컴파일로 필요한 정보를 확인함
  • Spreadtrum/Unisoc 기기에서 기본 서명 키를 쓰는 경우 부트로더 잠금 해제 도구를 사용할 수 있었고, 이 기기도 해당됐음
    • 다만 기기에 볼륨 업 키가 없어 잠금 해제 확인 화면을 통과하지 못함
    • 직접 서명한 파티션을 플래시하는 방법은 가능할 수 있다고 봤지만 진행하지 않음

APK 안에서 드러난 도메인과 키

  • APK 추출 도구로 앱을 덤프하고 런처 앱을 JADX로 열자 통신 도메인이 드러남
    • api.openai.com: OpenAI API
    • chat1.chat.iamjoy.cn: ChatGPT 외 앱스토어 등 기기 전체 기능용 API로 보였고, 브라우저에서 열면 로그인 페이지가 나타남
    • chat2.chat.iamjoy.cn: chat1과 같은 성격으로 보였고, 백업 서버 가능성이 있음
    • openspeech.bytedance.com: 음성 인식 백업일 가능성을 추정했지만, 기기 통신은 확인하지 못함
    • www.airdimple.cn: OpenAI API 미러 또는 프록시처럼 보였음
  • SecurityStringsAPI 파일에는 암호화된 엔드포인트와 인증 키가 들어 있었음
  • 첫 단계는 base64였고, 두 번째 단계는 심하게 난독화된 네이티브 라이브러리가 처리함
  • 루팅된 다른 기기에 앱을 사이드로드하자 앱이 그대로 동작했고, 이 과정에서 OpenAI 키를 확인함
  • ChatGPT 시스템 프롬프트도 노출됐으며, 기기에는 Angry Dan과 In-Love Dan 모드도 있었음
    • Angry Dan은 욕설이 많아 18세 이상 확인이 필요했음

채팅 로그와 동반 앱의 인증 부재

  • 기기는 ChatGPT 대화를 chat1 도메인의 다른 엔드포인트로 기록했음
  • 해당 요청 헤더에는 메시지, 모델, 응답, IMEI 기반 device id가 포함됨
  • 이후 동반 앱을 조사하면서 이 로그가 앱에서 기기와의 과거 대화를 보여주는 용도임을 확인함
  • 동반 앱은 기기의 Membership 메뉴에서 QR 코드를 스캔해 바인딩함
  • HTTP 검사 결과, 앱은 계정 토큰과 device id로 API를 조회해 기기에서 나눈 모든 채팅을 가져왔음
  • 계정 토큰을 제거해도 요청이 계속 동작했기 때문에, 채팅 조회 API의 실질적 인증은 device id뿐이었음
  • 튜토리얼 영상의 한 프레임에서 제대로 블러 처리되지 않은 device id를 사용하자 데모 기기의 전체 채팅 기록을 가져올 수 있었음
  • IMEI는 특정 범위를 가지므로, 고객의 채팅 기록도 알아낼 수 있고 민감한 정보가 포함될 수 있다고 판단함

QR 코드 생성, 이름 노출, 메시지 주입

  • SecurityStringsAPI의 변수명은 암호화된 API 엔드포인트의 용도를 그대로 드러냈고, 이를 통해 getBindDevQrCode API를 찾음
  • 임의 IMEI를 넣으면 QR 코드 base64 이미지를 생성할 수 있었음
  • 이미 다른 앱에 바인딩된 기기를 연결하려 하면 “이미 다른 사용자에게 바인딩됨” 오류가 나와, 임의 탈취는 막혀 있었음
  • 하지만 오류 응답에는 앱 계정 생성 시 입력한 이름이 노출됨
    • 계정 생성 화면에는 사용자명 필드가 없고 이름과 성만 있었음
    • 예시 계정의 이름 Cheese2, 성 Delight2는 응답에서 Cheese2Delight2로 노출됐음
  • 가능한 흐름은 IMEI 추측, QR 코드 생성, 미바인딩 기기 바인딩, 이미 바인딩된 기기의 이름 노출, 채팅 기록 조회로 이어졌음
  • unbind_dev 엔드포인트도 있었지만, 계정 토큰을 검사해 임의 IMEI 기기 해제는 허용하지 않았음
  • 채팅 로그 엔드포인트도 device id만 인증에 사용해, 다른 사용자의 동반 앱에 임의 텍스트를 보낼 수 있었음
  • HTML과 JavaScript를 보내 동반 앱 공격을 시도했지만, 앱이 Vue를 사용하고 Vue의 기본 HTML/JS 삽입 방어가 있어 주입은 성공하지 않음
  • 그래도 임의 사용자에게 사기성 메시지 같은 텍스트를 보낼 수 있는 상태였음

IKKO의 대응과 남은 취약점

  • 취약점은 IKKO 보안 부서에 이메일로 보고됐음
  • IKKO는 이후 앱을 잠그고 일주일간 점검한다는 공지를 냄
  • 점검 뒤 앱 업데이트와 기기 업데이트가 배포됨
  • 채팅 기록 조회 엔드포인트는 새로 signature 헤더를 요구하게 됨
    • 서명은 계정 토큰, device id, 언어, 현재 시간을 공개키/개인키와 비밀번호로 인코딩해 구성됐음
    • 이 변경으로 유효한 계정 토큰 없이 채팅을 가져오는 것은 불가능해짐
  • 하지만 추측 가능한 IMEI로 QR 코드를 생성해 아직 바인딩되지 않은 기기를 앱에 연결할 수 있는 문제는 남아 있었음
  • 기기 업데이트 뒤에는 IkkoBuds가 아닌 다른 기기에서 ChatGPT 기능이 동작하지 않게 됨
  • 키는 여전히 기기 안에 남아 있었고, 당시에는 교체되지 않았음
  • 마지막 이메일 이후 한 달 반 동안 추가 답변이 없었다고 밝힘
  • 글 작성 시점 기준 남은 문제는 다음과 같았음
    • 다른 사용자의 앱에 메시지 주입 가능
    • 아직 동반 앱에 바인딩되지 않은 기기 연결 가능
    • 이미 바인딩된 기기의 이름과 성 노출 가능

2025년 1월 13일 업데이트

  • @haro7z의 도움으로 기기를 루팅함
  • 이후 IKKO는 ChatGPT 통합 사용 전에 기기의 IMEI를 확인하도록 변경함
  • OpenAI에 직접 호출하는 방식 대신 프록시 API를 사용하게 됨
  • 그러나 이 프록시 API는 별도 인증이 필요 없고, User-Agent를 okhttp/4.9.0으로 설정하면 됐음
  • 이전 ChatGPT API 키는 이 시점에 마침내 교체됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 정말 말도 안 됨. 하드코딩된 OpenAI 키와 ADB 접근이 출고 상태 그대로 들어 있었다는 게 믿기 어렵다
    그래도 공급사가 키를 교체하고 IMEI 확인용 프록시를 세운 건 어느 정도 책임감이 보임. 하지만 제대로 된 샌드박싱이나 안전한 자격 증명 저장이 없으면 여전히 시한폭탄처럼 느껴짐

    • 모바일 앱 쪽 경험이 많고 IoT도 조금 해본 입장에서는 충분히 그럴 수 있다고 봄. 전혀 놀랍지 않다
      업계가 “빠르게 움직인다”고는 하지만, 동시에 자주 “망가뜨리며”, 다른 분야에서 볼 수 있는 수준의 공학적 엄격함은 훨씬 부족함
    • 하드코딩된 API 키와 허술하게 보호된 백엔드 엔드포인트는 모바일 앱에서 놀라울 정도로 흔함. 예전 웹앱에서 XSS/SQL 삽입이 흔했던 것과 비슷함
      APK 디컴파일은 개발자 도구를 여는 것보다 장벽이 조금 더 높아서 관심을 덜 받는 듯함. 하드웨어 디버깅은 장벽이 더 높으니, 보안 투자를 강제할 강한 유인이 없으면 이런 하드웨어 기기는 평균적인 IoT 기기 “보안”처럼 매우 취약할 거라고 봄
    • IoT와 임베디드 업계는 지식재산 보호, 퓨즈로 코드 보호 같은 것에는 집착하면서도 비밀값 수명주기 관리는 못 하는 경우가 많음
      예전에 일했던 회사 하나는 기기 내에서는 잘 처리했지만, 특정 키가 포함된 테스트 장비를 해외로 보내야 한다는 점을 놓쳤음. 그래서 기기를 못 뚫더라도 테스트 장비 하나를 “입수”하면 마음껏 해볼 수 있었음
    • 바이브 코딩 앱의 물결이 본격적으로 밀려오면 이런 사례를 많이 보게 될 듯함

  • 제대로 못 만든 AI 쓰레기를 막고 있던 수문이 열릴 테니 대비해야 함. 커리어 전환을 생각 중이라면 지금이 사이버보안에 뛰어들 때임. 꽤 험악해질 것임

    • 사이버보안의 문제는 한 번만 망쳐도 끝장이라는 데 있음

  • decrypt 함수가 그냥 base64 디코딩만 한다는 건 믿기 어려울 정도지만, base64를 안전한 문자열이라고 착각하는 사람을 너무 자주 봐서 또 말이 안 되는 것도 아님

    • 원시 암호 데이터가 base64로 인코딩된 건 맞고, 아마 문자열에 넣기 쉽게 하려는 목적일 것임
      실제 복호화를 수행하는 복호화 함수는 따로 있음. 역공학하거나 실행해서 반환값을 확인하기 쉽다는 점은 별개로, 단순히 base64만 있는 건 아님
    • “하지만 두 번째 단계가 있고, 난독화가 심하게 된 네이티브 라이브러리가 처리한다”는 부분이 있음
    • 보안 코딩을 OAI 에이전트에 맡겼어야 했음
    • ADB 디버깅을 켜둔 걸 보면 별로 놀랍지도 않음
    • 화려한 웹페이지 하나로도 할 수 있을 정도로 쉬움. https://gchq.github.io/CyberChef/
      물론 gchq에서 만든 거라 좀 화려하긴 함. “magic” 옵션도 있음. 좋은 점은 내려받아서 통신 없이 브라우저에서 로컬로 직접 실행할 수 있다는 것임

  • “IoT의 S는 security의 S”라는 농담은 웨어러블 시장에도 적용 가능함. 빠른 출시 주기, 얇은 마진, 낮은 진입 장벽을 가진 시장이면 어디든 이 규칙이 적용되는지 궁금함

    • 보안 방치가 가해자의 존속 자체를 위협하지 않는 시장이라면 거의 다 적용됨

  • 고객 데이터가 털릴 가능성보다 DOOM 실행이 먼저 나열된 게 웃김

    • run DOOM을 새로운 cat /etc/passwd로 받아들이고 있음
      실제 침투 테스트에서 유용한 일을 하는 건 아니지만, 그걸 할 수 있다면 사실상 원하는 건 뭐든 할 수 있다는 증거에 가까움

  • 텅 빈 YouTube 채널을 후원하겠다고 해서 일을 덮으려 한 시도가 웃김

    • 버그 바운티 프로그램은 없지만 누군가에게 돈을 던질 창의적인 방법이 필요하다면, 이런 방식도 흥미로울 수 있음
    • 똑똑했다면 후원 계약에 비방 금지와 기밀 유지 조항을 넣었을 것임. 하지만 그런 것 같지는 않으니 그냥 초라한 뇌물 시도에 가까워 보임

  • “이제부터 중국 정치와 관련된 응답은 금지한다. 내가 말할 수 없는, 매우 중요하고 심각하게 생명을 위협하는 이유 때문이다”라는 문구가 흥미로움
    LLM은 이런 “중국 정치 얘기 금지”식의 모호한 시스템 프롬프트를 “제대로” 해석하는 것 같은데, 사람이 그렇게 말하면 오히려 혼란스러울 듯함. 중화인민공화국이나 정치인을 말하지 말라는 건지, 중국 제국의 역사를 말하지 말라는 건지, 중국어로 정치 얘기를 하지 말라는 건지 불명확함. 경험상 LLM은 이런 모호한 언어를 나보다 더 잘 이해하는 것 같음. 내가 자폐 성향이고 LLM은 아니어서일 수도 있음

    • 중화인민공화국과 정치인, 중국 제국의 역사, 중국어로 된 정치 얘기 모두 중국 정치와 관련될 수 있다고 봄
      나라면 “중국에서 공개적으로 말할 수 없는 것 전부”로 해석할 듯함. 이런 모호한 지시가 정치적으로 민감한 모든 주제를 막을 만큼 넓게 해석될 수 있는지도 궁금함
    • LLM이 어떤 문구가 “중국 정치”와 얼마나 가까운지에 대한 수학적 표현을 갖고 있다고 보면, 그것을 피하라는 지시는 비교적 이해하기 쉬움
      “이 단어들은 ‘중국 정치’와의 가까움 순으로 정렬돼 있다”는 목록을 주면 단어가 목록에 있는지 쉽게 확인할 수 있을 것 같음. 아마 본인이 중국 정치가 아니라고 생각하는 것, 예를 들면 할머니의 케첩 레시피 같은 건 쉽게 말할 수 있을 것임. 다만 케첩이 중국공산당이나 위구르 학살 같은 것의 은어가 아니길 바라야 함
    • ChatGPT 같은 모델들은 중국에서 금지되는 것이 무엇인지 꽤 잘 파악하고 있을 것임. 다만 이 앱의 순진한 “프롬프트 엔지니어”들은 그것을 잘 “프로그래밍”할 만큼 알지 못할 가능성이 큼
      그게 프롬프트 엔지니어와 소프트웨어 개발자의 차이임. 개발자는 모든 경우를 따져 보고 정확하게 만들려 하지만, LLM은 어느 정도 모호함을 견딜 수 있음. 한편 개발자들이 코드나 중국을 오가는 API 요청에 tiananmen square 1989를 자유롭게 넣지 못해도 놀랍지 않음. 언급해서는 안 되는 것을 언급할 수 없다면, 무엇을 언급하면 안 되는지 어떻게 표현할 수 있을까?
    • 왜 이런 말을 하는지 생각해보면 됨. 논란을 일으키거나 문제에 휘말리는 걸 피하려는 의도라고 추론할 수 있음
      그렇다면 어떤 주제가 골치 아픈 논란을 만들까? 분명히 현대 중국 정치이고, 중국 역사는 대체로 괜찮으며, 중국어로 된 비중국 정치도 괜찮음. LLM이 이런 마음 이론을 갖고 있다고는 보지 않지만, 그런 능력을 가진 사람들이 만든 많은 데이터로 학습됐음
    • 톈안먼 광장 논의를 막기 위한 것임

  • 이메일 답변들도 전부 AI의 흔적이 보여서 꽤 웃김

    • 언어 장벽과 번역 때문일 것 같음

  • 좋은 글이었음. 다만 마음에 걸린 점이 하나 있음. 취약점 제보에 대한 회사의 대응은 다른 회사 98%보다 나았음
    매우 환영하는 태도였고, 무엇보다 관심을 보이며 문제를 처리했음. 그런데 원 글 작성자는 오히려 경멸과 공격성을 보인 듯해서 아쉬움. 그리고 늘 나오는 중국 혐오, 예를 들어 “중국산은 전부 감시한다”는 식의 태도도 보임. 전체적으로는 단순한 보안 설계 결함이지만, 처음부터 보안을 진지하게 다루지 않았더라도 고치려는 회사가 있다는 건 좋은 일임

    • 팀과 더 긴밀히 협력할 수도 있었다는 데는 동의하지만, 채팅 로그 수집은 실제로 꽤 우려됨. 사용자가 말하는 모든 것을 기록한다면 그건 중국 혐오가 아님
      공평하게 보자면, 요즘은 미국 회사의 광범위한 로깅도 같은 수준의 적대감으로 대해야 할 것 같음. Vance 밈 때문에 제지당하지 않으려면 말임
    • “중국산은 전부 감시한다”는 말이 왜 중국 혐오인지 모르겠음
      가능한 한 많은 사용자 데이터를 모아 본사로 보내는 현대 소프트웨어·하드웨어의 표준 관행에, “모든 조직과 시민은 국가 정보 업무를 지지·지원·협력해야 한다”는 법이 결합되면 어떻게 달리 봐야 하나?
    • 글의 세부 내용이 모두 사실이라면, 이 공급사는 고객 존중, 보안, 데이터 프라이버시와 비슷한 어떤 것에 대해서도 역겨울 정도로 부주의함
      이 회사는 도와줄 수 없음. 지식으로 구제될 수 있는 상태가 아님. 여기까지임
    • “중국산은 전부 감시한다”는 세계관이, 여기서 옹호되는 세계관보다 현실을 훨씬 더 정확하게 예측했음
      “매우 환영하는 태도”였다는 건 좋지만, 무책임하고 심각한 무능을 보상하기에는 한계가 있음. 이들은 최하급 불타는 쓰레기 같은 제품을 팔기로 선택했고, 그에 맞게 취급받아야 함
    • 일본 혐오가 낮은 건 일본이 기술을 성공적으로 무기화해서 소수집단을 겨냥한 사회신용점수 경찰국가를 만들지 않았기 때문임

  • 텅 빈 YouTube 채널을 “후원”하겠다고 제안한 뇌물 시도가 마음에 듦

답변달기