Buổi 11: Các Hướng Tương Lai của Bảo Mật và Khai Thác Lỗ Hổng Phần Mềm

1. Thực Trạng An Toàn Phần Mềm

1.1 Số liệu CVE qua các năm

Số lượng lỗ hổng được công bố (CVE – Common Vulnerabilities and Exposures) tăng đột biến trong thập kỷ qua:

NămSố CVE
1999894
20054.935
20104.653
201714.714
201917.344
202120.171
202222.671
xychart-beta title "CVE theo năm" x-axis [1999, 2005, 2010, 2015, 2017, 2019, 2021, 2022] y-axis "Số lượng CVE" 0 --> 25000 bar [894, 4935, 4653, 6504, 14714, 17344, 20171, 22671]

1.2 Tại sao phần mềm không bao giờ hoàn toàn an toàn?

1.3 Hai xu hướng đối lập trong tương lai

graph LR A[Lỗ hổng phần mềm] --> B[Memory Corruption\ne.g. Buffer Overflow, UAF] A --> C[Logic / Implementation Flaw\ne.g. auth bypass, race condition] B --> D["Ngày càng KHÓ khai thác\n(OS protections: ASLR, DEP, CFI, Stack Canary)"] C --> E["Luôn tồn tại\nKhó tự động phát hiện"]

2. Các Hướng Nghiên Cứu Tương Lai – An Toàn Phần Mềm

2.1 Kỹ Thuật Làm Rối (Obfuscation)

Obfuscation là kỹ thuật biến đổi mã nguồn hoặc mã nhị phân thành dạng khó đọc, khó phân tích mà vẫn giữ nguyên hành vi chức năng của chương trình.

Mục tiêu:

  • Bảo vệ tài sản trí tuệ (IP protection)
  • Chống lại kỹ nghệ đảo ngược (reverse engineering)
  • Cản trở phân tích malware

Các kỹ thuật phổ biến:

Kỹ thuậtMô tả
RenamingĐổi tên biến/hàm thành tên vô nghĩa
Control Flow FlatteningBiến cấu trúc điều khiển tuần tự thành state machine
Instruction SubstitutionThay lệnh đơn giản bằng chuỗi lệnh tương đương phức tạp hơn
Dead Code InsertionChèn mã không có tác dụng để gây nhiễu
Opaque PredicatesChèn điều kiện rẽ nhánh mà kết quả đã biết trước (true/false) nhưng khó phân tích tĩnh
String EncryptionMã hóa chuỗi ký tự và giải mã tại runtime
# Trước obfuscation
def calculate_price(quantity, unit_price):
    discount = 0.1 if quantity > 100 else 0
    return quantity * unit_price * (1 - discount)

# Sau obfuscation (minh họa đơn giản)
def x9f2(a3k, b7m):
    _v = (lambda q: 0.1 if q > 100 else 0)(a3k)
    return a3k * b7m * (1 - _v)

2.2 Phát Hiện Tương Đồng Mã (Code Similarity Detection / BCSD)

Binary Code Similarity Detection (BCSD) là bài toán so sánh các đoạn mã nhị phân để phát hiện:

  • Clone detection: Tìm mã nguồn/nhị phân bị sao chép (vi phạm license)
  • Vulnerability propagation: Một lỗ hổng trong thư viện X có xuất hiện trong firmware Y không?
  • Malware analysis: Phần này của malware có tương đồng với mã độc đã biết không?

Thách thức:

graph TD A[Source Code] -->|Compiler A, OS1, Arch1| B[Binary 1] A -->|Compiler B, OS2, Arch2| C[Binary 2] B --> D{So sánh\nngữ nghĩa} C --> D D --> E[Khó vì:\nKhác instruction set\nKhác calling convention\nKhác optimization level]

Các phương pháp tiêu biểu:

Công cụ / PaperPhương phápĐặc điểm
BinDeepDeep Learning trên CFGCross-platform
CodeeTensor EmbeddingBinary code search
JTransJump-aware TransformerXử lý control flow
AsteriaAST Encoding + Deep LearningCross-platform BCSD

3. Các Hướng Nghiên Cứu Tương Lai – Khai Thác Lỗ Hổng

3.1 Tự Động Hóa Tìm Bug (Automated Bug Hunting)

Vấn đề cốt lõi: Tìm lỗ hổng là quá trình tốn nhiều thời gian – hàng giờ, ngày, tuần, thậm chí tháng. Giải pháp là tự động hóa.

flowchart LR A[Bug Hunting] --> B[White-box\nCó mã nguồn] A --> C[Black-box\nKhông có mã nguồn] B --> D[Static Analysis\nFuzzing có hướng dẫn] C --> E[Fuzzing\nDynamic Analysis] D --> F[Tự Động Hóa] E --> F

3.2 Phân Tích Tĩnh – Static Code Analyzer

Phân tích tĩnh (Static Analysis) kiểm tra mã nguồn mà không thực thi chương trình.

Ưu điểm:

  • Phát hiện lỗi sớm (early detection) trong SDLC
  • Bao phủ 100% code paths về lý thuyết
  • Không cần môi trường thực thi

Nhược điểm:

  • False positives cao: cảnh báo sai nhiều
  • False negatives: Bỏ lỡ nhiều lỗ hổng phức tạp
  • Rất khó phát hiện UAF (Use-After-Free) và các lỗi liên quan đến trạng thái runtime

3.3 Fuzzing – Kỹ Thuật Kiểm Thử Ngẫu Nhiên Có Hướng Dẫn

Fuzzing là kỹ thuật tự động sinh ra dữ liệu đầu vào bất thường/ngẫu nhiên và đẩy vào chương trình để quan sát hành vi – đặc biệt là khiến chương trình crash (gặp lỗi không kiểm soát được).

Phân loại Fuzzing:

graph TD F[Fuzzing] --> G[Black-box Fuzzing\nKhông biết cấu trúc nội bộ] F --> H[Grey-box Fuzzing\nDùng coverage feedback] F --> I[White-box Fuzzing\nSymbolic Execution + SMT] H --> J[AFL, LibFuzzer, HonggFuzz] I --> K[KLEE, angr, Triton]

Các bước cơ bản của Fuzzing:

1. Chuẩn bị corpus (tập dữ liệu đầu vào ban đầu)
2. Mutation: Biến đổi ngẫu nhiên dữ liệu (bit flip, byte flip, splice...)
3. Thực thi chương trình với dữ liệu biến đổi
4. Quan sát: Crash? Hang? Coverage tăng?
5. Nếu crash → lưu test case → phân tích lỗ hổng
6. Nếu coverage tăng → ưu tiên mutate tiếp từ input này
7. Lặp lại vòng lặp

3.4 American Fuzzy Lop (AFL) – Fuzzer Huyền Thoại

AFL là một coverage-guided fuzzer mã nguồn mở, được phát triển bởi Michał Zalewski (Google), nổi tiếng vì đã tìm ra hàng nghìn lỗ hổng nghiêm trọng trong thực tế.

Cơ chế hoạt động:

sequenceDiagram participant A as AFL Engine participant B as Instrumented Binary participant C as Coverage Map A->>B: Gửi mutated input B->>C: Ghi coverage (basic block transitions) C->>A: Phản hồi coverage mới? A->>A: Nếu coverage mới → thêm vào queue A->>A: Chọn input từ queue → mutate tiếp B-->>A: Crash signal (SIGSEGV, SIGABRT...) A->>A: Lưu crash case

Các kỹ thuật mutation của AFL:

Kỹ thuậtMô tả
Bit flipsLật từng bit hoặc nhóm bit
Byte flipsLật từng byte hoặc nhóm byte
ArithmeticsCộng/trừ các giá trị số học nhỏ
Known intsThay bằng các giá trị đặc biệt (0, -1, INT_MAX…)
HavocKết hợp ngẫu nhiên nhiều đột biến
SpliceGhép 2 test case khác nhau

Minh họa output của AFL:

american fuzzy lop - process timing
  run time    : 0 days, 0 hrs, 8 min, 24 sec
  cycles done : 0
  last new path: 0 days, 0 hrs, 1 min, 59 sec

overall results
  total paths  : 812
  uniq crashes : 8          ← 8 crash patterns duy nhất
  uniq hangs   : 10

map coverage
  map density  : 3158 (4.82%)   ← % edge coverage
  count coverage: 2.56 bits/tuple

fuzzing strategy yields
  bit flips    : 447/75.5k
  byte flips   : 7/9436
  arithmetics  : 0/0
  havoc        : 0/0

3.5 Đặc Điểm Bug Hiện Đại

Khi các cơ chế phòng thủ ngày càng mạnh, các bug tồn tại trong phần mềm ngày càng có tính chọn lọc và điều kiện kích hoạt phức tạp:

  • Bug chỉ xuất hiện khi một chuỗi điều kiện rất đặc biệt (very specific condition) được thỏa mãn đồng thời
  • Fuzzing truyền thống (ngẫu nhiên) khó có thể “vô tình” tạo ra đúng chuỗi điều kiện đó
  • Cần các kỹ thuật tự hướng dẫn (guided) thông minh hơn

3.6 QIRA – Timeless Debugger

QIRA (QEMU Interactive Runtime Analyser) là một “timeless debugger” – cho phép quan sát và duyệt qua lịch sử thực thi của chương trình.

Tính năng nổi bật:

  • Xem trạng thái chương trình tại bất kỳ thời điểm nào trong quá khứ
  • Di chuyển forward và backward theo timeline thực thi
  • Không cần đặt breakpoint trước – ghi lại toàn bộ execution trace
  • Rất hữu ích khi phân tích crash hoặc hành vi phức tạp

3.7 Các Kỹ Thuật Nâng Cao

3.7.1 Taint Analysis

Taint Analysis (phân tích vết bẩn) là kỹ thuật theo dõi luồng dữ liệu từ nguồn không tin cậy (user input) qua các phép biến đổi cho đến khi dữ liệu đó ảnh hưởng đến hành vi nguy hiểm (sink).

flowchart LR I["Input\n(tainted)"] --> P1[strcpy] --> V["buffer[256]\n(tainted)"] V --> P2[memcpy] --> D["dest\n(tainted)"] D --> CRASH["💥 Buffer Overflow!"] style I fill:#ff6b6b style V fill:#ff6b6b style D fill:#ff6b6b style CRASH fill:#cc0000,color:#fff

Phân loại:

  • Static Taint Analysis: Phân tích tĩnh, không cần thực thi (nhanh, nhiều false positive)
  • Dynamic Taint Analysis: Theo dõi tại runtime (chính xác hơn, overhead cao)

Công cụ: PANDA (Platform for Architecture-Neutral Dynamic Analysis), QIRA, Triton, angr

3.7.2 Symbolic Execution + SAT/SMT Solving

Symbolic Execution thực thi chương trình với các giá trị tượng trưng (symbolic values) thay vì giá trị cụ thể, nhằm:

  • Khám phá tất cả các nhánh thực thi
  • Tự động sinh điều kiện đầu vào để đạt tới một điểm cụ thể trong code
# Ví dụ minh họa Symbolic Execution
def vulnerable(x):          # x là symbolic
    if x > 100:             # tạo 2 path: x > 100 và x <= 100
        if x < 200:         # path con: 100 < x < 200
            crash()         # SMT solver tìm x thỏa mãn: x > 100 AND x < 200
                            # Ví dụ: x = 150

SMT Solver (Satisfiability Modulo Theories):

  • Nhận các ràng buộc (constraints) từ symbolic execution
  • Tìm giá trị cụ thể thỏa mãn các ràng buộc đó
  • Công cụ phổ biến: Z3 (Microsoft), CVC4, Boolector

3.7.3 Machine Learning trong Bug Hunting

Học máy được áp dụng để:

  • Tự động phân loại crash (là lỗ hổng bảo mật hay chỉ là bug thường?)
  • Hướng dẫn fuzzer: Ưu tiên mutation theo hướng “thú vị” hơn
  • Phát hiện lỗ hổng từ mã nguồn/nhị phân qua mô hình NLP
  • Sinh exploit tự động

4. DARPA Cyber Grand Challenge (CGC) và Tương Lai Tự Động Hóa

4.1 Tầm Nhìn của CGC

DARPA Cyber Grand Challenge là cuộc thi năm 2016, với mục tiêu phát triển hệ thống hoàn toàn tự động có khả năng:

graph TD CGC[Cyber Grand Challenge] --> A["🔍 Tìm kiếm lỗ hổng\n(White-box & Black-box)"] CGC --> B["🔧 Vá (Patch) lỗ hổng\ntự động"] CGC --> C["💣 Viết mã khai thác\n(exploit) tự động"] A --> D[Cyber Reasoning System - CRS] B --> D C --> D

4.2 Mayhem CRS – Hệ Thống Lý Luận Không Gian Mạng

Mayhem (phát triển bởi ForAllSecure, đội gồm các nhà nghiên cứu từ CMU) đã giành chiến thắng CGC 2016.

Kiến trúc của Mayhem:

flowchart TD INPUT[Binary Program] --> FZ[Smart Fuzzer\nCoverage-guided] INPUT --> SE[Symbolic Execution\nPath exploration] FZ --> TA[Taint Analysis\nData flow tracking] SE --> CS[Constraint Solver\nZ3 / SMT] TA --> CS CS --> BUG{Bug Found?} BUG -->|Yes| EXPLOIT[Exploit Generation] BUG -->|Yes| PATCH[Patch Generation] BUG -->|No| FZ ML[Machine Learning\nGuide prioritization] --> FZ ML --> SE

Kỹ thuật cốt lõi:

Thành phầnVai trò
Smart FuzzingSinh đầu vào tự động, hướng dẫn bởi coverage
Taint AnalysisXác định dữ liệu đầu vào ảnh hưởng tới điểm nào
Constraint SolverTìm đầu vào để kích hoạt điều kiện lỗ hổng
MLƯu tiên hóa các đường khám phá có tiềm năng

4.3 MATE – Merged Analysis To Prevent Exploits

MATE là dự án tiếp nối, được Galois phát triển cùng Harvard University và Trail of Bits trong chương trình DARPA CHESS (Computers and Humans Exploring Software Security).

Triết lý MATE: Human-Machine Hybrid

Pipeline của MATE:

flowchart LR SRC["C/C++ Source"] --> CPG["Code Property Graph\nStore"] BIN["Compiled Binary"] --> SA["Static Analysis"] SA --> CPG CPG --> SE["Directed\nSymbolic Execution"] CPG --> IF["Information Flow\nAnalysis"] SE --> VD["Vulnerability\nDetection"] IF --> VD VD --> EA["Exploitability\nAnalyzer"] EA --> POV["Proof of Vulnerability\n(PoV)"] POV --> PATCH["Patching"] HUMAN["Human Insight"] -.->|"Refinement"| VD DYN["Dynamic Analysis\nProtocol Mining"] --> CPG

5. Các Chủ Đề Nghiên Cứu Tại InSecLab (UIT)

📝 50 Câu Trắc Nghiệm

Câu 1. Theo thống kê CVE, xu hướng số lượng lỗ hổng được công bố qua các năm là gì?

  • A. Giảm dần do công nghệ bảo mật tiến bộ
  • B. Ổn định, dao động quanh mức 5000/năm
  • C. Tăng mạnh qua các năm, đặc biệt từ 2017 trở đi
  • D. Tăng đến 2015 rồi giảm

Câu 2. Tại sao các khai thác dựa trên Memory Corruption sẽ ngày càng khó thực hiện?

  • A. Vì lập trình viên đã học cách tránh lỗi bộ nhớ
  • B. Vì các hệ điều hành hiện đại triển khai nhiều cơ chế bảo vệ (ASLR, DEP, CFI…)
  • C. Vì antivirus hiện đại phát hiện 100% các exploit
  • D. Vì không còn lỗ hổng bộ nhớ nào tồn tại

Câu 3. Loại lỗ hổng nào được dự đoán sẽ “luôn tồn tại” trong tương lai dù bảo mật tiến bộ?

  • A. Buffer Overflow
  • B. Use-After-Free
  • C. Logic / Implementation Flaw
  • D. Format String Vulnerability

Câu 4. Obfuscation trong bảo mật phần mềm có mục đích chính là gì?

  • A. Tăng tốc độ thực thi của chương trình
  • B. Làm cho mã nguồn/nhị phân khó phân tích và reverse engineer hơn
  • C. Giảm kích thước file thực thi
  • D. Mã hóa dữ liệu người dùng

Câu 5. Kỹ thuật obfuscation “Control Flow Flattening” hoạt động theo cơ chế nào?

  • A. Đổi tên tất cả biến và hàm thành tên vô nghĩa
  • B. Biến cấu trúc điều khiển tuần tự thành một state machine phẳng
  • C. Chèn code chết (dead code) vào chương trình
  • D. Mã hóa tất cả chuỗi ký tự

Câu 6. “Opaque Predicates” trong obfuscation là gì?

  • A. Các hàm mã hóa ẩn
  • B. Điều kiện rẽ nhánh có kết quả luôn đúng/sai nhưng khó phân tích tĩnh
  • C. Các biến không được khởi tạo
  • D. Lệnh nhảy không điều kiện

Câu 7. Binary Code Similarity Detection (BCSD) được ứng dụng trong bảo mật để làm gì?

  • A. Phát hiện malware dựa trên signature hash
  • B. Phát hiện lỗ hổng đã biết lan truyền sang firmware/thư viện khác
  • C. Tăng tốc độ biên dịch
  • D. Nén binary để giảm kích thước

Câu 8. Thách thức chính của BCSD cross-platform là gì?

  • A. Kích thước file binary quá lớn
  • B. Cùng mã nguồn nhưng binary khác nhau hoàn toàn khi biên dịch trên CPU/OS/compiler khác nhau
  • C. Cần kết nối internet để so sánh
  • D. Chỉ hoạt động với file ELF

Câu 9. Fuzzing về cơ bản thực hiện điều gì?

  • A. Phân tích mã nguồn không thực thi để tìm lỗi
  • B. Sinh và đưa dữ liệu bất thường vào chương trình để phát hiện crash/lỗi không kiểm soát
  • C. Mô phỏng tấn công mạng
  • D. Kiểm tra hiệu năng của phần mềm

Câu 10. Fuzzing được cho là nguồn gốc của bao nhiêu % lỗ hổng được tìm thấy trong 10 năm qua?

  • A. 50%
  • B. 70%
  • C. 85%
  • D. 95%

Câu 11. AFL (American Fuzzy Lop) là loại fuzzer thuộc loại nào?

  • A. Black-box fuzzer (không có thông tin cấu trúc)
  • B. White-box fuzzer (dùng symbolic execution)
  • C. Grey-box fuzzer (dùng coverage feedback từ instrumentation)
  • D. Model-based fuzzer

Câu 12. AFL hoạt động tốt nhất trong điều kiện nào?

  • A. Binary không có mã nguồn (black-box)
  • B. Có mã nguồn để chèn instrumentation lúc compile
  • C. Chạy trên môi trường ảo hóa
  • D. Khi kết hợp với antivirus

Câu 13. Kỹ thuật mutation “havoc” trong AFL là gì?

  • A. Lật từng bit trong input
  • B. Kết hợp ngẫu nhiên nhiều phép đột biến khác nhau
  • C. Ghép 2 test case khác nhau lại
  • D. Thay thế bằng các giá trị số nguyên đặc biệt

Câu 14. QIRA được mô tả là “timeless debugger” – điều này có nghĩa là gì?

  • A. Debugger chạy không giới hạn thời gian
  • B. Có thể quan sát trạng thái chương trình tại bất kỳ điểm nào trong lịch sử thực thi và di chuyển forward/backward
  • C. Không cần cài đặt, chạy trực tiếp từ internet
  • D. Tương thích với mọi ngôn ngữ lập trình

Câu 15. Taint Analysis theo dõi điều gì trong chương trình?

  • A. Hiệu năng CPU của từng hàm
  • B. Luồng dữ liệu từ nguồn không tin cậy (user input) đến các điểm nguy hiểm (sink)
  • C. Thứ tự khởi tạo biến
  • D. Số lần hàm được gọi

Câu 16. Công cụ PANDA được dùng cho mục đích gì trong bảo mật?

  • A. Static code analysis
  • B. Dynamic Taint Analysis – ghi lại và phân tích trace thực thi
  • C. Phát hiện virus
  • D. Quản lý lỗ hổng

Câu 17. Symbolic Execution khác với thực thi thông thường ở điểm nào?

  • A. Chạy nhanh hơn
  • B. Sử dụng giá trị tượng trưng (symbolic) thay vì giá trị cụ thể, để khám phá tất cả paths
  • C. Không cần mã nguồn
  • D. Chỉ phân tích code tĩnh

Câu 18. “Path Explosion” là vấn đề gì của Symbolic Execution?

  • A. File binary quá lớn để phân tích
  • B. Số lượng đường thực thi tăng theo cấp số nhân với số điều kiện rẽ nhánh, làm hệ thống không thể xử lý
  • C. Thiếu bộ nhớ RAM khi chạy
  • D. Không tương thích với kiến trúc ARM

Câu 19. Z3 là công cụ gì và được dùng trong lĩnh vực nào?

  • A. Fuzzer của Microsoft
  • B. SMT Solver của Microsoft, dùng để giải các ràng buộc trong symbolic execution
  • C. Debugger cho Windows
  • D. Static analyzer của Google

Câu 20. DARPA Cyber Grand Challenge (CGC) được tổ chức năm nào?

  • A. 2014
  • B. 2016
  • C. 2018
  • D. 2020

Câu 21. Hệ thống nào đã giành chiến thắng tại DARPA CGC 2016?

  • A. CHESS
  • B. MATE
  • C. Mayhem
  • D. Galois

Câu 22. CRS trong bối cảnh CGC là viết tắt của gì?

  • A. Code Review System
  • B. Cyber Reasoning System
  • C. Critical Response Security
  • D. Computer Risk Score

Câu 23. Mayhem CRS sử dụng kết hợp những kỹ thuật nào?

  • A. Antivirus + Firewall + IDS
  • B. Smart Fuzzing + Taint Analysis + Constraint Solver + Machine Learning
  • C. Static Analysis + Code Review + Penetration Testing
  • D. Decompilation + Manual Analysis

Câu 24. Dự án MATE thuộc chương trình nào của DARPA?

  • A. CGC (Cyber Grand Challenge)
  • B. CHESS (Computers and Humans Exploring Software Security)
  • C. DARPA SBIR
  • D. DARPA AI Next

Câu 25. Triết lý chính của dự án MATE so với CGC thuần túy là gì?

  • A. Hoàn toàn tự động hóa, không cần con người
  • B. Kết hợp human insight với automated analysis để xử lý phần mềm thực tế phức tạp
  • C. Chỉ dùng static analysis
  • D. Tập trung vào web application

Câu 26. Static Code Analyzer có hạn chế gì so với Dynamic Analysis?

  • A. Cần runtime environment
  • B. Thường có nhiều false positives và bỏ lỡ các lỗi chỉ xuất hiện lúc runtime (như UAF)
  • C. Chỉ hỗ trợ C/C++
  • D. Cần quyền root để chạy

Câu 27. Coverity phát hiện lỗi nào theo mô tả trong bài giảng?

  • A. SQL Injection và XSS
  • B. Out-of-bounds access, uninitialized scalar, resource leak, missing return statement
  • C. Lỗi mạng và giao thức
  • D. Logic flaw và authentication bypass

Câu 28. “Bug Hunting” được mô tả là tốn nhiều thời gian, giải pháp được đề xuất là gì?

  • A. Thuê thêm nhân sự
  • B. Tự động hóa (Automation) quá trình tìm bug
  • C. Dùng nhiều ngôn ngữ lập trình an toàn hơn
  • D. Chuyển sang kiến trúc microservice

Câu 29. AFL có thể sử dụng với binary không có mã nguồn không? Nếu có, thông qua cơ chế nào?

  • A. Không, AFL bắt buộc cần mã nguồn
  • B. Có, thông qua QEMU mode (dynamic instrumentation) với hiệu năng thấp hơn
  • C. Có, thông qua static rewriting với hiệu năng tương đương
  • D. Có, chỉ cần debug symbols là đủ

Câu 30. Trong output của AFL, “uniq crashes: 8” có nghĩa là gì?

  • A. AFL đã crash 8 lần trong quá trình chạy
  • B. Tìm thấy 8 crash patterns duy nhất (8 loại lỗi khác nhau về stack trace/location)
  • C. Cần chạy thêm 8 lần nữa
  • D. Có 8 test case trong corpus ban đầu

Câu 31. “Coverage-guided fuzzing” có lợi thế gì so với “dumb fuzzing” (random hoàn toàn)?

  • A. Không cần corpus ban đầu
  • B. Ưu tiên các input mở ra code path mới, giúp khám phá code hiệu quả hơn
  • C. Chạy nhanh hơn vì không cần đo coverage
  • D. Không cần môi trường sandbox

Câu 32. Kỹ thuật “splice” trong AFL mutation là gì?

  • A. Cắt bỏ một phần của input
  • B. Ghép hai test case từ corpus lại với nhau tạo ra input mới
  • C. Sao chép input nhiều lần
  • D. Đảo ngược thứ tự byte

Câu 33. Tại sao bug hiện đại ngày càng “khó” hơn để fuzzer thông thường tìm thấy?

  • A. Binary ngày càng được encrypt
  • B. Bug chỉ kích hoạt với điều kiện rất đặc biệt mà fuzzing ngẫu nhiên khó đạt tới
  • C. Chương trình không còn crash khi gặp lỗi
  • D. OS chặn tất cả crash signals

Câu 34. Machine Learning được ứng dụng trong bug hunting theo những cách nào?

  • A. Chỉ để phân tích log
  • B. Hướng dẫn fuzzer, phân loại crash, phát hiện lỗ hổng từ code, sinh exploit
  • C. Chỉ để báo cáo kết quả
  • D. Thay thế hoàn toàn fuzzing

Câu 35. Reinforcement Learning (RL) được áp dụng trong obfuscation như thế nào?

  • A. Train model để detect obfuscated code
  • B. Tự động sinh ra chuỗi obfuscation transformation tối ưu để maximize khó phân tích
  • C. Dùng RL để deobfuscate code
  • D. Tối ưu hóa compile-time obfuscation

Câu 36. Trong output AFL, “map density: 4.82%” có ý nghĩa gì?

  • A. 4.82% test cases gây crash
  • B. 4.82% các edge trong control flow graph đã được khám phá
  • C. Hiệu suất CPU là 4.82%
  • D. 4.82% input hợp lệ được xử lý đúng

Câu 37. Dự án Asteria giải quyết bài toán gì?

  • A. Automatic exploit generation
  • B. Cross-platform binary code similarity detection dựa trên AST encoding và deep learning
  • C. Automated patch generation
  • D. Malware classification

Câu 38. DARPA CHESS là viết tắt của gì?

  • A. Cybersecurity Hardware Embedded System Security
  • B. Computers and Humans Exploring Software Security
  • C. Cyber Hardening and Exploit Stopping System
  • D. Comprehensive Heuristic Engine for Security Scanning

Câu 39. Tại sao các hệ thống CRS trong CGC không thể trực tiếp áp dụng vào phần mềm thực tế như web browser?

  • A. Web browser chạy trên Windows, không tương thích
  • B. Phần mềm thực tế phức tạp hơn nhiều, cần human insight để định hướng phân tích
  • C. Không đủ băng thông mạng
  • D. CRS chỉ hỗ trợ binary 32-bit

Câu 40. Code Property Graph (CPG) trong MATE là gì?

  • A. Đồ thị vẽ coverage của fuzzer
  • B. Cấu trúc dữ liệu hợp nhất AST, CFG, PDG của chương trình để phân tích toàn diện
  • C. Graph database chứa CVE
  • D. Biểu đồ call graph của binary

Câu 41. Trong Taint Analysis, “source” và “sink” là gì?

  • A. Source là nơi bắt đầu chạy code, sink là nơi kết thúc
  • B. Source là nguồn dữ liệu không tin cậy (user input), sink là điểm nguy hiểm có thể bị lợi dụng
  • C. Source là file đầu vào, sink là file đầu ra
  • D. Source là hàm allocate, sink là hàm free

Câu 42. Kết hợp Symbolic Execution với Fuzzing (Hybrid Fuzzing) có lợi thế gì?

  • A. Chậm hơn nhưng chính xác hơn
  • B. Dùng symbolic execution để vượt qua các điều kiện khó, fuzzing để bao phủ nhanh phần còn lại
  • C. Loại bỏ hoàn toàn false positives
  • D. Không cần corpus ban đầu

Câu 43. CFI (Control Flow Integrity) bảo vệ chống lại loại tấn công nào?

  • A. SQL Injection
  • B. ROP (Return-Oriented Programming) và JOP chains – tấn công chuyển hướng luồng điều khiển
  • C. Buffer Overflow trực tiếp vào stack
  • D. Heap spray attacks

Câu 44. Theo bài giảng, “exploit chain” liên quan đến vấn đề gì?

  • A. Chain nhiều lỗ hổng nhỏ lại để tạo thành exploit lớn hơn
  • B. Chi phí để thực hiện chuỗi khai thác này quá cao khi có nhiều biện pháp bảo vệ
  • C. Cả A và B
  • D. Kỹ thuật dùng nhiều CVE cùng lúc

Câu 45. ASLR (Address Space Layout Randomization) chống lại loại tấn công nào?

  • A. SQL Injection
  • B. Tấn công dựa trên địa chỉ cố định – kẻ tấn công không thể biết trước địa chỉ của stack, heap, library
  • C. Network-based attacks
  • D. Timing attacks

Câu 46. JTrans được mô tả là “jump-aware transformer” – điều này giải quyết vấn đề gì trong BCSD?

  • A. Phân tích code Java
  • B. Transformer thông thường bỏ qua thông tin control flow jump – JTrans mã hóa thông tin nhảy để cải thiện so sánh
  • C. Tăng tốc quá trình so sánh
  • D. Hỗ trợ thêm kiến trúc CPU mới

Câu 47. Trong bài giảng, điều kiện nào khiến phát hiện UAF bằng static analysis là “rất khó”?

  • A. UAF xảy ra ở kernel space
  • B. UAF phụ thuộc vào trạng thái runtime (thứ tự alloc/free/use) không thể suy ra từ code tĩnh
  • C. UAF chỉ xảy ra trong code multi-thread
  • D. Static analyzer không hỗ trợ C++

Câu 48. Phương pháp nào trong số sau đây là ví dụ về “Black-box fuzzing”?

  • A. AFL với compile-time instrumentation
  • B. LibFuzzer
  • C. Đưa dữ liệu ngẫu nhiên vào API của chương trình mà không biết cấu trúc nội bộ
  • D. Symbolic execution với SMT solver

Câu 49. Theo bài giảng, hai hướng nghiên cứu chính về Software Security (không phải exploitation) là gì?

  • A. Intrusion Detection và Firewall
  • B. Code Obfuscation và Code Similarity Detection
  • C. Cryptography và Authentication
  • D. Web Security và Mobile Security

Câu 50. Điều gì đặc biệt về cuộc thi CGC so với các CTF thông thường?

  • A. Có nhiều đội tham dự hơn
  • B. Các đội là hệ thống AI tự động thi đấu, không phải con người – hoàn toàn tự động tấn công và phòng thủ trong thời gian thực
  • C. Chỉ thi về web security
  • D. Diễn ra trong 24 giờ liên tục

Câu 51. “Automated Exploit Generation (AEG)” là bài toán nghiên cứu gì?

  • A. Tự động tạo antivirus signature
  • B. Tự động sinh mã khai thác (exploit code) từ thông tin về lỗ hổng đã phát hiện
  • C. Tự động cập nhật phần mềm
  • D. Tự động viết unit test

Câu 52. Kỹ thuật “Instruction Substitution” trong obfuscation thực hiện điều gì?

  • A. Xóa các instruction không cần thiết
  • B. Thay một instruction đơn giản bằng chuỗi instruction tương đương nhưng phức tạp hơn
  • C. Đổi thứ tự các instruction
  • D. Mã hóa instruction thành dạng encrypted

Câu 53. Tại sao “Dead Code Insertion” là kỹ thuật obfuscation hiệu quả?

  • A. Vì nó làm chương trình chạy nhanh hơn
  • B. Vì nó thêm code không bao giờ thực thi nhưng làm phân tích tĩnh phức tạp hơn
  • C. Vì nó xóa code không cần thiết
  • D. Vì nó tạo ra backdoor ẩn

Câu 54. Trong CGC, các đội tham dự là những tổ chức nào theo bài giảng?

  • A. Chỉ các công ty an ninh mạng
  • B. UC Berkeley, MIT Lincoln Laboratory, Raytheon, FSecure, SRD International
  • C. Chỉ các trường đại học
  • D. Các cơ quan chính phủ

Câu 55. “Automated Program Repair” (Vá lỗ hổng tự động) đặt ra những thách thức gì?

  • A. Không có thách thức gì, đây là bài toán đã được giải
  • B. Phải vá đúng lỗi, không làm hỏng chức năng hiện có, và patch phải nhỏ gọn/hiệu quả
  • C. Chỉ khó với ngôn ngữ scripting
  • D. Cần quyền admin

💡 Ghi chú tổng kết: Bài giảng phác thảo bức tranh tương lai của software security theo hai hướng: (1) bảo vệ code ngày càng tinh vi hơn (obfuscation, similarity detection), và (2) tấn công/phòng thủ ngày càng tự động hóa hơn (fuzzing thông minh, symbolic execution, ML, AEG). Xu hướng hội tụ là các hệ thống hybrid human-machine như MATE, nơi máy tính xử lý tầm quy mô còn con người cung cấp insight chiến lược.