Posted by Baho Utot on 01/22/08 22:30

Jerry Stuckle wrote:

[putolin]

>>
>> Indeed. But the server will disregard them.
>>
>
> Actually, no. The server will respond.

No, the TCP/IP stack will drop the connection


Quoting RFC 793

Connections:

The reliability and flow control mechanisms described above require
that TCPs initialize and maintain certain status information for
each data stream. The combination of this information, including
sockets, sequence numbers, and window sizes, is called a connection.
Each connection is uniquely specified by a pair of sockets
identifying its two sides.

When two processes wish to communicate, their TCP's must first
establish a connection (initialize the status information on each
side). When their communication is complete, the connection is
terminated or closed to free the resources for other uses.

Since connections must be established between unreliable hosts and
over the unreliable internet communication system, a handshake
mechanism with clock-based sequence numbers is used to avoid
erroneous initialization of connections.

>
>>
>> There is nothing in the TCP/IP protocol which disallows it,
>>> and the packets will be quite happily sent to the server.
>>>
>>
>> wher they will be dropped.

That right, the socket (port 80) will never see the data until the
connection is established.


>>
>
> Sorry, they will be accepted and acted upon. The server does not
> require acknowledgment of the connection.
>

The socket doesn't but the TCP/IP stack does.

>>>> To hijack that session you need to jump in at point 3/. and replace
>>>> the packet with your own. You need to know all about the TCP session
>>>> as well as the senders IP address AND current sender port number, or
>>>> the packet will be discarded as not part of any TCP session the
>>>> server knows about.
>>>>
>>>
>>> No, because your point 1 is incorrect.
>>>
>>
>> Yes,beacuse you don't understand te TCP initialisation protocol.
>>
>

You need to know the ISN of the datagram to hijack a connection, you will
need to watch out for SYN+ACK RST and will have to "swamp the host" to
hijack.

> Actually, I do. I was writing TCP/IP code back in the 80's when I
> worked at IBM.

Did it work?

>
>>>> OR you need to set up your own session. To do that needs
>>>> bidirectional communication with the server.
>>>>
>>>
>>> No session needed. In fact, as far as TCP/IP goes, there is no such
>>> thing as a session.
>>>
>>
>> Oh dear. You don't know very much do you?
>>
>
> Obviously a lot more than you do.
>
>> TCP/IP is a Guaranteed connection protocol. It has a session that
>> establishes each end point, an number associated with that session, a
>> packet number inside that session, and various flags to say whether the
>> packet is a new session request, and etablished session, and ack for a
>> recieved packet and LOADS more stuff.
>>
>
> At the application layer, yes, it is. However, with hacker tools you
> can burrow down below that level and get the server to perform using
> spoofed IP addresses.
>
> You really don't know much, do you?
>

You only control one end of the connection, The TCP/IP stack on the other
will drop the connection.

>>
>> Don't confuse it with pure IP..which has none of the above, and is
>> merely the underlying packet routing mechanism.
>>
>
> I'm not.
>

Or UDP

>>>> People claim that firewalls that only allow connection from a given
>>>> IP address are not secure (enough). That IP addresses can be spoofed.
>>>> So they can, but I have never heard of it being done in practice in
>>>> the real world, other than in a particular artificial environment.
>>>> Certainly NOT by Andy Hacker masturbating in his bedroom with a copy
>>>> of Linux for Geeks on the floor.
>>>>
>>>
>>> Yes, unfortunately, it has been done in real world. But the effects
>>> are rather limited. One of the things it was used for before bot nets
>>> was DDOS attacks on a server.
>>>
>>
>> thats IP attack, not TCP/IP attack.
>>
>

or ICMP attack

> This attack is effective because it gets the server to respond to all of
> these messages. It doesn't just overload the network connection; it
> overloads the server.
>
> So if you say this is only an IP attack, and the sever will not respond,
> please explain the effectiveness of this attack.
>
>> We wer talking in te context of actuallky causing a server to execute
>> code via an HTTP connection. Its somply not possible with IP spoofing
>> UNLESS yuou can latch into an establsihed TCP/IP connection.
>>
>

Correct. Connection hijacking exploits desynchronized state in TCP. You
will need to desynchronize the host until they (hosts) will discard
datagrams from each other, then you can inject your modified datagrams. It
could be done at the handshake or in the middle of an established
connection.


> Exactly. That's why this attack can be successful. Otherwise, one
> machine could not overload a server.
>
>> HINT: Look at your firewall and you may see 'Established' as an
>> allowable thing for incoming packets. Why? because ESTABLISHED packets
>> are those on a connection YOU have opened OUTWARDS, and you want
>> responses to them to come back to you. No UN-ESTABLISHED packets are
>> allowed in, so no one can OPEN a port on your machine.
>>
>
> Which has absolutely nothing to do with this discussion. Sorry.
>

Why the firewall will toss the traffic


>>
>>>> You need very high level access to core routers to be able to *see*
>>>> the traffic session flow and enough ability to reconfigure core
>>>> internet routers to do that. AND the sort of kit that can keep UP
>>>> with the traffic flow on a router like that is basically NSA level kit.
>>>>
>>>
>>> Not at all. Any server along the route can monitor all traffic going
>>> through its servers. But because different packets can take different
>>> routes, the most effective monitoring is at either end of the
>>> connection. In the middle there's much less chance you will get all
>>> of the packets.
>>
>> They are not servers Jerry, they are routers.
>>
>
> Most are also servers. They do more than just route traffic. They can
> cache and server pages, for instance.
>

Huh. Me thinks there are very few "servers" on the backbone.
Inside your own network well..... whatever you want.

>> Before you open your mouth, do your homework next time.
>>
>
> Yes, you really should.
>

Grab a Cisco manual, a few RFCs and a copy of Wireshark.

Go ahead I'll wait :)

>>>
>>>> I.e. your government can probably do it, Possibly the top techie at
>>>> an ISP, given some fancy kit, but not anyone else.
>>>>
>>>>
>>>>
>>>
>>> It doesn't take that much of a techie to do it, unfortunately.
>>>
>>
>> I an assure you it does, if you want to operate interactively with a
>> remote machine on TCP connection
>>>
>>
>
> Yes, it would take a someone far beyond your capability. But not
> beyond a competent sysadmin.
>
> You really have a superficial understanding of TCP/IP and the protocol.
> It's a lot more than what you think.
>

I agree that it is difficult, you need a modified TCP/IP stack + "tools".
A lot of free time also helps.

If your talking snooping then that is easy, All one needs is Wireshark.

--
Dancin in the ruins tonight
Tayo'y Mga Pinoy

[Back to original message]