Application Security

Hva er en Zero-Day Sårbarhet

Zero-day sårbarhet er en programvaresikkerhetsfeil som leverandøren eller utvikleren nettopp har oppdaget, så de har ikke hatt tid til å lage eller utgi en oppdatering. Siden det ennå ikke finnes noen løsning, kan nettkriminelle utnytte disse feilene til å lansere angrep som er vanskelige å oppdage og stoppe.

Hva er en null-dagers sårbarhet?

En null-dagers sårbarhet er en programvaresikkerhetsfeil som leverandøren eller utvikleren nettopp har oppdaget, så de har ikke hatt tid til å lage eller utgi en oppdatering. Siden det ennå ikke finnes noen løsning, kan nettkriminelle utnytte disse feilene til å lansere angrep som er vanskelige å oppdage og stoppe.

For eksempel viste WannaCry løsepengeangrepet i mai 2017 hvor skadelige null-dagers sårbarheter kan være. Dette verdensomspennende angrepet rammet mer enn 200 000 datamaskiner i 150 land ved å bruke en Windows-feil før mange organisasjoner kunne oppdatere systemene sine.

Nøkkelfunksjoner ved en null-dag

  • Ukjent for leverandøren: Programvareskaperen er uvitende om at feilen eksisterer før et angrep skjer eller det blir avslørt av forskere.
  • Ingen tilgjengelig oppdatering: Det finnes ingen offisiell sikkerhetsoppdatering eller “fiks” på tidspunktet for oppdagelsen.
  • Høy risiko: Vanlige antivirusverktøy som bruker kjente trussel-signaturer, oppdager ofte ikke null-dagers utnyttelser fordi disse truslene er nye og ukjente.
  • Umiddelbar trussel: Angripere har en klar fordel inntil en oppdatering er utgitt og anvendt.

Hvordan et null-dagers angrep fungerer

En null-dagers trussel følger vanligvis en tidslinje kalt ‘Sårbarhetsvinduet.’

  1. Sårbarhet Introdusert: En utvikler skriver utilsiktet kode som inneholder en sikkerhetsfeil (f.eks. en buffer overflow eller SQL-injeksjon gap).
  2. Utnyttelse Opprettet: En angriper finner feilen før leverandøren eller sikkerhetsforskere legger merke til den. De lager deretter en ‘Zero Day Exploit,’ som er kode laget for å utnytte denne svakheten.
  3. Angrep Igangsatt: Angriperen bruker et ‘Zero Day Attack’ på visse mål eller til og med over internett. På dette tidspunktet kan standard sikkerhetsskanninger ofte ikke se angrepet.
  4. Oppdagelse & Avsløring: Leverandøren lærer til slutt om feilen, enten gjennom et bounty-program, en sikkerhetsforsker, eller ved å oppdage et aktivt angrep.
  5. Patch Utgitt: Leverandøren utvikler og distribuerer en sikkerhetsoppdatering. Når patchen er tilgjengelig, er feilen ikke lenger en “zero day” men blir en “kjent sårbarhet” (ofte tildelt et CVE-nummer).

Hvorfor Zero-Day Sårbarheter Betyr Noe i Cybersikkerhet

Zero-day sårbarheter er blant de mest alvorlige risikoene for organisasjoner fordi de omgår hovedforsvaret, som er patch management.

  • Omgåelse av forsvar: Fordi eldre sikkerhetsverktøy er avhengige av kjente trusseldatabaser, kan null-dagers angrep slippe gjennom brannmurer og endepunktbeskyttelse ubemerket.
  • Høy verdi: Disse utnyttelsene er svært verdifulle på det mørke nettet. Nasjonalstatshackere og avanserte vedvarende trusselgrupper (APT) beholder dem ofte for å bruke mot viktige mål som kritisk infrastruktur eller regjeringsnettverk.
  • Operasjonell innvirkning: Å fikse en null-dagers sårbarhet betyr ofte nød-nedetid, bruk av manuelle løsninger, eller til og med å ta systemer offline til en oppdatering er klar.

Null-dagers vs. kjente sårbarheter

FunksjonNull-dagers sårbarhetKjent sårbarhet (N-dag)
StatusUkjent for leverandør/offentlighetenOffentliggjort
Oppdatering tilgjengeligIngenOppdatering finnes (men kan ikke være anvendt)
DeteksjonVanskelig (krever atferdsanalyse)Enkel (signaturbasert deteksjon)
RisikonivåKritisk / AlvorligVariabel (avhenger av oppdateringsstatus)

Relaterte termer

FAQ: Null-dagers sårbarhet

Q: Hva er forskjellen mellom en zero-day sårbarhet og en zero-day utnyttelse?

Sårbarheten er en feil i selve programvarekoden. Utnyttelsen er den faktiske koden eller teknikken som angripere bruker for å utnytte en feil og bryte inn i et system.

Q: Hvordan kan jeg beskytte meg mot zero-day angrep hvis det ikke finnes noen oppdatering?

Fordi du ikke kan oppdatere noe du ikke vet om, avhenger beskyttelsen av å bruke flere lag med forsvar:

  • Bruk Web Application Firewalls (WAF) for å blokkere mistenkelige trafikkmønstre.
  • Implementer Runtime Application Self-Protection (RASP).
  • Bruk atferdsanalyse i stedet for bare signaturbasert deteksjon.
  • Oppretthold en streng hendelsesresponsplan for å reagere raskt når en zero-day blir avslørt.

Q: Kan antivirusprogramvare oppdage zero-day angrep?

Tradisjonell antivirusprogramvare som kun bruker ‘signaturer’ (som er som fingeravtrykk av kjent skadelig programvare) kan ikke finne zero-day trusler. Imidlertid kan moderne Endpoint Detection and Response (EDR) verktøy som bruker AI og overvåker uvanlig oppførsel ofte oppdage zero-day angrep, som uventet filkryptering eller uautorisert dataoverføring.

Ready to validate what matters?

Ready to validate what matters?

Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit

Teams with fewer than 50 developers: start a 14-day Trial instead of booking a demo. Start a 14-day Trial →

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorised target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)