Kịch bản quét bảo mật SIM bằng SIMTester v2.0.1

Mục tiêu: xác định SIM có tồn tại lỗ hổng kiểu SimJacker/WIBattack, có applet/file lạ tiềm ẩn rủi ro, hay bị lộ lệnh quản trị không cần xác thực hay không.

Áp dụng cho: macOS, đầu đọc PC/SC (ACR38/ACR39/Identiv…), Java 8/11 hoặc bản SIMTester ≥ v2.0.0 (đã fix lỗi Java version check).

Chuẩn bị

mkdir -p .logs
cd ~/SIMTester   # hoặc đường dẫn bạn đang để file SIMTester_v2.0.1.jar

Toàn bộ lệnh dưới đây dùng chung tham số đầu đọc: -tf PCSC -ri 0 (đổi -ri nếu bạn có nhiều đầu đọc).

Bước 0 — Đọc thông tin cơ bản của SIM

java -jar SIMTester_v2.0.1.jar -tf PCSC -ri 0 -la

Output mong đợi (an toàn/bình thường):

• Card connected... state OK
• AUTH: 3G_...9000 → xác thực Milenage 3G thành công, kênh giao tiếp ổn định
• EF_DIR có 1–2 bản ghi AID hợp lệ (USIM, thường kèm ISIM) — không có bản ghi AID lạ/thứ 3 không rõ nguồn gốc

Dấu hiệu cần chú ý: EF_DIR có AID không xác định được nguồn gốc, hoặc AUTH báo lỗi liên tục (khác 9000).

Bước 1 — Fuzzing sơ bộ (Poke)

java -jar SIMTester_v2.0.1.jar -tf PCSC -ri 0 -poke

Output mong đợi:

SIMTester hasn't detected any weaknesses it tests for.

Toàn bộ dòng log fuzz đều dạng no PoR packet even if requested (SW: 0x9000) — nhất quán ở mọi TAR/keyset thử nghiệm.

Dấu hiệu nguy hiểm: xuất hiện dòng cảnh báo kiểu weakness found / critical / có PoR trả về hợp lệ ở keyset không rõ nguồn gốc.

Bước 2 — Fuzzing sâu S@T + WIB (đầy đủ 15 keyset)

java -jar SIMTester_v2.0.1.jar -tf PCSC -ri 0 -t B00001 B00010 -k 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Output mong đợi:

SIMTester hasn't detected any weaknesses it tests for.

(mất khoảng vài phút, tuỳ tốc độ SIM)

Ý nghĩa nếu sạch: nếu S@T (B00010) hoặc WIB (B00001) có tồn tại trên SIM, chúng được bảo vệ đúng chuẩn (yêu cầu chữ ký/mã hoá hợp lệ) — không khai thác được qua SimJacker/WIBattack.

Bước 3 — APDU Scanner Level 1 (qua OTA)

java -jar SIMTester_v2.0.1.jar -tf PCSC -ri 0 -sa | tee .logs/apdu_l1_$(date +%Y%m%d_%H%M%S).log

Output mong đợi: danh sách Valid CLA found: XX, response was: 0x6D00/0x6987/... — đây là các CLA “tồn tại” nhưng không có lệnh nào thực thi thành công không xác thực.

Dấu hiệu nguy hiểm: response_data khác null (có dữ liệu trả về) ở CLA lạ, hoặc SW = 0x9000 (thành công) đi kèm CLA không rõ mục đích.

Bước 4 — APDU Scanner Level 2 (trực tiếp qua đầu đọc)

java -jar SIMTester_v2.0.1.jar -tf PCSC -ri 0 -sa -sal2 2>&1 | tee .logs/apdu_l2_$(date +%Y%m%d_%H%M%S).log

Output mong đợi: phần lớn Valid APDU found đi kèm mã lỗi chuẩn ISO 7816 (6B00 sai tham số, 6700 sai độ dài, 6986/6985 điều kiện chưa thoả, 6982 thiếu xác thực, 6E00 lớp không hỗ trợ). Có thể có đúng 1 dòng 9000 ứng với CLA(80) INS(10) = lệnh TERMINAL PROFILE — đây là lệnh chuẩn, vô hại, không phải lỗ hổng.

Log có thể xen kẽ dòng lỗi:

[ChannelHandler, transmitOnDefaultChannel] SCARD_E_NOT_TRANSACTED, trying to reset the card and retry..

→ Đây là lỗi driver PC/SC, không phải bảo mật — an toàn, có thể bỏ qua, chỉ ảnh hưởng thời gian chạy.

Sau khi chạy xong, upload file CSV APDU_<ICCID>_<timestamp>.csv được SIMTester tự sinh ra, kiểm tra:

• Số dòng 9000 (thành công) nên rất ít (≤ vài dòng, và chỉ với lệnh chuẩn không nhạy cảm như TERMINAL PROFILE)
• Không có dòng nào với response_data chứa dữ liệu ngoài mong đợi

Bước 5 — OTA-Passthrough Fuzzer (kiểm tra header PID/DCS/UDHI)

java -jar SIMTester_v2.0.1.jar -tf PCSC -ri 0 -of

Output mong đợi:

This scan will go over 432 PID, DCS, UDHI, IEI/CPH.
...
done fuzzing OTA passthrough, exiting..

Không có dòng cảnh báo/“found” nào xuất hiện giữa quá trình chạy.

Lưu ý: File CSV OTA_<ICCID>_<timestamp>.csv ở bản v2.0.1 có thể không ghi dữ liệu chi tiết từng dòng (chỉ có header + # msgs: 432) — đây là giới hạn/lỗi ghi log đã biết của bản này, không phải lỗi thao tác. Đánh giá dựa vào log terminal là đủ.

Bước 6 — File Scanner (quét toàn bộ hệ thống file)

java -jar SIMTester_v2.0.1.jar -tf PCSC -ri 0 -sf 2>&1 | tee .logs/filescan_$(date +%Y%m%d_%H%M%S).log

Output/CSV mong đợi: cấu trúc chuẩn gồm MF (3F00), DF_TELECOM (7F10), DF_GSM (7F20), ADF_USIM, ADF_ISIM — đúng chuẩn 3GPP/ETSI.

Bình thường (không phải lỗ hổng): có thể có 1–2 thư mục/file gắn nhãn N/A (mã hex không thuộc chuẩn công khai, ví dụ A515, hoặc file AF2x/AF3x) — đây là dữ liệu độc quyền của nhà mạng, phổ biến, SIMTester không đọc được nội dung bên trong nên không đánh giá được, nhưng sự tồn tại của nó không đồng nghĩa với lỗ hổng.

Dấu hiệu cần chú ý thêm: file có kích thước bất thường lớn, hoặc số lượng thư mục lạ nhiều bất thường so với 1 SIM thương mại tiêu chuẩn.

Bước 7 (tuỳ chọn, nặng) — TAR Full Scan: xác nhận applet có THẬT SỰ tồn tại

Chỉ chạy nếu muốn xác nhận 100% (không bắt buộc để kết luận an toàn — Bước 1+2 đã đủ để kết luận “không khai thác được”):

mkdir -p .logs
nohup java -jar SIMTester_v2.0.1.jar -tf PCSC -ri 0 -st -k 1 \
  > .logs/tar_fullscan_$(date +%Y%m%d_%H%M%S).log 2>&1 &

Theo dõi tiến độ: tail -f .logs/tar_fullscan_*.log — có thể chạy vài giờ đến vài ngày, dừng an toàn bất kỳ lúc nào bằng Ctrl+C hoặc kill.

Bảng tổng hợp tiêu chí “AN TOÀN” vs “CẦN KIỂM TRA THÊM”

Checklist cuối cùng trước khi kết luận “SIM an toàn”

•  Bước 0: đọc SIM thành công, AUTH 9000
•  Bước 1: Poke sạch
•  Bước 2: Fuzz sâu S@T/WIB (15 keyset) sạch
•  Bước 3: APDU Level 1 — không có thực thi lạ
•  Bước 4: APDU Level 2 — chỉ 1 lệnh chuẩn thành công, đã kiểm tra CSV
•  Bước 5: OTA passthrough — không cảnh báo
•  Bước 6: File Scanner — cấu trúc chuẩn
•  (Tuỳ chọn) Bước 7: TAR full scan xác nhận applet thật sự tồn tại hay không

Nếu cả 6 bước bắt buộc đều đạt, SIM được coi là đã vượt qua toàn bộ bài kiểm tra bảo mật khả dụng của SIMTester đối với các lỗ hổng đã biết (SimJacker, WIBattack, lệnh quản trị lộ không xác thực, cấu trúc file bất thường).

Lưu ý an toàn chung

• Không dùng -vp <pin> với PIN sai nhiều lần (rủi ro khoá PIN/PUK thật).
• Không dùng -dp (disable PIN) trên SIM đang dùng hàng ngày.
• Tất cả các lệnh scan/fuzz trong kịch bản này không có cơ chế đếm-khoá, chạy lại nhiều lần không gây hại cho SIM.