Of Dialog Origin Vulnerability and Sender ID
Two interesting technology articles caught my eyes in today’s issue of ZDNet Asia magazine.
The first article is about a security advisory by Secunia. In the advisory, Secunia warns about the possibility of malicious sites redirecting users to a trusted site, and then waiting a couple of seconds (presumably to wait for the said trusted site to load) before showing a Javascript prompt for users to fill.
As most likely at this time the user has the trusted site on his browser window, it might appear to him that the said trusted site is the one generating the pop up. Note that I said appear, because in fact that prompt is from the malicious site I mentioned above.
A scenario to this is having this blog you’re reading (note that I said this is a scenario; I don’t want to trick people into doing it anyway). Imagine that you’re following a seemingly innocent link like this. What you see is the log-in page of DBS Internet Banking. Out of a sudden, there’s a pop up asking you to type out your Internet Banking PIN. (I said imagine! Stop staring blankly at the screen waiting for the pop-up!) You might think that this pop-up window actually originates from DBS. In fact, after clicking OK, the PIN you have just entered is sent back to me!
I feel that this is a smart move by the phishers (phishing is a term for spoofing a legitimate site, usually to get an innocent user’s log-in ID and password). Imagine what someone with no sense of his own security on the world wide web would do when prompted with such a prompt.
So now that you’ve found out about it, you have no excuse when facing this situation, ok? 
By the way, Secunia has this nice illustration on its advisory page, which I shall reproduce here.
I’m even more interested in the second article. After reading the article, I can sort of feel the arrogance of Microsoft.
In the world of email, there’s this thing called Sender ID, a technology originally developed by Microsoft which basically says “oh, the sender of this email is really this so-and-so guy and not anyone else”. The concept is supposedly good, because it filters most spoofed spam messages (those spam emails that claims that it was sent by, for example, DBS when the actual sender is some unknown company trying to sell their products by riding on DBS’s name).
Here’s the catch: Most email service providers, especially the smaller ones, don’t support Sender ID, in the sense that they don’t automatically attach the Sender ID in messages sent from these providers.
Moreover, Sender ID has some other flaws. For example, mail forwarding services will render Sender ID unusable because the Sender ID will then be from this mail forwarding service instead of the original sender as the email says.
In fact, the technology was not popular such that the Internet Engineering Task Force (IETF), a body setting standards for the Internet, last year decided to scrap a special group made to develop Sender ID.
Guess what Microsoft did with its Hotmail service.
It goes on with implementing Sender ID verification for incoming emails.
So starting this November, Hotmail will ask every single email “Is your Sender ID valid? If it’s not valid or if it doesn’t exist, go to the Junk Mail folder”.
It’s basically threatening every single email provider in the world to comply with their standards, or risk getting emails they send to Hotmail put into the Junk Mail folder.
Remember what I said 7 paragraphs ago?
That’s right, most email service providers, especially the smaller ones, don’t support Sender ID.
So if Microsoft insists on implementing this, and you happen to use one of these smaller email service providers, and you try to send an email to your friend, who happens to have a Hotmail account, your email will be dumped into the Junk Mail folder!
If even the IETF scraps the idea, I don’t think Microsoft has the right to force the entire email community into this implementation of Sender ID.
Instead, as I said, that’s what I call arrogance.
bcc