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.

(Pentest Apache #3) - The Nature of # (%23) Character | Mod Security Rules in Apache

In my earlier posts, I have talked about  some interesting issues in deployed modules in Apache and insecure configuration. Refer here:

1. (Pentest Apache #1) Exposed Apache Axis - SOAP Objects
2. (Pentest Apache #2) - The Beauty of "%3F" and Apache's Inability | Wordpress | Mod Security

In this post, I want to discuss an interesting issue that occurs due to misconfigured rules in modsecurity. It is not a severe issue but it helps the penetration tester to gain some additional information about the server-side environment. For example:- directory listing.

In modsecurity, NE is stated as No Escape. One can explicitly configure the rules with this flag to implement no escaping. For example: "#" will be converted to "%23" if NE flag is not set.  If NE flag is set , the "#" character is treated as such and processed accordingly.  For more about modsecurity flags, refer here: http://httpd.apache.org/docs/2.2/rewrite/flags.html.  An example taken from there:


"RewriteRule ^/anchor/(.+) /bigpage.html#$1 [NE,R]. This example will redirect /anchor/xyz to /bigpage.html#xyz."

If escaping is not set properly in addition to some misconfiguration issue, it could result in unexpected behavior. I have noticed this flaw plethora of times during a number of security assessments. Let's have a look at one of the real time example:-


URL pattern 1: http://www.example.com/temp/#htaccess.cl
URL pattern 2: http://www.example.com/temp/%23htaccess.cl

In case (1), if NE flag is set, the URL has to be processed with "#" character. In case (2), if NE flag is not set, the URL has to be processed with "%23", hexadecimal notation of the character "#". But due to misconfiguration, the behavior changes.

The tested server is : Apache/2.2.14. Actually, both URLs are responded with 200 OK responses. In case (1), the output results in directory listing. In case (2), the output results in content of the file htaccess.cl.

Case 1: Content-Type is text/html;charset=UTF-8

With # Character 

Case 2: Content-Type is text/plain

With %23 Character

It could be a one reason that file name starts with "#" character. But, the primary reason is the inability of Apache to understand misconfigured URL rewriting rules. Usually, if the URL rewriting rule fails, the web server should respond in 404 error message. In case of misconfiguration, the fall back step is the directory listing, atleast that what I have seen in practical scenarios (it could be different).

Inference: Play around with URL rewriting rules to detect bypasses which could result in gleaning additional information.

A Sweet Script to Dump Keys from Wlan Profiles - Post Exploitation (or Regular Use)

Update: Just found that PaulDotCom has written over this blog post in episode 327: http://pauldotcom.com/wiki/index.php/Episode327.

"This is a great example of so many things. First, its a really neat little script (though I imagine the powershell junkies will be excited to convert it). It highlights the importance of post-exploitation. But that is really just a term for us gear heads. What this means for the organization is terrible. It means you can exploit systems that really don't seem to matter, maybe Jane's computer was compromised and didn't have any sensitive data on it and her account does not. However, Jane connects to the same "secure" wireless network as more important people, say Bob from finance. Now, a small little hole, like a missing Adobe patch, just caughed up the keys to your kingdom. It means that vulnerabilities and risk have this weird relationship and its one of the toughest things to understand, until you have a pen test."

After exploitation, retrieving data from the compromised machine is always an interesting scenario. Considering the time factor, even a small automation is productive. Running a same command several times is  not bad but its better to take a next step.

The below presented script helps to dump security keys for all the wlan profiles present on the compromised system (if you have an administrator access). I use this sweet script to do the work so use it when ever you want.

Wlan Profiles - Security Keys Dumping Script

It outputs as:

Fetch the batch script from here: http://www.secniche.org/tools/dump_wlan_config.txt

Enjoy !

DEFCON 20 Talk : Botnets Die Hard : Owned and Operated Video