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.

Protect Your Software Development Web Interfaces - Information Lumps: A Case Study of Jenkins !

Automation of software development practices through applications has become the defacto standard in the security industry. Organizations are using support applications to reduce the workload in building and updating software.  The basic idea behind this post is to check how security is structured for software management applications such as Jenkins in a real time scenarios and what we need to look into while performing security assessments. Before discussing further, let's talk about Jenkins. According to the software website: "Jenkins is an application that monitors executions of repeated jobs, such as building a software project or jobs run by cron.". For more details, you can read here: https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins.

From software development perspective, Jenkins provides an integrated system which developers can use to manage software changes made to specific projects. It has been noticed that, although organizations use this software, but misconfigured interfaces (not running inside firewall and improper access rights) could have substantial impact. From security perspective, exposure of an integrated system that manages software development model could become a sensitive risk. To prove this fact, a case study of Jenkins application is discussed in which it is shown that how misconfigured and exposed interfaces could result in potential security glitches. 

These tests are conducted in an open environment. It has been found that several of the big companies use Jenkins and with no surprises the interfaces are exposed and running with improper authentication. In addition to this, there are numbers of Jenkins systems that are Internet facing and expose plethora of information to the attackers (remote users). A misconfigured Jenkins server results in disclosure of critical information that can be used in different set of attacks. A number of misconfiguration issues are presented below that result in information disclosure: 

Note: Based on this security issues, a few vulnerabilities have been reported to industry leaders (organizations) which have recognized the issue. I will release the details once the issue is patched.

Developers Information: Exposed Jenkins interface reveals information about the developers participating in the software projects. It is possible to extract userids of the registered accounts with associated names. This is a substantial point of gaining information about the users of a specific organization. An example of the exposed user details is shown below:

Exposed Developers Information !

Software Builds Information and Source Codes: It is possible to gain information about the software builds without any authentication (misconfigured scenarios).  Information about the changes in the software over a passage of time reveals information about the development flow of the components. Jenkins application does not ask for any explicit permission from the administrators to validate the user before accessing the ongoing software builds.  An example is shown below:

Exposed Software Build and Version numbers !

In certain scenarios, it is also possible to download the source code from the Jenkins without any authentication. Although for making changes to the code, you require credentials but the fun part is you can download code without them. Take a look at the example shown below:

Source Code Files !

Server-side Information Disclosure in Environment Variables: Access to environment variables also provides plethora of information. Example presented below shows the significant information about the configure MySQL (JDBC) database server. The attacker can easily glean username and password of the database (SONAR_JDBC_USERNAME & SONAR_JDBC_PASSWORD) including the internal IP address with port number on which JDBC service is running. 

Revealed Environment Information !

Exposure of Application Secret Data: During analysis, it has been found that a number of server side scripts have hard coded critical information such as secret-keys and credentials which can be exposed when console-output operations are performed. The underlined example shows how a secret key is extracted by accessing the console-output.  In this example, the curl command uses a secret key to connect to a specific domain for fetching JSON data through GET request. Once this information is exposed, the attacker can directly perform queries with the target domain. 

Revealed Secret Key !

Cron Jobs Execution: It is also possible to start the cron jobs which reveal plethora of information due to the usage of debugging calls. The majority of the time cron jobs produce a heck lot of output showing the success of running software. The example shown below presents the creation of database by a specific cron job in one of the vulnerable Jenkins configuration. It reveals how the table of OAUTH tokens is created and index is generated. 

Information Leakage through Cron Jobs !

Information Disclosure in Debug Errors: During a quick check in certain Jenkins configurations, it has been noticed that the Jenkins server does not handle the requests to restricted resources in a secure manner. The attacker can perform additional steps to request access to restricted resources to generated debug errors as shown below: 

Information Disclosure in DEBUG Errors !

Some of the standard requests specific to Jenkins are shown below:

• For verifying whether anonymous access is allowed or not in Jenkins, the link can be fetched as: http://www.example.com/pview/
• To retrieve the system information, the attacker can try for: http://www.example.com/systeminf
• For accessing the script interface (command line access), one can try for: http://www.example.com/script
• To retrieve the Jenkins account signup webpage: http://www.example.com/signup
• For creating account, send a direct request to:http://www.example.com/securityRealm/createAccount 

Explicit CSRF Protection: It is always a good practice to analyze the design of the application from security standards. Some security standards should be deployed in the application by default. For example: - Jenkins provides a global security option in which protection against CSRF attacks have to be explicitly checked. If this option is not checked, the Jenkins application fails to deploy the protection globally. During our analysis, it has been noticed a number of Jenkins systems are running without CSRF protection which makes them vulnerable to critical web attacks.

Explicit Security Configuration !

SSH Endpoint Disclosure: Jenkins implements a SSH random port feature in which the software randomize the port selection for running SSH service. Typically, when a client sends a GET request, Jenkins replies back with "X-SSH-Endpoint" HTTP header which leverages the information in the form of host: port. It means SSH service is listening on following host with given port number. If the system is already exposed on the Internet, the attacker can easily glean information about the port number on which SSH server is listening. A real time example of a server running Jenkins is shown below:

SSH Endpoint Disclosure !

This information discussed in this post only provides a glimpse of security risks associated with the poorly administered software managing applications. These applications can provide a potential beef for the attackers to gain substantial amount of information about the organization and server side environment which facilitates the additional attacks.

For replicating the issues, trigger Google dork as: intitle: "Dashboard [Jenkins]" for getting a list of Jenkins server available on the Internet.

Impacts: As shown above, the misconfigured software management applications can have severe impacts as discussed below:

• Information about developers can be used to conduct Phishing attacks including social engineering trickery to launch targeted attacks.
•  A common mistake for not enabling the CSRF protection exposes the Jenkins environment to number of critical web vulnerabilities such as Cross-site File uploading.
• In appropriate error handling discloses information about the different stack traces and internal components of the software.
• Unrestricted cron jobs will result in successful running of different builds of the software. As shown above, information disclosed in the console output results in leakage of sensitive data such as secret keys. The attacker can use the secret keys to attack target servers.
• Disclosure of software build information provides an attacker with a complete knowledge of the updates and modification that have taken place in the software. This information is beneficial for hunting security vulnerabilities or design analysis.

Recommendations:

•  For software development and management interfaces, restrict the access completely. It is highly recommended that the server should be configured with complete authentication. It means no functionality of the application should be allowed to be accessed without authentication or in a default state.
• Simply removing the HTTP links from interfaces is not a robust way to restrict access. The links can be fuzzed easily to gain access to hidden functionality. Deploy security features using a global configuration.
• Standard security protection mechanism should be enabled by default without asking any preferences from the users or administrators.
• Administrator should verify the new account creation in software like Jenkins before an access is granted to the registered user.

Configure Well and Be Secure!