Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


CloudFront, Cloudflare and others impacted by new CPDoS web cache poisoning attack
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

CloudFront, Cloudflare and others impacted by new CPDoS web cache poisoning attack

Researchers from TH Koln have disclosed a new type of attack that can poison CDNs into caching and then serving error pages instead of legitimate websites. The new attack has been named CPDoS (Cache-Poisoned Denial-of-Service) and has been deemed practical in the real world.

Three variants of the CPDoS attack exist, depending on how attackers decide to structure the malformed header: with using oversized header fields, meta characters that trigger errors, or instructions that override normal server responses.

  • HTTP Header Oversize (HHO)
  • HTTP Meta Character (HMC)
  • HTTP Method Override (HMO)

During the research into the practicality of CPDoS attacks, the TH Koln team said they managed to carry out widespread cache poisoning attacks against a test website hosted on the network of several CDN providers.

Mitigations against CPDoS attacks exist. The simplest solution is that website owners configure their CDN service to not cache HTTP error pages by default. Many CDN service providers include such settings in their dashboards, so this won't be a difficult step to take.

Ref.: https://cpdos.org/

Thanked by 2hyperblast uptime

Comments

  • uptimeuptime Member
    edited October 2019

    Some discussion on Hacker News since yesterday -> https://news.ycombinator.com/item?id=21323396

    after the authors disclosed this issue to AWS it was fixed and CloudFront no longer caches 400 Bad Request by default

    Haven't really digested the finer points yet but would be interested to hear from @BunnySpeed for their take on all this ...

    EDIT2:

    I sent them a note as a courtesy, just guessing it may be old news but will be nice to get some perspective in any event

    Thanked by 2ITLabs hyperblast
  • BunnySpeedBunnySpeed Member, Host Rep
    edited October 2019

    @uptime said:
    Some discussion on Hacker News since yesterday -> https://news.ycombinator.com/item?id=21323396

    after the authors disclosed this issue to AWS it was fixed and CloudFront no longer caches 400 Bad Request by default

    Haven't really digested the finer points yet but would be interested to hear from @BunnySpeed for their take on all this ...

    EDIT2:

    I sent them a note as a courtesy, just guessing it may be old news but will be nice to get some perspective in any event

    From our perspective, we've always been aware that cache might get poisoned by error pages, so by default, those are only cached for a few seconds max. Just enough not to overload the origin server if something weird is going on, but short enough that a legitimate would get cached/returned almost immediately after which would get cached with a proper TTL. Perhaps disabling caching of error pages might be a good idea, but then you open the origin to other issues.

    EDIT: Forgot to add, if you want to be extra safe you can always make your origin return Cache-Control: no-cache with any error pages.

    Thanked by 3uptime ITLabs sanvit
  • jsgjsg Member, Resident Benchmarker

    I think that both the university of Cologne (not exactly an ivy league place ...) and CloudF§%&# behaved sub-par (which for CF actually is their normal). The university blew a threat of mediocre to low severity out of proportions and CF reacted with a typical corporate PR blurb.

Sign In or Register to comment.