<![CDATA[Latest posts for the topic "Case Study: xoá vết (cover tracks)"]]> /hvaonline/posts/list/51.html JForum - http://www.jforum.net Case Study: xoá vết (cover tracks) /hvaonline/posts/list/41207.html) có những ý kiến và thảo luận nghiêng hẳn sang hướng "xoá vết". Bởi vậy, tôi mở case study tiếp theo với chủ đề "xoá vết". Có lẽ định nghĩa "xoá vết" để làm gì không còn cần thiết nữa nhưng biên độ "xoá vết" cần được xác định cho rõ. Xoá vết bao gồm tất cả những hành động huỷ bỏ mọi dấu vết trên mỗi chặng xâm nhập. Bởi vậy, khi đưa ra thảo luận, bạn cần xác định cụ thể bạn đang nói về hành động huỷ bỏ dấu vết ở chặng nào, môi trường nào và hoàn cảnh nào. Bạn cũng cần phân tích và nêu ra lý do tại sao bạn cần làm như vậy. Mời bà con tham gia.]]> /hvaonline/posts/list/41388.html#256226 /hvaonline/posts/list/41388.html#256226 GMT Case Study: xoá vết (cover tracks) Vì các phương pháp "xoá vết" / "ẩn danh" còn tuỳ thuộc vào môi trường, hoàn cảnh và tâm lý con người nên em lấy 1 ví dụ giả định để thảo luận xung quanh trường hợp cụ thể này. Về phía client (quá trình chuẩn bị): Theo em thấy, trước khi muốn mình "ẩn danh" khi kết nối đến Internet thì phải biết và nắm rõ trước là server yêu cầu cái gì từ client và client sẽ cung cấp cái gì lên cho server. Từ đó ta mới có nền tảng để tự tìm cách bảo vệ và che dấu thông tin khi kết nối vào Internet. Ở phần này, ta cần phải có hiểu biết nhất định về các giao thức (protocols). Nắm được thông tin, cấu hình, cách sử dụng các dịch vụ ta sử dụng để kết nối Internet. => 1 khi mà nắm được những thứ đó, nó sẽ giúp bạn biết được những thông tin nào từ phía client sẽ được gửi cho server, lúc này ta có thể xem "những gì có thể fake" và "những gì không thể fake". * Vậy ở đây, ta có thể fake được những gì trong đống server yêu cầu client phải cung cấp ? - Đối với giao thức HTTP, ta có thể giả mạo User-Agent , thông tin về client như thời gian hệ thống, ... * Thế những thứ "không thể tự giả mạo" được như là IP Address thì sao ? - Đến lúc này, ý tưởng "nhồi" vào giữa client-server 1 proxy trung gian làm nhiệm vụ là người tiếp nhận các gói tin của client và chuyển tiếp đến server "với danh nghĩa là nó gửi đi" và server trả lời lại cho proxy rồi proxy lại làm công việc chuyển tiếp của nó ... => Tìm chọn và sử dụng những proxy nhiều người sử dụng nhưng cái quan trọng là hỗ trợ tối đa việc bảo mật thông tin cá nhân của người dùng. Vậy là ta đã kiểm soát và giả mạo được đống thông tin quan trọng. Nhưng không có gì đảm bảo được là ta vẫn an toàn, còn client-side-script (javascript, flash,...) nữa mà, và còn rất nhiều "bằng chứng" có thể buộc tội được ta nếu bị phát hiện ... => Vô hiệu hoá những plugins/add ons/ Functions hỗ trợ việc chạy client-side-script. Về phía server (quá trình xoá dấu vết sau khi khai thác): Ở chặng này, chúng ta cần phải thu thập đầy đủ thông tin về server (như là phiên bản hệ thống, thông tin và phiên bản các dịch vụ, cấu hình) => Từ những thông tin mà ta thu thập được, giúp ta tìm ra được nơi lưu trữ logs (syslogs,app logs, ...). Khi có được những thứ này, ta sẽ gặp 1 trong những tình huống sau: + Bạn có quyền hạn ghi/ xoá trên những file logs: Ta có thể fake, thay vào đó những thông báo/ cảnh báo giả để đánh lạc hướng điều tra hoặc ta cũng có thể "thanh toán" thẳng đám này ... diệt gọn và sạch ! + Bạn không có quyền hạn để tác động được đến những file logs + server cấu hình có giới hạn ... Chẳng lẽ bó tay sao ? ;) Tất nhiên là không rồi, hãy nhìn vào "cấu hình server", ta thấy cái gì ? ... "Giới hạn dung lương lưu trữ" ... Ở đây cũng lại phụ thuộc vào những yếu tố liên quan đến cấu hình quản lý logs của server, thời gian live và giới hạn dung lượng logs cho phép. Dựa vảo những "giới hạn" đó mà ta có thể tìm cách làm server "tự xử" - Chẳng hạn bạn cố tình flood 1 loạt những thứ khiến server phải cảnh báo -> Flood liên tục cho đến khi "chạm giới hạn" thì server sẽ tự xoá đống logs kia để lấy chỗ cho đống logs mới ... + Bạn không có quyền hạn để tác động được đến những file logs + server "không có giới hạn" . Nếu ở trường hợp này thì mệt rồi :( Thôi ta đành "lẩn trốn 1 thời gian" và áp dụng cách sau:
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 ...  
-> Ngồi hi vọng rằng : "Anh quản trị gì đó ơi, anh lười cho em được nhờ !" Bước cuối cùng trước khi out khỏi hệ thống, bạn đừng quên clear sạch đống "rác và cả chiến tích" của bạn tạo ra ;) Nhiều trường hợp các bạn bị truy ra là cũng vì 1 số thói quen của các bạn hay để lại ở cái đống này lắm :-" --------------------------------- Hì tiện đây mình có 1 "quiz question" này, các bạn thử nghĩ xem tại sao nhé ;)
Như mình từng đề cập đến, nhiều khi vì quá cẩn thận mà bạn vô tình để lộ sơ hở và chính sự cẩn thận của bạn lại hại bạn. Mình có ví dụ sau: Nhiều bạn nói rằng, máy sử dụng dịch vụ VPN và "để đề phòng + đánh lạc hướng", các bạn "cài thêm máy ảo" và thực hiện các hành động của mình trên máy ảo. Câu hỏi của mình là, tại sao ở trường hợp này nó lại "rất nguy hiểm" nếu như bạn "quên 1 thứ ..." ? Và cái thứ mà mình nhắc đến kia là công việc gì :D  
... :P ]]>
/hvaonline/posts/list/41388.html#256354 /hvaonline/posts/list/41388.html#256354 GMT
Case Study: xoá vết (cover tracks) /hvaonline/posts/list/41388.html#256411 /hvaonline/posts/list/41388.html#256411 GMT Case Study: xoá vết (cover tracks) Về phía server (quá trình xoá dấu vết sau khi khai thác): Ở chặng này, chúng ta cần phải thu thập đầy đủ thông tin về server (như là phiên bản hệ thống, thông tin và phiên bản các dịch vụ, cấu hình) => Từ những thông tin mà ta thu thập được, giúp ta tìm ra được nơi lưu trữ logs (syslogs,app logs, ...). Khi có được những thứ này, ta sẽ gặp 1 trong những tình huống sau: + Bạn có quyền hạn ghi/ xoá trên những file logs: Ta có thể fake, thay vào đó những thông báo/ cảnh báo giả để đánh lạc hướng điều tra hoặc ta cũng có thể "thanh toán" thẳng đám này ... diệt gọn và sạch ! + Bạn không có quyền hạn để tác động được đến những file logs + server cấu hình có giới hạn ... Chẳng lẽ bó tay sao ? smilie Tất nhiên là không rồi, hãy nhìn vào "cấu hình server", ta thấy cái gì ? ... "Giới hạn dung lương lưu trữ" ... Ở đây cũng lại phụ thuộc vào những yếu tố liên quan đến cấu hình quản lý logs của server, thời gian live và giới hạn dung lượng logs cho phép. Dựa vảo những "giới hạn" đó mà ta có thể tìm cách làm server "tự xử" - Chẳng hạn bạn cố tình flood 1 loạt những thứ khiến server phải cảnh báo -> Flood liên tục cho đến khi "chạm giới hạn" thì server sẽ tự xoá đống logs kia để lấy chỗ cho đống logs mới ... + Bạn không có quyền hạn để tác động được đến những file logs + server "không có giới hạn" . Nếu ở trường hợp này thì mệt rồi smilie Thôi ta đành "lẩn trốn 1 thời gian" và áp dụng cách sau:   --->cho mình hỏi tí, trường hợp log đã đổ về server log center thì sao hã bạn?]]> /hvaonline/posts/list/41388.html#256418 /hvaonline/posts/list/41388.html#256418 GMT Case Study: xoá vết (cover tracks)

vitcon01 wrote:
Về phía server (quá trình xoá dấu vết sau khi khai thác): Ở chặng này, chúng ta cần phải thu thập đầy đủ thông tin về server (như là phiên bản hệ thống, thông tin và phiên bản các dịch vụ, cấu hình) => Từ những thông tin mà ta thu thập được, giúp ta tìm ra được nơi lưu trữ logs (syslogs,app logs, ...). Khi có được những thứ này, ta sẽ gặp 1 trong những tình huống sau: + Bạn có quyền hạn ghi/ xoá trên những file logs: Ta có thể fake, thay vào đó những thông báo/ cảnh báo giả để đánh lạc hướng điều tra hoặc ta cũng có thể "thanh toán" thẳng đám này ... diệt gọn và sạch ! + Bạn không có quyền hạn để tác động được đến những file logs + server cấu hình có giới hạn ... Chẳng lẽ bó tay sao ? smilie Tất nhiên là không rồi, hãy nhìn vào "cấu hình server", ta thấy cái gì ? ... "Giới hạn dung lương lưu trữ" ... Ở đây cũng lại phụ thuộc vào những yếu tố liên quan đến cấu hình quản lý logs của server, thời gian live và giới hạn dung lượng logs cho phép. Dựa vảo những "giới hạn" đó mà ta có thể tìm cách làm server "tự xử" - Chẳng hạn bạn cố tình flood 1 loạt những thứ khiến server phải cảnh báo -> Flood liên tục cho đến khi "chạm giới hạn" thì server sẽ tự xoá đống logs kia để lấy chỗ cho đống logs mới ... + Bạn không có quyền hạn để tác động được đến những file logs + server "không có giới hạn" . Nếu ở trường hợp này thì mệt rồi smilie Thôi ta đành "lẩn trốn 1 thời gian" và áp dụng cách sau:  
--->;cho mình hỏi tí, trường hợp log đã đổ về server log center thì sao hã bạn? 
==> Khi log được đổ về server log center thì bạn không có quyền chỉnh sửa và đụng chạm. Điều bạn chỉ có thể làm là làm nhiễu log, đợi mớ log trên hết hạn và cầu nguyện cho Quản trị log server đó lười biếng. Bạn đọc kỹ lại bài viết của .lht. Các thảo luận của các bạn hình như đang lệch sang hướng "Làm sao để ẩn danh tối đa khi xâm nhập" Để "xóa dấu vết" một cách toàn diện thì bạn phải xác định:
  • Hành động của bạn có thể lưu dấu vết ở những chỗ nào? Tính chất của các dấu vết bạn để lại
Từ đó bạn mới lên được quy trình xóa dấu vết chi tiết Thường khi xâm nhập thì dấu vết của bạn thường lưu tại các điểm sau: - Client (Máy tính của bạn) - Modem và Gateway của ISP - Proxy hay các node mạng bạn đi qua () - Hệ thống mạng máy tính đích (Có thể là một server, hoặc có thêm IPS, Firewalđal, ... ) - Nơi bạn công bố thông tin (HVA, facebook, blog ... ) Ví dụ: nếu bạn là hacker tấn công Server BKAV thì bạn sẽ làm gì để ẩn danh và xóa dấu vết??? Mời mọi người tiếp tục thảo luận! - Ky0 -]]>
/hvaonline/posts/list/41388.html#256432 /hvaonline/posts/list/41388.html#256432 GMT
Case Study: xoá vết (cover tracks) - Tìm hiểu thông tin, xem xét đánh giá target - Khai thác, tấn công target - Công bố kết quả, nghe ngóng thông tin về cuộc tấn công. Trong các giai đoạn này, các thông tin của bạn sẽ hiện diện ở 4 điểm mấu chốt: - Điểm xuất phát: máy tính cá nhân, nơi truy cập,..: Các thông tin này bạn hoàn toàn chủ động trong việc cover. +Việc xóa vết trên máy tính của bạn có thể thực hiện bằng nhiều cách khác nhau như sử dụng proxy, virtual machine, VPN,.... +Nơi truy cập: bạn có thể kiếm cho bạn vài cái SIM 3G rác rẻ tiền rồi dùng một lần bỏ, hoặc bạn có thể ra 1 quán cafe internet xa lắc xa lơ mà bạn chẳng bao giờ mò chân tới. Còn nếu như bạn nào hôm trước vừa nói là có thể trace ra số điện thoại mà bạn vào quán cafe đó khi bạn thực hiện tấn công thì để yên tâm bạn nên để điện thoại ở nhà :/):) - Đường truyền trung gian (ISP, proxy,..): Tại điểm này thì bạn hoàn toàn bị động trong việc cover. Chính vì thế nên bạn phải giấu được thông tin trước khi các thông tin của bạn bước vào vị trí này và hoàn toàn phó thác may rủi cho những nhà quản lý vị trí này nếu bạn cover không kỹ. - Mục tiêu: Dù bạn có khả năng nâng quyền hạn của bạn trên mục tiêu thế nào đi nữa thì hoàn toàn bạn vẫn có thể không truy cập được vào toàn bộ log của mục tiêu (ví dụ như bạn không có quyền chỉnh sửa log hay vào log center,v.v..) thì về cơ bản thì theo mình là chỉ còn cách làm nhiễu loạn log, làm đầy log, hoặc sau 1 thời gian thì quay trở lại (cách này mình hay dùng vì khi nào cần lấy thông tin thì mới quay lại)... (như .lht. đã phân tích ở trên) Với cách làm như vậy thì quản trị mạng khi theo dõi sẽ vất vả hơn khi trace ra thời điểm bạn tấn công cũng như cách thức bạn tấn công như thế nào.. - Quan hệ xã hội: điểu yếu nhất trong hệ thống thông tin chính là con người. Mặc dù bạn là người tấn công nhưng cũng chính bạn với các mối quan hệ xã hội của bạn lại là nơi yếu nhất và dễ bị lộ nhất. + Bạn có thể gặp gỡ với bạn bè, chiến hữu của bạn trong một cuộc vui hoặc có chuyện buồn trong cuộc sống cần tâm sự với bạn bè nên cần có đôi ba chén để giải khuây chẳng hạn, có thể khi uống đến một mức nào đó thì những thông tin thầm kín về cuộc tấn công hoàn toàn có thể bị chính bạn đưa ra trước bàn nhậu. Một vài người trong cuộc nhậu đó nắm được thông tin và dù vô tình hay cố ý đưa lên mạng thì bạn chắc chắn sẽ bị sờ gáy. + Hay mức độ cẩn trọng sẽ giảm dần theo thời gian. Đến một lúc nào đó, bạn nghĩ là mọi chuyện đã qua và bạn có thể thoải mái yên tâm vi vu lướt đến nhưng nơi mà trước đó bạn đã cẩn trọng công bố thông tin thì cũng có thể lúc đó bạn bị tóm! + Họ sử dụng social enginering để xác định bạn là người ở đâu, thói quen là gì thông qua các cách sử dụng ngữ điệu, câu, chữ khi bạn nói về chiến công của bạn trên mạng (cái này mình tích lũy được khi theo dõi thông tin mọi người cho rằng anonymous vn sử dụng translator machine, hoặc cố tình viết theo ngữ điệu khác lạ) Như vậy, để cover một cách toàn diện thì việc đó sẽ được thực hiện trên cả 3 giai đoạn trên cũng như tối đa cover trên cả 4 điểm mấu chốt trong từng giai đoạn. 1. Giai đoạn tìm hiểu thông tin, xem xét đánh giá target: Có thể quản trị hệ thống mà bạn xâm nhập thành công về sau này sẽ review lại được giai đoạn thăm dò hệ thống của bạn và có thể sẽ tòi ra bạn trong số những khách viếng thăm hệ thống của họ. Bởi khi bạn thăm dò, ít nhiều trên công việc thăm dò của bạn sẽ để lại các vết khác lạ so với các truy cập thông thường. 2. Giai đoạn khai thác, tấn công target: Giai đoạn này thì hoàn toàn phải cover một cách cực kỳ thận trọng. Khi bắt đầu cuộc điều tra thì thông thường họ sẽ tập trung vào tìm hiểu bạn đã làm gì ở giai đoạn này nhất. Chính vì thế mà bất kỳ một sai sót để lộ thông tin ở giai đoạn này cũng sẽ giết chết bạn.Ví dụ như bạn để lại 1 cái backdoor chẳng hạn, họ có thể analyze con này và có thể tìm được một chút manh mối gì đó (đặc biệt nếu con backdoor này là do bạn tự compile nên sẽ có một số thông tin bạn không để ý bị ghi lại và con backdoor này). 3. Giai đoạn công bố kết quả, nghe ngóng thông tin về cuộc tấn công, quay lại hiện trường: Giai đoạn này nếu như không cover cẩn thận thì hoàn toàn nó sẽ làm cho mọi công sức của bạn từ trước đến giờ đổ ra biển lớn hết. Trong quá trình điều tra, thường thì họ sẽ tỏa đi khắp mọi nơi để nghe ngóng thông tin về bạn, bất kỳ một dữ kiện nhỏ nhất nào liên quan đền việc tấn công họ cũng sẽ vồ lấy và khai thác thông tin đó một cách triệt để, từ thông tin email, thông tin cá nhân liên quan, thông tin trên các diễn đàn, mạng xã hội khác và từ đó họ sẽ thực hiện sàng lọc đối tượng . Nếu bạn chủ quan, vội vàng tung ra ngay chiến lợi phẩm để khoe, để nâng danh mình lên hoặc để thách thức mà quên việc cover thì chính nó sẽ tố cáo thủ phạm là ai (điển hình mới nhất là vụ handheld.vn). Chính vì thế mà nếu bạn ở giai đoạn này thì chắc chắn phải rất cẩn thận hoặc bạn nên quên giai đoạn này đi, cứ để mọi người nói sao thì nói còn bạn không tham gia hay bình luận gì hết. Trong bài này mình không nói cụ thể về cách cover tracks thế nào mà chỉ phân tích về các tình huống có thể xảy ra trước, trong và sau quá trình xâm nhập. Do không có nhiều thời gian để viết nên có những chỗ viết hơi vắn tắt hoặc do kiến thức có hạn nên sẽ có vài điểm không hợp lý thì mọi người bỏ qua và cứ cho nhận xét thẳng thắn để mình khắc phục.]]> /hvaonline/posts/list/41388.html#256454 /hvaonline/posts/list/41388.html#256454 GMT Case Study: xoá vết (cover tracks) Code:
dd if=/dev/urandom of=partition_of_data
thế thì không thể Recovery được. Nếu để Trojan tỉnh dậy phá hoại sau vài tháng thì lúc này có thể server sẽ hết sạch log của toàn bộ cuộc tấn công để đưa Trojan lên trước đó. Nếu server save các bản backup thì cho nhớ cho Trojan xoá sạch toàn bộ các bản backup. - Tại "một miệng thì kín mà chín miệng thì hở": Có 1 ví dụ không thể nào hay hơn trong vụ: Đại học FPT: khi sinh viên gian lận và hack vào server trường -> /hvaonline/posts/list/41260.html Cụ thể ở đây cu cậu sửa bài tôi đã để lộ thông tin cho quá nhiều người nên tôi biết và điều tra theo. Nếu chỉ 1 mình cậu ta âm thầm làm việc và không ai biết thì chắc tôi vẫn đang cặm cụi ngồi học lại liên tục và dài dài và tự bảo sao mình học kiểu gì mà điểm luôn kém thế ;). Cách xoá vết tại chặng này thì chắc là không cần nói thì ai cũng biết. Ngoài ra còn 1 điểm đặc biệt cần chú ý: Cần xác định chắc chắn cẩn thận trước khi tấn công. Phải tin tưởng vào chính mình khi đã làm việc gì. Ví dụ: khi bạn tấn công vào 1 mạng hệ thống nào đó, mà bị triệu tập để gặp. Chắc chắn là sẽ không thể tìm được mình, đừng có nghe vài câu: "server hệ thống có lưu lại log của bạn, ..., bạn có thể nhận đi và tội sẽ rất nhẹ, sẽ được khoan hồng". Nếu bạn tin tưởng vào chính mình và phải chắc chắn rằng toàn bộ thông tin đã được xoá sạch thì hãy nhìn thẳng vào mặt người hỏi bạn câu đấy và nói: "KHÔNG!". Các cách xoá vết ở trên chỉ là để tham khảo, còn cách tốt nhất là đừng có làm ;) Đôi khi chỉ cần 1 sơ suất nhỏ mà lại được chuyển từ màu áo xanh tươi Chelsea sang Juventus thì đó thật là 1 điều tội tệ :-) ]]>
/hvaonline/posts/list/41388.html#256520 /hvaonline/posts/list/41388.html#256520 GMT
Case Study: xoá vết (cover tracks)

chube wrote:
Ok đón xe ôm về cà mau, chú nhớ mang cục 3G theo nha, mang nhiều sim rác vô nha, vào đó vừa tắm biển vừa hack nó mới đã !  
Một vài người cho rằng kiếm một quán net ở xa xa và ít đến để hack thì khó bị truy tìm hơn - Một người lạ đến quán net thì có bị để ý hay không? - Một người vào quán net tải một mớ thứ về và đôi lúc dùng dòng lệnh đen xì có bị mọi người để ý không? - Chưa kể một mớ trojan keylog có thể tồn tại trên các máy tính ở quán net nữa? An toàn trong trường hợp này là đến những quán net đông người và quản lý lười biếng. Ví dụ: mấy tiệm internet ở làng đại học Thủ Đức chẳng hạn :D Một vài người bảo dùng 3G và SIM rác thì không lo bị truy tìm.

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 
- USB 3G có số seri mã nhận dạng hay không? - Các thông số của USB 3G có được gửi đến trạm phát sóng hoặc nhà mạng không? - Mạng 3G làm thế nào để quản lý các thuê bao? (về mặt kỹ thuật, tránh xung đột với thuê bao khác ....) ... Để thực sự an toàn thì bạn chỉ sử dụng USB 3G một lần và hủy cùng với cái SIM rác sau khi xong việc :) Giải pháp tốt nhất thì dùng các mạng wifi miễn phí, cái này thì chạy vòng vòng thì cũng được vài cái rồi làm giống như phanledaivuong ;-) Nhưng để an toàn nhất thì chúng ta không nên làm việc xấu - Ky0 - ]]>
/hvaonline/posts/list/41388.html#256617 /hvaonline/posts/list/41388.html#256617 GMT
Case Study: xoá vết (cover tracks) /hvaonline/posts/list/41388.html#256635 /hvaonline/posts/list/41388.html#256635 GMT Case Study: xoá vết (cover tracks) nguồn (source) và điểm đích (destination). Nguồn ở đây là một public IP trực tiếp tương tác với đích: Nguồn ---> Đích. Trong đó, - Những gì đằng sau nguồn đều là tracks. - Những gì trước đích và chung quanh đích đều là tracks. Ví dụ, một perpetrator tấn công một máy chủ có IP là zz.zz.zz.zz và public IP của perpetrator là xx.xx.xx.xx. Nếu biểu thị ở một dạng "flow" đơn giản thì có thể là: máy con (1.1.1.1) --> jump server 1 (2.2.2.2) ---> jump server 2 (3.3.3.3) --> firewall bảo vệ đích (4.4.4.4) --> đích (5.5.5.5). Với biểu thị trên thì "nguồn" chính là 3.3.3.3 và "đích" chính là 5.5.5.5. Nếu packets đi từ 1.1.1.1 xuyên qua các jump servers (VPN, VPS, anonymous proxies....) trước khi trở thành 3.3.3.3 đối với đích 5.5.5.5 thì tất các những jump servers ấy đều thuộc về "tracks". Ở phía "đích", ngoài FW (4.4.4.4) còn có thể có những "stealth" IDS nằm ẩn và thu thập tất cả mọi thông tin đi từ "nguồn" 3.3.3.3 (bởi vì IDS không thể nào detect được những gì thuộc về 2.2.2.2 hoặc 1.1.1.1 hoặc nếu được thì chỉ là những thông tin mơ hồ vì hầu hết anonymous proxy đúng nghĩa sẽ xoá hết những thông tin nguyên thuỷ của client đứng sau nó). Ở phía đích, ngoài IDS còn có thể có kernel-based keylogger thu thập hết những "actions" xảy ra trên chính 5.5.5.5). Nói tóm lại, "xoá vết" bao gồm tất cả những gì đi từ điểm xuất phát (1.1.1.1) xuyên qua những chặng trung gian (n.n.n.n) đến điểm đích và những gì xung quanh điểm đích. Bởi vậy, ngoài việc xoá (hoặc ẩn) những thông tin trên những chặng trung gian còn phải tìm hiểu xem đích được cái gì bảo vệ và theo dõi.]]> /hvaonline/posts/list/41388.html#256880 /hvaonline/posts/list/41388.html#256880 GMT Case Study: xoá vết (cover tracks)

conmale wrote:
Bà con tham gia thảo luận xôm tụ lắm nhưng vẫn chưa có cái nhìn toàn diện nên khó khai triển cho rốt ráo. Tớ xin đưa ra vài điểm mấu chốt để dễ khai triển. Khi nói đến "tracks" (trong tinh thần cover-tracks), ta nói đến điểm nguồn (source) và điểm đích (destination). Nguồn ở đây là một public IP trực tiếp tương tác với đích: Nguồn ---> Đích. Trong đó, - Những gì đằng sau nguồn đều là tracks. - Những gì trước đích và chung quanh đích đều là tracks. Ví dụ, một perpetrator tấn công một máy chủ có IP là zz.zz.zz.zz và public IP của perpetrator là xx.xx.xx.xx. Nếu biểu thị ở một dạng "flow" đơn giản thì có thể là: máy con (1.1.1.1) --> jump server 1 (2.2.2.2) ---> jump server 2 (3.3.3.3) --> firewall bảo vệ đích (4.4.4.4) --> đích (5.5.5.5). Với biểu thị trên thì "nguồn" chính là 3.3.3.3 và "đích" chính là 5.5.5.5. Nếu packets đi từ 1.1.1.1 xuyên qua các jump servers (VPN, VPS, anonymous proxies....) trước khi trở thành 3.3.3.3 đối với đích 5.5.5.5 thì tất các những jump servers ấy đều thuộc về "tracks". Ở phía "đích", ngoài FW (4.4.4.4) còn có thể có những "stealth" IDS nằm ẩn và thu thập tất cả mọi thông tin đi từ "nguồn" 3.3.3.3 (bởi vì IDS không thể nào detect được những gì thuộc về 2.2.2.2 hoặc 1.1.1.1 hoặc nếu được thì chỉ là những thông tin mơ hồ vì hầu hết anonymous proxy đúng nghĩa sẽ xoá hết những thông tin nguyên thuỷ của client đứng sau nó). Ở phía đích, ngoài IDS còn có thể có kernel-based keylogger thu thập hết những "actions" xảy ra trên chính 5.5.5.5). Nói tóm lại, "xoá vết" bao gồm tất cả những gì đi từ điểm xuất phát (1.1.1.1) xuyên qua những chặng trung gian (n.n.n.n) đến điểm đích và những gì xung quanh điểm đích. Bởi vậy, ngoài việc xoá (hoặc ẩn) những thông tin trên những chặng trung gian còn phải tìm hiểu xem đích được cái gì bảo vệ và theo dõi. 
==> Đây cũng là vấn đề đau đầu khi forensic mà gặp tình trạng trên :P. Để đạt được những điều trên thì ta cần phải tiến hành thăm do chi tiết mục tiêu. Tuy nhiên quá trình thăm dò cũng có thể tạo ra các track khác. ta cũng cần phải cover được những cái track này. Đối với các hacker chuyên nghiệp thì họ thường lựa chọn thời điểm ra tay rất xa với thời điểm thăm dò (Điểm này cũng sẽ phát sinh nhiều vấn đề). Mời mọi người tiếp tục thảo luận chi tiết về từng chặng! -:|- ]]>
/hvaonline/posts/list/41388.html#256900 /hvaonline/posts/list/41388.html#256900 GMT
Case Study: xoá vết (cover tracks)

xBoyx wrote:
... 
Đây là case study chớ không phải là nơi hỏi các thắc mắc. Nên tham gia đóng góp vào case study. Nếu có thắc mắc thì mở một chủ đề mới ở box thích hợp để trao đổi riêng ra.]]>
/hvaonline/posts/list/41388.html#256925 /hvaonline/posts/list/41388.html#256925 GMT
Case Study: xoá vết (cover tracks)

conmale wrote:
Nói tóm lại, "xoá vết" bao gồm tất cả những gì đi từ điểm xuất phát (1.1.1.1) xuyên qua những chặng trung gian (n.n.n.n) đến điểm đích và những gì xung quanh điểm đích. Bởi vậy, ngoài việc xoá (hoặc ẩn) những thông tin trên những chặng trung gian còn phải tìm hiểu xem đích được cái gì bảo vệ và theo dõi. 
Case này của anh cũng rộng quá. Em thắy việc xoá vết chỉ chủ động được tại 1.1.1.1 -> 3.3.3.3, phần côn lại thì hên xui quá. Tuỳ vào mức độ được truy cập của người quản lý mà có cách riêng để xoá vết. Với 1 số web master thuê hosting để đặt website thì có thể 1 số cu cậu sau khi chèn shell lên còn khéo léo chạy thêm lệnh "touch" để chỉnh lại ngày giờ modify cho những quản lý nào mà kiểm tra hosting bằng time modify thì không phát hiện hosting mính dính "chấu". Còn đối với cách quản lý "thu thập hết những "actions" xảy ra trên chính 5.5.5.5" và mỗi ngày đọc log server 1 lần như anh conmale đang làm thì việc cover tracks chủ yếu là làm thế nào cho anh conmale không tìm được mình :D.]]>
/hvaonline/posts/list/41388.html#257020 /hvaonline/posts/list/41388.html#257020 GMT
Case Study: xoá vết (cover tracks) /hvaonline/posts/list/41388.html#257037 /hvaonline/posts/list/41388.html#257037 GMT Case Study: xoá vết (cover tracks)

phonglanbiec wrote:
... Tuy nhiên, sự thật là sự thật, nếu người khác có thời gian, chắc chắn họ sẽ tìm ra. Do vậy, ngoài việc có thể/không có thể can thiệp vào log của server. Ta còn phải tạo cho mình 1 vỏ bọc an toàn. Ví dụ như máy tính ta sau khi tấn công xong phải huỷ hết mọi thông tin: ví dụ như tấn công từ VMWare, sau khi tấn công xong thì lưu mọi thông tin đó lên Internet, huỷ ngay máy VMWare đó. Máy luôn sẵn sàng có 1 chương trình làm backdoor, 1 log ảo nhằm nếu bị phát hiện, thì ta vẫn có thể chứng minh mình là 1 nạn nhân trong 1 quá trình :)  
Mình thấy nếu mà dùng cách sử dụng backdoor, log ảo để chứng mình không ổn lắm :) nếu bạn làm vậy thì người ta cũng có thể chứng minh bạn đã làm vậy :P]]>
/hvaonline/posts/list/41388.html#257048 /hvaonline/posts/list/41388.html#257048 GMT
Case Study: xoá vết (cover tracks) máy con (1.1.1.1) --> jump server 1 (2.2.2.2) ---> jump server 2 (3.3.3.3) --> firewall bảo vệ đích (4.4.4.4) --> đích (5.5.5.5).   Cái sơ đồ này anh conmale đưa ra để mọi người phân biệt rõ từng chặng mà mình đi qua nó. Ở đây mỗi chặng nó ít nhiều đều lưu lại 1 số thông tin/ hành động của ta. Tuỳ trường hợp mà cái sơ đồ này sẽ thay đổi cho phù hợp với tình huống, trong nhiều trường hợp, jump server 1 ở đây sẽ là ISP (Internet service provider). Lúc này sẽ có 1 nhóm người khi truy cập vào Internet sẽ có chung 1 IP Address:
máy nhà (1.1.1.1 | IP mạng nội bộ của ISP) --> ISP (2.2.2.2 | IP access to internet) ---> jump server (3.3.3.3) --> firewall bảo vệ đích (4.4.4.4) --> đích (5.5.5.5).  
Chú ý điểm được nhấn mạnh:
- Những gì đằng sau nguồn đều là tracks. - Những gì trước đích và chung quanh đích đều là tracks.  
Vậy ở đây điểm được nhấn mạnh là
jump server (3.3.3.3) | firewall bảo vệ đích (4.4.4.4) | đích (5.5.5.5) 
Vì thế
từ điểm xuất phát (1.1.1.1) xuyên qua những chặng trung gian (n.n.n.n) 
Ta cần biết ở chặng trung gian cuối cùng,cái gì "đã" được "hide / protect" và những gì "giữ nguyên cho tới khi đến đích". Đến đây, có thể "thông tin" máy ta được che giấu (khi đi qua các proxies) nhưng "hành động" của chúng ta không thể nào che giấu được khi qua những chặng này. Vậy ta cần chú ý những gì ? - Những hành động của chúng ta và ảnh hưởng / tác động của nó đến hệ thống đích. - Thông tin về hệ thống đích (cấu hình, phiên bản, dịch vụ được sử dụng). Với những thông tin về hệ thống, từ đó sẽ giúp ta hình dung ra được toàn cảnh phía hệ thống đích: + Các dịch vụ đang sử dụng sẽ nói cho ta biết hệ thống đó đang sử dụng những IDS loại nào và nó detect / logs lại những gì. + Thông tin cấu hình sẽ giúp ta biết được "những giới hạn" của hệ thống đó. Từ đó , như bài trước mình đề cập đến 1 số tình huống sau:
+ Bạn có quyền hạn ghi/ xoá trên những file logs: Ta có thể fake, thay vào đó những thông báo/ cảnh báo giả để đánh lạc hướng điều tra hoặc ta cũng có thể "thanh toán" thẳng đám này ... diệt gọn và sạch ! + Bạn không có quyền hạn để tác động được đến những file logs và trong hoàn cảnh server cấu hình có giới hạn ... Ta hãy nhìn vào "cấu hình server", ta thấy cái gì ? ... "Giới hạn dung lương lưu trữ" ... Ở đây cũng lại phụ thuộc vào những yếu tố liên quan đến cấu hình quản lý logs của server, thời gian live và giới hạn dung lượng logs cho phép. Dựa vảo những "giới hạn" đó mà ta có thể tìm cách làm server "tự xử" - Chẳng hạn bạn cố tình flood 1 loạt những thứ khiến server phải cảnh báo -> Flood liên tục cho đến khi "chạm giới hạn" thì server sẽ tự xoá đống logs kia để lấy chỗ cho đống logs mới ... + Bạn không có quyền hạn để tác động được đến những file logs và trong hoàn cảnh server "không có giới hạn" . Nếu ở trường hợp này thì mệt rồi :( Thôi ta đành "lẩn trốn 1 thời gian" và áp dụng cách sau:
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 ... 
-> Ngồi hi vọng rằng : "Anh quản trị gì đó ơi, anh lười cho em được nhờ !"  
Ngoài ra, những hành động/ tác động của ta đến hệ thống cũng phải được chú ý. Những gì ta tạo ra cần phải được clear. Những "tàn tích" cần phải được xử lý cẩn thận (file được tạo/ chỉnh sửa khi nào, thời gian tạo/ chỉnh sửa) ...]]>
/hvaonline/posts/list/41388.html#257056 /hvaonline/posts/list/41388.html#257056 GMT
Case Study: xoá vết (cover tracks)

.lht. wrote:
Đến đây, có thể "thông tin" máy ta được che giấu (khi đi qua các proxies) nhưng "hành động" của chúng ta không thể nào che giấu được khi qua những chặng này.  
Như mình đã nói, thông tin ta connect đến các chặng này thì không thể che dấu được, mỗi bước đi của ta ít nhiều đều để lại dấu chân. Nhưng quan trọng ta chọn đi ở đâu, chẳng hạn như đi ra biển (các servers) thì dấu chân để lại nhiều; còn đi trên gạch (các PC đã bị ta hack) thì dấu chân của ta để lại ít hơn. Suy nghĩ của mình khi viết bài này: mình đặt mình là người điều tra, và người điều tra nghĩ gì, sau đó mình làm ngược lại với suy nghĩ đó :)]]>
/hvaonline/posts/list/41388.html#257138 /hvaonline/posts/list/41388.html#257138 GMT
Case Study: xoá vết (cover tracks)

phonglanbiec wrote:

.lht. wrote:
Đến đây, có thể "thông tin" máy ta được che giấu (khi đi qua các proxies) nhưng "hành động" của chúng ta không thể nào che giấu được khi qua những chặng này.  
Như mình đã nói, thông tin ta connect đến các chặng này thì không thể che dấu được, mỗi bước đi của ta ít nhiều đều để lại dấu chân. Nhưng quan trọng ta chọn đi ở đâu, chẳng hạn như đi ra biển (các servers) thì dấu chân để lại nhiều; còn đi trên gạch (các PC đã bị ta hack) thì dấu chân của ta để lại ít hơn. Suy nghĩ của mình khi viết bài này: mình đặt mình là người điều tra, và người điều tra nghĩ gì, sau đó mình làm ngược lại với suy nghĩ đó :) 
Cái gì cũng phải theo thực tế bạn à, chẳng lẽ lúc nào cũng có 1 cái "PC-hacked" cho ta nghịch ? Và còn chưa kể đến tốc độ kết nối khi thông qua các bước đó liệu bạn có đủ kiên nhẫn để ngồi hack khi mà tốc độ truy cập xuyên qua nhiều bước bị giảm dần ? :D Mà như trên mình có nói, "thông tin ta connect" hầu như khi đi qua các proxies trung gian đã được xoá và thay đổi chứ không phải "không thể che dấu được". Cái "không thể che dấu được" ở đây mình đề cập đến chính là "hành động". :) ]]>
/hvaonline/posts/list/41388.html#257142 /hvaonline/posts/list/41388.html#257142 GMT
Case Study: xoá vết (cover tracks)

Ky0 wrote:

chube wrote:
Ok đón xe ôm về cà mau, chú nhớ mang cục 3G theo nha, mang nhiều sim rác vô nha, vào đó vừa tắm biển vừa hack nó mới đã !  
Một vài người cho rằng kiếm một quán net ở xa xa và ít đến để hack thì khó bị truy tìm hơn - Một người lạ đến quán net thì có bị để ý hay không? - Một người vào quán net tải một mớ thứ về và đôi lúc dùng dòng lệnh đen xì có bị mọi người để ý không? - Chưa kể một mớ trojan keylog có thể tồn tại trên các máy tính ở quán net nữa? An toàn trong trường hợp này là đến những quán net đông người và quản lý lười biếng. Ví dụ: mấy tiệm internet ở làng đại học Thủ Đức chẳng hạn :D Một vài người bảo dùng 3G và SIM rác thì không lo bị truy tìm.

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 
- USB 3G có số seri mã nhận dạng hay không? - Các thông số của USB 3G có được gửi đến trạm phát sóng hoặc nhà mạng không? - Mạng 3G làm thế nào để quản lý các thuê bao? (về mặt kỹ thuật, tránh xung đột với thuê bao khác ....) ... Để thực sự an toàn thì bạn chỉ sử dụng USB 3G một lần và hủy cùng với cái SIM rác sau khi xong việc :) Giải pháp tốt nhất thì dùng các mạng wifi miễn phí, cái này thì chạy vòng vòng thì cũng được vài cái rồi làm giống như phanledaivuong ;-) Nhưng để an toàn nhất thì chúng ta không nên làm việc xấu - Ky0 -  
Ngoài ra còn cái MAC cũng khá quan trọng bạn nhỉ.]]>
/hvaonline/posts/list/41388.html#258449 /hvaonline/posts/list/41388.html#258449 GMT
Case Study: xoá vết (cover tracks)

Flicker675 wrote:

Ky0 wrote:

chube wrote:
Ok đón xe ôm về cà mau, chú nhớ mang cục 3G theo nha, mang nhiều sim rác vô nha, vào đó vừa tắm biển vừa hack nó mới đã !  
Một vài người cho rằng kiếm một quán net ở xa xa và ít đến để hack thì khó bị truy tìm hơn - Một người lạ đến quán net thì có bị để ý hay không? - Một người vào quán net tải một mớ thứ về và đôi lúc dùng dòng lệnh đen xì có bị mọi người để ý không? - Chưa kể một mớ trojan keylog có thể tồn tại trên các máy tính ở quán net nữa? An toàn trong trường hợp này là đến những quán net đông người và quản lý lười biếng. Ví dụ: mấy tiệm internet ở làng đại học Thủ Đức chẳng hạn :D Một vài người bảo dùng 3G và SIM rác thì không lo bị truy tìm.

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 
- USB 3G có số seri mã nhận dạng hay không? - Các thông số của USB 3G có được gửi đến trạm phát sóng hoặc nhà mạng không? - Mạng 3G làm thế nào để quản lý các thuê bao? (về mặt kỹ thuật, tránh xung đột với thuê bao khác ....) ... Để thực sự an toàn thì bạn chỉ sử dụng USB 3G một lần và hủy cùng với cái SIM rác sau khi xong việc :) Giải pháp tốt nhất thì dùng các mạng wifi miễn phí, cái này thì chạy vòng vòng thì cũng được vài cái rồi làm giống như phanledaivuong ;-) Nhưng để an toàn nhất thì chúng ta không nên làm việc xấu - Ky0 -  
Ngoài ra còn cái MAC cũng khá quan trọng bạn nhỉ. 
Cái MAC gì? Sao không nói rõ hơn?]]>
/hvaonline/posts/list/41388.html#258451 /hvaonline/posts/list/41388.html#258451 GMT
Case Study: xoá vết (cover tracks)

Flicker675 wrote:

Ky0 wrote:

chube wrote:
Ok đón xe ôm về cà mau, chú nhớ mang cục 3G theo nha, mang nhiều sim rác vô nha, vào đó vừa tắm biển vừa hack nó mới đã !  
Một vài người cho rằng kiếm một quán net ở xa xa và ít đến để hack thì khó bị truy tìm hơn - Một người lạ đến quán net thì có bị để ý hay không? - Một người vào quán net tải một mớ thứ về và đôi lúc dùng dòng lệnh đen xì có bị mọi người để ý không? - Chưa kể một mớ trojan keylog có thể tồn tại trên các máy tính ở quán net nữa? An toàn trong trường hợp này là đến những quán net đông người và quản lý lười biếng. Ví dụ: mấy tiệm internet ở làng đại học Thủ Đức chẳng hạn :D Một vài người bảo dùng 3G và SIM rác thì không lo bị truy tìm.

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 
- USB 3G có số seri mã nhận dạng hay không? - Các thông số của USB 3G có được gửi đến trạm phát sóng hoặc nhà mạng không? - Mạng 3G làm thế nào để quản lý các thuê bao? (về mặt kỹ thuật, tránh xung đột với thuê bao khác ....) ... Để thực sự an toàn thì bạn chỉ sử dụng USB 3G một lần và hủy cùng với cái SIM rác sau khi xong việc :) Giải pháp tốt nhất thì dùng các mạng wifi miễn phí, cái này thì chạy vòng vòng thì cũng được vài cái rồi làm giống như phanledaivuong ;-) Nhưng để an toàn nhất thì chúng ta không nên làm việc xấu - Ky0 -  
Ngoài ra còn cái MAC cũng khá quan trọng bạn nhỉ. 
Trong kết nối TCP/IP thì MAC là địa chỉ vật lí của từng máy và có giá trị sử dụng ở tầng host-to-network (data link). Xin nói thêm về MAC 1 chút là mỗi máy (chính xác hơn là thiết bị kết nối) sẽ có một địa chỉ dưới dạng: zz:zz:zz:yy:yy:yy trong đó zz:zz:zz là được đăng kí bởi nhà sản xuất thiết bị kết nối. Muốn biết được cái MAC của máy đối tượng thì ít ra mình chí ít phải vào được modem wifi mà đối tượng đang kết nối. Để chắc ăn hơn thì mượn máy đối tượng vào cmd và gỏ ipconfig. (chi tiết này không chính xác) Khi xác định được MAC rồi thì mình sẽ kết luận được máy đối tượng dùng thiết bị kết nối của hãng nào sản xuất O-) Xin bổ xung 1 chi tiết nữa là MAC bạn có thể chỉnh bằng tay tuỳ thích. Nên dù có nắm dãy số này bạn cũng chẳng biết được gì Tóm lại, không ăn nhập gì với chủ đề này cả. đã sửa lại sao khi làm theo lời của maithangbs]]>
/hvaonline/posts/list/41388.html#258651 /hvaonline/posts/list/41388.html#258651 GMT
Case Study: xoá vết (cover tracks) /hvaonline/posts/list/41388.html#258656 /hvaonline/posts/list/41388.html#258656 GMT Case Study: xoá vết (cover tracks) nếu 2 máy không nằm cùng trong 1 mạng nội bộ (LAN). Mình thấy đã có người giải thích như sau, bạn thử đọc nhé :D
Actually, the MAC-address stored in the packet is changed on every hop of a packet's journey. MAC is shorthand for Media Access Control, with media refering to the local communication media. While source and destination IP-Addresses remain the same throughout the journey (and are used for long-distance routing decisions), the source and destination MAC-Addresses just indicate the next hop. Because of this, the MAC-Address stored in packets received by your server should be the MAC address of your point of presence-router, or of the equipment of your provider. You might want to have a look at the OSI Layer model and encapsulation.  
]]>
/hvaonline/posts/list/41388.html#258701 /hvaonline/posts/list/41388.html#258701 GMT
Case Study: xoá vết (cover tracks) /hvaonline/posts/list/41388.html#258703 /hvaonline/posts/list/41388.html#258703 GMT Case Study: xoá vết (cover tracks) 3.3.3.3) --> firewall bảo vệ đích (4.4.4.4) --> đích (5.5.5.5). Đây là dạng tấn công từ kẻ ở bên ngoài. Vậy, dạng tấn công từ kẻ ở bên trong thì sao? Có rất nhiều người nghĩ rằng tin tặc thường tấn công từ bên ngoài vào nhưng thực tế khảo sát và thống kê thì cho thấy, hơn 80% những dạng tấn công nguy hiểm và chết người đi từ chính bên trong (nội bộ mục tiêu). Hãy xét dạng "track" sau: máy con (5.5.5.6) --> tunnel out 1 (2.2.2.2) ---> jump server 2 (3.3.3.3) --> firewall bảo vệ đích (4.4.4.4) --> đích (5.5.5.5). Ở đây, máy con 5.5.5.6 thuộc network với hệ thống đích 5.5.5.5 nhưng máy con không tấn công trực tiếp vì nó sẽ để quá nhiều dấu tích. Bởi vậy, máy con sẽ tạo tunnel ra 2.2.2.2 rồi từ 2.2.2.2 nó nhảy sang 3.3.3.3 để từ đó, nó mới tấn công vào 5.5.5.5. Ở góc độ xoá vết, firewall bảo vệ network 5.5.5.0 cùng lắm chỉ có thể thấy 5.5.5.6 tạo một connection đến IP 2.2.2.2 nào đó và dấu vết mất hút ngay điểm đó. Vậy, điểm yếu và điểm mạnh của dạng tấn công và cover track ở trên nằm chỗ nào? PS: tất nhiên, đây chỉ là một dạng đơn giản hoá vì thực tế có vô vàn các biến hoá.]]> /hvaonline/posts/list/41388.html#258953 /hvaonline/posts/list/41388.html#258953 GMT Case Study: xoá vết (cover tracks) Ở đây, máy con 5.5.5.6 thuộc network với hệ thống đích 5.5.5.5 nhưng máy con không tấn công trực tiếp vì nó sẽ để quá nhiều dấu tích. Bởi vậy, máy con sẽ tạo tunnel ra 2.2.2.2 rồi từ 2.2.2.2 nó nhảy sang 3.3.3.3 để từ đó, nó mới tấn công vào 5.5.5.5. Ở góc độ xoá vết, firewall bảo vệ network 5.5.5.0 cùng lắm chỉ có thể thấy 5.5.5.6 tạo một connection đến IP 2.2.2.2 nào đó và dấu vết mất hút ngay điểm đó. Vậy, điểm yếu và điểm mạnh của dạng tấn công và cover track ở trên nằm chỗ nào?   Ở khu vực firewall kiểm tra luồng traffic vào ra, firewall nhận thấy luồng traffic từ 5.5.5.6 đi ra và luồng nào đó từ 2.2.2.2 đi vào có sự tương quang rõ rệt. Tuy người quan sát không nhận biết tại sao có 1 nhóm đi ra từ 5.5.5.6 đi ra rồi không có traffic trả về tương ứng cho dịch vụ. Nhưng người quan sát lại thấy 1 luồng đi vào từ 2.2.2.2 có cùng vùng dịch vụ(port chẳng hạn) và trường sequence chẳng hạn... khá là lạ. Từ đó mới thấy nghi ngờ. Chuyện này phải ngồi nhìn thời gian dài mới thấy ra được, và có chủ ý quan sát.]]> /hvaonline/posts/list/41388.html#258984 /hvaonline/posts/list/41388.html#258984 GMT Case Study: xoá vết (cover tracks) /hvaonline/posts/list/41388.html#258988 /hvaonline/posts/list/41388.html#258988 GMT Case Study: xoá vết (cover tracks)

.lht. wrote:
Ở dạng tấn công [từ bên trong] này, điểm yếu/mạnh dễ nhận thấy nhất là: Yếu: - Các hệ thống theo dõi sẽ dễ dàng thu thập được thông tin và hành động. Trong đó "hành động" dễ bị nhận diện và phát hiện nhất. Mạnh: - Ta dễ dàng nắm được cấu hình của hệ thống mạng đó để lên kế hoạch cover track.  
Giả sử ai đó tạo 1 cái tunnel xuyên qua payload của HTTP đến cổng 443 của một hostname nào đó rất thông thường (my.chungkhoan.vn) chẳng hạn rồi cứ để đỏ cả ngày, không làm gì hết hoặc thỉnh thoảng để cho làm ra vẻ thông thưởng, chạy một cái script để nó gởi nhận vài trăm gói tin. Sau một ngày hay vài ngày, người đó mới bắt đầu SSH ra đến my.chungkhoan.vn xuyên qua HTTP tunnel rồi từ đó mới nhảy sang một VPN hoặc một (hoặc nhiều) anymous proxy để thực hiện việc quay ngược vào đích (5.5.5.5) thì sao? Nên nhớ, traffic đi xuyên qua từ máy con (5.5.5.6) --> tunnel out 1 (2.2.2.2) cực kỳ nhỏ nếu chỉ dùng command line bình thường. Trong khi tin tặc âm thầm làm chuyện này, công ty ấy có hàng ngàn đến hàng triệu packets ra vào thì lấy cái gì phân biệt được đặt tính của traffic đi từ máy con (5.5.5.6) --> tunnel out 1 (2.2.2.2)? Sở dĩ em thấy rõ trong trường hợp này bởi vì đã có cái sườn sẵn. Trong tình huống bình thường của một ngày sinh hoạt bình thường, traffic đi từ máy con (5.5.5.6) --> tunnel out 1 (2.2.2.2 cho my.chungkhoan.vn) ở cổng 443 là traffic cực kỳ bình thường.]]>
/hvaonline/posts/list/41388.html#258993 /hvaonline/posts/list/41388.html#258993 GMT
Case Study: xoá vết (cover tracks) tối thiểu hoá lượng dấu vết có thể để lại trong quá trình tấn công. (Xét theo góc độ cover track anh cũng đã đề cập ở trên, firewall chỉ có thể thấy được lượng traffic đi từ máy con đến (2.2.2.2) và sau đó mất hút. Rõ ràng rất khó để có được chút manh mối.) + Khi máy con trong kịch bản anh đề ra sử dụng nhiều bước trung gian thì điểm mạnh kế tiếp hẳn nhiên là tăng độ anonymously,, vì bắt đầu từ giai đoạn tạo ssh trong tunnel http thì mọi thứ đã được mã hoá - dĩ nhiên là attacker có thể áp dụng khoá riêng cho việc kết nối 2 bên bao gồm máy con (5.5.5.6) và (2.2.2.2) để tăng độ an toàn thông qua việc xác thực - cho đến giai đoạn jump sang 1 server anonymous thì khi tấn công đích (5.5.5.5), mọi dấu vết thu lại (nếu có) đều gây bất lợi cho việc điều tra (Xét theo góc độ cover track thì attacker cũng có thể áp dụng những kịch bản nhằm đánh lạc hướng sự điều tra , 1 ví dụ anh conmale đã nêu rõ bên trên.) - Xét về điểm yếu có thể có trong cách tấn công trên thì với ý kiến cá nhân ( có thể còn thiếu sót ) em xin nêu ra 1 vài điểm như sau : - Do hành động này là gián tiếp cho nên phải thông qua nhiều giai đoạn - nên nhớ rằng kịch bản đưa ra đã được đơn giản hoá do thực tế còn muôn vàn cách biến hoá khác nhau - cho nên điểm yếu đầu tiên đó là ta đã tăng sự phân tán trong việc xoá vết bởi vì sao ? Chỉ cần 1 động tác thừa hoặc 1 chi tiết bỏ sót thì mọi khả năng bị trace lại đều khả hữu. Vì vậy ở mỗi giai đoạn attacker cần có 1 kế hoạch cụ thể để dựa vào đó mà thực hiện việc cover tracks 1 cách hiệu quả. - ( Đây là điểm em chưa đủ kinh nghiệm để có thể khẳng định! ) Do máy con được nêu ra ở đây (5.5.5.6) thuộc cùng mạng của máy đích (5.5.5.5) cho nên khi attacker thực hiện tấn công sẽ phải thực hiện ngay trên máy tại công ty, việc này có thể dẫn đến 1 vài điểm yếu khác , ta giả tỉ rằng máy con này của công ty bị giới hạn quyền hạn nên khi máy đích bị tấn công, nếu họ triển khai theo hướng điều tra nội bộ, ắt hẳn phải điều tra máy trong cùng mạng, vì vậy nhiều rủi ro tại công đoạn này cũng có thể xảy ra.]]> /hvaonline/posts/list/41388.html#259045 /hvaonline/posts/list/41388.html#259045 GMT Case Study: xoá vết (cover tracks) máy con (1.1.1.1) --> jump server 1 (2.2.2.2) ---> jump server 2 (3.3.3.3) --> firewall bảo vệ đích (4.4.4.4) --> đích (5.5.5.5).   Giải pháp: Dùng một Linux Live CD như BackTrack với option "BackTrack Forensics - No Drive or Swap Mount" để đảm bảo không lưu lại vết/chứng cứ các hoạt động của bạn vào ổ cứng của máy con.
Ưu điểm: BackTrack Live CD sẽ sử dụng bộ nhớ RAM để lưu tất cả các file mà BackTrack dùng, khi tắt nguồn và khởi động lại máy, thông tin trên RAM của lần làm việc trước sẽ không còn để forensics cũng như không có dữ liệu hay chứng cứ nào được lưu vào ổ cứng của máy con. Giải pháp này tránh được các nhược điểm nếu bạn sử dụng hệ điều hành Windows, các vết các hoạt động của bạn có thể được lưu lại ở nhiều nơi trên ổ cứng mà bạn khó lòng kiểm soát hết được, ví dụ như các file thumbs.db, pagefile.sys,..., các vùng ổ cứng được format. Nếu cần lưu lại dữ liệu thì có thể dùng TrueCrypt để lưu dữ liệu trong một TrueCrypt Hidden Volume là 1 encrypted file container nằm trong một TrueCrypt Volume khác trên một ổ USB flash riêng, cả hai TrueCrypt Volume này đều được bảo vệ với những bộ password và keyfile khác nhau, password có độ dài ít nhất 20 ký tự để chống dạng tấn công brute force. Cần đảm bảo là TrueCrypt Hidden Volume đươc dùng để lưu dữ liệu ở trên chỉ được mở trong môi trường mà bạn đảm bảo là sạch hoàn toàn, không có trojan (như khi dùng BackTrack Linux Live CD chẳng hạn), nếu không mọi thứ có thể bị đổ vỡ.]]>
/hvaonline/posts/list/41388.html#259290 /hvaonline/posts/list/41388.html#259290 GMT
Case Study: xoá vết (cover tracks)

bolzano_1989 wrote:
Giải pháp này tránh được các nhược điểm nếu bạn sử dụng hệ điều hành Windows, các vết các hoạt động của bạn có thể được lưu lại ở nhiều nơi trên ổ cứng mà bạn khó lòng kiểm soát hết được, ví dụ như các file thumbs.db, pagefile.sys,..., các vùng ổ cứng được format.  
Nếu lỡ để bị lưu trên ổ cứng thì đọc thêm ở đây để học cách xoá. Code:
/hvaonline/posts/list/35052.html#215288
]]>
/hvaonline/posts/list/41388.html#259459 /hvaonline/posts/list/41388.html#259459 GMT
Case Study: xoá vết (cover tracks) Yahoo Facebook Email Web etc...   - Người dùng cao cấp (superuser) sẽ sữ dụng các ứng dụng không phổ biến, có những hoạt động không phổ biến đối với nhóm người dùng kia.
nmap tracert whois nslookup brute froce tools etc...  
ISP sẽ xây dựng một ứng dụng lọc các gói tin đi qua network interface của họ và xây dựng một database cho từng đối tượng superuser có trong mạng của họ, khoanh vùng các superuser và xem xét hoạt động của superuser, cũng như thói quen. Ngoài ra các ISP thực hiện MAN IN THE MIDDLE ATTACK đối với các đối tượng khả nghi. Thông qua những hoạt động sau có thể giúp cho ISP nắm được hành động của supperuser: - DNS Query: DNS Query sử dụng UDP, không encrypt dữ liệu gửi đi. Động thái này của ISP sẽ giúp ISP tìm hiểu thói quen của superuser. Chẳng hạn normal user rất ít khi vào HVA, hoặc các trang thông tin bảo mật khác, nhưng nhóm superuser lại quan tâm tới các thông tin ở đây hơn. - Footprinting: Các hoạt động như nmap, nslookup...để lại những dấu vết đặc thù. Chẳng hạn khi chúng ta dùng nmap xảy ra quá trình rất đặc thù là các gói SYN được tạo ra rất nhiều và gửi tới target nhưng không bao giờ trả lời các gói SYN/ACK bằng một gói ACK cả. - Sử dụng ToR: sử dụng tor mặc dù an toàn thậm chí DNS Query cũng được mã hóa (em đã xác nhận bằng việc thử nghiệm truy vấn các trang HTTPS và bắt phân tích bằng WireShark), nhưng khi bạn sử dụng ToR quá nhiều sẽ tạo nên nhiều nghi vấn mơ hồ. Và họ có thể tiến hành phân tích các IP bạn kết nối thông qua SSL xem liệu nó có domain không, các cổng bạn kể nối tới có phải cổng mà normal user hay dùng không. (tất nhiên là một nút trong mạng ToR nơi cung cấp dịch vụ cho bạn không thể dặt port của nó là 21/25/80/88 rồi, các port mặc định này không rãnh, và bạn cũng không có quyền chọn lựa nút nào trong mạng ToR bạn sẽ đi qua). Như anh conmale phân tích việc kết nối vào mạng ToR gồm 2 quá trình là kết nối với mạng ToR nhận thông tin định tuyến sau đó tiến hành gửi dữ liệu vào mạng ToR thông qua các nút trung gian. Có lẽ ở bước đầu tiên bạn đã bị phân loại và đưa vào sổ theo dỏi. - Ngoài ra chỉ cần can thiệp vào transport layer cũng có thể phân loại người dùng rồi. Phương pháp xóa vết em đưa ra: - Thay đổi thông tin: Đổi username và MAC address tương ứng cho 1 user khác của ISP. Tất nhiên cũng cần sẳn sàng để đổi ngược lại khi "có biến". (Việc này muốn làm cần phải tìm được 1 router cùng ver với mình, sau đó phải build lại frimware cho nó, cái này có SDK từng thằng). - Sử dụng /etc/hosts giảm bớt các DSN query. - Định nghĩa một phương thức bảo mật khác hoặc dùng một phương thức thường được sử dụng nhất để truy vấn và gửi dữ liệu ra bên ngoài HTTP/HTTPS/ICMP....(data field của ICMP có thể là nơi tốt đễ chứa dữ liệu đã encrypt chỉ một chút sáng tạo nhỏ sẽ giúp bạn có một proxy khá lí thú). Đến đây em thấy ý kiến của anh conmale thực sự hay:

conmale wrote:
Giả sử ai đó tạo 1 cái tunnel xuyên qua payload của HTTP đến cổng 443 của một hostname nào đó rất thông thường (my.chungkhoan.vn) chẳng hạn rồi cứ để đỏ cả ngày, không làm gì hết hoặc thỉnh thoảng để cho làm ra vẻ thông thưởng, chạy một cái script để nó gởi nhận vài trăm gói tin. Sau một ngày hay vài ngày, người đó mới bắt đầu SSH ra đến my.chungkhoan.vn xuyên qua HTTP tunnel rồi từ đó mới nhảy sang một VPN hoặc một (hoặc nhiều) anymous proxy để thực hiện việc quay ngược vào đích (5.5.5.5) thì sao?  
Ý kiến này gợi mở nhiều điều và đảm bảo gây khó khăn đủ cho ISP cũng nãn đôi phần. P/s: em xin lỗi hôm bửa hỏi không đúng chổ.]]>
/hvaonline/posts/list/41388.html#260134 /hvaonline/posts/list/41388.html#260134 GMT
Case Study: xoá vết (cover tracks)

chiro8x wrote:
Thực lòng em không cảm thấy tin tưởng vào các ISP của Việt Nam lắm, chúng ta sử dụng internet thông qua các thiết bị mạng và các thiết bị này được phân phối thông qua các ISP. ISP sẽ biết đích xác là ai dùng thiết bị gì, tại địa điểm nào, username đăng nhập vào hệ thống là gì.  
Đề nghị bạn nói rõ những nhận định mình trích ở trên, sử dụng căn cứ kỹ thuật, không nhận định cảm tính. ]]>
/hvaonline/posts/list/41388.html#261898 /hvaonline/posts/list/41388.html#261898 GMT
Case Study: xoá vết (cover tracks)

hoahongtuoi wrote:

chiro8x wrote:
Thực lòng em không cảm thấy tin tưởng vào các ISP của Việt Nam lắm, chúng ta sử dụng internet thông qua các thiết bị mạng và các thiết bị này được phân phối thông qua các ISP. ISP sẽ biết đích xác là ai dùng thiết bị gì, tại địa điểm nào, username đăng nhập vào hệ thống là gì.  
Đề nghị bạn nói rõ những nhận định mình trích ở trên, sử dụng căn cứ kỹ thuật, không nhận định cảm tính.  
Làm thế nào nhà mạng thống kê được lưu lượng sử dụng internet (dù là cáp đồng, cáp quang hay usb 3G) để cuối tháng in hóa đơn tính tiền cho bạn? Bạn tự tìm hiểu, đó cũng sẽ là lời giải thích cho đề nghị của bạn.]]>
/hvaonline/posts/list/41388.html#261899 /hvaonline/posts/list/41388.html#261899 GMT
Case Study: xoá vết (cover tracks)

miyumi2 wrote:

hoahongtuoi wrote:

chiro8x wrote:
Thực lòng em không cảm thấy tin tưởng vào các ISP của Việt Nam lắm, chúng ta sử dụng internet thông qua các thiết bị mạng và các thiết bị này được phân phối thông qua các ISP. ISP sẽ biết đích xác là ai dùng thiết bị gì, tại địa điểm nào, username đăng nhập vào hệ thống là gì.  
Đề nghị bạn nói rõ những nhận định mình trích ở trên, sử dụng căn cứ kỹ thuật, không nhận định cảm tính.  
Làm thế nào nhà mạng thống kê được lưu lượng sử dụng internet (dù là cáp đồng, cáp quang hay usb 3G) để cuối tháng in hóa đơn tính tiền cho bạn? Bạn tự tìm hiểu, đó cũng sẽ là lời giải thích cho đề nghị của bạn. 
Chẳng có ISP nào mà không log những thông tin đó lại. Nên nếu chỉ nói ISP VN thì hơi tội cho họ quá!]]>
/hvaonline/posts/list/41388.html#262144 /hvaonline/posts/list/41388.html#262144 GMT
Case Study: xoá vết (cover tracks) /hvaonline/posts/list/41388.html#265401 /hvaonline/posts/list/41388.html#265401 GMT Case Study: xoá vết (cover tracks) /hvaonline/posts/list/41388.html#265427 /hvaonline/posts/list/41388.html#265427 GMT Case Study: xoá vết (cover tracks) /hvaonline/posts/list/41388.html#268115 /hvaonline/posts/list/41388.html#268115 GMT Case Study: xoá vết (cover tracks) /hvaonline/posts/list/41388.html#275316 /hvaonline/posts/list/41388.html#275316 GMT Case Study: xoá vết (cover tracks)

cuongps wrote:
.Máy luôn sẵn sàng có 1 chương trình làm backdoor, 1 log ảo nhằm nếu bị phát hiện, thì ta vẫn có thể chứng minh mình là 1 nạn nhân trong 1 quá trình. => Cao thủ. 
Nên đưa ra các dẫn chứng và phân tích cụ thể cho ý kiến của mình! Case Studies không phải là nơi "chém gió" như các mục khác. Trân trọng! - Ky0 - ]]>
/hvaonline/posts/list/41388.html#275368 /hvaonline/posts/list/41388.html#275368 GMT