Home / Blogs

VeriSign's New Security Seal Too Trusting?

On November 4, 2003, VeriSign announced a new "trust enhancing" seal which they built using Macromedia's Flash technology. This new seal makes a connection to their server and displays, in a dynamic text field, the name of the company that bought the certificate. The seal then invites you to click the seal to verify it. This is intended to make people feel more secure about the authenticity of the site they're visiting. But that is a false sense of trust. The purpose of this article is to examine how poorly designed and implemented VeriSign's approach really is.

Please understand, I am a huge fan of Flash. I use it every day in my professional and personal work on the Internet. I believe, when used intelligently, Flash is an incredibly powerful tool for both entertainment and electronic commerce. But I am bothered when people try to use Flash in ways that end up making Flash look faulty. Bad Flash implementations make it harder for developers like me to sell customers and clients on good Flash implementations.

While there are problems inherent to VeriSign's approach that call into question their understanding of "The Value of Trust," there are ways they could have made this particular implementation less trivially spoofable. The flaws I demonstrate on this page are flaws in the concept and the execution rather than anything inherently flawed in Flash. Overall this kind of graphical "trustmark" is extremely easy to forge just by recreating the artwork. But in this case, you don't even have to do that. The seal can still be called directly off the VeriSign servers, yet it is easily modified, without recreating artwork, and without doing anything untoward with VeriSign's servers!

Please take a moment and view the code used in the page source, in which you'll see that the code for inserting these two Flash files is completely generic. There is no javascript in the HTML either. The seal is being called directly from VeriSign. You'll also see that I am not passing it any variables through the object and embed tags, yet I am still getting my custom value into it, and that value is not one originating at Verisign's server.

The Code:

<OBJECT classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com/pub/shockwave/cabs/
flash/swflash.cab#version=5,0,0,0" WIDTH="100" HEIGHT="72"
id="f1" ALIGN="">
    <PARAM NAME=movie VALUE="https://seal.verisign.com/flash/
    seal_100x72.swf">
    <PARAM NAME=play VALUE=false>
    <PARAM NAME=quality VALUE=high> 
    <PARAM NAME=bgcolor VALUE=#FFFFFF>
    <EMBED src=https://seal.verisign.com/flash/seal_100x72.swf
quality=high bgcolor=#FFFFFF WIDTH="100" HEIGHT="72"
NAME="sendV" ALIGN=""
TYPE="application/x-shockwave-flash" play=false
PLUGINSPAGE="http://www.macromedia.com/go/getflashplayer">
</EMBED>
</OBJECT>

<OBJECT classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com/pub/shockwave/cabs/
flash/swflash.cab#version=5,0,0,0" WIDTH="200" HEIGHT="100"
id="f2">
    <PARAM NAME=movie VALUE="http://
    www.infinitumdesign.com/sendV.swf">
    <PARAM NAME=quality VALUE=high>
    <PARAM NAME=bgcolor VALUE=#FFFFFF>
<EMBED src="http://www.infinitumdesign.com/
sendV.swf" quality=high bgcolor=#FFFFFF WIDTH=
"200" HEIGHT="100" NAME="f2" ALIGN="" TYPE="application/x-
shockwave-flash" PLUGINSPAGE="http://www.macromedia.com/go/
getflashplayer">
</EMBED>
</OBJECT>

The Seal:
(Warning! This seal is invalid! It has been placed here to demonstrate flaws with VeriSign's new seal. Enter in the name of your choice and watch VeriSign's Flash file change.)

                        

How the Real Seal Works:

In a normal usage, to deploy the VeriSign seal, you would include javascript on your page that passes your domain name to the Flash file sitting on VeriSign's servers. That script then writes the information into the Flash file, as well as several functions in javascript. (Unwisely, these functions have fairly generic names — such as "splash" — so it is just a matter of time before some sites see variable name collision with content already on the customer's site.)

The embedded Flash file is passed the domain name so that it can go out and look up the presentable name for display in the Flash file. The Flash file then makes a call out to the seal server and gets the name. If the domain name is invalid, it sends back the same variable name but this time with an empty value. This theoretically prevents you from passing the organization name into the Flash file in the same way the domain name was passed into the file. In the end though, this doesn't actually prevent anyone from being able to pass in custom data into the Flash file.

What I did:

To demonstrate the weaknesses in this particular approach, I needed to give the best appearance of this being a legitimate seal. The best way to do that is to embed the seal using standard Flash object/embed tags. I then also placed a completely innocent looking Flash file on the page. Currently this file has an input field that allows you to change the seal name as you wish, but if I were doing this to really look legitimate, it could be something completely innocuous, such as the logo for the page.

This second file has javascript calls in the form of getURL commands. These javascript calls initialize the splash function (the function that runs when the seal is clicked), and make calls to the seal Flash file setting a variable. It then sends the Flash file's timeline to the appropriate frame to play and display the seal name. By encasing the javascript in the Flash file, there is no easy way for the average person to even know that I am tinkering with the seal file. It would be entirely possible to have run the javascript from the page itself, but that would have made the HTML for the page look much messier, and therefore less convincing.

The verification page is just a file sitting on my server that replicates the verification page on VeriSign. I removed the address bar and other browser features so that the location from which the page was called would not be a giveaway. I've kept most of the page content just as it appears — making a few changes just for humor's sake. But that page could have easily been a convincing forgery, up to and including translation pages, a fake "Report Abuse" page, and other elements.

As a last note, this will not work on all environments, but should work on most. If there is a problem though, the VeriSign logo should still come up, but the name and the Click to Verify message will not be displayed. With a bit more work though, support for multiple environments would not be too difficult.

General Seal Issues:

  • The .swf file is Flash 5, but the HTML sent by VeriSign is Flash 6 - While this file would run on your system if you have Flash 5, the HTML will still try to get you to upgrade to the latest version of Flash. Many enterprise sites are just moving over to Flash 6. Inevitably, some corporations will place this seal on their site and every visitor to the site will be forced to upgrade to Flash 6. This will be problematic for many sites.

  • The variables are placed in predictable places - My code was able to work because I was always able to store a variable in the right place. If the data had been accessed in a movie whose name was dynamically assigned with attachMovie, and perhaps based on a random number or timestamp, I would have had a far harder time overwriting the variable. (Perhaps VeriSign can find somebody who is handy with numbers to tell them how such a thing might work.)

  • The "Click to Verify" calls a javascript function - Having the verification link call javascript out in the HTML means that anyone stealing the .swf can easily divert the verification page.

  • There are no scripts to check the data over time for changes, such as the ones made here - A script that runs periodically could watch the variable for changes in its value. If the value changes, the script could remove the _root timeline, clearing out the whole movie (a "self destruct" feature).

By Justin Everett-Church, Professional Flash Developer & Author

Related topics: DNS, Domain Names, Registry Services, Security

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:

Comments

To post comments, please login or create an account.

Related Blogs

Related News

Topics

Industry Updates – Sponsored Posts

Top Level Domain Holdings Raises $14M for New gTLDs

.ORG COO Discusses Priorities With DailyVista, Pursuit of .NGO Domain

StarHub to Acquire '.starhub' New Top-Level Domain

ARI Registry Services Signs 21 Contracts in the First Week of New TLD Applications

MarkMonitor to Exhibit at Internet Tech Policy Exhibition and Reception to be Held on Capitol Hill

Sedari Signs With Dot Moscow Bidders

.ORG, The Public Interest Registry Welcomes Nancy Gofus As Chief Operating Officer

Minds+Machines Works with .bayern

The New Domain For Japan, JP.NET, Launches With Exclusive Invitation to Trademark Owners

Verisign to Award New Infrastructure Research Grants

Being a .PRO When Choosing a Registry Services Partner

UK Cabinet Office Looks to BlueCat Networks' Expertise and Best Practices for Securing PSN

Afilias Acquires Registry Services Corporation, .PRO

Thoughts on Applying for a Generic Top-Level Domain

Sedari Launches "Guess the Numbers Game" for New TLD Program

dot Brand Makes Its Debut: Afilias Advises Companies to Act Now for Successful TLD Applications

BlueCat Networks Helps Organizations Transition to IPv6 with HP

BlueCat Networks to Host Webinar on DNS, DHCP and IPAM Featuring Independent Research Firm

Facets of gTLD Registry Technical Operations - Registry Services

Technology and Finance Industries to Dominate New gTLD Applications

Hot Topics

Verisign

Security

Sponsored by
Verisign
Minds + Machines

Top-Level Domains

Sponsored by
Minds + Machines
Neustar UltraDNS

DNS

Sponsored by
Neustar UltraDNS
Afilias

DNSSEC

Sponsored by
Afilias
dotMobi

Mobile

Sponsored by
dotMobi