Spam - technique de camouflage
Pierre Pinard© (01..03.2004 - révision 1)
Une technique d'aveuglement des filtres par encodage
J'ai reçu ces deux courriers dont le sujet ne m'inspire pas, par exemple "watch p4ris h1lt0n for free" et dont l'adresse e-mail me semble forgée de toutes pièces, par exemple "Moises Rasmussen" <moisesrasmussen_zt@barbora.ms.mff.cuni.cz>. Normalement je mets ce type de courrier directement à la poubelle sans les lire mais, pour une fois, j'ai regardé, avec prudence, volet de visualisation fermé, le code source. Voici le corps intégral des 2 messages :
MIME-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: base64
SGV5DQogICAgWW91IG11c3QgY2hlY2sgb3V0IHRoaXMgUGFyaXMgSGlsdG9u
IHNpdGUgaXRzIEZSRUUgYW5kIGdvdCBoZXIgSE9UIHZpZGVvIGV2ZXJ5b25l
DQogICBpcyB0YWxraW5nIGFib3V0IGNvbWUgY2hlY2sgaGVyIG91dCBoZXJl
IA0KICANCiAgIGh0dHA6Ly93d3cuYmVzdG9mdGhlc3RhcnouY29tLyAgICBp
dHMgYWJzb2x1dGVseSBmcmVl
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: base64
SGV5LA0KDQpHZXQgeW91ciBWYWxpdW0gLCBYYW5heCwgVmlhZ3JhIGFuZCBT
dXBlciBWaWFncmEgKCB2aWFncmEgdGhhdCBsYXN0IGFsbCB3ZWVrZW5kKQ0K
RGVsaXZlcmVkIEZlZCBFeCBPdmVybmlnaHQuDQoNCiAgICAgICBnb3RvIGxp
bmsgYmVsb3cgdG8gb3JkZXIgbm93DQoNCmh0dHA6Ly91OTJqMWQyb3gzLnJ4
LWxhbmQuYml6L20wMDEyL2luZGV4LnBocD9pZD1tMDAxMg0KDQoNCg0KDQpp
cyB0aGluZyB0aGluZyB0aGlzIHUgaGFwcHkgaXMgb3V0IHN0dWZmIGlzICAN
Cg0KDQoNCg0KDQoNCg==
Ce n'est pas très clair. Comme écrit en ligne 3 de chacun des messages, c'est encodé en alphabet base64 (un encodage par groupe de 4 caractères de 6 bits formant des mots de 24 bits, chaque caractère codé sur 6 bit n'étant pas le caractère lui-même mais un index pointant dans un alphabet de 64 caractères) donc illisible sans décodeur. Cet encodage peut constituer un camouflage du texte du message (50% des spam utilisent cette technique) comme il peut concerner un objet légitimement encodé en base64 (une image en .jpg ou en .gif..., une pièce attachée...). L'encodage normal est en base 7 (mots de 7 bits) et se déclare par : Content-Transfer-Encoding: 7bit.
Je coupe toute communication avec l'extérieur au niveau du firewall pour me prémunir contre un piège ou un web-bug et avoir un log dans le firewall au cas où... et je demande la visualisation du message avec l'outil de messagerie Mozilla à qui sont interdit les iFrames, les scripts, les images externes, les ActiveX etc. ... Le message est décodé automatiquement. cela donne :
Pour le premier
| Hey You must check out this Paris Hilton site its FREE and got her HOT video everyone is talking about come check her out here http://www.bestofthestarz.com/ its absolutely free |
Pour le second
Hey,
Get your Valium , Xanax, Viagra and Super Viagra ( viagra that last all weekend)
Delivered Fed Ex Overnight.
goto link below to order now
http://u92j1d2ox3.rx-land.biz/m0012/index.php?id=m0012
is thing thing this u happy is out stuff is |
Le problème est que la plupart des filtres des utilitaires anti-spam travaillent en amont du décodage donc aucun filtre, à règles ou bayésien, ne filtrera ce spam. Des discussions sans fin ont lieu actuellement (mai 2004) sur l'opportunité de filtrer ou non sur cet encodage. Certains utilitaires, SpamPal par exemple avec le plug-in RegExFilter, décodent le contenu avant de l'analyser. S'ils s'apperçoivent qu'il s'agit bien de texte et non pas d'image ou de binaire (programme), ils augmentent leurs suspissions de spam à l'égard de tels messages. RegExFilter déclare, par exemple: "BASE64_ENC_TEXT_A Message text disguised using base-64 encoding" (un texte de message camouflé en utilisant l'encodage base64).
Le rapport de lecture ci-dessous de Spam-Pal (incorporé dans l'entête du message - la partie normalement invisible des messages) montre que le plug-in RegExFilter a lu "Don't really need Viagra!". Il y voie aussi des incitations à un acte de commerce ('Subject' starts with Buy, Buying) et à passer à l'acte d'achat dans l'urgence (Encourages you to waste no time in ordering). Tout ceci augmente les suspissions de spam à l'égard de tels messages jusqu'au moment ou trop d'indices concordent et font basculer le courrier dans la trappe à spam.
X-RegEx-Score: 764.5
X-RegEx-Warning: spam (764.5 > 499.9)
X-RegEx: [47.3] VERY_SUSP_RECIPS Very similar addresses in recipient list
X-RegEx: [50.0] SIMILAR_TO: similar domains in 'To:'
X-RegEx: [50.0] SIMILAR_TO: similar usernames in 'To:'
X-RegEx: [109.6] FROM_AND_RECEIVED_DO_NOT_MATCH FQDN in From and Received header do not match
X-RegEx: [50.0] SOME_WORDS_2 Some words used in spam
X-RegEx: [50.0] SOME_WORDS_2 Some words used in spam
X-RegEx: [100.0] VIAGRA_BODY_GK_01 Don't really need Viagra!
X-RegEx: [235.4] BASE64_ENC_TEXT_A Message text disguised using base-64 encoding
X-RegEx: [-49.8] MSGID_GOOD_EXCHANGE Message-Id indicates the message was sent from MS Exchange
X-RegEx: [3.7] TO_HAS_SPACES To: address contains spaces
X-RegEx: [81.3] SUBJ_BUY 'Subject' starts with Buy, Buying
X-RegEx: [37.0] ORDER_NOW Encourages you to waste no time in ordering
X-SpamPal: SPAM REGEX ID#024124446-36
Les encodages dans les e-mail :
Les encodages - Microsoft:
- Content-Transfer-Encoding: 7bit
The 7bit is the most fundamental message encoding. Actually, 7bit is not encoded; 7bit encoded files are files that use only 7-bit characters and have lines no longer than 1000 characters. CR (carriage return) and LF (line feed) characters can only occur as pairs to limit the line length to 1000 characters, including the CRLF pair. NULL characters are not allowed. 7bit encoded files need no encoding or decoding. This is the default.
- Content-Transfer-Encoding: 8bit
8bit encoding has the same line-length limitations as the 7bit encoding. It allows 8bit characters. No encoding or decoding is required for 8bit files. Since not all MTAs can handle 8bit data, the 8bit encoding is not a valid encoding mechanism for Internet mail.
- Content-Transfer-Encoding: base64
Base64 encoding is the scheme used to transmit binary data. Base64 processes data as 24-bit groups, mapping this data to four encoded characters. It is sometimes referred to as 3-to-4 encoding. Each 6 bits of the 24-bit group is used as an index into a mapping table (the base64 alphabet) to obtain a character for the encoded data. The encoded data has line lengths limited to 76 characters. The characters used in base64 encoding, the base64 alphabet, include none of the special characters of importance to SMTP or the hyphen used with MIME boundary strings.
- Content-Transfer-Encoding: binary
Binary encoding is simply unencoded binary data. It has no line-length limitations. Binary encoded messages are not valid Internet messages.
- Content-Transfer-Encoding: quoted-printable
Quoted-printable encoding is used where data is mostly US-ASCII text. It allows for 8-bit characters to be represented as their hexadecimal values. For instance, a new line can be forced by using the following string: "=0D=0A". Line lengths are limited to 76 characters. Using an equal sign as the last character on the line as a "soft" line break accommodates longer lines. The 76-character limit does not include the CRLF sequence or the equal sign.
Any character, except the CRLF sequence, can be represented by an equal sign followed by a two-digit hexadecimal representation. This is especially useful in getting mostly text messages to pass reliably through gateways such as EBCDIC where such characters as "{" and "}" have special meaning.
- Content-Transfer-Encoding: X-token
Private or proprietary encoding schemes can be included in messages by having specialized UAs or applications available to both the sender and the receiver, each recognizing an agreed upon x-token and providing their own encoding mechanism. The x-token can be any character string preceded by "x-" or "X-".
Rédigé en écoutant
|
 |
|
