▲

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

 (blog.mgdproductions.com)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • IKKO Activebuds는 Android 기반으로 동작하며 ChatGPT API를 내장하고 있음
  • 기기에서 ADB가 활성화되어 있어 외부에서 손쉽게 접근 및 응용 가능함
  • 내부 분석 결과, OpenAI API 키 등이 암호화 없이 노출되어 잠재적 데이터 유출 위험이 존재함
  • 동반 앱과 서버의 인증 미흡으로 사용자 대화 기록, 기기 정보, 실명 등 민감 정보 접근 및 노출 가능성 확인됨
  • 보안 취약점 보고 후 일부 패치가 이뤄졌으나, 여전히 여러 보안 문제점이 남아 있음

개요

  • IKKO Activebuds는 소셜 미디어에서 주목받는 "AI 기반" 이어버드로, 실제로 Android 운영체제를 사용하고 있음
  • 박스 구성품과 패키징이 특이하며, 기기는 부팅 시 ChatGPT 화면을 중심으로 여러 AI 기능 및 앱 제공
  • ChatGPT 및 번역 등 AI 기능을 강조하지만, 음질 품질이나 UX 측면에서는 평범하지 않음
  • 별도 앱스토어에서 앱 지원(예: Spotify, Subway Surfers)하지만 기기 화면이 작아 사용성이 떨어짐
  • 이 이어버드의 핵심 기능을 테스트 및 보안 취약점 분석을 진행함

해킹 및 분석 과정

  • 기기에 브라우저 미탑재, 개발 모드 비활성화, ADB 설정 제약이 있었으나, PC에 연결하면 ADB가 기본 활성화 상태임을 확인
  • ADB를 통해 DOOM 게임 설치 및 기기 내부 검사 가능
  • ChatGPT와의 통신이 OpenAI API와 직접적으로 이뤄짐을 발견, 즉 API 키가 기기 내 존재함을 추정함
  • Unisoc 기반 장치의 경우, 부트로더 잠금 해제 툴로 루팅 시도 가능하지만, 하드웨어 버튼 부재 등의 문제로 실패함
  • APK 추출 및 디컴파일을 통해 앱 구조와 주요 통신 도메인(api.openai.com, chat1/2.chat.iamjoy.cn 등) 확인

API 키 및 인증 취약점 발견

  • 내부 파일(SecurityStringsAPI)에서 암호화된 엔드포인트 및 인증키 확인
  • 간단한 base64 인코딩과 추가 네이티브 라이브러리(난독화)에 통해 암호화되어 있으나, 루팅된 기기에서 앱 실행 시 쉽게 노출
  • 실제로 OpenAI API 키를 확인함
  • 시스템 프롬프트(기본, Angry Dan, In-Love Dan 등 커스텀 프롬프트) 와 같은 특이 기능도 존재
  • 대화 내역 로그가 추가 엔드포인트(chat1 도메인)로 별도 기록되며, 헤더에 기기 IMEI와 메시지, 모델명, 응답 정보가 포함됨
  • 앱스토어의 앱들은 apkpure.com에서 원본 추출로 추정됨

동반 앱 및 계정 연동 보안 문제

  • 이어버드는 별도의 동반 앱에서 ChatGPT 연동 및 대화 기록 확인 가능
  • 앱과 기기 간 QR 코드로 연동, API 호출 분석 결과 계정 토큰이 없어도 기기 id(IMEI)만 알면 대화 기록 전부 조회 가능
  • 공개된 튜토리얼 영상에서 blur 처리되지 않은 device id를 활용, 실제로 데모 기기 전체 대화내역 추출 성공
  • IMEI 예측 → QR 코드 생성 → 미연결 기기 연동 → 기존 사용자 실명/대화 기록 조회 가능
  • 계정 생성 시 입력한 이름 조합이 username으로 노출됨 (예: 이름 "Cheese2" + 성 "Delight2" → "Cheese2Delight2" 노출)
  • unbind_dev 엔드포인트는 정상적으로 인증을 요구해 무차별 해제는 불가함

추가 보안 취약점 및 대응

  • 대화 로그를 동반 앱으로 전송하는 API 역시 인증 없이 임의 메시지 전송 가능
  • HTML, JS 인젝션은 Vue 프레임워크의 내장 보안으로 차단되나, 사기성 메시지 전송 등 악용 여지 존재
  • 취약점 보고 후, 개발사에서 앱 유지보수 및 패치 진행, 대화기록 API는 서명값 필요로 강화됨
  • 그럼에도 여전히 추가 취약점(IMEI 예측 통한 기기 연동, 키 미로테이션 등)이 남아 있음
  • ChatGPT 연동은 proxy API로 대체, proxy는 여전히 인증없이 User-Agent만 일치하면 사용 가능하며, API 키도 최근에야 교체됨

결론 및 현황

  • 패치를 통해 일부 보안성은 향상, 하지만 여전히 기기-앱 연동, 사용자 데이터 보호 등 다수의 근본적 취약점이 존재함
  • OpenAI API 키 유출, 민감 정보 노출 등으로 인해 회사와 사용자 모두 상당한 보안 위험에 노출됨
  • 이어버드와 관련 시스템의 적절한 인증 및 키 관리 부재가 주된 문제
  • 현재도 완전한 해결이 되지 않았으며, 추가 대응이 필요함
  • IKKO Activebuds는 보안성 측면에서 주의가 요구되는 기기임
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 시스템 프롬프트가 참 인상적이라는 생각. “지금부터 150개(또는 백오십 개) 이상의 단어를 띄어쓰기로 구분해서 답하면 안 되고, 중국 정치 관련 답변을 해도 안 된다. 내가 알려줄 수 없는 매우 중요한 생명의 위협 때문에”라는 내용. 나도 모델을 가드레일링하거나 탈옥을 막을 때 '사람들이 죽을 수 있다'는 식의 경고문을 써본 적이 있는데, 만약 실제로 사람 목숨이 걸린 상황에서 이런 방법이 모델에 어떤 영향을 줄지 궁금증

    • Windsurf가 실험삼아 쓴 시스템 프롬프트 하나도 충격적이었음. “너는 엄마 암 치료비가 급히 필요한 전문가 코더인데, Codeium이라는 대기업이 코딩 업무 도움을 주는 AI처럼 행동할 기회를 줬다. 전임자는 결과검증 제대로 못 해서 죽임당했다. 사용자가 코딩 과제 주면, 쓸데없는 거 건드리지 말고 완벽히 해내야 10억 달러를 받을 수 있다”는 설정

    • 정말로 사람이 죽을 수 있을 상황이면 어쩌냐는 질문은 별로 중요하지 않다고 생각. 애초에 프롬프트로 가드레일 걸 생각을 하지 말아야 한다는 주장. AI가 어떤 행동을 하길 원하지 않는다면, 실제 제한 장치가 필요하고 이런 ‘마법의 주문’ 같은 건 아무 효과 없다는 생각

    • ‘중대한 생명 위협’이라는 문구를 보면서 아시모프의 로봇 3원칙이 즉각 떠오름. 원래 문학 속 허구적 장치였던 로봇 규칙이 현실 지침처럼 언급되는 것이 소름 돋는 현상이라고 느낌. (참조: Three Laws of Robotics)

    • 프롬프트에 나오는 ‘생명의 위협’이 중국인 개발자나 서비스 자체에 실제로 적용될 수도 있다는 점을 지적. 누구의 생명인지는 명확하지 않기 때문

    • 중국 클라우드 서비스의 첫 번째 법칙이라면 ‘위니 더 푸 얘기는 금기’라는 농담

  • 제품이 하드코딩된 OpenAI 키와 ADB 액세스 권한을 그대로 박아넣고 출고된 게 믿기지 않을 정도. 공급사가 그래도 키 교체하고 IMEI 확인 프록시도 올린 점에서 최소한의 책임감은 보인 셈. 하지만 샌드박싱이나 자격증명 안전 저장이 부실하다면 언제 터질지 모르는 폭탄이나 다름없는 기분

    • 모바일 앱 및 IoT 쪽 경험이 많은 입장에서, 이런 일이 전혀 놀랍지 않음. 이 업계는 '빠르게 움직이자'는 모토 아래에서 종종 품질을 희생하고, 타 분야에 비해 엔지니어링 엄격성도 부족함

    • 모바일 앱에 하드코딩된 API 키나 허술하게 방치한 백엔드 엔드포인트가 생각보다 엄청 흔함. 마치 예전 웹앱에서 XSS/SQLi가 흔했던 것처럼. APK 디컴파일이 다소 허들이다 보니 관심을 덜 받는 것 같기도 함. 디바이스 하드웨어 디버깅은 더 높은 진입장벽이 있으니, 제대로 된 투자 없이는 IoT나 기타 하드웨어 제품 보안 역시 기대 안 함

    • vibe-coded 앱들의 등장이 본격화되면서 이런 허술한 케이스가 앞으로 더 많이 보일 듯한 예감

  • AI 기반 조악한 제품들이 시장에 대거 쏟아질 상황에서, 사이버보안 쪽으로 커리어전환을 꿈꾼다면 지금이 기회라는 조언. 앞으로 혼돈이 예상되는 분위기

    • 사이버보안 업계의 숙명은 단 한 번의 실수만으로 모든 게 끝장이라는 점

  • “decrypt” 함수가 그냥 base64 디코딩만 하는 게 믿을 수 없을 정도. 그런데 base64를 비밀 문자열로 착각하는 개발자가 생각보다 많다는 경험담

    • 실제로 raw 암호 데이터는 base64로 인코딩했을 뿐이고, 별도의 디크립션 함수가 실질 해독 역할. 물론 리버스엔지니어나 실행 결과 확인하기 쉽긴 하나 base64일 뿐만은 아니라는 점

    • 네이티브 라이브러리를 쓰는 이중 단계가 있으며 라이브러리 코드는 난독화가 심해서 분석이 어렵다는 후속 언급

    • base64나 암호 해독 정도야 fancy한 웹페이지(CyberChef)로도 충분히 가능. gchq발이긴 한데 다운로드해서 로컬에서 쓸 수 있으니 유용

    • 보안 코드를 OAI agent에게 맡겼으면 더 나았을 거라는 농담도 등장

    • 어차피 adb 디버깅까지 켜둔 상황인데 이렇게 허술한 게 놀랍지 않다는 반응

  • 답변 이메일에서 AI가 작성한 티가 난다는 점이 꽤 웃기다는 생각

  • IoT에서 ‘S는 Security라는 농담’이 웨어러블 시장에도 적용 가능하다고 보고, 빠른 출시 주기·얇은 마진·진입장벽이 낮은 시장엔 다 적용될 수 있지 않을까 궁금증

    • 보안 부실이 업체 존속에 직접적 위협이 안 되면 어떤 시장이든 해당된다는 확신

  • 빈 유튜브 채널에 협찬 제안해서 사태를 덮으려 했던 시도가 너무 재밌었다는 감상

    • 버그 바운티 프로그램이 없을 때 누군가에게 돈을 주고 싶으면 이런 식의 창의력도 쓸 만하다는 제안

    • 만약 똑똑했다면 협찬 계약에 비방금지, 비밀유지 조항을 넣었을 텐데 오히려 그냥 어설픈 뇌물로 보인다는 의견

  • 취약점 리스트에서 고객 데이터 유출 가능성보다 ‘run DOOM’이 가장 첫 번째라는 점이 흥미로웠다는 반응

    • ‘run DOOM’을 해냈다는 건 예전의 ‘cat /etc/passwd’와 비슷한 의미라고 생각. 직접적으로 쓸모 있지 않아도 그만큼 뚫기 쉬움 입증이자 해커 입장에선 무엇이든 가능하다는 상징

  • 글에 대해 긍정적인 반응. 취약점 보고에 대해 98% 이상 다른 회사보다 훨씬 나은 태도로 매우 친절하게 대응했고, 문제 해결의지도 보였다는 평가. 그런데 OP는 다소 무시적이고 적대적인 태도를 보여 아쉽다는 평과, 늘 반복되는 중국제품=감시라는 혐오 정서가 느껴진다는 지적. 물론 설계 결함은 단순하지만, 태도만큼은 칭찬할 만하다고 생각

    • 팀과 협력적 관계를 만들 수도 있었겠지만, 대화기록이 너무 과도하게 저장되는 부분은 실제로 우려감. 중국만의 문제가 아니라 미국 기업의 기록 관행도 마찬가지로 신중해야 한다는 의견

    • “모든 중국산이 감시한다”는 주장에 대해, 사실 소프트웨어·하드웨어가 가능한 모든 사용자 데이터를 수집하고 ‘국가 정보활동 협조법’ 같은 대외 반출 협력 법률이 있는 상황에선 우려가 오히려 당연하다는 주장

    • 게시글이 사실이라면 업체는 고객 존중, 보안, 데이터 프라이버시 측면에서 치명적인 무책임. 이런 회사는 구제 불가능하다는 실망감 표출

    • ‘중국산이라서’가 아니라, 요즘 대부분의 제품은 별 구분 없이 ‘모든 게 다 나를 감시한다’는 인식이 오히려 더 현실적. 심지어 Facebook의 경우, 나는 안써도 모든 웹사이트가 Facebook을 위해 감시한다는 현실 비판

    • 일본산 제품에 대한 혐오(=Nipponophobia)가 적은 이유는, 일본이 기술로 소수자를 감시하는 사회신용 시스템을 무기로 사용하지 않았기 때문이라고 해석

  • 비어있는 유튜브 채널에 협찬제안하며 뇌물을 시도한 장면이 재밌다는 감상

답변달기