Norge hadde knapt tatt sine første bein inn i det nye året da cybersikkerhet igjen havnet i søkelyset etter at Amedia ble utsatt for et alvorlig ransomware-angrep.
Ifølge ekspertene vil hackere også være en utfordring i 2022.
Det kan være vanskelig å orientere seg i jungelen av hackerbegreper. Derfor har kode24 fått Chris Dale, konsulent i River Security, til å forklare noen av begrepene han mener du bør få med deg i 2022.
Stortinget trenger flere sikkerhetsfolk: - Men kompetansen mangler
#1: XXE – XML External Entities
Hvilken funksjonalitet har egentlig en XML-parser? Hvilke elementer støttes i en XML-fil eller i DTD’en (Document Type Definition) som beskriver et XML- dokument? Finnes det funksjoner som kan benyttes av en angriper dersom hen kan tilføre egen data som blir parset?
Det viser seg at for eksempel XML parsere har støtte for en haug med forskjellige funksjoner som gjør at avansert bruk av XML blir mulig.
Ett eksempel er at i en DTD - om det er skrevet direkte i et XML-dokument eller hentet fra en ekstern fil - kan man skrive elementer eller "entitys", som kan brukes ellers i XML-dokumentet.
Entitiys-ene har en fager funksjonalitet, og kan for eksempel brukes til å lese innhold fra filer eller eksterne servere.
Fuzzing: - Kanskje alle utviklere burde teste egne applikasjoner for alle bytes?
Ett tenkt tilfelle er at angriperen kan spesifisere en DTD som for eksempel <!DOCTYPE foo [ <!ENTITY ent SYSTEM "file:///etc/passwd" > ]>. Dersom angriperen kan referere til entityen via nøkkelordet &ent;, blir entityen "resolved" og &ent; erstattet med verdien fra /etc/passwd - gitt det er en Linux server.
Får man ikke data tilbake som angriperen kan lese, kan man i stedet bruke entityer til å gjøre oppslag til eksterne tjenester, for eksempel <!DOCTYPE foo [ <!ENTITY ent SYSTEM "http://angriper.no/" > ]>. Gitt en slik entity vil en angriper kunne overvåke domenet sitt, og se om det mottar innkommende forespørsler fra serveren som forsøker å "resolve" entityen.
Hvem hadde tenkt at XML-parsere har innebygd funksjonalitet for å lese filer og gjøre oppslag via nettverket? XML kan også brukes til andre angrep, men her forholder vi oss til den korte versjonen. Et angrep som i noen tilfeller er gjennomførbart via XML er for eksempel SSRF.
Sånn finner du ut om du er ramma av Log4j-hullet, og sånn fikser du det
#2: SSRF – Server Side Request Forgery
Det høres kanskje komplisert ut, men prøv å bryt begrepet opp og forstå hva SSRF egentlig forsøker å fortelle. Selv deler jeg SSRF i tre hoveddeler:
- Server-Side – Dette foregår på serveren, til motsetning til på klient-siden.
- Request – Vi snakker om en henvendelse eller oppslag, for eksempel http eller annet
- Forgery – Forfalskning!
SSRF betyr altså et angrep hvor vi kan bruke en server til å utføre forfalskede oppslag mot en gitt plass. Angrepet muliggjør ofte at en angriper kan bruke en server til å nå ressurser på innsiden, for eksempel lese ut informasjon fra filer på et filsystem. Gjøre oppslag mot andre systemer på internettverket eller koble på IMDS, skymiljøene sitt Instance Metadata Service API-et som ofte inneholder sensitiv informasjon.
Ikke et komplisert angrep, men som kan ha fatale følger.
«Dersom utvikleren ikke er forsiktig risikerer man at angriperen vil kunne legge inn data i applikasjonen.»
#3: SQL Injection
Veldig mange sårbarheter oppstår på grunn av et program ikke klarer tydelig nok å skille mellom data og kommandoer.
SQL benyttes av utviklere for å gjøre oppslag mot relasjonsdatabaser som typisk har innhold som brukerdata. Utfordringen med SQL Injection er nettopp at utviklere ofte lar brukeren av applikasjonen styre deler av SQL spørringen som går til databasen.
Dersom utvikleren ikke er forsiktig risikerer man at angriperen vil kunne legge inn data i applikasjonen. Når den er videresendt til databasen blir den misforstått som å være kommandoer til databasen.
Ett eksempel er en spørring som lar en bruker av databasen hente fram brukerne i databasen ved å søke på e-poster. En slik spørring kan se slik ut:
SELECT brukernavn, epost FROM tabell_brukere WHERE epost = '<INPUT FRA BRUKER>'
Relativt typisk funksjonalitet, men hva en angriper søker på:
chrisdale' OR '1'= '1
...eller hva med:
sammeHva' OR 'Ingen bryr seg om denne teksten' OR 'Ingen bryr seg om denne teksten
Legg merke til at siste fnutt (') ikke er lagt på med vilje. Den resulterende SQL-spørringen blir komplett og forårsaker en selvdefinerende SANN spørring. Dette vil la SQL-spørringen returnere alle brukernavn og eposter, til tross for at man ikke har gjort et eksakt søk på noe spesifikt.
Dette er ofte starten på mye mer ekstreme og interessante SQL angrep som kan kompromittere både brukernavn og passord, samt i noen tilfeller lar angriper få full kontroll på serveren det kjører på.
- Naivt å tro at det ikke finnes norske datakriminelle
#4: XSS - Cross-Site-Scripting
Jeg synte XSS er et ufortjent navn på denne sårbarheten. Der andre sårbarheter typisk fokuserer på å angripe serveren, handler XSS om å benytte serveren for å angripe brukerne.
Sårbarheten manifesteres når verdier tilført applikasjonen, blir reflektert tilbake til brukere uten noe slags form for sanitering/vasking/rensing eller encoding av spesial tegn, for eksempel omforming av < til <.
Se for deg en applikasjon som spør hva navnet ditt er, man tilfører et navn og nettsiden sier «Hello Chris Dale». URL ser kanskje noe slikt ut som dette: https://exampe.com/?name=Chris%20Dale. Hva om en angriper tilfører mer enn bare et navn, for eksempel HTML attributter eller JavaScript kode?
Vil denne koden vises, slik navnet vises på nettsiden, eller vil bli tolket av nettleser som faktiske elementer som skal tegnes/renderes på siden? Hva om man putter inn sitt navn som <script> alert(document.domain)</script>, og man ser en pop-up som sier tilbake navnet på domenet?
Man sitter nå igjen med en URL som inneholder noe slikt som: https://example.com/?name=<script>alert(document.domain)</script> , og gjett hva som skjer om du sender denne lenken til noen andre? Dersom de trykker på den, så får de også en pop-up.
Dette kalles reflected XSS og prolemet blir signifikant mye større når angripere velger å kjøre mer avansert JavaScript som for eksempel stjeler cookies eller melder maskinen inn i rammeverk som lar dem styre nettleseren mens JavaScriptet kjører.
Hver tiende nordmann takler ikke totrinns-bekreftelse
Enda verre kan det bli når man har et såkalt stored XSS angrep hvor angrepet ikke lenger er bygget inn i lenken til systemet, men er lagret på serveren og vises til alle brukere hver gang de besøker den sårbare siden.
Man kan teste XSS ved å tilføre HTML eller JavaScript og se om disse blir kjørt på nettsiden, eller blir vist som vanlig data. En populær måte å teste for XSS er å ha JavaScript console åpnet mens man legger inn XSS deteksjonsangrep som dette: '';!--"<XSS>=&{()}
Dennes "strengen" forsøker å fremprovosere feil på nettsiden i HTML "tags", attributter eller i JavaScript kode. Dersom man klarer å forårsake feil, så starter gjerne jakten på et "proof-of-concept" som beviser JavaScript eksekvering. Til tross for at det er anbefalt input validering i hytt og pine, så er det ikke typisk den beste løsning for å stoppe XSS. I stedet så bør man gjøre output "encoding" for å oversette farlige tegn til sin trygge motpart.