<![CDATA[Latest posts for the topic "Case Study: phân tích hiện trường sau khi bị thâm nhập."]]> /hvaonline/posts/list/51.html JForum - http://www.jforum.net Case Study: phân tích hiện trường sau khi 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.]]> /hvaonline/posts/list/41207.html#253862 /hvaonline/posts/list/41207.html#253862 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. 1. Công ty này nên thiết lập ngay một web server khác và 1 trang "In Maintenance" và ngắt ngay server bị tấn công khỏi network ,hay nói cách khác ,cách ly server đó. Mục đích: Để bảo vệ uy tín cho công ty ,và để cho kẻ tấn công không phán đoán được hành động của nạn nhân ,1 trang "In Maintenance Mode" cũng không làm cho khách hàng lo lắng vì maintenance cũng là chuyện bình thường đối với mọi trang web. Cách ly server đó ra khỏi network để tránh tình trạng bị alter data ,log ,hay configuration trên server ,nhằm phục vụ cho mục đích forensic. 2. Lập tức thông báo cho nhóm điều hành forum thay đổi ngay password cho tài khoản email, tài khoản ftp,remote admin (nếu service tương ứng được cài đặt trên máy họ) đồng thời đưa ra hướng dẫn tạo mật khẩu an toàn. Yêu cầu các thành viên trong nhóm điều hành tiến hành quét virus ,rootkit ,trojan trên máy của họ. Nếu phát hiện điều gì bất thường ,phải báo cáo lại cho bộ phận IT chịu trách nhiệm khắc phục sự cố. Mục đích: Việc này đảm bảo rằng kẻ tấn công không còn giữ quyền kiểm soát email ,account ftp,remote admin (nếu có) của các thành viên trong nhóm điều hành forum. Ngoài ra ,bước này cho phép ta xác định nguồn của cuộc tấn công có bắt đầu từ việc mất pasword ,dính rootkit hay keylogger của các thành viên trong nhóm điều hành hay không. Nếu có thì sẽ xác định được quá trình họ bị mất password (password không tuân theo hướng dẫn tạo password an toàn) ,hay thông qua việc download các software trên chính forum hay từ nguồn khác. Điều này sẽ giúp xây dựng chính sách bảo mật hợp lý sau khi đã khắc phục được sự cố. 3. Mời ngay 1 công ty hay các chuyên gia có kinh nghiệm ứng cứu sự cố và forensic :^) ]]> /hvaonline/posts/list/41207.html#253873 /hvaonline/posts/list/41207.html#253873 GMT Case Study: phân tích hiện trường sau khi 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?   1. Để đảm bảo bảo mật - Thực hiện việc phân tách hệ thống, nhằm đóng băng hệ thống cũ và xây dựng hệ thống mới. Tránh tình trạng downtime quá lâu - Xây dựng 1 đội nghiên cứu hoặc thuê bên thứ 3 chịu trách nhiệm truy dấu vết của attacker để lại trên máy chủ cũ. - Liên hệ với các cơ quan chức năng có thẩm quyền để "rộng" đường trong việc điều tra - Xây dựng các giải pháp phòng tránh tạm thời để tránh tình trạng hệ thống bị thâm nhập 1 lần nữa - Rà soát các dịch vụ, lỗ hổng -phần mềm máy chủ đang chạy. Kiểm tra các user / pc nhân viên có thẩm quyền liên quan đến hệ thống 2. Để đảm bảo uy tín công ty - Trỏ domain hiện tại sang một trang thông cáo, nhằm truyền tải nội dung giữa Cty và khách truy cập. Tránh tình trạng các thông tin từ các phía truyền thông tuyên truyền sai lệch ]]> /hvaonline/posts/list/41207.html#253913 /hvaonline/posts/list/41207.html#253913 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. 1. web của công ty vừa bị thâm nhập. 2. Để 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? 1. web của công ty vừa bị thâm nhập là hệ quả của một số nguyên nhân tồn tại trước đó khách quan hoặc chủ quan. (VD: cá nhân nghịch phá , đối thủ cạnh tranh không lành mạnh, quan hệ khách hàng hoặc cộng đồng không tốt, nhân viên kỹ thuật trong công ty nghỉ việc, quản trị hệ thống thiếu quan tâm đến các dịch vụ trên máy chủ web,cập nhập,fix bugs ...vv.) 2. Bảo đảm bảo mật và uy tín của công ty là quá trình xây dựng lâu dài, từ lúc thành lập công ty và tiếp diễn. Bất kỳ công ty nào làm khi làm kinh doanh đều phải xây dựng cho mình kế hoạch phục hồi sau thảm họa (Disaster Recovery). Kế họach khôi phục sau thảm họa là quá trình chuẩn bị, là phản ứng từ trên xuống dưới, tất cả cá nhân liên quan. Việc chuẩn bị tốt chu đáo kế hoạch phản ứng với các danh sách thảm họa đã được phân loại sẽ giúp công ty giảm thiểu thiệt hại về vật chất lẫn uy tín của mình. - Tùy theo quy mô lớn nhỏ của công ty cũng như dịch vụ mà mình cung cấp( VD: Website availability 24/7 ) mà xây dựng kế hoạch Disaster Recovery cho phù hợp. Như vậy, việc xây dựng kế hoạch khắc phục sau thảm họa là việc cần triển khai trước tiên song song với sự phát triển của công ty. Còn tình huống web bị thâm nhập là xãy ra sau, và cần chấp nhập sự thật khi public web ra internet bị tấn công là vấn đề không tránh khỏi. Ghi nhận trường hợp của bkav và các thông tin từ các tờ báo online được xem là có uy tín ở việt nam phản ảnh: Cho thấy sự thiếu chuẩn bị và cách đánh giá vấn đề dẫn đến các hành động, phản ứng của cá nhân đại diện bkav được cộng đồng mạng đánh giá là bất lợi cho doanh nghiệp khi kinh doanh sản phẩm và dịch vụ của mình sau này. - Việc đánh giá mực độ hậu quả một cách nghiêm túc,cũng như công việc thu thập thông tin để tìm ra nguyên nhân cốt lõi của vấn đề là việc cần thiết nên làm. Có thể thấy vấn đề nghiêm trọng trong trường hợp của bkav xuất phát từ cách hành xử, phản ứng đã tồn tại từ rất lâu, chứ không phải vấn đề bị tấn công (defaced và mất DB) và bị cài file "hacked.html" trên máy chủ. bkav bị tấn công(defaced và mất DB) là hậu quả tất yếu xuất phát từ nguyên nhân là cách hành xử, phản ứng từ vụ bị tấn công trước đó. - Như đã đề cập ở trên, Bảo đảm bảo mật là quá trình làm việc lâu dài song song với sự phát triển của công nghệ, là sự hợp tác từ cá nhân liên quan từ cấp Lãnh đạo tới nhân viên. Ghi nhận ý kiến của anh Conmale về kiện toàn bảo mật "Bảo mật ở các tầng, các lớp không đơn thuần chỉ cấu hình ứng dụng trên máy chủ web. Thanks for viewing ]]> /hvaonline/posts/list/41207.html#253916 /hvaonline/posts/list/41207.html#253916 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#253925 /hvaonline/posts/list/41207.html#253925 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

comale wrote:
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.  
Theo em thấy thì website đã bị hack thì uy tín đã sứt mẻ rồi, việc còn lại là làm sao để không sứt mẻ thêm và phục hồi nó. Dưới "góc độ forensic" thì việc tối quan trọng là tìm ra lỗ hổng và vá lỗi kịp thời. Nhưng cái khó ở đây là vừa tìm được lỗ hổng vừa phải đảm bảo việc làm ăn vẫn thuận lợi, đối với 1 công ty lớn chỉ cần đặt server offline 1p có thể thiệt hại nhiều tỉ đồng. Do đó cái một chiến lược tốt sẽ là một chiến lược "nhanh" mà vẫn "chắc". Ngoài những thứ các bạn khác đã nói ở trên thì mình xin bổ xung theo quan điểm của mình: 1) Luôn có 1 máy chủ dự phòng và thiết lập ở chế độ DEBUG mode và SAFE mode (disable các tính năng không cần thiết). Khi bị hack lập tức switch qua máy chủ này và lưu lại toàn bộ traffic vào ra để điều tra nếu hacker có ý quay lại. 2) Trong lúc đó khoanh vùng các application có khả năng bị lỗi cao. Cái này tùy thuộc nhiều vào dấu hiệu bị hack mà attacker để lại. (qua access log, event log của window, thời gian loggin, ip loggin). Ví dụ: Nếu bị hack vào database thì khả năng cao là : - sql injection trong vbulletin forums, các pluggin, app v.v.. - lỗi 0-day mysql server Nếu bị deface / upload file lạ trên hệ thống: - xem khả năng bị chiếm quyền root của server vì các ứng dụng webserver, php có lỗi 0-day - khả năng admin bị cài virus và mất mật khẩu - khả năng webserver bị lỗi cho upload file hay thay đổi file 3) Cùng lúc chạy các ứng dụng tìm rootkit kết hợp audit manually các file bị thay đổi trong hệ thống trong khoảng thời gian bị tấn công. 4) Sửa lỗi và thông báo cho các cơ quan chức năng, đặc biệt quan trọng theo mình là phải luôn trung thực, cầu tiến và bình tĩnh trong phát ngôn với các tổ chức bên ngoài. ]]> /hvaonline/posts/list/41207.html#253926 /hvaonline/posts/list/41207.html#253926 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

Ikut3 wrote:
- Liên hệ với các cơ quan chức năng có thẩm quyền để "rộng" đường trong việc điều tra  

KAi wrote:
Chưa thấy bạn nào đề cập đến việc "làm việc các đơn vị chức năng có liên quan" như "Trung tâm an ninh mạng", "Lực lượng cảnh sát phòng chống tội pham công nghệ cao" nhỉ smilie  
hứ hứ :P]]> /hvaonline/posts/list/41207.html#253928 /hvaonline/posts/list/41207.html#253928 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#253952 /hvaonline/posts/list/41207.html#253952 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

WinDak wrote:

comale wrote:
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.  
Theo em thấy thì website đã bị hack thì uy tín đã sứt mẻ rồi, việc còn lại là làm sao để không sứt mẻ thêm và phục hồi nó. Dưới "góc độ forensic" thì việc tối quan trọng là tìm ra lỗ hổng và vá lỗi kịp thời. Nhưng cái khó ở đây là vừa tìm được lỗ hổng vừa phải đảm bảo việc làm ăn vẫn thuận lợi, đối với 1 công ty lớn chỉ cần đặt server offline 1p có thể thiệt hại nhiều tỉ đồng. Do đó cái một chiến lược tốt sẽ là một chiến lược "nhanh" mà vẫn "chắc". Ngoài những thứ các bạn khác đã nói ở trên thì mình xin bổ xung theo quan điểm của mình: 1) Luôn có 1 máy chủ dự phòng và thiết lập ở chế độ DEBUG mode và SAFE mode (disable các tính năng không cần thiết). Khi bị hack lập tức switch qua máy chủ này và lưu lại toàn bộ traffic vào ra để điều tra nếu hacker có ý quay lại. 2) Trong lúc đó khoanh vùng các application có khả năng bị lỗi cao. Cái này tùy thuộc nhiều vào dấu hiệu bị hack mà attacker để lại. (qua access log, event log của window, thời gian loggin, ip loggin). Ví dụ: Nếu bị hack vào database thì khả năng cao là : - sql injection trong vbulletin forums, các pluggin, app v.v.. - lỗi 0-day mysql server Nếu bị deface / upload file lạ trên hệ thống: - xem khả năng bị chiếm quyền root của server vì các ứng dụng webserver, php có lỗi 0-day - khả năng admin bị cài virus và mất mật khẩu - khả năng webserver bị lỗi cho upload file hay thay đổi file 3) Cùng lúc chạy các ứng dụng tìm rootkit kết hợp audit manually các file bị thay đổi trong hệ thống trong khoảng thời gian bị tấn công. 4) Sửa lỗi và thông báo cho các cơ quan chức năng, đặc biệt quan trọng theo mình là phải luôn trung thực, cầu tiến và bình tĩnh trong phát ngôn với các tổ chức bên ngoài.  
Mình thấy phần chạy ứng dụng tìm rootkit trong điểm thứ 3 của Windak nêu ra không cần thiết lắm, vì theo mình thì 1 khi hệ thống đã bị owned thì không thể tin tưởng để tiếp tục sử dụng tiếp mà phải chuyển sang 1 máy chủ fresh khác (còn máy owned thì offline để forensic). Thay vì đó, ta nên tập trung time cho forensic thì tốt hơn ;) -rickb]]> /hvaonline/posts/list/41207.html#253954 /hvaonline/posts/list/41207.html#253954 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#253957 /hvaonline/posts/list/41207.html#253957 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#253959 /hvaonline/posts/list/41207.html#253959 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

vulehcm wrote:
Có điểm này mình chưa thấy có bạn nào trình bày đó là việc xác thực log trước khi tiến hành mang nó đi phân tích. Đây có lẽ là một bước bình thường với những bạn quen việc phân tích log nhưng cũng có rất nhiều bạn quên làm bước này. Thực ra theo mình đây là một bước rất quan trọng, vì thường thì nếu attacker đã owned system thì sẽ xáo trộn log để xoá dấu vết hoặc là đánh lạc hướng điều tra, gây rắc và khó khăn trong việc điều tra. Kinh nghiệm bản thân là nếu xác định hoặc có dấu hiệu system bị owned thì không nên tin 100% vào log. 
Đúng rồi, có khi nó còn dùng log để gắp lửa bỏ tay người :| ]]> /hvaonline/posts/list/41207.html#253960 /hvaonline/posts/list/41207.html#253960 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#253964 /hvaonline/posts/list/41207.html#253964 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. 10. Sống cho đàng hoàng đừng để thiên hạ ghét. - Lý do : Để những lần bị hack sau không tới sớm hơn.]]> /hvaonline/posts/list/41207.html#253975 /hvaonline/posts/list/41207.html#253975 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

WinDak wrote:

comale wrote:
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.  
Theo em thấy thì website đã bị hack thì uy tín đã sứt mẻ rồi, việc còn lại là làm sao để không sứt mẻ thêm và phục hồi nó. Dưới "góc độ forensic" thì việc tối quan trọng là tìm ra lỗ hổng và vá lỗi kịp thời. Nhưng cái khó ở đây là vừa tìm được lỗ hổng vừa phải đảm bảo việc làm ăn vẫn thuận lợi, đối với 1 công ty lớn chỉ cần đặt server offline 1p có thể thiệt hại nhiều tỉ đồng. Do đó cái một chiến lược tốt sẽ là một chiến lược "nhanh" mà vẫn "chắc". Ngoài những thứ các bạn khác đã nói ở trên thì mình xin bổ xung theo quan điểm của mình: 1) Luôn có 1 máy chủ dự phòng và thiết lập ở chế độ DEBUG mode và SAFE mode (disable các tính năng không cần thiết). Khi bị hack lập tức switch qua máy chủ này và lưu lại toàn bộ traffic vào ra để điều tra nếu hacker có ý quay lại. 2) Trong lúc đó khoanh vùng các application có khả năng bị lỗi cao. Cái này tùy thuộc nhiều vào dấu hiệu bị hack mà attacker để lại. (qua access log, event log của window, thời gian loggin, ip loggin). Ví dụ: Nếu bị hack vào database thì khả năng cao là : - sql injection trong vbulletin forums, các pluggin, app v.v.. - lỗi 0-day mysql server Nếu bị deface / upload file lạ trên hệ thống: - xem khả năng bị chiếm quyền root của server vì các ứng dụng webserver, php có lỗi 0-day - khả năng admin bị cài virus và mất mật khẩu - khả năng webserver bị lỗi cho upload file hay thay đổi file 3) Cùng lúc chạy các ứng dụng tìm rootkit kết hợp audit manually các file bị thay đổi trong hệ thống trong khoảng thời gian bị tấn công. 4) Sửa lỗi và thông báo cho các cơ quan chức năng, đặc biệt quan trọng theo mình là phải luôn trung thực, cầu tiến và bình tĩnh trong phát ngôn với các tổ chức bên ngoài.  
Mình xin bổ sung thêm 1 ý kiến, sau bước 1 của WinDak mình sẽ nhanh chóng xác định chính xác với biên độ khoảng 5-10 phút thời điểm trước,diễn ra và sau khi hệ thống bị xâm nhập. Sau đó tới bước 2 WinDak đề cập mình sẽ kết hợp với phần thông tin trên Firewall cùa ISP thực hiện forensic.]]> /hvaonline/posts/list/41207.html#253979 /hvaonline/posts/list/41207.html#253979 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#253980 /hvaonline/posts/list/41207.html#253980 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. 1 plan. Plan và các quá trình của mình sẽ như sau: TRƯỚC KHI TRIỂN KHAI DỊCH VỤ 1) Thu thập thông tin - Công đoạn này là xem xét kĩ yêu cầu của công việc và dịch vụ. => Tránh thiếu sót hay thừa thãi về sau. 2) Chuẩn bị - Liệt kê ra 1 danh sách những gì ta cần để thực hiện như là: nguyên liệu (máy chủ, phần mềm, ...) - Ở bước này kèm theo luôn cả tìm hiểu thông tin về những nguyên liệu đó - như là cấu hình phần cứng liệu có đủ, phần mềm version nào ổn định, tìm hiểu thêm xem có bug mới nào của nó đã được report .... và cuối cùng là theo cảm tính đánh giá về hãng cung cấp để lựa chọn sản phẩm. - Với yêu cầu đề ra ở đây là "Đảm báo tính bảo mật và uy tín", ta cần dự phòng và tính trước những sự cố -> Chuẩn bị server dự phòng. - Chuẩn bị nhân lực, phân chia công việc rõ ràng. TRIỂN KHAI DỊCH VỤ 1) Xây dựng - Cài đặt và cấu hình server cẩn thận, phân quyền rõ ràng <> Phần lớn các công ty hiện nay mình thấy họ sử dụng tài khoản root để chạy chung các dịch vụ/ tác vụ trên server. 2) Thử nghiệm và theo dõi trước khi đưa vào sử dụng - Tiến hành chạy thử và theo dõi kiểm tra xem có phát sinh lỗi gì hay không, ... SAU KHI TRIỂN KHAI DỊCH VỤ 1) Theo dõi - Kiểm tra log liên tục. - Theo dõi và ghi nhận những điểm "không ổn" và đưa ra phương án để "giải quyết". - Luôn luôn cập nhật thông tin về các bug,exploit và update hệ thống. 2) Thu thập ý kiến đóng góp người dùng ... SỰ CỐ SAU KHI TRIỂN KHAI DỊCH VỤ * Bước này sẽ được giải quyết đơn giản hơn nếu mà ta từ những bước trước chuẩn bị sẵn. 1) Ngắt hoàn toàn các hoạt động của máy chủ chính và những hoạt động liên quan của nó và đưa máy chủ dự phòng vào hoạt động. 2) Đưa ngay thông báo/ cảnh báo đến người dùng. 3) Tiến hành phân tích và điều tra phát hiện lỗi: - Nếu chúng ta thường xuyên theo dõi log và cập nhật thông tin mới, ta sẽ thu thập được từ đó những thông tin hữu ích. - Nếu quyền hạn được phân chia rõ ràng, cũng góp phần giúp ta nhanh chóng khoanh vùng đối tượng. 4) Còn tuỳ vào tính chất sự việc mà liên hệ với bên thứ 3 để "cùng giải quyết". ------------------------------------------- Ở đây theo ý kiến cá nhân của riêng mình, thì trước khi làm 1 cái gì đó cũng nên liệu trước các vấn đề có thể sảy ra và chuẩn bị sẵn từ trước. Như tình huống của anh conmale đưa ra, nếu ta ngay từ đầu đã đề phòng và chuẩn bị trước thì đã không đến nỗi tệ hại lắm ;) Còn về uy tín của công ty, không có gì là hoàn hảo cả. Cái "uy tín" này còn phải dựa vào cách ứng xử của công ty đó trong trường hợp này thế nào, có khiến người dùng mất cảm tình hay không mà thôi :))]]> /hvaonline/posts/list/41207.html#253981 /hvaonline/posts/list/41207.html#253981 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#253982 /hvaonline/posts/list/41207.html#253982 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#253984 /hvaonline/posts/list/41207.html#253984 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. 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ệ.   Có bạn nào nghĩ đến chuyện ngay từ đầu chúng ta sẽ triển khai 2 VPS trên dedicated server này không (anh conmale không nói rõ điểm này) ? Lúc đó thì forensics thế nào nhỉ?]]> /hvaonline/posts/list/41207.html#253988 /hvaonline/posts/list/41207.html#253988 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#253993 /hvaonline/posts/list/41207.html#253993 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

conmale wrote:
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. 
]]> /hvaonline/posts/list/41207.html#254010 /hvaonline/posts/list/41207.html#254010 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#254011 /hvaonline/posts/list/41207.html#254011 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. "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ệ. ". Chúng ta có gì? 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ụ. Khi nói đến điểm a và nói đến forensics, chúng ta nghĩ ngay đến khả năng bị thâm nhập ngay trên 1 máy chủ bởi vì giới hạn được đưa ra chỉ gói ghém trên 1 máy. Khi nói đến 1 dedicated server, ta dễ hình dung đến khả năng penetrate đến chính máy chủ ấy thay vì nhảy từ một máy chủ láng giềng nào khác. Điều này có thể (hoặc có thể không) giới hạn biên độ điều tra bởi vì nếu chưa xét rõ xem ngoài dedicated server ấy, nạn nhân có sở hữu máy chủ nào gần đó và mở toang cửa để thâm nhập và dùng nó làm bàn đạp để xâm nhập mục tiêu? Tôi đã từng va phải trường hợp (khi audit một số hệ thống) là bên cạnh máy chủ được sử dụng chính thức (máy A) còn có một máy khác dùng để thử nghiệm (máy B). Khốn khổ là từ máy B có thể rsh hoặc rlogin thẳng vô máy A mà không cần xác thực gì hết. Bởi vậy, bỏ rơi khả năng "máy chủ láng giềng" có thể là bỏ hẳn một mảng rất lới giúp mang lại kết quả cho việc điều tra. 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.... Hãy thử nhìn sự việc ở góc độ một chuyên viên bảo mật và điều tra thay vì ở góc độ một "lính" được sai để... đánh ;). Hãy nhìn bức tranh tổng thể và hình thành cụ thể "kế hoạch tác chiến" từng mảnh một từ những điểm a, b và c. Khoan hãy nhảy thẳng vào góc độ "phòng chống" bởi vì chưa có gì rõ ràng hết. Mời bà con tiếp tục.]]> /hvaonline/posts/list/41207.html#254019 /hvaonline/posts/list/41207.html#254019 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. uy tín của công ty, tránh tình trạng như BKAV ) - Điều tra xem lái xe có uống rượu bia, và gia đình có tiểu sử về bệnh thần kinh hay không = kiểm tra xem các ứng dụng được cài đặt trên server có lỗi gì không? - Xem các yếu tố tác động trực tiếp và gián tiếp đến vụ tai nạn = Yêu cầu ISP cung cấp thêm các thông tin để tiện điều tra. - Truy tìm thằng gây tai nạn xong bỏ chạy = bắt thằng hack :D

gamma95 wrote:
Do hạn chế về trình độ, nên nếu là mình thì mình sẽ rút điện Server và gọi cho C50 nhờ vả 
Đọc bài của bác gà mở mà em rối tung đầu, chả biết thảo luận cái gì nữa]]> /hvaonline/posts/list/41207.html#254020 /hvaonline/posts/list/41207.html#254020 GMT Case Study: phân tích hiện trường sau khi 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?" nên em đi sang chiều hướng phòng chống. Do bản thân em cũng chưa được trải nghiệm thực tế hay được chỉ dẫn qua nên có thế cái góc nhìn của em vẫn chưa được rõ ràng, các ý kiến nêu ra cũng chỉ là ý kiến cá nhân. Nhưng không sao :) tiếp tục lấy sự "hóng hớt" và "bồi dưỡng" thêm kiến thức và tiếp tục thảo luận là tiêu chỉ -:-) Ở đây chúng ta nắm được các thông tin sau:
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ụ.  
Điều cần làm trước hết khi sảy ra sự cố: 1) Dữ nguyên hiện trạng và cách ly máy chủ này. 2) Thông báo/ Cảnh báo đến người sử dụng. (Điều này nên thực hiện sớm nhất có thể, nó sẽ ảnh hưởng đến cách đánh giá từ phía người sử dụng) 3) Sử dụng máy chủ dự phòng để đưa dịch vụ hoạt động trở lại - song song đó tiến hành theo dõi kĩ lưỡng các truy cập (Nếu ta đứng ở phía attacker, với cái tâm lý "hả hê" thì cứ vài phút lại F5 trở lại coi thành quả của mình chẳng hạn =)) hoặc attacker vô tình để lộ thông tin.) Tiến hành phân tích máy chủ bị thâm nhập 1) Nhìn ngay vào cái đồng hồ, khoanh vùng thời gian sảy ra sự cố. 2) Khoanh vùng đối tượng. - Trước khi đi sâu vào kĩ thuật, xem xét khả năng nhân viên để lộ mật khẩu. - Kiểm tra các kết nối "đặc quyền" được cho phép từ bên ngoài. - Cuối cùng mới đi vào kĩ thuật. 3) Khi đi vào kĩ thuật, đầu tiên ta sẽ chú ý đến "hệ thống phòng thủ" vốn có - Lúc này xem xét lại khả năng phát hiện và ngăn chặn của hệ thống, ghi nhận những điểm yếu kém của nó - Góp phần giúp ta suy đoán ra phuơng thức attacker sử dụng. 4) Thu thập thông tin từ logs và tìm hiểu về lỗ hổng của phần mềm - Dựa vào những dấu hiệu mà ta suy đoán. Điều tra attacker (Còn tuỳ trường hợp và tình huống) 1) Dựa vào các thông tin thu thập được từ bước phân tích, ta đặt mình vào phía attacker. 2) Suy đoán những hướng đi và phuơng thức rồi tiến hành "đặt bẫy" - khả năng attacker trở lại cao. 3) Tìm hiểu thêm thông tin từ bên ngoài ...]]> /hvaonline/posts/list/41207.html#254035 /hvaonline/posts/list/41207.html#254035 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. 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ụ. Một máy chủ duy nhất, thông thường một vài đơn vị nhiều chí phí không thích sài dịch vụ shared hay dịch vụ server nằm trong 1 cụm server. Chuyện Server này như chuyện vác 1 cái server tới ISP, thuê chổ đặt, thê IP, thuê firewall(email,web,...), proxy server, thuê hoặc không thuê quản trị ở ISP. Và gần như là phó mặt luôn cho quản trị của ISP. Chuyện trên dẫn tiếp chuyện , HDH và tùm lum dịch vụ ở trên cái server đó có được update hay không, phải xem người đi gửi server có kí hợp đồng với ISP về công việc này không. Có yêu cầu thông báo tình trạng log gửi qua mail cho người gửi server hay không. Chuyện này lại càng phụ thuộc vào người gửi. Hai chuyện trên dẫn tiếp chuyện, người gửi server(khách hàng) có quan tâm tới LOG hoạt động của các dịch vụ, thường xuyên theo dõi bug có thể gây ra vấn đề dịch vụ gặp lỗi ngẫu nhiên, lỗi mất quyền truy cập dịch vụ vào tay kẻ xấu khai thác lỗi,.... bug-track Những chuyện trên sẽ là cơ sở để xem xét hiện trạng của server và các dịch vụ. Tình trạng nguyên thuỷ của các dịch vụ, HDH hay gọi là nguyên trạng có những gì. Sau đó , quản trị ở ISP đã thêm những configuration trực tiếp gì lên server, có ghi lại cấu hình sau đó không. Có cấu hình log liết gì không ? Có PLAN backup và có PLAN theo dõi LOG và thông báo sự cố không ? Lại tiếp tục tính tiếp việc theo dõi hiện trạng , sau khi có sự cố. Ghi nhận lại thời điểm mà sự cố xảy ra để làm một cái mốc thời gian, tuy có thể nó không thực sự đúng với thời điểm mà kẻ xấu đã khai thác 1 lỗi. Từ đó kiểm tra ngược lại, dịch vụ nào có lỗi gì được khai thác, thời điểm dịch vụ được thêm cấu hình, dịch vụ tạo được thêm, thay đổi, chèn 1 data,configuration vào để phục vụ cho việc khai thác lỗi. Đứng lại suy nghĩ tại sao để phán đoán tình hình, khách hàng thuê FIrewall tập trung của ISP nên không hề suy xét tới thiết lập các biện pháp hỗ trợ phán đoán sự cố ngay trên server, cập nhật server. Việc này khẳng định nghi ngờ chính các dịch vụ trên server bị thao túng. Và một vấn đề khác cũng phải xem lại, firewall của ISP là loại phục vụ cho vô vàn dịch vụ dùng chung. Có thể nó cũng đã cho qua một số truy vấn server, được phép và hợp lệ, tất nhiên là đối với nó. Công tác cụ thể tiếp theo là moi móc các dịch vụ và HDH. Chuyện này như chị gamma95 đề xuất, gọi C50 là một cách. Biện pháp cụ thể ra sao, mời các bác chuyên kiêm tra ra tay. ]]> /hvaonline/posts/list/41207.html#254036 /hvaonline/posts/list/41207.html#254036 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#254048 /hvaonline/posts/list/41207.html#254048 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#254070 /hvaonline/posts/list/41207.html#254070 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. - 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 ]]> /hvaonline/posts/list/41207.html#254106 /hvaonline/posts/list/41207.html#254106 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

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". ]]> /hvaonline/posts/list/41207.html#254110 /hvaonline/posts/list/41207.html#254110 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

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 :) 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ả #:S ]]> /hvaonline/posts/list/41207.html#254217 /hvaonline/posts/list/41207.html#254217 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

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 :P ), 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. ]]> /hvaonline/posts/list/41207.html#254576 /hvaonline/posts/list/41207.html#254576 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. 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.]]> /hvaonline/posts/list/41207.html#254581 /hvaonline/posts/list/41207.html#254581 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

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 :( ]]> /hvaonline/posts/list/41207.html#254631 /hvaonline/posts/list/41207.html#254631 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

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 ;). Nếu anh chấm cho nghiêm khắc thì điểm cao nhất là 40/100 ;).]]> /hvaonline/posts/list/41207.html#254637 /hvaonline/posts/list/41207.html#254637 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

.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ờ...:D, 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 ạ . ]]> /hvaonline/posts/list/41207.html#254683 /hvaonline/posts/list/41207.html#254683 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. => 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.   :D]]> /hvaonline/posts/list/41207.html#254695 /hvaonline/posts/list/41207.html#254695 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

.lht. wrote:
Ở trên mình có nói mà :D 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 :D]]> /hvaonline/posts/list/41207.html#254850 /hvaonline/posts/list/41207.html#254850 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

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" ]]> /hvaonline/posts/list/41207.html#254947 /hvaonline/posts/list/41207.html#254947 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. "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 :| quá chú ý vào "phòng tránh" nên không nghĩ đến khía cạnh này ... #:S ]]> /hvaonline/posts/list/41207.html#254972 /hvaonline/posts/list/41207.html#254972 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#254989 /hvaonline/posts/list/41207.html#254989 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#255090 /hvaonline/posts/list/41207.html#255090 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

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% B-)  
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.]]> /hvaonline/posts/list/41207.html#255094 /hvaonline/posts/list/41207.html#255094 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#255100 /hvaonline/posts/list/41207.html#255100 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

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% B-)  
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 ]]> /hvaonline/posts/list/41207.html#255200 /hvaonline/posts/list/41207.html#255200 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

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.]]> /hvaonline/posts/list/41207.html#255228 /hvaonline/posts/list/41207.html#255228 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

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?]]> /hvaonline/posts/list/41207.html#255399 /hvaonline/posts/list/41207.html#255399 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

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?]]> /hvaonline/posts/list/41207.html#255432 /hvaonline/posts/list/41207.html#255432 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#255503 /hvaonline/posts/list/41207.html#255503 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. 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 ;). 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).]]> /hvaonline/posts/list/41207.html#255570 /hvaonline/posts/list/41207.html#255570 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. 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 ;) ............................]]> /hvaonline/posts/list/41207.html#255586 /hvaonline/posts/list/41207.html#255586 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

.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.]]> /hvaonline/posts/list/41207.html#255591 /hvaonline/posts/list/41207.html#255591 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

.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.]]> /hvaonline/posts/list/41207.html#255610 /hvaonline/posts/list/41207.html#255610 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#255621 /hvaonline/posts/list/41207.html#255621 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. ó 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]]]> /hvaonline/posts/list/41207.html#255628 /hvaonline/posts/list/41207.html#255628 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#255634 /hvaonline/posts/list/41207.html#255634 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

.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ủ" ;). 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 ;) 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.]]> /hvaonline/posts/list/41207.html#255640 /hvaonline/posts/list/41207.html#255640 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. 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? ;) ). ]]> /hvaonline/posts/list/41207.html#255651 /hvaonline/posts/list/41207.html#255651 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. 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 :D

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 :P (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 :*- 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 :D) 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 =)) 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 :D 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 :P ) => 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ễ -:-) ). 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 :D => Đô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 :D - 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 #:S ]]> /hvaonline/posts/list/41207.html#255696 /hvaonline/posts/list/41207.html#255696 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

Ky0 wrote:
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.  
Điểm này e là rất khó Ky0.]]> /hvaonline/posts/list/41207.html#255706 /hvaonline/posts/list/41207.html#255706 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

Phó Hồng Tuyết wrote:

Ky0 wrote:
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.  
Điểm này e là rất khó Ky0. 
Trong quá trình forensic mỗi công đoạn có cái khó riêng nhất là việc thiếu hụt thông tin :P. Điểm mà Phó Hồng Tuyết đề cập sẽ vô cũng khó khăn nếu log trên server bị xóa hoàn toàn. Chưa hết việc thu thập log trong vòng 1 tháng vào server là việc khá khó khăn nếu ISP chỉ lưu trữ log trong vòng một tuần chẳng hạn. Việc phác họa về hacker dựa trên các thông tin và dấu vết có chính xác và chi tiết hay không phụ thuộc rất nhiều vào năng lực của điều tra viên. Mình chỉ đưa ra các bước tổng quát trong quá trình forensic và có lấy ví dụ với thông tin ít ỏi mình có được. Nếu ISP và BKAV cung cấp cho mình thêm thông tin và log thì mình sẽ có ví dụ để phân tích cụ thể hơn ;) - Ky0 -]]> /hvaonline/posts/list/41207.html#255730 /hvaonline/posts/list/41207.html#255730 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#255775 /hvaonline/posts/list/41207.html#255775 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#255918 /hvaonline/posts/list/41207.html#255918 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

LeVuHoang wrote:
Em đoán ý của mrro là IP chỉ là 1 mảnh của forensic, nhiều thứ còn có thể dựa vào behaviour. Ví dụ như trong trường hợp BKAV sẽ là: 1. Khoanh vùng đối tượng, chắc chắn hay ít nhất sẽ có mối quan hệ giữa anh chàng bị bắt và BKAVOp. 2. Ngày trước mấy con bot của STL viết bằng VC++, nếu không may viết bằng Delphi chắc em cũng có trong danh sách bị tình nghi =]] Nói chung, các biện pháp kỹ thuật là 1 phần trong cuộc điều tra, để xem vài ngày nữa có tình tiết nào mới không. Ngoài ra, theo ý riêng của em, vì BKAV không lường trước được sự việc là sẽ bị hack nên có thể đã bị cài backdoor từ lâu rồi mà không để ý --> các log quan trọng không giữ được hay khó để lần ra lại từ đầu mà ngay cả hiện nay không biết nội bộ BKAV đã biết được hổng chỗ nào chưa để fix. 
Anh nghĩ nghiệp vụ thu hẹp biên độ thì make sense nhưng chỉ dựa vào IP của t0r mà điều tra thì vô khả thi. Anh thử analyse những packets đi xuyên qua t0r tunnel đến HVA thì thấy chúng hoàn toàn bình thường và hợp lệ. Không có bất cứ một signature nào đặc biệt để có thể tách rời nó ra mà điều tra. Điểm vô vọng nhất là xác định bao nhiêu t0r "exit nodes" mà packets đi xuyên qua để trace ngược lại IP nguyên thuỷ của người dùng. Nhìn cái hình này thì đúng là bó chiếu:
Giả sử những cái X màu xanh ở trên là những IP random của người dùng t0r khắp nơi trên thế giới mà họ đã set trong t0r client:
thì làm sao mà trace? Những IP của người dùng chẳng những là những dynamic IP (thay đổi thường xuyên) mà chính t0r path cũng thay đổi liên tục thì quả là bó tay.]]> /hvaonline/posts/list/41207.html#255943 /hvaonline/posts/list/41207.html#255943 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. @conmale: bọn em có làm việc với nhóm Tor khi công bố BEAST và kết luận, đúng như anh nhận xét, Tor không bị ảnh hưởng bởi BEAST vì họ sử dụng miếng vá của OpenSSL từ đầu [1]. dẫu vậy thì ý của em không phải là nói đến độ an toàn của Tor. mời anh xem tiếp để rõ ý em. @al0nex: cảm ơn vì bạn đã đưa ra một nhận xét rất thú vị: BKIS sẽ bỏ ra bao nhiêu tiền để truy lùng thủ phạm (và rốt cuộc sẽ thu lại được gì)? @.lht.: phác thảo về cách phát hiện thủ phạm của bạn dùng Javascript cookie chính là điều mà mình muốn nói đến. thực tế thì ngoài địa chỉ IP, sử dụng Tor hay không sử dụng Tor và Javascript cookie ra, còn có rất nhiều cách khác để một website có thể theo dõi được chúng ta. những kết quả nghiên cứu gần đây cho thấy rất khó để có thể trở nên ẩn danh hoàn toàn khi duyệt web [2] [3] [4]. điểm yếu cốt lõi, mà mình đã có lần đề cập, là attacker thường không có ý định xâm nhập trong những lần đầu tiên viếng thăm nạn nhân. dựa quan sát này và các kết quả nghiên cứu ở trên, người ta hoàn toàn có thể "đánh dấu" trình duyệt của attacker, để rồi khi attacker thực hiện tấn công, hoặc quay lại hiện trường để dò la tin tức, người ta có thể nhanh chóng nhận ra anh attacker này là ai trong quá khứ, mặc dù anh ấy đã cố tính đi xuyên qua Tor. nói nôm na là mặc dù đã che đi khuôn mặt, nhưng hình xăm trên tay hoặc giọng nói hoặc cử chỉ vẫn có thể tố cáo thủ phạm. để triển khai được một hệ thống theo dõi như thế này cũng không quá khó. dẫu vậy ở nhiều quốc gia, theo dõi người dùng như thế là một hành động không được hoan nghênh và có khi là phạm luật. mình nghĩ đối với một công ty như BKIS thì họ hoàn toàn có thể triển khai một hệ thống như thế, nhưng mình không tin là họ đã, đang hoặc sẽ làm. đơn giản vì có những việc đơn giản hơn nhiều và có hiệu quả tức thì như kiện toàn hệ thống mà họ còn không làm, thì khó mà hình dung họ sẽ đầu tư cho những biện pháp có tính phòng xa như thế này. ở góc nhìn ngược lại, attacker muốn không bị theo dõi thì phải cập nhật và hiểu rõ những nghiên cứu mới nhất về web security & privacy mà mình đề cập ở trên, rồi tìm cách tự bảo vệ bản thân, một việc mà mình cho là khó hơn rất nhiều so với tấn công BKIS. nhân tiện mình cũng muốn nói đây là một chủ đề mà mình đã dự tính trình bày ở TetCon 2012, nhưng do không tìm được người làm cùng nên đành phải gác lại. nếu bạn .lht. hoặc ai đó có hứng thú thì mình sẽ rất sẵn sàng hỗ trợ bạn nghiên cứu về vấn đề này, như là một đề tài của TetCon 2013. chúng ta có thể triển khai đề tài này theo hai góc nhìn: góc nhìn của người dùng cuối muốn bảo vệ riêng tư khi duyệt web và góc nhìn của những attacker muốn ẩn danh khi hành sự. mình nghĩ đây là một đề tài rất thú vị, có khả năng tìm ra những kỹ thuật mới chưa được công bố. -m [1] https://blog.torproject.org/blog/tor-and-beast-ssl-attack [2] http://samy.pl/evercookie/ [3] https://grepular.com/Abusing_HTTP_Status_Codes_to_Expose_Private_Information [4] https://panopticlick.eff.org/]]> /hvaonline/posts/list/41207.html#255945 /hvaonline/posts/list/41207.html#255945 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

mrro wrote:
giờ mới có thời gian xem chủ đề này một cách rốt ráo. @conmale: bọn em có làm việc với nhóm Tor khi công bố BEAST và kết luận, đúng như anh nhận xét, Tor không bị ảnh hưởng bởi BEAST vì họ sử dụng miếng vá của OpenSSL từ đầu [1]. dẫu vậy thì ý của em không phải là nói đến độ an toàn của Tor. mời anh xem tiếp để rõ ý em.  
Thanks em. Đọc phản hồi cụ thể của em, anh mới hiểu rõ ý em. Trong chủ đề ở mục "Các thảo luận khác", em có cảnh báo là t0r có thể không an toàn cho nên anh cứ nghĩ là bản thân t0r không an toàn cho nên mới lò dò tìm hiểu. Vậy cũng tốt vì ít ra mình xác nhận được là t0r (client và server) an toàn nếu như user không dùng thêm những thứ linh tinh như flash, java applets...v..v...

mrro wrote:
@al0nex: cảm ơn vì bạn đã đưa ra một nhận xét rất thú vị: BKIS sẽ bỏ ra bao nhiêu tiền để truy lùng thủ phạm (và rốt cuộc sẽ thu lại được gì)? @.lht.: phác thảo về cách phát hiện thủ phạm của bạn dùng Javascript cookie chính là điều mà mình muốn nói đến. thực tế thì ngoài địa chỉ IP, sử dụng Tor hay không sử dụng Tor và Javascript cookie ra, còn có rất nhiều cách khác để một website có thể theo dõi được chúng ta. những kết quả nghiên cứu gần đây cho thấy rất khó để có thể trở nên ẩn danh hoàn toàn khi duyệt web [2] [3] [4]. điểm yếu cốt lõi, mà mình đã có lần đề cập, là attacker thường không có ý định xâm nhập trong những lần đầu tiên viếng thăm nạn nhân. dựa quan sát này và các kết quả nghiên cứu ở trên, người ta hoàn toàn có thể "đánh dấu" trình duyệt của attacker, để rồi khi attacker thực hiện tấn công, hoặc quay lại hiện trường để dò la tin tức, người ta có thể nhanh chóng nhận ra anh attacker này là ai trong quá khứ, mặc dù anh ấy đã cố tính đi xuyên qua Tor. nói nôm na là mặc dù đã che đi khuôn mặt, nhưng hình xăm trên tay hoặc giọng nói hoặc cử chỉ vẫn có thể tố cáo thủ phạm. để triển khai được một hệ thống theo dõi như thế này cũng không quá khó. dẫu vậy ở nhiều quốc gia, theo dõi người dùng như thế là một hành động không được hoan nghênh và có khi là phạm luật. mình nghĩ đối với một công ty như BKIS thì họ hoàn toàn có thể triển khai một hệ thống như thế, nhưng mình không tin là họ đã, đang hoặc sẽ làm. đơn giản vì có những việc đơn giản hơn nhiều và có hiệu quả tức thì như kiện toàn hệ thống mà họ còn không làm, thì khó mà hình dung họ sẽ đầu tư cho những biện pháp có tính phòng xa như thế này. ở góc nhìn ngược lại, attacker muốn không bị theo dõi thì phải cập nhật và hiểu rõ những nghiên cứu mới nhất về web security & privacy mà mình đề cập ở trên, rồi tìm cách tự bảo vệ bản thân, một việc mà mình cho là khó hơn rất nhiều so với tấn công BKIS.  
Trước kia anh đã từng dính vô vài projects thiết kế IDS và data mining cho nó. Thiết lập thì không khó nhưng khó ở chỗ có nhân lực và tài nguyên để duy trì và thường xuyên theo dõi hay không thôi :P . Trong trường hợp BKAV hoặc những ứng dụng trên tầng web thì có lẽ Splunk là best candidate cho công tác theo dõi. Xét ở góc độ chuyên nghiệp của kẻ tấn công theo anh thấy quả là không hẳn nằm ở attack vectors mà nằm ở chỗ "cover tracks". Covering tracks không những nằm ở biên độ và hiện trường nơi tấn công mà còn trải dài nhiều khu vực khác. Đối với "dấu vết" anh có thể thu thập được từ wearmon vì anh chàng đã đăng nhập HVA nhiều lần, sau khi phân tích, anh thấy bế tắc vì nó muôn trùng. Tuy vậy, đôi khi chính những thông tin mà "anonymous VN" gì đó tung ra lại hàm chứa những "dấu vết" nào đó :P . Cái này thì phải cần đến nghiệp vụ phân tích ở mảng khác chớ không trực tiếp là computer forensics.

mrro wrote:
nhân tiện mình cũng muốn nói đây là một chủ đề mà mình đã dự tính trình bày ở TetCon 2012, nhưng do không tìm được người làm cùng nên đành phải gác lại. nếu bạn .lht. hoặc ai đó có hứng thú thì mình sẽ rất sẵn sàng hỗ trợ bạn nghiên cứu về vấn đề này, như là một đề tài của TetCon 2013. chúng ta có thể triển khai đề tài này theo hai góc nhìn: góc nhìn của người dùng cuối muốn bảo vệ riêng tư khi duyệt web và góc nhìn của những attacker muốn ẩn danh khi hành sự. mình nghĩ đây là một đề tài rất thú vị, có khả năng tìm ra những kỹ thuật mới chưa được công bố. -m [1] https://blog.torproject.org/blog/tor-and-beast-ssl-attack [2] http://samy.pl/evercookie/ [3] https://grepular.com/Abusing_HTTP_Status_Codes_to_Expose_Private_Information [4] https://panopticlick.eff.org/ 
Đề tài này rất lý thú. Nó đòi hỏi kiến thức rất sâu và rất rộng cộng thêm khả năng forensics nữa. Nếu khai triển thì hay lắm em.]]> /hvaonline/posts/list/41207.html#255950 /hvaonline/posts/list/41207.html#255950 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#255959 /hvaonline/posts/list/41207.html#255959 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

mrro wrote:
giờ mới có thời gian xem chủ đề này một cách rốt ráo. @conmale: bọn em có làm việc với nhóm Tor khi công bố BEAST và kết luận, đúng như anh nhận xét, Tor không bị ảnh hưởng bởi BEAST vì họ sử dụng miếng vá của OpenSSL từ đầu [1]. dẫu vậy thì ý của em không phải là nói đến độ an toàn của Tor. mời anh xem tiếp để rõ ý em. @al0nex: cảm ơn vì bạn đã đưa ra một nhận xét rất thú vị: BKIS sẽ bỏ ra bao nhiêu tiền để truy lùng thủ phạm (và rốt cuộc sẽ thu lại được gì)? @.lht.: phác thảo về cách phát hiện thủ phạm của bạn dùng Javascript cookie chính là điều mà mình muốn nói đến. thực tế thì ngoài địa chỉ IP, sử dụng Tor hay không sử dụng Tor và Javascript cookie ra, còn có rất nhiều cách khác để một website có thể theo dõi được chúng ta. những kết quả nghiên cứu gần đây cho thấy rất khó để có thể trở nên ẩn danh hoàn toàn khi duyệt web [2] [3] [4]. điểm yếu cốt lõi, mà mình đã có lần đề cập, là attacker thường không có ý định xâm nhập trong những lần đầu tiên viếng thăm nạn nhân. dựa quan sát này và các kết quả nghiên cứu ở trên, người ta hoàn toàn có thể "đánh dấu" trình duyệt của attacker, để rồi khi attacker thực hiện tấn công, hoặc quay lại hiện trường để dò la tin tức, người ta có thể nhanh chóng nhận ra anh attacker này là ai trong quá khứ, mặc dù anh ấy đã cố tính đi xuyên qua Tor. nói nôm na là mặc dù đã che đi khuôn mặt, nhưng hình xăm trên tay hoặc giọng nói hoặc cử chỉ vẫn có thể tố cáo thủ phạm.  
Nếu ngay từ khi bắt đầu dò thông tin về victim đến lúc quay lại hiện trường để dò la tin tức, mọi thông tin về trình duyệt đều được ngẫu nhiên hóa (randomize) thì làm sao tạo được mối liên hệ giữa những lần đầu tiên viếng thăm nạn nhân và lúc bắt đầu thăm dò nạn nhân cho đến các hoạt động về sau? Nếu như attacker ngay từ đầu đã xác định mọi hành động đơn giản nhất từ việc thu thập thông tin liên quan đến bảo mật của victim đến các hành động về sau đều cần phải được thực hiện trong một máy ảo riêng với một trình duyệt riêng (ví dụ: Tor Browser Bundle) ở tiệm Cafe Internet/nơi có Public WiFi hoặc xuyên qua Tor network và không để lại một message nào ở website của victim thì ngoài thông tin về trình duyệt, còn có thể dựa vào thông tin nào khác để theo dõi người truy cập như mrro đề cập nữa không?]]> /hvaonline/posts/list/41207.html#255981 /hvaonline/posts/list/41207.html#255981 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.
Bây giờ mình giả sử C50 muốn điều tra người tấn công vào BKAV Forum (mình sẽ bỏ qua vụ phân tích log trước mà tập trung vào việc hacker đó sử dụng Tor để tấn công vào BKAV Forum) Câu hỏi đặt ra, nếu thói quen của "đối tượng" tấn công thành công vào BKAV Forum sau đó im hơi lặng tiếng,đánh bài chuồn...chẳng tiếp xúc với internet thì làm sao mà C50, ISP VN, doanh nghiệp bị hại bắt được hacker này. Trong khi đó khi người lập ra dịch vụ, cũng như người sử dụng tor đâu ai biết ai là ai !! Như mrro có đề cập đến vấn đề "cách phát hiện thủ phạm của bạn dùng Javascript cookie" giả sử như lúc này thu thập cookie của "nghi phạm" tình nghi trong khi đó nghi phạm chỉ 1 lần duy nhất thăm cái wesite này và hàng ngày có hàng chục ngàn lượt truy cập thì có khác nào mò kim xuống đáy biển. :) ]]> /hvaonline/posts/list/41207.html#256000 /hvaonline/posts/list/41207.html#256000 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#256033 /hvaonline/posts/list/41207.html#256033 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

vd_ wrote:
@bolzano_1989 mrro có nói đến evercookie => browser của attacker sẽ bị mark bằng 1 cookie đặc biệt, nên nếu attacker ghé thăm các domain mà cxx control thì cxx có thể rút ra một số lượng thông tin kha khá. Anh conmale cũng có nói đến social engineering, tui nghĩ trong trường hợp này social engineering sẽ hữu hiệu hơn là technical solution. Bởi vậy các bạn chém gió nên chém vừa vừa thôi :D ( xem phim Mỹ mấy ông cớm hay chơi chiêu hù mấy em giang hồ vặt rồi lượm lặt vòng vo sẽ đến trùm ) 
Bạn để ý mình nêu ở trên là chỉ dùng 1 bản Tor Browser Bundle để duyệt website victim (không dùng bất cứ trình duyệt nào khác để vào website victim), dùng xong thì xóa luôn :) . Chú ý là nên kết hợp thêm extension NoScript khi duyệt website thông thường (đặc biệt là các website và diễn đàn Việt Nam hay quốc gia mà attacker đang sinh sống thì không bao giờ allow JavaScript -:-) ). Khi đã có ý định thăm dò bảo mật thì attacker có thể chạy Tor Browser Bundle trong máy ảo được setup riêng hoặc trong môi trường sandbox, dùng xong thì dọn dẹp sandbox luôn. => Đảm bảo website victim không lưu lại vết nào trong máy tính của attacker. => Khi truy cập các website khác bằng máy thật, không có vết nào để thu thập từ evercookie cả. Giả sử C50 có kiểm soát được các forum hay website thông dụng để tạo và lấy được evercookie thì liệu họ có cơ sở nào để tạo được mối liên hệ giữa việc truy cập website khác (bằng trình duyệt thật thường dùng) với việc truy cập website victim như trên?]]> /hvaonline/posts/list/41207.html#256044 /hvaonline/posts/list/41207.html#256044 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#256091 /hvaonline/posts/list/41207.html#256091 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#256125 /hvaonline/posts/list/41207.html#256125 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

WinDak wrote:
Nếu kịch bản là: - Hacker login vào một free VPS, online bằng TOR - Cài máy ảo (VM) - Cài 1 hệ điều hành Linux fresh vào VM - Tấn công BKAV qua trình duyệt và application của VM - Xóa harddisk của VM - Ngắt kết nối với VPS - Không bao giờ sử dụng VPS đó nữa (disable service hoặc terminate plan) Rõ ràng cho dù có evercookie thì nó cũng chỉ save browser của máy ảo Như vậy liệu có cách nào phát hiện được không ? Mọi người cho ý kiến ? 
MAC là dấu chân asin trong trường hợp bạn nêu ở trên. nếu VPS Free thì yêu cầu là bạn phải đăng ký dịch vụ (dính MAC - thậm chí là IP thật), thông tin sẽ được lưu lại nơi bạn đăng ký Free VPS. Nếu VPS do bạn của bạn share thì mức độ nguy hiểm cao hơn. --- trở lại vấn đề : VPS thì tất nhiên nó có ip tĩnh. khi có ip này sẽ truy ra được nhà cung cấp dịch vụ nào. Yêu cầu xin log của người mua VPS đó hoặc log đăng ký VPS. Khi có được log này thì sẽ có khả năng có được IP thật và MAC * nếu dùng FAKE IP : thì khó xác định. * IP Thật + MAC : :| ]]> /hvaonline/posts/list/41207.html#256148 /hvaonline/posts/list/41207.html#256148 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

Phó Hồng Tuyết wrote:
MAC là dấu chân asin trong trường hợp bạn nêu ở trên. nếu VPS Free thì yêu cầu là bạn phải đăng ký dịch vụ (dính MAC - thậm chí là IP thật), thông tin sẽ được lưu lại nơi bạn đăng ký Free VPS. Nếu VPS do bạn của bạn share thì mức độ nguy hiểm cao hơn. --- trở lại vấn đề : VPS thì tất nhiên nó có ip tĩnh. khi có ip này sẽ truy ra được nhà cung cấp dịch vụ nào. Yêu cầu xin log của người mua VPS đó hoặc log đăng ký VPS. Khi có được log này thì sẽ có khả năng có được IP thật và MAC * nếu dùng FAKE IP : thì khó xác định. * IP Thật + MAC : :|  
Bạn có đọc kỹ tôi viết không vậy ? Tôi có nói rõ là sử dụng TOR, vậy thì trace về VPS như thế nào ? Chưa kể những dịch vụ như Amazon EC2 còn cho phép tạo và xóa VPS trong tài khoản cá nhân 1 cách tùy ý, và cũng không thấy có điểm nào đòi bạn phải đăng ký MAC address cả Mời bạn trình bày tiếp.]]> /hvaonline/posts/list/41207.html#256166 /hvaonline/posts/list/41207.html#256166 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

.lht. wrote:
Attacker: Tor thì hại gì chứ ? Me: Phiền bạn ghé qua đây ;) https://check.torproject.org/?lang=vi 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. 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ả :-" 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 ? 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 ...  

.lht. wrote:
Để đạ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 ? 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 !  

mrro wrote:
người ta hoàn toàn có thể "đánh dấu" trình duyệt của attacker, để rồi khi attacker thực hiện tấn công, hoặc quay lại hiện trường để dò la tin tức, người ta có thể nhanh chóng nhận ra anh attacker này là ai trong quá khứ, mặc dù anh ấy đã cố tính đi xuyên qua Tor. nói nôm na là mặc dù đã che đi khuôn mặt, nhưng hình xăm trên tay hoặc giọng nói hoặc cử chỉ vẫn có thể tố cáo thủ phạm.  
Hehe, tôi có tìm hiểu và sử dụng Tor từ lâu và nhưng tôi chưa bao giờ tìm hiểu Tor an toàn tới mức nào. Thật ra bây giờ tôi nhìn vào thứ này mà chú conmale đưa ra thì tôi mới bắt đầu cảm thấy "hãi" vì độ cover track của Tor là quá kinh khủng

conmale wrote:
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" 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)"  
Ở bài viết sau đây, tôi xin mạn phép giới thiệu về khả năng cover-backtrack của Tor tại client,vì tôi thấy có .lht. và mrro không tin lắm về sự cẩn thận của tor, và phần này cũng khá thú vị ^_^. Như mọi người đã biết, Tor-client chỉ đơn thuần là một client proxy làm nhiệm vụ kết nối tới Tor-server, nếu bạn nào lên trang download của tor mà down tor về thôi, bật lên thì chắc chắn là vẫn không truy cập được bằng proxy. Vì lý do là cần phải có một công cụ định hướng traffic (hoặc setup tay) từ browser => tor-client. Trong gói cài đặt thì Tor có một công cụ như thế gọi là Tor-button. Và extension này cực kỳ lợi hại, mời mọi người xem qua về document: https://www.torproject.org/torbutton/torbutton-options.html.en. Theo như tài liệu thì tôi thấy Tor-button chỉ ra các "vết" có thể để lại và đã vá như sau. 1. Disable các plugin khác như Flash, Java, QuickTime, SilverLight, ..... 2. Làm nhiễu các đoạn javascript/CSS ẩn với nhiệm vụ reload liên tục, để khi user exit-Tor thì sẽ reveal IP của user ^_^, ngoài ra cũng có CSS popup nữa 3. Hook và mask các Date-object tại client-side, chú ý là timezone tại client side và nó có thể get bằng lệnh đại loại như sau: http://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_gettimezoneoffset 4. Window dimension. Cái này là độ to khi bạn dùng trình duyệt, nếu mà luôn luôn mở dạng full-screen thì khi bị lấy thông tin, ví dụ như tôi dùng màn hình 1024x768, lúc điều tra ra 3 nghi can, 2 nghi can dùng màn hình rộng, có mỗi tôi là 1024x768 thì tôi sẽ bị tình nghi nhiều hơn ^_^. Ở đây Tor-button chuyển toàn bộ dimension về dạng bội số của 50px 5. Block Tor/Non-Tor access vào internet từ những url có dạng file:// 6. Cấm truy cập history 7. Disable DOM Storage 8. Cookie: Store Non-Tor cookies in a protected jar => Non-Tor cookie sẽ được bảo vệ và che giấu 9. Spoof US English Browser. Bạn nào dùng Firefox-Vi thì sau khi activated Tor-button, bạn sẽ trở thành Firefox-En :D 10. Chỉnh sửa User-agent. Ở đây tor-button có nói rằng tất cả tor-user sẽ có một uniform, và đó là: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0 11. Và một số chuyện rắc rối khác xảy ra từ extension khác, hay là lúc crash firefox,....... Tôi thử bật tor-button và đi vào youtube, thì tôi thấy rằng: https://lh3.googleusercontent.com/-AEVLtW84_zE/T01GrEedRaI/AAAAAAAABOo/tFAPL2yPnGQ/s1280/noyoutube.png
không thể load được youtube :D vì flash đã bị disable Như vậy là ít nhất là Flash đã bị vô hiệu hóa, các evercookie khác như Java, HTML5, .... thì tôi không rành lắm nên không thử được. Bây giờ tôi thử get Time, window dimension và user-agent. Hình sau cho thấy time và các giá trị về dimension cũng đã bị mask
Ngoài ra có một điểm khá thú vị về User-Agent mà tôi vừa tranh cãi là thế này. Liệu Tor-client có giúp chúng ta chỉnh sửa user-agent hay không hay chỉ có Tor-button mới làm việc đó, hay là Tor exit-node quyết định đến User-Agent ? Thì tôi kiểm định bằng cách bật Tor-client, nhưng không dùng tor-button mà tự tay setup proxy thì tôi bị lộ user-agent, mặc dù có thể thấy là IP của tôi không phải là IP VN nữa https://lh4.googleusercontent.com/-cofv0fUv3rk/T01GqZ0xbNI/AAAAAAAABOo/I-MHNVjAmuM/s1280/nontorbutton.png
Còn đây là sau khi bật Tor-button https://lh6.googleusercontent.com/-qVBBlyNJEmY/T01GpwCpWlI/AAAAAAAABOo/C9wwAcuvE38/s1280/torbutton.png
https://lh5.googleusercontent.com/-r8e9rA1b1io/T01Gsd3ikWI/AAAAAAAABOo/Hs7W7YVB8Sg/s1024/ubuntu.png
Và như vậy đúng như trong document đã ghi: "User agent masking is done with the idea of making all Tor users appear uniform" - điều này làm giảm đi sự bất thường khi bạn dùng một distro độc của linux chẳng hạn, sẽ khó mà dò ra bạn là ai một khi bạn đã khoác chiếc áo Tor. Như vậy có thể thấy rằng khá nhiều fingerprint mà chúng ta thường hay không để ý thì Tor-button/Tor-browser đã bít khá nhiều. Tôi không chắc là có còn lỗ hổng nào nữa không, nhưng nếu dùng các side-attack như evercookie, cookie, history, file-url-access, timezone như bạn .lht. đã nêu thì chúng ta có thể hoàn toàn yên tâm là tor đã handle hết vụ này ^_^. Tôi có thấy là weareanon có user-agent ban đầu hơi giống với user-agent uniform của tor-users, chỉ khác ở chỗ bị bôi đỏ ("Mozilla/5.0 (Windows; U; X11; Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" , nên weareanon có khả năng cao là đang dùng tor-browser rồi. Ngoài ra nếu cài thử Tor-browser thì sẽ thấy Tor-browser sẽ bonus thêm cho ta những gì ? a. Tor-browser có cài Tor-button b. Noscript :D nhưng tôi ko biết nó để làm gì nên bạn nào rành về nó thì phân tích giùm tôi. c. HTTPS everywhere. d. Mỗi khi tắt Tor-browser, toàn bộ dữ liệu sẽ bị xóa sạch. e. Tôi vào tab plugin (thường thì thấy plugin-flash nằm ở đấy) và phát hiện ra là nó trống trơn :D => hoàn toàn không phải lo ngại gì về super-cookie. Sẵn bàn về weareanon, sáng hôm qua tôi có nghĩ đến một hướng khác để tìm ra weareanon. Tôi nghĩ là để download tor thì tôi chỉ việc vào google, gõ "tor", enter, vào trang torpoject.com và download tor. Vậy ở đây điểm yếu của weareanon là xác xuất mà weareanon connect đến torproject.org mà không có sự bảo vệ là rất cao, mà chưa kể là trong vòng mấy tháng qua theo tôi là hầu như ít có ai quan tâm tới tor cho lắm nên việc khoanh vùng dựa vào đây thì sẽ rất dễ. Nhưng tôi nghĩ là xác xuất mà ISP VN ghi hết cái mớ log đó là rất thấp vì không có log nào chứa nổi, chưa kể 50/50 là weareanon không phải đang ở VN vì thông tin về họ rất là mập mờ. Không biết mọi người nghĩ sao về nhận định này ?]]> /hvaonline/posts/list/41207.html#256170 /hvaonline/posts/list/41207.html#256170 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

.lht. wrote:
Về mảng social engineering thật sự em thấy hay và không "tởm" như anh conmale nghĩ :D Ở VN thường thấy nhất ở trường học, người ta chỉ "chú trọng" vào kiến thức mà "không quan tâm" đến khả năng giao tiếp của học sinh ... Trong lĩnh vực security cũng vậy anh ạ, ngoài kĩ thuật tốt thì social engineering thật sự là 1 mảng rất hay đáng để nghiên cứu và thảo luận :D  
He he, em gom chung "social engineering" với mọi dạng "khả năng giao tiếp" rồi. Khả năng giao tiếp trên căn bản trung thực và trong sáng (A) hoàn toàn khác khả năng giao tiếp trên căn bản thủ đoạn, mưu mẹo và thậm chí lừa lọc (B). Social engineering nhằm khai thác thông tin ít khi nào dừng lại ở A mà hầu như cần phải khai thác tối đa ở B. Tởm là tởm ở chỗ đó. Đối với anh, khoảng A là cần thiết và rất nên phát huy nhưng B thì không nên. Xã hội nay càng lúc càng nhiều lừa lọc, ranh mãnh và giả tạo rồi. Xây dựng thêm cái B chỉ thêm hại.]]> /hvaonline/posts/list/41207.html#256171 /hvaonline/posts/list/41207.html#256171 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. @WinDak, bolzano_1989: trong một thế giới lý tưởng thì kẻ tấn công sẽ trở nên hoàn hảo và không phạm phải bất kỳ sai lầm nào như hai bạn mô tả. dẫu vậy có hai điểm mà các bạn cần lưu ý. thứ nhất, các kịch bản mà các bạn đưa ra đều dựa trên giả thuyết là kẻ tấn công đã biết lỗi của BKIS từ trước. câu hỏi là làm thế nào mà kẻ tấn công tìm được lỗ hổng này? và trong quá trình tìm kiếm, thử nghiệm lỗ hổng đó, bạn có chắc chắn rằng kẻ tấn công sẽ thực hiện tất cả những gì mà bạn đưa ra trong kịch bản hay không? mình có nói ở trên, điểm khác biệt mấu chốt là tâm lý của kẻ tấn công. trong giai đoạn tìm kiếm, thử nghiệm lỗ hổng, rất có thể kẻ tấn công vẫn chưa có một ý định gì cụ thể (chẳng hạn như dùng lỗ hổng để deface BKIS). vì lẽ đó, rất có thể kẻ tấn công sẽ không quá cẩn thận và chính sự không cẩn trọng này sẽ tố cáo kẻ tấn công khi anh ta thực hiện tấn công, mặc dù lúc này anh ấy đã rất cẩn thận. cá nhân mình từng thấy ít nhất 2-3 trường hợp như thế này trong thực tế rồi. thứ hai, chúng ta đang giả định: kẻ tấn công biết và hiểu rõ các kỹ thuật theo dõi trên web. chính sự hiểu biết này giúp cho kẻ tấn công xây dựng được một kịch bản như hai bạn đưa ra. câu hỏi là chuyện gì sẽ xảy ra nếu kẻ tấn công không biết đến các kỹ thuật này? thực tế là không riêng gì kẻ tấn công mà tất cả chúng ta đều không (thể) sợ và không (thể) phòng ngừa những nguy cơ mà chúng ta không biết. @kinggreedy1991: bạn nên tìm hiểu thật kỹ về các kỹ thuật theo dấu trên web dựa theo các tài liệu mà mình liệt kê ở trên, rồi từ đó hẵng hãy tìm hiểu tiếp xem Tor-browser với Tor-button có thật sự giúp bạn tránh bị theo dõi hay không. đây là một thử nghiệm thú vị, nên làm và sau khi làm xong nên gửi lên HVA để bàn thảo. mình thấy bạn chưa hiểu bản chất của các kỹ thuật theo dõi, mà chỉ thực hiện vài bài kiểm tra qua loa rồi kết luận là chỉ cần sử dụng Tor-browser với Tor-button là an toàn. ảo tưởng về khả năng của công cụ là tiếc nuối lớn nhất của các cầu thủ Juventus ;-). -m ]]> /hvaonline/posts/list/41207.html#256174 /hvaonline/posts/list/41207.html#256174 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#256192 /hvaonline/posts/list/41207.html#256192 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

mrro wrote:
tất cả chúng ta đều không (thể) sợ và không (thể) phòng ngừa những nguy cơ mà chúng ta không biết.  
Câu này đã nghe mrro nhắc đến rất nhiều lần trước đây mà hình như không thấy ai nhớ đến :D ]]> /hvaonline/posts/list/41207.html#256206 /hvaonline/posts/list/41207.html#256206 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

vd_ wrote:
@bolzano_1989 Tui đang nghĩ đến hướng indirect tiếp cận đến attacker. Ví dụ attacker nếu đủ khả năng thì sẽ xoá dấu vết bằng cách xoá máy ảo, trình duyệt v.v... Nhưng ở đây chúng ta chú ý là attacker còn thường xuyên vào các diễn đàn bàn về sự việc này để công bố và nghe ngóng, như vậy không lẽ mỗi lần post bài ở hva hay blogspot thì attacker (hoặc bạn của attacker) phải lặp lại hoàn toàn chu kỳ cài vm - tor - xoá vm v.v...  
Theo mình thì một khi đã có ý định ra vào các diễn đàn nghe ngóng tình hình thì tuyệt đối không dùng máy tính ở nhà, cơ quan, hay bạn bè, người thân để nghe ngóng. Ngoài ra thì máy ảo VMware cho phép restore lại trạng thái có thể tin tưởng được rất nhanh và tiện lợi, mình thấy cũng chẳng mất công mấy. Quan trọng là attacker cần mã hóa file ảnh của máy ảo để công tác forensics khi tịch thu máy tính của attacker nếu có không cho được kết quả nào, khi nào cần dùng thì giải mã ra dùng lại. Chú ý là sau khi dùng xong thì phải xóa (secure delete) luôn file ảnh đĩa mà máy ảo đang dùng hiện hành để không còn chứng cứ trong máy attacker nữa, dữ liệu nếu có được lưu lại cũng phải được mã hóa nốt (trong một ổ đĩa ảo chẳng hạn). Để thuận tiện hơn thì về sau (sau khi đã thâm nhập và thu thập dữ liệu thành công) và để tránh những nguy cơ mà mình không biết, cứ dùng một live cd chuyên dùng cho Penetration Testing (Pen-Test) như BackTrack, v.v. để duyệt web nghe ngóng diễn đàn, dữ liệu cần lưu thì cứ phải được mã hóa và lưu trong một ổ đĩa ảo. Ngoài ra attacker cần tránh truy cập website, diễn đàn + có hành động gì liên quan đến victim vào lúc đêm hôm khuya vắng ít người dùng máy tính truy cập mạng.]]> /hvaonline/posts/list/41207.html#256207 /hvaonline/posts/list/41207.html#256207 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

mrro wrote:
ảo tưởng về khả năng của công cụ là tiếc nuối lớn nhất của các cầu thủ Juventus ;-). -m  
Thật sự đọc bài này của anh em không thể nhịn được cười =)). Cứ thấy admin mrro ít nói chuyện trên hva thì tưởng anh cứng nhắc lắm. Ai dè các câu nói cũng rất thâm thuý và hài hước.]]> /hvaonline/posts/list/41207.html#256218 /hvaonline/posts/list/41207.html#256218 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. To Err Is Human - Con người khi hành động hầu như đều có mục đích nào đó, tội phạm cũng vậy, trong quá trình thực hiện hành vi phạm tội của mình... tội phạm sẽ để lại dấu vết đồng thời, cũng tìm cách xoá dấu vết. - Việc xoá dấu vết cũng đồng nghĩa với việc "để lại các dấu vết khác". Tất cả những tình huống, khả năng mà chúng ta đưa ra ở trên đều chỉ là giả định, mà điều tra (tiếp cận theo forensic) thì lại phải căn cứ vào "kết quả thực tế". Do đó, theo mình..... cứ giả định rồi theo cái giả định đó thì không bao giờ có hồi kết. Đối với 1 vụ việc hay một vụ án gì đi nữa, vấn đề khó nhất chỉ là: - Tầm quan trọng của vụ việc? - Số lượng người huy động để tham gia ? - Chi phí tổng thể là bao nhiêu? Đó là những lý do phải cân nhắc :) NÊN | KHÔNG Trở lại tình huống của BKAV chẳng hạn. - Đi theo hướng khai thác mối quan hệ giữa "Hec cơ" bị bắt với "hec cơ" hay "nhóm hec cơ" khác là một lợi thế? Cụ thể như sau: - Thông tin về hec cơ bị bắt + Số điện thoại liên lạc, tin nhắn + Thông tin về email/pass | Thông tin account trên các diễn đàn + Thông tin lưu ở máy tính (cái này thì 50/50) ===> Lọc ra các thông tin (1) - Tác động tâm lý (hỏi, ghi lời khai,....) + Thời gian, Mục đích, quá trình thực hiện hành vi? v.v + Xác định sự phù hợp giữa thông tin ở 1 và lời khai ===> Đưa ra các hướng để tác động tâm lý ]]> /hvaonline/posts/list/41207.html#256393 /hvaonline/posts/list/41207.html#256393 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập.

mrro wrote:
để triển khai được một hệ thống theo dõi như thế này cũng không quá khó. dẫu vậy ở nhiều quốc gia, theo dõi người dùng như thế là một hành động không được hoan nghênh và có khi là phạm luật. mình nghĩ đối với một công ty như BKIS thì họ hoàn toàn có thể triển khai một hệ thống như thế, nhưng mình không tin là họ đã, đang hoặc sẽ làm. đơn giản vì có những việc đơn giản hơn nhiều và có hiệu quả tức thì như kiện toàn hệ thống mà họ còn không làm, thì khó mà hình dung họ sẽ đầu tư cho những biện pháp có tính phòng xa như thế này.  
Cái này quả là vấn đề thú vị mà em đang nghĩ đến. Mấy cái Log cũng khá nguy hiểm đến nỗi công ty em chặn cả Google Analytics :">. Còn làm 1 cái tương tự thì ... Nhưng mà em nghĩ nếu như sử dụng các công cụ như ẩn danh của chrome, thì có vẻ cũng rất hay đấy. Tuy nhiên đến mức độ disable cả Script, flash, java và Cookies thì cũng dễ gây nghi ngờ.]]> /hvaonline/posts/list/41207.html#257125 /hvaonline/posts/list/41207.html#257125 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/list/41207.html#257127 /hvaonline/posts/list/41207.html#257127 GMT