digimator Skrevet 28. september 2017 Del Skrevet 28. september 2017 Så hvordan hacker man en maskin med "eksponert" remote desktop med litt tid og innsats? AtW Det er ikke nødvendig å hacke maskinen direkte. Sosial hacking og phishing er sannsynligvis mye enklere å få til. Eventuelt en keylogger på maskinen til en som kjenner passordet eller ved hjelp av DNS poisoning, slik at det er en annen maskin som svarer og deretter mottar passordet. Folk med erfaring med slikt kan sikkert nevne flere metoder. Man sikrer seg ikke mot sosial hacking ved å ha en brannmur eller en lukket port, får man logindata, og det er mulig å logge inn, så hjelper det lite med andre sikkerhetstiltak? AtW Det er stor forskjell på å kunna logga inn direkte frå internet, og å måtta inn på firmaet sitt nett først. Veldig stor forskjell. Hva er forskjellen om jeg via sosial hacking har de relevante passordene? AtW Fordi dersom Deloitte har noenlunde sikkerhet i nettet, så skal det meire enn ein konto for å komma inn på nettet deira. På vårt nett har vi to faktor autentisering, der ein faktor involverar eit sertifikat som du må vera inne på nettet for å få tak i. Lenke til kommentar
0laf Skrevet 28. september 2017 Del Skrevet 28. september 2017 (endret) Når vi snakker om sikkerhetstrusselen der denne serveren spesifikt står med remote desktop åpen, er det ikke lengre så interessant med portscan siden vi snakker konkret om å angripe remote desktop. Da vet vi allerede porten, vi kan ignorere problemstillingen fysisk tilgang, og vi har bare noen få forsøk til å få passordet rett. Hvis du klarer å få ut et hash som kan(?) brute forces på egen maskin, så er det en ting, men vi er i utgangspunktet avhengige av å utnytte en kjent svakhet dersom vi ikke klarer gjette passordet før kontoen blir blokkert. Joa, men man kan anta at man ikke klarer å gjette riktig på et par forsøk uansett, å må finne andre veier inn. Klarer man å få ut SAM info (Security Account Manager), for eksempel med samdump, så kan man gjøre forsøkene på å knekke passord på egen maskin i stedet. Når det er sagt, så er jo standard RDP (Remote Desktop Protocol) port 3389, og WS2012 begrenser ikke antall forsøk som standard, så det er jo bare å tute på med millioner av passordforsøk gjennom et script. Med mindre noen har endret oppsettet på serveren, eller har en brannmur foran serveren som lukker port 3389 etter gjentatte forsøk, så blir man ikke kastet ut. Når det er sagt, så er det jo mulig å sette opp en server med RDP forholdsvis sikkert, ved å benytte TLS, autentisering gjennom NLA, en skikkelig brannmur osv. Likevel, problemet her er vel ikke at serverne er "helt åpne", i den forstand at det ikke finnes sikkerhet, men at et selskap som driver med nettopp sikkerhet har tusenvis av interne maskiner som ser ut til å ligge "helt åpne" på internet, slik at hvem som helst kan få kontakt med maskiner som egentlig ikke burde vært tilgjengelige utad. Endret 28. september 2017 av adeneo Lenke til kommentar
Civilix Skrevet 29. september 2017 Del Skrevet 29. september 2017 (...) Når det er sagt, så er jo standard RDP (Remote Desktop Protocol) port 3389, og WS2012 begrenser ikke antall forsøk som standard, så det er jo bare å tute på med millioner av passordforsøk gjennom et script. Med mindre noen har endret oppsettet på serveren, eller har en brannmur foran serveren som lukker port 3389 etter gjentatte forsøk, så blir man ikke kastet ut. Når det er sagt, så er det jo mulig å sette opp en server med RDP forholdsvis sikkert, ved å benytte TLS, autentisering gjennom NLA, en skikkelig brannmur osv. Likevel, problemet her er vel ikke at serverne er "helt åpne", i den forstand at det ikke finnes sikkerhet, men at et selskap som driver med nettopp sikkerhet har tusenvis av interne maskiner som ser ut til å ligge "helt åpne" på internet, slik at hvem som helst kan få kontakt med maskiner som egentlig ikke burde vært tilgjengelige utad. Du kjenner ikke til passord policy, hvor komplisert passord som brukes eller hvor ofte det endres. Du kjenner ikke til eventuelle brannmur/IDS systemer som kan ligge i forkant av serveren, bare forutsetter det verste scenario. I sikkerhetsarbeid er det beste verktøyet risikovurderinger, ikke en brannmur. Og ut i fra det vi har sett er det fullt mulig at det er sikret godt nok i forhold til de vurderinger som er tatt. Nå kjenner jeg ikke Deloitte men hvis de er blant de store går jeg ut i fra at de ikke bare installerer en brannmur og forsvinner, de setter opp styringsystemer for sikkerhet, kjører risikoanalyser og lager planer for når man blir angrepet. Alt dette er ting vi ikke vet noe om i dette tilfellet, så hvorfor kritiserer vi dem? 1 Lenke til kommentar
tommyb Skrevet 29. september 2017 Del Skrevet 29. september 2017 (endret) ... så hvorfor kritiserer vi dem? Kanskje fordi... ...it was the victim of a hack that went unnoticed for up to six months. (...) Customers who have had confidential information compromised are believed to include some of the world’s biggest banks, multinationals, pharmaceutical firms and US government agencies. It is believed the hacker compromised the firm’s global email server and gained access to an estimated five million emails, user names, passwords, IP addresses and health records stored in Deloitte’s Azure cloud service, provided by Microsoft. Når et selskap som skal leve av å sertifisere sikkerhet får helsejournaler på avveie er det all grunn til kritikk. Det er liten grunn til å tro de er dårlige på å gjøre risikovurderinger og evaluere prosesser. Men normalt sett er det nok deres kunder som fyller ut innholdet i risikovurderingene, implementerer tiltakene, oppdaterer og følger prosedyrene. Både fordi det er kundene som jobber på og forstår sitt fagfelt best og fordi det er viktig at prosedyrer og tiltak er forankret i de utførende delene av organisasjonene. Så om det viser seg at Deloittes teori og dokumentasjonsprosess er sterkere enn deres egen driftspraksis, er det strengt tatt ingen overraskelse, generelt sett. Endret 29. september 2017 av tommyb 1 Lenke til kommentar
Civilix Skrevet 29. september 2017 Del Skrevet 29. september 2017 (...) Var det hva denne artikkelen handlet om? Lenke til kommentar
tommyb Skrevet 29. september 2017 Del Skrevet 29. september 2017 (endret) (...) Var det hva denne artikkelen handlet om? Det er opplysninger om Deloitte som går direkte på temaet "... hvis de er blant de store går jeg ut i fra at de ikke bare installerer en brannmur og forsvinner, de setter opp styringsystemer for sikkerhet, kjører risikoanalyser og lager planer for når man blir angrepet." Guardian avslørte altså på mandag at de faktisk hadde blitt angrepet (vellykket). Kilde: [guardian] Løsningen var altså å holde kjeft om det. Og revidere seg selv. Men de hadde altså ikke sett noen grunn til å ha totrinnsautentisering i denne revisjonen, det kom først opp i denne parallelle saken. Kilde tidligere sitat: [The Week] Endret 29. september 2017 av tommyb Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå