en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Mars 2021 Sikkerhet Roundup

God vår til alle våre lesere! Velkommen til denne marsutgaven av SSL.com Security Roundup, der vi ser tilbake på en måned som gikk i 2021. Spesielt ser vi tilbake på den siste måneden innen digital sikkerhet, og har samlet det vi anser som det mest nyhetsverdige ting i det riket, for deg, nedenfor.

eSigner tilbyr SSL.com-kunder en enhetlig plattform og brukergrensesnitt for skydokument- og kodesignering. Lær mer om eSigner.eSigner

IETF avvikles TLS 1.0 og 1.1

Vi har visst det en stund nå TLS versjoner 1.0 og 1.1 er usikre. Internet Engineering Task Force (IETF) gjorde det nettopp offisielt med RFC 8996, som formelt avskriver disse foreldede TLS versjoner.

Fra det abstrakte:

Dette dokumentet avskaffer formelt Transport Layer Security (TLS) versjoner 1.0 (RFC 2246) og 1.1 (RFC 4346). Følgelig er disse dokumentene flyttet til historisk status. Disse versjonene mangler støtte for nåværende og anbefalte kryptografiske algoritmer og mekanismer, og ulike offentlige og industriprofiler av applikasjoner som bruker TLS nå mandat å unngå disse gamle TLS versjoner. TLS versjon 1.2 ble den anbefalte versjonen for IETF-protokoller i 2008 (senere foreldet av TLS versjon 1.3 i 2018), og gir tilstrekkelig tid til å gå over fra eldre versjoner. Fjerning av støtte for eldre versjoner fra implementeringer reduserer angrepsoverflaten, reduserer muligheten for feilkonfigurasjon og strømlinjeformer biblioteks- og produktvedlikehold.

SSL.coms takeway: Deaktivering av tidlige, usikre versjoner av SSL og TLS er et viktig beste praksis for internett-sikkerhet. Hvis du ikke er sikker på om TLS 1.0 og 1.1 er fortsatt aktivert på serverne dine, det er nå en flott tid å sjekke og oppdatere innstillingene dine om nødvendig. Ta en titt på disse ressursene fra SSL.com for mer informasjon:

Chrome 90 vil som standard være HTTPS

Fra versjon 90 bruker Chrome adressefelt HTTPS som standardprotokoll. Det betyr at nettadresser som er angitt uten prefikset, som de fleste brukere pleier å gjøre, blir sikrere https:// istedenfor http://, som var Chrome-standard frem til dette punktet. Bryteren har åpenbare sikkerhetsimplikasjoner — HTTPS er sikrere og forhindrer avlytting og snusing ved å kryptere trafikk. Bryteren av Chrome gir også et løft i ytelse ved at den eliminerer behovet for omdirigering fra forrige standard til den mer brukte protokollen. Som rapportert av de Chromium Blog:

I tillegg til å være en klar sikkerhets- og personvernforbedring, forbedrer denne endringen den opprinnelige innlastingshastigheten til nettsteder som støtter HTTPS, siden Chrome vil koble seg direkte til HTTPS-endepunktet uten å måtte omdirigeres fra http: // til https: //. For nettsteder som ennå ikke støtter HTTPS, vil Chrome falle tilbake til HTTP når HTTPS-forsøket mislykkes (inkludert når det er sertifikatfeil, for eksempel navnematching eller ikke-klarert selvsignert sertifikat, eller tilkoblingsfeil, for eksempel DNS-oppløsningsfeil) .

I utgangspunktet vil bryteren rulle ut på Chrome Desktop og Chrome for Android. En bryter for Chrome på iOS følger.

SSL.coms takeaway: Med de fleste nettsteder som nå er HTTPS aktivert, vil denne endringen i Chrome øke sikkerheten og hastigheten for brukerne. Tydeligvis medundertegner vi ethvert trekk som har disse målene i bakhodet.

Verkada Hack eksponerer 150,000 XNUMX sikkerhetskameraer

I en ganske upålitelig start fikk en Silicon Valley-oppstart kjent som Verkada et massivt sikkerhetsbrudd. Hackere tok kontroll over mer enn 150,000 kameraer plassert på steder som fengsler, politistasjoner, Tesla-fabrikker, sykehus, treningssentre og til og med kontorene til selskapet selv. Hvorfor var disse kameraene så følsomme steder? Vel, fordi Verkada, dessverre nok, er et sikkerhetsselskap. I følge en omfattende rapport by Bloomberg William Turton, hackerne fikk tilgang gjennom et brukernavn og passord som ble funnet online for en “Super Admin” -konto, og ga tilgang til kameraene til alle selskapets kunder.

Denne tilgangen gjorde det mulig for inntrengerne å se inn på sykehusrom, vitneintervjuer mellom politi og kriminelle mistenkte, og se hvem som hadde brukt adgangskontrollkort på et Tempe-sykehus. Når det gjelder motivasjonen bak hacket, Bloomberg rapporter:

Databruddet ble utført av et internasjonalt hackerkollektiv og ment å vise den omfattende videoovervåking og hvor enkelt det kan brytes inn i systemer, sa Tillie Kottmann, en av hackerne som hevdet kreditt for å ha brutt San Mateo, California-basert. Verkada. Kottmann, som bruker pronomen, hevdet tidligere kreditt for hacking av chipmaker Intel Corp. og bilprodusent Nissan Motor Co. Kottmann sa at årsakene til hacking er "mye nysgjerrighet, kjemper for informasjonsfrihet og mot immateriell eiendom, en enorm dose antikapitalisme, et snev av anarkisme - og det er også bare for gøy å ikke gjøre det. ”

Hacket "avslører hvor bredt vi blir undersøkt, og hvor lite forsiktighet er lagt i det minste å sikre plattformene som brukes til å gjøre det, og ikke forfølge annet enn fortjeneste," sa Kottmann.

Etter hendelsen deaktiverte Verkada alle interne administratorkontoer og startet en etterforskning.

SSL.coms takeaway: Når vi ser bort fra den samlede kritikken av livet i et overvåkingssamfunn, fokuserer vi på sunn fornuft her. Ikke avslør påloggingsinformasjonen på Internett, men vurder sikrere alternativer som sertifikatbasert autentisering også.

Store sikkerhetsfeil funnet i Netop Vision Software

I skumle nyheter for foreldre som bare prøver å komme seg gjennom resten av hjemmelæringen, har man funnet store sikkerhetsproblemer i Netop Vision - en populær programvare for virtuell læring som brukes av rundt 3 millioner lærere og studenter. Netop muliggjør hjemmelæring ved å fungere som et elevovervåkingssystem som lar lærere arbeide eksternt på studentenes datamaskiner, og brukes hovedsakelig til å administrere skolelaboratorier eller klasserom. På grunn av Covid har studentene imidlertid tatt med seg datamaskiner med programvaren for fjernundervisning, noe som øker rekkevidden og sårbarheten.

Forskere ved McAfee kunngjorde at de hadde funnet fire kritiske feil i klasseromsadministrasjonsprogramvaren. Feilene kan tillate angripere å ta kontroll over datamaskiner, stjele legitimasjon eller installere løsepenger. Bekymringsfullt kan sikkerhetsproblemene også gjøre det mulig for hackere å posere som lærere og observere studenter.

Benjamin Freed kl EdScoop rapporterte om problemet i mars:

Medlemmer av McAfees Advanced Threat Research Group testet Netop-programmet ved å lage et simulert virtuelt klasserom, med en datamaskin som fungerte som lærerstasjon og tre studentenheter. En av de første tingene forskerne la merke til var at brukerprofiler for lærere og elever hadde forskjellige tillatelsesnivåer. De oppdaget også raskt at all nettverkstrafikk mellom læreren og studentene ble sendt i ukrypterte pakker - inkludert skjermbilder av elevenes skjermer som ble sendt til læreren - uten mulighet til å slå på kryptering.

"Med denne informasjonen klarte teamet å skjule seg som lærer ved å endre koden," skrev McAfee-forskerne.

Etter å ha lært om angrepet, handlet selskapet raskt for å fikse de fleste av problemene. Imidlertid fortsetter programvaren å bruke ukrypterte tilkoblinger, noe som er en fortsatt risiko.

SSL.coms takeaway: Dette er en god påminnelse om at all programvare som brukes til ekstern læring (eller eksternt annet, egentlig) skal bruke nettverkskryptering for å forhindre avlytting eller verre.

 

 

Abonner på SSL.coms nyhetsbrev

Ikke gå glipp av nye artikler og oppdateringer fra SSL.com