[prev in list] [next in list] [prev in thread] [next in thread] 

List:       licq-main
Subject:    Re: [Licq-main] spoof
From:       Dirk Mueller <dmuell () gmx ! net>
Date:       2000-05-24 19:45:11
[Download RAW message or body]

On Mit, 24 Mai 2000, Matthew Gabeler-Lee wrote:

> Licq (or any client) could implement rudimentary spoof protection by
> checking ip addresses for the UIN sending the message, but this would
> have some drawbacks:

Well, let me clarify the things before everybody starts thinking about how
cool spoofing is. 

1) how spoofing worked: 

in the older ICQ versions, every TCP event (message, url etc) contained
the source UIN. By altering the source UIN in the event packet the mirabilis
clients thought that the message came from somebody else, _although_ the
real sender was known via the TCP handshake already. this works with TCP
versions up to 4, which means up to (including) ICQ98a. 
Licq also played the game. However it is trivial to protect from such a
spoofing attempt, it's just two lines of sourcecode. If this is requested,
no problem. 

2) why it doesn't work any more: 

newer ICQ TCP protocols, like v6 and above (ICQ99a/b, ICQ2000) don't send
the sourceUin in the event packets any more. This has also the consequence
that the spoofing won't work any more, because there is no longer such 
a field where we could spoof the client. 
As we use the new protocol now for several reasons, the spoofing "feature"
has become useless. 

NOTE that we had removed the spoof feature already in previous versions
because we KNEW that it won't work. HOWEVER we added it in because some
childish users started crying. 

3) There is a possibility to spoof clients left. The ICQ clients detect the
origin of an direct event by remembering the sourceUIN that was given during
the handshake session when the direct TCP connection is built up. We could
spoof this. but it won't work most of the cases: 

a) if the user we try to spoof has already a connection, winICQ will just
drop our connection. but also consequently if we come first, the "real" user
will stay locked out as long as we're keeping this TCP connection. but
that won't help. the windows ICQ clients (and also Licq will do soon the
same) just start a reverse TCP request which we can't spoof and is
guaranteed to be valid. 

The consequence is: there is no possibility to spoof while the user we try
to spoof is online. if the user is _offline_, then a TCP connection looks
suspicious ;-)

b) we would have to built up the TCP connection again each time the
"sourceUIN" changes, i.e. when switching for a normal to a spoofed message
etc. This is slow and might be easy to detect for the remote.

c) the answers won't reach us, but the other guy we spoofed. 

d) it won't work if the event goes through server. 

e) if the windows user selects "don't allow direct communication with
older, less secure clients" then we won't be able to spoof him. Guess
why that option has been added to winICQ :-))

There might be possibilites left to spoof in some very special cases, but it
won't work reliably. It is difficult to detect a spoof in the general case,
because the ICQ protocol has no way of authentification, that means if
somebody pretends to be UIN "1234567" nobody will be able to proof him
wrong. 

It's anyway simpler to crack the login password used by the guy we try to
spoof if you want to do the spoofing reliably. 

So my suggestion is still to the (no longer working) spoof feature
completely. 


Dirk

[prev in list] [next in list] [prev in thread] [next in thread]