Internet Security in the Macromedia Flash Age

This file is available on a Cryptome DVD offered by Cryptome. Donate $25 for a DVD of the Cryptome 10-year archives of 35,000 files from June 1996 to June 2006 (~3.5 GB). Click Paypal or mail check/MO made out to John Young, 251 West 89th Street, New York, NY 10024. Archives include all files of cryptome.org, cryptome2.org, jya.com, cartome.org, eyeball-series.org and iraq-kill-maim.org. Cryptome offers with the Cryptome DVD an INSCOM DVD of about 18,000 pages of counter-intelligence dossiers declassified by the US Army Information and Security Command, dating from 1945 to 1985. No additional contribution required -- $25 for both. The DVDs will be sent anywhere worldwide without extra cost.

21 November 2006. Add comment by A.

20 November 2006

From: "Christopher Pappas" <chris[at]iiiiiiiiii.net>
To: <cryptome[at]earthlink.net>
Subject: Internet Security in the Macromedia Flash Age
Date: Mon, 20 Nov 2006 12:21:51 -0600

Thought this up this weekend. Attached is a sketchy 1st draft of something I'm writing. Feel free to rearrange.

Since I haven't heard anyone talking about this MAJOR problem, and this needs to get out into the public domain ASAP, I'm sending over what I've come up with so far. Macromedia, I'm sure, is aware of the potential economic rammifications if such "talk" were to get out there, and so far neither they nor any of the major browser companies have done anything to safe-guard against such an attack.

Everybody still considers Flash to be this benevolent new species, I guess. Like man was at one point in time.

-Christopher

-----------------------------

Summary:

"If you look into how widespread Flash Player's use is (something like 98.5 percent of all browsers carry the Flash Player in some version or another) vs. the security measures in place to prevent misuse –there are almost none– an entire array of malicious activity has yet to be explored.

Flash banner ad’s are everywhere. They’ve become the de-facto standard for online advertising. Sometimes these ads are distributed through internal advertising departments; most of the time, however, these advertisments go through advertising-specic distributers such as AdServe who deploy them to millions and millions worldwide through algorithmic distribution mechanisms...

The only safeguard, so far, is code auditing before a person publishes their file to the internet –which is also difficult to check since the source files, 9 times out of 10, aren’t hosted with the ad distribution company. And think: If just one high-profile banner ad was deployed with such a program embedded, it would affect millions of people.

To begin, the point of this exercise is to 1) set up a "key" for escaping the problem while 2) setting up a function that will be used as a kill-switch for those who don’t have the key by slowly, almost imperceptibally at first, increasing the amount of processing power/mem usage required from the users machine to operate the flash-file. This is done by exploiting the internet browser and Flash Player’s inability to determine whether or not somthing is stuck in an infinite loop (or potentially, an entire army of infinite loops). If the user sticks around for too long it will thereby a) crash their browser or b) potentially crash their machine. The flash movie could be anywhere from the size of an entire website, to the size of a banner ad, to a 1px x 1px square, tucked somewhere unobservable, yet operating as it should…." More below

Description of functions used:

Shared Object:

Flash’s Shared Object exists in the form of a single variable, a string of pre-defined chararcters, that is set once the Flash file executes on the webpage. The shared object function does one of two things: a) it installs itself automatically if the programmer tells it too –without the users permission– or b) checks to see whether or not it already exists on users machine and, if Yes, perform operation 1 or, if no, execute operation 2. Correctly used, the function works as a regular cookie does, remembering user login info, preference setting ("would you like us to ‘Skip Intro’ next time you visit the page?"), and so forth. But unlike a cookie, flash’s shared object passes through no browser/spamware/pop-up blocker/anti-viral checks and can execute functions within a flash file that are far more dynamic than that of a regular static, html webpage --and checking to see if it's been incorporated into the flash file is difficult, as the only way to view the flash-file's code is to decompile the .swf or audit the source-files.

SetInterval:

As the title so describes, setInterval sets an interval. It tells flash to perform a function every so often, thereby creating a loop. The Syntax:

intervalTime = 5000;
myInterval = setInterval(pauseMe, intervalTime);

‘intervalTime’, a variable, equals 5000 milliseconds. ‘myInterval’ is the name of the setInterval function. This is used as a way to referrence the setInterval function later on if you’d like to clear/cancel it. Inside the parenthesis, ‘pauseMe’ refers to the function that the setInterval loop executes on rotaion. ‘intervalTime’, the interval time as defined above. Complete, the setInterval function looks like this:

intervalTime = 5000;
myInterval = setInterval(pauseMe, intervalTime);

function pauseMe() {
trace("Hello Everybody!"); 
}

On execution, Flash will return the message "Hello Everybody" every 5000 milliseconds, or every 5 seconds. Harmless enough, right? But keep in mind that ‘trace’, an example used for illustration, can be replaced with anything within Actionscript’s library, and incredibly complex operations can be carried out.

If you look into how widespread Flash Player's use is (something like 99.5 percent of all browsers carry the Flash Player in some version or another) vs. the security measures in place to prevent misuse –there are almost none– an entire array of malicious activity has yet to be explored.

In advertising: Flash banner ad’s are everywhere. They’ve become the de-facto standard for online advertising. Sometimes these ads would are distributed through internal advertising departments; most of the time, however, these advertisments go through advertising-specic distributers such as AdServe who deploy these ads to millions and millions worldwide through algorithmic distribution mechanisms. Random rotataion, unique visitor stats, demographics. Predefined charicteristics are fed into the machine and based upon variable data returned some ads are sent here, some there; the frequency of one is increased on NYT, decreased on CNN; one is completely pulled, one is sent everywhere and stays there for a given amount of time. All if it is calculated. *But typically, from a user standpoint, the banner being shown at one moment will not be there the next time they visit, but the time after that, and so forth. It appears to be working randomly. And at all times, without exception, the banner being displayed on the site at any given moment is not stored locally on the sites own servers, but is "served up" by the advertising distributer in question.

Because of the "randomness" of such ad distribution, determining the nature of the problem from a user standpoint is very difficult, and lots of the time impossible. One moment their system might crash when checking the sports section, but the next time they visit it will work just fine. And at no point will the user suspect that it’s the advertising being displayed. If the problem is recurrent they might suspect that it’s their browser, or the site in question, but what if the problem happened first at one site and then, later, on another? The ads, if it’s a major campaign, will be running on both. The user wonders, "Could both sites have the same exact problem?" Probably not. And so they suspect that it’s their hardware. And to further cover the trail, if one does suspect that it’s the site in question and enquires about it, the programming team responsible for site-maintainence will be sent chasing after their own code for a solution and never find it: The banners, let us remember, are hosted on the advertising distributers website. And to further cover the trail, when a site team debugs it’s own code, they tend to do it locally. Meaining, what you see on the web is NOT what the team works on code-wise when there’s a problem. So, of course, the site appears fine, everything validates, etc. The maintenance team is chasing ghosts. And usually, at least in my experience, the ad’s themselves are never displayed locally, but only when the the site is live. They then think to themselves: Is it our servers? Another week is spent digging through their server code for a problem that doesn’t exist. And by that time, the banner is out of rotation… Now, if one applies this theory to a wide array of sites who employ such banner distribution systems, with each site receiving a rotation of banners being served up at strange, seemingly random intervals, and assume that each site is or is not dealing with the same ghost-problem; and the non-technical web surfer, who is also dealing with a ghost problem of a different nature –their machine randomly crashing over sometime-safe information– who will more likely than not attribute the problem to their own hardware; and finally, keeping in mind the fact that AdServe is but one company out of hundreds, operating in thousands of different markets, and distributing the exact same banners to millions of people –what can one safely assume? A major disruption to advertising revenue, to commerce, and to the many, many different areas within the electronic world. This entire thing could be set off with only one flash-banner. Imagine what would happen 30 of these same banners were released into the the domain….

The Program

To begin, the point of this exercise is to 1) set up a "key" for escaping the problem while 2) setting up a function that will be used as a kill-switch for those who don’t have the key by slowly, almost imperceptibally at first, increasing the amount of processing power/mem usage required from the users machine to operate the flash-file. This is done by exploiting the internet browser and Flash Player’s inability to determine whether or not somthing is stuck in an infinite loop (or potentially, an entire army of infinite loops). If the user sticks around for too long it will thereby crash their machine. The flash movie could be anywhere from the size of an entire website, to the size of a banner ad, to a 1px x 1px square, tucked somewhere unobservable, yet operating as it should….

(NOTE: This is a VERY simple example, easily circumventable, to illustrate the point. It can be infinitely elaborated on to increase deadliness, security of hidden data, time-release (so that the malicious intent is not observable in testing), etc. Note also that setInterval, the killer function used in this example, is common use in banner land — malicious intent could be disguised as a simple programming error. )

First, setting up the Shared Object (Optional):

// sets flash shared object
version = SharedObject.getLocal("intro_data");

// if user doesn’t have the object key installed on their computer, execute malicious ////// // //function

if (version.data.intro == undefined || "yourDead") {
version.data.intro = "yourDead";
version.flush();
gotoAndPlay("yourDead"); // goes to the next frame which houses function. This could also refer to a target movieClip, etc.
} else {
gotoAndStop("secretData");
version.data.intro = "dontKillIt"; //sets shared object value, which could be set locally by writing/executing your own .swf
version.flush();
}

//Second, setting up the malicious loop on frame 2 ("yourDead"):

//sets up initial loop function to be called

var intervalTime:Number = 5000;

function endlessLoop(intervalTime):Number {
myInterval = setInterval(loopMe, intervalTime);

function loopMe():Void {
trace("whatever");
if(50 < intervalTime) {
// reduces the interval time, increasing the frequency of the loop //(though keeps it above zero so it doesn’t cancel out)

intervalTime = intervalTime - 10; 
}
return intervalTime;
} 
}

//sets up functions to call loop based upon value of intervalTime, thereby //compounding the initial loop’s effect by increasing the number of //operations

function callLoop():Void {
waiting = setInterval(loopCaller, 2000);
function loopCaller():void {
currentInterval = intervalTime;

if(currentInterval <= 4000) {
endlessLoop();
}
if(currentInterval <= 3000) {
endlessLoop();
}
// and so forth
}
}

// and now, to set this demon in motion, we call the loop…

callLoop();
endlessLoop();

A sends 21 November 2006:

It is amazing how stupid (for lack of a better word) people are on the Internet. I have been saying this for years; running active code on a static webpage is asking for trouble! Furthermore, Flash is not only used for ads, BUT FOR WEB PAGES! (Even the USAF Thunderbirds main page requires it!)

Knowing a bit about things such as these, I use Mozilla's "SeaMonkey" browser suite, and the "PrefBar" addition which (among other useful tools) allows a checkbox to enable/disable all instances of Flash.

http://prefbar.mozdev.org/installation.html

I only enable it after all other options are exhausted, and generally, with most pages that have no other alternative to Flash, I just bypass them completely. (I don't "YouTube" either!)

While not endorsing any product, those who may not be aware of this, may find this information useful.

SeaMonkey (and other Mozilla browsers) also allow you to block images from specific servers, which is an additional useful security feature, BTW.