Hva er Enumeration?

Dette er mer inntrengende enn scanning og sniffing, og krever en aktiv kobling til systemet som testes. En angriper kan enumerate alt fra web applikasjoner og mer underliggende infrastruktur som nettverk og tjenester. Enumeration er steget etter scanning og rekognosering. Har man på plass gode logger fra applikasjoner og infrastrukturtjenester, og man benytter overvåkning på nettverkstrafikk med IDS eller IPS, så vil man enkelt kunne avdekke angrep i tidlig fase. Både scanning og enumeration har en tendens til å generere uvanlig støy.

Applikasjoner er også utsatt for enumeration og det gjelder spesielt «log inn» og «glemt passord» funksjonaliteter. Hvis disse er implementert svakt kan en angriper finne ut om en bruker har en registrert konto på applikasjonen eller ikke.

Les mer: 5 sikkerhetstips til applikasjonslogger

Enumeration er ofte det første angrepet mot systemene dine. I denne artikkelen ser vi på hvordan slike angrep skjer og hvordan man kan beskytte seg mot slike angrep, både mot infrastuktur og mot applikasjoner. 

1. Infrastruktur

Enumeration mot infrastruktur handler om å hente ut informasjon som brukerkontoer, IP adresser, server navn og tjenester, og andre nettverksressurser. Angripere vil ofte enumerate (men er ikke begrenset til):

DNS

• DNS Zone Transfer er en teknikk som sender informasjon om bakomliggende maskiner med IP adresser og operativsystem versjoner.

SNMP

• SNMP (Simple Network Management Protocol) er en protokoll for å kontrollere routere, switcher, og servere eksternt.

SMTP

• Liste alle gyldige brukere på SMTP server.

LDAP / AD

• Liste alle brukernavn.

NTP

• Liste opp maskiner koblet til NTP tjenesten.
• IP adresser, systemnavn og OS versjoner.

NetBIOS

• Liste opp servere og maskiner som tilhører domenet.
• Liste opp delte filområder på maskiner på nettverket.
• Hente ut policies og passord.

Hvordan uføre sikkerhetstesting gjennom hele utviklingsløpet? Last ned vår guide her. 

Deteksjon

Det finnes en rekke verktøy man kan benytte for å enumerate protokoller og tjenester. Her er noen av de vanligste.

• DNS enumeration: Dig, Host, DNSenum, DNS Recon, Nmap, Fierce
• SNMP enumeration: SNMP-Walk, SNMP-Check, snmpenum
• SMTP: Smtp-user-enum, iSMTP, telnet
• LDAP: LdapMiner, LDAP Explorer, ldapsearch, Jxplorer
• AD: PowerShell, PowerView
• NTP: Nptrace, ntpq, ntpdc
• NetBIOS: Nbscan, superscan, new view

Mitigering

Bytt alle default passord på server tjenester og protokoller som er aktive. Hvis du ikke trenger tjenesten så deaktiver den (spesielt SNMP).

DNS

• Overvåk/saumfar dine DNS Zoner. Det er ofte test miljøer og subdomener blir liggende lenge, og de kan potensielt kjøre utdatert programvare eller eksponere uønsket informasjon.
• Hold alle DNS servere oppdatert.
• Skjul BIND informasjon.
• Benytt whitelists til å si hvilke DNS servere som har lov til å utføre zone transfers.
• Ikke ha HINFO records i DNS zone filer.

SNMP

• Hold tjenesten oppdatert til enhver tid.
• Bruk Least-Privilege prinsippet for bruk.
• Blokker TCP/UDP port 161. Hvis du trenger de åpne, så lås ned hvilke IP adresser som kan benytte SNMP.
• Blokk tilgang til null session pipes og shares, og IPsec filtering.

LDAP

• Separer epost adresser og login navn.
• Begrens bruk for bare kjente brukere med autentisering.
• Krypter trafikk med TLS.
• NTP
• Hold tjenesten som kjører oppdatert til enhver tid.
• Pass på at software du benytter ikke åpner flere porter (default NTP port er 123).

SMTP

• Slå av åpne epost relays.
• Drop ukjente mottakere.
• Aldri utlevere epost server info i eposter.  

NetBIOS

• Slå av SMB og fjern File and Printer Sharing i Windows.
• Lukk NetBIOS portene 445, 137. 138 og 139.

Les mer: 5 sikkerhetsmetrikker for applikasjonsforvaltning

2. Applikasjonsutvikling

Det er ikke bare infrastruktur på datasenteret ditt eller i skyen som må beskytte seg mot enumeration. Det gjelder også applikasjonene man utvikler og drifter. Heldigvis er de preventive metodene enkle og raske både å implementere og teste.

Deteksjon

Det er flere ting som kan gjøres feil ved «logg inn» eller «reset bruker/passord» funksjonalitet.

Feilmeldinger

• Hvis feilmeldinger inneholder mer informasjon enn nødvendig. F.eks. hvis brukernavn er korrekt, men passord er feil så får man beskjed om at bare passordet er feil. Da vet man med høy sannsynlighet at brukeren er registrert på siden.

Feilbegrensning

• Applikasjonen bør låse ned kontoen etter tre feilede påloggingsforsøk. Det anbefales at kontoen automatisk låses opp igjen innen en gitt tid, slik at man ikke trenger en sysadmin til å aktivere kontoen igjen.

Responstid

• Hvis applikasjonen svarer veldig raskt på brukere som finnes i systemet, og veldig tregt på brukere som ikke finnes i systemet kan dette gi røpe at en bruker er registrert. Selv om man har gjort tiltak med korrekte feilmeldinger og begrenset antall feil innloggingsmuligheter vil dette røpe brukeren.

Navnekonvensjoner

• Hvis applikasjonen har altfor rigide regler på hvordan et brukernavn skal være, kan en angriper kunne gjette seg frem til gyldige brukerkontoer.

Mitigering

Utviklere kan skrive enhetstester på alle disse, samt at funksjonelle testere kan ha det som test cases.

Feilmeldinger

• Utviklere lager generiske feilsider som hverken bekrefter eller avkrefter om brukerkonto er registrert. Ved mislykket innlogging, uansett om det er bruker eller passord, så returner bare informasjon om at en av de er feil (aldri spesifiser hva som er feil). Ved resetting av passord så svar bare at hvis brukeren finnes i systemet vil det sendes ut en passord-reset mail om ikke lenge.

Feilbregrensning

• Utviklere setter opp enhetstester som utfører et gitt antall mislykkede innlogginger og verifiserer deretter at konto er fryst.
• Funksjonelle testere utfører samme test i kjørende applikasjon. Benytt Selenium Webdriver e.l. for å spille inn den funksjonelle testen slik at den kan kjøres automatisk i fremtiden.

Responstid

• Utviklere lager enhetstester som utfører mislykkede innloggingsforsøk med både en bruker som eksisterer i applikasjonen og en som ikke eksisterer, deretter henter de ut response tid og sammenligner. Hvis det er grove forskjeller på disse skal testen feile. Sjekk også at HTTP status kode er samme for begge requests.
• Funksjonelle arkitekter kan utføre samme test manuelt i en kjørende applikasjon, igjen; benytt et automatiseringsverktøy som spiller inn testen slik at den kjører automatisk senere.  

Navnekonvensjoner

• Ikke ha for strenge og rigide regler/policies for navn på brukerkontoer.

Hvordan utføre sikkerhetstesting gjennom hele utviklingsløpet?

Sikkerhetsekspert, Even Lysen, gir deg en guide til hvordan man kan utføre sikkerhetstesing gjennom hele utviklingsløpet.

Last ned guiden