Vi har gennem en periode arbejdet ude ved Ordbogen med formålet at teste deres sikkerhed.

Jeg vil her sige noget af det vi har udført, men resultaterne udelades.

I forløbet har vi udført både scanninger inde fra, men også haft test personer ude fra, som ingen viden havde om kontormiljø m.m. for at holde det BlackBox – altså vi ikke bruger den viden, som vi har.

Undervejs har vi:

• Fået skriftlige tilladelser på ALT arbejde.
• Brugt en Flipper til test af nøglebrikker
• Fysisk indtrængning af tredjeparter
• NMap scanninger
• Bruteforce
• Undersøgt Ordbogen på LinkedIn
• Fundet email struktur til phishing
• Phishing

Resultaterne deles ikke, men det har været en rigtig lærerig proces, at gå fra praksis i lukkede test miljøer til faktisk at anvende det på en virksomhed.

Jeg er igang med at gennemføre “Authentication” på TryHackMe.

Gennemførte:

Handler om Authentication Enumeration, som er et fundamentalt aspekt af sikkerhedstest. Det koncentrere sig på mekanismer, som beskytter sensitive aspekter på en hjemmeside.

Eksempel på at finde valide emails med Verbose Errors.

Her skriver den, at en mail ikke findes.

Her skriver den koden ikke er korrekt, dermed må mailen være.

Script:

Hermed finder vi ud af, at “candersson@gmail.com” findes.

Man kan også udnytte Password Reset, hvis denne er opsat dårligt.

Eksempel:

Her kan man se, at den generede kode bliver vist, når man intercepter med Burp Suite og derfor bruger Intruder, som også er en del af Burp Suite.

Derudover arbejde jeg også med at exploite HTTP Basic Authentication, samt OSINT.

Handler om Session Management, herunder Session Creation, Session Tracking, Session Expiry, Session Termination, Authentication, Authorisation, Identification, Accountability, Cookies, Tokens.

Cookies VS Tokens:

Omhandler JWT Security, Token-Based Authentication, JSON Web Tokens, JWT Lifetimes, Signature Validation Mistakes, etc.

Eksempel på Signature Validation Mistakes

Dette viser, at kun de første 2 dele af ens token bliver tjekket.

Admin værdien ændres fra 0 til 1.

Hermed ved blot at ændre i en decoder, så har fået opnået admin adgang.

Opgaver løst:

Identifying the OAuth Services:

/o/authorize pattern bruges af django-oauth-toolkit.

Stealing OAuth Token

Når man logger ind her, så redirecter den en til:

Du logger nu ind her og kommer til:

Her gives der adgang til CoffeApp, men den redirecter egentligt til vores side og ikke CoffeApp

Her får vi så vores Access Token. Denne kan skrives i URL’en som nedenstående:

/callback => er altid tilgængeligt og acceptere kode parametre, samt returnerer Access Token.

Exploiting OAuth – CSRF in OAuth

Her logges der ind igen.

Man trykker nu på “Sync Contacts” og ledes givere til:

Fordi der ikke er en state i parameteren, så kan man udføre CSRF angreb.

Exploiting OAuth – Implicit Grant Flow

I opgaven lød det, at jeg skulle besøge siden:

Her vælges “Sync …”

Der var oplyst et brugernavn og kode, som indtastes og fører en videre til:

Her vælges “Authorize”

På denne side, så kommer ens output nedenfor. Vi kan derfor ligge et script ind, som udføre ondsindet kode.

De tomme felter, f.eks. under “Hello” er dette script. Nu hvor scriptet ligger på siden, så starter vi en Python HTTP Server, som lytter på port 8081.

Så resfreshes siden oven for.

Hermed får vi en Token. Den smider vi ind på valideringssiden.

Opgaven er nu løst og vi har fået vores tag.

Andre opgaver:

Derudover var der andre opgaver, som kun var spørgsmål, som skulle svares på.

Her lærte jeg mere om hvordan MFA virker.

MFA kombinerer typisk 2 eller flere forskellige typer af credentials fra kategorierne:

• Something You Know
• Something You Have
• Something You Are
• Something You Do

Typer af 2FA:

• Time-Based One-Time Passwords
• Push Notifications
• SMS
• Hardware Tokens
• Conditional Access
  • Location-Based
  • Time-Based
  • Behavioral Analysis
  • Device-Specific

I typiske red teams bruges “Evilginx”, som er et værktøj der kan udføre sofistikerede phishing attacks, som kan “bypass” MFA. Det fungere som “Man-In-The-Middle”, som kan intercept og redirect OTPs ment for legitime brugere.

Opgaver:

Practical – OTP Leakage

Kan ske ved dårlig implementering af 2FA eller usikker kode.

For at løse opgaven, så skulle jeg logge ind på denne side:

Her kan man se, at man i en debug proces har skrevet ens token ud, som gør at den er let at finde.

Ved at skrive “5435” ind, så fik jeg adgang til koden uden at bruge en authenticator.

Practical – Insecure Coding

Det kan f.eks. være, at man har opsat 2FA, men at man kan tilgå f.eks. “dashboard” uden at have færdiggjort hele 2FA processen.

I opgaven skulle jeg logge ind her:

Jeg trykkede login, kom til siden, hvor jeg skulle skrive min 2FA kode ind.

Istedet for at skrive koden ind, så gik jeg blot til adressen nedenstående og fik adgang:

Opgaven er løst.

Forklaringen er her, at denne kode er sikker:

Men at denne er usikker:

Grunden til dette er, at i den ene er man først Authenticated, når man har løst 2FA, hvor i den anden, så er man allerede inden man har Authenticated med koden.

Practical – Beating the Auto-Logout Feature

Det kan være, hvis man fejler 2FA, så bliver man logget ud og skal starte forfra.

Ved at bruge et script, som nedenstående, så kan sådan et system omgåes:

Jeg gik derfor igang med opgaven, hvor jeg skulle tilgå:

Herefter lavede jeg en fil, som hed “exploit.py”, hvor jeg indsatte ovenstående kode i.

Nu var det blot at køre scriptet.

Til sidst kan vi se, at det lykkedes for den, hvor jeg fik en PHPSESSID. Denne smider jeg ind i mine cookies:

Derefter tilgås nedenstående side:

Opgaven er nu løst.

Dette er den sidste opgave i “Authentication”. Man får ikke særlig meget info, så derfor måtte jeg søge inspiration på nettet.

Jeg skulle starte en server, som fik IP’en 10.10.160.160 for at lave øvelsen. Jeg startede ud med at lave en scanning med Nmap på IP-adressen.

Her fandt jeg port 1337, som jeg prøvede at tilgå:

Dette førte mig til en login side.

Jeg kiggede derfor ind i “Forgot your password?”, hvor jeg testede hvad output var, hvis jeg skrev en tilfældig mail:

Til min overraskelse så skrev den, at mailen ikke er gyldig (hvilket er en klassisk fejl)

Jeg sad dog fast her, men gik så igang med at undersøge siden yderligere. Jeg inspicerede derfor koden, hvor jeg fandt:

Her er en Dev Note, som fortæller om en navnekonvention på mapper.

Ved hjælp af FFuF, så kunne jeg undersøge mapper med den navnekonvention ved brug af en Wordlist.

Jeg fandt 4, hvor logs var mest spændende. Jeg gik derfor ind på siden:

Her åbnede jeg “error.logs”

Her fandt jeg et fejlet loginforsøg med mailen: “tester@hammer.thm”. Jeg gik derfor ind for at nulstille adgangskoden.

Her fandt jeg ud af, at der var tidsbegrænsning på. Jeg valgte derfor at indtaste “1234” og med Burp Suite intercepte kaldet.

Her kunne jeg se den indtastede kode, samt hvor meget tid der var tilbage. Det hjalp mig ikke så meget.

Ved lidt søgning på google, så fandt jeg frem til at lave en fil med tallene 0-9999 (da den søger en 4 cifret kode)

Derudover skulle jeg lave en liste med en masse IP’er:

Denne skulle dog kortes ned, da 1000 er rigeligt.

Jeg gik nu ind i “Network” på browseren og fandt min PHPSESSID:

Derefter brugte jeg mine lister, samt min PHPSESSID til at udføre følgende kommando i FFuF:

Her kom den frem med koden 8066

Jeg indtastede koden på (der er en anden kode på billedet, da jeg i første omgang glemte at tage et billede)

Efter at have indtastet koden, så fik jeg adgang til at nulstille adgangskoden:

Jeg brugte nu dette til at logge ind:

Hermed var første Flag fundet.

Jeg skulle nu finde det næste, som jeg gjorde ved at indtaste kommandoen “ls” for at se alle filer.

Ud af filerne, så var 188ade1.key den mest spændende. Jeg tilgik derfor nedenstående og fik nøglen:

Jeg undersøgte derudover koden på siden, hvor jeg fandt følgende:

Der var et script med en jwtToken. Jeg gik nu ind på jwt.io og decodede koden:

Efterfølgende encodede jeg koden, dog med lidt ændringer:

Jeg gik tilbage på siden, hvor jeg skulle logge ind igen. Jeg loggede ind, satte Burp Suite til at intercepte, skrev “ls” igen, hvor Burp Suite fangede den:

Jeg erstattede her “Authorization: Bearer xxx” med min nye jwtToken, samt “command: “ls” med “cat /home…””. Bagefter gik jeg ind i “target” i Burp Suite og fandt:

Responsen var her det sidste flag jeg manglede.

Jeg er nu langt om længe færdig med Authentication efter at have gennemført ovenstående, men også alle dem, som var et krav for hver enkelt af de ovenstående.

OSWAP Top 10 er en liste over de mest kritiske “web application security”-problemer.

Injection / OS Command Injection

• Kunne være SQL eller Command Injection
• Hvor man kan kalde kommandoer med de rettigheder, som applicationen har. F.eks. whoami, ifconfig m.m.

Broken Authentication

• Opstår når der er svagheder i login- og sessionshåndteringermekanismer.
• Almindelige fejl er: Brute Force, svage koder, svage session cookies.

Sensitive Data Exposure

• Når en hjemmeside kommer med oplysninger omkring sensitiv data. Det kunne fx være navne, fødselsdag, finansielle dokumenter, adgangskode m.m.

• Her ved at kigge i Source koden fandt jeg et hint om en stig, som gav frugt. Jeg downloade webapp.db ned og fandt hurtigt frem til en md5 krypteret nøgle. Denne kunne let nedbrydes på en offentligt tilgængelig side.

XML External Entity

• Misbruger funktioner af XML Parsers/data.
• Kan tillade at en angriber kan interagere med backend eller externe systemer, som application kan tilgå.
• Et angreb kunne se således ud, hvor man får adgang til at læse en fil/RSA nøgle

Broken Access Control

• Det handler om, at man får adgang til f.eks. en admin side, som man ikke burde kunne.
• 2 scenarier

Security Misconfiguration

• Når noget som kunne være konfigureret, men ikke er.

• Opgave:

• På ovenstående side fik jeg adgang blot ved at søge på google efter “Pensive Notes exploit”, hvor jeg fandt et GitHub med standardkoder.
• Dette er selvfølgelig også udført på et testmiljø!

Cross-Site Scripting

• Handler om at kunne udføre kode på en brugers computer

• Dette virker oftest på steder, hvor man kan kommentere. Når jeg sætter denne kode ind, hvor der ikke er et ordenligt filter, så vil den udføres på alles computer, som besøger siden.

Insecure Deserialization

• Når en applikation behandler ukendt eller ikke-valideret data under deserialisering, som kan misbruges til at injicere ondsindet kode.
• Eksempel:

• Her kunne man f.eks. ændre userType fra user til admin. Hvis der ikke er validering, så får man admin adgang.

Components With Known Vulnerabilties

• Dette kunne være, at man bruger en version af et program, som har en kendt sårbarhed, blot fordi man ikke har opdateret.
• Eksempel:

Her kan man se, at ved at hente en exploit fra exploit-db, udføre den på en hjemmeside, så kunne vi få adgang til en shell.

Insufficent Logging and Monitoring

• Handler om at logge nok. Man burde logge ALT hvad en bruger udføre på en hjemmeside.
• Følgende informationer burde logges:

Jeg arbejde igen på TryHackMe med “Protocols and Servers”.

Denne omhandlede HTTP, FTP, Telnet, Post Office Protocol 3 og Internet Message Access Protocol

Her er et eksempel med FTP:

Her kunne man forestille sig, at man havde Brute Forced sig ind istedet, fundet filen ftp_flag.thm og downloadet den.

Jeg har gennemført “Web Hacking” på TryHackMe.

Denne omhandlede at bruge inbyggede funktioner i browseren. Så man kunne se “View Source”, “Inspector”, “Debugger” og “Network”.

Dette omhandler om finde content – altså ting som f.eks. videoer, filer, backups m.m. Man kan både finde content manuelt, men også med automatiserede programmer (fx GoBuster)

Denne omhandler at finde gyldige subdomæner for et domæne. 3 “subdomain enumeration methods”: Brute Force, OSINT, Virtual Host

Her finder den subdomænerne: web55. og www.

Med dette værktøj finder den delta og yellow som subdomæner.

Her kigges der på Username Enumeration, Brute Force, Logic Flaw og Cookie tampering. Eksempler på nogen af opgaverne:

Username Enumeration

Her er de 4 fundne brugernavne, som er vailide: admin, robert, simon, steve

Brute Force

Her kan vi se, at den bruteforcer, hvor den finder brugeren Steves adgangskode, som er thunder.

Denne omhandler at man ændre i URL’en, så hvis der ikke er tilstrækkelig beskyttelse kan give adgang til data, som man egentligt ikke burde kunne se.

Her ændres 1234 til 1000, som gør, at man kan se oplysningerne om en anden ordre end den, som var tiltænkt.

Omhandler File Inclusion, Path Traversal, Local File Inclusion og Remote File Inclusion. Det kunne f.eks. være at hvis man kan ændre i URL’en, f.eks. således:

Her kan man ændre “userCV.pdf” til noget andet. Man kunne også prøve at gå tilbage i path’en, således:

Hvis der ikke er beskyttelse mod dette, så kan man få adgang til oplysninger, som ikke var tiltænkt.

Her viser den hvordan, at hvis man ændre i URL’en og der ikke er beskyttelse, at man kan få den til at køre kode, som er gemt på en anden hjemmeside.

Denne omhandler SSRF (Server-Side Request Forgery), hvor man laver en ekstra eller ændre en HTTP request to angriberens ønske.

Her er der eksempler på hvordan man kan finde SSRF.

Denne omhandler Reflected, Stored, DOM Based og Blind XSS. Vi har gennemgået de 3 første på 3. semester, så jeg fokuserede på Blind XSS

I Blind XSS kan man ikke se at payload arbejder eller teste det igen for en selv.

Eksempel på scenarie:

Hvis der er opsat filtre på ens payload, så kan man prøve med følgende for at undgå dem:

Denne omhandler at misbruge en applikations “opførsel” til at køre kommandoer på operativ systemet, hvor man bruger samme privilegier, som applikationen har.

Omhandler meget om SQL vi har lært på 3. semester, derfor fokuserede jeg mest på In-Band SQLi og Blind SQLi.

I In-Band SQLi kan vi se resultatet på vores angreb, hvor i Blind SQLi får man ikke nogen feedback på vores angreb.

Jeg arbejde på TryHackMe, hvor jeg læste teori imens jeg udføre opgaver

Jeg gennemførte Security Solutions

Opret regel i Windows Firewall

Derudover så prøvede jeg også det samme på Linux.

Her arbejdede jeg bl.a. med værktøjet Snort til at opdage angreb.

Denne kom ind på hvilke scannere til at finde vulnerabilities. Et af de værktøjer, som kunne bruges er OpenVAS

Praktisk eksempel med OpenVAS

Her kan vi se, at det anbefales adgangskoder skal ændres fordi det er brugt default adgangskoder.

Jeg har idag arbejdet med Burp Suite på TryHackMe

En af de ting man kan med Burp Suite er at intercept requests fra hjemmesider, man besøger.

Her kan vi se, at jeg intercepter requesten til Bastion Hosting (test side sat op af TryHackMe), hvor at jeg kan ændre i f.eks. GET requesten, inden at siden indlæses.

Jeg løste også opgaverne på TryHackMe, hvoraf en af dem var denne:

Her interceptede jeg imens jeg trykkede på “Submit Query”, lavede om i emailen således, at den udføre Javascript kode.

Dette er bare en mulighed, at kunne give input, som formen normalt ikke vil behandle.

Jeg arbejde også med Intruder, som er en del af Burp Suite. Dette fungere lidt som Hydra.

Derudover lavede jeg også den ekstra udfordring, som var:

Dermed kunne jeg se, at det brugernavn og adgangskode, som var gyldige er: o.bennett : bella1

Jeg har udarbejdet en PTES rapport for et DDoS angreb, som vi har aftalt med PO, at vi må udføre (alt papirarbejde er på plads).

PTES rapport skabelon:

Jeg fik arbejdet lidt mere med TryHackMe, hvor jeg f.eks. kiggede på værktøjet Gobuster, som kan bruges til at finde “skjulte” hjemmesider.

Udover at kunne bruge GoBuster til at finde skjulte sider, undersøgte jeg også andre muligheder, som bl.a. var at tage en vilkårlig hjemmeside URL og indtaste /robots.txt efter domænet. Denne liste kan frembringe følsomme sider og dermed potentielle sårbarheder.