Gå til innhold

Deloitte hadde tusenvis av datamaskiner eksponert på internett


Anbefalte innlegg

Videoannonse
Annonse

Hvis det ligger en PC eller server rett på nett, med remote desktop-funksjonalitet og kun beskyttet av et passord, og informasjon om at maskinen ikke er patcha tilgjengelig selv før man knotter inn passordet, ja, da synes jeg det kvalifiserer til at helt åpent. Selv om at det naturligvis går an å toppe dette med å bevisst slå av påloggingssida i Windows.

Lenke til kommentar

Hvis det ligger en PC eller server rett på nett, med remote desktop-funksjonalitet og kun beskyttet av et passord, og informasjon om at maskinen ikke er patcha tilgjengelig selv før man knotter inn passordet, ja, da synes jeg det kvalifiserer til at helt åpent. Selv om at det naturligvis går an å toppe dette med å bevisst slå av påloggingssida i Windows.

 

Jeg synes ikke det, vanligvis kommer man ikke inn på en PC med de forutsetningene (om den ikke er ekstremt lenge siden den er oppdatert).

 

AtW

  • Liker 1
Lenke til kommentar

Hva legges i "helt åpen", sier ikke at dette er god politikk fra deloitte, men det som er beskrevet vil jeg ikke kalle "helt åpent".

 

Gitt konteksten her, at det antagelig dreier seg om kritiske systemer hvor det oppbevares store mengder følsom informasjon, så er det dekning for å kalle dette helt åpent, selv om det kreves at man må taste inn et passord.

 

Det begynner å bli en del år siden passord alene ble ansett for å være tilstrekkelig, selv på private epostkontoer, etc.

 

Du beskytter ikke et bankhvelv med en liten hengelås. Joda, det er låst, og en slik hengelås er sikkert tilstrekkelig sikkerhet ved en del bruksområder. Men den er utilstrekkelig mot dem som virkelig gidder å gjøre en innsats. Og det kan for tiden virke som at noen gidder å gjøre det mot selskaper som Deloitte.

Lenke til kommentar

 

Hva legges i "helt åpen", sier ikke at dette er god politikk fra deloitte, men det som er beskrevet vil jeg ikke kalle "helt åpent".

Gitt konteksten her, at det antagelig dreier seg om kritiske systemer hvor det oppbevares store mengder følsom informasjon, så er det dekning for å kalle dette helt åpent, selv om det kreves at man må taste inn et passord.

 

Det begynner å bli en del år siden passord alene ble ansett for å være tilstrekkelig, selv på private epostkontoer, etc.

 

Du beskytter ikke et bankhvelv med en liten hengelås. Joda, det er låst, og en slik hengelås er sikkert tilstrekkelig sikkerhet ved en del bruksområder. Men den er utilstrekkelig mot dem som virkelig gidder å gjøre en innsats. Og det kan for tiden virke som at noen gidder å gjøre det mot selskaper som Deloitte.

 

 

Så hvordan hacker man en maskin med "eksponert" remote desktop med litt tid og innsats?

 

AtW

Lenke til kommentar

 

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.

Endret av Harald Brombach (digi.no)
  • Liker 2
Lenke til kommentar

 

 

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

  • Liker 1
Lenke til kommentar
Gitt konteksten her, at det antagelig dreier seg om kritiske systemer hvor det oppbevares store mengder følsom informasjon, så er det dekning for å kalle dette helt åpent(...)

 

Så vidt jeg leser ut av artikkelen er det ingen som har sagt noe om innhold på de eksponerte serverne? Hvordan vet vi at det er mer enn en testserver eller honeypot?

  • Liker 1
Lenke til kommentar

 

 

 

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.

  • Liker 1
Lenke til kommentar

 

 

 

 

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

  • Liker 1
Lenke til kommentar

Hva er forskjellen om jeg via sosial hacking har de relevante passordene?

 

Dersom du klarer å få noen hos Deloitte til å gi deg brukernavnet og passordet til administratorkontoer, så spiller det liten rolle, det eneste som kan beskytte da måtte være at maskinen var air-gappet, og du måtte ha fysisk tilgang.

 

Likevel, maskiner som eksponeres mot et nettverk, og særlig da et nettverk som er i kontakt med omverdenen via internett, bør beskyttes langt bedre.

 

Så hvordan hacker man en maskin med "eksponert" remote desktop med litt tid og innsats? 

 

Det kommer jo an på maskinen, først ville man vel sjekket hvilke porter som var åpne, og om det var en mulig vei inn i filsystemet.

 

Det finnes måter å få WS2012 til å spytte ut hashene av passordene dersom enkelte patcher mangler, og klarer man å få kjørt samdump på maskinen, så får man tilgang til de hashede passordene.

 

Nå kan man ikke bruke hashen for å logge inn, men Windows har sin egen måte å lagre passord på, og krypteringen skjer i beste fall med MD4.

 

Brute-force på egen maskin for å matche hash mot klartekst, for eksempel ved å benytte hashcat, ophcrack eller lignende, er ikke noe stort problem, og vips så er man inne.

 

Nå finnes det en rekke fremgangsmåter, og også en rekke kjente feil i WS2012 som har blitt tettet opp gjennom årene, slik at det kan godt være det er mange muligheter her.

 

Poenget er jo uansett at man ikke lar direkte innlogging til en server være eksponert på et åpent nett på den måten som er gjort her, det er en enorm sikkerhetsrisiko.

Endret av adeneo
Lenke til kommentar

 

 

Så hvordan hacker man en maskin med "eksponert" remote desktop med litt tid og innsats? 

 

Det kommer jo an på maskinen, først ville man vel sjekket hvilke porter som var åpne, og om det var en mulig vei inn i filsystemet.

 

Det finnes måter å få WS2012 til å spytte ut hashene av passordene dersom enkelte patcher mangler, og klarer man å få kjørt samdump på maskinen, så får man tilgang til de hashede passordene.

 

Nå kan man ikke bruke hashen for å logge inn, men Windows har sin egen måte å lagre passord på, og krypteringen skjer i beste fall med MD4.

 

Brute-force på egen maskin for å matche hash mot klartekst, for eksempel ved å benytte hashcat, ophcrack eller lignende, er ikke noe stort problem, og vips så er man inne.

 

Nå finnes det en rekke fremgangsmåter, og også en rekke kjente feil i WS2012 som har blitt tettet opp gjennom årene, slik at det kan godt være det er mange muligheter her.

 

Poenget er jo uansett at man ikke lar direkte innlogging til en server være eksponert på et åpent nett på den måten som er gjort her, det er en enorm sikkerhetsrisiko.

 

 

Jeg ville aldri satt en maskin så åpent som dette i artikkelen på nett, og er ikke enig med ATW at passordet gir mye til beskyttelse, og man ser jo også at maskinen ikke er patchet. Men når det er sagt, synes jeg ikke du svarer helt på hans spørsmål.

 

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. 

 

Og det er der skoen trykker, slik jeg ser det. Kjente og nyoppdagede sikkerhetshull, i kombinasjon med å ikke ligge bak en brannmur eller VPN. Ikke engang sikker på at totrinnsautentisering hjelper allverdens hvis man ligger med ryggen bar rett mot internett. Og her ligger det altså flere tusen bare rygger. 

Lenke til kommentar

også svar til tommyb

Det kommer jo an på maskinen, først ville man vel sjekket hvilke porter som var åpne, og om det var en mulig vei inn i filsystemet.

 

Det finnes måter å få WS2012 til å spytte ut hashene av passordene dersom enkelte patcher mangler, og klarer man å få kjørt samdump på maskinen, så får man tilgang til de hashede passordene.

 

Nå kan man ikke bruke hashen for å logge inn, men Windows har sin egen måte å lagre passord på, og krypteringen skjer i beste fall med MD4.

 

Brute-force på egen maskin for å matche hash mot klartekst, for eksempel ved å benytte hashcat, ophcrack eller lignende, er ikke noe stort problem, og vips så er man inne.

 

Nå finnes det en rekke fremgangsmåter, og også en rekke kjente feil i WS2012 som har blitt tettet opp gjennom årene, slik at det kan godt være det er mange muligheter her.

 

Poenget er jo uansett at man ikke lar direkte innlogging til en server være eksponert på et åpent nett på den måten som er gjort her, det er en enorm sikkerhetsrisiko.

 

Han spesifiserte jo eksponert remote desktop, som jeg ikke kjenner til at det er noen kjente exploits mot atm. Det er ingen måter å tvinge windows til å sende fra seg passord hashen fra innloggingsskjermen, så man må angripe en bruker først og da tar man jo heller å snapper opp passordet enn passord hashen.

 

En annen ting er dette med oppdateringer, at en server mangler oppdateringer er ikke nyttig informasjon da du kan gå ut i fra at ingen server i verden er helt oppdatert mesteparten av tiden. Det er veldig dyrt å holde alle servere oppdatert hele tiden, og du er godt beskyttet med å ha rutinemessige oppdateringer så skjeldent som en gang i månaden og heller ta hotfixes når det blir offentligjort alvorlige sårbarheter. Du får ingen informasjon om hvem oppdateringer som mangler, så med andre ord er det ingen ny informasjon for angriper.

 

Om det er en enorm sikkerhetsrisiko er fullt og helt avhengig av hva man får tilgang til med en innlogging, 

  • Liker 1
Lenke til kommentar
Gjest Slettet-Pqy3rC

Ironien er jo det fornøyelige her, snakker om å feie for egen dør.

 

Ang RDP;

 

Jeg har åpnet det for en del brukermaskiner; Omtrent sånn:

mstsc /V:rdp.mittdomene.no:47883

(portnummer styrer hvilken maskin som nås. Det åpnes via "schedules" så det er ikke alltid åpent.)

 

Ser ikke helt den store risikoen, selv om ukjente skulle kunne ta seg inn. Det er uansett langt fra maskinen de kommer inn på til server stacket (et helt annet nett, kun nødvendige ting åpent mellom). Disse brukerne har ikke allverdens tilganger. Typisk kan de logge seg videre inn på Mail/CRM eller noe, men da kreves jo ytterligere passord. (Dessuten; mail/CRM kan nåes direkte fra utsiden også).

 

Serverstacket vill jeg ikke gjort det på, RPD inn er en sånn "av og til er det ok" greie.

 

I det hele tatt skal en ha sparsomt med tilganger fra "bruker LAN" til "server LAN". Slik at enhver som fysisk klarer å få tilgang (f.eks snoker rundt i gangene) til en inlogget bruker dings kun får hentet minimalt med info. Så dersom en er der at RDP til brukermaskiner er farlig bør en ha på plass både ståldører og avansert fysisk tilgangskontroll.

 

 

Om det er en enorm sikkerhetsrisiko er fullt og helt avhengig av hva man får tilgang til med en innlogging,

Enig. Endret av Slettet-Pqy3rC
Lenke til kommentar

Som sagt, jeg synes ikke dette er lurt av de, men jeg personlig ville ikke brukt begrepet "åpent", man er stort sett avhengig av at de har gjort en annen feil for at å hacke seg inn såvidt jeg kan forstå, det kan være de har, og det er ikke dumt å ha flere lag med sikkerhet, men det er ihvertfall ikke det jeg klassifiserer som "åpent":

 

AtW

  • Liker 1
Lenke til kommentar

Om du ikke trives med begrepet "åpent", så kan vi for min del si "rett på nett" i stedet. Jeg husker i alle fall et par anledninger der det var svært greit å ikke ha Windows-maskiner koblet direkte mot internett. August 11, 2003 var en slik anledning. Etter den gang har jeg sett på en slik oppkobling som "ubeskyttet" eller "åpen rett mot nett". 

 

Lenke til kommentar

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 konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...