Update 05-27-2009: A web developer at AOL is investigating these issues and in the meantime this post has been temporary disabled. It’ll return for educational purposes when the issues are resolved.
A recent PDF exploit has been running wild across the internet for the past few days. Not unlike many other Adobe Acrobat exploits, this one relies on the fact that Acrobat and Acrobat Reader ship with JavaScript enabled by default. Shame on you, Adobe.
What is interesting about this exploit is that you do not even need to open the PDF, simply viewing a file listing in Windows Explorer causes the exploit to execute. Thankfully, there is a simple fix – disable Adobe Acrobat’s JavaScript engine.
To disable JavaScript, Open Acrobat Reader and click on the Edit menu and select Preferences. In the Preferences window, select JavaScript from the left side and uncheck “Enable Acrobat JavaScript” Press OK and you’re done.
For those of you who are administrating a Windows domain network, it might be more difficult for you to do this on each and every PC. Instead, make your lives easier by using a Group Policy Object to push a registry change out to all your machines.
I have created a registry file that will disable JavaScript on Acrobat Reader. Since I don’t know which versions are installed on each of the machines in the domain, I played it safe by adding the reg keys for the 4 latest version of Acrobat Reader – 6.x, 7.x, 8.x and 9.x.
At work, a client recently contacted us about some random ads that were popping up on their site - interestingly enough through Adobe Acrobat. While I’m on a mac and didn’t experience the popups firsthand, I did pinpoint the problem to come from a hidden iframe located on the page (The client is a news organization and the iframes were being added to the bottom of each news article – so either they suffered an SQL injection or the attacker got into their platform somehow.) It turns out the code was doing something more malicious then just displaying ads. Read more…
Ajax requests suffer from the same Cross Site Request Forgery attack vectors as normal pages. Many developers assume that a given ajax request will only take place on their site, and therefor skip out on the security. Not true.
Google found out the hard way when security researcher Jeremiah Grossman uncovered a flaw in the way Gmail implemented its contact list ajax requests. When the browser loaded Gmail, it would make a request to Gmail and load a users contacts, among other things. Gmail returned the contacts as an array of JavaScript objects. Read more…