Zo lust ik er nog wel een.
"M.E. Doc" klinkt ook als een arts die zich verstaanbaar probeert te maken naar iemand die een andere taal spreekt.

Nee het is echt zo! Vandaar het gele honingraatstructuurtje in hun logo. Maar jij zoekt niet goed op internet.
Trouwens onzinnig om daar nu opeens over te hebben. Is inhoudelijk niet het onderwerp.

- Attacks via update servers vinden al lang plaats:
https://www.security.nl/posting/495265/Militair+intranet+Zuid-Korea+gehackt+via+updateservers
https://www.security.nl/posting/41591/Gehackt+Koreaans+updatesysteem+verspreidt+malware
https://www.security.nl/posting/33150/35+miljoen+Koreanen+bestolen+via+Trojaanse+update

- Gebruik alleen automatische updates van betrouwbare softwareleveranciers en dan ook alleen voor security updates
- Gebruik geen automatische updates van onbekende(re) partijen of voor alleen feature updates
- Monitor en pas netwerksegmentatie toe

Kijk ook naar de attack vectors. Het missen van updates is een probleem voor browser, OS en Office. Maakt het uit als je boekhoudsoftware een versie achterloopt? Hoeveel van de updates van M.E.Doc zijn security related?

Eigen een onwerkbare situatie voor de meeste mensen.

En malware kan gewoon op de achtergrond actief blijven, totdat er wel Internet verbinding is. En wanneer weet je dat je malware actief hebt?
POP3 is iets wat je eigenlijk alleen maar gebruikt als je een ISP Email adres hebt. De meeste gebruiken tegenwoordig toch echt cloud Email.
Internet verbinding verbreken en weer maken, klinkt leuk, maar of dit nu de oplossing?


Is mis eigenlijk welke risico je nu bedoelt?

Eigen iedere software die automatisch updates gaat doorvoeren?

Wat Neb zegt is een goede, maar daarbij wil ik aantekenen dat de updatesoftware de integriteit van de update moet controleren; door bijvoorbeeld een PGP handtekening te controleren en alleen updates te accepteren die correct ondertekend zijn met een van een beperkt lijstje sleutels (Bij installatie van de software op de computer gezet).

Als je een vaste updateserver hebt: verbinden met TLS (https) en certificaat controleren; doe aan "certificate pinning".

Een aanname fie in de praktijk al fout gebleken is.

Je kunt beter de impact on je eigen omgeving inperken door containerisatie.

Er is geen enkele reden dat een software update proces meer zou mogen dan enkel zijn eigen software updaten en dat alleen nog na accordaient/gandmatige start.

Er is geen enkele reden een applicatie zoals een boekhoud pakket of dbms met administrator rechten te draaien.

Gewoon specifieke rechten inregenen zoals sinds jaar en dag mogelijk is. Ja dat kost wat en is wat lastiger. Het gemak om het niet te doen en alles open te laten heeft ook zijn prijs.
Het eerste is zichtbaar budget het laatste is event schadepost. Kwestie van boekhouden of het uit komt.

Alles wat je niet zelf host, is een derden. Het maakt op dat moment niet uit wie je leverancier is. En bij automatische updates van een derden, en je altijd afhankelijk van die derde partij.
Echter..... Ook al host je dit intern, dan heb je nog eigenlijk exact het zelfde probleem. Wie zegt dat de update van je leverancier te vertrouwen is?

Microsoft is al vaker "gehackt". 15 jaar geleden stond hun anonymous FTP server open. De beveiliging bestond uit het niet tonen van een directoryinhoud, totdat het opeens allemaal wel zichtbaar was, mogelijk door een bug/exploit. Op die FTP server stonden enorme klantdatabestanden, interne documenten, patches, updates en software.

Het komt voor maar het is een zeldzaamheid. Bij microsoft heb ik nog niets opgevangen over updateservers maar niets is onmogelijk. Zo hadden ze ook eens een beveiligingssleutel gewoon in de documentatie opgenomen (open source).

Voor het verhaal van MEdoc waren er dit soor gevallen die er op leken.
https://www.security.nl/posting/463892/Linux+Mint+wijzigt+wachtwoordbeleid+na+hack
https://en.wikipedia.org/wiki/Norton_AntiVirus (norton 25-7-2006)

Voor thuis maak ik me er niet zo druk over. Impact overweging. Voor bedrijfsomgevingen en gevoelige data steek ik er anders in. Microsoft is vermoedelijk failliet als ze zo'n fout met update servers maken. Dat besef helpt dat ze er eg voorzichtig mee zullen zijn.

Dat valt niet echt onder hacken...... "mogelijk door een bug/exploit". Komt hiervoor of met een bron, of roep dit soort hele vage dingen niet. Beheerders fout is een stuk logischer.
Maar we hebben het dus met je hack over een verkeerd geconfigureerde ftp server die iets te veel aanbied. Dit heeft dus helemaal niets met maken waarover we nu discussieren, nog even afgezien dat het over 15 jaar geleden hebben, dat is de middeleeuwen van de ICT.

De meeste "fouten" zijn daar voornamelijk verkeerd geapprove patches die aangeboden worden. Gehacked zijn ze (tot zover we weten) nog nooit.

En als de firewall op die PC nou eens zou aanslaan?
Maar in ieder geval is het al veiliger dat de e-mail PC niet het netwerk kan besmetten, omdat hij afgezonderd is.

Ik heb e-mail erbij genoemd omdat via die weg ook veel besmetting optreedt.
(je kan het zelfs ook beschouwen als een soort updatesysteem, maar dan voor de persoon die achter de computer zit)

Het zal wel geen ideale methode zijn die ik heb voorgesteld, maar je mag best met een betere methode komen die werkbaar maar ook bijzonder veilig is. De bedoeling van deze mail is dat we van elkaar leren.
Afhankelijk van de werkksituatie zal dat ook best wel verschillen denk ik.
De methode van een ZZP-er zal niet hetzelfde zijn als bij een groot bedrijf van 1000 man.
Er worden hier nogal eens wat woorden van personen afgekraakt, maar kom nou eens met een beter idee en maak duidelijk waarom het beter is. Populairder wil niet altijd zeggen dat het veiliger is.
We zitten allemaal met het probleem van aanvalsrisico's via e-mail, en sinds kort hebben we dus weer eens gezien dat het ook via het update kanaal kan. De vraag is: wat kunnen we er aan doen om het veiliger te maken zonder dat het een onwerkbare situatie wordt. En dan zal de oplossing van een hobbyist, thuiswerker of ZZP-er er vast anders uitzien dan een oplossing voor dat grote bedijf, maar daarom hoeft het niet minder waardevol te zijn. Dus iedereen is uitgenodigd voor een goed idee.
En ook softwares met een nogal onveilige update policy zijn handig om te weten. Denk ook aan AV-software e.d.
Misschien is het wel verstandiger om een andere AV-software te nemen. Je weet maar nooit.
Er zijn hier vast wel mensen die er verstand van hebben om dat bij zichzelf na te gaan hoop ik.

Nee, dat is het niet. Een beheerdersfout is het zeker niet vanwege de responses van de FTP server. Daaruit bleek duidelijk dat er een stabiliteitsprobleem was. Als je er niets van weet kun je beter geen conclusies trekken die niet door de feiten worden ondersteund.

Klinkt raar.... G-Suite van google. Past bij een ZZP-er prive persoon, of een groot bedrijf.
Perfecte anti spam, antimalware, werkt heel goed in een webbrowser. De meest normale standaard documenten kunnen er in geopend worden. Geavanceerd bedrijf, wat veel mogelijkheden bied.

Enige nadeel, het is google, en dat is voor vele personen vloeken. Terwijl ze een hele mooie productlijn hebben staan, waar menig bedrijf nog iets van kan leren.

Je denk dat security updates de enige belangrijke updates zijn ?

Boekhoud software kan bijvoorbeeld geupdate worden in verband met nieuwe belastingregels. Of bugfixes - feitelijk is de boekhouding toch ongeveer de meest kritische data die een bedrijf heeft - en dat kan maar beter correct zijn.
(feitelijk heel wat belangrijker dan bijvoorbeeld een 'side channel attack tegen de gpg library mogelijk voor software die op dezelfde host draait ) .

Zo'n reactie uit een andere thread misstaat ook onder dit topic ("Updatemethoden veilig") niet.
Dit is precies het soort reacties die onder dit topic vallen.
Bij deze en welbedankt SecGuru_OTX.

Je vergeet de franse wijn ;)

Sorry, maar ik zie in hun gele zeskantige logo/icoontje geen overeenkomsten met Medoc wijn.
https://duckduckgo.com/?q=M.E.Doc+logo+site%3Awww.me-doc.com.ua&kad=nl_NL&ia=web

Een stuk zeskantige gele kaas uit de Medoc dan?... Ook niet.
https://www.dictionaries24.com/nl/nederlands,russisch,honing
(wat doet dat salontafeltje daar tussen "me" en "ok"? Of is dat een geïnfecteerde "d"?)

Niet dat het er toe doet, maar ‘???’ = ‘med’ betekend honing in het Russisch.

Hoewel ik het er mee eens dat https beter is, is het niet per se noodzakelijk om dat te gebruiken als er een cryptografisch alternatieve wijze van integriteitscontrole is. Dus niet zoals bij M.E. Doc waarbij je een willekeurige executable kan uitvoeren zonder enige vorm van controle, maar bijvoorbeeld gpg sigs van alle bestanden. Daarbij ga je er vanuit dat de public key bekend is op de client en dat de client van alle bestanden de sigs controleert voordat ze worden geinstalleerd. Dat doen/deden sommige Linux distributies ook.

Sig files zijn beter dan SSL certificaat controles op executables omdat er strakke regie is over wie de public key uitgeeft (de bron zelf) en de sleuteluitwisseling en controle niet afhankelijk is van de kwaliteit van alle trusted CA's. Er is gebleken dat de implementatie van die SSL certificaat controles op executables bij sommige antivirus bedrijven niet in orde was. Er werd blijkbaar niet op certificaat integriteit gecontroleerd, maar op naam. Een bekende naam zoals Microsoft werd doorgelaten. Dat is wel lekker snel, maar het is natuurlijk geen controle.

Dus: gpg sigs zijn in principe beter dan SSL certificaten voor subsequente updates. HTTPS is beter voor de initiele download waarbij de public key wordt geleverd. Nog beter is HTTPS+GPG sigs, daarbij is het risico van inmenging door derden, ook bij MitM en valse certificaten het kleinst.

In ieder geval moet je de waarde van HTTPS en SSL certificaten niet overschatten, er zijn al vaker valse certificaten uitgegeven. Anderzijds is de waarde van de GPG public key sterk afhankelijk van de wijze van overdracht en dat is vaak niet goed te controleren.

Het bedrijf in Oekraine, waar het over gaat in dit topic, is in principe een betrouwbare software leverancier. In theorie zou ook Microsoft gehacked kunnen worden, om vervolgens Windows Update te misbruiken voor het verspreiden van malware. Danwel het update mechanisme van software van andere 'betrouwbare' software leveranciers.


Een belangrijke update kan je ook testen, voordat je deze op alle systemen installeert. Het advies was om niet-security updates niet vol automatisch uit te rollen; niet om ze te negeren.

Sterk! ;-)
Doordenker en dubbelzinnig.

Ongebruikelijk experiment maar het werkt:

Als je voldoende werkgeheugen hebt probeer dan eens LIVE Linux Mint (LLM) vanaf een USB-stick. (Zonder in te gaan op hoe dit te uit te voeren). Ook hierbij kan een virtuele Windows worden gebruikt. Een virtuele Windows XP + de benodigde software (virtualbox) bv. is zo klein dat deze snel in het werkgeheugen kan worden geladen (vanaf een externe HD, daarna HD ontkoppelen). De opstarttijd zal wel ongeveer 2 minuten langer zijn. LLM (geldt ook voor XP) start schoon (malwarevrij) op. Pas als het internet wordt gebruikt kan een besmetting in het werkgeheugen optreden maar dit zal weinig effect hebben zolang er verder niets op de computer is aangesloten. Een eventuele besmetting (incl. 0-day) verdwijnt bij een herstart. De kans op een besmetting is klein en de zekerheid van een schone start is groot. Gebruik een (oude/overbodige) computer zonder interne HD. Updates en (virus)scans zijn niet nodig. Natuurlijk is dit niet voor iedereen een ideale oplossing maar misschien ontstaan er zo nieuwe ideeën.

NIET op de manier waarop het bij M.E.Doc gegaan is!!
Immers Microsoft gebruikt in tegenstelling tot M.E.Doc wel gesignde updates. je kunt Windows Update niet zo gek
krijgen dat ie een door jouzelf gemanipuleerde update installeert op een schone Windows PC.
Pas als je de secret signing key van Microsoft weet te achterhalen dan kun je zelf updates maken die door Windows
Update gezien worden als OK. Dat kan dus NIET op de manier zoals het bij M.E.Doc ging: de computer van de klanten
verleiden om een update ergens anders vandaan te halen dan ze normaal doen, of een server waar updates op staan
stiekem voorzien van verkeerde updates. En als Microsoft dit een beetje goed voor elkaar heeft is die key ergens
heel veilig opgeborgen in een speciaal apparaat.

En inderdaad, met https heeft het niks te maken. Dat maakt het niet of nauwelijks veiliger omdat er veel te veel
partijen zijn die zelf certificaten kunnen uitgeven die een gebruiker zomaar zal accepteren.
Zelfs de "Staat der Nederlanden" kan dat! Dus die kan zonder problemen inbreken op een https verbinding. maar
een Windows Update uitbrengen kunnen ze niet.

Helaas is dit niet waterdicht:

1) Microsoft heeft ongetwijfeld meerdere "secret signing keys" (private keys), anders zouden ze van 1 locatie afhankelijk zijn om bestanden te kunnen ondertekenen. Sowieso worden bestanden de laatste tijd met zowel SHA1 als SHA256 ondertekend, dus 2 certificaten met waarschijnlijk niet dezelfde private key. Maar diversiteit is hier sowieso verstandig: stel dat MS slechts 1 private key zou gebruiken en aanvallers weten die te kopiëren (of de HSM (Hardware Security Module) te stelen) waarna het bijbehorende certificaat moet worden ingetrokken, dan zouden alle productieprocessen stoppen tot "de key" vervangen is, een proces dat ongetwijfeld procedures kent en dus tijd kost. Een ander probleem is de impact op reeds gesigneerde bestanden; je kunt een certificaat tijdgebonden intrekken, d.w.z. alle signatures vóór datum en tijd X blijven geldig. Echter als het de aanvaller vervolgens ook lukt om time-stamp signatures vóór die datum te zetten, wordt malware alsnog als safe gezien. Het veiligste is dus volledig intrekken van zo'n certificaat, maar dan zouden ineens alle door Microsoft ondertekende bestanden als kwaadaardig worden gezien en zou geen enkele Windows PC meer opstarten!

2) Waarschijnlijk zitten die keys in HSM's en wordt fysieke diefstal enorm moeilijk gemaakt. Maar als aanvaller hoef je geen private keys in handen te hebben als je jouw malware simpelweg door een "build straat" (waarin sources worden gecompileerd, gelinkt, evt. van andere resources voorzien en evt. samengesteld tot installatiebestanden) kunt loodsen! In elk geval van Adobe is zo'n incident gepubliceerd, maar dit komt vermoedelijk veel vaker voor.

3) Ik vermoed dat Windows Update (op PC's) niet uitsluitend Microsoft code signing certificaten accepteert. Want dan zou het een drama worden als Microsoft's PKI infra gecompromitteerd zou raken. Het nadeel hiervan is dat aanvallers ook andere dan Microsoft code signing certs kunnen inzetten om malware, als ware het een Microsoft Update, te injecteren (maar dan denk ik eerder aan targeted attacks op kleine schaal).

4) Ook Microsoft maakt soms gebruik van software ontwikkeld door derde partijen waarvan je ook maar moet afwachten of die hun zaken goed voor elkaar hebben.

5) Bij Microsoft en toeleveranciers werken zwakke schakels (mensen) die o.a. via fouten, onkunde, misverstanden, bedreiging, chantage of ordinaire hebzucht roet in het eten kunnen gooien.

6) Windows updates worden verspreid via http. Als het je lukt om malware van een geldige digitale handtekening te voorzien, is het een koud kunstje om deze in update verbindingen te injecteren (mits je daar toegang tot hebt).

7) Microsoft's certificate revocation zuigt. Direct na opstarten vragen Windows PC's via http om revocation informatie en geven daarbij de versie mee die ze op dat moment hebben. Als de server helemaal niets of "unchanged" terugmeldt, is Windows tevreden. Zowel de aanvraag als antwoord kunnen door een aanvaller (met toegang tot de verbinding) worden vervalst of geblokkeerd. Overigens hebben aanvallers geen fysieke toegang tot de gebruikelijke verbinding nodig als zij DNS en/of routing kunnen manipuleren.

8) Aan code signing heb je weinig tot niets als je er niet op kunt vertrouwen dat de leverancier niet allerlei informatie vanuit jouw systeem wegsluist met onbekende transportbeveiliging, om wellicht niet volledig bekende redenen en met 1 of meer onbekende (eind- en tussendoor-) bestemmingen.

9) Microsoft heeft Authenticode bedacht. Daarmee kan een bestand een geldige handtekening blijven houden ook als het signing certificaat allang verlopen is. Vereist daarbij is een gesigneerde timestamp. Ik begrijp waarom, maar het zou mij niet verbazen als Windows nu nog bestanden gesigneerd met MD5 en 1024 bit RSA keys accepteert mits de timestamp maar "oud genoeg" is. Een timestamp die vermoedelijk ook met MD5/RSA1024 ondertekend mag zijn (en dus relatief eenvoudig vervalst kan worden). Ondersteuning van oude crypto ondermijnt beveligingssystemen vaak aanzienlijk.

Kortom, hoewel code signing, secure boot etc. kunnen helpen om de integriteit van systemen te beschermen, bieden ze slechts beperkte garanties, kunnen tot denial of service leiden (mede doordat niet bootende PC's waarschijnlijk een groter risico vormen voor Microsoft dan gegevensdiefstal van, of ransomware op, jouw PC) en zijn vaak helemaal niet zo moeilijk te omzeilen als de meeste mensen denken. En geven daarom vaak een vals gevoel van veiligheid. Helaas is het allemaal niet zo simpel, en complexiteit zou wel eens vijand nummer 1 kunnen zijn...