|
|
Posted by The Natural Philosopher on 01/23/08 10:19
Jerry Stuckle wrote:
> Willem Bogaerts wrote:
>>>>> Not the way TCP/IP works. You can send up to 7 packets before an
>>>>> ACK is
>>>>> required by the sender. This is all done by the transport layer, and
>>>>> the web server has no idea what's going on.
>>>> Stupid question maybe, but can such a signal be sent anyway or does it
>>>> require some part of the question it answers to? If it can be sent
>>>> anyway and be recognized as valid, you would still be able to send data
>>>> and have the returns sent to the wrong destination.
>>>>
>>>> As you have guessed, I did not study the TCP/IP protocol.
>>>>
>>> If you send a SYN packet - a a request to open, it will be answered.
>>>
>>> If you send an ESTABLISHED packet, if its not part of a recognized
>>> established session it will be junked. Unless its some new TCP/IP
>>> software that is more full of bugs than Jerries head..
>>
>> What I mean is, could you send a stream of packages (even if a lot of
>> them are junked), such that some of them will always respond to the
>> server? I don't know how many possibilities or how much time this would
>> take, but I am just trying to see if the anonymous injection attack
>> mentioned earlier could work.
>>
>> Instead of:
>>> Client --- Host
>>> SYN -->
>>> <-- SYN+ACK
>>> ACK -->
>> Would it be possible to do:
>> Client --- Host
>> SYN -->
>> (pause)
>> ACK -->
>> Inother words, a "brute force ACKing"?
>>
>> Just curious,
>
> Willem,
>
> One thing I should also add. You'll find a few people here who think
> they can read a couple of RFC's or Wikipedia and be experts in TCP/IP.
>
Some people spent years implementing TCP/IP systems on international
networks, and even giving tedious training course in basic and advanced
security. Some people spent weeks attending Interop and studying RFCS
and packet sniffers to work out why early TCP implementations didn't
work with each other
Some people had a company that actually employed security specialists,
with Phds in cryptography, and listened to what they said.
Some people had to debug early TCP/IP code.
Not claim they wrote a couple of lines of code from a crib manual for IBM.
Some people have remembered why they sold it all,and retired early, so
they could code for fun and not have to deal with arrogant arseholes
who are more interested in showing off to nerdy geeks than in getting
their work done.
Who DO you work for Jerry?
> I agree the RFC's indicate how something *should* operate. But hackers
> operate outside the bounds of normal protocols, and take advantage of
> hole in the protocol.
>
> These guys have no *real* idea what they're talking about, and no
> knowledge of how to exploit the holes in the protocols. But they
> continue to refer you to Wikipedia and RFC's to prove their case.
>
> The problem is - they prove nothing. But they're too stoopid to
> understand that.
>
> There *are* numerous holes in the TCP/IP architecture. You found one of
> them - it is quite easy to spoof a connection as you indicated. But
> there are other, much more efficient ways to do so, also.
>
> I'm not going to get into them here because 1) it's off-topic for a php
> newsgroup, and 2) I'm not going to give these idiots clues on how they
> can hack other peoples' systems.
>
Navigation:
[Reply to this message]
|