4 điểm bởi GN⁺ 2025-06-02 | 1 bình luận | Chia sẻ qua WhatsApp
  • Kết quả tháo rời và phân tích firmware của thiết bị đầu cuối thanh toán Worldline Yomani XR được dùng tại Thụy Sĩ cho thấy có thể vào root shell chỉ bằng cách nhập root tại serial console truy cập được qua nắp nhỏ ở mặt sau
  • Thiết bị có bảo vệ chống can thiệp vật lý để phát hiện việc mở vỏ, ngắt tiếp xúc PCB, cắt các đường mạch zigzag, hư hại flex PCB quanh đầu đọc thẻ, nhưng việc lộ cổng debug đã trở thành một đường tấn công riêng
  • Firmware trích xuất từ flash onboard chứa filesystem không được mã hóa, và chạy dựa trên kernel Linux 3.6, Buildroot 2010.02, BusyBox, uClibc, bootloader tùy biến Booter v1.7
  • Các chức năng bảo mật như thẻ, PIN, màn hình và bàn phím dường như do bộ xử lý riêng mp1 cùng mp1.img đã được mã hóa và ký đảm nhiệm; không có bằng chứng cho thấy có thể truy cập trực tiếp từ Linux mp2
  • Chưa xác định được phiên bản firmware dễ bị ảnh hưởng và cũng có thiết bị đã vô hiệu hóa root login, nhưng trong môi trường mà kẻ tấn công có thể độc chiếm thiết bị trong chốc lát, vẫn còn một bề mặt tấn công lớn không cần thiết

Đối tượng phân tích: Worldline Yomani XR

  • Đối tượng phân tích là thiết bị đầu cuối thanh toán Worldline Yomani XR được dùng rộng rãi tại Thụy Sĩ
  • Sau khi khởi động, việc kiểm tra UI và quét cổng không cho kết quả đáng chú ý, nên nhóm nghiên cứu chuyển sang tháo rời phần cứng
  • Bên trong gồm nhiều PCB
    • Bo mạch nhỏ cho các đầu nối bên ngoài
    • Bo mạch chính
    • Bo mạch đặt dọc có khe cắm thẻ
  • SoC chính có vẻ là một ASIC tùy biến dựa trên Arm dual-core, xuất hiện trong firmware với tên mã “Samoa II
  • Theo tài liệu của Worldline, chip này là ASIC tùy biến chứ không phải chip thương mại được đổi thương hiệu
  • Bên cạnh SoC có flash ngoài nhỏ và RAM

Cấu trúc bảo vệ chống can thiệp phần cứng

  • Không tìm thấy công tắc phát hiện mở vỏ thông thường; thay vào đó chính board-to-board interconnect được dùng làm phương tiện phát hiện mở vỏ
  • Giữa các bo mạch có Zebra strip nhạy với áp lực, nên phải siết chặt bo bằng vít để duy trì tiếp xúc
    • Chỉ cần tháo một số vít cũng có thể làm mất tiếp xúc và gây sự kiện can thiệp
    • Cần phát hiện ngay cả khi đã ngắt nguồn, nên thiết bị dùng pin coin cell
  • Các vùng PCB nhạy cảm được phủ bằng đường mạch phát hiện can thiệp dạng zigzag
    • Nếu xâm nhập vật lý làm đứt chỉ một copper trace, cơ chế phát hiện can thiệp cũng có thể được kích hoạt
  • Khe cắm thẻ nằm trong một vỏ bên trong riêng, và flex PCB bao quanh nó đóng vai trò bảo vệ chống can thiệp
  • Sau khi lắp lại, thiết bị chỉ hiển thị một màn hình đỏ lớn “TAMPER DETECTED”, và trong chế độ này dường như không phản hồi với đầu vào bên ngoài

Trích xuất flash và khôi phục filesystem

  • Khi việc thăm dò lúc runtime bị chặn, nhóm nghiên cứu tháo chip flash onboard và nối dây để dump nội dung
  • Trái với dự đoán, nội dung dump nhìn chung không được mã hóa
  • Flash sử dụng cách bố trí ECC không phổ biến
    • Không phải cấu hình chuẩn 2048 byte payload + 64 byte ECC/spare
    • Cấu trúc gồm 3 chunk dữ liệu 694 byte, sau mỗi chunk có 10 byte ECC
    • 16 byte cuối của spare area có vẻ là metadata của filesystem YAFFS2
  • Vì vùng metadata nhỏ hơn YAFFS2 thông thường, cần patch filesystem để xử lý cấu trúc metadata nhỏ hơn
  • Sau khi triển khai reader filesystem tương thích, nhóm nghiên cứu đã trích xuất thành công nội dung filesystem

Hệ thống dựa trên Linux cũ

  • Filesystem trích xuất xác nhận thiết bị chạy Linux
  • Hệ thống chứa các thành phần cũ
    • Linux kernel 3.6
    • Buildroot 2010.02
    • Bản build tháng 2 năm 2023
    • Bootloader tùy biến Booter v1.7
    • init script, BusyBox, uClibc
    • libcrypt 0.9.26
  • Chưa xác định firmware dump được mới đến mức nào, nhưng nó phải là firmware phát hành sau tháng 2 năm 2023

Root shell không cần mật khẩu

  • Khi nối lại chip flash bằng dây, thiết bị khởi động lại dù vẫn hiển thị thông báo can thiệp
  • Để xem Linux boot log, nhóm nghiên cứu dùng logic analyzer kiểm tra quanh debug connector và phát hiện hoạt động ở một pad của debug connector chưa gắn linh kiện
  • Serial console hiển thị login prompt cùng với Linux boot log
    • Boot log có dòng “Reset reason: Tamper”
    • Cũng xuất hiện các log như dropbear is not present, kiểm tra cập nhật firmware, khởi động application monitoring daemon
    • Cuối cùng hiển thị prompt samoa login:
  • Khi nhập root làm login, shell prompt ~ # xuất hiện mà không cần mật khẩu
  • Cách truy cập này không cần exploit chain hay brute-force password cracking

Cổng debug có thể truy cập từ bên ngoài

  • Truy cập root shell không chỉ giới hạn trong trường hợp mở bên trong thiết bị
  • serial port có thể được truy cập từ bên ngoài qua một nắp nhỏ ở mặt sau thiết bị
  • Có thể kết nối vào debug connector mà không cần mở thiết bị và kích hoạt bảo vệ chống can thiệp
  • Nhóm nghiên cứu cho rằng nếu có thể độc chiếm thiết bị trong chốc lát, kịch bản kết nối vào cổng serial, đăng nhập, đặt malware rồi rời đi là khả thi

Tách biệt vai trò giữa bộ xử lý bảo mật và Linux

  • Root shell bị lộ không đồng nghĩa ngay với việc có thể truy cập dữ liệu thẻ hoặc PIN
  • Hệ thống Linux chỉ là một phần của kiến trúc tổng thể, và không tìm thấy bằng chứng cho thấy có thể truy cập trực tiếp từ Linux tới màn hình, bàn phím hoặc đầu đọc thẻ
  • Việc xuất màn hình dường như cũng không do framebuffer driver xử lý trực tiếp, mà theo cách chuyển chuỗi cho binary display_tool, rồi binary này gửi inter-processor message
  • Các chức năng liên quan đến bảo mật như thẻ, nhập PIN và hiển thị màn hình có vẻ do bộ xử lý riêng mp1 xử lý
  • Linux chạy trên bộ xử lý thứ hai mp2 đảm nhiệm networking, update và business logic

Luồng khởi động và image bảo mật

  • Linux core dường như luôn khởi động bất kể trạng thái can thiệp
  • Sau đó Linux nạp secure bootloader loadercode vào bộ nhớ
  • loadercode kiểm tra xem bảo vệ chống can thiệp đã bị kích hoạt hay chưa
    • Nếu phát hiện can thiệp, nó hiển thị màn hình đỏ
    • Nếu không có vấn đề, nó khởi động secure image thực sự là mp1.img
  • mp1.img nằm trong filesystem Linux, nhưng có vẻ đã được mã hóa và ký bởi hai entity
  • Secure image xử lý thẻ, màn hình và bàn phím đã được mã hóa và ký đúng cách

Lịch công bố và các điểm chưa chắc chắn còn lại

  • Lịch công bố được ghi nhận như sau
    • 14/11/2024: phát hiện root shell
    • 15/11/2024: báo cáo cho nhà sản xuất và thông báo dự kiến công bố sau 90 ngày
    • 18/11/2024: nhà sản xuất xác nhận đã nhận báo cáo
    • 01/06/2025: công bố
  • Root shell bị lộ là một bề mặt tấn công lớn không cần thiết, nhưng chưa tìm thấy bằng chứng cho thấy dữ liệu nhạy cảm như thông tin thẻ có thể bị xâm phạm qua đường này
  • Chưa xác định được phiên bản firmware nào dễ bị ảnh hưởng
  • Trong quá trình nghiên cứu cũng phát hiện có thiết bị đã vô hiệu hóa root login
  • Chưa xác định được debug feature đã đi vào production firmware tại thời điểm nào, hay liệu nhà sản xuất đã phát hiện và sửa nó nội bộ từ trước hay chưa

1 bình luận

 
GN⁺ 2025-06-02
Các ý kiến trên Hacker News
  • Có thể tạo giao dịch thẻ ghi nợ/tín dụng giả bằng đầu đọc thẻ USB giá 2 đô la
    Toàn bộ đặc tả đều công khai và giao thức cũng được tài liệu hóa. Theo tôi nhớ thì file PDF khoảng 5.000 trang, đọc cực kỳ khổ sở
    Nhưng để xác minh giao dịch đó thì phải gửi qua Internet tới ngân hàng, và khi đó các cơ quan liên bang/FBI kiểu vậy có thể sẽ tìm đến
    Bản thân đầu đọc thẻ gần như không có cơ chế bảo vệ thật sự; đa phần chỉ là một Linux nhỏ dùng mật khẩu tệ hại. Sự bảo vệ đến từ hợp đồng và quy định giữa cửa hàng và ngân hàng

    • Nói đầu đọc thẻ không có bảo vệ là không đúng. Chỉ binary đã được ký mới được chạy, filesystem chứa file thực thi là chỉ đọc, còn filesystem dữ liệu được đặt noexec
      Đăng nhập root bị vô hiệu hóa, dùng busybox đã bị cắt bỏ nhiều chức năng, khóa được nạp từ vùng bảo mật khi khởi động. Việc nạp master key chỉ có thể thực hiện lúc load tại nhà máy, bản thân quá trình boot cũng an toàn ở một mức độ nào đó, và nếu phát hiện bị can thiệp thì chip sẽ bị xóa
      Tất nhiên nếu đó là loại terminal Android giá rẻ, chưa được chứng nhận EMV, nhập từ châu Á, thì rất có khả năng nó dùng Linux tiêu chuẩn với root filesystem đọc/ghi được, bật đăng nhập root, thậm chí bật sudo cho user chạy ứng dụng. Có thể cũng không có phát hiện can thiệp, screen casting không bị khóa, port có thể mở, và busybox gần như còn nguyên vẹn
      Với tư cách người đã phát triển ứng dụng EMV cho nghiệp vụ acquiring thẻ trong vài năm và giờ vẫn thỉnh thoảng làm, tôi thấy ngay cả chế độ phát triển cũng cần vendor cấp developer ID và bị khóa khá chặt
    • Phần nói hợp đồng và quy định giữa cửa hàng và ngân hàng là cốt lõi của bảo vệ thì chính xác
      Vì vậy các thuyết âm mưu kiểu mang đầu đọc thẻ di động đi khắp nơi để lấy cắp tiền từ thẻ contactless cũng sai. Bản thân giao dịch kiểu đó có thể tạo được, nhưng vấn đề là những gì xảy ra sau đó và các thiết lập cần có từ trước
      Cũng không chắc có thể rút được tiền trước khi bị bắt và bị chặn. Ngày nay nhiều người bật thông báo push cho giao dịch, nên tôi nghĩ càng khó hơn
    • Điều đó không đúng. Terminal của merchant có tích hợp phần cứng bảo mật để lưu khóa của ngân hàng và mạng thẻ
      Nếu các khóa đó bị lộ, ai đó có thể giả mạo giao dịch hợp lệ
    • Tôi lo hơn về khả năng đầu đọc thẻ tại hiện trường bị xâm nhập rồi thông tin thẻ thật đã được cache hoặc lưu trữ bị đọc ra, hoặc malware kiểu chặn bắt được cài vào
      Trong trường hợp cụ thể này thì có vẻ khó hoặc bất khả thi, nhưng đó là lý do nghiên cứu trong lĩnh vực này vẫn có ý nghĩa
    • Có thể giải thích kỹ hơn một chút về đoạn “có thể tạo giao dịch thẻ ghi nợ/tín dụng giả bằng đầu đọc thẻ USB giá 2 đô la” không? Ý tôi không phải là “hãy dạy tôi cách làm”
  • Tôi không biết phải xem gì, nhưng từng bị cám dỗ muốn mở một chiếc đầu đọc Stripe M2 mà tôi có ra để xem bên trong
    Vấn đề là trong 36 đầu đọc đã mua, có 7 chiếc “chết”. 2 chiếc không giữ được sạc, 1 chiếc không quét được NFC, và 4 chiếc hiển thị “tampered”. Nhìn bề ngoài thì tỷ lệ hỏng đã tệ, nhưng phải xét cả tần suất sử dụng và tuổi đời mới thấy toàn cảnh
    Nhưng câu trả lời còn tệ hơn. Thiết bị đã 1–3 năm tuổi, tổng số ngày sử dụng tối đa chỉ 9 ngày. Tức là sau tổng cộng 9 ngày sử dụng, 7 trong 36 chiếc đã hỏng theo cách nào đó. Khi di chuyển, tất cả đều được cất trong hộp hard-shell có foam insert, mỗi đầu đọc có một khe riêng
    Vì vậy tôi không đặc biệt thích đầu đọc M2, nhưng hiện nó vẫn là lựa chọn tốt nhất của tôi
    [0] Bổ sung bối cảnh: công ty chúng tôi xử lý thanh toán cho các lễ hội. Chúng tôi di chuyển đến địa điểm sự kiện, xử lý thanh toán trực tiếp bằng iPad và đầu đọc M2, còn phần lớn thanh toán diễn ra trên web/app. Vì thế trong 3 năm, số “ngày sử dụng” lại ít như vậy

    • Trước khi cất để chờ sự kiện tiếp theo, tốt nhất nên sạc chúng. Phần lớn pin không thích bị lưu kho lâu trong trạng thái sạc thấp
      Và rất có khả năng cơ chế phát hiện can thiệp cũng cần pin hoạt động bình thường
  • Cũng có thể cấu trúc là khi seal chống can thiệp bị kích hoạt thì root shell được mở
    Tức là hệ thống hoặc ở chế độ bảo mật có các khóa mã hóa cần thiết để vận hành, hoặc ở chế độ không bảo mật với root shell mở để debug và phân tích lỗi, nhưng trong quá trình chuyển đổi đó các private key quan trọng bị xóa

    • Tôi cũng đoán vậy. Có lẽ còn có thể flash khóa mới để làm thiết bị dùng lại được
      Tôi bắt đầu tò mò liệu có thể kiếm được một terminal thật không. Nếu chúng đang bị thay thế và biến mất dần, có lẽ tìm hàng cũ cũng không quá khó
  • Bổ sung cho những người dễ phấn khích: có đoạn nói rằng “root shell bị lộ có vẻ không phải rủi ro lớn như lo ngại ban đầu. Chúng tôi không tìm thấy bằng chứng cho thấy dữ liệu nhạy cảm như thông tin thẻ có thể bị xâm phạm theo cách này”
    Dù vậy, đây vẫn là bài đáng đọc với nhà thiết kế bảo mật

    • Việc có quyền truy cập vật lý vào terminal và thậm chí lấy được quyền root mà vẫn không đọc được số thẻ tín dụng nghe rất đáng nghi
      Trong bảo mật, truy cập vật lý — và ở mức độ thấp hơn là truy cập root — gần như tương đương với hack thành công
  • Nếu Linux đã bị xâm nhập là thứ quyết định sẽ nạp code “chế độ bị xâm nhập” hay hệ thống bảo mật mp1, thì đây có vẻ là một hướng đáng khám phá
    Bootloader tự thân được nói là an toàn, nhưng nếu tùy vị trí thực thi mà nó được nạp vào trong môi trường đã bị xâm nhập thì có thể không có nhiều ý nghĩa
    Có thể xem coprocessor như một dạng Secure Enclave, nhưng việc Linux có thể nạp và chạy một bootloader riêng là điều đáng lo

    • Không thể nạp bootloader riêng. Tôi đã thử chỉnh sửa bootloader “bảo mật” có tên loadercode, nhưng nó không boot
      Vì vậy tôi đoán một bên thứ ba, có lẽ là boot ROM, đang xác minh nó
      Ngoài ra, Linux dường như luôn nạp loadercodemp1.img bất kể trạng thái can thiệp. Code path khác nhau tùy trạng thái can thiệp có vẻ được chọn bên trong loadercode, vốn được bảo vệ tính toàn vẹn
  • Nếu muốn chế độ dễ, cứ nhìn vào các máy thanh toán thẻ chạy Android hiện nay là được
    Đặc biệt vì người dùng nhập PIN trực tiếp trên màn hình, nên khả năng sẽ “đáng công” hơn nhiều

    • Bộ điều khiển cảm ứng thường được nối với một bộ ghép kênh do bộ xử lý bảo mật điều khiển
      Khi nhập dữ liệu nhạy cảm như PIN hay PAN, đầu ra của bộ điều khiển cảm ứng được định tuyến trực tiếp tới bộ xử lý bảo mật, bỏ qua hệ điều hành dòng Android phụ trách GUI
    • Dữ liệu PIN, ngay cả khi hiển thị trên bàn phím cảm ứng, vẫn được mã hóa và sử dụng giao diện người dùng do firmware chạy trong vùng tin cậy kiểm soát
      Vì vậy các ứng dụng trung gian có thể tiếp cận trong kiểu tấn công này không thể thấy PIN
    • Làm như vậy có lẽ sẽ lấy được PIN khá dễ, nhưng nếu các phần quan trọng được thiết kế theo cùng cách để chuyển sang bộ đồng xử lý bảo mật, thì vẫn không làm được nhiều với thẻ
      Thẻ hiện đại thực hiện nhiều phép toán mật mã ngay bên trong thẻ để ngăn kiểu tấn công này
      Cuộc tấn công này có lẽ chỉ hiệu quả trên thiết bị đầu cuối mà trong các tùy chọn thanh toán chỉ còn đầu đọc thẻ từ hoạt động; với những thiết bị như vậy thì đèn cảnh báo skimmer đáng ra phải bật lên từ trước khi thấy lời nhắc nhập PIN
    • Không rõ từng khu vực dùng thiết bị Android nào, nhưng ở Ấn Độ thì có vẻ chúng chạy Android Oreo. Hỗ trợ đã kết thúc vào tháng 1 năm 2021
  • Tuyệt vời. Tôi thích nghĩ về cách vượt qua và khai thác những hạn chế phần cứng như chống can thiệp trên diện rộng này, nhưng trước giờ vẫn cho rằng một khi nó kích hoạt thì coi như hết
    Nhưng hóa ra không hẳn vậy, vẫn còn rất nhiều phần thú vị đáng để soi tiếp. Dù vậy, việc phần bảo mật bị vô hiệu hóa đúng nghĩa là điều đương nhiên. Nếu không thì tôi đã mất hết niềm tin vào người thiết kế

    • Với bộ xử lý được gia cố thì điều đó có thể vẫn đúng. Bài gốc cũng viết rằng đây không phải là phần bị xâm phạm
      Có vẻ chỉ các chuỗi văn bản được truyền cho một binary tên là display_tool, rồi binary đó gửi thông điệp liên bộ xử lý. Bàn phím và đầu đọc thẻ cũng tương tự. Tôi không tìm thấy bằng chứng cho thấy các thiết bị ngoại vi này có thể được truy cập trực tiếp từ Linux
      Thay vào đó, có vẻ một bộ xử lý hoàn toàn riêng biệt gọi là mp1 phụ trách các tác vụ “bảo mật” như xử lý thẻ, nhập PIN và hiển thị thông tin trên màn hình. Linux “không bảo mật” chạy trên bộ xử lý thứ hai mp2 chỉ xử lý mạng, cập nhật và logic nghiệp vụ
    • Chỉ đọc phần mô tả thì cũng có vẻ phía Linux có thể đóng vai trò nào đó trong việc xử lý sự kiện can thiệp
      Dù vậy, hy vọng kiến trúc chỉ cho phép nó thấy rằng đã xảy ra can thiệp. Nếu không, sau khi lấy được root shell trước, có thể sẽ có cơ hội ngăn sự kiện can thiệp xóa khóa bảo mật
  • Đọc về mọi cơ chế phát hiện can thiệp của thiết bị khiến tôi tự hỏi cách dễ nhất để kích hoạt chế độ can thiệp là gì
    Rốt cuộc, nếu chỉ cần làm vậy với vài thiết bị, thì với một cửa hàng mà phần lớn hoặc toàn bộ thanh toán đi qua các máy này, đó có thể trở thành một cuộc tấn công từ chối dịch vụ hiệu quả

    • Làm rơi xuống sàn hoặc đổ nước lên
  • Việc soi những thiết bị như thế này rất thú vị, nhưng tôi không hiểu vì sao lại mở ngay ra để kích hoạt trạng thái can thiệp. Chẳng lẽ họ không biết hầu hết đầu đọc đều có cơ chế như vậy sao?
    Các thử nghiệm thực tế trong trạng thái can thiệp có thể không còn ý nghĩa. Cũng có khả năng thiết kế là khi vào trạng thái can thiệp để khởi tạo thì shell sẽ mở
    Nhìn thì có vẻ việc mở thiết bị nên là điều thử sau cùng

    • Trước tiên tôi cảm thấy cần nắm được mình đang xử lý cái gì: phần cứng, SoC nào, các giao diện, flash, những thứ như vậy
      Nếu không thì quá mù mờ. Tất nhiên nhìn lại thì có lẽ chỉ cần chạm vào đầu nối debug là xong
      Và tôi cũng lấy được shell trên thiết bị thứ hai chưa bị can thiệp
  • Những thiết bị này có mặt khắp châu Âu. Tôi không rõ Thụy Sĩ thế nào, nhưng ở khá nhiều vùng châu Âu mà tôi biết, người ta không thực sự sở hữu hoặc dùng thẻ tín dụng nhiều
    Tôi sẽ gọi chúng là POS, tức hệ thống điểm bán hàng. Những thiết bị này có thể đọc đủ loại thẻ. Dù sao thì bài viết hay

    • Thực ra là dùng nhiều. Tôi ghét phải mang theo đống thẻ trong ví. Vì nhiều lý do tôi đã có đầy thẻ không dùng để thanh toán rồi, nên chẳng còn chỗ để nhét thêm thứ như thẻ ghi nợ
      Tôi cũng không thấy hấp dẫn ở việc nhét thêm nhiều thứ vào điện thoại hay smartwatch. Tôi thích đồng hồ cơ, và nếu mất điện thoại thì về mặt riêng tư đã đủ là thảm họa rồi. Tất nhiên đó là trường hợp của tôi