Những lỗi sai thường gặp trong điều tra pháp y kỹ thuật số (Phần 2)

quantri 2024-12-26 Điều tra dữ liệu, Tin tức

Phần 1: Những lỗi sai thường gặp trong điều tra pháp y kỹ thuật số (Phần 1) – HTI Services

Để tiếp nối bài viết của kì trước, dưới đây là 5 lỗi sai thường gặp khác trong lĩnh vực DFIR (Pháp y kỹ thuật số và ứng phó sự cố).

Sai lầm #4: Truy cập RAM không đúng cách và mất khóa mã hóa

Hầu như mọi thiết bị kỹ thuật số hiện đại đều sử dụng mã hóa. Các thiết bị di động hiện đại có tích hợp mã hóa mặc định mà không cần người dùng phải bật thủ công. Máy tính, đặc biệt là máy tính xách tay, cũng có thể được kích hoạt mã hóa ngay từ khi thiết lập ban đầu, cho dù là mã hóa dựa trên hệ thống tệp (APFS) hay mã hóa dựa trên hệ điều hành (Bitlocker trong Windows).

Vì mã hóa phổ biến như vậy nên sẽ là một sai lầm nghiêm trọng nếu giám định viên tắt nguồn một máy tính đang hoạt động để thực hiện cái gọi là “thu thập hộp chết” (dead-box acquisition). Đây từng là cách tiếp cận thông thường trong việc thu thập dữ liệu vào những ngày trước kỷ nguyên mã hóa. Nếu bạn tắt nguồn một thiết bị được mã hóa hiện đại, bạn có thể sẽ mất quyền truy cập vào tất cả thông tin mà bạn có thể đã thu thập và sử dụng để phá vỡ mã hóa.

Lưu ý: Hãy đảm bảo bạn đọc kỹ các hướng dẫn của ACPO hoặc các tài liệu tương tự, bàn về các phương pháp hay nhất, hướng dẫn và quy tắc thu thập bộ nhớ tạm thời.

Khi cần giải mã, cơ hội tốt nhất để chống lại mã hóa là lấy một bản sao lưu RAM từ thiết bị đang hoạt động. Dữ liệu trong bộ nhớ tạm thời có thể chứa các khóa giải mã, và chúng có thể quyết định thành công hay thất bại của quá trình điều tra (mặc dù cần phải nhấn mạnh rằng không có gì đảm bảo rằng việc sao lưu RAM sẽ tạo ra khóa giải mã của thiết bị!).

FTK Imager, một công cụ tuyệt vời cho nhiều phương pháp thu thập, nhưng yêu cầu quá nhiều bộ nhớ để trở thành lựa chọn tốt nhất cho việc dump RAM. Kích thước của nó lên tới hơn 20 megabyte, trong khi có nhiều công cụ khác trên thị trường nhỏ hơn hàng trăm lần. Rõ ràng, công cụ càng lớn thì càng có nhiều dữ liệu người dùng bị ghi đè trong bộ nhớ khi chạy, do tệp thực thi của công cụ được tải vào bộ nhớ.

Sai lầm #5: Thực hiện phiên duyệt web trực tiếp

Nghe có vẻ như là một lỗi không thể xảy ra, nhưng thực tế mỗi năm chúng tôi đều nghe khá nhiều câu chuyện về việc này xảy ra. Đây là một lỗi có thể mắc phải ngay cả với các điều tra viên có kinh nghiệm và đây là cách nó xảy ra:

Một điều tra viên DFIR thiếu kinh nghiệm có thể bị cám dỗ thực hiện phân tích trực tiếp trên thiết bị và cố gắng lấy thông tin chỉ có thể có được từ trình duyệt do người dùng đã đăng nhập. Một bản sao “hộp chết” (dead-box image) có thể khiến dữ liệu trình duyệt bị mã hóa. Việc giải mã dữ liệu như vậy không phải là một nhiệm vụ đơn giản (mặc dù có thể).

Lỗi này cũng có thể xảy ra do thực tế rằng người đầu tiên tiếp cận thiết bị kỹ thuật số thường không phải là một điều tra viên kỹ thuật số có chuyên môn. Bất kỳ ai không được đào tạo về cách thu giữ thiết bị đúng cách có thể bị cám dỗ nhanh chóng và bất cẩn lấy thông tin từ thiết bị đang hoạt động, gây ra thiệt hại không thể khắc phục đối với khả năng chấp nhận dữ liệu trước tòa án sau này.

Cố gắng phân tích trực tiếp trên thiết bị bằng tài khoản của nghi phạm có thể gây ra những vấn đề pháp lý nghiêm trọng trong quá trình tố tụng, vì chuỗi bảo quản chứng cứ không thể được đảm bảo.

Lỗi #6: Cố gắng giải mã bằng brute-force, có thể mất hơn một tỷ năm

Mã hóa hiện đại đã chứng minh được sự vững chắc của nó. Nếu mật khẩu đủ mạnh, không có phương pháp giải mã nào thực sự khả thi và hợp lý để áp dụng mà không tốn quá nhiều thời gian. Không giống như các thuật toán trước đây cho phép điều tra viên thử hàng trăm, nếu không nói là hàng nghìn mật khẩu mỗi giây, mã hóa hiện đại yêu cầu vài giây cho mỗi mật khẩu được thử!

Tiến hành một cuộc tấn công brute-force toàn diện (trong hầu hết các trường hợp) không phải là lựa chọn thông minh. Ngay cả với một hệ thống hiệu suất cao, được trang bị đầy đủ bộ nhớ và nhiều card đồ họa, các nỗ lực brute-force tuần tự có thể mất hàng tỷ năm để hoàn thành!

Khi nói về brute-force tuần tự, chúng tôi muốn nói đến việc kiểm tra các mật khẩu theo thứ tự từ thấp đến cao (ví dụ: a, b, c… aa, ab, ac và tiếp tục). Dễ dàng thấy rằng việc kiểm tra hàng loạt mật khẩu có thể có theo thứ tự lần lượt, và nhân mỗi nỗ lực này với chỉ một giây cho mỗi mật khẩu, sẽ đưa ra một kết quả đáng sợ.

Một phương pháp tốt hơn là sử dụng tấn công từ điển. Nếu bạ

n đã có một số dữ liệu được trích xuất từ thiết bị của nghi phạm (ví dụ: các bản dump bộ nhớ), dữ liệu này có thể được sử dụng cho việc giải mã. Hầu hết mọi người tạo mật khẩu dựa trên những từ trong vốn từ vựng của họ, những từ mà họ sử dụng thường xuyên (ví dụ: tên con cái, ngày sinh, nơi ở, màu yêu thích, sở thích,…). Kết hợp các thuật ngữ liên quan đến vụ án và ưu tiên thử những mật khẩu tiềm năng đó tăng cơ hội thành công.

Vì hầu hết mọi người thường sử dụng lại mật khẩu cho nhiều tài khoản khác nhau, đôi khi chỉ cần tìm ra “mắt xích yếu nhất” là đủ. Điều tra viên có thể cố gắng crack mật khẩu được lưu trữ ở nơi ít an toàn nhất trước, sau đó áp dụng mật khẩu đó cho các mục được mã hóa mạnh hơn.

Lỗi #7: Nhầm lẫn giữa giờ UTC và giờ địa phương

Trên thế giới có rất nhiều múi giờ khác nhau (về mặt kỹ thuật thì có hơn 24 múi giờ). Mỗi múi giờ đều có giờ địa phương riêng: khi ở London là 12 giờ trưa thì ở New York là 7 giờ sáng. Tiêu chuẩn lưu trữ ngày giờ là Giờ Quốc tế (UTC). Điều này có nghĩa là hầu hết các ứng dụng và hệ thống đều lưu trữ dấu thời gian theo UTC. Tuy nhiên, điều này có thể gây ra sự bất tiện và nhầm lẫn đối với người dùng thông thường, những người thường quen sử dụng giờ địa phương của mình. Đó là lý do tại sao các ứng dụng có thể chọn lưu dấu thời gian theo giờ địa phương, được thiết lập trên từng thiết bị của người dùng.

Với khối lượng dữ liệu lớn trong các vụ án ngày nay, việc nhầm lẫn giữa giờ UTC và giờ địa phương do các ứng dụng khác nhau lưu trữ là điều dễ xảy ra. Nếu bạn không chuyển đổi tất cả các dấu thời gian sang UTC (hoặc giờ địa phương), bạn có thể gặp phải tình trạng các tin nhắn trò chuyện bị đảo ngược thứ tự. Điều này xảy

ra nếu một ứng dụng trò chuyện lưu trữ dấu thời gian theo UTC, trong khi ứng dụng khác sử dụng giờ địa phương.

Công cụ pháp y của bạn có thể làm trầm trọng thêm sự nhầm lẫn này đối với nhiều loại chứng cứ nếu các dấu thời gian không được chuyển đổi chính xác. Vấn đề càng trở nên phức tạp h

ơn nếu bạn có nhiều nguồn dữ liệu từ các múi giờ khác nhau. Công cụ pháp y mà bạn chọn phải cho phép bạn chỉ định các múi giờ khác nhau cho các thiết bị trong vụ án để tránh nhầm lẫn về dấu thời gian.

Lỗi #8: Làm thiết bị di động chứa bằng chứng bị “hỏng”

Càng ngày, các thiết bị di động càng tiến hóa, và việc thu thập dữ liệu từ chúng càng trở nên khó khăn hơn. Các bản sao vật lý (physical images), từng khả dụng khi smartphone đầu tiên ra đời, giờ đây không còn khả thi do các tính năng mã hóa được tích hợp sẵn. Hơn nữa, các bản sao lưu tiêu chuẩn chỉ cung cấp một lượng dữ liệu rất hạn chế. Đó là lý do tại sao hầu hết các phương pháp hiện đại để thu thập dữ liệu từ thiết bị thông minh đều dựa trên các lỗ hổng đã biết và các cuộc trích xuất sau đó.

Một lỗi phổ biến là sử dụng cách khai thác mà không kiểm tra trước trên một điện thoại mẫu (donor phone). Bất kỳ sự thiếu chính xác hoặc sai sót nào trong các bước thực hiện (ví dụ: thời gian chờ không chính xác hoặc một mô hình SoC (System on a Chip) hơi khác so với mô hình được hỗ trợ trong các lỗ hổng)—có thể vô tình làm hỏng thiết bị (brick the device). Mất bằng chứng theo cách này không chỉ gây thất vọng mà còn có thể hủy hoại vụ án của bạn nếu thiết bị đó là một nguồn bằng chứng quan trọng. Vì vậy, việc kiểm tra cẩn thận mọi phương pháp thu thập dữ liệu sử dụng trên một thiết bị mẫu tương tự, hoặc tốt nhất là đúng mẫu thiết bị đó là vô cùng cần thiết.

Cũng cần lưu ý rằng, đôi khi ngay cả các thiết bị có cùng mẫu và cùng SoC bên trong cũng có thể hoạt động khác nhau. Thật không may, điều này có nghĩa là một cuộc thử nghiệm thành công, ngay cả trên cùng một thiết bị, cũng không đảm bảo 100% rằng sẽ an toàn cho thiết bị cụ thể đó. Tuy nhiên, việc thử nghiệm trước rõ ràng sẽ tăng cơ hội thành công và vẫn tốt hơn là không thử nghiệm chút nào.

HTI Services cung cấp các khóa Đào tạo Điều tra kỹ thuật số điện tử được thiết kế riêng cho các đơn vị giám định kỹ thuật số điện tử và điều tra kỹ thuật số điện tử ở Việt Nam với đa dạng lựa chọn, phù hợp với nhiều nhu cầu khác nhau của từng đơn vị, tổ chức.

Liên hệ ngay với chúng tôi qua Hotline 0928.765.688 để nhận được tư vấn chi tiết.

Trụ sở Hà Nội: Tầng 12 – VP2, Tòa nhà Sun Square, 21 Lê Đức Thọ, Nam Từ Liêm, Hà Nội