Messages posted by: StarGhost

http://en.wikipedia.org/wiki/SOCKS
http://tools.ietf.org/html/rfc1928

Cho mình hỏi bộ nhớ ngoài là cái gì vậy?

@mrro: à, hóa ra đây là các kiểu tấn công hoàn toàn mới, khác nhiều với suy nghĩ của mình. Bạnmrro tài thật, lại còn biết mình sẽ tham gia nữa. ^_^

@WinDak:
1) việc gắn 2 messages không phải do attacker làm, mà là do server làm.
2) Mình thấy bạn nói cũng có lí. Về mặt nguyên tắc thì toàn bộ communication phải được bound với credentials, bao gồm cả requests lẫn replies. Lúc đầu mình cũng không tưởng ra là server lại chấp nhận unauthenticated requests. Mình cho rằng đây phần nhiều là lỗi implementation. Tuy nhiên, mình cũng không chắc là trong RFCs của TLS có nhấn mạnh điều mình nói ở trên để nhắc nhở developers không nữa.
p/s: Cái link của mrro không có die, chỉ là nó thừa dấu chấm thôi.

Không phải là không phát hiện ra. Thực ra ý tưởng về sự yếu kém từ việc bất đồng về khái niệm security ở các layers đã được bàn thảo khá lâu rồi. Ngoài TLS ra thì còn một số các protocols khác cũng bộc lộ nhược điểm, ví dụ như BTNS IPSec, HIP.

Các protocols này (kể cả TLS) thường hoạt động hoàn hảo nếu chúng đi cùng với PKI. Đáng tiếc, không phải lúc nào cũng vậy. Thêm vào đó là các vấn đề như: higher-layer protocols không hiểu mình được cái gì bảo vệ, lower-layer protocols không hiểu mình đang bảo vệ cái gì, thời lượng của communication sessions ở mỗi layer khác nhau, etc.

Tuy nhiên, cách thức chính xác để tấn công vào HTTP và TLS thì bây giờ mới thấy nói. Chỉ có điều, ở paper trên tác giả viết hơi khó hiểu, nên mình cũng chưa nắm rõ. Bạn mrro có thể giúp mình chỉ ra step-by-step của cuộc tấn công trong cả 3 scenarios được không?

Khiếp, có mỗi cái luận án mà sao những 32MB nhỉ? To quá mình chả download được. Nghe nói đây là công trình tâm huyết mấy chục năm lận.

@puffy: cái vụ seteuid() của bạn mình không đồng ý nhé. Không biết bsd kernel hoạt động ra sao, chứ trong linux thì chả cần seteuid(), chỉ cần SUID bit được set trong file permission thi khi file đó được chạy, euid sẽ tự động được set luôn thành file owner.

WinDak wrote:

Không phải không thể, như bạn xem kỹ bài ở trên mình vẫn có thể ptrace được SUID program, trong khi ptrace của tớ euid là "user". Vấn đề là khi đó thì euid mình vẫn chỉ là euid của ptrace chứ không được copy từ SUID của process child.

Như vậy thì có gì mâu thuẫn? Nếu bạn gọi ptrace() trước, thì process sẽ không có suid/sgid. Nếu process đã có suid/sgid rồi, thì bạn không thể ptrace() được nữa. Đây là nguyên tắc security cho ptrace().

WinDak wrote:

Một cái nữa mình đã thử là thử fopen(/etc/shadow) khi đang ptrace thì bị block ngay tại trận, như vậy ptrace không care đến cái SUID mà mình đã set.

Không hiểu câu này của bạn. Bạn cơ bản không thể ptrace() được process có suid hoặc sgid, trừ phi process của bạn có euid là root. Một ví dụ điển hình là khi dùng gdb để debug suid/sgid programs.

Nếu bạn muốn dấu algorithm này kia thì mình có một cách này. Đầu tiên bạn viết program của bạn như bình thường. Sau đó set permission cho nó, ví dụ 700, trong đó owner là bạn. Sau đó bạn viết một suid program khác gọi cái program này (dùng execve()).

Bạn không mơ ngủ, và đây cũng không phải là bug của Linux. Linux cho phép cái này để phục vụ debugging. GDB thông báo "Permission denied" là vì nó tiến hành open() cái executable trước khi ptrace() nên bị denied, chứ không phải là không trace được.

Tuy nhiên, bạn chỉ có thể đọc được binary của executable này và các file bạn có read permission. Ngoài ra thì không còn gì khác. Hơn nữa, bạn cũng phải tốn khá nhiều công sức mới recover được chính xác cái binary đó, chỉ dựa vào việc peek qua ptrace.

Không biết các bạn thì thế nào, chứ mình thì tình hình là không qua nổi mấy cái tiêu chuẩn trên kia rồi. Mình trước giờ chỉ biết quan niệm là học nhiều biết nhiều, học ít biết ít, học tí nào hay tí ấy, chứ chả có chuẩn chiếc gì cả cho mệt óc.

Ha ha, đây là minh chứng rõ rệt cho hậu quả của việc dùng non-standard cryptographic primitives. Mình chỉ có một comment là không hiểu sao tụi Flickr lại dùng từ "signature", khiến cho cái paper có thể bị dị ửng bởi cryptographers.

Ngoài ra, mrro nên tiếp tục làm một số literature research và mở rộng scope của vấn đề, ví dụ: weaknesses in message authentication techniques on practical systems. Như vậy có thể submit một paper tới một conference hoặc workshop, có thể không là Usenix, nhưng nhỏ hơn thì có thể. Làm sao mà references tầm khoảng 25 cái trở lên là được.

@Mr.Kas: các câu hỏi của mình không phải vô lý. Cái được gọi là tutorial của bạn hầu như chả có gì ngoài việc giới thiệu một cái template. Nếu là mình, mình chỉ cần nói: "À mình biết một cái template cho Web server security hay lắm, các bạn download về nghiên cứu thử. Link ở đây:
http://www.first.org/resources/guides/w2k3.zip". Mấy cái screenshot về sau thực ra không cần thiết vì đối tượng của template không phải là người dùng thông thường, mà là administrators. Nếu họ phải dùng đến cái gọi là tutorial của bạn thì trình độ họ quá kém để administer một hệ thống.

Cái mà mọi người thực sự mong chờ ở đây là cái kiến thức và kinh nghiệm của bạn khi dùng template này, vì mọi người ai cũng có thể google các keys trong đó, nhưng chỉ có người có kinh nghiệm mới hiểu rõ mỗi key có ảnh hưởng ra sao đến hệ thống, việc thay đổi giá trị của nó theo hướng nào thì tạo ra hiệu ứng gì, và tại sao. Tuy nhiên, mình còn chưa thấy nó được thể hiện chỗ nào trong topic này.

Ở đây mình thấy có câu hỏi của bạn ongvove_2009 là khá hay, và cũng là vấn đề mình quan tâm. Đáng tiếc là mình không có cái gọi là kinh nghiệm như bạn, nên mình cũng mong bạn mô tả rõ các configuration liên quan.

p/s: cái blog http://tuaninfo.co.cc chắc là của bạn hả?

@iltomats: kiểu debug của bạn mình cũng áp dụng đó. Còn kiểu hay hơn thì mình cũng không rõ lắm, vì mình không mấy khi lập trình.

Còn việc bạn dùng gdb nhảy vào cái gọi là thư viện system, thì mình xin có lưu ý sau:
- Thứ nhất, không có cái gì gọi là thư viện system cả, chỉ có thư viện (libraries), hoặc là syscalls.

- Đây không phải là vấn đề với gdb - một debugger, mà là vấn đề với libc. Các modules của libc đều được complied tối ưu hóa hết mức có thể, nên không một debugger nào có thể nhảy vào từng function trong libc để show cho bạn high-level C code. Bạn chỉ có thể debug bằng assembly.

- Một số compilers chọn giải pháp dùng trực tiếp syscalls thay vì nhảy vào libc rồi gọi syscalls trong đó. Trong trường hợp này thì bạn không thể debug được syscalls vì nó được xử lý ở kernel mode. Nếu muốn, bạn có thể debug kernel, nhưng nói chung là khá phức tạp.

- Trong trường hợp bạn muốn debug một function trong libc, bạn có thể tìm source của function đó, compile nó (với -g switch) rồi override nó với function gốc trong libc. Cách làm hết sức đơn giản, xem trong http://www.ibm.com/developerworks/linux/library/l-glibc.html.

- Nếu bạn cảm thấy painful khi dùng gdb, thì có thể dùng một GUI của nó, ví dụ như DDD chẳng hạn. Tuy nhiên, nếu bạn dùng nhiều thì mới thấy được gdb cho bạn đầy đủ những thứ bạn cần, chỉ có điều đòi hỏi bạn phải biết các commands cần thiết.

tranhuuphuoc wrote:

Cách đây vài ngày tôi có nhận được phần mềm của bạn hkvn , theo thông tin mà tôi được biết phần mềm này không lạ gì với anh em "chế độ củ" HVA , VNOSS trước đây nhưng tiếc vì lý do trót hứa không cung cấp, không phân tán cho nên tôi không gởi lên để bà con mổ xẽ và bình luận .

Vậy thì lão tự mổ xẻ và bình luận đi thôi. Mình chỉ khoái nhất cái đoạn sau

Ghép kênh (tính năng độc đáo của GG): Kết hợp nhiều đường truyền để tạo ra đường truyền tổng hợp có địa chỉ IP tĩnh riêng có băng thông bằng tổng băng thông các đường truyền thành phần.Đường truyền này cũng có thể cam kết tốc độ tối thiểu ra quốc tế như leased line nhưng chi phí thấp hơn do tận dụng được hạ tầng của các công nghệ phổ thông.

Không biết câu thần chú ở đây là gì?

Mr.Kas wrote:

Cái con keyloger mà tớ dùng thực chất là một chương trình theo dõi hệ thống (có cả log system) của một công ty chuyên cung cấp các giải pháp bảo mật (tiếc là tớ quên của công ty nào rồi) để tớ tiện theo dõi máy tớ, và mặc định của cái chương trình này là chụp ảnh định dạng bmp 24 bit (máy tớ dùng LCD 1440x900 nên hơi nặng kí) và cái này không phải dùng để "ăn cắp" password vì máy của tớ thì chỉ có tớ dùng và tớ chả cho ai đụng vào làm gì cả. Vả lại máy tính văn phòng trong các công ty nhỏ lẽ (không phải các tập đoàn IT lớn) thì hầu như là main 845, HDD 40 GB, đâu tới TB

Nếu bạn StarGhost cảm thấy cái "công ty" ấy "to" thế mà viết 1 cái phần mềm vừa "thiển cận" vừa "kém cỏi" thì tớ nghĩ StarGhost đủ sức mở một "tập đoàn" bảo mật lớn rồi đấy, có khi cạnh tranh thắng cả anh Quảng nhà ta

Hì, bạn không cần phải khích mình như thế. Mình thấy bạn phát biểu hơi khập khiễng, vì lúc đầu bạn nói rằng nó là keylogger, rồi bây giờ bạn lại bảo nó là monitoring software. Có công ty bảo mật nào viết keylogger không bạn? Nếu người viết chương trình đó có coi nó như một monitoring software thì chả nói làm gì, nhưng nếu coi nó là một keylogger thì vẫn là thiển cận thôi.

Mr.Kas wrote:

máy đã bị cài virus keylogger có chức năng ghi bàn phím và chụp hình lúc mỏ yahoo chat lên

Thế còn việc chụp hình thì tính thế nào ?

Trước đây tớ cũng có thử con keyloger trên chính máy tính mình, hẹn giờ cứ 3s chụp hình một lần, và kết quả là cảm thấy chiếm bộ nhớ rất nhiều vì một tấm ảnh đến 3.70 MB (định dạng bmp 24 bit).

Vậy thì cái người viết keylogger đó quả là thiển cận khi không dùng jpeg. Hơn nữa, hard drive bây giờ hầu hết đều rất lớn, mình thật không nghĩ đến chuyện bị đầy vì một con keylogger. Một con keylogger mà chỉ ăn cắp Yahoo password thì quá là kém cỏi. Ngay cả việc hẹn giờ cứ 3s chụp hình một lần đã cho thấy nó không được viết một cách cẩn thận.

Bạn Mr.Kas cho mình hỏi là cái file kia ở đâu ra mà có, do bạn tạo ra? Hay là ai khác, và nếu do ai đó, thì bạn lấy từ đâu? Hơn nữa, update cuối cùng của nó cũng đã cách đây gần 6 năm, nó vững vậy sao? Còn nữa, bạn đã kiểm tra kĩ càng xem nó có gây ra các "phản ứng phụ" gì hay chưa?

Mr.Kas wrote:

máy đã bị cài virus keylogger có chức năng ghi bàn phím và chụp hình lúc mỏ yahoo chat lên, NV nào chát sẽ bị mất password yahoo.

Mình nghĩ cái Keyloger này chỉ được bật khi mở Yahoo lên, còn trên nền trình duyệt thì nó không chủ động ghi lại, chứ nếu không thì dung lượng máy làm gì đủ cho Keyloger ghi log (Trung bình một ngày mọi người gõ phím rất nhiều nên cũng có rất nhiều thứ cần ghi lại)

Mình thấy bạn Mr.Kas phát biểu rất là thiếu thực tế. Cứ cho là dung lượng hard drive của máy còn 1GB trống, thì không biết là bạn phải gõ mất bao nhiêu năm mới ghi đầy được 1 GB đó, khi mà mỗi cú gõ của bạn nhiều nhất cũng chỉ là 2 bytes.

mrro wrote:

@StarGhost: mình không hiểu mình đọc sót chỗ nào nhỉ? bạn mô tả cơ chế xác thực của SSH, cho rằng điểm yếu nhất là ở lần đầu, không có cách nào để xác thực. Thì mình mới nói, ở lần đầu đó, server có đưa ra cái key fingerprint mà, thế thì sao lại cho là không có cách nào để xác thực?

Việc user không kiểm tra key fingerprint vì kiểm tra cái đó tốn thời gian hoặc tốn tiền là chuyện hoàn toàn khác. Mình nói rồi đó, security is not free.

-m

Hì hì, có lẽ bạn không đứng trên góc độ của một protocol designer nên mới nói vậy. Hiện tại các nghiên cứu về authentication với inexpensive infrastructure rất quan trọng, vì chúng sẽ được dùng phổ biến hơn nhiều các kiểu authentication khác như PKI.

mrro wrote:

@StarGhost: security is not free :-p. nếu mà không muốn mất thời gian hay mất tiền để kiểm tra thì cứ nhắm mắt xài thôi. key fingerprint thì khi kết nối lần đầu, openssh server có đưa cho user thấy cái fingerprint mà.

---> Trên thực tế, đây là cách mà hầu hết SSH user chọn.
--->Hì hì, bạn còn chưa đọc kĩ mô tả của mình về LoF authentication ở trên. Vấn đề chính là ở cái "lần đầu" này.

@conmale: với một security expert như anh thì đây có lẽ không phải là vấn đề. Nhưng nó lại là vấn đề với hầu hết network users, và thực ra cái risk của LoF authentication vẫn là một đề tài gây tranh cãi.

@mrro: vấn đề là ở đây: làm thế nào để kiểm tra fingerprint, khi mà ta còn không biết cái fingerprint thực nó trông như thế nào. Nếu cái SSH server không phải của mình, và mình cũng không liên lạc được với những người biết fingerprint của server đó (qua out-of-bound channels như telephone hay SMS), thì phải làm sao? Đấy là còn chưa kể đến việc dùng out-of-bound channels tạo ra cost mà không phải SSH user nào cũng muốn.

@conmale: khi anh cài lại máy, và putty đến SSH server B qua proxy, anh sẽ nhận được một cái warning về unknown host key. Vậy lúc này anh xử lý ra sao? Đây mới là vấn đề về authentication (làm sao ta biết được người đang kết nối với mình chính xác là người mình muốn kết nối?)

SSH được sử dụng rộng rãi bấy lâu nay phần ít là do nó có secure channel, nhưng phần nhiều là do nó không đòi hỏi các security infrastructure như PKI, Web of Trust, hoặc database of credentials dùng trong server authentication. Phương thức mà nó sử dụng được gọi là Leap-of-Faith (LoF) authentication.

Ý tưởng của LoF thì đúng như tên gọi của nó: khi anh kết nối tới một server B lần đâu tiên (first communication), anh không có một thông tin gì để xác minh sự thật thà của server đó, thì thay vì cố gắng tìm cách authenticate server này, anh nhảy (jump, leap) qua tin tưởng (faith) server B đó ngay lập tức. Thông qua cú nhảy này, anh thiết lập một số thông tin để sau này khi anh gặp lại server B, anh có thể chắc chắn rằng nó chính là cái server anh đã kết nối trước kia. Cái thông tin đó trong trường hợp của SSH chính là public key của server B.

Tuy nhiên, vấn đề với LoF authentication là ở chỗ làm sao anh biết được là attacker có hay không xuất hiện trong first communication, lúc mà authentication thực sự bị bỏ qua.

Cho mình hỏi NetID là cái gì vậy bạn? Mình đọc đi đọc lại bài của bạn mà không hiểu gì cả.

@conmale: trước khi anh cài lại máy, anh có nghĩ đến chuyện export và backup đoạn registry chứa host keys của putty hay không? Em thấy mọi người cứ hay bàn về mã hóa này nọ, nhưng điều quan trọng hơn, và cũng là nền tảng của security, tức là authentication, thì không thấy ai nói đến. Câu hỏi cần đặt ra là: làm sao ta biết được người đang kết nối với mình chính xác là người mình muốn kết nối. Vấn đề này rất quan trọng khi các securiy infrastructure thuộc dạng phức tạp và đắt đỏ như PKI, Web of Trust, database of credentials không tồn tại.

@Mr.Kas: để mình phân tích thử xem nhé:
- Living Promiscuously: cái này thì chả có gì đáng nói cả, vì hầu hết NIC bây giờ đều có promiscuous mode.

- Sniff trong mạng hub: cũng chả có gì đáng nói, vì dùng hub thì ráng chịu.

- port mirroring: nếu attacker không login được vào switch (trong hầu hết trường hợp), thì cách này vô tác dụng. Nếu switch không support port mirroring thì cũng vô tác dụng.

- hubbing out: đòi hỏi attacker phải có một cái hub trong tay, và phải sờ được vào đường dây kết nối đến đối tượng. Nếu attacker không thỏa mãn 2 điều kiện này, thì cũng vô dụng.

- ARP poisoning:

Mr.Kas wrote:

Khi một máy tính cần gửi dữ liệu cho một máy khác, nó gửi một yêu cầu ARP tới switch mà nó kết nối. Switch đó sẽ gửi một gói ARP broadcast tới tất cả các máy đang kết nối với nó để hỏi. Khi mà máy đích nhận được gói tin này, nó sẽ thông báo cho switch bằng cách gửi địa chỉ MAC của nó. Sau khi nhận được gói tin phản hồi, Switch định tuyến được kết nối tới máy đích. Thông tin nhận được được lưu trữ trong ARP cache của switch và switch sẽ không cần phải gửi một thông điệp ARP broadcast mới mỗi lần nó cần gửi dữ liệu tới máy nhận.

Đoạn này cho thấy bạn chưa thật sự hiểu ARP và switch hoạt động như thế nào. ARP là protocol thuộc dạng end-to-end, nó không cần sự can thiệp của switch. Ở mức độ cơ bản nhất, switch thậm chí không cần phải biết ARP là cái gì mà vẫn hoạt động đúng với chức năng của nó. Vậy nên cũng không có chuyện switch cần và lưu thông tin gì từ ARP cả.

Mr.Kas wrote:

ARP cache poisoning là một kỹ thuật nâng cao trong việc nghe đường truyền trong một mạng switch. Attacker gửi các gói tin địa chỉ sai tới máy nhận với mục đích để nghe trộm đường truyền hiện tại, ARP cache poisoning là quá trình gửi một thông điệp ARP với địa chỉ MAC giả mạo tới switch hoặc router nhằm mục đích nghe lưu lượng của thiết bị mục tiêu.

Một gói tin địa chỉ sai là một gói tin như thế nào? Gói tin đó làm thế nào mà giúp attacker đạt được mục đích nghe lén? Vậy sử dụng static ARP có ngăn chặn được việc này hay không, và sử dụng ra sao?

Cuối cùng, nếu static ARP có thể ngăn chặn được ARP cache poisoning, và nếu các attacks bên trên cũng không khả thi, vậy thì việc sniff trong switched network đã bị ngăn chặn hay chưa?

@conmale: giả sử máy anh mới cài lại, sau đó anh SSH đến server đúng lúc có attacker trong hệ thống, thì hơi gay go đấy.

@Mr.Kas: mình thấy bạn cứ luẩn quẩn mãi về NetBIOS. Bây giờ mình giả sử tất cả các máy trong network đều tắt hết những gì liên quan đến NetBIOS, vậy việc tìm ra địa chỉ IP các máy đó có khả thi không?

Còn về cái việc sniffing trong network, sẽ rất thú vị nếu bạn mô tả (ngắn gọn) các kiểu tấn công và phân tích xem việc cấu hình static ARP thì ngăn chặn được cái gì và không ngăn chặn được cái gì, tại sao. Mình thì không có nhiều kiến thức về mảng này, tuy nhiên mình có thể thảo luận dựa trên quan điểm của bạn.

Mr.Kas wrote:

Từ hồi mình biết dùng Internet đến nay, chưa có hệ thống mạng nào mình sử dụng mà có cái gì gọi là WINS server cả, vậy phải chăng các hệ thống mạng đó đã ngăn chặn việc dò tìm địa chỉ IP?

Xin trả lời bạn vài điểm như sau, WINS chính là Windows Internet Name Service, được triển khai trong LAN để phục vụ các máy tính trong mạng phân giải NetBIOS name (Computer name) lẫn nhau. Trong các mô hình Network. Hiện nay (ví dụ Network Microsoft Windows 2000/2003) sử dụng giải pháp tìm tên là DNS service, WINS service triển khai thêm là một sự lựa chọn mở rộng và hoàn toàn không bắt buộc gì cả. Tuy nhiên nhiều Tổ chức muốn dùng My Network Places để có thể xác định các Server trên Network. My Network Places hoạt động tìm kiếm các Network Computer dựa trên Windows Browser service. Và Windows Browser service giải quyết tên dựa trên nền tảng broadcast (broadcast-based service), nếu Network triển khai WINS server thì Windows Browser service trên các Computer sẽ phụ thuộc vào WINS server để thu thập thông tin về các Computer phân tán khắp các Segment của Network.

Bạn còn chưa trả lời câu hỏi của mình. Mình đâu có hỏi bạn WINS là gì và hoạt động ra sao, mình chỉ hỏi là nếu một network không có WINS, vậy phải chăng network đó đã ngăn chặn attacker tìm ra địa chỉ IP của các máy?

Mr.Kas wrote:

Vậy chứ việc khóa cứng ARP và dùng ARP static thì hạn chế MitM attacks ra sao?

Khóa cứng bảng ARP và chọn dạng ARP startic sẽ giúp máy chúng ta hạn chế được hình thức tấn công thay đổi bảng ARP (còn gọi là Spoofing ARP). Và sẽ tránh được sniff.

A, cái này do bạn đọc được ở đâu hay suy luận ra vậy? Bạn có chắc không vậy?

Mr.Kas wrote:

Thế nào là xác định đúng mục tiêu, địa chỉ IP nó có cái gì mà giúp xác định đúng mục tiêu vậy? Vậy nếu mình cứ muốn tấn công bất kì môt ai đó thì sao?

Mình nghĩ khi attack thì hacker sẽ nhắm vào một hay một vài mục tiêu nào đó được xác định rõ ràng. Không tấn công tràng lang được. Ví dụ trong một LAN có 100 máy, hacker muốn sniff thông tin từ một ai đó quan trọng thì không thể sniff tất cả và phân tích, mà phải tìm chính xác máy mà mình muốn tấn công. Còn tấn công kiểu "hên xui" thì mình không nói

Mình thấy bạn hơi "ngây thơ" khi nghĩ attacker sẽ phải lựa chọn một mục tiêu nào đó để tấn công. Mình cũng chắc là bạn chưa bao giờ thử sniff và phân tích traffic từ một network với nhiều máy. Mình nói thật với bạn là monitor traffic của 100 máy chả ăn nhằm gì cả, và minh trước đây cũng đã từng làm rồi. Hơn nữa, không một kẻ tấn công nào lại ngồi mò mẫm một cách thủ công mớ traffic được dumped từ tcpdump hoặc wireshark cả. Một nguyên tắc trong security là không bao giờ được phép có những giả định bất lợi cho attacker.

Mr.Kas wrote:

Việc khóa cứng bảng ARP và dùng ARP static liệu thật sự có thể chống được "Man in the middle" không... nhỉ?

Việc này không ngăn chặn được, nhưng hạn chế được một phần Man in the middle, cách khóa cứng bảng ARP chỉ ngăn cản hình thức Spoofing ARP.

Vậy chứ việc khóa cứng ARP và dùng ARP static thì hạn chế MitM attacks ra sao?

Mr.Kas wrote:

Việc quét các địa chỉ IP thì liên quan như thế nào đến tấn công thay đổi bảng ARP nhỉ?

Việc quét này không liên quan đến thay đổi ARP, nhưng thông qua việc quét này hacker có thể xác định đúng mục tiêu trong LAN của mình để tấn công (dùng Spoofing ARP).

Thế nào là xác định đúng mục tiêu, địa chỉ IP nó có cái gì mà giúp xác định đúng mục tiêu vậy? Vậy nếu mình cứ muốn tấn công bất kì môt ai đó thì sao?

Mr.Kas wrote:

Tại sao vô hiệu hóa Netbios name mà ngăn chặn được dò tìm IP nhỉ?

Các Computer trong LAN sẽ được cấu hình với vai trò WINS client, sẽ đăng kí tên của mình (NetBIOS/Computer name) với WINS server. WINS client có thể gửi các yêu cầu truy vấn tên đến WINS server để phân giải Name thành IP address. Dựa vào tính chất đó của WINS Sever chúng ta có thể dựa vào WINS server để phân giải NetBIOS name và sử dụng các thông tin này để tìm kiếm các Computer trong LAN.

Từ hồi mình biết dùng Internet đến nay, chưa có hệ thống mạng nào mình sử dụng mà có cái gì gọi là WINS server cả, vậy phải chăng các hệ thống mạng đó đã ngăn chặn việc dò tìm địa chỉ IP?

Mr.Kas wrote:

Để chống nó thì cũng không có gì khó khăn, nhưng phải hiểu bản chất của nó. Những chương trình thuộc dạng này đều tiên thường phải quét các địa chỉ IP trong mạng, khi đã có IP rồi thì mới tiến hành sniffer. Do đó cách đầu tiên là vô hiệu hóa Netbios name nhằm ngăn cản sự dò tìm IP. Về mặt bản chất thì tools này làm việc dựa trên phương thức thay đổi bảng ARP và tấn công theo kiểu "Man in the midle". Cách khắc phục thứ hai là khóa cứng bảng ARP và chọn dạng ARP startic.

Việc quét các địa chỉ IP thì liên quan như thế nào đến tấn công thay đổi bảng ARP nhỉ?
Tại sao vô hiệu hóa Netbios name mà ngăn chặn được dò tìm IP nhỉ?
Việc khóa cứng bảng ARP và dùng ARP static liệu thật sự có thể chống được "Man in the middle" không... nhỉ?
Bạn Mr.Kas có thể giải thích cho mình rõ được không?

Mình cho rằng bạn suy nghĩ hơi đơn giản quá. Bạn có nghĩ đến những thứ như subliminal channel, covert channel, hay steganography chưa? Việc ngăn chặn thất thoát là điều không thể, thậm chí là như ở Langley người ta kiểm tra tất cả mọi thứ bạn mang ra mang vào. Bạn nên nghĩ đến việc tiến hành access controls và auditing cho cặn kẽ thì hơn.

@mrro: haha, các bác Nhật và Hàn là trùm copy lại của người khác mà. Thế nhưng mà họ viết khéo lắm, mấy cái conferences nho nhỏ là đều lọt cửa hết, vì mấy tay trong đó có mấy khi chịu xem kĩ. Mình mà cho làm commitee chắc cũng bị họ lừa vậy.

Nhưng mà nói chung kể cả attack của Beck-Tews thì cũng chỉ chơi được với ARP thôi. Mà chopchop hình như là một mớ source code thì phải. Sao mrro biết là nó lấy ý tưởng từ đâu?

Về việc "chop", thì trường hợp tổng quát của chopchop là nếu bạn chop k bits, thì bạn sẽ phải thử 2^k lần để tìm ra k bits đó. Tuy nhiên, mình không rõ là AP có chấp nhận packets lẻ byte hay không, nên thay vì chop 1 byte, thì mình chop một lúc 2 bytes luôn. Tất nhiên với điều kiện là thời gian tìm ra 2 bytes này phải nhanh hơn 2 phút, chứ không thì chả bõ.