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

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Case Studies

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

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

Phó Hồng Tuyết
Member

Joined: 20/04/2007 20:02:10
Messages: 275
Location: Nơi Sâu Thẳm Tâm Hồn
Offline

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.

"Một người thành công không có ý nghĩ đổ thừa thất bại do ...."

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

Ky0
Moderator

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

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 smilie

.
Đ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 smilie

- Ky0 -

UITNetwork.com
Let's Connect

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

conmale
Administrator

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

He he, chiều nay trong lúc họp, ngồi trace thử cái t0r client / server thì thấy rằng có hai phân đoạn rạch ròi:

1. handshaking giữa t0r client và t0r relay server(s).

2. traffic từ trình duyệt đi xuyên qua t0r tunnel (đã được thiết lập ở trên).

tcpdump và gdb xuyên qua quá trình "Hello" giữa t0r client và t0r relay server(s) và quá trình push giữa hai đầu cho thấy trước khi mỗi payload được gởi đi, một record rỗng được chèn vô. Đây chính là tính năng của openSSL từ phiên bản 0.9.6d trở đi. Bởi vậy, BEAST không thể nào exploit được. Đây là biểu hiện y hệt như TLS 1.1 mà t0r clients và t0r servers sử dụng. Sở dĩ nó không bị "broken" bởi vì các t0r clients và t0r servers handshake trực tiếp không qua trình duyệt nào hết (không bị tình trạng broken negotiation như đã và đang xảy ra giữa trình duyệt thông thương và các web sites thông thường). Cả t0r clients và t0r relay servers đều đồng ý với dạng TLS rỗng được chèn cho nên chúng vẫn hoạt động bình thường. Chính vì vậy, việc "tóm" được một mảnh user secret (cookie chẳng hạn) từ một vị trí có thể đoán được như trong BEAST case là không thể xảy ra giữa t0r clients và t0r relay servers.

Sau khi tunnel (giữa t0r clients và t0r relay servers) được hình thành, trọn bộ thông tin đi từ trình duyệt (hoặc chat cient hoặc bất cứ cái gì có thể đi xuyên qua) hoàn toàn nằm ở dạng encrypted payload. Trình duyệt gởi và nhận thông tin với end-points (web site đích) không hề bị lộ ra ngoài để có thể thi triển BEAST.

Tóm lại, trình duyệt đi xuyên qua t0r tunnels là safe. Cùng lắm ISP chỉ có thể capture một IP của ADSL hoặc cable hoặc cái gì đó connect đến một t0r relay server (trong hàng ngàn cái) nhưng không thể capture được cái gì trong payload hết.

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

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

LeVuHoang
HVA Friend

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

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.

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

conmale
Administrator

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

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.

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

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

mrro
Administrator

Joined: 27/12/2001 05:07:00
Messages: 745
Offline

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.

để 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/

http://tinsang.net

TetCon 2013 http://tetcon.org

Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html

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

conmale
Administrator

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

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 smilie

. 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 đó smilie

. 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.

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

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	28/02/2012 09:00:13 (+0700) \| #68 \| 255959

.lht.
Member

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

Cảm ơn anh mrro,
Thật sự với điều kiện chưa cho phép và trình độ có hạn nên em chỉ dám xin anh đống tài liệu để tham khảo và tham gia tích cực các hoạt động dạng như case study này để nâng cao kiến thức thôi smilie

Về cái hội thảo TetCon thật sự em cũng rất thích được "hóng" nhưng vì em ở nước ngoài nên không đi "hóng" được smilie

Mà từ mấy bài phân tích về Tor và coi qua cái Tor Bundle, chắc em chuyển qua tìm hiểu về phương pháp phát hiện proxy và cấm tiệt không cho truy cập nếu phát hiện dùng tor quá smilie

Trash from trash is the place for new good things ~

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	28/02/2012 09:53:29 (+0700) \| #69 \| 255981

bolzano_1989
Journalist

Joined: 30/01/2007 12:49:15
Messages: 1406
Offline

Lúc đầu bạn .lht. có đề cập đến việc chôm cookie dựa trên lỗi trình duyệt và ứng dụng web, sau đó bạn đã xóa
đi rồi, mình hoàn toàn đồng ý việc có thể xảy ra tình huống này. Bkav hay victim có thế lực hoàn toàn có thể bắt tay với những diễn đàn hay website thông dụng nào để chôm cookie người dùng trong giai đoạn điều tra tội phạm, tuy nhiên mình cho rằng việc làm này khá bẩn và vi phạm quyền riêng tư con người trầm trọng.

Gửi anh mrro:

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?

Kiểm tra các file bạn nghi ngờ có virus:
http://goo.gl/m3Fb6C
http://goo.gl/EqaZt
http://goo.gl/gEF8e
Nhận mẫu virus qua FB: http://goo.gl/70Xo23
HVA Malware Response Team: kiemtravirus@gmail.com
Trợ giúp diệt virus: http://goo.gl/2bqxY

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

tranhuuphuoc
Moderator

Joined: 05/09/2004 06:08:09
Messages: 865
Location: Lầu Xanh
Offline

Mình chỉ end-user sử dụng Tor, theo như kiến thức của mình biết thì Tor trên máy của mình sẽ chọn bất kỳ node nào để truyền dữ liệu đến đích và đường đi này chỉ xác định trong khoãng thời gian nào đó chứ không phải thời gian hoàn toàn vĩnh viễn , kết thúc thời gian này xong thì nó lại xác định 1 đường đi kế tiếp, như vậy nó sẽ thay đổi liên tục và việc truy tìm thủ phạm rất gian nan, vất vã.

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. smilie

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

vd_
Member

Joined: 06/03/2010 03:05:09
Messages: 124
Offline

@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 smilie

( 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 )

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	28/02/2012 13:34:32 (+0700) \| #72 \| 256044

bolzano_1989
Journalist

Joined: 30/01/2007 12:49:15
Messages: 1406
Offline

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 ( 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 smilie

. 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 smilie

).

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?

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	28/02/2012 18:38:46 (+0700) \| #73 \| 256091

WinDak
Researcher

Joined: 27/01/2002 11:15:00
Messages: 223
Offline

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 ?

-- w~ --

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

.lht.
Member

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

Về mảng social engineering thật sự em thấy hay và không "tởm" như anh conmale nghĩ smilie

Ở 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 smilie

Trash from trash is the place for new good things ~

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

Phó Hồng Tuyết
Member

Joined: 20/04/2007 20:02:10
Messages: 275
Location: Nơi Sâu Thẳm Tâm Hồn
Offline

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 : smilie

"Một người thành công không có ý nghĩ đổ thừa thất bại do ...."

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

WinDak
Researcher

Joined: 27/01/2002 11:15:00
Messages: 223
Offline

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.

-- w~ --

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	29/02/2012 03:46:11 (+0700) \| #77 \| 256170

kinggreedy1991
Member

Joined: 26/02/2012 00:52:18
Messages: 1
Offline

.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 smilie

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 smilie

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 smilie

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 smilie

=> 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 ?

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

conmale
Administrator

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

.lht. wrote:

Về mảng social engineering thật sự em thấy hay và không "tởm" như anh conmale nghĩ

Ở 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

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.

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

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

mrro
Administrator

Joined: 27/12/2001 05:07:00
Messages: 745
Offline

@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 smilie

.

-m

http://tinsang.net

TetCon 2013 http://tetcon.org

Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html

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

vd_
Member

Joined: 06/03/2010 03:05:09
Messages: 124
Offline

@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... Chưa kể theo thời gian thì sự chủ quan của con người sẽ tăng và sẽ dễ bị mắc sai lầm (to err is human) -> chỉ cần đủ kiên nhẫn, đủ thời gian góp nhặt thông tin thông qua việc đánh dấu các phát biểu liên quan đến sự việc thỉ cũng có thể thu thập khá khá thông tin. Và như vậy, chỉ cần tóm bạn của bạn của bạn của .... thì với social engineering + "physical" engineering (xem phim Mẽo, quánh 1 trận thì cái gì cũng khai smilie

) => có thể tiếp cận được.

Vì vậy, cảnh báo của conmale hay mrro không bao giờ thừa.

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

neoad
Member

Joined: 28/06/2006 17:14:17
Messages: 5
Offline

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 smilie

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

bolzano_1989
Journalist

Joined: 30/01/2007 12:49:15
Messages: 1406
Offline

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.

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

phanledaivuong
Member

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

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 smilie

.
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.

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	01/03/2012 10:13:09 (+0700) \| #84 \| 256393

trantuan_bkhcm
Member

Joined: 25/11/2004 07:01:30
Messages: 6
Offline

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 smilie

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ý

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	07/03/2012 19:57:45 (+0700) \| #85 \| 257125

afterlastangel
Member

Joined: 08/12/2007 21:58:13
Messages: 33
Offline

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ờ.

Beneath this mask there is more than flesh. Beneath this mask there is an idea, and ideas are bulletproof.

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

afterlastangel
Member

Joined: 08/12/2007 21:58:13
Messages: 33
Offline

<Lạc đề lan man>
Nếu người thâm nhập chỉ cần không là người Việt Nam, ở Việt Nam như từ đầu đã nói thì em nghĩ không đến mức phải quá cẩn trọng trong mọi hành động nước bước.
Đơn giản nếu đã biết được tao là ai thì cũng không thể làm gì được tao nếu tao chẳng có liên hệ gì khi còn ở VN cả. Và cái danh sách blacklist của VN cũng dài lắm rồi nên mấy tên cỏn con này chắc cũng chẳng được để ý lắm.
=> em đoán nhiều khả năng người này đang ở Việt Nam
</Lạc đề lan man>

Quay lại vấn đề phân tích log khi truy cập. Mọi người chắc chỉ để ý đến Access Log không phân tích đến các log của Web Analytics. Để ẩn danh rắt kỹ thì chắc phải chuẩn bị kế hoạch và chắc chắn cũng cần audit trước khi tấn công vì con người mà...

Nhưng ví dụ nếu truy cập bằng Tor lúc đầu thì đã để lại 1 lỗ hổng rất lớn rồi. Vì các chữ kí lạ lẫm rất dễ bị phát hiện. (Không flash, không script, độ phân giải màn hình).

Việc lục log của ISP là có khả năng xảy ra. Vì nghe đồn thì ISP ở VN cũng bị bắt buộc ghi log lại. Có người nói rằng an toàn khi xài Tor. Nhưng thử hỏi kỹ lại ở VN có bao nhiêu người dùng các port khác để truy cập vào 1 server mà không dùng port 80. ISP có thể lọc ra tất cả các kết nối đáng nghi ngại (nếu như đã có policy từ trước) như dùng VPN và xác định user đó đang dùng Tor. Theo em nghĩ đến lúc này có thể khoanh vùng lại còn chừng vài chục ngàn người. Sau đó so sánh các kết quả này với thời gian BKAV bị tấn công (nếu phát hiện được).
Anonymous có thể cầm cái mặt nạ để đi cướp an toàn nhưng chính cái mặt nạ ấy nên có thể người ấy đã là mục tiêu bị theo dõi từ lâu. (Ví dụ như 1 vụ án đối tượng sử dụng súng thì công việc của công an cũng rất dễ dàng để sàn lọc được đối tượng).

Beneath this mask there is more than flesh. Beneath this mask there is an idea, and ideas are bulletproof.

Go to:

Users currently in here
1 Anonymous