Thảo luận tcp\ip - .:: HVAOnline ::.

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Thảo luận mạng và thiết bị mạng

Thảo luận tcp\ip

[Question] Thảo luận tcp\ip	20/11/2007 00:37:46 (+0700) \| #1 \| 98666

vikjava
Elite Member

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

Mình mới đọc tcp\ip còn nhiều vấn đề thắc mắc quá , post lên hỏi mọi người .
1. Trong quá trình bắt tay 3 bước thì ISN cho mỗi kết nối được cấp phát theo cơ chế nào , số lại được cấp phát random hay là theo một quy luật hay một cái gì đó ???
2. Ip spoofing : giả vờ gởi dữ liệu từ địa chỉ không phải của hacker, kẻ tấn công sẽ sử dụng giá trị tcp sequence number hợp lệ để thiết lập một kết nối tcp với máy bị tấn công. Về việc giả vờ và sử dụng giá trị sequence number cụ thể như thế nào em không được rõ chỗ này lắm.
3. Trong kết nối tcp\ip khi máy a mở kết nối tới máy b, a sẽ gởi isn (của a) và b sẽ gởi lại isn(của b) + ack=isn(của a)+ 1 . Vậy làm cách nào để can thiệp vào giai đoạn thằng b gởi lại.
4. Connection hijacking : khai thác trạng thái không đồng bộ . Vậy làm thế nào để tạo ra trạng thái không đồng bộ này.

smilie

Mình cần một số câu hỏi để có thể hệ thống lại và bổ sung kiến thức về tcp\ip .Mới đọc qua 2 lần cũng chẳng nắm bắt được nhiều Cảm ơn smilie

[Question] Re: Thảo luận tcp\ip	20/11/2007 02:02:06 (+0700) \| #2 \| 98684

dabu
Elite Member

Joined: 03/03/2003 03:31:20
Messages: 226
Offline

Xin nói cách mình hiểu như sau:
ISN = Initial Sequence Number [khởi động tuần tự số] là con số ngẫu nhiên của client khi gửi 1 SYN yêu cầu đền thiết lấp chế độ 3-way handshake.
Còn việc spoofing IP như sau: Khi biết được số SN [Sequence number] số tuần tự của một packet nào đó thì Hacker có thể chèn vào một gói packet nào đó cố số SN + 1 nhưng có Source IP là của hacker, do vậy packet đó vẫn hợp lệ khi yêu cầu đền server.
Trường hợp thứ 3 bạn nói là SYN flood tức "ngập lụt" gói tin đồng bộ SYN, một hacker có thể viết một chương trình nào đó liên tiếp gửi hoàn loạt các gói tin SYN đên host cần flood nhưng có số IP source là giả mạo. Vì vậy host bị flood sau khi nhận gói SYN nó sẽ trả lời lại nguồn nhưng nguồn này không có thật trên mạng, cho nên nó phải "trông đợi" các gói ACK trở về, trông đợi hoài mỏi mệt quá nên nó bị treo smilie

. Như vọng phu chờ chồng vậy, smilie

Còn Connection hijacking thi mình không hiểu cho lắm.

It's time to build a new network.

[Question] Thảo luận tcp\ip	20/11/2007 04:59:00 (+0700) \| #3 \| 98714

enn3exlibs
Elite Member

Joined: 10/12/2006 16:54:02
Messages: 243
Location: bluesun
Offline

vikjava wrote:

Mình mới đọc tcp\ip còn nhiều vấn đề thắc mắc quá , post lên hỏi mọi người .
1. Trong quá trình bắt tay 3 bước thì ISN cho mỗi kết nối được cấp phát theo cơ chế nào , số lại được cấp phát random hay là theo một quy luật hay một cái gì đó ???

Mỗi kết nối mới được thiết lập sẽ khởi tạo một ISN mới, khác với các ISN trước, số này thay thay đổi theo một quy luật nhất định, không phải random( vì tránh trùng mà): tăng một khoảng theo chu kỳ thời gian, bạn đọc lại trong sách có nói rõ mà( chương 18)

[Question] Thảo luận tcp\ip	20/11/2007 08:39:23 (+0700) \| #4 \| 98773

rickb
Reseacher

Joined: 27/01/2007 17:47:27
Messages: 200
Offline

vikjava wrote:

Mình mới đọc tcp\ip còn nhiều vấn đề thắc mắc quá , post lên hỏi mọi người .
1. Trong quá trình bắt tay 3 bước thì ISN cho mỗi kết nối được cấp phát theo cơ chế nào , số lại được cấp phát random hay là theo một quy luật hay một cái gì đó ???
2. Ip spoofing : giả vờ gởi dữ liệu từ địa chỉ không phải của hacker, kẻ tấn công sẽ sử dụng giá trị tcp sequence number hợp lệ để thiết lập một kết nối tcp với máy bị tấn công. Về việc giả vờ và sử dụng giá trị sequence number cụ thể như thế nào em không được rõ chỗ này lắm.
3. Trong kết nối tcp\ip khi máy a mở kết nối tới máy b, a sẽ gởi isn (của a) và b sẽ gởi lại isn(của b) + ack=isn(của a)+ 1 . Vậy làm cách nào để can thiệp vào giai đoạn thằng b gởi lại.
4. Connection hijacking : khai thác trạng thái không đồng bộ . Vậy làm thế nào để tạo ra trạng thái không đồng bộ này.

Mình cần một số câu hỏi để có thể hệ thống lại và bổ sung kiến thức về tcp\ip .Mới đọc qua 2 lần cũng chẳng nắm bắt được nhiều Cảm ơn

Hi vikjava,

1. Trong quá trình bắt tay 3 bước thì cơ chế cấp phát ISN là phụ thuộc vào cách implementation của từng loại kernel OS. Ngày xưa thời kevin hack vào hệ thống Sun thì người ta ko quan tâm đến việc cấp phát ISN nên đã design kernel cấp phát theo cơ chế tăng dần, do đó khi kevin đọc source code của OS anh ta biết được cách cấp phát đó và có thể Hjacking, còn bây giờ từ sau vụ việc đó thì hầu hết cách kernel mới đều cấp phát ISN theo cơ chế random, càng phức tạp càng tốt

2. Cái này bạn đọc kỹ phương pháp năm xưa kevin tấn công vào Sun sẽ rõ

3. Theo cá nhân mình biết thì để ngăn b trả lời lại thì chỉ có cách ta thực hiện MIMT (ko nhất thiết phải dùng ARP Spoofing, có thể social engineering để set 1 dòng arp static chẳng hạn smilie

) từ trước đó

4. Mình ko rõ ý bạn ở đây lắm nên ko trả lời được

Thân

[Question] Re: Thảo luận tcp\ip	20/11/2007 23:10:50 (+0700) \| #5 \| 98880

vikjava
Elite Member

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

hi all !
1. theo rickb nói thì mình tạm hiểu là isn giống như môt biến đếm cục bộ trong hệ thống, mỗi kết nối được thiết lập sẽ được cấp phát isn theo một nguyên tắc của hệ thống đó.
2. Mình chẳng biết gì về hack nên kevin tấn công như thế nào thì mình chịu thua , mình cũng không có tài liệu nói về vụ này. Mong các bạn giải thích giùm chỗ này hoặc cho một cái hướng dẫn để mình ngâm tiếp smilie

( ngâm hoài chắc tăng huyết áp quá )
3. ARP Spoofing huhuhu phải tìm hiểu tiếp thằng này mới có câu trả lời câu 3 . Nhưng theo mình suy đoán thì arp spoofing thì chắc chỉ có thực hiện trong Lan thui chứ nhỉ , mà để thực hiện trong lan thì phải giả dạng là một máy trong lan ... lại tè le rùi. Help me
4. Trang thái không đồng bộ xảy ra khi số hiệu sequence number trong gói tin nhận được không giống với số hiệu trước đó. tcp xử dụng sliding window để đảm bảo những gói tin thất lạc có thể từ từ tìm đường về, hai thằng kết nối đang ở trạng thái chờ , chúng ta có thể giả mạo gói tín thất lạc đó gởi tới .... Đọc và dịch nó như thế , nhưng mình không hiểu làm thế nào để tạo ra trạng thái chờ đó hoặc cách nào để biết mà tạo ra gói tín nó đang chờ .

p\s: tcp\ip thú vị thật , mọi người thảo luận và chỉ giùm hén. Có gì cho mình một số câu hỏi để hệ thống lại những cái học được và những cái cần bổ sung.

thanks !

[Question] Re: Thảo luận tcp\ip	21/11/2007 01:19:31 (+0700) \| #6 \| 98907

Mr.Khoai
Moderator

Joined: 27/06/2006 01:55:07
Messages: 954
Offline

Chào vikjava,

ARP proof đúng là phải thực hiện trong LAN mà thôi. Việc can thiệp vào thẳng vào giai đoạn 3-way handshack là không thực tế và khá khó thực hiện cho hoàn hảo. Và, bạn tấn công MitM từ 3-way handshack thì có thể hiệu quả cũng chả được gì smilie

TCP không có cơ chế bảo mật nào để MitM có thể đạt hiệu quả tốt.

Bạn cho biết từ chính xác của cái "trạng thái không đồng bộ" là gì? Và bạn muốn tấn công/ứng dụng trạng thái này ở tầng nào? và như thế nào?

khoai

[Question] Re: Thảo luận tcp\ip	21/11/2007 05:46:42 (+0700) \| #7 \| 98967

vikjava
Elite Member

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

Chào khoai và mọi người !
Mình đọc tài liệu thấy nó nói những vấn đề trên, mình không hình dung ra được cách thực hiện . Và như khoai nói thì nó khó thực hiện . Mình chỉ muốn biết nó thực hiện như thế nào smilie

Không hiểu câu hỏi của khoai lắm , nội dung của trạng thái không đồng bộ tớ đọc ở đây.

3.Man in the Middle Attack

This is also called connection hijacking. In this attacks, a malicious party intercepts a legitimate communication between two hosts to controls the flow of communication and to eliminate or alter the information sent by one of the original participants without their knowledge. In this way, an attacker can fool a target into disclosing confidential information by spoofing the identity of the original sender or receiver. Connection hijacking exploits a "desynchronized state" in TCP communication. When the sequence number in a received packet is not the same as the expected sequence number, the connection is called "desynchronized." Depending on the actual value of the received sequence number, the TCP layer may either discard or buffer the packet. When two hosts are desynchronized enough, they will discard/ignore packets from each other. An attacker can then inject forged packets with the correct sequence numbers and potentially modify or add messages to the communication. This requires the attacker to be located on the communication path between the two hosts in order to replicate packets being sent. The key to this attack is creating the desynchronized state.

thân!

[Question] Re: Thảo luận tcp\ip	21/11/2007 16:22:06 (+0700) \| #8 \| 99059

Mr.Khoai
Moderator

Joined: 27/06/2006 01:55:07
Messages: 954
Offline

Àh, vậy ý chính của đoạn trên là muốn tạo desychronized state giữa hai hosts khi tấn công MitM. Vậy vikjava hãy nghĩ xem, desynchronized state là tình trạng gì? Và cần có điều kiện gì để tạo ra tình trạng đó?

Và vì sao tác giả đoạn trên lại phải tạo ra desynchronized state? Nếu không có desynchronized state mà cứ hijack thì điều gì sẽ xảy ra?

khoai

[Question] Re: Thảo luận tcp\ip	21/11/2007 22:52:20 (+0700) \| #9 \| 99084

vikjava
Elite Member

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

Hi Khoai và mọi người !

- desynchronized state xảy ra khi hai bên đã thiết lập kết nối nhưng không có dữ liệu được truyền và server_seq không bằng client_ack , client_seq không bằng sever_ack .
- Vì ở trạng thái desynchronized state thì cả hai ở trạng thái chờ gói tin hợp lệ , tạo ra trạng thái chờ này thì người tấn công có thể giả mạo gói tin mà tụi nó chờ.
- Nếu không có desynchronized state mà cứ hijack thì điều gì sẽ xảy ra? Mình không hiểu được câu này lắm , suy luận là không có điều gì xảy ra cả vì theo khoai nói là khó can thiệp vào một kết nối tcp khi nó đang hoạt động trơn tru.

thân!

[Question] Re: Thảo luận tcp\ip	22/11/2007 01:36:38 (+0700) \| #10 \| 99138

Mr.Khoai
Moderator

Joined: 27/06/2006 01:55:07
Messages: 954
Offline

vikjava wrote:

- desynchronized state xảy ra khi hai bên đã thiết lập kết nối nhưng không có dữ liệu được truyền và server_seq không bằng client_ack , client_seq không bằng sever_ack .

Thật ra nếu không có dữ liệu đựoc truyền thì làm sao có....desychronized state được smilie

Đúng là tình trạng trên xảy ra khi server ack khác client seq, và client ack khác server seq. Nhưng cụ thể là khác hơn thế nào?

vikjava wrote:

- Nếu không có desynchronized state mà cứ hijack thì điều gì sẽ xảy ra? Mình không hiểu được câu này lắm , suy luận là không có điều gì xảy ra cả vì theo khoai nói là khó can thiệp vào một kết nối tcp khi nó đang hoạt động trơn tru.

Ý khoai nói khó là khó khi phải chờ một gói cụ thể, ví dụ là SYN/ACK khi bạn muốn tấn công vào 3-way handshack. Giả sử bạn inject dữ liệu vào một TCP stream, hoặc hijack stream đó thì phía server sẽ có client seq, client ack, server seq và server ack như thế nào. Vậy còn client thật thì các thông tin trên như thế nào. Và, TCP sẽ hoạt động thế nào trong tình trạng trên? Tình trạng trên không phải là desynchronized state nhé.

khoai

[Question] Re: Thảo luận tcp\ip	22/11/2007 03:41:25 (+0700) \| #11 \| 99157

vikjava
Elite Member

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

Chào khoai và các bạn

Mình xin chỉnh lại là sau khi đã thiết lập kết nối , dữ liệu được truyền nhưng việc tryên này bị tắt nghẽn ( rơi vào trạng thái đợi)và server_seq không bằng client_ack , client_seq không bằng sever_ack .

Câu hỏi của khoai về phần cụ thể là khác hơn thế nào thì chắc đợi mình tối về ngâm cứu mai sẽ thảo luận tiếp ... hihihi công lực chưa đủ để trình bày.

Câu dưới khoai hỏi thì mình bó tay . khoai và các bạn cho mình một hướng đi smilie

Thân!

[Question] Re: Thảo luận tcp\ip	22/11/2007 13:17:25 (+0700) \| #12 \| 99296

281
Elite Member

Joined: 27/05/2007 00:22:15
Messages: 228
Offline

vikjava wrote:

Chào khoai và các bạn

Mình xin chỉnh lại là sau khi đã thiết lập kết nối , dữ liệu được truyền nhưng việc tryên này bị tắt nghẽn ( rơi vào trạng thái đợi)và server_seq không bằng client_ack , client_seq không bằng sever_ack .

Ý của bồ có phải là sau khi thiết lập kết nối, Client truyền dữ liệu tới Sever, trên đường đi thì bị tắt nghẽn (có thể Packet bị mất), đúng không?

Nếu Packet không tới được Server thì làm sao Server có client_seq? --> Server đợi và Client thì đợi server_ack, sau một thời gian (timeout) không nhận được ACK từ server thì buộc lòng Client phải gửi lại Packet đó chứ không tạo nên trạng thái desynchronized.

Theo 281 hiểu là trạng thái desynchronized xảy ra khi seq của Packet đến nằm ngoài Window của bên nhận:
- client_seq < server_ack
- client_seq > server_ack + win
Lúc đó Packet sẽ không được chấp nhận và bị loại bỏ.

Ví dụ:
- Packet của Server S gửi cho Client C: seq 5000, ack 2000, win 100
- C gửi cho S: seq: 1990, ack 5000, win 100

do đó S sẽ tiếp tục gửi lại cho C: seq 5000, ack 2000, win 100
và C sẽ tiếp tục gửi cho S: seq: 1990, ack 5000, win 100

...
...

[Question] Re: Thảo luận tcp\ip	22/11/2007 13:45:06 (+0700) \| #13 \| 99303

StarGhost
Elite Member

Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline

Theo mình hiểu cái đoạn trên thì tình trạng "desynchronized" chắc chỉ là cố gắng làm sao để các thông số seq, ack thậm chí là cả CRC nó không match với nhau, để cả 2 bên cho rằng packet hoặc bị mất đâu đó, hoặc bị lỗi, để client phải gửi lại. Lợi dụng tình hình này, attacker sẽ gửi 1 "forged packet" đến server, còn packet gửi trực tiếp từ client, sẽ bị discard bởi attacker.

Tất nhiên, câu hỏi cuối cùng là, tại sao phải làm 1 cách phức tạp như thế, đơn giản chỉ modify cái packet mỗi khi nó chạy qua là xong. Còn nếu muốn chiếm session (những communication không có encryption), thì chỉ cần sniff cái session từ đầu, rồi đến 1 lúc nào đó thì ngắt network connection của client đi, và route packet về máy mình, và tất nhiên phải có sẵn program chạy để đón packet.

SG.

Mind your thought.

[Question] Re: Thảo luận tcp\ip	24/11/2007 04:08:44 (+0700) \| #14 \| 99566

vikjava
Elite Member

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

Mr.Khoai wrote:

Thật ra nếu không có dữ liệu đựoc truyền thì làm sao có....desychronized state được Đúng là tình trạng trên xảy ra khi server ack khác client seq, và client ack khác server seq. Nhưng cụ thể là khác hơn thế nào?

Ý khoai nói khó là khó khi phải chờ một gói cụ thể, ví dụ là SYN/ACK khi bạn muốn tấn công vào 3-way handshack. Giả sử bạn inject dữ liệu vào một TCP stream, hoặc hijack stream đó thì phía server sẽ có client seq, client ack, server seq và server ack như thế nào. Vậy còn client thật thì các thông tin trên như thế nào. Và, TCP sẽ hoạt động thế nào trong tình trạng trên? Tình trạng trên không phải là desynchronized state nhé.

khoai

Chào khoai và các bạn!

1. Có phải câu hỏi của khoai liên quan tới hai cách tạo ra desynchronization là desynchronization during connection establishment và in the middle of a connection
2. Vẫn không tìm được câu trả lời ...
smilie

@StarGhost : nếu kô làm các bước trên thì bạn làm sao modify packet.

[Question] Re: Thảo luận tcp\ip	25/11/2007 13:53:21 (+0700) \| #15 \| 99936

Mr.Khoai
Moderator

Joined: 27/06/2006 01:55:07
Messages: 954
Offline

Chào vikjava,

1. Cái khoai muốn bạn tìm hiểu thêm là desychrolized state thật sự xảy ra khi nào. Và khi đó, client ack, server ack, client seq và server seq có các điểm gì đặc biệt (cụ thể là giá trị của chúng so với client ISN và server ISN có gì đặc biệt) Các cách tấn công vào TCP đều chú trọng vào seq và ack.

2. Lần nữa, vẫn là giá trị của 2 cái ack và 2 cái seq. Khi client và server hoàn tất 3-way handshack, 4 giá trị trên đều hợp lệ và match nhau: client ack = server seq + 1; và server ack = client seq + 1. Nhưng nếu một attacker ở giữa chèn một gói tcp, hoặc hijack session thì khi đó, server ack sẽ khác real client req + 1. Server sends cái ack đó ra ngoài (với một số byte reply) thì bản thân real client cũng nhận được.

Như vậy TCP layer ở client thật sẽ ứng xử thế nào khi nó nhận được một ack không hợp lệ? Tình trạng này có gì dính đến cái desychronized state không?

Thảo luận cho vui. Khoai nghĩ thảo luận càng lâu và càng sâu thì sẽ càng thấm cách hoạt động của tcp. Nói cho cùng thì các dạng tấn công dựa trên tầng TCP đã không thật tiễn và không còn tác dụng khi mà đa phần các applications đều chạy trên SSL.

khoai

[Question] Re: Thảo luận tcp\ip	27/11/2007 05:25:28 (+0700) \| #16 \| 100359

vikjava
Elite Member

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

Chào khoai !

Mình sẽ tìm hiểu thêm về vụ này rùi bàn tiếp. Hihi để hiểu rõ thui chứ chẳng biết tấn công gì cả. Cảm ơn nhé

Mọi người kô tham gia cho xôm tụ ... smilie

Go to:

Users currently in here
1 Anonymous