14.6 C
London
Tuesday, September 26, 2017
Home Tags Cache Poisoning

Tag: Cache Poisoning

Vanilla Forums software suffers from vulnerabilities that could let an attacker gain access to user accounts, carry out web-cache poisoning attacks, and in some instances, execute arbitrary code.
The Drupal Security Team fixed a handful of issues in version 7 and 8 of its content management system core engine this week that could have led to cache poisoning, social engineering attacks and a denial of service condition. Drupal SA-CORE-2016-005 – Moderately Critical Update to Drupal core 7.52 and Drupal core 8.2.3. #security — Drupal Security (@drupalsecurity) November 16, 2016 According to a security advisory, the update, pushed Wednesday, fixed four vulnerabilities marked “moderately critical.” The vulnerabilities affect Drupal core 7.x versions prior to 7.52 and Drupal core 8.x versions prior to 8.2.3. One of the more pressing fixes addresses an issue in Drupal 8’s transliteration mechanism.

The module provides one-way string transliteration; it also cleans file names during upload.

According to the advisory, if an attacker used a specially crafted URL in the module, they could cause a denial of service. A similar issue existed in Drupal 7’s confirmation forms, according to the advisory. “Under certain circumstances, malicious users could construct a URL to a confirmation form that would trick users into being redirected to a 3rd party website after interacting with the form, thereby exposing the users to potential social engineering attacks.” The remaining two bugs were marked less critical by Drupal. One was tied to the fact that Drupal 8’s user password reset form didn’t specify a proper cache context, something which could have caused cache poisoning and unwanted content appearing on a user’s page.

Another stemmed from an issue with access query tags in Drupal 7 and 8.

That bug could have leaked information on taxonomy terms to unprivileged users. Users of the CMS are being encouraged to download Drupal core 7.5.2 if they’re using Drupal 7.x, or Drupal core 8.2.3, if they’re using Drupal 8.x. The fixes are the first since Drupal three critical vulnerabilities in its core engine back in September.

Those bugs could have affected how a program executes and allowed for the full export of the system’s configuration report without administrative permission, among other outcomes.
Rotating cryptographic keys is a security best practice, so it's good news that ICANN has begun the process to change the root key pair underpinning the security of the DNS. While the chances of a misstep is small, the fact remains that changing the ro...
Administrators who have configured their domains to use DNSSEC: Good job! But congratulations may be premature if the domain hasn't been correctly set up.

Attackers can abuse improperly configured DNSSEC (Domain Name System Security Extensions) domains...
For message authentication, not for tracking. Promise! A proposal raised late May at the Internet Engineering Task Force (IETF) suggests adding cookies to the DNS to help defend the critical system against denial-of-service exploits. The domain name system (DNS) is an old and fundamental piece of the Internet architecture, providing translation between human-readable addresses like theregister.co.uk and IP addresses. The DNS has also been exploited several times over the years as a traffic amplifier in DoS attacks. [amplification attacks] RFC 7873, authored by Donald Eastlake (Huawei*) and Mark Andrews (ISC*), puts forward the intriguing notion that a simple cookie deployment could help. They describe DNS Cookies as “a lightweight DNS transaction security mechanism” for clients and servers. While the idea offers only “limited protection”, the authors say they can help address denial-of-service, amplification, forgery, and cache poisoning attacks. For the privacy-conscious, the authors note that their proposal is that the DNS cookies only be returned to their originating IP address, preventing them being used as a tracking mechanism. The protection offered by the DNS cookie, the RFC says, comes from the fact that an attacker would have to guess the 64-bit pseudorandom value of the cookie. The client cookie would be calculated using the client's IP address, the server IP address, and “a secret value known only to the client”. The client's IP address, the client cookie, and a secret known to the server would be used to calculate the server cookie. Here's how the authors imagine the cookies would help in various DNS attack scenarios: DoS attacks using forged addresses – the basic DNS denial-of-service attack uses a forged client address. The cookie doesn't block such attacks – but it does identify the client by its real IP address, which makes attribution more feasible, making the attack less anonymous; DNS amplification – from the RFC: “Enforced DNS Cookies would make it hard for an off-path attacker to cause any more than rate-limited short error responses to be sent to a forged IP address, so the attack would be attenuated rather than amplified”. Server DoS – any DNS request accepted by a server uses its resources, making it relatively straightforward to hose a server by flooding it with requests. The cookies make it very easy to reject forged requests “before any recursive queries or public key cryptographic operations are performed.” Cache poisoning and answer forgery attacks – the DNS cookies let resolvers reject forged replies. The RFC also lays out an incremental rollout scheme for DNS cookies. ® Bootnote: *IETF RFCs are the work of individuals, not their employers, but affiliations get a mention as a courtesy. ® Sponsored: Rise of the machines