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.

Case Study: Frys Electronics Web Portal - How Exactly *Not To Design* Password Change Component !

NOTE: The issue highlighted in this post is for educational purposes only.

Last weekend some electronic gadgets were ordered from the Fry’s electronic store at (https://shop3.frys.com//wf?a=SIGN_IN,w=CHECKOUT=1). An account was created and after interacting with the web application for 10 minutes, a number of security issues were identified in the Fry's online portal due to insecure design and coding practices. The idea behind this post is to educate application developers on how to design secure components. It is just something I came across and decided to share.

In this post, the insecure design of "Password Change Component" has been presented. The user should take the highlighted issue in consideration while accessing the online web portal.

Insecure Design - Password Change Component

It has been noticed that the "Password Change Component" used by Fry's online portal is designed insecurely. A secure design practice involves that application component should ask for the “old password” from the user before the new password is supplied and verified accordingly. This is required by the application to perform additional password verification to determine whether the HTTP request is issued by the legitimate user or not. If the “old password” is required and validated, it enhances the design and robustness of the system. Further, the component does not even enforce complex password requirements. For examples:- (1) the last used password can be reset again as new password, (2) minimum password length enforced is 6 characters. Many other variables in the password complexity requirements are not met either.

The issue does not end here. The flaw highlighted above is a basic design fallacy. Let's see how multiple vulnerabilities can be chained together.

Cross-site Request Forgery - Password Change Component

The password change component (mod_exist_password.php) is vulnerable to Cross-site Request Forgery (CSRF) attack. Let's look into a number of design checks:

1. The application does not implement origin verification checks either via unique tokens or "Origin" header. As a result, HTTP POST requests are accepted by application without any token verification and validation.
2. The password change component does not explicitly enforce the verification of “old password”.
3. The application does not even perform a basic "HTTP Referer" verification check on the server side.

It means the attacker can easily author a CSRF exploit to change the password on the fly which ultimately results in the account hijacking.

Let's validate this.

The HTTP POST request is taken from the CSRF exploit drafted as a Proof-of-Concept (PoC). It can be deciphered that the HTTP POST request does not carry any token as a part of request header or the body header. In addition, the ‘Referer” header is also removed from the HTTP request.  General, “Referer” validation on the server side is treated as a defense against CSRF attack. In this case, no "Referer" validation is performed either.

POST /wf HTTP/1.1 Host: shop3.frys.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0 Accept: text/html,application/xhtml xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Content-Type: application/x-www-form-urlencoded Content-Length: 169 Cookie: ID_KOT=987123654; J1_USER_ID=[Removed]; BTgroup=B; FSERVERID=s107 Connection: close Upgrade-Insecure-Requests: 1 r=misc,c=new_password=[Truncated]&r=misc,c=new_password_again=[Truncated]&a=MODIFY_PASSWORD,w=ACCTMAINT=&button.x=21&button.y=9 HTTP/1.1 200 OK Date: [Truncated] Server: Apache X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1 Cache-Control: max-age=0 Expires: [Truncated] Vary: Accept-Encoding Connection: close Content-Type: text/html;charset=ISO-8859-1 Via: 1.1 sjc1-10 Content-Length: 13877

By simply sending the HTTP POST request to the server via a CSRF exploit when the user is logged-in the session, the attacker can change the end-user password.

Disclosure:

Frys was contacted via Twitter and via LinkedIn as no direct security contact information was available. No response was received so the details have been released.