All posts by admin

Attention! You Might Be Using an Infected PHP PEAR Package Manager

PEAR stands for PHP Extension and Application Repository. Using PEAR, you can download and manage various PHP libraries that allow you to easily implement various functionalities like login authentication, networking, and so on without needing to write the code from scratch.

Someone has hacked the PHP PEAR website (pear.php.net) and replaced the original PEAR installation package with a malicious package.

If you have downloaded the PEAR package manager—which is go-pear.phar file—from the official website in the past six months, kindly consider you are affected.

As soon as possible, you should download and install the latest version from the GitHub repository: https://github.com/pear/pearweb_phars, which is secure.

Currently, the PEAR website is down. And the PEAR team is doing a forensic investigation to find more details about the hack.

Affected Version: v1.10.9

Latest Version: v1.10.10

You may check the official twitter handle for the latest updates.

 

CVE-2017-1000499 CSRF vulnerability in phpMyAdmin

A critical security vulnerability CVE-2017-1000499 has been identified in phpMyAdmin which could allow remote attackers to perform dangerous database operations just by deceiving administrators into clicking a link.

Technical Overview

The vulnerability is a cross-site request forgery (CSRF) attack. A cross-site request forgery or CSRF attack occurs when an attacker deceives a user to click on a crafted URL and gets access to perform database operations.

How it Works

  1. A database admin is logged into phpMyAdmin
  2. An attacker tricks the admin into clicking a CSRF URL in the same browser
  3. Now the attack URL will make an HTTP request in the web-browser to phpMyAdmin
  4. This can result in the disclosure of sensitive information or could allow the remote attacker to perform dangerous database operations
  5. The user, unfamiliar of the situation becomes a victim.

How can I protect phpMyAdmin?

It is highly recommended that users update their installations as soon as possible to Versions:4.7.7 or downgrade to <4.7.0 

More Info

Affected Versions

Versions 4.7.x (prior to 4.7.7) are affected

Unaffected Versions

Versions older than 4.7.0 are not affected

Fixed Versions

4.7.7 and <4.70

Reference Links

https://www.phpmyadmin.net/security/PMASA-2017-9/

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000499

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

CVE-2015-0235: Newly discovered GHOST glibc library vulnerability

The GHOST vulnerability, which has been assigned CVE-2015-0235, is a serious weakness in the Linux glibc library. It allows attackers to remotely take complete control of the victim system without having any prior knowledge of system credentials.

GHOST is a ‘buffer overflow’ bug affecting the gethostbyname() and gethostbyname2() function calls in the glibc library. This vulnerability allows a remote attacker to execute arbitrary code with the permissions of the user running the application.

The gethostbyname() function calls are used for DNS resolving, which is a very common event. To exploit this vulnerability, an attacker must trigger a buffer overflow by supplying an invalid hostname argument to an application that then calls gethostbyname().

Affected linux server distros
CentOS Linux version 5.x, 6.x & 7.x
Ubuntu Linux version 10.04, 12.04 LTS
Debian Linux version 7.x

How to check if the vulnerability is present on your server?
You can use the below test to check if your system is vulnerable.

  1. Download ghosttest.c program’s source code here
  2. Compile the script: [root@L1workplace ~]# gcc GHOST.c -o GHOST
  3. Execute the script: [root@L1workplace ~]# ./GHOST

Output for the script would be one of the following:

  • Vulnerable: This output indicates that you are vulnerable to GHOST Vulnerability & you have to follow the recommendations.
  • Not Vulnerable: This output indicates that you need not worry about upgrading glibc but should still restart networked services in case they have not been restarted since glibc was last upgraded.
  • Should not happen: This output indicates that your script has not run properly.

This command shows the programs that depend on glibc on your machine:

shell> lsof | grep libc | awk ‘{print $1}’ | sort | uniq

Recommendations and Fixes
1. Update the glibc packages on your system.

On CentOS 5.x/6.x/7.x :

shell> yum –disableplugin=fastestmirror upgrade glibc
[ This may also upgrade glibc-common, glibc-headers, glibc-devel and nscd packages ]

On Ubuntu and Debian :

shell> apt-get update
shell> apt-get install libc-bin libc-dev-bin libc6 libc6-dev

2. Restart vulnerable services listening on the machine’s public IP or 0.0.0.0 :

shell> netstat -tulnp | grep -v 127.0.0.1

For managed customers, we are in process of applying the necessary patches.
Please mail us at support@e2enetworks.com for any queries that you may have.

A comparison of SSD VPS plans by different providers

E2E Networks has launched a new series of VPS plans, called the VPS-SSD-A plans on 15th January, 2015. These plans feature the best price performance ratio for any provider based in India. Below is a comparison of plans based on the resources at a price point of around Rs 2700 per month:

* Plans and prices accessed on 13.01.2015
* Dollar to INR conversion rate as $1 = Rs 62, 2% added for bank exchange fees Apart from the excellent plan pricing, the VPS plans has following features:

  • Hosted in India: Our datacenter is based in Delhi-NCR which means you get low latency from all over India.
  • Based on Xen virtualization: Our platform doesn’t allow overselling of RAM. It means that the physical underlying machine is not overcrowded and hence VPS’s don’t compete for resources.
  • Pro-rated billing: The billing for the VPS plans are done on a per day basis. Hence you will get refunded for the number of days you would not use the VPS in a month once the VPS is deprovisioned.
  • DDoS Protection: Our VPS plans come with DDoS protection included which has the ability to mitigate the attacks up to 1 Gbps (best effort delivery protection up to 10 Gbps at provider level)
  • Dual powered servers: The underlying physical machines are powered with dual redundant power supply, hence the probability of the servers going down because of power supply failure is very low.

Please check our comparison infographic below:
Comparison of SSD VM plans with 4 GB RAM |Create infographicsIf you want to know more about SSD VPS plans from E2E Networks, please contact us at +91-11-4084-4965 or sales@e2enetworks.com.

Providers RAM (GB) SSD (GB) vCPUs Dataflow (GB/month) Cost (Rs/month)*
E2E Networks 4 60 2 5000 1749
DigitalOcean 4 60 2 4000 2530
AWS t3.medium 3.75 4 1 100 3839

India to Europe and Eastern US IP traffic routed via Pacific till 12th Feb, 2015

Due to a submarine cable system fault near Mumbai in TATA’s IMEWE & TGN-EA cable systems on December 27th 2014 , a portion of India to Europe and India to Eastern US IP traffic have been re-routed via Pacific routes instead of the usual Middle East / Atlantic routes.

Hence, you may experience an increased latency on your IP services for the Europe and US East Coast due to this impact.

A cable repair ship has been scheduled to sail and the tentative repair date is 12th Feb, 2015 subjected to the weather conditions.

Please write to support@e2enetworks.com for any queries you may have.

CVE-2014-6271: Bash vulnerability that allows remote code execution

UPDATE 2: Updated bash packages that address CVE-2014-7169 are now available. With this update prefix and suffix for environment variable names which contain shell functions are added as hardening measure. Additionally two out-of-bounds array accesses in the bash parser are fixed. Please check the following links:
CentOS: https://access.redhat.com/node/1200223
Ubuntu: http://www.ubuntu.com/usn/usn-2363-2/
Debian: https://www.debian.org/security/2014/dsa-3035

UPDATE from Redhat: Red Hat has become aware that the patch for CVE-2014-6271 is incomplete. An attacker can provide specially-crafted environment variables containing arbitrary commands that will be executed on vulnerable systems under certain conditions. The new issue has been assigned CVE-2014-7169. The patches are being worked upon conjunction by upstream developers as a critical priority. We will keep you updated regarding this. You can keep track on https://security-tracker.debian.org/tracker/CVE-2014-7169

A vulnerability named CVE-2014-6271 was made public yesterday which was discovered last week. This vulnerability in bash lets an attacker to execute arbitrary code if he is allowed to pass commands to bash. As bash is a common shell for evaluating and executing commands from other programs, this vulnerability may affect many applications that evaluate user input, and call other applications via a shell.

Bash supports exporting shell variables as well as shell functions to other bash instances. This is accomplished through the process environment to a child process.

The major attack vectors that have been identified in this case are HTTP requests and CGI scripts.

Following are the mitigating steps you can take:

  • Upgrade to a new version of bash
  • Replace bash with an alternate shell
  • Limit access to vulnerable services
  • Filter inputs to vulnerable services

How to check if there is a vulnerable bash package on your server?

# env x=’() { :;}; echo vulnerable’ bash -c “echo this is a test”

A vulnerable binary will show:
vulnerable
this is a test

After upgrading the package, you should see:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’
this is a test

How to update bash packages?
Please follow the distros specific links below to upgrade your bash to versions mentioned ASAP:

  • CentOS
    # yum upgrade bash
  • Debian
    # apt-get update && apt-get install –only-upgrade bash
  • Ubuntu
    # apt-get update && apt-get install –only-upgrade bash

For managed customers we are in process of updating the bash package. Please write to support@e2enetworks.com for any queries you may have.

- From Team E2E

Google Search rankings now affected by whether your website has HTTPS or not

Last week Google announced that it has started using HTTPS as a ranking criteria for websites. It means that its search algorithm will increase the ranking of the sites using secure and encrypted connections. This automatically implies that your search ranking will suffer if you are not already using a SSL certificate for HTTPS on your website.

This is an ongoing part of Google’s “HTTPS Everywhere” initiative.

  • - Initially, the weight given to HTTPS in lower compared to other factors like high quality content as Google wants to give time for website owners’ to shift to HTTPS.
  • - Hence, it is now imperative for you as a website owners now to adopt HTTPS by purchasing SSL Certificates.

The advantages of SSL certificates are not limited to SEO only. It provides:

  • Encryption on your website so that information transferred from website to the internet is secure
  • Authentication to your website so that your customers have increased trust.

Following diagram shows typical interaction between a web browser of the user and your web server:
Screen Shot 2014-08-11 at 5.48.56 pm

You can read our introductory primer on SSL certificate at http://e2enetworks.com/help/archives/604 where we have explained the benefits, types and procedure for installation of SSL certificates.

You can check the our range of SSL certificates here. If you have any queries regarding SSL certificates, their ordering or installation, please contact us at sales@e2enetworks.com.

How Open DNS Resolvers are used for DNS Amplification attacks?

A DNS resolver is a recursive DNS server that helps us answer the question: what is the IP address of a particular server, for example, what is the IP address of the server e2enetworks.com. If the DNS resolver you query knows the answer, because someone has already asked it recently and the answer is cached, it responds. If it doesn’t, it passes the request on to the authoritative DNS for the domain.

Typically, an ISP’s DNS resolvers are setup to only answer requests from the ISP’s clients. But misconfigured name servers on the Internet that have recursion enabled and provide recursive DNS responses known as “open resolvers” accept queries from anyone on the Internet. These are highly insecure DNS servers and are a ripe tool for DNS amplification attacks.

DNS queries are usually sent via the UDP protocol. UDP is a fire-and-forget protocol, meaning that there is no handshake to establish that where a packet says it is coming from actually is where it is coming from. This means, an attacker can spoof the header of a UDP packet to say it is coming from a particular IP ( the one which the attacker wants to attack) and send that spoofed packet to an open DNS resolver. The DNS resolver will reply back with a response to the spoofed IP address with an answer to whatever question was asked.

dns_amplification_attack.png

To amplify an attack, the attacker asks a question that will result in a very large response. For example, the attacker may request all the DNS records for a particular zone. Or they may request the DNSSEC records which, often, are extremely large. In this way, the attacker can send a relatively small UDP request and use open resolvers to send back at the target a crippling amount of traffic which severely affects the server under attack as well as the network as large.

If you are running open resolvers on your E2E server, we request you to stop this service immediately. It is an open invitation for potential DNS amplification attacks and detrimental not only to your server’s uptime but the whole network.

Root Compromise Vulnerability in instances running ElasticSearch

We are recently observing a spike in root compromise of instances running ElasticSearch and getting affected by the issues explained in the link here. This is a new vulnerability which is not yet documented.

For the moment, we have following recommendations specific to ES which should be reviewed and implemented as soon as possible:
1. Upgrade ES to the latest version
2. Never run ES as root user
3. Never allow ES to be publicly accessible
4. If you’re running an older version, you want to add this to your config/elasticsearch.yaml:
script.disable_dynamic: true

For more information, please check ElasticSearch documentation links 1 and 2.

Update: For E2E managed clients with known ES installation, we are proactively reaching out with security advice. If you are an unmanaged client running ES on your server, please send an email to support@e2enetworks.com and we will help you with the recommendations.

Zero day vulnerabililty in Timthumb Webshot feature in WordPress

A critical Zero-day vulnerability in a popular image resizing library called TimThumb, which is used in thousands WordPress themes and plugins. If you or your company use the popular image resizing library called “TimThumb” to resize large images into usable thumbnails that you can display on your site, then you make sure to update the file with the upcoming latest version and remember to check the TimThumb site regularly for the patched update.

The vulnerability allows an attacker to remotely execute arbitrary PHP code on the affected website. Once the PHP code has been executed, the website can be easily compromised in the way the attacker wants. Until now, there is no patch available for the flaw.

Using the following command, hackers can create, delete and modify any files on your server:

http://vulnerablesite.com/wp-content/plugins/pluginX/timthumb.php?webshot=1&src=http://vulnerablesite.com/$(rm$IFS/tmp/a.txt)

http://vulnerablesite.com/wp-content/plugins/pluginX/timthumb.php??webshot=1&src=http://vulnerablesite.com/$(touch$IFS/tmp/a.txt)

Which plugins and themes are vulnerable?

There are hundreds of other WordPress plugins and themes, those are using TimThumb library by default. Some of theme are:
1. TimThumb 2.8.13 WordPress plugin
2. WordThumb 1.07 is also using same vulnerable WebShot code.
3. WordPress Gallery Plugin
4. IGIT Posts Slider Widget
5. All WordPress themes from Themify contains vulnerable wordthumb at “/themify/img.php” location.

Timthumb comes with the webshot option disabled by default, so only those Timthumb installations are vulnerable to the flaw who have manually enabled the webshot feature.

How to check and disable Timthumb Webshot?

1. Open timthumb file inside your theme or plugin directory, usually located at “/wp-content/themes//path/to/timthumb.php”
2. Search for “WEBSHOT_ENABLED”
3. If the you find define (‘WEBSHOT_ENABLED’, true) , then set the value to “false”, i.e. define (‘WEBSHOT_ENABLED’, false)

Avoid a messed up rendering of your web applications due to cache when you release a new update

The modern web applications both public facing and SAAS variety extensively cache HTTP elements like Javascript, CSS, images as well cacheable parts of the webpage both by using a web accelerator like Varnish/Squid or Nginx as well as by the browser to improve the user experience of an end user.

A browser based in-memory cache intercepts incoming HTTP responses from the web application servers, saving copies of the HTTP elements on local storage. If there is repeat request for the same HTTP element, it can use the response received earlier.

Extensive usage of web caching has several User Interaction advantages:
a. Reduced latency — Because the request is satisfied from the cache instead of the origin server, it takes less time for it to fetch the content to the browser.
b. Reduced page rendering time — When browser cache is re-used from the local machine of the client it reduces the page rendering time.
c. Reduced load on origin servers — since a lot of requests get served from cache, the origin servers are hit with lesser number of requests, thus letting them serve far more number of page views than without using caching.



webcacheblog
According to rule 3 of Yslow, the components of a web page can be made cacheable by adding an expire i.e. implementing “Never expire” policy by setting far future Expires header.

However, as the content and apps are served locally, browser cache or reverse proxy cache can serve web resources that are out of date. Page rendering can go out of whack if cached versions of CSS and JS are used and latest versions didn’t get fetched by the browser or the reverse proxy returned a stale version of these type of files.

The browser therefore must be forced to download the latest copies if changes are made to web content. It can be achieved by following simple guidelines as below :
1. All JavaScript or CSS files should be versioned, so that browsers interpret them as new files. This can be done by adding a query string at the end of the file name. e.g. myscript.js should be written as myscript101.js, and in the subsequent updates myscript102.js and so on and the corresponding reference changed in the refreshed HTML content of the page itself.
2. Session cookies should be renamed via auto-versioning in the release process of your web application. Default cookie names should ideally not be used, reverse proxy caching old cookies can result in incorrect working of browser sessions.
3. CDN/Reverse Proxy should not be setup to cache dynamic Ajaxified requests in general.
4. Wherever URL change is not possible for significantly dynamic content ( such as newsfeeds etc. ) via versioning due to SEO related considerations, Expires time value of less than 15 minutes should be avoided, even for high traffic websites as it wouldn’t result in significant reduction in hit-ratio of web caching on reverse proxy end.

New OpenSSL Security Vulnerability

New vulnerabilities have been discovered in the OpenSSL library soon after the malicious Heartbleed threat which appeared in April. According to a security release issued to the users, it is mentioned that this bug makes it possible for an attacker to deploy a “man-in-the-middle” attack on traffic encrypted with OpenSSL. That means an attacker could intercept the an encrypted connection between users and the server, and decrypt it to extract secure information or modify the information.

This vulnerability requires use of MITM ( Man in the middle ) attack vector hence it is more difficult to deploy than the Heartbleed bug which could be used to attack any server with OpenSSL.

Implications for you

1. Only the following versions of OpenSSL are unaffected:
OpenSSL 1.0.1h
OpenSSL 1.0.0m
OpenSSL 0.9.8za

2. Ubuntu: The bug can be removed by updating your system to the following package version -
Ubuntu 14.04 LTS:
libssl1.0.0 1.0.1f-1ubuntu2.2
Ubuntu 13.10:
libssl1.0.0 1.0.1e-3ubuntu1.4
Ubuntu 12.04 LTS:
libssl1.0.0 1.0.1-4ubuntu5.14
Ubuntu 10.04 LTS:
libssl0.9.8 0.9.8k-7ubuntu8.18

3. Debian: For the stable distribution (wheezy), these problems have been fixed in version 1.0.1e-2+deb7u10. All applications linked to openssl need to be restarted. You can use the tool “checkrestart” from the package debian-goodies to detect affected programs or reboot your system.
For the unstable distribution (sid), these problems will be fixed soon.

4. CentOS: The vulnerability can be removed by upgrading as follows –

CentOS 5.x series – Version 0.9.8e-27.el5_10.3 must be used.
CentOS 6.x series – Version 1.0.1e-16.el6_5.14 must be used

5. Use of this bug does not leave any traces, hence you can not detect if you have been exploited using this vulnerability.

All the managed clients at E2E Networks have been upgraded to the latest security patches by us. Please contact us at support@e2enetworks.com, if you are an unmanaged client and want us to help you with installation of the patches.

‘HEARTBLEED’ latest vulnerability in OpenSSL

A new vulnerability (CVE-2014-0160) has been discovered in OpenSSL named ‘Heartbleed’ (vulnerabilities in TLS heartbeat extension ). OpenSSL is the core cryptographic library used to establish SSL/TLS connections. It enables clients to (a) verify that they are indeed communicating with the server they expect and not a man-in-the-middle and (b) encrypt the network traffic so that parties other than the client and server cannot eavesdrop on the messages

The BAD & the UGLY

The latest vulnerability compromises the aforementioned security features provided by OpenSSL and allows a malicious client or server to read up to 64KB of memory from the remote machine, potentially compromising any secrets including the private keys of TLS certificates and previously transmitted or information transmitted in future if a captured packet dump is available for the same.

How to safeguard against it ?

Not all versions of OpenSSL suffer from this vulnerability. If you are running an SSL enabled website, please check your OpenSSL version by running the following command
$ OpenSSL version -a
The first line of the output will tell you the version of the OpenSSL that you are running.
The versions affected by the Heartbleed vulnerability are 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1.
For RH based distributions like CentOS 6 the above doesn’t apply please refer to this announcement :- http://lists.centos.org/pipermail/centos-announce/2014-April/020249.html

If you are running a vulnerable version along with the heatbeat extension then you should to upgrade to the fixed version released by your GNU/Linux distribution. There is a possibility that heartbeat extension might not be enabled on your server but it is a good practice to update to latest version available on your GNU/Linux distribution anyway.

To check if you have heartbeat installed, you can run the following command in your terminal (on a GNU/Linux machine)

$ openssl s_client -connect example.com:443 -tlsextdebug 2&>1| grep ‘server extension “heartbeat” (id=15)’ || echo safe

In the above command replace ‘example.com’ with your own website. If the output of the command is
‘safe’ then you have nothing to worry about, if otherwise then you need to upgrade as soon as possible.

To upgrade, follow the following procedure :

1. For Centos 6.x Systems (Centos 5.x uses previous versions of OpenSSL which haven’t been affected by this vulnerability) users can do a simple upgrade using yum by simply running :

$ yum –disablerepo=”*” –enablerepo=”updates” update openssl

2. For Ubuntu and Debian Systems it can be done by running :

$ sudo apt-get update
$ sudo apt-get upgrade openssl

If you are running debian/ubuntu and still seeing issues after upgrading openssl, don’t forget to upgrade libssl-dev.. If your repository configurations are correct the above commands should patch this vulnerability on your systems.

Update: E2E has fixed the vulnerability by upgrading openssl to a recommended version on all managed boxes and un-managed boxes (where our keys are available). Please mail us on managed-support@e2enetworks.com (For Managed customers) and support@e2enetworks.com (for  un-managed customers) for all details on the issue