Case Study: phân tích hiện trường sau khi bị thâm nhập.

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Case Studies

Case Study: phân tích hiện trường sau khi bị thâm nhập.

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	17/02/2012 10:17:56 (+0700) \| #31 \| 254110

tmd
Member

Joined: 28/06/2006 03:39:48
Messages: 2951
Offline

Ikut3 wrote:

- Xác nhận thời điểm tấn công gần đúng qua file log
smilie Riêng chuyện file log có thể bị làm giả, mất tính toàn vẹn thì em cũng chưa biết sẽ xử lý thế nào ?

- Quản lí log tập trung, log dữ liệu không trực tiếp lưu trên máy chạy dịch vụ đó mà mỗi record trong quá trình ghi nhân sẽ được đẩy qua Log Centralize.

- Tuy nhiên nếu Attacker hoàn toàn có thể làm sai log (đầu độc, gây nhiễu, v.v...) trước khi quá trình đẩy log từ máy chủ dịch vụ đến máy chủ lưu trữ log. Đối với vấn đề này, thì mình vẫn chưa có giải pháp nào, mời mọi người cho ý kiến

Mánh này sẽ bị phát hiện nếu người quản trị chơi trò "nhét que tăm khe cửa".

3 giai đoạn của con... người, ban đầu dek biết gì thì phải thăm dò, sau đó biết rồi thì phải thân thiết, sau cùng khi quá thân thiết rồi thì phải tình thương mến thương. Nhưng mà không thương được thì ...

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	17/02/2012 16:14:47 (+0700) \| #32 \| 254217

vikjava
Elite Member

Joined: 28/06/2004 02:32:38
Messages: 926
Location: NQN
Offline

Ikut3 wrote:

- Xác nhận thời điểm tấn công gần đúng qua file log
smilie Riêng chuyện file log có thể bị làm giả, mất tính toàn vẹn thì em cũng chưa biết sẽ xử lý thế nào ?

- Quản lí log tập trung, log dữ liệu không trực tiếp lưu trên máy chạy dịch vụ đó mà mỗi record trong quá trình ghi nhân sẽ được đẩy qua Log Centralize.

- Tuy nhiên nếu Attacker hoàn toàn có thể làm sai log (đầu độc, gây nhiễu, v.v...) trước khi quá trình đẩy log từ máy chủ dịch vụ đến máy chủ lưu trữ log. Đối với vấn đề này, thì mình vẫn chưa có giải pháp nào, mời mọi người cho ý kiến

- Quá trình đẩy log từ máy chủ dịch vu đến máy chủ lưu trữ log thông thường đòi hỏi Real Time. Vì khi triển khai giải pháp log tập trung thì máy chủ này không chỉ có nhiệm vụ lưu trữ log, nó có thể thực hiện chức năng tương tự như 1 IDS. Thời gian phản ứng với sự cố càng sớm càng tốt ....

- Case study này có lẽ không liên quan đến giải pháp log tập trung hay làm cách nào để đối phó với tình trạng làm nhiễu log, xoá log. Hành động làm nhiễu log, xoá log thông thường đi sau hành động tấn công, server bị nhân nhượng vì thế có lẽ nên tập trung vào giải pháp ở các tầng, các lớp bằng việc monitor, detect, alert đối với những event thuộc dấu hiệu hack ....

Tập trung vào 3 đối tượng anh conmale đề cập cũng đã có nhiều thứ để bàn rồi, mở rộng ra sẽ loãng smilie

a. Một máy chủ có nhiều dịch vụ.
b. Máy chủ ấy được ISP bảo vệ.
c. Phiên bản của của hệ điều hành và các dịch vụ.

@tmd: không hiểu bác nói gì cả smilie

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	20/02/2012 07:16:01 (+0700) \| #33 \| 254576

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

vikjava wrote:

a. Một máy chủ có nhiều dịch vụ.
b. Máy chủ ấy được ISP bảo vệ.
c. Phiên bản của của hệ điều hành và các dịch vụ.

Ở góc độ forensics, 3 điểm trên chính là biên độ điều tra (ngôn ngữ chuyên ngành còn gọi là perimeters).

Biên độ "được ISP bảo vệ" có thể rất mơ hồ bởi vì phần lớn các ISP chỉ áp dụng một hệ thống chung nhằm cản lọc những "known vulnerabilities". Hầu hết, những attack vectors mới hoặc chưa report đều qua mặt những hệ thống cản lọc chung chung của ISP. Tệ hại nhất là thông tin để điều tra hầu như không có mấy vì chẳng có ISP nào chịu logs những hoạt động ra vào (cũng dễ hiểu vì chẳng có hệ thống lưu trữ nào đủ lớn để lưu những thông tin hoạt động ra vào). Trường hợp dedicated server bị tấn công là "fully managed" và có hệ thống bảo vệ + theo dõi riêng thì không kể nhưng dạng này thuộc dạng quý hiếm và dường như ở VN không có.

Nói chung, nếu dựa vào ISP để thu thập thông tin cho mục đích forensics và những hoạt động ấy đang xảy ra thì khả thi nhưng nếu đã xảy ra trước đây thì khá vô vọng.

Biên độ "một máy chủ có nhiều dịch vụ" có thể có những điểm quan trọng để điều tra, ví dụ: system logs, IDS logs, application logs... Tuy nhiên, nếu system và applications chỉ log lại những thông tin "bất thường" và hoàn toàn không logs những thông tin "không bất thường" thì rất kẹt. Hầu hết những tấn công ở "web" vectors khó có thể xác định tính "bất thường" ngoại trừ trường hợp IDS và applications có những quy chế logs chặc chẽ. Trong trường hợp kẻ tấn công là kẻ có kinh nghiệm, ngoài khả năng xoá trọn bộ logs (theo kiểu cover-tracks cổ điển mà mấy cuốn sách "dạy hack" thường đề cập smilie

), kẻ tấn công có thể "gây nhiễu" trong logs hoặc chỉ xoá những thông tin cần được xoá trong logs. Cách thứ nhì là cách sẽ gây khó khăn bởi vì mọi chuyện có vẻ như bình thường nhưng quả thật hệ thống đã bị thâm nhập nhưng không biết bị thâm nhập ở vector nào. Cách này chứng tỏ hacker ấy là một kẻ dày dạn, có thừa thời gian và thừa điềm tĩnh để "gây nhiễu" trên chính hệ thống mình thâm nhập. Trong trường hợp này, nếu forensics không khéo sẽ bị lạc hướng (thay vì bế tắc như trường hợp logs bị xoá hoàn toàn). Xét ở góc độ phòng chống, nếu không thu thập được thông tin cho forensics mà vẫn tiếp tục sử dụng hệ thống ấy như cũ thì đó là quyết định dại dột.

Forensics chỉ có thể mang lại kết quả nếu như hệ thống đã được sắp xếp và ấn định sẵn. Nếu chỉ dựa vào cơ chế "logging" tiêu chuẩn của hệ điều hành và của từng application thì xem như là thất bại (ngoài trừ trường hợp hacker quá thiếu kinh nghiệm nên không thực hiện "cover-track" đúng bài bản).

Nếu hệ thống được áp dụng passive monitoring (như snort theo dõi ở dạng stealth) và có remote loggings + kernel level keylogging và những thứ này không bị hackers phát hiện thì chắc chắn sẽ thu thập được nhiều thông tin quý giá. Nếu gặp phải hacker dày dạn (như cỡ cố tình làm nhiễu logs) thì những cơ chế ấy có thể bị ép cho ngưng hoạt động hoặc thậm chí cố gây nhiễu thì cũng sẽ tạo muôn vàn khó khăn cho forensics.

What bringing us together is stronger than what pulling us apart.

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	20/02/2012 08:41:59 (+0700) \| #34 \| 254581

.lht.
Member

Joined: 26/09/2010 10:06:38
Messages: 75
Location: Inside you
Offline

Forensics chỉ có thể mang lại kết quả nếu như hệ thống đã được sắp xếp và ấn định sẵn. Nếu chỉ dựa vào cơ chế "logging" tiêu chuẩn của hệ điều hành và của từng application thì xem như là thất bại (ngoài trừ trường hợp hacker quá thiếu kinh nghiệm nên không thực hiện "cover-track" đúng bài bản).

Vậy ở đây, forensics mang lại nhiều kết quả khi mà hệ thống được sắp xếp từ trước (có thể là nhiều nếu "hacker không chuyên" và ít hoặc khó khăn nếu "hacker cao thủ" ).
Nếu những hệ thống khi mà trước đó không được chuẩn bị từ trước (rất nhiều ở VN lẫn trên thế giới) khi bị tấn công phải chăng là "khó khăn để tìm ra cho đến mức độ vô vọng" ?

Ở trên, mọi người "phụ thuộc" vào logs để suy đoán diễn biến và hiện trạng là nhiều. Theo như em thấy thì song song nó, hằng ngày ta cũng nên theo dõi những cập nhật và phát hiện lỗi mới. Nó sẽ giúp cho quá trình forensics nhanh phát hiện ra vấn đề hơn (với nhiều trường hợp - cụ thể là những công bố lỗi bảo mật mới nhất của phiên bản dịch vụ).

=> Biên độ "Phiên bản của của hệ điều hành và các dịch vụ" sẽ có ích hơn nhiều.

Về mặt tâm lý quản trị viên, như 1 bạn Sứ giả thiện chí của BKAV có nickname Longdo đã từng viết:

Với một website đang beta như webscan, người ta chủ yếu theo dõi các chỉ số truy cập, seo, phản hồi người dùng...chứ không phải lúc nào cũng lùng sục lên code đâu bạn ạ.

Từ đây ta nhận thấy 1 điều rằng, đôi khi những cái "current" logs thường có "khoảng thời gian không được động đến cho đến khi 1 sự việc nào đó sảy ra" và cần phải kiểm tra.
Với 1 hệ thống lớn, nhiều người truy cập. Chắc hản sẽ có ấn định xoá logs trong 1 khoảng thời gian (có thể là sau vài tuần cho đến vài tháng) để tránh tình trạng hệ thống có nhiều "rác" ngốn hết tài nguyên.

Với 1 attacker khôn ngoan và có tính kiên nhẫn, với mục tiêu của anh ta. Trong trường hợp anh ta tấn công hệ thống thành công và cài đặt thành công backdoor nhưng "dìm ỉm" chuyện đó (không như anh bạn hacker kia để 1 file html to đùng ngay sau khi xâm nhập thành công). Và vài tháng sau anh ta trở lại để thực hiện hành vi phá hoại của mình thì như vậy những cái logs lưu giữ thông tin quạn trọng nhất để có thể hình dung ra quá trình bị thâm nhập lại không còn nữa ...

=> Thường xuyên theo dõi tình trạng hệ thống và kiểm tra logs định kì + đầy đủ cũng rất quan trọng.

Trash from trash is the place for new good things ~

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	20/02/2012 12:50:11 (+0700) \| #35 \| 254631

phanledaivuong
Member

Joined: 23/05/2008 17:34:21
Messages: 315
Location: /dev/null
Offline

conmale wrote:

vikjava wrote:

a. Một máy chủ có nhiều dịch vụ.
b. Máy chủ ấy được ISP bảo vệ.
c. Phiên bản của của hệ điều hành và các dịch vụ.

Ở góc độ forensics, 3 điểm trên chính là biên độ điều tra (ngôn ngữ chuyên ngành còn gọi là perimeters).
....

Nếu bài này là đáp án thì ở case study này thì tất cả đều trượt à anh smilie

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	20/02/2012 13:42:44 (+0700) \| #36 \| 254637

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

phanledaivuong wrote:

conmale wrote:

vikjava wrote:

a. Một máy chủ có nhiều dịch vụ.
b. Máy chủ ấy được ISP bảo vệ.
c. Phiên bản của của hệ điều hành và các dịch vụ.

Ở góc độ forensics, 3 điểm trên chính là biên độ điều tra (ngôn ngữ chuyên ngành còn gọi là perimeters).
....

Nếu bài này là đáp án thì ở case study này thì tất cả đều trượt à anh

Hầu như là trượt smilie

. Nếu anh chấm cho nghiêm khắc thì điểm cao nhất là 40/100 smilie

What bringing us together is stronger than what pulling us apart.

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	20/02/2012 22:18:34 (+0700) \| #37 \| 254683

Nowhereman
Elite Member

Joined: 19/11/2003 06:25:42
Messages: 108
Offline

.lht. wrote:

Với 1 attacker khôn ngoan và có tính kiên nhẫn, với mục tiêu của anh ta. Trong trường hợp anh ta tấn công hệ thống thành công và cài đặt thành công backdoor nhưng "dìm ỉm" chuyện đó (không như anh bạn hacker kia để 1 file html to đùng ngay sau khi xâm nhập thành công). Và vài tháng sau anh ta trở lại để thực hiện hành vi phá hoại của mình thì như vậy những cái logs lưu giữ thông tin quạn trọng nhất để có thể hình dung ra quá trình bị thâm nhập lại không còn nữa ...

.

@.lht.: theo bác khi mò vào được hệ thống rồi, cài "backdoor" rùi. và im ỉm chờ hết một tháng ( ví dụ ) cho hệ thống nó tự huỷ cái bộ logs hôm mò mẫm vào đi. .. cho an toàn rồi hãy BACK quay trở lại qua đường backdoor à bác? thế khi bác quay lại qua đường backdoor đó. hệ thống có làm ra tí lóc ( logs ) cóc nào kô bác ??? để em còn chờ... smilie

, vì em chỉ biết cách cổ điển là cover -tracks thôi bác. ( nói thẳng là chỉ biết và cố xoá trọn bộ logs ) xin các bác các anh cho ý kiến ạ .

lang thang vẫn mãi không nhà
đôi chân lê bước thê lương tháng ngày
càng đi càng thấy đắm say
tình thương con Chúa lòng này chẳng phai
thời gian cứ mãi miệt mài
lang thang đi tiếp ....rồi bay lên z ời
cúi đầu con lạy Ông Trời
xin thươn

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	21/02/2012 00:25:22 (+0700) \| #38 \| 254695

.lht.
Member

Joined: 26/09/2010 10:06:38
Messages: 75
Location: Inside you
Offline

Ở trên mình có nói mà smilie

Những thông tin quan trọng nhất để phát hiện lỗ hổng lúc này có thể đã bị "tự huỷ" nên nếu khi "back" thì mình qua đường backdoor.

Mục tiêu của người quản trị là tìm ra "lỗ hổng chính" để fix, còn attacker lại cao tay hơn "chờ" 1 thời gian "quay lại với con đường khác đã mở ra từ trước" chứ không theo con đường cũ. Sự việc này sẽ khiến 1 người quản trị "không thường xuyên theo dõi (lười)" khó tìm ra được vấn đề.

=> Thường xuyên theo dõi tình trạng hệ thống và kiểm tra logs định kì + đầy đủ cũng rất quan trọng.

Trash from trash is the place for new good things ~

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	22/02/2012 12:20:37 (+0700) \| #39 \| 254850

phanledaivuong
Member

Joined: 23/05/2008 17:34:21
Messages: 315
Location: /dev/null
Offline

.lht. wrote:

Ở trên mình có nói mà Những thông tin quan trọng nhất để phát hiện lỗ hổng lúc này có thể đã bị "tự huỷ" nên nếu khi "back" thì mình qua đường backdoor.

Mục tiêu của người quản trị là tìm ra "lỗ hổng chính" để fix, còn attacker lại cao tay hơn "chờ" 1 thời gian "quay lại với con đường khác đã mở ra từ trước" chứ không theo con đường cũ. Sự việc này sẽ khiến 1 người quản trị "không thường xuyên theo dõi (lười)" khó tìm ra được vấn đề.

Đây là 1 case study khá hay để thâm nhập xoá vết hơn là điều tra smilie

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	23/02/2012 14:30:43 (+0700) \| #40 \| 254947

PXMMRF
Administrator

Joined: 26/09/2002 07:17:55
Messages: 946
Offline

conmale wrote:

Nhân tiện trang diễn đàn BKAV vừa bị tấn công (defaced và mất DB), tôi xin đưa ra một "case study" thực tế như sau:

Một trang web của công ty vừa bị thâm nhập. Để bảo đảm bảo mật và uy tín của công ty, theo bạn, công ty ấy cần khai triển những gì và lý do tại sao?

Cho rằng (các phiên bản đưa ra ở đây hoàn toàn là ngẫu nhiên): trang web ấy chạy trên hệ điều hành Windows 2003, sử dụng IIS làm reverse proxy, Apache phiên bản 2.2.15, PHP phiên bản 5.3, sử dụng software thương mại là vBulletin có phiên bản 4.1.5 và cơ sở dữ liệu là mysql phiên bản 5.1. Tất cả các dịch vụ đều chạy trên cùng một máy chủ (dedicated server) và được firewall của ISP bảo vệ.

Vui lòng khai triển ở góc độ "forensics" để từ đó mới có thể đưa đến biện pháp.

Mời các bạn tham gia.

Hì hì, bác conmale đưa ra các phiên bản của HĐH và applications của một hệ thống một cách ngẫu nhiên mà dường như thấy "sát sàn sạt", nó đang gần giống như một hệ thống nào đó mới bị defaced và bị tấn công DDoS (hay chỉ là DoS thôi) và "sập tiệm".

Win 2K3 thì như đúng rồi, IIS hay nginx làm reverse proxy nhỉ, chắc là IIS?, PHP 5.3.x -có nên thêm con số x nào đấy vào cho thật cụ thể không? , Apache (Win32) thì có lẽ là 2.2.17 cho nó mới hơn, dù thế hiện cũng đã cũ. Thế hệ thống có cài ActivePerl không nhỉ? Các thứ khác thì xin OK!

Hì hì! chỉ giỡn đôi chút để làm các bạn vui thêm sau khi căng thẳng suy nghĩ về câu hỏi của anh conmale mà thôi!
----------------------
Nay xin quay về câu hỏi của anh conmale.

Trên đây có nhiều bạn đã trả lời với nhiều ý kiến. Có những ý kiến khá hay, đáng học hỏi. Nhưng có vẻ có những ý kiến hơi khái quát, hơi bao quát quá. Các giải pháp đưa ra có thể hay chỉ áp dụng như một nguyên tắc, nguyên lý, qui định chung về bảo mật hay khắc phục sự cố mà thôi.

Tôi xin bổ sung thêm một vài ý kiến nhỏ.

Ta giả dụ hệ thống bị defaced theo cách mà trang web webscan.bkav.com.vn bị defaced, nghĩa là hacker đặt đươc một file "hacked.html" vào thư mục gốc hay Documentroot của Apache, tức là của webserver và sau đó một vài ngày nó bị tấn công từ chôi dịch vụ và bị ngưng trệ trong nhiều ngay, dù có vẻ không có sự tham gia của một hệ thống botnet (DDoS zombies) trên mạng.

Điều quan trọng đâu tiên chúng ta phải xác định rõ cấu hình cụ thể của webserver vừa bị hack.
Trước tiên, loại HĐH mà webserver cài đặt là một yếu tố rất quan trọng cần phải xem xét. Win2k3 hay Windows OS nói chung có những điểm yếu rất khó khắc phục, tạo cơ hôi cho hacker thâm nhập. Vấn đề phải tìm xem hành đông hay hiện tượng thâm nhập vừa qua có liên quan đến điểm yếu nào của Win2K3 hay không?
Chú ý là việc update tự động các lỗ hổng bảo mật cho Windows thì MS làm khá tốt và dễ dàng. Vì vậy chỉ nên tập trung vào các lỗi mà admin của hệ thống bị hack chưa kip update, vì một lý do nào đó, hay lỗi mà MS chưa kịp ban hành bản vá lỗi trên mạng. Có rất ít hacker tim ra lỗi 0-day để hack.

Điểm thứ hai chúng ta phải xem xét đến phiên bản web server (trình quản lý web) được cài trong hệ thống. Ở đây là Apache(Win32)2.2.15. Apache không ban hành các bản vá lỗi tự động như MS cho Windows. Họ chỉ ban hành các phiên bản mới thay cho các phiên bản cũ có lỗi, có khả năng bị hack. Hiện nay đã là Apache 2.2.22 (released 2012-01-31). Chỉ cần tham khảo tài liệu của Apache là biết các lỗi của phiên bản cũ. Vấn đề chỉ còn là phải xác định hiện tượng và hành đông xâm nhập cụ thể của hacker vừa qua có liên quan đến các lỗi này không và đó là lỗi nào? (Tuy nhiên xác định được điều này không hề dễ dàng tí nào).

Điểm thứ 3, nhưng có khi lại là quan trọng nhất là các application được cài đặt trong hệ thống. Các application ở đây là PHP 5.3, MySQL 5.1, vBulletin 4.1.5.... Chú ý là các application mới là các nguyên nhân tạo ra nhiều lỗ hổng để cho hacker đột nhập hay defaced hệ thống. Một Application đươc cải tiến để tiện dụng hơn, có nhiều tính năng hơn thì lai càng có nhiều lỗ hổng hơn, đó là hậu quả, là "side effect", điển hình là PHP chẳng hạn.

Vì vậy nếu hiện tượng haker defaced website và để lai một file "hacked.html" ở root thì điều trước tiên ta phải nghĩ đến lỗi RFI (không phải "Đài phát thanh Pháp quốc" đâu nhé! Hì hì- mà là Remote file Inclusion vulnerability) hay LFI (Local File Inclusion). Lỗi này cho phép hacker đưa (upload) một file bẩn vào hệ thống từ xa và đặt nó ở directory hacker mong muốn. Vấn đề là admin của hệ thống đã không config. PHP (cụ thể là file php.ini) kỹ càng....(Các bạn ở BKAV cũng nên kiểm tra lai điều này). Chú ý là chỉ PHP đời mới sau này, như PHP 5.3.x, mới có lỗi này. Hì hì.

Tất nhiên một hệ thống Windows cài DotNet (.Net framework ) như hệ thống mà anh conmale đưa, cũng có lỗi RFI, nhưng khả năng hacker tận dụng lỗi này có vẻ ít hơn.
Chúng ta nhớ lai, trong đợt các hacker TQ defaced hàng loạt website của VN vừa qua, chúng cũng tận dụng lỗi nói trên (RFI). Ngược lai các hacker trẻ VN cũng làm giống như thế.

Cũng cần xác định rằng việc hacker defaced website như trường hợp webscan.bkav.com.vn thì không có nghĩa là hacker đã chiếm được quyền admin (lấy được password) của hệ thống đâu nhé. Khoảng cách đến đó nhiều trường hơp khá xa đấy.

Còn việc hệ thống bị tấn công từ chối dịch vụ và bị ngưng trệ trong thời gian dài mà không có sự tham gia cuả một hệ thống botnet trên mạng, thì thực tế có thể có đấy. Vấn đề là phải có hai yếu tố:
- Hacker phải dùng một DoS tool loại nào?
- Hệ thống phải cài các application nào để DoS tool này mới có thể phát huy tác dung? (Chỉ cần một hay hai hacker DoS trong một vài phút là hệ thống có thể ngưng trê nhiều giờ).Hệ thống mà anh conmale nói có cài các application ấy đấy. Tuy nhiên vấn đề này tôi xin nói sau, vì bài viết đã dài.

Chỉ khi xác định đươc cách thức tấn công cụ thể của hacker thì ta mới chặn được nó và có biện pháp hữu hiệu để phòng thủ.

"The Only Way To Stop A Hacker Is To Think Like One"

The absence of disagreement is not harmony, it's apathy.
(Socrates)
Honest disagreement is often a good sign of progress.
(Mahatma Gandhi)

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	23/02/2012 22:23:19 (+0700) \| #41 \| 254972

.lht.
Member

Joined: 26/09/2010 10:06:38
Messages: 75
Location: Inside you
Offline

Anh nói vậy mới làm em chợt nhận ra cái điểm quan trọng đó mà không nhớ đến từ đầu smilie

"The Only Way To Stop A Hacker Is To Think Like One"

Ở các ý kiến trước của mọi người đều chỉ nói đến khía cạnh của 1 quản trị chứ chưa đặt mình vào vị trí và suy nghĩ như attacker ...

Nếu đặt mình vào vị trí của attacker, có lẽ mọi chuyện trở lên dễ dàng hơn nhiều.

"Apache thì có sóng gió slowloris"
"PHP 5.3.9 thì dính RCE (remote code execution) và các phiên bản cũ hơn 5.3.9 thì DoS exploit."
"vBB 4.x.x thì có lỗi ở phần Search (SQL injection) - nếu dùng tài khoản root cho database thì khá nguy hiểm ... (rất hay gặp ở nhiều site lớn dùng server riêng)"
....

Trời ơi smilie

quá chú ý vào "phòng tránh" nên không nghĩ đến khía cạnh này ...
smilie

Trash from trash is the place for new good things ~

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	24/02/2012 09:46:41 (+0700) \| #42 \| 254989

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

Ngày xưa, khi HVA từng bị DDoS triền miên bất tận, có lúc bị hết luôn disk space. log daemon và apache chẳng còn chỗ để ghi logs. Những lúc ấy thật nguy hiểm. Nguy hiểm không những ở khía cạnh không còn lưu được logs cho công tác forensics mà còn nguy ở chỗ bị phân tán trong việc theo dõi và phòng bị bảo mật cho máy chủ. Mọi tài nguyên, thời gian và tâm lực chỉ đổ dồn vô chuyện chống đỡ ddos nên xao nhãng chuyện cập nhật bản vá, backup, kiện toàn bảo mật...v...v... Đó là bài học lớn xảy ra vào năm 2006 cho HVA.

What bringing us together is stronger than what pulling us apart.

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	24/02/2012 16:28:26 (+0700) \| #43 \| 255090

xnohat
Moderator

Joined: 30/01/2005 13:59:19
Messages: 1210
Location: /dev/null
Offline

Anh conmale, đồng chí weareanon đã cung cấp file thông tin về máy chủ của BKAV, theo em thì mình dùng nó bổ sung vô cái case study luôn đi, em đọc thấy trong đó có nhiều file đồng chí weareanon chưa hề phân tích ví dụ như cái file apache config đọc cũng khá lý thú, có bồ bên topic về vụ hack BKAV bên kia đã tìm ra là BKAV không hề dùng mod security chẳng hạn.

À mà như bác Mai đã nhận ra, khi đọc mấy cái file do bồ weareanon cung cấp, em thấy mấy cái giả định của anh trúng tới 95% smilie

iJust clear, "What I need to do and how to do it"/i
br
brBox tán gẫu dời về: http://www.facebook.com/hvaonline

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	24/02/2012 16:33:49 (+0700) \| #44 \| 255094

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

xnohat wrote:

Anh conmale, đồng chí weareanon đã cung cấp file thông tin về máy chủ của BKAV, theo em thì mình dùng nó bổ sung vô cái case study luôn đi, em đọc thấy trong đó có nhiều file đồng chí weareanon chưa hề phân tích ví dụ như cái file apache config đọc cũng khá lý thú, có bồ bên topic về vụ hack BKAV bên kia đã tìm ra là BKAV không hề dùng mod security chẳng hạn.

À mà như bác Mai đã nhận ra, khi đọc mấy cái file do bồ weareanon cung cấp, em thấy mấy cái giả định của anh trúng tới 95%

Hello em, anh thấy weareanon "mượn" nhà của HVA để post thông tin mà mình lại trưng thông tin của weareanon thì coi không được. Cho nên anh đã gởi PM cho bạn ấy để xin phép. Nếu weareanon đồng ý thì anh sẽ xúc tiến.

What bringing us together is stronger than what pulling us apart.

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	24/02/2012 17:09:54 (+0700) \| #45 \| 255100

xnohat
Moderator

Joined: 30/01/2005 13:59:19
Messages: 1210
Location: /dev/null
Offline

mình có trưng dữ liệu cá nhân gì của weareanon lên đâu anh, ý em là mình dùng cái này nè anh

http://www.mediafire.com/?h84wmv6zq7oh7ly

iJust clear, "What I need to do and how to do it"/i
br
brBox tán gẫu dời về: http://www.facebook.com/hvaonline

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	25/02/2012 08:40:45 (+0700) \| #46 \| 255200

PXMMRF
Administrator

Joined: 26/09/2002 07:17:55
Messages: 946
Offline

xnohat wrote:

Anh conmale, đồng chí weareanon đã cung cấp file thông tin về máy chủ của BKAV, theo em thì mình dùng nó bổ sung vô cái case study luôn đi, em đọc thấy trong đó có nhiều file đồng chí weareanon chưa hề phân tích ví dụ như cái file apache config đọc cũng khá lý thú, có bồ bên topic về vụ hack BKAV bên kia đã tìm ra là BKAV không hề dùng mod security chẳng hạn.

À mà như bác Mai đã nhận ra, khi đọc mấy cái file do bồ weareanon cung cấp, em thấy mấy cái giả định của anh trúng tới 95%

Chào xnohat

Mình không quen biết bạn weareanon và cho đến nay cũng chưa trao đổi với bạn ấy lần nào qua email, chat.... Tôi cho rằng bạn weareanon là một bạn có trình độ IT rất khá và trên mạng có cách trao đổi đúng mực, vừa phải, khôn khéo. Tuy nhiên tôi không có bình luận gì về mục đích hack vào BKAV forum của bạn ấy, hay bạn ấy có thưc sự là một thành viên của Anonymous và LulzSec Vietnam hay không? Cũng như thực sự đang có một tổ chức như vậy ở VN hay không.

Bài viết của tôi (phía trên, trong topic này) viết trước bài viết "Thông báo số 2" (gọi thế cho tiện) của bạn weareanon. Bài viết của tôi ngày 23/02/2012 15:30:43 (+0700) | #40 | 254947, còn bài "Thông báo số 2" của weareanon đăng trên HVA forum ngày 24/02/2012 12:03:15 (+0700) | #469 | 255001 (dường như weareanon cũng đăng tải nôi dung "Thông báo số 2" trên mạng vào cùng thời gian này)

Khi website webscan.bkav.com.vn bị defaced, tôi có trao đổi với gamma95, người tôi cho là rất thông minh, hiểu biết trong việc phân tích những sự kiện như thế này. Tôi ghi nhận, nhưng không hoàn toàn đồng ý với ý kiến của bạn ấy. Ý kiến riêng của tôi, thì đã trình bầy một phần ở post trên.

Dù khá bận công việc (liên quan đến việc nhân GT Nhà nước về KH&CN 2010), tôi vẫn bỏ một phần thời gian "nghiên cứu-tìm hiểu" về các website-hệ thống của BKAV vừa bị hack. Dĩ nhiên là tìm hiểu theo cách của người làm bảo mật, không phải là thâm nhập-hacking vào bên trong hệ thống. Tôi cũng chỉ tìm hiểu về werbserver-hệ thống webscan.bkav.com.vn, chứ không về forum.bkav.com.vn. Tuy nhiên các hệ thống khác nhau của BKAV lai có cấu hình khá giống nhau, trên nền tảng: Win2K3-Apache(Win32)-PHP 5.3.x-MySQL... vân vân (xin không viết hết cả ra).

Từ cách deface website BKAV của hacker vào trang webscan.bkav.com.vn và chi tiết cấu hình của webserver, băng kinh nghiệm bản thân, tôi đoán cách thức cụ thể hacker deface website của BKAV cũng như cách thức hacker tấn công từ chối dịch vụ (DoS- chứ dường như không phải DDoS) rất hiệu quả vào webserver này, vài ngày sau đó.

Về nôi dung bản "Thông báo số 2" của bạn weareanon tôi còn có những thắc mắc và nghĩ ngợi. Tất nhiên BKAV không chỉ mắc những lỗi mà weareanon đã nêu, mà còn những lỗi khác, thí dụ các lỗi liên quan đến việc config. Apache trên file httpd.conf. Nhưng cũng chính nôi dung config. Apache của BKAV (mà weareanon dẫn ra) lại có những điểm lạ, ít nhất được coi là khó hiểu hay có chút mâu thuẫn. Có thời gian ta sẽ bàn thêm việc này.

Tôi muốn lưu ý về cách thức tấn công từ chối dịch vụ của các hacker vào hệ thống của BKAV vừa qua. Theo tôi đây là một cách tấn công mới, rất hiệu quả, chỉ cần rất ít người tham gia, không cần một mạng botnet to lớn, mà việc tạo lập nó vốn rất mất công và việc kiểm soát bot net rất dễ tuột khỏi tay hacker. (như trường hợp vừa qua khá nhiều mạng botnet của STL đã bị huỷ diệt hay mất đi sự được kiểm soát, sau khi anh TQN và một số thành viên HVA khác RCE các malicious codes của botnets và các International Antivirus Co. kịp thời cập nhật chương trình diệt virus của họ).

Có thể các cuộc tấn công DoS của hacker vào BKAV forum đã đánh đúng vào "gót chân Achilles" của hệ thống, gây ra bởi chính một số application cài đặt trong nó. Theo tôi, đây là vấn đề quan trọng, liên quan đến mạng truyền thông quốc gia, cộng đồng, mà HVA chúng ta cần lưu ý, có những cảnh báo, hướng dẫn giúp công đống cách thức phòng thủ hay khắc phục, trong thời gian tới

The absence of disagreement is not harmony, it's apathy.
(Socrates)
Honest disagreement is often a good sign of progress.
(Mahatma Gandhi)

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	25/02/2012 10:20:32 (+0700) \| #47 \| 255228

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

xnohat wrote:

mình có trưng dữ liệu cá nhân gì của weareanon lên đâu anh, ý em là mình dùng cái này nè anh

http://www.mediafire.com/?h84wmv6zq7oh7ly

À, anh lại nghĩ là ý em khai triển theo góc độ điều tra dấu vết ở những biên độ khác. Trong trường hợp này, dấu vết weareanon có thể tiết lộ là dấu vết anh ta đã post bài trên diễn đàn HVA. Thông thường kẻ tấn công luôn luôn tìm hiểu kết quả những việc mình đã làm, thậm chí công bố việc mình đã làm vì một lý do nào đó. Anh thấy đây cũng là một góc độ khai triển, bởi vậy anh đã xin phép weareanon qua PM như sau:

conmale wrote:

Tôi đường đột gởi PM này để xin phép bạn sử dụng một số thông tin đăng nhập của bạn được lưu trên log của diễn đàn đó là IP address và User-Agent để làm case study cho thành viên diễn đàn. Tôi xét thấy những thông tin ấy hoàn toàn anonymous và là những thông tin khá lý thú nên mới gởi bạn đề nghị này.

Rất mong bạn xem xét và hồi âm.

Cảm ơn.

và weareanon đã trả lời hôm nay như sau:

Thưa ngài,

Đầu tiên, chúng tôi thành thực cám ơn sự giúp đỡ của ngài và các quản trị viên đối với sự vụ của chúng tôi.
Lời đề nghị của ngài, chúng tôi thấy đây là một yêu cầu xác đáng, vì chúng tôi tin tưởng ngài với sự am tường kỹ nghệ máy tính rất chuyên sâu, sẽ có thể dùng các thông tin ấy một cách hiệu quả và tránh được cho chúng tôi các sự cố đáng tiếc. Do đó chúng tôi rất hoan hỉ nếu có thể giúp ngài được chút gì đó hữu ích.

Thân chào ngài và chúc ngài nhiều sức khoẻ,
Kính thư
weareanon

He he, cách viết và cách trả lời của weareanon hơi lạ (gần giống như người ngoại quốc dịch tiếng ngoại quốc sang tiếng Việt smilie

) nhưng quan trọng là anh ấy đã đồng ý. Bởi thế, anh sẽ tán 1 bài khai triển theo góc độ này.

What bringing us together is stronger than what pulling us apart.

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	25/02/2012 15:27:55 (+0700) \| #48 \| 255399

cino
Member

Joined: 29/11/2010 00:50:44
Messages: 37
Offline

conmale wrote:

Khi nói đến điểm b, chúng ta nói đến khả năng máy chủ kia hoàn toàn không có cơ chế bảo vệ mà chỉ phụ thuộc vào "dịch vụ bảo vệ" mà ISP cung cấp. Đây có thể là sự trông cậy chết người mà chủ nhân của máy chủ ấy vướng phải. Chẳng có gì bảo đảm rằng hệ thống bảo vệ của ISP chặt chẽ và đúng với nhu cầu và cấu hình thực tế trên cái dedicated server này. Firewall, IPS, IDS..v...v... không thể hoàn toàn lấp được những lỗi và những tắc trách trong cấu hình. Đó là chưa kể khi đụng tình huống, liệu ISP có lưu giữ những thông tin cần thiết cho mục đích forensics hay không?

Điểm c giúp ta xác định các vectors có thể (Windows 2003, Apache, IIS, PHP, vBB, Mysql). Đây có lẽ là những mảnh thông tin rõ ràng nhất và dễ dàng nhất (bug-track everyone? ) nhưng cũng là mảnh cần nhiều thời gian để phân tích logs, điều tra các lỗ hổng ..v..v....

Chào bác,

Em có một số khúc mắc nho nhỏ:

Ở điểm b của bác, xét đến việc có được ISP ra tay bảo vệ hay chưa và hoàn toàn không tin tưởng vào sự bảo vệ này thì liệu điểm này có liên quan tới chủ đề đang "study" hay không?

Ở c, nếu logs hoàn toàn bị xoá (vì chỉ nằm trên 1 server) thì có phải việc giám định bị đi vào ngõ cụt không?

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	25/02/2012 17:25:05 (+0700) \| #49 \| 255432

LeVuHoang
HVA Friend

Joined: 08/03/2003 16:54:07
Messages: 1155
Offline

conmale wrote:

xnohat wrote:

mình có trưng dữ liệu cá nhân gì của weareanon lên đâu anh, ý em là mình dùng cái này nè anh

http://www.mediafire.com/?h84wmv6zq7oh7ly

À, anh lại nghĩ là ý em khai triển theo góc độ điều tra dấu vết ở những biên độ khác. Trong trường hợp này, dấu vết weareanon có thể tiết lộ là dấu vết anh ta đã post bài trên diễn đàn HVA. Thông thường kẻ tấn công luôn luôn tìm hiểu kết quả những việc mình đã làm, thậm chí công bố việc mình đã làm vì một lý do nào đó. Anh thấy đây cũng là một góc độ khai triển, bởi vậy anh đã xin phép weareanon qua PM như sau:

conmale wrote:

Tôi đường đột gởi PM này để xin phép bạn sử dụng một số thông tin đăng nhập của bạn được lưu trên log của diễn đàn đó là IP address và User-Agent để làm case study cho thành viên diễn đàn. Tôi xét thấy những thông tin ấy hoàn toàn anonymous và là những thông tin khá lý thú nên mới gởi bạn đề nghị này.

Rất mong bạn xem xét và hồi âm.

Cảm ơn.

và weareanon đã trả lời hôm nay như sau:

Thưa ngài,

Đầu tiên, chúng tôi thành thực cám ơn sự giúp đỡ của ngài và các quản trị viên đối với sự vụ của chúng tôi.
Lời đề nghị của ngài, chúng tôi thấy đây là một yêu cầu xác đáng, vì chúng tôi tin tưởng ngài với sự am tường kỹ nghệ máy tính rất chuyên sâu, sẽ có thể dùng các thông tin ấy một cách hiệu quả và tránh được cho chúng tôi các sự cố đáng tiếc. Do đó chúng tôi rất hoan hỉ nếu có thể giúp ngài được chút gì đó hữu ích.

Thân chào ngài và chúc ngài nhiều sức khoẻ,
Kính thư
weareanon

He he, cách viết và cách trả lời của weareanon hơi lạ (gần giống như người ngoại quốc dịch tiếng ngoại quốc sang tiếng Việt ) nhưng quan trọng là anh ấy đã đồng ý. Bởi thế, anh sẽ tán 1 bài khai triển theo góc độ này.

Anh conmale, em nghĩ đây là sự cố tình của các bạn ấy. Trong Món quà số 2, cách hành văn không hề giống như vầy. Giả thuyết đưa ra có thể là để tránh tìm hiểu về văn phong, các bạn ấy có thể đưa qua 1 translator machine rồi chỉnh sửa lại?

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	25/02/2012 22:24:21 (+0700) \| #50 \| 255503

K4i
Moderator

Joined: 18/04/2006 09:32:13
Messages: 635
Location: Underground
Offline

Em cũng đang có nhận định giống anh LeVuHoang. Nếu so sánh văn phong từ Thông báo số 1 - Thông báo số 2 - Bức thư ngày hôm nay thì dường như có việc có sử dụng machine translator trong thông báo số 2 và Bức thư gửi C50.

Sống là để không chết chứ không phải để trở thành anh hùng

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	26/02/2012 13:15:41 (+0700) \| #51 \| 255570

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

Hôm trước tớ có PM xin phép weareanon dùng một số thông tin có lưu trên logs của HVA để tiếp tục khai triển case study này và đã được anh ấy đồng ý. Hôm nay, tớ xin khai triển thêm một tí ở góc độ này.

Thông thường, perpetrator nếu tinh ranh và kinh nghiệm, hắn ta sẽ xoá logs, xoá hết tất cả các dấu vết thâm nhập trên mục tiêu. Tuy nhiên, đến một lúc nào đó, nếu cần công bố thông tin, hắn vẫn phải dùng một phương tiện nào đó để thực hiện ý định công bố ấy. Trong trường hợp weareanon, anh chàng đã chọn HVA làm nơi tung ra thông điệp đầu tiên và tất nhiên, trên logs của HVA sẽ ghi nhận lại một số thông tin. Ví dụ:

109.163.233.201 - - [24/Feb/2012:01:56:48 -0600] "GET /hvaonline/posts/list/41282.html HTTP/1.1" 200 13964 "/hvaonline/forums/show/19.html" "Mozilla/5.0 (Windows; U; X11; Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0"

Thoạt nhìn thì thấy không có gì lạ, nhưng nhìn kỹ thì User-Agent này là vừa Windows, lại vừa Unix. Theo specs của Mozilla thì User-Agent trên bất hợp lệ về mặt cú pháp. Không thể nào trình duyệt này vừa có signature cho OS là vừa Windows mà lại vừa Unix smilie

.

Tuy nhiên, điều thú vị hơn là sau hơn 10 phút, nó lại trở thành:

109.163.233.201 - - [24/Feb/2012:02:10:50 -0600] "GET /hvaonline/posts/list/480/41193.html HTTP/1.1" 200 13808 "/hvaonline/forums/list.html" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.20) Gecko/25250202 BTRS35926 Firefox/2.0.0.20 (.NET CLR 3.5.30729)"

Ở đây, User-Agent đột ngột thay đổi và User-Agent này có điểm buồn cười là trên đời này không có cái gì là "Gecko/25250202" hết.

IP 109.163.233.201 được resolved thành wau2.torservers.net và nó thuộc một Class C của mạng 109.163.233.192/28 do ZWIEBELFREUNDE quản lý. Đây là một t0r node khá phổ biến (trong hơn 2 ngàn nodes). Điều này có nghĩa mỗi ngày phải có hàng TB traffic đi xuyên qua nó.

Giả sử an ninh mạng của một quốc gia liên hệ với quản lý của mạng ZWIEBELFREUNDE và yêu cầu cung cấp thông tin truy cập của nguồn IP nguyên thuỷ đến t0r node có IP là 109.163.233.201. Nếu mạng này có log lại đầy đủ thông tin nguồn IP nguyên thuỷ nào đó truy cập đến 109.163.233.201 thì ngay cả việc trace và correlate access từ nguồn IP nguyên thuỷ là một việc không đơn giản tí nào. Tuy nhiên, đây là chuyện hầu như không thể vì chẳng có mạng nào có thể log tất cả mọi packets cho công tác audit, hơn nữa đây là mạng đại trà chớ chẳng phải là mạng thuộc hệ thống tài chính hay chính phủ cho nên không có policy logging như vậy. Hơn nữa, không phải vô cớ mà "ZWIEBELFREUNDE" lại có slogan là “Friends of the Onion”, nơi security, privacy và anonymity được bảo vệ. Tình hình có lẽ còn phải gay go hơn nếu perpetrator dùng một private VPS hoặc anonymous VPN nào đó trước khi access t0r network.

Để điều tra cấp độ này và để có sự hợp tác rộng rãi giữa các quốc gia và các ISP có lẽ phải cần đến criminals loại international bởi vì mỗi ngày cyber frauds có hàng ngàn cases thì làm sao có đủ ưu tiên và nhân lực để truy tìm t0r users cho mấy cái deface vớ vẩn?

Quay lại hai cái ví dụ trên (trong hàng trăm requests có cùng IP như vậy), chúng ta thấy chẳng có gì bảo đảm request của ví dụ một và ví dụ hai thuộc về một người dùng hay hai người dùng hết. Nếu có 2 hoặc 100 người dùng sử dụng t0r và được t0r network randomly gán cho cái "gateway" có cùng IP address như trên thì đúng là bó tay vì đằng sau nó có thể có hàng trăm IP khác.

Forensics ở khía cạnh này nói lên điều gì? Nó nói lên rằng, đôi khi perpetrator cẩn thận việc xoá dấu vết ngay tại hiện trường nhưng lại thiếu cẩn thận hoặc chủ quan khi tung lên thông tin thì công tác xoá dấu vết kia hoá ra vô ích và bởi thế, việc điều tra đôi khi trở nên hết sức đơn giản và dễ dàng (tất nhiên là HVA hoặc nơi nào đó mà perpetrator chọn để thông tin phải cung cấp cho nhóm điều tra thông tin đầu tiên, đó là thông tin về IP 109.163.233.201).

What bringing us together is stronger than what pulling us apart.

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	26/02/2012 15:41:34 (+0700) \| #52 \| 255586

.lht.
Member

Joined: 26/09/2010 10:06:38
Messages: 75
Location: Inside you
Offline

Có 1 ý tưởng thật "ngớ ngẩn" nhưng cũng thật "thú vị" để chơi trò "may rủi" thu nhỏ phạm vi đối tượng tình nghi hoặc nếu "may" có thể tóm gọn attacker nếu attacker "không cẩn thận".

Từ cái IP và những "thông tin liên quan" mà anh conmale cung cấp, BKAV có thể "giăng 1 cái lưới" để "bắt" những "con cá ngu ngơ".

Ở đây giả dụ ta đặt tình huống là attacker vẫn tiếp tục sử dụng IP đó hoặc thậm chí attacker không sử dụng IP đó nữa nhưng vẫn dùng Tor và những nodes khác của Tor để tiếp tục truy cập và nghe ngóng ở BKAV.

Nếu ta đặt mình vào vị trí attacker, 1 kẻ khôn ngoan sẽ chọn những node "phổ biến, truy cập khá và nhanh".

Attacker: Vậy bạn có cách gì để thu hẹp phạm vi đối tượng ? ...
Me: Vâng, chính sự thông minh, khôn khéo đó đôi khi sẽ hại bạn ! smilie

Attacker: Tại sao ?
Me: Vì bạn để lộ thông tin bạn dùng Tor smilie

Attacker: Để lộ thông tin dùng Tor thì làm sao chứ ?
Me: Bạn dùng Tor và chính Tor nó hại bạn smilie

Attacker: Tor thì hại gì chứ ?
Me: Phiền bạn ghé qua đây smilie

https://check.torproject.org/?lang=vi

Attacker: Opp ...
Me: Vâng, bản thân Tor nó có công cụ nhận dạng xem bạn có đang sử dụng Tor hay không. Vậy mấy bác bên BKAV cũng tạo 1 công cụ kiểm tra các IP truy cập đến đó có thuộc đám "con cháu" của Tor không thì sẽ giới hạn được phạm vi.

Attacker: Ah ừ ... biết tôi dùng Tor rồi thì làm được gì nữa ? Hàng trăm hàng ngàn người khác cũng đang sử dụng Tor và cùng thông qua 1 IP như tôi mà smilie

Bạn cứ đùa smilie

Me: Vâng, nhưng không mấy ai lại trùng hợp cùng truy cập vào những site của BKAV cả :-"

Attacker: smilie

Cứ cho là thế đi, nhưng tìm ra được tôi "hơi bị khó đấy" !
Me: Chỉ là vấn đề thời gian thôi, nếu bạn vẫn "theo đường cũ" ....

Attacker: Là sao smilie

?
Me: Bạn nghĩ sao khi mà BKAV khi phát hiện bạn dùng Tor, họ sẽ tiến hành theo dõi bạn ?

Attacker: Theo dõi sao ?
Me: Khi biết bạn dùng Tor, họ sẽ lưu lại cái IP hiện hành vào Cookie của các trang web BKAV mà bạn truy cập . Sau đó những lần truy cập sau, cái cookie đó được lôi ra so sánh và cái IP trong đó được lôi ra để so sánh với những IP tiếp theo ở những lần truy cập tiếp theo ...

Attacker: .....
Me: Và cứ như vậy, họ tiến dần đến bạn smilie

Chỉ 1 sơ hở rất nhỏ, bạn đã nằm trong lưới như 1 con cá rồi smilie

............................

Trash from trash is the place for new good things ~

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	26/02/2012 17:13:23 (+0700) \| #53 \| 255591

phanledaivuong
Member

Joined: 23/05/2008 17:34:21
Messages: 315
Location: /dev/null
Offline

.lht. wrote:

Attacker: Opp ...
Me: Vâng, bản thân Tor nó có công cụ nhận dạng xem bạn có đang sử dụng Tor hay không. Vậy mấy bác bên BKAV cũng tạo 1 công cụ kiểm tra các IP truy cập đến đó có thuộc đám "con cháu" của Tor không thì sẽ giới hạn được phạm vi.

Cứ dùng firefox change user-agent và các công cụ Tor, ... để post bài lên HVA.
Dùng IE or Chrome vào BKAV.

Bạn trả lời hộ mình: Tại sao vào BKAV phải dùng Tor?
Chỉ có cu cậu vụ handheld.vn mới dùng account lừa đảo để post bài: Catch me if you can. Sau đó login vào acc thật để đọc bài thôi. Chứ nếu thằng gây án là mình thì luôn luôn là gây án xong rồi mất tích. Không bao giờ quay lại hiện trường, chỉ có trà đá và nghe ngóng tình hình.

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	26/02/2012 19:49:12 (+0700) \| #54 \| 255610

xnohat
Moderator

Joined: 30/01/2005 13:59:19
Messages: 1210
Location: /dev/null
Offline

.lht. wrote:

Có 1 ý tưởng thật "ngớ ngẩn" nhưng cũng thật "thú vị" để chơi trò "may rủi" thu nhỏ phạm vi đối tượng tình nghi hoặc nếu "may" có thể tóm gọn attacker nếu attacker "không cẩn thận".

Từ cái IP và những "thông tin liên quan" mà anh conmale cung cấp, BKAV có thể "giăng 1 cái lưới" để "bắt" những "con cá ngu ngơ".

Ở đây giả dụ ta đặt tình huống là attacker vẫn tiếp tục sử dụng IP đó hoặc thậm chí attacker không sử dụng IP đó nữa nhưng vẫn dùng Tor và những nodes khác của Tor để tiếp tục truy cập và nghe ngóng ở BKAV.

Nếu ta đặt mình vào vị trí attacker, 1 kẻ khôn ngoan sẽ chọn những node "phổ biến, truy cập khá và nhanh".

Attacker: Vậy bạn có cách gì để thu hẹp phạm vi đối tượng ? ...
Me: Vâng, chính sự thông minh, khôn khéo đó đôi khi sẽ hại bạn !

Attacker: Tại sao ?
Me: Vì bạn để lộ thông tin bạn dùng Tor

Attacker: Để lộ thông tin dùng Tor thì làm sao chứ ?
Me: Bạn dùng Tor và chính Tor nó hại bạn

Attacker: Tor thì hại gì chứ ?
Me: Phiền bạn ghé qua đây https://check.torproject.org/?lang=vi

Attacker: Opp ...
Me: Vâng, bản thân Tor nó có công cụ nhận dạng xem bạn có đang sử dụng Tor hay không. Vậy mấy bác bên BKAV cũng tạo 1 công cụ kiểm tra các IP truy cập đến đó có thuộc đám "con cháu" của Tor không thì sẽ giới hạn được phạm vi.

Attacker: Ah ừ ... biết tôi dùng Tor rồi thì làm được gì nữa ? Hàng trăm hàng ngàn người khác cũng đang sử dụng Tor và cùng thông qua 1 IP như tôi mà Bạn cứ đùa
Me: Vâng, nhưng không mấy ai lại trùng hợp cùng truy cập vào những site của BKAV cả :-"

Attacker: Cứ cho là thế đi, nhưng tìm ra được tôi "hơi bị khó đấy" !
Me: Chỉ là vấn đề thời gian thôi, nếu bạn vẫn "theo đường cũ" ....

Attacker: Là sao ?
Me: Bạn nghĩ sao khi mà BKAV khi phát hiện bạn dùng Tor, họ sẽ tiến hành theo dõi bạn ?

Attacker: Theo dõi sao ?
Me: Khi biết bạn dùng Tor, họ sẽ lưu lại cái IP hiện hành vào Cookie của các trang web BKAV mà bạn truy cập . Sau đó những lần truy cập sau, cái cookie đó được lôi ra so sánh và cái IP trong đó được lôi ra để so sánh với những IP tiếp theo ở những lần truy cập tiếp theo ...

Attacker: .....
Me: Và cứ như vậy, họ tiến dần đến bạn Chỉ 1 sơ hở rất nhỏ, bạn đã nằm trong lưới như 1 con cá rồi

............................

Xuất sắc, ý tưởng này thực sự rất khả thi. Vì hacker có thể chỉ sử dụng tor khi tấn công, còn khi quay trở lại, hắn có thể không sử dụng tor mà là IP thật, khi đó thì cái cookie sẽ tố cáo hắn.

iJust clear, "What I need to do and how to do it"/i
br
brBox tán gẫu dời về: http://www.facebook.com/hvaonline

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	26/02/2012 21:49:43 (+0700) \| #55 \| 255621

LeVuHoang
HVA Friend

Joined: 08/03/2003 16:54:07
Messages: 1155
Offline

Bác này quên là có cái Tor Bundled smilie

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	26/02/2012 22:32:21 (+0700) \| #56 \| 255628

.lht.
Member

Joined: 26/09/2010 10:06:38
Messages: 75
Location: Inside you
Offline

Thật ra đó chỉ là 1 ý tưởng đơn giản.

Để đạt kết quả tốt hơn cũng có thể kiểm tra hoặc thu thập thêm các thông tin liên quan trên client có thể rồi tiến hành sàng lọc.
Và trong quá trình nghe ngóng tình hình, tâm lý của bạn attacker sẽ có khi quay trở lại. Và ai dám chắc là bạn ý sử dụng Tor mãi ?

Ngoài ra, 1 kĩ thuật nâng cao hơn :

Javascript có thể sử dụng để tạo custom cookie. Thử nghĩ đơn giản thế này: Tại sao ta không lợi dụng javascript để moi móc thêm thông tin ngay trên client và gửi ngược lại lên server ?

- Ví dụ với javascript, ta có thể lấy được thời gian hệ thống của client (từ đó biết được bạn ý đang thuộc "zone" nào)!
- Với javascript, ta có thể lấy được user-agent của trình duyệt.

Đó là còn chưa kể, ngoài javascript thì còn có flash, java là những loại script chạy phía client !

...

phanledaivuong wrote:

.lht. wrote:

Attacker: Opp ...
Me: Vâng, bản thân Tor nó có công cụ nhận dạng xem bạn có đang sử dụng Tor hay không. Vậy mấy bác bên BKAV cũng tạo 1 công cụ kiểm tra các IP truy cập đến đó có thuộc đám "con cháu" của Tor không thì sẽ giới hạn được phạm vi.

Cứ dùng firefox change user-agent và các công cụ Tor, ... để post bài lên HVA.
Dùng IE or Chrome vào BKAV.

Bạn trả lời hộ mình: Tại sao vào BKAV phải dùng Tor?
Chỉ có cu cậu vụ handheld.vn mới dùng account lừa đảo để post bài: Catch me if you can. Sau đó login vào acc thật để đọc bài thôi. Chứ nếu thằng gây án là mình thì luôn luôn là gây án xong rồi mất tích. Không bao giờ quay lại hiện trường, chỉ có trà đá và nghe ngóng tình hình.

Hì, bạn đọc chưa kĩ rồi smilie

[Edited vì hiện giờ 1 số ý tưởng trong này không xác thực nữa vì nó liên quan đến các exploits của browser]

Trash from trash is the place for new good things ~

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	26/02/2012 23:37:08 (+0700) \| #57 \| 255634

al0nex
Member

Joined: 31/05/2009 23:35:40
Messages: 17
Offline

tor cũng ko thực sự an toàn. Nếu xét 1 vụ việc thì ko nên quên "chi phí điều tra" ..

- với vụ BKAV thì phải xem bkav có chịu "chi" cho vụ điều tra này ko đã smilie

. BKAV liệu có bỏ chi phí ra lục tung internet lên chăng. VD: như kiểu: VPS>>VPN>>Tor>>BKAV site smilie

. Với kết nối mạng như trên ! bkav khó lòng theo đuổi vụ việc đến tận cùng smilie

Lí do: chi phí điều tra đem so sánh với cái lợi khi bắt dc "hacker" quả là khập khiễng smilie

...

- với những vụ "tầm cỡ" & bên nguyên chịu "chi" thì ko khó để tìm ra thủ phạm smilie

(phục thuộc nhiều yếu tố khác nữa)

- nếu có gì sai mong các bác cứ ném đá smilie

------------------------------------------

Nếu đứng theo góc độ bảo mật thì theo ngu í của em nên làm như sau:

1. Khi xác nhận bị Attack => cách li server smilie

2. Thông báo cho toàn bộ hệ thống & những bên liên quan

3. Ước tính thiệt hại & khắc phục sự cố :

- nêu ra những thông tin nào đã bị attacker lấy cắp (database, password, v..v.v.v.v)
- thông báo cách khắc phục sự cố cho những bên liên quan (ở đây là member: change password .v.v.)

4. Truy tìm thủ pham:
- xem phân tích tỉ mỉ log server
- dựa vào thông tin ghi lại trên server xác định bug mà attacker đã dùng để tấn công => xử lí bug smilie

- xác định thông tin Attacker (IP, time of attack, user agent .v.v.vv.)
- từ đó khoanh vùng đối tượng => đưa ra cách xử lí tốt nhất L)

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	27/02/2012 02:26:05 (+0700) \| #58 \| 255640

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

.lht. wrote:

Thật ra đó chỉ là 1 ý tưởng đơn giản.

Để đạt kết quả tốt hơn cũng có thể kiểm tra hoặc thu thập thêm các thông tin liên quan trên client có thể rồi tiến hành sàng lọc.
Và trong quá trình nghe ngóng tình hình, tâm lý của bạn attacker sẽ có khi quay trở lại. Và ai dám chắc là bạn ý sử dụng Tor mãi ?

Ngoài ra, 1 kĩ thuật nâng cao hơn :

Javascript có thể sử dụng để tạo custom cookie. Thử nghĩ đơn giản thế này: Tại sao ta không lợi dụng javascript để moi móc thêm thông tin ngay trên client và gửi ngược lại lên server ?

- Ví dụ với javascript, ta có thể lấy được thời gian hệ thống của client (từ đó biết được bạn ý đang thuộc "zone" nào)!
- Với javascript, ta có thể lấy được user-agent của trình duyệt.

Đó là còn chưa kể, ngoài javascript thì còn có flash, java là những loại script chạy phía client !

...

phanledaivuong wrote:

.lht. wrote:

Attacker: Opp ...
Me: Vâng, bản thân Tor nó có công cụ nhận dạng xem bạn có đang sử dụng Tor hay không. Vậy mấy bác bên BKAV cũng tạo 1 công cụ kiểm tra các IP truy cập đến đó có thuộc đám "con cháu" của Tor không thì sẽ giới hạn được phạm vi.

Cứ dùng firefox change user-agent và các công cụ Tor, ... để post bài lên HVA.
Dùng IE or Chrome vào BKAV.

Bạn trả lời hộ mình: Tại sao vào BKAV phải dùng Tor?
Chỉ có cu cậu vụ handheld.vn mới dùng account lừa đảo để post bài: Catch me if you can. Sau đó login vào acc thật để đọc bài thôi. Chứ nếu thằng gây án là mình thì luôn luôn là gây án xong rồi mất tích. Không bao giờ quay lại hiện trường, chỉ có trà đá và nghe ngóng tình hình.

Hì, bạn đọc chưa kĩ rồi

[Edited vì hiện giờ 1 số ý tưởng trong này không xác thực nữa vì nó liên quan đến các exploits của browser]

Thật ra perpetrator đã cố tình ẩn thì những ứng dụng client-side khó phát huy được tác dụng. Cho dù có tác dụng đi chăng nữa, đây cũng là tình trạng đã xảy ra và tư duy của mình cứ tự động đi ngược lại vị trí "phòng thủ" smilie

. Giả sử nạn nhân bị tấn công quyết định từ rày về sau sẽ log tối đa thông tin (trên mọi tầng) để có thông tin cho forensics trong tình huống bị thâm nhập, chính nạn nhân ấy tự tạo cho mình một khó khăn mới và khó khăn này không phải nhỏ, đó là: tài nguyên (chỗ chứa, băng thông để chuyển tải dữ liệu đã log) và thời gian + nhân lực để thường xuyên theo dõi và phân tích dữ liệu thu thập được.

Nói thêm một tí về sự hạn chế của các ứng dụng "client-side" để thu thập thông tin. Ứng dụng "client-side" hoàn toàn nằm trên tầng application và chúng khó lòng thu thập được những thông tin có giá trị để sử dụng cho forensics. Giả sử perpetrator sử dụng L2IPsec VPN thì làm sao các ứng dụng client side thu thập được IP thật? Gay go hơn nữa, nếu perpetrator dùng một máy ảo (trên VMware, VirtualBox...) và dù có thu thập thông tin cỡ nào đi chăng nữa cũng chỉ toàn là thông tin thuộc máy ảo.

Theo anh thấy, social engineering trong những trường hợp này khả thi hơn là khai triển với góc độ kỹ thuật. Cá nhân anh thì anh thấy rất tởm những trò social engineering bởi vì những trò này xét cho cùng là những trò nói láo để dụ nai smilie

nhưng phải nói là để điều tra thì nó là một thứ công cụ không thể xem thường. Social engineering càng dễ dàng hơn khi Internet càng ngày càng có nhiều những phương tiện giao lưu, các mạng xã hội, gởi mail ở dạng forged.... Ngay cả môt trò kích thích tò mò bằng cách tung ra một tin gì đó giât gân để thu hút sự chú ý để thu thập thông tin những trình duyệt truy cập và từ đó thu hẹp biên độ tìm kiếm (thông thường hiếm ai obsfucated "signature" của mình khi duyệt những trang tin tức phổ biến).

Nói tóm lại, chỉ có mấy ông amateur tưởng mình là đại cao thủ (sau khi dùng một mớ tool có sẵn) nhưng không nắm những khái niệm cover-track đúng mức (trong khi thâm nhập, sau khi thâm nhập và trong quá trình tung ra thông tin sau đó) thì mới bị tóm một cách dễ dàng.

What bringing us together is stronger than what pulling us apart.

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	27/02/2012 07:12:40 (+0700) \| #59 \| 255651

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

Nhân mrro đề cập đến tính "an toàn" của t0r bên topic kia và một số anh em cũng đề cập đến mảng này, tớ thử "t0r" và capture một "case".

Mô hình tớ thử t0r trong case này như sau:

VMware Linux (with t0r client) ---> Mac OS host --> Linux Firewall ---> Internet ---> hvaonline.net site.

1. Trên VMware chạy Linux, sau khi enable t0r client, tớ thử liệt kê netstat -nat thì thấy có kết quả sau:

tcp 0 0 127.0.0.1:49195 127.0.0.1:9051 ESTABLISHED
tcp 0 0 127.0.0.1:9051 127.0.0.1:49195 ESTABLISHED
tcp 0 0 192.168.41.196:39646 171.25.193.20:443 ESTABLISHED
tcp 0 0 192.168.41.196:40618 38.229.70.53:443 ESTABLISHED
tcp 0 0 192.168.41.196:50637 146.185.23.180:443 ESTABLISHED

trong đó,
- cổng 9051 chính là cổng "Control Port" của t0r trên chính VMWare Linux.
- các IP 171.25.193.20, 38.229.70.53 và 146.185.23.180 trên cổng 443 là các t0r relay servers.

Các t0r relay servers này có thể thay đổi thường xuyên.

Trên VMware Linux box này, tớ access và capture packets xuyên qua cổng 443 bằng tcpdump. Mặc dù tớ duyệt là qua cổng 80 bình thường nhưng vì t0r client đẩy traffic xuyên qua cổng 443 của t0r network cho nên sniff trên cổng 80 sẽ không có thông tin gì hết.

Packets được sniff trên cổng 443 ngay trên VMware Linux box như sau:

Các bạn cũng thấy, IP 192.168.41.196 là private IP của chính VMware Linux box và IP 171.25.193.20 là IP của t0r relay server. Nếu client bị sniff trong trường hợp này, cùng lắm chỉ thấy được có traffic từ localhost này đi đến 1 trong vài ngàn t0r relay servers nhưng không thấy được gì khác vì payload hoàn toàn được mã hoá bằng TLS 1.0 (ngoại trừ...):

2. Trên Mac OS host, nếu chạy netstat, tớ sẽ thấy các connections:
tcp4 0 0 172.17.1.205.52763 146.185.23.180.443 ESTABLISHED
tcp4 0 0 172.17.1.205.52676 38.229.70.53.443 ESTABLISHED
tcp4 0 0 172.17.1.205.52674 171.25.193.20.443 ESTABLISHED

cái này là do VMware chạy Linux sử dụng NAT (cho network) trên VMware và trên Mac OS host, nó làm việc như chính nó đang connect đến các t0r relay servers.

Thử sniff trên Mac OS host, tớ thấy:

trong đó,

- 172.17.1.205 chính là private IP của máy Mac OS host
- 171.25.193.20 cũng chính là IP của một trong nhiều ngàn t0r relay IP.

Cũng như trên VMware, traffic này hoàn toàn được encrypted (TLS 1.0).

3. Trên Linux Firewall cũng tương tự như trên.

4. Trên hvaonline.net site, tcpdump cụ thể cho thấy:

- 89.45.202.93 lại là một t0r relay server khác hoặc một t0r node ở dạng "exit relay".
- 74.63.219.12 chính là IP của HVA.

Từ t0r relay node này, traffic đi vào HVA hoàn toàn không encrypted (như hình minh hoạ).

Hai điểm lý thú ở đây:

a. Từ client (trên VMware Linux) đến đích (hvaonline.net) mình không biết traffic đi xuyên qua bao nhiêu t0r nodes và xuyên qua những nodes nào. Khi đến đích, một IP hoàn toàn khác (89.45.202.93) với IP được kết nối vào t0r relay network (171.25.193.20) được dùng để truy cập HVA. Nếu điều tra ngược lại, không cách gì dựa vào 89.45.202.93 để trace ngược lại điểm xuất phát (171.25.193.20) bởi vì làm sao trace được khi t0r pass through những t0r nodes dynamically? Đó là chưa kể, từ client (trên VMware Linux), t0r relay servers có thể thay đổi thường xuyên và mỗi lần thay đổi như vậy, requests lại đi xuyên các t0r nodes khác nhau trước khi đến đích là HVA.

b. Tất cả các encryption channels trên đường đi (trong giới hạn mình có thể capture) đều là TLS 1.0. Có lẽ đây là lý do mrro cảnh báo (BEAST, anyone? smilie

What bringing us together is stronger than what pulling us apart.

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	27/02/2012 10:26:40 (+0700) \| #60 \| 255696

Ky0
Moderator

Joined: 16/08/2009 23:09:08
Messages: 532
Offline

Em xin bổ sung một chút về một số điểm.
- Đối với các công ty tổ chức thì thường có những quy trình ứng phó với các sự cố, dĩ nhiên Nếu một công ty cỡ nhỏ hoặc quản trị viên quá kém cỏi hay lười nhác thì sẽ không có quy trình. Tuy nhiên sơ đẳng cũng biết nên ứng phó như thế nào (Do không có quy trình chi tiết nên sẽ bối rối và có thể phạm sai lầm).
- Một vài bước trong quá trình forensic

Một vài giả định:

- Điều tra viên có đầy đủ tool hỗ trợ việc forensic (công cụ phục hồi dữ liệu, các phần mềm phân tích log ….)
- Các thông tin hacker lấy được lần lượt được hacker công bố (tương tự như trường hợp của BKAV)
- Các bên liên quan phối hợp hỗ trợ thông tin cho quá trình forensic.

I. PHỤC HỒI HỆ THỐNG VÀ ĐÁNH GIÁ THIỆT HẠI

Về mặt kỹ thuật:

Đưa server dự phòng vào hoạt động, đồng thời triển khai Firewall và IDS để giám sát tránh tình trạng Hacker quay lại tiếp tục phá hoại.
Cách ly Server bị tấn công đợi cơ quan điều tra vào cuộc.
Đánh giá thiệt hại chung để đưa ra các thông tin bảo vệ khách hàng

Về mặt PR:

Soạn một thông cáo báo chí chính thức, nhằm kiểm soát thông tin tránh các thông tin ngoài luồng gây ảnh hưởng đến uy tín của công ty.
Cáo lỗi với khách hàng và cung cấp các thông tin hướng dẫn bảo vệ quyền lợi của khách hàng.
Phối hợp với cơ quan điều tra để công bố các thông tin gây nhiễu (nếu cần thiết) phục vụ quá trình điều tra.

II. TÌM HIỂU CÁCH THỨC HACKER XÂM NHẬP

Do “hacker trẻ tuổi và tài năng” đã đưa ra các phân tích và nhận định quá đầy đủ, sâu sắc và chuẩn xác nên các thành viên khác không thể phân tích và nhận định được gì hơn smilie

Hacker trẻ tuổi và tài năng wrote:

Trên đây có nhiều bạn đã trả lời với nhiều ý kiến. Có những ý kiến khá hay, đáng học hỏi. Nhưng có vẻ có những ý kiến hơi khái quát, hơi bao quát quá. Các giải pháp đưa ra có thể hay chỉ áp dụng như một nguyên tắc, nguyên lý, qui định chung về bảo mật hay khắc phục sự cố mà thôi.

Tôi xin bổ sung thêm một vài ý kiến nhỏ.

Ta giả dụ hệ thống bị defaced theo cách mà trang web webscan.bkav.com.vn bị defaced, nghĩa là hacker đặt đươc một file "hacked.html" vào thư mục gốc hay Documentroot của Apache, tức là của webserver và sau đó một vài ngày nó bị tấn công từ chôi dịch vụ và bị ngưng trệ trong nhiều ngay, dù có vẻ không có sự tham gia của một hệ thống botnet (DDoS zombies) trên mạng.

Điều quan trọng đâu tiên chúng ta phải xác định rõ cấu hình cụ thể của webserver vừa bị hack.
Trước tiên, loại HĐH mà webserver cài đặt là một yếu tố rất quan trọng cần phải xem xét. Win2k3 hay Windows OS nói chung có những điểm yếu rất khó khắc phục, tạo cơ hôi cho hacker thâm nhập. Vấn đề phải tìm xem hành đông hay hiện tượng thâm nhập vừa qua có liên quan đến điểm yếu nào của Win2K3 hay không?
Chú ý là việc update tự động các lỗ hổng bảo mật cho Windows thì MS làm khá tốt và dễ dàng. Vì vậy chỉ nên tập trung vào các lỗi mà admin của hệ thống bị hack chưa kip update, vì một lý do nào đó, hay lỗi mà MS chưa kịp ban hành bản vá lỗi trên mạng. Có rất ít hacker tim ra lỗi 0-day để hack.

Điểm thứ hai chúng ta phải xem xét đến phiên bản web server (trình quản lý web) được cài trong hệ thống. Ở đây là Apache(Win32)2.2.15. Apache không ban hành các bản vá lỗi tự động như MS cho Windows. Họ chỉ ban hành các phiên bản mới thay cho các phiên bản cũ có lỗi, có khả năng bị hack. Hiện nay đã là Apache 2.2.22 (released 2012-01-31). Chỉ cần tham khảo tài liệu của Apache là biết các lỗi của phiên bản cũ. Vấn đề chỉ còn là phải xác định hiện tượng và hành đông xâm nhập cụ thể của hacker vừa qua có liên quan đến các lỗi này không và đó là lỗi nào? (Tuy nhiên xác định được điều này không hề dễ dàng tí nào).

Điểm thứ 3, nhưng có khi lại là quan trọng nhất là các application được cài đặt trong hệ thống. Các application ở đây là PHP 5.3, MySQL 5.1, vBulletin 4.1.5.... Chú ý là các application mới là các nguyên nhân tạo ra nhiều lỗ hổng để cho hacker đột nhập hay defaced hệ thống. Một Application đươc cải tiến để tiện dụng hơn, có nhiều tính năng hơn thì lai càng có nhiều lỗ hổng hơn, đó là hậu quả, là "side effect", điển hình là PHP chẳng hạn.

Vì vậy nếu hiện tượng haker defaced website và để lai một file "hacked.html" ở root thì điều trước tiên ta phải nghĩ đến lỗi RFI (không phải "Đài phát thanh Pháp quốc" đâu nhé! Hì hì- mà là Remote file Inclusion vulnerability) hay LFI (Local File Inclusion). Lỗi này cho phép hacker đưa (upload) một file bẩn vào hệ thống từ xa và đặt nó ở directory hacker mong muốn. Vấn đề là admin của hệ thống đã không config. PHP (cụ thể là file php.ini) kỹ càng....(Các bạn ở BKAV cũng nên kiểm tra lai điều này). Chú ý là chỉ PHP đời mới sau này, như PHP 5.3.x, mới có lỗi này. Hì hì.

Tất nhiên một hệ thống Windows cài DotNet (.Net framework ) như hệ thống mà anh conmale đưa, cũng có lỗi RFI, nhưng khả năng hacker tận dụng lỗi này có vẻ ít hơn.
Chúng ta nhớ lai, trong đợt các hacker TQ defaced hàng loạt website của VN vừa qua, chúng cũng tận dụng lỗi nói trên (RFI). Ngược lai các hacker trẻ VN cũng làm giống như thế.

Cũng cần xác định rằng việc hacker defaced website như trường hợp webscan.bkav.com.vn thì không có nghĩa là hacker đã chiếm được quyền admin (lấy được password) của hệ thống đâu nhé. Khoảng cách đến đó nhiều trường hơp khá xa đấy.

Còn việc hệ thống bị tấn công từ chối dịch vụ và bị ngưng trệ trong thời gian dài mà không có sự tham gia cuả một hệ thống botnet trên mạng, thì thực tế có thể có đấy. Vấn đề là phải có hai yếu tố:
- Hacker phải dùng một DoS tool loại nào?
- Hệ thống phải cài các application nào để DoS tool này mới có thể phát huy tác dung? (Chỉ cần một hay hai hacker DoS trong một vài phút là hệ thống có thể ngưng trê nhiều giờ).Hệ thống mà anh conmale nói có cài các application ấy đấy. Tuy nhiên vấn đề này tôi xin nói sau, vì bài viết đã dài.

Chỉ khi xác định đươc cách thức tấn công cụ thể của hacker thì ta mới chặn được nó và có biện pháp hữu hiệu để phòng thủ.

"The Only Way To Stop A Hacker Is To Think Like One"

Dựa trên các thông tin hacker công bố trên http://bkavop.blogspot.com/2012/02/mon-qua-so-2-man-tau-hai-ve-bao-mat-cua.html thì có thêm những lưu ý sau:
- Nguy cơ Server bị cài cắm Trojan

TQN wrote:

Trong file tasklist.txt, có vài điểm mà em nghi ngờ cái server này đã nhiểm virus của stl. Uổng thiệt, nếu cậu hacker này mà tasklist thêm thông số thì em khoẻ biết mấy:

jusched.exe 1628 Console 0 6,136 K
jusched.exe 2948 1 6,192 K
wuauclt.exe 3652 Console 0 3,896 K
jucheck.exe 3392 Console 0 8,588 K
jucheck.exe 4136 1 7,344 K

jucheck # jusched nhé các bạn. Khả năng jucheck.exe là virus cao hơn jusched.exe của Java Update.
Nếu đã tắt Windows Update thì wuauclt.exe sẽ không run, các bạn còn nhớ wuauclt.exe trong "đống" mèo què của stl chứ.
Nếu em đoán đúng thì hết nói về cái BKAV phờ rồ. Nhưng nói vậy thôi chứ làm sao em có 3 mẫu này được ?

Nguy cơ Server bị nhiễm mã độc khi duyệt web trên chính server bằng chrome

Anonymous wrote:

Cái ngu số 04

Administrator lướt web ngay trên server và trong giờ làm việc

Bạn vui lòng tham khảo tệp tin "tasklist.txt" , bạn sẽ thấy các dòng sau:

chrome.exe 4520 Console 0 42,804 K
chrome.exe 4588 Console 0 32,088 K

Sau khi thấy có quá nhiều process của trình duyệt Chrome đang vận hành trên server chúng tôi nghi ngờ là quản trị viên server đang lướt web ngay trên server nên thực hiện việc sniff gói tin trên server, kết quả khá thú vị khi thấy quản trị server đúng là đang lướt web đọc báo, thậm chí vô Facebook bằng Server của BKAV. Chúng tôi rất tiếc không thể cung cấp gói sniff đó lên đây do nó chứa nhiều thông tin có thể làm hại người vô tội.

Đánh giá
Do hacker ra tay rất chuyên nghiệp và có sự chuẩn bị kỹ nên có thể hacker đã thăm dò rất kỹ và rất có thể đã xâm nhập vào trước đó. Nên cần kiểm tra lại log trên server và ISP trong vòng 1 tháng gần nhất đến thời điểm hiện tại. (Vì sao log quan trọng trong quá trình forensic sẽ giải thích ở phần sau).

1. Log trên Server

Khi bị tấn công xâm nhập thì log trên server không còn đáng tin cậy, tuy nhiên bằng các phương pháp kỹ thuật ta cũng có thể có được các thông tin hữu ích cho quá trình forensic.

Trường Hợp 1: Log bị xóa (do hệ thống tự động xóa hoặc quản trị viên vô tình xóa).
Trường hợp này dễ dàng dùng các công cụ phục hồi dữ liệu chuyên nghiệp để lấy lại log nguyên bản.

Trường Hợp 2: Log bị xóa (do hacker chủ động xóa).

Trường hợp hacker xóa log bằng các câu lệnh xóa thông thường => Dễ dàng khôi phục lại log gốc bằng các công cụ chuyên dụng.
Trường hợp hacker xóa log bằng các công cụ xóa an toàn (xóa và ghi đè 30 lần chẳng hạn) => Không thể phục hồi log để phục vụ quá trình forensic. => Việc truy tìm và buộc tội hacker là điều cực kỳ khó khăn. Tuy nhiên cũng có thể còn chút dấu vết nào đó nhận dạng hacker (chương trình xóa an toàn hacker sử dung, thói quen xóa dấu vết khi xâm nhập ....)

Trường Hợp 3: Log bị sửa
Dùng các công cụ phục hồi dữ liệu chuyên dụng lấy lại log trước đó. So sánh sự khác nhau giữa log lưu trước đó và hiện tại (đơn giản với lệnh diff trên linux thì dễ dàng có được các đoạn log cần thiết).

Trường Hợp 4: Log bị làm nhiễu
Dùng các công cụ phân tích log và thống kê (splunk). Thông qua quá trình sàng lọc cũng sẽ được các thông tin cần thiết.

Trường Hợp 5: Kết hợp nhiều phương pháp
Trường hợp này sẽ mất nhiều thời gian và có thể sẽ bị phát hiện trong lúc xóa dấu vết. => Trường hợp này hiếm xảy ra, nếu rơi vào tình trạng này thì việc điều tra cực kỳ khó khăn (có thể khiến quá trình forensic đi vào ngõ cụt).

2. Log của ISP

Đây là các thông tin có thể tin cậy. Kết hợp với phân tích log trên Server ta có thể biết được cách thức hacker xâm nhập, thời gian xâm nhập, IP .... Đồng thời kết hợp với log trên server thì ta có thể hình dung được các hành động của hacker trên hệ thống, đồng thời tìm các điểm yếu của hệ thống.

3. Thu thập thông tin từ các bên liên quan và các nguồn khác

Thu thập thông tin từ Blog: IP truy cập vào http://bkavop.blogspot.com/ post bài, email đăng ký blogspot.
Thu thập thông tin từ nhà cung cấp email: IP và log quá trình đăng nhập và sử dụng tài khoản email.
Thu thập thông tin từ các các nguồn khác: HVA, bkav, vozforum … => tìm các sai sót và cung cấp dữ liệu hình thành "chân dung" hacker

III. Nghiệp vụ trong Forensic

mrro wrote:

cách đây vài năm tôi có viết một bài nhắc đến Tor như là một công cụ tốt để trở nên ẩn danh trên Internet. bây giờ đọc lại thì tôi mới thấy, nói như cách g4mm4 hay nói, hạn chế của tôi hồi đó. bạn nào nghĩ rằng sử dụng Tor là an toàn thì bây giờ bắt đầu lo lắng là vừa. đối với một hệ thống có sự chuẩn bị tốt thì phải rất cao tay mới mong lai vô ảnh, khứ vô hình khi xâm nhập vào hệ thống đó. địa chỉ IP, thứ mà Tor có thể giúp che dấu một phần, chỉ là một trong số rất rất nhiều "dấu vân tay" mà chúng ta để lại khi duyệt web.

Như anh mrro đã đề cập địa IP chỉ là một mảnh nhỏ (tựa như dấu vân tay) trong quá trình forensic. Để hiểu hơn thì chúng ta tìm hiểu một chút về quy trình forensic.

Bước 1: Phân tích hiện trường và thu thập thông tin => phác họa chân dung thủ phạm

Các thông tin cần thiết cho quá trình forensic:

Dấu vân tay (Địa chỉ IP)
Dấu vết (hành vi của thủ phạm) và chứng cứ (log) tại hiện trường
Phân tích tính cách khả năng, hành vi của tội phạm (Thu thập thông tin từ các nguồn + Các biện pháp thăm dò tâm lý) => Phác họa chân dung cơ bản của tội phạm.

Các thông tin trên càng đầy đủ và chính xác thì quá trình xác định nghi can và tìm ra thủ phạm càng nhanh chóng.

Ví dụ: Trường hợp của BKAV

Dựa trên các thông tin log ISP, và thông tin được cung cấp từ các công ty, tổ chức … Ta có thể xác định được là hacker sử dụng Tor nên việc tìm ra địa chỉ IP thực của hacker gần như là không thể (tạm thời thiếu mất một yếu tố).
Dấu vết (hành vi của thủ phạm) và chứng cứ (log) tại hiện trường của BKAV chưa xác định được trạng thái. Nhưng dù chứng cứ (log) tại hiện trường có bị xóa sạch hay tạo hiện trường giả (sửa log, làm nhiễu log) thì vẫn còn các dấu vết (Các bước hành động tổng quát của hacker).
Thêm các thông tin từ http://bkavop.blogspot.com/, https://www.facebook.com/pages/BKAV-Op/197446347029547?sk=wall, các forum … Thì ta có thể hình thành bảng đánh giá phác họa chân dung Hacker.

Chú thích: Trong ngành phân tích tâm lý tội phạm, các nhà khoa học đã hình thành một bảng trắc nghiệm, đánh giá hành vi, tâm lý của tội phạm từ đó phác thảo tương đối chính xác (>60%) “chân dung” tội phạm (kết hợp giữa khoa học phân tích tâm lý và suy luận khoa học xã hội). Bạn nào hay theo dõi phim điều tra phá án của của Anh, Pháp, Mỹ, Hồng Kông và các phim về CSI thì chắc biết phương pháp này smilie

(Phương pháp này giống phương pháp suy luận của Sherlock Holmes). Lúc đầu chỉ là bảng trắc nghiệm thống kê nhưng giờ một số nơi đã viết thành một phần mềm chuyên dụng nên hỗ trợ rất nhiều cho công tác điều tra smilie

Bước 2: Tạo danh sách Nghi Phạm và khoanh vùng các nghi can

Lên danh sách các nghi phạm (rất dài), dựa trên các kết quả phân tích khoa học và suy luận để thu hẹp danh sách nghi phạm (còn lại khoảng khoảng 1/4 đến 1/2 danh sách). => Bước này thường dựa vào động cơ gây án để thu hẹp.

Ví dụ:Trường hợp của BKAV
Các nhóm đối tượng tình nghi:
Đối thủ cạnh tranh không lành mạnh
AntiFan
Hacker muốn chứng tỏ tài năng (Nếu các thông tin tại http://bkavop.blogspot.com/ chính xác thì các script kiddy cũng có thể thực hiện smilie

)
Hacker liên quan đến người bị bắt trước đó (02/02/2012)
Hacker bất bình với hành xử của BKAV => Trường hợp của BKAV có quá nhiều nghi phạm nên rất khó khăn trong quá trình forensic smilie

Còn có nhóm đối tượng nằm trong nhiều nhóm trên nữa. Đối với BKAV danh sách nghi phạm sẽ rất nhiều smilie

Tiến hành giám sát các nghi phạm, thu thập thông tin hình thành bảng đánh giá nghi phạm.
=> Đây là bước cực kỳ khó khăn, đòi hỏi nhân lực và thời gian theo dõi dài, nếu nghi phạm không có dấu hiệu bất thường (do xong việc) thì việc hình thành danh sách nghi can là cực kỳ khó. Chính vì vậy thường các điều tra viên thường tung tin sai lệch để thủ phạm lộ sơ hở => từ đó khoanh vùng nghi can.

Ví dụ: Trường hợp của BKAV

vnexpress wrote:

Đại tá Trần Văn Hòa, Cục phó Cục Cảnh sát phòng chống tội phạm công nghệ cao (C50 - Bộ Công an), khẳng định với VnExpress.net rằng đã xác định được hacker - tác giả của những thông tin về các lỗi bảo mật của Bkav đang gây xôn xao trên mạng, đồng thời cho biết những gì hacker đưa lên có một số điều không chính xác.

http://vnexpress.net/gl/vi-tinh/hacker-virus/2012/02/bkav-len-tieng-ve-vu-phat-tan-8-sai-lam-bao-mat/
Thì nhanh chóng hacker có thông tin phản hồi:
http://bkavop.blogspot.com/2012/02/thu-gui-ngai-quan-chuc-chinh-phu-chuyen.html
Và:
https://www.facebook.com/pages/BKAV-Op/197446347029547?sk=wall

Đánh giá

Đây là hành động nhóm hacker lo sợ sẽ “ảnh hưởng đến người vô tội” hoặc BKAV & C50 thí con tốt để trấn an dư luận. Lúc này mục tiêu ban đầu của hacker( đòi lại công bằng cho hacker bị bắt và hạ uy tín của BKAV) không đạt được.
Hacker đã thăm dò và lên kế hoạch tỉ mỉ cho việc tấn công BKAV (deface, drop database, dump database, thông tin cấu hình các thành phần, …) đồng thời lộ trình đưa lần lượt các thông tin lên mạng. Nhưng vẫn chưa dự trù đối phó hết các chiêu tâm lý của BKAV & C50. Chính vì thế “thư gửi điều tra viên” kia có chút lúng túng nhưng lại được viết theo phong cách hành văn khác (giống cách hành văn phản hồi cho anh conmale). -a-
Hacker đã xác định tấn công BKAV thì C50 sẽ vào cuộc=> một mình Hacker đấu trí với một đội ngũ chuyên nghiệp là việc làm dại dột -b-

=> Từ -a- và -b- ta có thể thấy rằng hacker tấn công BKAV có ít nhất 2 người và được phân công công việc một cách rõ ràng.

Dự đoán

BKAV vẫn tiếp tục im lặng nếu tìm được nghi phạm sẽ quăng bom, nếu không tìm ra thì im lặng và dùng các biện pháp bưng bít thông tin nhằm cho vụ việc rơi vào quên lãng.
Hacker vẫn lần lượt tung các thông tin có được trong đợt xâm nhập BKAV
Màn đấu trí giữa C50 và hacker
Màn đấu khẩu giữa sgtc BKAV và cộng đồng IT

Sau khi dùng các đòn tâm lý thì sẽ có một số nghi phạm có dấu hiệu bất thường(Có tật thì giật mình smilie

) => Sàng lọc được một số đối tượng hình thành danh sách nghi can (còn khoảng chục người).
Tiếp tục giám sát nhằm thu hẹp các các nghi can (để xin lệnh khám xét hoặc tạm giam để thẩm vấn cho dễ smilie

).

Bước 3: Tiến hành thẩm vấn các nghi can và thu thập chứng cớ

Lúc này các nghi can còn lại tương đối ít nên việc xin lệnh khám xét tương đối dễ.

Trường Hợp 1: Thu thập được các bằng chứng cần thiết => R.I.P
Lúc này thẩm vấn rất đơn giản, hacker chỉ còn cách cúi đầu nhận tội.

Trường Hợp 2: Không thu thập được bất cứ bằng chứng nào

Nghi can sẽ được hai nhân viên thẩm vấn (Có thể có một vài người giám sát để phát hiện nghi can có nói dối hay không). Bằng các biện pháp tâm lý từ đe dọa đến mềm mỏng để khai thác thông tin và khiến nghi phạm mất bình tĩnh mà để lộ sơ hở. => Nếu nghi can phạm tội thực sự sẽ để lộ sơ hở và bị người thẩm vấn hỏi vặn lại => Thành khẩn khai báo.
Các nghi can có mối liên hệ với nhau thì tung hỏa mù dạng: “Thằng xxx và thằng yyy đã thành khẩn khai nhận, và nó nói chủ mưu chính là anh/chị” => Lần lượt từng người khai báo với suy nghĩ: “Nếu thằng xxx hay thằng yyy có khai báo thật và đổ tội hết lên đâu mình thì toi”
Nghi can khai báo lung tung hoặc không có gì để khai báo => Tiến hành thẩm vấn các nghi can khác. Nếu không thu được gì thì tiếp tùng sàng lọc lại các đối tượng. => Mất thời gian và có thể không tìm ra được thủ phạm.

Đánh giá:

Một đấu trí với hai thì không thể dành chiến thắng được . Thực tế chứng minh dù tội phạm có tinh ranh và ngoan cố đến đâu đi chăng nữa, thì sau một thời gian thẩm vấn sẽ ngoan ngoãn nhận tội => Chính vì thế trong phim nghi can thường không nói gì khi không có luật sư bên cạnh. Ở Việt Nam thì tùy từng hoàn cảnh .
Đôi khi nghi can tâm lý không vững nên sau khi bị đe dọa, bị mớm cung vẫn có thể nhận tội bừa => Đối với tội phạm kinh tế hay tội phạm công nghệ cao thì rất hiếm có trường hợp này.
Nếu nghi can hoàn toàn không phạm tội thì sẽ chả có gì để khai => Đôi khi nghi can phạm tội nhưng khả năng ứng phó và đối đáp quá tài tình thì các điều tra viên cũng không thu được kết quả gì (Trường hợp này chỉ có những chuyên gia tình báo, nhân viên an ninh nằm vùng được đào tạo bài bản mới vượt qua được, trừ trường hợp mấy thằng bị mất trí nhớ )

- Ky0 -

PS:
- Mới coi xong bộ Forensic Hero III, đang theo dõi bộ Sherlock Holmes 2011 nên bị nhiễm hơi nhiều smilie

- Có lẽ nên dành một topic thảo luận về Tor thì hay nhất
- Năm nay sẽ là năm cao số khi Tor được mọi người sử dụng để tấn công các website smilie

UITNetwork.com
Let's Connect

Go to:

Users currently in here
3 Anonymous