Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 86 reacties
Submitter: player-x

Er is een exploit opgedoken die een recent ontdekt veiligheidslek in Mac OS 10.10 misbruikt. Door het veiligheidslek is het mogelijk om software te installeren zonder dat de gebruiker er toestemming voor heeft gegeven.

De exploit maakt misbruik van een lek dat vorige maand werd ontdekt door beveiligingsonderzoeker Stefan Esser, meldt Ars Technica. In Mac OS 10.10 heeft Apple een nieuwe omgevingsvariabele, DYLD_PRINT_TO_FILE, toegevoegd aan de dynamic linker, bedoeld voor het loggen van informatie naar een specifiek bestand. De variabele werd echter niet op de gebruikelijke manier toegevoegd aan de dynamic linker, waardoor deze niet checkt of er bepaalde rechten nodig zijn om een gekozen bestand te openen.

Mac OS 10.10 dyld opent log file zonder checks

Onderzoekers van Malwarebytes ontdekten malware die een systeembestand aanpast zodat het de Vsearch adware kan installeren zonder dat er toestemming van de gebruiker nodig is. Hoewel het lek al wel gedicht is in de beta-versies van Mac OS 10.11, is het lek nog steeds aanwezig in de laatste beta van Mac OS 10.10.5.

Mac DYLD_PRINT_TO_FILE exploit

Maandag berichtte Wired over de nieuwe Thunderstrike 2-worm, een proof-of-concept die meerdere kwetsbaarheden in Mac OS X gebruikt om zich te verstoppen in de firmware. De twee lekken zijn niet gerelateerd. Apple zou inmiddels verschillende kwetsbaarheden, die gebruikt worden door Thunderstrike 2, hebben gedicht en de onderzoekers zullen op de Black Hat-conferentie meer informatie vrijgeven.

Moderatie-faq Wijzig weergave

Reacties (86)

Er is een patch door de onderzoeker gemaakt.
en de gemiddelde gebruiker is daar wat mee? Apple hoort het te dichten natuurlijk :-). een patch gemaakt door een hacker, ga ik trouwens niet installeren, hoe dan ook.

@SPT

een beveiligingsonderzoeker is volgens mij ook een hacker ;-)

[Reactie gewijzigd door white modder op 4 augustus 2015 16:20]

Hacker = software ontwikkelaar, hooguit met een ander doel.
Een software ontwikkelaar die ook nog een beveiligingsonderzoeker is, is prima te vertrouwen, veel patches die de laatste tijd voor verschillende gaten zijn gebruikt komen van hackers.

Afhankelijk van hoe belangrijk beveiliging is voor jouw situatie kan je prima beargumenteren dat je kiest voor de oplossing van een hacker zolang er nog geen officiŽle patch uit is.

Zo was de de patch voor Heartbleed, gemaakt door beveiligingsonderzoekers/hackers van Google, al meer dan twee weken beschikbaar voordat deze via de officiŽle kanalen beschikbaar kwam. Veel bedrijven hebben toen gekozen voor "een patch gemaakt door een hacker".
Hacker = software ontwikkelaar, hooguit met een ander doel.
dupy in 'nieuws: Hackers zetten inloggegevens van BitDefender-klanten online'

In dit voorbeeld is de hacker een crimineel die geld wil afpersen van een bedrijf.

De term hacker wordt te pas en onpas gebruikt, voor ethische maar ook criminelen. door dit gebruik wordt het moeilijk een onderscheid te maken tussen wie nu goed onderzoekend bezig is en wie crimineel.
Je hebt in de software wereld termen voor dat soort hackers, White hat hackers zijn hackers die voor bijvoorbeeld beveiligings bedrijven werken en actief bezig zijn om lekken te vinden en te sluiten. daartegenover heb je Black hat hackers deze zijn over het algemeen bezig met lekken te vinden en daar misbruikvan te maken.
Dat zijn dan ook geen hackers maar crackers
Hacker = software ontwikkelaar,
Dat is erg kort door de bocht, behalve dat er ook genoeg hackers zijn die zich totaal niet met software bezig houden, is het net als een iemand die zijn huis verft gelijkstellen aan een kunstschilder.
Natuurlijk kan een software-ontwikkelaar ook een hacker zijn, en sommige hackers kunnen ook software ontwikkelen, maar over het algemeen proberen hackers juist dingen te doen met software waar de software nooit voor bedoeld is, eigenlijk dus wat de ontwikkelaar van de software nooit heeft kunnen verzinnen of voor ogen had.
OsX 10.10 wordt vervangen binnenkort door OSX 10.11 el Capitan.
En het artikel zegt dat Apple al wat gedicht heeft:
Apple zou inmiddels verschillende kwetsbaarheden, die gebruikt worden door Thunderstrike 2, hebben gedicht en de onderzoekers zullen op de Black Hat-conferentie meer informatie vrijgeven.
En in de tussentijd maar hopen dat het goed gaat?
En wat met de Apples die later of niet naar 10.11 gaan? Hoe lang ondersteunt Apple 10.10?
Totdat 10.12 uitkomt. Apple ondersteunt altijd 2 versies (met een enkele uitzondering waarbij oudere versies toch nog een security patch krijgen).
Apple ondersteunt 3 versies, zo krijgt Mountain Lion nu ook nog gewoon security updates.
Er komt sowieso nog ťťn grote update voor 10.10 aan. Verder zullen er nog minstens tot 10.12 uitkomt veiligheidsupdates uitkomen. Gewoon je updates in de gaten houden dus.
Hacker = software ontwikkelaar

Elke echte hacker kan sofware ontwikkelen,niet elke software ontwikkelaar is een hacker of heeft bij lange na niet de mindset en of kennis.
software ontwikkelaar is ook een heel breed begrip.

Basic:
10 hello world
20 goto 10

Ben ik nu software ontwikkelaar ?

Denk dat je een hacker eerder kan omschrijven als iemand die de fouten van andere in software opspoort. Afgezien dat je kennis van software moet hebben gaat jou kennis c.q inzicht verder dan de doorsnee software ontwikkelaar die fouten maat die hij/zij niet gezien heeft en jij wel.
Nee, je bent het PRINT statement namelijk vergeten ;)
|:( :O geen software ontwikkelaar dus
De patch is gemaakt door een beveiligingsonderzoeker, wat toch wel iets anders is dat zomaar een hacker. Ga hem zelf ook nog niet meteen installeren, maar als het aantal infecties toeneemt is het in elk geval fijn dat deze patch beschikbaar is.

De beveiligingsonderzoeker in kwestie is met naam en toenaam bekend, en werkt voor een bedrijf in Keulen. Het blog waar in dit artikel naar wordt verwezen staat zelfs op de website van zijn werkgever. Er is geen enkele reden om aan te nemen dat dit ICT-bedrijf de patch zou gebruiken om malware te verspreiden. Ze zouden bovendien aansprakelijk zijn voor de daardoor veroorzaakte schade, het zou dus financieel meteen hun einde betekenen. Als we alleen maar wisten dat de patch door een hacker was gemaakt was het heel wat anders geweest, hackers heb je namelijk in alle soorten en maten.

[Reactie gewijzigd door SPT op 4 augustus 2015 18:40]

Beveiligingsonderzoeker is de term die veel white-hat hackers zich aangemeten hebben vanwege de over het algemeen negatieve bijsmaak van de term hacker. Er zit ook feitelijk geen verschil in, zowel een beveiligingsonderzoeker als een (computer-)hacker gaat op zoek naar gaten in de beveiliging van systemen.
Ik installeer hem wel, want ik heb de source gelezen en die is prima. Verder gaat apple het natuurlijk gewoon dichten, maar niet op dezelfde manier en ook niet vandaag nog. Dat wordt eerst ontwikkeld, getest en nog extra gecontroleerd. Dat kost tijd, bijvoorbeeld 1 dag, of 2. Of misschien wel een week.

Verder is het leuk dat jij het niet gaat installeren, "hoe dan ook", maar je baseert het eigenlijk op niks, behalve misschien een onderbuikgevoel op basis van angst en onwetendheid ;) Niet negatief bedoeld hoor, maar dat is waar de meeste standpunten van mensen vandaan komen.
Dat jij de code kan lezen wil niet zeggen dat iedereen dat kan. De rest is dus onwetend over de betrouwbaarheid. Dat heeft niets met onderbuikgevoelens te maken. Het is een gezonde houding in een zaak als deze. Niet domweg installeren.
Dus met andere woorden: je kan niks installeren als je de code niet kan lezen. Dat is wat je nu zegt.
Ik kan mij voorstellen dat sommige Apple gebruikers niet willen wachten op Apple. De hacker heeft netjes een installer (PKG) gemaakt en verder valt in de source code niets raars te zien behalve dat het de exploits tegenhoudt :)
en de gemiddelde gebruiker is daar wat mee?
Jazeker, je klikt op de link die z1rconium en je installeert the pkg of dmg, gaat precies hetzelfde als elk andere installatie. Uiteraard alleen doen als je Stefan Esser ook vertrouwd.
Apple hoort het te dichten natuurlijk :-)
Jazeker, maar kunt nu Apple voor zijn als je wilt, als het gedicht is natuurlijk niet vergeten deze patch weer te in-installeren.
Er zijn anders voldoende agenten die een slot kunnen open priegelen.
Hacker is niet 'iemand die iets kraakt', dat is een cracker. Een hacker is iemand die iets op een manier gebruikt waarvoor het nog niet bedacht was.
Er zijn genoeg corrupte agenten of agenten die op andere manieren de mist in gaan. Dus nee, het is geen onzin.
Blijkbaar is het lek ook niet aanwezig in El Capitan.
Niet nodig, men vergeet te melden dat de lek pas van kracht is als je software installeert uit een onbetrouwbare bron die er misbruik van maakt.

Kortom of je bent als gebruiker al risicovol bezig en aanvaard je de gevolgen.
Om onbetrouwbare software te installeren dien je ook de standaard beveiliging aanpassen en permissie geven. Ik mag hopen dat je als gebruiker daar op attent bent.
Als je daar op moet hopen dan weet je dat het mis zal gaan. De mogelijkheid is er en veel gebruikers doen maar wat. Dat is bij Apple gebruikers niet anders dan bij Windows gebruikers.
Op het moment je die handelingen verricht ben je al op de hoogte gebracht.
Het is eigen risico als je uit onbetrouwbare bronnen wil installeren en dat kan je het OS niet kwalijk nemen.
Voor wie zich zorgen maakt:

Voor beide vulnerabilities geldt dat het vooral gevaarlijk is voor mensen die de default instelling hebben veranderd die een ondertekende binary vereist. Als je 'Allow apps downloaded from anywhere' / ' Sta programma's toe die zijn gedownload vanuit elke willekeurige bron' aan hebt staan (en dus Gatekeeper hebt uitgeschakeld) loop je een risico. Daarmee wordt iedere binary die op wat voor manier dan ook op je machine terecht komt (dubieuze USB stick, drive-by download van een website, vulnerability in een third-party app of plugin etc.) toegestaan om code uit te voeren. Staat het uit dan is het risico aanzienlijk kleiner tot nihil.

Even controleren en indien nodig terugzetten naar de default dus. In ieder geval tot de patch (voor de eerste vulnerability) en de firmware update (voor de tweede vulnerability) er is.

[Reactie gewijzigd door Maurits van Baerle op 4 augustus 2015 16:45]

Ten eerste vraag ik me af of deze optie wijzigen invloed zal hebben op het lek, ten tweede voel ik me nogal beperkt als ik deze schakelaar niet uitzet want zelfs de meest (voor mij) simpele tools die ik gebruik als developer krijg ik niet actief zonder deze optie uit te zetten.
Voor beide problemen geldt dat er code uitgevoerd moet worden. Als jij het uitvoeren van niet-ondertekende binaries blokkeert wordt het ineens een stuk lastiger. Zomaar een binary op een systeem smokkelen (bijvoorbeeld door een lek in een browser of in Flash) en uitvoeren zal niet meer lukken. Het aanpassen van een bestaande binary om code uit te voeren zal ook niet werken omdat de ondertekening dan niet meer klopt. Er zijn nog wel wat aanvalsmethoden denkbaar maar je verkleint het risico toch wel met minstens 90%.

Wat je tweede punt betreft. Je kunt dan nog steeds niet-ondertekende apps gebruiken, je zult ze alleen eerst moeten goedkeuren. Met Gatekeeper aan krijg je een melding dan een app niet uitgevoerd kan worden omdat hij niet ondertekend is. Daarna ga je naar 'Security' en geef je voor die specifieke app aan dat hij wel uitgevoerd mag worden. Vanaf dat moment wordt het voor die specifieke app onthouden (en wordt er vermoed ik eigenlijk ook een hash bijgehouden zodat hij niet door malware aangepast kan worden).

Ik heb zelf gewoon Gatekeeper aan en moet af en toe alleen even Gatekeeper leren dat die ene applicatie wel te vertrouwen is. Het is prima te doen. Tegelijkertijd weet je dat je gewaarschuwt wordt als er een ineens ongevraagd een app wil opstarten die je niet kent (en die dus waarschijnlijk niet erg fris is).

Tegen Trojans doet dit natuurlijk niets omdat je zelf willens en wetens Trojans vertrouwd maar het is een flink stuk beter dan niets.

[Reactie gewijzigd door Maurits van Baerle op 4 augustus 2015 17:03]

Top, wist niet van het verlenen van toestemming. Zo een typisch iets wat je een keer tegenkomt als je nieuw bent op OSX en vervolgsns nooit meer naar omkijkt (en bij een nieuw product/verse installatie al de oplossing op denkt te weten)
Die hoef je alleen bij het installeren en 1e keer openen te wijzigen en erna kan je het weer terug zetten.
Als developer zou je moeten weten dat je meer opties hebt en hoef je je ook helemaal niet beperkt te voelen.
Hoe kom je er bij dat het voor het tweede lek (die firmware worm) iets uitmaakt wat jij in de software hebt ingesteld? Hooguit voor de eerste infectie... maar daarna gaat de worm volledig via firmware, ůůk naar andere computers! Het OS komt daarbij helemaal niet meer aan bod! Maar omdat Mac gewoon dezelfde firmware gebruiken als (windows) pc's zijn ze net zo blood gesteld hieraan.
Voor de verspreiding maakt het niet meer uit, voor de besmetting wel. Door Gatekeeper aan te houden kun je de kans op besmetting enorm verkleinen. Gatekeeper is een goede voorzorgsmethode tot de firmware update uit is.

[Reactie gewijzigd door Maurits van Baerle op 4 augustus 2015 17:42]

Je kunt alleen de software besmetting via een malware van internet verkleinen... Maar niet de firmware besmetting via een aangekoppelde ethernet adapter, of USB stick, of SSD drive. En dat is het bijzondere van deze worm!

Aangezien er vooralsnog geen beveiliging tegen is, is dit potentieel heel erg gevaarlijk! Wie heeft er nog nooit een USB stick/drive van een ander gebruikt, of een adapter geleend? (Vooral Mac gebruikers lenen constant adapters van elkaar, omdat ze hun eigen adapter vergeten zijn!)
Dat klopt uiteraard. Maar, als malware via hardware dus al in het wild verspreidt raakt zal dat aanzienlijk minder snel gaan dan via internet. Er zal een fysieke component nodig zijn.

Risico=kans*gevolg. Het gevolg is ernstig maar gelukkig is het risico een stuk kleiner dan via een internet verspreiding. Daarom moet je je dus ook beveiligen tegen internetbesmetting, zeker voor dit probleem.

Totdat de patch uit is kun je jezelf hiermee dus redelijk beschermen. Zeker als je bedenkt dat het, wegens de fysieke component, wel maanden kan duren voordat de malware jou bereikt.
niet helemaal waar,

Als je python applicaties gebruikt en of andere scripting applicaties. Dan zou de exploit ook in het script geplaatst kunnen worden. Terwijl er geen ondertekening nodig is.

App ondertekening is alleen voor .app applicaties niet voor scripts..

Dus als iemand geleerd heeft om Sickbeard te gebruiken. die via een deamon werkt. en een nieuwe versie krijgt.. Wordt deze gewoon geŁpdatet.. Sterker nog. als ik in die module dan de code verwerkt en laat starten bij gebruik.. dan ben je de sjaak..
Als je zeker bent dat je nu nog niet "gehackt" bent kan je een md5-sum nemen van /etc/sudoers en regelmatig vergelijken.

Checken of je niet gehackt bent kan je eventueel doen door in een terminal volgende uit te voeren (case sensitive):

grep PASSWD /etc/sudoers

Als je enkel lijnen terug krijgt die beginnen met een # is het OK, deze lijnen zijn een comment en worden immers genegeerd. Ik krijg bijv. deze feedback wat OK is:

# %wheel ALL=(ALL) NOPASSWD: ALL

Als je hier volgende ziet staan (vervang user door jou gebruikersnaam) EN je weet niet waar het vandaan komt, zou het wel eens kunnen dat je het zitten hebt, al is het geen sluitend bewijs. Ik zou lig niet tevreden zijn met zulke lijn.

user ALL=(ALL) NOPASSWD:ALL


Maar dus, stel dat je niet gehackt bent, je ziet geen verdachte NOPASSWD lijnen, dan kan je een fingerprint (md5sum) nemen van het kwetsbare bestand /etc/sudoers.

In de terminal type je dan iets in de zin van onderstaande:
md5 /etc/sudoers > ~/sudoers_md5.txt

Als je dan later wil checken of je bent gehackt kan je in de terminal de md5 sum van /etc/sudoers opnieuw berekenen en meteen in dezelfde regel een 2e opdracht geven om het eerder gemaakte bestand te printen (... && cat ... ):
md5 /etc/sudoers && cat ~/sudoers_md5.txt

Als het goed is zou je dus 2x exact dezelfde regel moeten krijgen. Als je twee verschillende md5sums krijgt moet je gaan zoeken hoe dat komt maar is dus de kans bestaande dat er met /etc/sudoers geknoeid is.


Als je nog een stap verder wil gaan, kan je ook volgende commando uitvoeren in een terminal:

sudo chflags uchg /etc/sudoers

(voor de niet terminal kenners, je paswoord wordt gevraagd maar je ziet geen feedback, lijkt alsof je niets aan het typen bent)
Dit maakt het kwetsbare bestand "immutable". Dat is een "flag" of eigenschap die je het bestand meegeeft waardoor het niet kan worden gewijzigd, zťlfs niet door root (Administrator van Windows zeg maar)! Probeer maar visudo te doen na bovenstaande commando, dat zal niet werken (Operation not permitted). Om bovenstaande commando terug om te draaien, geef volgende commando in:

sudo chflags nouchg /etc/sudoers

Let wel: als je /etc/sudoers immutable maakt, kan je mogelijk later problemen krijgen, stel dat een update of OS upgrade veranderingen moet doorvoeren aan /etc/sudoers, verwacht dan maar moeilijkheden mocht de immutable flag nog altijd aanstaan. Dus voor een upgrade sudo chflags nouchg /etc/sudoers.

En als je je verder wil verdiepen in het topic kan je nog altijd de manpages raadplegen in de terminal:
man -k sudo
man sudoedit
man sudoers
man visudo

{EDIT}
Kan ik code maken in een post hier? Dat kan het al iets gemakkelijker leesbaar maken.
{/EDIT}
{EDIT2}
correct autocorrect (noch > nouchg)
{/EDIT2}

[Reactie gewijzigd door bucovaina89 op 4 augustus 2015 19:33]

Wat ik niet in het bericht zie staan is of het ook in de normale versies voor kan komen, of dat dit alleen in de beta versies zit. Iemand die dit weet?
Volgens ArsTechnica zijn op het moment alle versies kwetsbaar behalve 10.11 (beta).
Mogelijk wordt de fix ook in de final van 10.10.5 opgenomen, dat is nog onduidelijk.

Overigens wordt er bij de comments van Ars wel een opmerking geplaatst dat deze kwetsbaarheid alleen gebruikt zou kunnen worden wanneer iemand Gatekeeper heeft ingesteld op alle bronnen toestaan. Beetje vergelijkbaar met Android waar je apps buiten de store om kan installeren.
Volgens mij is alles voor versie 10.10 niet kwetsbaar voor het eerste probleem. De vulnerability is er namelijk pas in 10.10 ingeslopen. Kortom, de kwetsbaren zijn alle versies van 10.10 tot en met de een-na-laatste 10.11 beta.

De tweede kwetsbaarheid is volgens mij OS-onafhankelijk. Daar is het vooral een kwestie van de updates in te gaten houden en wachten op een firmware-update die het oplost. In de tussentijd voorzorgsmaatregelen treffen.

[Reactie gewijzigd door Maurits van Baerle op 4 augustus 2015 16:22]

Dit is natuurlijk een belangrijk detail dat velen zullen vergeten in de komende reacties met "zie je nu wel dat een Mac ook niet veilig is"
Staat er inderdaad niet expliciet in, maar ik maak er van dat 10.10 kwetsbaar is, de 10.10.5 beta ook, maar de 10.11 beta niet.
it is already fixed in the first betas of OS X 10.11, it is left unpatched in the current release of OS X 10.10.4 or in the current beta of OS X 10.10.5.
nvm

[Reactie gewijzigd door Me_Giant op 4 augustus 2015 16:47]

Mac OS is toch Unix based... daar kon zoiets toch niet gebeuren ? (althans dat was het antwoord dat ik altijd las als er weeral eens een lek in Windows zat).
En het is op een standaard Mac installatie ook niet mogelijk is. Je moet je Mac in een kwetsbare mode zetten voor dit kan gebeuren.
Apple biedt blijkbaar die mogelijkheid/instelling aan en dus zijn zij verantwoordelijk voor dit lek en kun je dus niet zomaar de gebruiker de schuld geven als hij die instelling aanpast.
Volgens die redenering is Apple (of MS in geval van Windows) ook verantwoordelijk voor alle programma's die je installeert, want tenslotte zijn zij degene die het toelaten om het te installeren...
Er is een verschil tussen een instelling in het OS en een programma van een andere partij, ik neem aan dat je dat verschil zelf ook ziet.
Neemt niet weg dat jou vergelijking ook nergens op slaat. Als iets instelbaar is, is het altijd op eigen risico. Neem side-loaden op Android, als jij dat toestaat, heb je kans op rotzooi apps te installeren van malafide partijen, waardoor die ook weer rotzooi kunnen installeren. Is dat dan de schuld van Google? Nee, het is een feature die standaard uit staat, en jij inschakelt met het idee dat je weet wat je doet, waarom zou je het anders inschakelen?
De gebruiker zou toch eerst software moeten installeren uit onbetrouwbare bron. Dat is de verantwoordelijkheid van de gebruiker zelf net als in de materie verdiepen voordat je iets blindelings doet.
Of er wordt een andere bug in een bestaande applicatie misbruikt die code executie als jouw gebruiker mogelijk maakt, om vervolgens deze local root exploit uit te voeren.
Een dijk kan nog zo sterk zijn, je hebt maar 1 persoon nodig die er een gat in boort om er doorheen te kunnen kijken en je hebt alsnog een lek.
Het is de eeuwige discussie tussen gebruiksvriendelijk en beveiliging. Als ik puur even naar de afgelopen 20 jaar kijk, is veiligheid van een OS voor het gros van de computer gebruikers (helaas) niet de hoogste prioriteit.

Om het even in context te plaatsen, het veranderen van het startmenu naar het startscherm was voor meer mensen een reden om naar alternatieven te kijken dan welke exploit dan ook. Daarnaast betwijfel ik of Unix based systemen wel degelijk zoveel veiliger zijn dan Windows systemen. Heartbleed en Shellshock tonen aan dat ook Unix systemen niet onfeilbaar zijn.

Voor Android komen ook steeds meer exploits en virussen uit. Hoeveeel moeite er wordt gedaan om een systeem te penetreren hangt dus vooral af van de gebruikers aantallen. Nu 80% van de telefoons op Android draait en patch management op Android vrijwel non-existent is, zie je dat Android steeds vaker doelwit van hackers is. Net zoals Windows dat al jaren is.. Daarnaast is Microsoft al jaren bezig om haar gebruikers op te voeden.

Maar wat gebeurde er in 2007 toen Microsoft Windows dicht timmerde? Iedereen begon steen en been te klagen over de UAC schermen welke continue om toestemming bleven vragen. Microsoft promoot actief Secure Boot en iedereen valt over Microsoft heen.

Al met al kan ik heen andere conclusie trekken dat security voor de massa van ondergeschikt belang is. Om radeloos van te worden...
Het grootste gros van de ellende die op Android te installeren is, komt vooral door het Side-loaden, niet bewust door bugs ik de Unix kernel. Meestal onvoorzichtigheid door zomaar APK bestanden van internet te plukken of trappen in die neppe popups die melden dat je telefoon vatbaar is. M'n vriendin had dit ook, kreeg ook meermaals de melding dat haar telefoon onveilig zou zijn, maar dat zijn sites die je met een pop-up een APK bestand proberen te laten downloaden.
Maar da's niet eerlijk, want Windows zonder third-party (java, flash, pdf, etc) ook veilig. Applicaties welke je uit de store installeerd kunnen Windows ook niet kapot maken (allemaal user-space apps). Het is het zelf installeren van software buiten het zicht om van Microsoft (wat in feite natuurlijk ook gewoon sideloading is) wat voor de meeste exploits zorgt.

En of je nu klikt op een geinfecteerde attachment van een email of op een nep popup maakt natuurlijk niet zoveel uit vanuit security oogpunt.

Feit is dat Android net als Windows het ene gat na het andere moet repareren. En waar Microsoft tenminste nog het fatsoen had om Windows XP ruim 15 jaar te onderhouden, bied Google alleen patch support voor de laatste major Android versie. Bugs uit de 4.x serie worden niet meer gerepareerd.

Stel je nou eens voor dat Microsoft morgen zou stoppen met support voor Windows Vista, 7 en 8 en roept dat je maar gratis moet upgraden naar Windows 10 als je een veilig OS wilt. Ik denk dat de wereld dan te klein is. Toch komt Google met precies hetzelfde wel weg. En jullie (Android bezitters) accepteren dat gewoon..
Je hebt gelijk wat betreft het Android patch/update gebeuren. (Hoewel dit op de Nexus echt wel beter geregeld is dan op die van andere fabrikanten).
Maar het ging me even om het side-loaden. Als jij dit inschakelt, dan doe je dit voor een reden, en weet je waar je mee bezig bent, anders ga je niet klakkeloos schakelaars omzetten. Dat side-loaden zorgt ervoor dat je geen signed geneuzel nodig hebt om alles vrij te installeren wat je wilt. En dat is de grootste probleem factor.

Vergeet niet, de gebruiker is altijd de zwakste schakel. De grootste oorzaken van dergelijke infecties, is meestal omdat de gebruiker trapt in valse popupjes ("Let op, je telefoon is geÔnfecteerd, gebruik deze app om dit op te lossen"; *klik*), e-mail attachments vermomd als PDF die een zogenaamde PDF reader willen installeren die niks meer dan malafide acties installeert en volledige permissies vraagt, waar meer dan de helft van de gebruikers altijd maar op OK drukt. Dan nog altijd gratis apps willen die via torrents binnen gehengeld worden, vrijwel gegarandeerd om rotzooi binnen te halen, trojaans paard. Ga zo maar door.
Maar de gebruiker is inderdaad het probleem. Linux heeft natuurlijk altijd in een niche hoek gezeten en degene welke met Linux werkte waren ook altijd security minded. Nog steeds wordt Linux binnen bedrijven ingezet als IT infrastructuur zoals firewalls, gateways, mail, dhcp, etc.

Echter met de komst van Android en OSX zijn unix-achtige OS-en eigenlijk richting de consument gepushed. En bij de consument wringt de schoen, want de consument wil zonder onderbrekingen alles kunnen doen, terwijl de software op zijn machine dat eigenlijk niet zou kunnen.

Eigenlijk zou het OS alleen netwerk calls vanuit UI threads moeten accepteren by default. Maar da's lastig, want je wilt geen long-running processes op de UI thread omdat je dan UI freezes krijgt (daarom werken we met events en async code zodat de UI responsive blijft.

Overigens kun je in de Group Policies aangeven dat Windows alleen digitaal ondertekende executables mag uitvoeren. Dat is namelijk vooral een corporate feature, maar het is op zich wel een eenvoudige methode 'vreemde' applicaties op je systeem te weren. Natuurlijk is AuthentiCode op zich ook geen garantie dat je geen rommel kunt krijgen (een AuthentiCode certificaat kost ongeveer 250 dollar), maar als je het combineert met een publisher whitelist kun je alle software welke niet ondertekend is met een certificaat uit je whitelist meer draaien..

Echter gaat het te ver om dat te activeren voor de gemiddelde consument. Want dat zou betekenen dat je niet meer Chrome of Firefox zou kunnen draaien, omdat die programma's niet digitaal zijn ondertekend. Bedrijven welke een eigen AuthentiCode certificaat hebben, kunnen vervolgens zelf executables ondertekenen. Moet je alleen niet vergeten om de auto-update feature voor en registry aanpassen uit te zetten, omdat anders je nieuwe versie niet ondertekend is en dus weigert te starten.. Als je een dergelijk policy op machine niveau zet, dan kan zelfs een enterprise administrator op zo'n PC onvertrouwde applicaties installen, danwel starten. En dat is zelfs op Unix systemen niet mogelijk.

Maar je ziet dat soort procedures steeds vaker in middelgrote- en grote bedrijven.

Wat betreft sideloading en je aanname dat de gebruiker welke dit toestaan weet wat hij/zij doet. Die is onjuist, het internet staat vol met (video) tutorials hoe je sideloading op Android activeert en apps uit alternatieve appstores kunt installeren. De gebruiker wil gewoon die ene app installeren welke niet in de Google Store staat. Dat is de motivatie om sideloading te activeren. Want ik denk dat het gros van dergelijk tutorials helemaal niet informeert over de mogelijk veiligheids implicaties.

De mens neemt vanuit zijn natuur meer risico dan goed voor hem is. Je zou dit weekend eigenlijk eens naar de lokale EHBO post moeten gaan en je zult verbaasd zijn over de stupiditeiten welke mensen uithalen.. Risico's welke zeer gemakkelijk voorkomen hadden kunnen worden door bijvoorbeeld het even het trapje te verplaatsen. Weleens een fail compilatie gezien? Hoeveel van die fails had men kunnen voorkomen?

De massa gaat hetzelfde om met de veiligheid van zijn computers vanuit de gedachte dat hij/zij niet vatbaar is voor exploits, virussen of andere malware. Dat het hem/haar niet zal overkomen..
Gelukkig is de afgelopen 10 jaar de beveiliging voor de OS makers wel een prioriteit geworden. Windows zit bijvoorbeeld zeer goed dicht de dag van vandaag en we zien daar dat de meeste beveiligingsfouten uit third-party applications komen (flash, acrobat, java, ...). Maar de zwakste schakel blijft de eindgebruiker die zomaar alles aanklikt en waarschuwingen negeert.

Unix based systemen hebben al langer een cultuur van beveiliging dan Windows, hoewel ik persoonlijk ook de veiligheid van Windows op een gelijkaardig niveau inschat als de meeste andere besturingssystemen.

Toen Vista met UAC kwam was dit een zeer slecht afgestelde technologie. Je kon niet eens de klok op je systeem aanpassen zonder toestemming te geven en als je pech had dan vroeg Windows je meer dan 1 keer om toestemming om 1 eenvoudige taak te doen. Met Windows 7 werd UAC al beter uitgebalanceerd, maar voor sommige gebruikers was het toen al damage done en gaat UAC onmiddelijk uit na een verse installatie.

Secure boot daarentegen heeft een andere reden.De meeste malware houd je daar niet mee tegen. Waarom is MS dan afgekomen met Secure boot? Om cracks zoals de Windows 7 loader (die tijdens het boot process de nodige certificaten injecteerde) tegen te kunnen gaan.
Een klok aanpassen is dan ook een systeem (bios tijd) aanpassing, dus het is volkomen terecht dan niet iedereen dat zomaar kan. Onder Linux kun als user zonder root- of wheel rechten ook niet de tijd aanpassen. Bij de meeste desktop systemen moet je dan alsnog het root wachtwoord opgeven..

SecureBoot zorgt ervoor dat er in principe geen bootloader zonder signature geinstalleerd kunnen worden. Als SecureBoot in het bios is geactiveerd, dan kun je daarna gewoon prima Linux op dat systeem installeren. Alleen als je dan vervolgens vanuit Grub zou proberen om Windows te starten, dan weigert die omdat de bootloader niet ondertekend is.

Partities aangemaakt in Windows met SecureBoot kun je dan ook niet buiten Windows mounten.

Op zich is dat een goede methode om te voorkomen dat geinfecteerde bootloaders (welke malware inladen voordat het OS zelf is geladen) op je bootsector kunnen nestelen..

UAC in Vista was zeker niet perfect, maar de insteek was wel goed. Standaard kun je namelijk helemaal niets en heb je voor veel taken elevated rights nodig. Grote bedrijven gebruiken eenzelfde tactiek voor hun group policies. De standaard policy zet alles dicht en vervolgens koppelt maakt men meestal per user group een policy waarmee men weer bepaalde zaken opzet.

De beveiligings cultuur van Unix-achtige OS gebruikers is vele jaren veel beter geweest (en misschien nog wel zo) dan die van de Windows gebruiker, maar ook Unix heeft rare security kronkels. Onder Unix kan een bestand maar aan 1 gebruiken en/of groep worden gekoppeld. Moet het bestand door twee verschillende groepen ingelezen worden, dan ontkom je er niet aan om deze world readable te maken en mogelijk zelfs world writeable. ACL securities zijn pas ten tijden van PAM gekomen.

Gelukkig kijken alle OS-en tegenwoordig veel meer naar de concurrentie dan vroeger. Unix systemen hebben een grote inslag gemaakt op corporate niveau, terwijl Windows vooral op stabiliteit en gebruikers beveiliging grote slagen heeft gemaakt.

Zelfs ben ik een groot voorstander van hybride IT oplossingen waarbij men met een mix tussen Unix en Windows een sterke een goede bedrijfs omgeving kan neerzetten. Beide hebben een sterke- en zwakke punten, maar gecombineerd vullen ze elkaar zeer goed aan. Maar dat is alleen mogelijk als je binnen je organisatie (systeem)beheerders hebt welke de wereld niet in zwart-wit bekijken..
Het probleem in de discussie is dat iedereen zwart-wit en lineair denkt: Windows heeft veel gebruikers dus daarom is het een doelwit, en daarom is het onveilig. Daarmee wordt gesuggereerd dat Windows zelf er niets aan kan doen, het is slachtoffer van zijn eigen success. En zo ook met Android.

Dat is de lineaire weg. Echter, meerdere dingen kunnen tegelijkertijd waar zijn. Zo kan Windows meer lekken kennen omdat er meer aanvallers zijn, maar ook omdat het een bepaalde technische architectuur heeft. Beide dingen kunnen tegelijk waar zijn, en elkaar versterken.

Ik ben er wel degelijk van overtuigd Dat Unix achtige systemen tov Windows veiliger van opzet zijn. In den beginne was Windows een single user, no network OS waarop zowel de enige gebruiker als alle software letterlijk alles kan en mag. Later is dit met duizenden pleisters veranderd, maar nog steeds is dit de cultuur. Unix daarentegen is vanaf de kern opgebouwd op basis van multi user, non-admins, permissies, en networking.

Ik weet het, dit is een ernstige vereenvoudiging van de waarheid, maar er zit een kern van waarheid in. Unix, Windows en Android (wat je eigenlijk geen Linux kloon mag noemen omdat de lagen erboven zeer dik zijn) zijn allemaal anders ontworpen. Unix is vanaf het begin security minded, Windows pas sinds 10 jaar, en Android eigenlijk nog steeds niet.
Ik denk dat daar net het probleem zit. Als ik het goed begrijp hebben ze zich bij een eigen uitbreiding van die dynamic linker niet aan de standaard gehouden. Geen idee wat hier precies gebeurd is en in hoeverre die dynamic linker nog UNIX-afgeleid is maar als ik manager was zou ik hier een uitgebreid onderzoek naar eisen. Die linker is feitelijk de basis voor alles wat systeemlibs gebruikt, dus alle executables. Die wil je hoe dan ook in orde hebben.
Ik weet niet waar je dat gelezen hebt maar Unix varianten hadden al beveiligingsproblemen voordat Windows 1.0 Łberhaupt bedacht was.

Wat overigens niet wegneemt dat het ontwerp van Unix bepaalde aanvalsvormen minder waarschijnlijk maakt dan op Windows.
Nee wat je hebt gelezen is dat er geen virussen voor OSX zijn, en dat klopt nog steeds (als in de definitie van een virus). Dit is een exploit, daar zullen nog genoeg mogelijkheden voor zijn, op elk systeem.
Heb even gegoogled. Ondanks dat het aantal virussen zeer gering is (tientallen, niet de duizenden die er in omloop zijn voor Windows) zijn ze er wel. Zo te lezen voornamelijk trojans. Maar een trojan werd in het DOS-tijdperk al als virus aan gemerkt, dus ik neem aan dat dit nu niet anders is ;)

Dus helemaal gelijk heb je niet: maar veilig is OSX zeker. Gebruik zelf naast Windows ook Linux-systemen: op die laatste gebruik ik ook geen antivirus. De besmettingskans is zo gering dat het risico te aanvaarden is t.o.v. de system-resources die een anti-virus anders gebruikt (en de kosten van aanschaf en up-to-date houden).
Strikt genomen is een trojan geen virus. Een virus verspreidt zichzelf en doet dat in principe zonder op te vallen. Een Trojan daarentegen wil juist wel opvallen omdat hij bewust door een gebruiker gedownload en geactiveerd moet worden. Alleen lijkt een Trojan van buiten op een nuttige applicatie, vandaar de naam.

Cisco: 'What Is the Difference: Viruses, Worms, Trojans, and Bots?'

De correcte verzamelnaam is 'malware'. Daaronder vallen virussen maar ook wormen, trojans, bots etc. Alle virussen zijn malware maar niet alle malware is een virus.

[Reactie gewijzigd door Maurits van Baerle op 4 augustus 2015 16:41]

Not sure of trolling or.. Niets is feilloos.
Stefan Esser heeft ook een SUIDGuard kernel extensie gemaakt die dit misbruik van DYLD_PRINT_TO_FILE afvangt bij SUID executables, dat is i.i.g. een tijdelijke fix tot de patch van Apple er is. Hiermee krijg je een bericht in je system log i.p.v. root toegang :P

edit: spuit11 :')

[Reactie gewijzigd door Sfynx op 4 augustus 2015 16:25]

Maandag berichtte Wired over de nieuwe Thunderstrike 2-worm, een proof-of-concept die meerdere kwetsbaarheden in Mac OS X gebruikt om zich te verstoppen in de firmwire. De twee lekken zijn niet gerelateerd. Apple zou inmiddels verschillende kwetsbaarheden, die gebruikt worden door Thunderstrike 2, hebben gedicht en de onderzoekers zullen op de Black Hat-conferentie meer informatie vrijgeven.
Wat me na wat rondgooglen niet echt duidelijk is is of dit dezelfde kwetsbaarheden zijn van de eerdere Thunderstrike of echt nieuwe bugs... voorzover ik weet had Apple namelijk het hele Option ROM gebeuren en het lokale firmware herschrijven (pre- 2014 retina) al dicht gezet op de diverse modellen.
Volgens endgadget:
This is the second Thunderstrike exploit to target Macs. The first version was fixed with OS X 10.10.2 and required the hacker to have physical access to the computer. This new version is more nefarious because the malware can be delivered via a link. The latest OS X security update (10.10.4) seems to keep the exploit from taking hold.
Voor degene die ook twijfelen aan waarom newgrp nodig is:
https://security.stackexc...ulnerability-work-on-os-x
Tsja, gebruik van Macs blijft groeien. Dan komen er ook meer virussen.
Laat je niet foppen door het "Macs zijn inherent veilig" verhaal.
Linux was ook oh zo veilig. En kijk Android nu.

Het is DE reden waarom sysemen veilig zijn: Ze worden minder gebruikt.
Daarom is BSD ook zo veilig.
osx is baseerd op BSD...
OS X heeft een mach kernel die BSD based is. De rest van het OS is voortgekomen uit het next project van Steve Jobs. Om te zeggen dat heel het OS dan maar BSD based is, is wel heel simpel. Dan kon je 15 jaar terug ook stellen dat Windows gebasseerd was op MS DOS hoewel DOS alleen maar gebruikt werd om Windows op te kunnen starten.
De eerste malware voor Macs was er al in 1984.
Het is en blijft onzin te beweren dat Mac's minder geviseerd omdat ze een kleiner aantal zijn. Bij Mac's is er nooit een overwicht geweest in marktaandeel dus valt het niet te bewijzen maar iOS heeft ooit een dominant marktaandeel gehad en was toen vele malen groter dan Android. Waar denk je dat de minste virussen of malware te vinden was? Jawel op het dominante iOS. iOS had amper een handvol trojans terwijl het onbeduidende marktaandeel van Android al direct duizenden virussen te vinden waren.

Vergeet de security by obscurity myth. It ain't real!
Wel eens van architectuur gehoord?
Het zit echt niet in de aantallen, maar in architectuur en beheer/onderhoud/kennis.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True