brainstorming detecting/preventing compromised clients
ajw
the beginning, and then was busy with other things. Still not sure how
much time I can devote...
I was a Blue Security beta-tester and went into mourning when they
closed up...
Anyway, I was thinking about the problem of a spammer modifying the
client in order to detect clients or servers. Since the project is
open-source it's not hard to modify the client...
One thought is that a client could CRC itself and use that when
connecting to other machines; an invalid CRC would be dropped (and
possibly the IP and/or MAC address forwarded to a "potential
compromised client" -uh- repository (for lack of a better word).
That thought led to "well, I'd just modify it to send the right CRC" -
so there needs to be a way to detect that. One thought is to for the
machine-being-contacted to send the CRC's seed - it would calculate
what should come back from the contact-initiating-machine.
There are some issues with this - how it calculates the expected CRC.
It *could* CRC itself; if both machines are running the same client,
then they'll come up with the same values. Or it could maintain a
(short?) list of (randomly selected) seeds and correct values for
various client versions. For example, client (version 1.0 for Windows)
would have 500 seeds for the version 1.0 for Linux client (and possibly
Linux variants; I presume they'll have some different code...). It
uses itself to calculate seeds for its own version (1.0 for Windows).
When a new version is released, the old version would add 500 seeds and
CRC values for the old-version-client, and the new version is installed
- it has the seed/CRC list generated so far.
It could get messy, but would detect modified clients from attaching to
the network.
There's another issue of how does an old-version-client connect to a
newer-version-client that doesn't know seeds for the old version? One
possibility is that a client can request a list of seed/CRC values, and
it would receive a randomly-generated list of seeds and the
corresponding CRCs. If the seeds are long enough, it would be
difficult for a spammer to create enough clients to request enough
seeds/CRCs so they would have the right one when trying to connect to
the network (and the connected-to-machine sends a seed and wants the
right CRC returned to it)
My apologies if this has already been hashed out (pun intended) - at
some point I'll review the current docs and notes... (yeah, that'll
probably end up being never... :)
- Al Weiner -