▲

신용카드 단말기에서 root shell 획득

 (stefan-gloor.ch)
3P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • Worldline Yomani XR 신용카드 단말기의 보안 연구를 위해 리버스 엔지니어링을 시도함
  • 내부 분해 과정에서 물리적 침입 감지 기능은 잘 구현되어 있으나, 소프트웨어적으로 루트 셸이 외부 시리얼 포트에 노출되는 문제가 발견됨
  • 메모리 언납, 펌웨어 추출 및 분석을 통해 리눅스 3.6 커널 기반의 시스템 구조와 매우 오래된 구성요소들을 확인함
  • 시리얼 콘솔 포트를 통해 장치를 분해하지 않고도 쉽게 루트 권한 획득 및 악성 코드 설치가 가능함을 입증함
  • 전체 결제 및 인증 관련 중요한 작업은 별도의 보안 프로세서에서 이루어져, 실제로 중요한 데이터 노출 위험은 크지 않음

프로젝트 개요

  • 본 프로젝트는 결제 단말기의 보안 연구 목적으로 Worldline Yomani XR 모델을 역분석하는 과정을 중심으로 함
  • 스위스 전역에서 널리 사용되는 이 모델은 현재 단종이지만 여러 대형 소매점과 소규모 매장에서 여전히 사용 중임

첫 관찰 및 하드웨어 분해

  • UI 탐색, 포트 스캔 등 기본적인 조사 이후 하드웨어 분해를 시작함
  • 여러 PCB, 소재가 잘 구성된 하우징, 커스텀 ASIC 기반의 듀얼 코어 Arm 프로세서 등, 상당한 하드웨어 보안성이 관찰됨
  • 주요 SoC는 Samoa II란 코드명의 전용 ASIC이며, 외부에 플래시와 RAM이 탑재됨

침입 감지 및 위변조 보호

  • 하우징을 열지 않고도 압력 감지식 보드 연결(Zebra strip) 불량이나 나사 풀림만으로 침입 이벤트가 감지됨
  • 배터리를 통해 전원 차단 상황에서도 감지가 유지됨
  • 주요 PCB에 지그재그 동선(트레이스) , 카드 리더에 감싼 플렉시블 PCB 등이 손상 시 침입 탐지됨
  • 잠시 해체 후 재조립 시, 침입 감지로 인해 장치는 빨간 "TAMPER DETECTED" 화면만 표시하며 외부 입력에 응답하지 않음

칩-오프 펌웨어 추출

  • 온보드 플래시를 디솔더링하고 직접 연결해 펌웨어를 추출함
  • 데이터는 암호화되지 않았으나, 독특한 ECC 구조와 YAFFS2 파일 시스템의 메타데이터 배치가 확인됨
  • 파일시스템 리더를 구현하여 전체 파일 목록을 확보함
  • 시스템은 2010년 버전 Buildroot 기반 3.6 커널 사용, uClibc와 busybox, 오래된 라이브러리들이 다수 존재함

우연히 루트 셸 발견 과정

  • 펌웨어 분석 후, 플래시를 다시 연결하고 시리얼 콘솔 회선을 찾아 논리 분석기로 신호를 잡음
  • 부트 로그와 함께 로그인 프롬프트가 노출됨
  • "root" 입력 시 암호 없이 즉시 루트 셸 진입이 가능함
  • 실제로 이 시리얼 포트는 외부에서 커버만 열면 바로 접근 가능함
  • 공격자는 단말기를 분해하지 않고도 신속하게 접속, 악성코드 주입 등이 가능

얼마나 심각한 문제인가?

  • 부트 및 시스템 구성 분석 결과, 리눅스는 네트워크, 업데이트, 일부 비즈니스 로직만 담당함
  • 카드 결제, PIN 입력, 디스플레이 등 모든 보안 관련 기능은 별도의 mp1 프로세서가 관리함
  • 리눅스(mp2)는 항상 부팅되며, 이후 서명·암호화된 이미지가 보안 부트로더에 의해 보안 코어로 적재됨
  • 내부적으로 보안 코어 보호는 멀쩡히 동작 중이며, 보안 핵심 데이터는 루트 셸 노출로 유출되지 않음

공개 및 보고 일정

  • 2024년 11월 14일: 루트 셸 발견
  • 2024년 11월 15일: 제조사에 90일 공개 예정과 함께 알림
  • 2024년 11월 18일: 제조사로부터 보고 확인 회신
  • 2025년 6월 1일: 프로젝트 공개

결론

  • 외부 시리얼 포트를 통한 루트 셸 노출은 명백한 불필요 공격면이자 엔지니어링 실수임
  • 다만 보안 프로세서 분리 설계 덕분에, 실질적인 결제 정보 노출 위험은 낮음
  • 루트 로그인 허용이 프로덕션 펌웨어에 실수로 적용됐거나, 버전에 따라 다를 수 있음
  • 연구 과정에서 일부 장치는 루트 로그인 기능이 아예 비활성화된 것도 존재함
  • 내부적으로 해당 문제는 이미 인지 및 수정됐을 가능성이 있음

이 프로젝트는 여러 흥미로운 결과를 남겼으며, 펌웨어 심층 탐색의 가치도 다시금 보여줌

▲
GN⁺ 4일전  [-]
Hacker News 의견

  • 젊은 개발자들에게 한마디, “Hacker News”의 해커는 바로 이런 의미라는 설명, 이 게시글이 전형적인 해커의 여정을 쉽게 단계별로 분석한 예시라는 추천, 비슷한 사례를 더 알고 싶다면 Hack-a-day를 참고해볼 만하다는 안내, 글쓴이가 호기심 많고 기본 지식도 아주 탄탄한 인물처럼 보인다는 평, 본질적으로는 칩 데이터시트 조사, 손상 없이 디솔더링, 메모리라면 와이어로 재연결, 임기응변과 시행착오, 다음에는 얕은 구멍을 뚫을 때 핀홀 카메라를 써서 훼손 흔적을 피하는 방법도 고려해볼 만하다는 조언, 만약 글쓴이가 훼손 방지 체크도 뚫고 정상 작동까지 시도했다면 정말 흥미로웠을 거라는 아쉬움 공유

    • 해커라는 용어는 컴퓨터 보안에만 국한된 것이 아니라 훨씬 포괄적인 의미와 철학적 정의를 가진다는 설명, Guy Steele 등이 정리한 Jargon File을 인용해 해커의 정의를 소개, 예를 들면 “프로그래밍 시스템의 세부를 배우고 그 한계를 넓히는 걸 즐기는 사람”, “프로그래밍 자체를 열정적으로 즐기는 사람”, 그리고 “특정 프로그램에 능한 전문가”까지 다양한 의미로 쓰인다는 요약, 아마도 Hacker News 창립자 PG도 이 넓은 정의를 염두에 두고 이름을 지었으리라는 추정, 해커 용어의 역사에는 The UNIX-HATERS Handbook도 꼭 언급해야 한다는 첨언

    • 첫 번째 문장에 절대 공감, 오늘날 한 번만 더 LLM 래퍼가 나오면 정말 질릴 것 같다는 감상

    • 이 사이트가 VC 스타트업 인큐베이터에서 나왔다고 해킹 보안을 의미한다고 보긴 힘들다는 견해, 아마도 “move fast and break things”라는 스타트업식 해킹, 즉 빠르게 코드를 쏟아내며 문제를 돌파하는 스타일이란 뜻에 가깝다는 해석

    • 오랜 기간 눈팅만 하다가 최근에야 계정을 만들어 댓글을 달기 시작했는데, 이런 정보와 실행력이 돋보이는 게시물이야말로 Hacker News의 ‘해커’ 정신을 보여준다는 찬사

    • 이 글이 실제로 해킹에 관한 내용이라 처음으로 추천 버튼을 눌렀다는 고백, 평소엔 댓글에만 추천을 주지만 이 글은 예외였다는 말

  • $2 USB 카드 리더로 가짜 신용/직불카드 거래 시뮬레이션이 가능하다는 소개, 모든 명세와 프로토콜이 방대하지만 공개되어 있어 문서만 읽으면 구현할 수 있다는 설명, 하지만 실제 거래를 승인 받으려면 인터넷을 통해 은행에 데이터를 보내야 하고 그렇게 하면 곧바로 당국(예: FBI)이 출동할 수밖에 없다는 경고, 카드 리더 자체에는 거의 보호 장치가 없으며(대부분 리눅스와 약한 비밀번호 사용), 보안성은 상점과 은행 간의 계약과 규정에서 비롯된다는 설명

    • 카드 리더에 ‘보호 장치가 없다’는 주장에 반박, 실제로는 서명된 바이너리만 실행할 수 있고, 실행 파일 시스템은 읽기 전용, 데이터 파일 시스템에도 noexec 플래그, 루트 로그인 비활성화, 기능 축소된 busybox, 키는 부팅 시 보안 구역에서 적재, 마스터 키 삽입도 공장에서만 가능, 부팅 자체도 매우 안전하고, 훼손 감지 시 칩 자체가 공백으로 초기화되는 구조라는 상세 설명, 저가형 미인증 단말기는 보안이 거의 없을 수 있지만, EMV 개발 경험자로서 실제 단말기는 거의 완벽하게 잠겨 있다는 경험담 공유

    • ‘상점과 은행 간 규제가 유일한 보안’이라는 부분은 정확하다는 인정, 그래서 사람들이 휴대용 카드 리더로 비접촉 카드에서 돈을 훔친다는 음모론은 실행에 옮기기 힘들다는 의견, 실제로 거래를 만든다 해도 이후 절차나 이전 준비 단계 때문에 돈을 안전하게 빼가는 건 거의 불가능에 가깝다는 지적, 특히 요즘은 거래 푸시 알림 덕분에 범죄 시도가 드러날 가능성이 높다는 추정

    • 카드 리더가 현장에서 해킹되어 캐시된 CC정보를 읽거나 인터셉트형 악성코드가 설치되는 상황이 더 걱정이며, 이 분야의 연구가 중요한 이유라는 의견

    • 거래는 은행에 인터넷으로 전송해야 승인된다는 내용은 사실과 다르다는 설명, 은행이 카드 거래를 처리하는 오픈 API를 인터넷에 갖고 있지 않다는 지적

    • 카드 리더 보안은 약하다는 주장에 동의하지 않으며, 실제로 상점 단말기엔 은행 및 결제 네트워크 키를 안전하게 저장하는 보안 하드웨어가 내장되어 있다는 설명, 만약 그 키가 유출되면 합법 거래를 위조하는 게 가능하다고 덧붙임

  • Stripe M2 리더 36개를 구매해 쓰다 7개가 고장난 경험담, 2개는 배터리가 충전을 못하고 1개는 NFC 스캔 불가, 4개는 ‘훼손됨’ 오류를 내며 사망, 표면적으론 불량률이 심각하지만 사용 일수와 연식 등 맥락도 따져봐야 한다는 이야기, 실제로 1~3년 된 리더를 총 9일만 사용했음에도 7개나 고장났다는 점이 더 심각하다고 느낀다는 불만, 이동 시엔 각각 하드쉘 케이스와 폼 인서트로 철저히 관리하고 있어 보관 불량도 아니라고 함, 그럼에도 Stripe M2 리더가 여전히 가장 쓸 만한 선택지라 어쩔 수 없이 사용 중이라는 현실 설명, 참고로 회사가 축제 결제 담당이라 단기간만 대량으로 사용하게 된 배경도 추가

    • 다음 행사 전에는 반드시 완충 상태로 보관할 것을 권장, 대부분 배터리가 낮은 충전 상태로 오래 방치되는 걸 싫어하고, 훼손 감지 기능도 배터리가 정상이어야 작동할 가능성을 언급

  • 물리적으로 훼손 방지가 활성화되면 루트 셀이 열릴 수도 있다는 상상, 즉 시스템이 필요한 모든 암호키를 가진 보안 모드이거나, 아니면 루트 셀이 열려서 디버깅/고장 분석용으로 전환되는 방식일 수 있다는 추정, 단 이때는 중요한 프라이빗 키가 자동으로 삭제되었기를 바란다는 요청

    • 본인도 루트 셀을 통해 새 키를 플래시해서 재사용이 가능할지 궁금해졌다는 의견, 단말기가 퇴출 예정이면 중고로 얻는 것도 너무 어렵지 않을 것 같다는 기대

  • ‘루트 셀이 열려도 카드 정보가 위험하지 않다’는 원글 인용과 함께, 보안 설계자에겐 꼭 읽어볼 만한 자료라는 추천

    • 단말기에 물리적 접근이 가능하면서 루트 권한까지 있으면 카드 번호 읽기가 불가능하다는 건 전혀 납득이 안 된다는 견해, 보안에서 물리적 접근과 루트 접근은 곧 해킹 성공을 의미한다는 냉정한 현실 인식

  • (훼손된) 리눅스가 “compromised mode” 코드와 mp1 보안 시스템 중 무엇을 읽어올지 결정하는 구조라는 의견, 부트로더 자체가 보안하다고 해도 어떤 환경에서 실제로 실행되는지에 따라 의미가 달라질 수 있다고 지적, co-processor가 Secure Enclave 역할을 할 수 있지만 리눅스가 별도의 부트로더를 올릴 수 있는 구조라면 보안상 심각한 문제가 될 수 있다는 우려

    • 별도 부트로더는 로딩 불가능하다는 반박, 직접 tamper 후 부트로더를 조작해봤지만 정상적으로 부팅되지 않았으며 제3의 boot ROM이 검증하는 구조로 추정, 또한 리눅스는 tamper 상태와 관계없이 loadercode와 mp1.img를 항상 함께 로딩하고, tamper 상태에 따라 (무결성 보호된) loadercode 내부에서 분기하도록 설계되어 있다는 부연

  • 초보라면 최신 안드로이드 기반 신용카드 단말기를 먼저 시도해보라고 추천, 터치스크린으로 핀을 입력하니 더 재미있다는 유혹

    • 터치 컨트롤러는 일반적으로 보안 프로세서가 제어하는 MUX에 연결되어 있고, 보안 정보 입력 시 터치 입력이 곧장 보안 프로세서로 전달되어 안드로이드 계열 운영체제가 관여하지 않는다는 설명

    • 터치패드에 표시되더라도 PIN 데이터는 트러스트 존에서 실행된 펌웨어가 관리하며 암호화 상태라는 사실, 사이에 위치한 앱들은 PIN을 볼 수 없다는 강조

    • 이런 안드로이드 단말기를 해킹해도 보안 설계가 동일하다면 카드 자체에서 복잡한 암호화를 진행해서 실질적으론 쓸 수 있는 정보가 없을 거라는 전망, 이런 공격은 신용카드 리더만 남았을 때나 먹히며, 그런 단말기는 사용자에게 이미 스키머 위험 신호가 될 것이라는 의견

    • 인도에서 쓰이는 안드로이드 단말기는 아직도 Android Oreo(2021년 1월 지원 종료)로 동작한다는 점을 짧게 언급하며 흥미롭게 여기기

  • 단말기 내부 분석을 하자마자 바로 열고 훼손 모드를 트리거하는 것이 의아하다는 반응, 대부분 리더기에 훼손 감지가 있다는 점을 몰랐던 것 아니냐는 추정, 훼손 모드에서 테스트하는 것은 의미가 줄어들 수도 있고, 실제로 훼손 트리거 이후엔 초기화를 위한 셀이 열리는 것 아닐까 하는 궁금증, 마지막으로 굳이 처음부터 열어보는 게 당연한 흐름인지는 다시 한 번 생각해 보라는 조언

    • 처음에는 하드웨어, SoC, 인터페이스, 플래시 등 기본 정보를 파악해야 할 것 같아 열어봤다는 설명, 사전 조사 없이 접근하면 너무 어둠 속에서 시작하는 느낌이라 그랬다는 고백, 돌이켜 생각해보니 디버그 커넥터만 살짝 건드려도 끝났을 수도 있었다는 아쉬움, 그리고 두 번째로 온전한 단말기에서도 셸을 얻는 데 성공했다는 추가

  • ‘철저한 훼손 방지에도 불구하고 우회할 거리와 흥미로운 흔적이 여전히 많이 남아 있다는 점이 놀랍다’는 찬사, 보안 파트는 안전하게 마비되는 게 맞는 설계라고 평가

    • 강화된 프로세서(mp1)는 여전히 침투 불가 상태라는 점을 강조, 실제로는 문자 스트링만 display_tool 바이너리로 전달해 다른 프로세서와 메시지를 주고받는 구조임을 설명, 카드리더나 키패드 등은 리눅스에서 직접 접근 불가하며, 완전히 분리된 mp1 프로세서가 카드·PIN 입력·화면 표시 등 ‘보안’ 처리를 전담, mp2 리눅스는 네트워크·업데이트·비즈니스 로직만 처리한다는 설명

    • 리눅스 쪽이 tamper 이벤트 처리를 감지하는 역할을 할 수도 있지만, tamper 발생을 완전히 탐지한 후에야 보안키를 삭제할 수 있다면 루트 셸을 미리 따 놓고 tamper를 우회하는 흐름도 가능할 수 있어 위험하다는 시나리오 제시

  • 이런 단말기가 유럽 전역에 퍼져 있다는 사실, 스위스는 확실치 않지만 자신이 아는 많은 유럽 지역에서는 신용카드 소지가 드물다고 느낀다는 경험, 대신 POS 단말기는 온갖 종류의 카드를 읽을 수 있어 ‘POS 시스템’이라고 부르는 게 적절하다는 의견, 그래도 게시글은 재미있게 읽었다는 감상

    • 카드 여러 장을 지갑에 들고 다니는 걸 정말 싫어한다는 불평, 이미 여러 이유(결제용 외에도)로 지갑이 터질 지경이라 굳이 휴대폰이나 스마트워치에 더 추가하고 싶지도 않고, 기기 분실 시 개인정보 유출이 너무 치명적이라고 생각, 취향이지만 메카닉 시계를 선호하고, 그런 이유로 카드 간소화 방식을 안 쓴다는 솔직한 고백
답변달기