Tag Archives: Security

Replace your Symantec (GeoTrust, RapidSSL & Thawte) SSL/TLS certificates

Symantec and its owned subsidiaries including GeoTrust, RapidSSL & Thawte SSL certificates issued before June 1, 2016, will no longer be trusted by Google Chrome (66) post 17th Apr,2018.

Since Google Chrome has a majority of the browser market, its proposed distrust of Symantec certificates in the Chrome browser may potentially affect Chrome user traffic on your web sites.If you haven’t re-issued your Symantec,GeoTrust, RapidSSL & Thawte issued SSL then we recommend that you replace these certificates.

To verify your website SSL certificate Details and Validity:

VISIT HERE

Here’s what you should do if your website have a Symantec ,GeoTrust, RapidSSL & Thawte SSL Certificate-

Case Issued Expires Begin to Replace Complete Replacement by
1 Before June 1, 2016 Before March 15, 2018 N/A – no action required N/A – no action required
2 Before June 1, 2016 On or between March 15, 2018 and September 12, 2018 Any time March 15, 2018
3 Before June 1, 2016 On or after September 13, 2018 December 1, 2017 March 15, 2018
4 On or after June 1, 2016 On or after September 13, 2018 December 1, 2017 September 13, 2018

 

Steps to Replace Your Symantec (and Subsidiary CAS) SSL/TLS Certificates. This instruction outlines the certificate replacement steps. For more details, see the references listed at the end -

  1. Sign in to your existing Symantec, Thawte, GeoTrust, or RapidSSL account.
  2. Find the certificate(s) you need to replace.
  3. Create a CSR (certificate signing request).
  4. Select the replace/reissue certificate option.
  5. Submit your replacement/reissue request.
  6. As soon as DigiCert has revalidated/re-authenticated your domains and organizations (as required for the certificate type), they will reissue your replacement certificate.
  7. Install your SSL/TLS certificate.

Brand-Specific Certificate Replacement Instructions

How to Replace – Replace Your Symantec SSL/TLS Certificates

For More Informationhttps://knowledge.symantec.com/support/ssl-certificates-support/index?page=content&id=ALERT2386&viewlocale=en_US

Get the right SSL certificate for your needs

Get in touch with us if you have any questions about SSL certificates. We’re happy to talk with you.

CVE-2018-7600 affecting Drupal CMS

Drupal core – Highly critical – Remote Code Execution – SA-CORE-2018-002

A remote code execution vulnerability exists within multiple subsystems of Drupal 6.x, 7.x and 8.x. This potentially allows attackers to exploit multiple attack vectors on a Drupal site, which could result in the site being completely compromised. The flaw has been designated the id CVE-2018-7600.

How Can I Protect My Drupal?

To protect your Drupal from CVE-2018-7600, upgrade to the most recent version of Drupal 7 or 8 core.

  • If you are running 7.x, upgrade to Drupal 7.58. (If you are unable to update immediately, you can attempt to apply this patch to fix the vulnerability until such time as you are able to completely update.)
  • If you are running 8.5.x, upgrade to Drupal 8.5.1. (If you are unable to update immediately, you can attempt to apply this patch to fix the vulnerability until such time as you are able to completely update.)

Drupal 8.3.x and 8.4.x are no longer supported and we don’t normally provide security releases for unsupported minor releases. However, given the potential severity of this issue, we are providing 8.3.x and 8.4.x releases that includes the fix for sites which have not yet had a chance to update to 8.5.0.

Your site’s update report page will recommend the 8.5.x release even if you are on 8.3.x or 8.4.x. Please take the time to update to a supported version after installing this security update.

This issue also affects Drupal 8.2.x and earlier, which are no longer supported. If you are running any of these versions of Drupal 8, update to a more recent release and then follow the instructions above.

This will not require a database update.

This issue also affects Drupal 6. Drupal 6 is End of Life. For more information on Drupal 6 support please contact a D6LTS vendor.

I can’t update my site, what can I do to mitigate the problem?

There are several solutions, but they are all based on the idea of not serving the vulnerable Drupal pages to visitors. Temporarily replacing your Drupal site with a static HTML page is an effective mitigation. For staging or development sites you could disable the site or turn on a “Basic Auth” password to prevent access to the site.

Cloudflare Users: Cloudflare has added a Drupal WAF rule rule to block requests matching these exploit conditions their Web Application Firewall (WAF). You can find this rule in the Cloudflare ruleset in your dashboard under the Drupal category with the rule ID of D0003.

What other security measures might I put in place to improve my site’s security?

A few general suggestions include:

The Security Review which looks for weak configurations.

2 Factor Auth to improve the security of logins.

Password Strength which helps enforce stronger passwords.

Paranoia which provides a mix of tools to increase the security of sites.

Vulnerable and fixed packages on Debian

The table below lists information on source packages.

Source Package Release Version Status
drupal7 (PTS) wheezy 7.14-2+deb7u12 vulnerable
wheezy (security) 7.14-2+deb7u18 fixed
jessie 7.32-1+deb8u9 vulnerable
jessie (security) 7.32-1+deb8u11 fixed
stretch 7.52-2+deb9u2 vulnerable
stretch (security) 7.52-2+deb9u3 fixed
sid 7.58-1 fixed

 

The information below is based on the following data on fixed versions.

Package Type Release Fixed Version Urgency Origin Debian Bugs
drupal7 source (unstable) 7.58-1 894259
drupal7 source jessie 7.32-1+deb8u11 DSA-4156-1
drupal7 source stretch 7.52-2+deb9u3 DSA-4156-1
drupal7 source wheezy 7.14-2+deb7u18 DLA-1325-1

 

Find More Info

The FAQ about this issue

Links

https://www.drupal.org/sa-core-2018-002
https://security-tracker.debian.org/tracker/CVE-2018-7600
https://www.drupal.org/psa-2018-001
https://blog.cloudflare.com/drupal-waf-rule-to-mitigate-critical-exploit/

CVE-2018-1058 affecting PostgreSQL databases

A flaw was found in the way Postgresql allowed a user to modify the behavior of a query for other users. An attacker with a user account could use this flaw to execute code with the permissions of superuser in the database. Versions 9.3 through 10 are affected.

Technical Overview

The problem described in CVE-2018-1058 centers around the default “public” schema and how PostgreSQL uses the search_path setting. The ability to create objects with the same names in different schemas, combined with how PostgreSQL searches for objects within schemas, presents an opportunity for a user to modify the behavior of a query for other users. For example, a malicious user could insert a trojan-horse function that, when executed by a superuser, grants escalated privileges to the malicious user.

The easiest way to explain this is through an example.

There are two database users, alice and bob who both have access to the same database that contains the default public schema and a table in that schema with the following definition:

CREATE TABLE a (full_name varchar(255));

In the application that both alice and bob work on, there is a line of code that both users execute to return the names from table a as lowercase strings, i.e.

SELECT lower(full_name) FROM a;

The lower function is defined in the pg_catalog schema and accepts a single argument of type text. The PostgreSQL query parser knows that it can cast full_name from type varchar to text and thus use the lower function.

Knowing that the system has only the default public schema set up, user alice decides to create the following function in the public schema:

CREATE FUNCTION lower(varchar) RETURNS text AS $$

SELECT ‘ALICE WAS HERE: ‘ || $1;

$$ LANGUAGE SQL IMMUTABLE;

Though there is a function named lower in the pg_catalog schema, the above function is created successfully in the public schema as it is namespaced in a different location.

Additionally, the lower function in the public schema is a better fit for data in the full_name column, and thus if bob tries to run the following query:

SELECT lower(full_name) FROM a;

He will end up seeing a surprise message from alice indicating that she “was here” in addition to the expected return data. Thus, alice has successfully inserted a trojan function.

How Can I Protect My Databases?

There are several ways to protect your PostgreSQL installation from CVE-2018-1058.

Do not allow users to create new objects in the public schema

As a superuser, run the following command in all of your databases:

REVOKE CREATE ON SCHEMA public FROM PUBLIC;

Running REVOKE CREATE ON SCHEMA public FROM PUBLIC; prevents all non-superusers from creating objects in the public schema. This setting will protect a PostgreSQL database from the problem described in CVE-2018-1058.

Once this command is run, certain operations could fail within your database. For example, a non-superuser will not be able to create tables or functions anymore with the public schema, which may affect how a user manages application schema migrations.

Note that the REVOKE command is more powerful than running DROP SCHEMA public; as pg_dump does not preserve the public schema removal.

After running this command, you should strongly consider auditing your public schema to see if any users have created functions that have names similar to ones in the pg_catalog. From the command-line tool (e.g. psql), you can see a list of functions available in the public schema by running:

\df public.*

To see a full list of functions defined In the pg_catalog schema, please run:

\df pg_catalog.*

Set the default search_path for database users

A superuser can issue the following command to each user on your system to remove the public schema from the default search_path for a user:

ALTER ROLE username SET search_path = “$user”;

The above command preserves the default search_path that PostgreSQL provides, i.e. if there is a schema with the same name as SESSION_USER, then PostgreSQL will look for objects in the SESSION_USER schema first.

Note that any user with the CREATEROLE permission have the ability to alter the default search_path for other users. If that is the case, then please use the “Do not allow users to create new objects in the public schema” strategy described above to protect your system from CVE-2018-1058.

Set the default search_path in the PostgreSQL configuration file (postgresql.conf)

Similar to the previous step, an administrator can remove the public schema from the search_path setting in the postgresql.conf configuration file. A user that has the CREATEROLE or CREATEDB permissions or is the owner of the database can either alter the search_path for other users or create objects in the public schema for a database. If that is the case, then please use the “Do not allow users to create new objects in the public schema” strategy described above to protect your system from CVE-2018-1058.

Where to Find More Info

Please review the updated documentation to understand how to protect your PostgreSQL installation from CVE-2018-1058:

If you have further questions about CVE-2018-1058, please subscribe to and send an email to the pgsql-general@postgresql.org mailing list.

Links