Protection against Viruses (Was: Virus authors produce ...)

Hadmut Danisch <[email protected]> Sun, 22 Feb 2004 10:30:52 +0100
Newsgroups gmane.ietf.asrg.smtpverify
Message-ID <[email protected]>
Jeff, 

you made a very good list of arguments about constitutional rights, 
give me some time to think about, I'll reply a little bit later.


For now, I'll focus on the hijacking problem and give you a solution 
for your scenario.


>    I want to send an E-mail message with sender verification.  So I 
> verify myself.  Then somebody breaks into my computer and sends a bunch 
> of spam, using my sender verification.  The spam appears to come from me!
> 
>    Once somebody has broken into my computer, I am sunk.


I am developing mechanisms against e-mail fraud since around 1992, 
and I found this to be one of the main problems.

When doing research on communication security, the "science" tends
to use cryptography as the universal medicine. In fact, many people
claim that cryptographical methods would be the method of choice to 
cope with e-mail forgery. I also spent a lot of time thinking about
this, but I came to the conclusion that cryptography is not the best
choice. The scenario you describe was one of the design criterions for
RMX and one of the reasons why I left cryptography completely out of
this. 

Do RMX-alike mechanisms protect you against this scenario you
describe? Not really, but still better than cryptography. 

There are several methods to verify messages with cryptography.
E.g. you could verify the author with digital signatures 
(PGP, S/MIME,...), or you could verify the sending relay
with the usual authentication mechanisms. But all this means that you
have to store a secret key on the computer. And not all computers on
the world can and will be equipped with tamper proof security
devices. So once someone is breaking in into your machine, the first
thing he will do is to steal your secret. And this allows him to work 
offline. To forge your identity, he doesn't need to be in your
computer. A simple worm/virus is enough to collect secret keys. 
The computer magazine c't (the printed version had a longer article
about the worm&spam case) found that the hackers behind that attack 
hat access to >>10,000 computers, and were selling access to these
computers to spammers ('rent-a-relay...'). They would make even 
better business if they could sell secret keys for cryptographic 
mail forgery. If only 500 of all keys used worldwide would be
compromised, this would already open the door for spammers.

If we have around 1 Billion of computers online or mail users, 
how many of these keys will be compromised by viruses and worms?
It's so easy to have a worm send an e-mail with the secret key
to a central database. After all, that's what many worms already
do, and the virus described in c't was also looking for license
keys and sending them to the virus author.



The scenario you describe is - surprisingly - with RMX-like mechanisms
still much better than the scenario with cryptography. There is
nothing that can be stolen or copied. When you manage to throw the
attacker out your machine, he's out and cut off.

Yes, if the attacker breaks into your machine, then he can pretend to
be you, because - from a security point of view - he now has the same
technical capabilities as you have, and therefore there is no
technical way to distinguish between you and the hacker. It is somehow
disappointing, but there is no technical method to directly avoid this
(except for writing better operating systems...) But this is
still much more complicated and more overhead than stealing your 
secret key. 



But there is still a technical solution to this problem:


I said that if the attacker has gained your technical
capabilities then he became undistinguishable from you in a technical 
way. So what you need to do is to take yourself (i.e. your computer)
the capability to distribute spam. You don't need this capability, do
you? 

So one way would be to now allow your own machine to deliver mail to
other domains. Don't authorize it in the RMX/LMAP/... records. Don't
allow it to open port 25 through the firewall. Deliver your e-mail
through a central relay, which can be protected against intrusion much
more easily and effectively. This relay could limit the mails you send
to e.g. 100 mails a day. Or it can block sending more than 3 mails
with the same content. It can block sending more than 20 mails to
unknown recipients. It can completely block all mails from your
computer if there are more than 3 mail rejects for mails that came
from your computer.

So the central MTAs will have to become more intelligent.

But that's the idea behind RMX and my new HTTP proposal:

- It allows the domain administration to implement and 
  enforce an individual policy and their own verification. 
  You will never get all people on the world to accept the same
  security mechanisms. So leave it up to them how to do it
  (as long as it works).

- That's one reason why I came to the conclusion that static 
  authorization records are too limited. *We need dynamic records*
  to allow such policies as described above. E.g. to allow your
  machine to directly deliver not more than 20 mails to the world.

  This can't be implemented with DNS. This was one of the reasons
  why I changed my mind and moved to HTTP for fetching authorization 
  records. CGI is a pretty good way to provide dynamic records and to 
  make the decision on the server side instead on the MTA. This allows 
  e.g. counting the mails. And larger authorization records (which are
  problematic under DNS, but easy with HTTP) could contain contact
  addresses whom to contact in case of spam.

  Furthermore, dynamic queries or moving the decision to your server
  allows you to detect spam. Your authorization server could
  immediately alert you if your machine was directly delivering 
  mass mails. You can recognize that your machine has hijacked.

  With the current proposals like current-state-RMX, DMP, SPF,
  Microsoft's CallerID, you're lost in the scenario you describe.

  Dynamic authorization or moving the evalution from the MTA to the 
  authorization server allows to instantly detect such an intrusion. 
  It does not really prevent it, but it allows to react immediately
  and to alert you or to cut your computer off from mail delivery.



So no, you're not sunk. :-)

There's a solution to this problem. It does not really prevent, but
it can immediately detect abuse of your machine, and it can limit 
the number of sent messages to a very small amount.

But this shows that we are not yet at the point to make a final 
decision for an Internet-Standard. Security engineering is much more 
than making marketing, giving interviews to journalists, and
delivering handouts, as certain people do and pretend to do
"security".



regards
Hadmut