Phishing with Hand Grenades
In the drowsy space between the Christmas and New Year's holiday, a little presentation
by Italian security researchers nearly went unnoticed, despite the fact that
it unearthed a
show-stopping
security hole in a nearly ubiquitous application.
That application is the Adobe Acrobat browser plug-in, which does its thing
whenever you click on a link to a PDF file on a Web site. The plug-in accepts
JavaScript to do things like open a linked PDF and jump down in the document
to a bookmark described in the JavaScript code, or to open the Print dialog
box once the file has loaded. The JavaScript that gets executed is contained
directly in the URL.
Sounds useful, right? The problem is the Acrobat plug-in doesn't discriminate
what JavaScript code it will run. So a malicious party can present a trusted
link to a legitimate PDF file - say, tax forms at a major bank's Web site --
and use the JavaScript in their link to do...well, just about anything. Including
displaying an HTML Web page that looks exactly like the legitimate login page
of the bank. It can even change the appearance of the address so everything
looks kosher to the user.
Now you're phishing with hand grenades.
JavaScript cross-site scripting attacks are hardly new. But this one is unique
in that any site that hosts a PDF is vulnerable, and there is simply no way
to detect whether or not an attack has occurred.
"The scary thing about this attack is regardless of me as a bank or a
financial services provider, no matter how secure I made it, if I host PDFs
I now have a vulnerability," says Billy Hoffman, lead R&D engineer
for SPI Dynamics.
Adobe has scrambled to patch the vulnerability, which affects Acrobat 4.0 and
later, but Hoffman questions how many millions of unpatched clients are still
out there. He also says that Adobe's lesson is one that corporate developers
need to take to heart. In short, development managers need to think more critically
when it comes to connected apps, and avoid crafting open-ended functionality
that can get terribly misused.
"I would say the big [mistake] was they really didn't think through the
repercussions of this feature," Hoffman says. "I've never seen a PDF
need to use JavaScript or have JavaScript render or manipulate a PDF. They were
putting in features that really didn't need to be there. They put this in, but
really no one thought of what the security implications would be."
What are your thoughts on the Adobe plug-in vulnerability? Did Adobe royally
muck it up, or is it simply making the same mistakes as the rest of us on a
bigger stage? E-mail me at mdesmond@reddevnews.com.
Posted by Michael Desmond on 01/17/2007