Visselblåsare påstår att Microsoft kände till säkerhetsbrist som ledde till Solarwinds-hacket

Permalänk
Melding Plague

Visselblåsare påstår att Microsoft kände till säkerhetsbrist som ledde till Solarwinds-hacket

Tidigare Microsoft-anställd upptäckte bristen som möjliggjorde de senaste årens stora hack redan 2016.

Läs hela artikeln här

Visa signatur

Observera att samma trivselregler gäller i kommentarstrådarna som i övriga forumet och att brott mot dessa kan leda till avstängning. Kontakta redaktionen om du vill uppmärksamma fel i artikeln eller framföra andra synpunkter.

Permalänk
Medlem

så fokuserad på nya funktioner och ökade intäkter

Jepp, så är det... helt sjukt och hoppas andra tänker annorlunda.

Visa signatur

Proud AMD customer since 1998!

Permalänk
Medlem

Knappast något nytt att stora företag döljer sina brister för kunderna.

Däremot har Microsoft satt sig i skiten helt själva genom att gå ifrån tydliga produktreleaser.

Även baksidan av agil utveckling, där höga chefer och business owners har fingrarna i syltburken.

Permalänk
Medlem

Jag vet inte hur viktigt det är i Sverige (kontra stämningskåta USA), men artikeln här på swec låter som verifierad fakta medan källan ganska tydligt markerar "Harris påstår y, Harris minns att x sa, osv.

Hur funkar sånt? Är man amerikaniserad som förväntar sig" ALLEGEDLY [...] " i var och varenda mening?

Visa signatur

Bleak

Permalänk
Skrivet av zojjz:

Jag vet inte hur viktigt det är i Sverige (kontra stämningskåta USA), men artikeln här på swec låter som verifierad fakta medan källan ganska tydligt markerar "Harris påstår y, Harris minns att x sa, osv.

Hur funkar sånt? Är man amerikaniserad som förväntar sig" ALLEGEDLY [...] " i var och varenda mening?

"Nu rapporterar Propublica att en visselblåsare som tidigare jobbade på Microsoft påstår att de här säkerhetsbristerna var kända redan 2016, fyra år innan Solarwinds-hacket."

Detta borde räcka som gardering rent journalistiskt. Att sedan återupprepa att det handlar om ett påstående istället för verifierad fakta är mest osmickrande mot läsaren. Behövs det? Vet ej.

Permalänk
Medlem
Skrivet av walkir:

Knappast något nytt att stora företag döljer sina brister för kunderna.
...

Vill bara poängtera en självklarhet; Man kan ju inte göra det enkelt för bad-guys genom att servera svagheter på silverfat. Klart de måste döljas tills de åtgärdas

Permalänk
Hedersmedlem

Den här artikeln är skriven på ett sådant sätt att det är omöjligt att bilda sig själv en uppfattning om vadi problemet faktiskt består i. Många ord men inget riktigt "kött".

Hur mycket access behöver man till ADFS-servern för att nyttja den här sårbarheten? Jag kan tänka mig att en användare med administratörsaccess kan skapa i princip vilka "assertions" som helst och därmed ge sig själv de behörigheter som den här sortens federation medger... det är inte direkt någon hemlighet, utan det beror på att ADFS är ett betrott system för autentisering. Det är ungefär lika intressant som att någon som har admin-access till din domänkontrollant kan ta över hela din domän.

Om det är som jag tror att det är så kan jag förstå att MS ignorerat detta, detta hör till hur produkten är designad och var man deployar den, det är ingen regelrätt svaghet i sig.

Men om det är så att det finns något mer intressant här så får man gärna fylla på med lite mer info om vari sårbarheten består.

Permalänk
Medlem
Skrivet av pv2b:

Den här artikeln är skriven på ett sådant sätt att det är omöjligt att bilda sig själv en uppfattning om vadi problemet faktiskt består i. Många ord men inget riktigt "kött".

Hur mycket access behöver man till ADFS-servern för att nyttja den här sårbarheten? Jag kan tänka mig att en användare med administratörsaccess kan skapa i princip vilka "assertions" som helst och därmed ge sig själv de behörigheter som den här sortens federation medger... det är inte direkt någon hemlighet, utan det beror på att ADFS är ett betrott system för autentisering. Det är ungefär lika intressant som att någon som har admin-access till din domänkontrollant kan ta över hela din domän.

Om det är som jag tror att det är så kan jag förstå att MS ignorerat detta, detta hör till hur produkten är designad och var man deployar den, det är ingen regelrätt svaghet i sig.

Men om det är så att det finns något mer intressant här så får man gärna fylla på med lite mer info om vari sårbarheten består.

Du har lite mer i https://www.propublica.org/article/microsoft-solarwinds-golde..., men de nämner bara ytligt om token forgery och att man tar ADFS-serverns privata nyckel. Men just kopplingen mellan On prem-ADFS och Azure-tjänster är väl det i detta fall som var en del av intrångsvägen.

Men lägg till datat om intrången som kineserna och rysserna gjort senate åren mot Azure så kan man väl tänka sig att de inte validerar biljetten korrekt också. Kanske t.ex validerar CAn men inte resterande kedja etc.

Lägg också till det som framkommit på senare tid att det inte går att få en överblick i systemet om vem och vilka processer som givits access historiskt och som fortfarande har tokens. Man kan nog summera det som att EntraID/Azure AD och ADFS är något som borde göras om från grunden.

Permalänk
Hedersmedlem
Skrivet av Sidde:

Du har lite mer i https://www.propublica.org/article/microsoft-solarwinds-golde..., men de nämner bara ytligt om token forgery. Men lägg till datat om intrången som kineserna och rysserna gjort senate åren mot Azure så kan man väl tänka sig att de inte validerar biljetten korrekt.

Jo jag läste den också. Men Token Forgery kan ju precis lika gärna vara att någon som har administrativ access till ADFS-servern kan skapa "biljetter" som är helt legitima. Det finns ungefär 100 olika sätt att åstadkomma detta, med olika sofistikationsnivåer.

Det hela bottnar i spekulation bara. Det relevanta är - behöver man admin-access till ADFS-servern för att komma vidare in i Azure? Om ja, så är det inte en sårbarhet, säkerheten bygger på att ADFS-servern är säker.

Permalänk
Medlem
Skrivet av pv2b:

Jo jag läste den också. Men Token Forgery kan ju precis lika gärna vara att någon som har administrativ access till ADFS-servern kan skapa "biljetter" som är helt legitima. Det finns ungefär 100 olika sätt att åstadkomma detta, med olika sofistikationsnivåer.

Det hela bottnar i spekulation bara. Det relevanta är - behöver man admin-access till ADFS-servern för att komma vidare in i Azure? Om ja, så är det inte en sårbarhet, säkerheten bygger på att ADFS-servern är säker.

Felet är väl i att man ofta "tvingas" bygga denna trust mellan olika säkerhetsdomäner och att man inte informerar om att detta är ett problem. Vill man slippa omautentisering så kommer det med försämrad säkerhet. Och det är väl vad artikeln delvis handlar om, alltså att stänga av möjligheten för denna form av SSO och det ville man inte för då förlorade man potentiellt affären.

I slutändan säljer MS en by default osäker tjänst, istället för att rekommendera att t.ex myndigheter får en säker lösning med färre funktioner. För att begära om-autentisering med smartcard är ju knappast jobbigt för slutanvändaren. Man studsar ju bara på en ny idp.

Permalänk
Medlem

Kan säga att detta är rätt vanligt inom it branschen exakt som det beskrivs. Nog de flesta som jobbat inom IT kan hålla med.
Alla säger de tar allvarligt på säkerhet men så är inte fallet i många fall

Permalänk
Medlem

Så då var det dags igen för Microsoft att fokusera på säkerhet. Sist var det väl 2003 då Bill Gates lovade en omsvängning mot säkerhet.
Nu har ju Brad Smith lovat samma sak till Amerikanska kongressen.
https://www.propublica.org/article/microsoft-solarwinds-cyber...

Visa signatur

Klient: AMD 7 5800X | ASUS X570-F | 32GB 3200MHz | Corsair RM850 | Gigabyte 3070 | Phanteks P500A | Samsung 980 PRO
HTPC: Intel I7 4770T | 16 GB 1600 | FC8 EVO | Gigabyte GA-H87N-WIFI | Samsung 840 250GB
Server: Intel XEON E5620 x 2| ASUS Z8PE-D18 | 96GB 1333MHz | Corsair AX 1200W | HAF 932 | WD Black 2TB
Nätverk: Telia F@st| Unifi AC Lite/Pro/LR/Nano/Mesh/U6-LR/U6+/U6-Lite | Nighthawk M1 | pfSense | TP-Link TL-WPA8630KIT | Ubiquiti NanoStation M5 | UniFi Switch 8-150W

Permalänk
Hedersmedlem
Skrivet av Sidde:

Felet är väl i att man ofta "tvingas" bygga denna trust mellan olika säkerhetsdomäner och att man inte informerar om att detta är ett problem. Vill man slippa omautentisering så kommer det med försämrad säkerhet. Och det är väl vad artikeln delvis handlar om, alltså att stänga av möjligheten för denna form av SSO och det ville man inte för då förlorade man potentiellt affären.

I slutändan säljer MS en by default osäker tjänst, istället för att rekommendera att t.ex myndigheter får en säker lösning med färre funktioner. För att begära om-autentisering med smartcard är ju knappast jobbigt för slutanvändaren. Man studsar ju bara på en ny idp.

Det är väl ingen som tvingar någon att bygga en trust mellan kundens onpremdomän och Azure eller Microsoft 365?

För mig är det självklart att om du sätter upp ADFS så är det i princip så att du litar på att denna server får autentisera användare åt dig. Om någon obehörig har adminaccess på den servern så kan då denna server autentisera användare på felaktiga premisser. Det är helt teknikneutralt, din miljö blir då inte säkrare än din onprem-miljö för AD redan är eller inte är. Det samma gäller för all extern autentisering du hakar på en molnlösning, molnet blir inte säkrare än den valda autentiseringslösningen.

Det har inget med någon specifik teknik att göra, det är bara fundemantalt inbyggt i vad ADFS är för något - ett sätt att låta din on-prem-infra autentisera användare att få åtkomst till molntjänster. Det är inte Microsofts fel om man inte gjort en riskanalys innan man bara deployar något som "låter bra".

Den fundamentala frågan som man behöver svara på är: Är min on-prem-infrastruktur tillräckligt säker för att använda den som autentisering av mina molntjänster? Och vad är riskerna med att exponera denna infrastruktur mot Internet?

Permalänk
Medlem
Skrivet av Spawnbadboy:

Kan säga att detta är rätt vanligt inom it branschen exakt som det beskrivs. Nog de flesta som jobbat inom IT kan hålla med.
Alla säger de tar allvarligt på säkerhet men så är inte fallet i många fall

Problemet är också att ju säkrare man gör saker desto sämre användarupplevelse blir det. Men ja, när det kommer till kritiska brister så borde (måste) man täppa till dem, inte ducka.

Visa signatur

AMD 5800X ▪ MSI B550M Mortar ▪ G.Skill 32GB 3600MHz CL16 ▪ Palit 4070 Ti ▪ 1TB SSD 970 Evo+ ▪ Dark Power 13 1000W ▪ FD Define Mini C ▪ Aorus AD27QD + LG 27GL850

Permalänk
Medlem
Skrivet av pv2b:

Det är väl ingen som tvingar någon att bygga en trust mellan kundens onpremdomän och Azure eller Microsoft 365?

Beror på vem som tillhandahåller tjänsten och hur den säljs om. I teorin håller jag med dig men i verkligheten har jag sett detta gått fel om och om igen. Det är sällan ens samma del av verksamheten som beställer tjänster och formulerar krav på hur den ska se ut, och den som sköter t.ex ett AD eller ADFS.

Normalt sett har man ju flera olika idper baserat på olika säkerhetszoner/tjänster och dess exponering, hur kritisk de är etc.
Den som skyddas minst är den nära klientplattformen som är tätt knuten till Windows-klienterna eftersom den måste ges access till hela ens klientflora för alla klientnära tjänster.

Eftersom Microsoft själv enligt denna artikel hävdar att de kommer förlora myndighetsaffärer om de inte länkar ihop dessa olika zoner/tjänster genom samma trust. Så vet ju uppenbart Microsoft själva att de vilseleder kunder in på osäkra lösningar.

Det är alltså uppsåtligt av dem att genom sin tjänst äventyra säkerheten för olika företag.
Sedan är det precis som du säger inget tvång, utan snarare okunskap.
Men i andra brancher är det ju sällan OK att leverera osäkra, brandfarliga eller annars skadliga lösningar utan att vara väldigt tydliga med det.

Skrivet av pv2b:

För mig är det självklart att om du sätter upp ADFS så är det i princip så att du litar på att denna server får autentisera användare åt dig. Om någon obehörig har adminaccess på den servern så kan då denna server autentisera användare på felaktiga premisser. Det är helt teknikneutralt, din miljö blir då inte säkrare än din onprem-miljö för AD redan är eller inte är. Det samma gäller för all extern autentisering du hakar på en molnlösning, molnet blir inte säkrare än den valda autentiseringslösningen.

Det har inget med någon specifik teknik att göra, det är bara fundemantalt inbyggt i vad ADFS är för något - ett sätt att låta din on-prem-infra autentisera användare att få åtkomst till molntjänster. Det är inte Microsofts fel om man inte gjort en riskanalys innan man bara deployar något som "låter bra".

Oja. håller helt med. Men jag kan se varje vecka att man inte förstår detta.
Till stor del tycker jag det kommer från att man blir bombarderad från säljare/IT-företag som lovar guld och gröna skogar med alla dessa lösningar.

Men varenda IT-säljare är ju ute och kränger Zero Trust på samma princip.
Häng upp allt på en idp, som du sedan placerar gärna exponerat på Internet, eller i molnet. Som sedan ska ställa ut biljetter till alla dina tjänster oavsett om de är On-Prem eller i Molnet.
Så istället för Zero Trust byggt man 100% all in trust i IdPn.

Det finns bara en lösning och det är att dela upp sina tjänster och sluta integrera saker i onödan.
Och ja, man borde tänka efter före.

Men hur många produktinföranden har du varit med om där de som inför produkterna faktiskt frågar de tekniker som har kunskap om hur det ska fungera? Och oavsett det så om företag som Microsoft i detta läge vet om svagheten, och undanhåller det för kunden samt by default vill erbjuder den sämre lösningen.

Stavfel etc.
Permalänk
Hedersmedlem
Skrivet av Sidde:

Beror på vem som tillhandahåller tjänsten och hur den säljs om. I teorin håller jag med dig men i verkligheten har jag sett detta gått fel om och om igen. Det är sällan ens samma del av verksamheten som beställer tjänster och formulerar krav på hur den ska se ut, och den som sköter t.ex ett AD eller ADFS.

Normalt sett har man ju flera olika idper baserat på olika säkerhetszoner/tjänster och dess exponering, hur kritisk de är etc.
Den som skyddas minst är den nära klientplattformen som är tätt knuten till Windows-klienterna eftersom den måste ges access till hela ens klientflora för alla klientnära tjänster.

Eftersom Microsoft själv enligt denna artikel hävdar att de kommer förlora myndighetsaffärer om de inte länkar ihop dessa olika zoner/tjänster genom samma trust. Så vet ju uppenbart Microsoft själva att de vilseleder kunder in på osäkra lösningar.

Det är alltså uppsåtligt av dem att genom sin tjänst äventyra säkerheten för olika företag.
Sedan är det precis som du säger inget tvång, utan snarare okunskap.
Men i andra brancher är det ju sällan OK att leverera osäkra, brandfarliga eller annars skadliga lösningar utan att vara väldigt tydliga med det.

Oja. håller helt med. Men jag kan se varje vecka att man inte förstår detta.
Till stor del tycker jag det kommer från att man blir bombarderad från säljare/IT-företag som lovar guld och gröna skogar med alla dessa lösningar.

Men varenda IT-säljare är ju ute och kränger Zero Trust på samma princip.
Häng upp allt på en idp, som du sedan placerar gärna exponerat på Internet, eller i molnet. Som sedan ska ställa ut biljetter till alla dina tjänster oavsett om de är On-Prem eller i Molnet.
Så istället för Zero Trust byggt man 100% all in trust i IdPn.

Det finns bara en lösning och det är att dela upp sina tjänster och sluta integrera saker i onödan.
Och ja, man borde tänka efter före.

Men hur många produktinföranden har du varit med om där de som inför produkterna faktiskt frågar de tekniker som har kunskap om hur det ska fungera? Och oavsett det så om företag som Microsoft i detta läge vet om svagheten, och undanhåller det för kunden samt by default vill erbjuder den sämre lösningen.

Jo, jag tror nog vi är rörande överens. Problemet är inte att det finns en säkerhetbrist i ADFS, utan snarare att ADFS blir en svag punkt som kräver att man faktiskt lägger nödvändigt krut och säkerhetsdisciplin som krävs när man sätter upp en tjänst. Det är inte något oviktigt sidosystem, det blir liksom nyckeln in i hela din infrastruktur.

Svagheten uppstår när man gör ogenomtänkta deployments av detta, och kanske att Microsoft inte vill skrämma bort kunder genom att poängtera de säkerhetsåtgärder man faktiskt måste ta när man kör ADFS. För man kan ju resonera som att om de har on-prem-AD så måste de ändå göra allt det där säkerhetshöjande, och att lösningen i helhet inte blir mindre säker än ett on-prem-AD. (Många on-prem-AD:n är ju katastrofalt dåligt uppsatta... men det är ju inte ADFS fel.)

Permalänk
Medlem
Skrivet av pv2b:

Det är väl ingen som tvingar någon att bygga en trust mellan kundens onpremdomän och Azure eller Microsoft 365?

Förutom den lilla detaljen att Microsoft kräver att man ska ha det som förut kallades Azure AD om man ska köra det som förut kallades Office. Hela skiten är knuten till molnet, i stället för att bara installeras som ett helt vanligt Windows-program.

Så då har man som organisation att välja på att ha två AD:n, ett on-prem och ett i molnet, eller att ha ett AD som synkas mellan on-prem och moln. Gissa vad organisationer väljer.

SAML är nog för övrigt den enda standard jag har gjort ett allvarligt försök att sätta mig in i och misslyckats. Jävla oläsligt härke. Det skulle säkert gå om jag hade en bra anledning, men det känns rätt skönt att ha lämnat den världen.

Permalänk
Hedersmedlem
Skrivet av KAD:

Förutom den lilla detaljen att Microsoft kräver att man ska ha det som förut kallades Azure AD om man ska köra det som förut kallades Office. Hela skiten är knuten till molnet, i stället för att bara installeras som ett helt vanligt Windows-program.

Så då har man som organisation att välja på att ha två AD:n, ett on-prem och ett i molnet, eller att ha ett AD som synkas mellan on-prem och moln. Gissa vad organisationer väljer.

SAML är nog för övrigt den enda standard jag har gjort ett allvarligt försök att sätta mig in i och misslyckats. Jävla oläsligt härke. Det skulle säkert gå om jag hade en bra anledning, men det känns rätt skönt att ha lämnat den världen.

Du har nog missat vad ADFS är. Vill du synka katalogerna så kan du använda MS Entra Connect (tidigare känt som Azure AD Connect). ADFS är bara ett krav om du dessutom vill ha SSO, går utmärkt att köra Entra Connect utan att köra ADFS.

Permalänk
Medlem
Skrivet av Spawnbadboy:

Kan säga att detta är rätt vanligt inom it branschen exakt som det beskrivs. Nog de flesta som jobbat inom IT kan hålla med.
Alla säger de tar allvarligt på säkerhet men så är inte fallet i många fall

Är samma i alla branscher tyvärr, inte bara IT.

Säkerhet sägs prioriteras men ses bara som en kostnad, fram till att något går åt skogen.