" wat betekent dat als code niet gesigneerd is dat deze niet (zonder meer) wordt uitgevoerd." in het geval van remote code execution door middel van een buffer overflow is dit niet waar. OSX controleert alleen het programma alvorens het uit te voeren. Wanneer er dmv een buffer overflow code word geïnjecteerd aan een al draaiend process, zoals bij shelcode vaak het geval is, word dit niet tegen gehouden.

- Je hebt een webserver op je Mac die PHP draait, versie van PHP is niet echt relevant in deze.
- PHP heeft functies genaamd eval(http://www.php.net/eval), exec(http://php.net/function.exec) en shell_exec(http://www.php.net/shell_exec).
- eval() voert in principe alleen PHP code uit.
- exec() stelt PHP in staat om externe programma's uit te voeren vanuit een PHP script. exec() kan ook output van het uitgevoerde commando returnen.
- shell_exec() kan commando's naar je shell/terminal/commandline sturen. Ook hier kan de output weer door PHP worden ge-returned.

Maar hoe kan een aanvaller dan commando's sturen via jouw PHP script? Stel, je hebt het volgende script:

<?php
$output = shell_exec($_GET['input']);
echo $output;
?>

Dit scriptje heet voorbeeld.php. Als ik dus naar jouw server ga en http://jouwserver/voorbeeld.php?input={commando hier} uitvoer, dan kan ik, afhankelijk van onder welke rechten PHP draait, commando's uitvoeren.

En zeg nu zelf, hoe leuk zou het zijn als ik vanuit jouw PHP script een curl commando ingeef die mijn eigen (malicious) PHP scripts op jouw server kan downloaden. Ik zet ze dan zelf wel in de goeie map middels het cp commando, en als ik nog tijd over heb kijk ik nog even rond op je systeem voor wat grappige informatie :-)

Geeft dit je een idee van wat er mogelijk is? Er zijn nog veel meer mogelijkheden hoor, in andere talen, middels exploits, buffer overflows en meer.

Cheers,
Florian

In je post haal je zo te zien twee begrippen door elkaar :

'reverse shell'
en 'shellcode'

Nu gaan die vaak in combinatie, maar het zijn verschillende dingen.

Wat is een reverse (TCP) shell :

Normaal log je in op een shell (telnet, of SSH) door een TCP connectie te maken naar een server met het telnet of ssh proces, en dan log je in.
Maar zelfs de meest simpele firewall houdt vaak die inkomende sessie tegen.

Wat kun je dan doen : Als de computer waarop je wilt inloggen zelf een sessie naar buiten opzet, kun je over die sessie ook verkeer terug sturen. TCP is twee weg, tenslotte.
En als dat retourverkeer in inlog sessie is, kun je dat een reverse shell noemen.

Je hebt dus iets of iemand nodig aan de binnenkant die de sessie opzet, en aan de kant waar de sessie uitkomt is ook wat nodig.
Het is (als SSH portforward, en reverse portforward) een standaard feature van SSH. Maar met wat werk kan het ook met andere protocollen.

Zie bijvoorbeeld
http://toic.org/blog/2009/reverse-ssh-port-forwarding/

Technisch iets er tegen doen, als beheerder van een firewall, is een wapenwedloop tussen welke sessies je naar buiten toestaat, en hoe goed je die protocollen inspecteert.
SSH kan ook over poort 80 of over poort 443 .
TCP kun je tunnelen via HTTP (als payload in html content), of puur via SSL, of zelfs via DNS of ICMP.

dns of icmp tunnels zijn natuurlijk lage bandbreedte en hoge latency. Genoeg om 'werken' op de kantoorpc te vervelend te maken.
Met voldoende strakke controle over werkplek endpoints kun je natuurlijk ook veel reverse tunnels onmogelijk maken.

En shellcode is een stukje code wat je injecteert (vaak via een buffer overflow) en wat als resultaat een shell op de target computer geeft.
Als je dat kunt combineren met een reverse tcp sessie kun je als aanvaller dus binnenkomen op een computer die achter een firewall staat waar inkomende sessies geblokkeerd worden.

Met alle respect, maar dit is geen voorbeeld van een shell_code. dit is een voorbeeld van een php bestand commando's naar het systeem stuurt.

Shellcode is een set instructies die direct in het geheugen van de machine wordt geinjecteerd. Bijv. door een buffer overlfow kwetsbaarheid uit te buiten en zou direct jou instructie in het geheugen te schrijven.

Shellcode is vaak opgebouw uit bijv. ASM of op deze manier:

"\x6c\x6e\x08\x3c\x74\x65\x08\x35\xec\xff\xa8"

een uit te voeren instructie kan zijn, luister op een bepaalde poort naar een verbinding (shell) of maak over een bepaalde poort verbinding met een eerder opgegeven IP adres.

Om het risico te beperken dat bepaalde shellcodes hun doel bereiken kun je maatregelen treffen, w.o. de firewall juist te configureren. Hanteer whitelisting voor zowel ingaande en uitgaand verkeer, standaard blokkeer je dus al het inkomende en uitgaande verkeer en ga je daarop de uitzondingen toevoegen die je nodig hebt om te werken. Dit zal je niet 100% beschermen tegen reverse_tcp shells, maar de beperkt de mogelijkheden voor de aanvaller tot de door jou open gezette poorten of verbindingen.

Misschien handig om eens goed te lezen, ik heb het over shell_exec, dat is iets heel anders dan shellcode.

Kijk, het doel is dat je toegang krijgt op een andere machine. Bijvoorbeeld doordat die andere machine een verbinding naar jouw computer maakt en je een shell presenteert. Dat is redelijk omgekeerd vergeleken met jij maakt een verbinding en krijgt een shell gepresenteerd. Daar komt dat hele "reverse tcp shell" vandaan.

Nu dan jouw vraag, hoe krijg je dan die andere machine zo ver dat'ie dat doet? Dat valt eigenlijk buiten de definitie van dit ding; je gaat ervanuit dat als je dit kan bewerkstelligen je dan dus op d'ene of d'andere manier die andere machine kon overtuigen dat te doen. Dat is dus een aanname die je doet als je over deze truuk praat. Hoe er te komen is een apart onderwerp.

En hoe dan? Nou, remote code executie is wel makkelijk om dit te kunnen doen. En hoe je dat dan weer doet, ach, daar zijn duizendeneen verschillende mogelijkheden voor. Maar daarvoor is dit ding een mogelijk einddoel, en dus is voor dit ding die exploits een middel om het te lanceren. Als je doel en middel niet verwart ben je denk ik een stuk sneller op weg naar de materie begrijpen.

1e reactie Ts


Ja, het fenomeen Buffer Overflows heb ik ook voorbij zien komen.
Het issue van de Buffer overflows (voor Mac OS X) is ruim beschreven in diverse papers en presentaties door Charlie Miller tot en met ongeveer 2008. Na 2008 zijn er zowel nieuwe versies van Mac OS X als versie updates verschenen waarin dat mogelijk (?) door Apple is verholpen.

Bij een buffer overflow en injectie in een draaiend proces is het meest voorkomende voorbeeld daarvan een draaiende webbrowser.
Je browser is voor computergebruik tegenwoordig elementair en denk ik ook als het gaat om beveiliging van je systeem bijna belangrijker dan het Os zelf. Een browser zal in de eerste plaats (het makkelijkste ?) target zijn voor het exploiteren van kwetsbaarheden.
Kwetsbaarheden in de browser voor buffer overflows zijn voor rekening van de maker deze te verhelpen middels patches.

Dat maakt mede daarom dat ik nooit fan ben geweest van sterk in het Os geïmplementeerde browsers. Niet van Internet Explorer op Pc en niet van Safari op Mac OS X. Laat staan het gebruik van Safari onder oudere Mac OS X versies die niet of minder worden ondersteund door Apple.

Charlie Miller heeft meermalen een overzichtje gegeven welke processen kunnen worden geopend middels Safari, dat zijn er nogal wat. (of dat nog steeds zo is kan ik niet beoordelen maar ik vermoed dat het er niet minder op is geworden gezien de hang naar integratie, onder meer met social media, daar waren ze al vroeg bij overigens).

Miller Quote :


("bh-usa-07-miller-WP.pdf")

In het kader van de uitvoer van code hoef ik denk ik niet specifiek nader toe te lichten welke applications uit deze lijst mijn aandacht hebben.

Buffer overflow dus, destijds stelde hij al dat dit -laten we zeggen- een vrij lastig probleem is om te voorkomen bij een poging daartoe.
De vraag is om dit ook een aannemelijke aanvalstactiek is met een directe connectie poging via shell op het ip adres waarachter je computer zich op dat moment bevindt.

Nogmaals; welke functionaliteit binnen OS X wordt aangeroepen om commando's uit te voeren?
Terminal.app?
Ik neem namelijk aan dat het plaatsen van (al dan niet verborgen) directories niet compleet met remote commando's kan plaatsvinden.

- - -


Nee, ik heb geen php server draaien. Maar de aanwezige (server) functionaliteit onder OS X is mij inderdaad ook al eens eerder opgevallen.
Perl/Python/Apache, … ik heb mij al meerdere malen hier afgevraagd naar aanleiding van (misbruikte) Java functionaliteit of Python functionaliteit ook niet nader bekeken moet worden (bekijk voor de grap maar eens de complete tutorials die in de LibreOffice.app verborgen zitten voor Python scripts).
Weet niet hoe kwetsbaar het is wanneer je het niet gebruikt.
Heb niet het idee dat dit heel scheutig meegaat in de updates van Apple.

Wel heb ik gekeken (loopt nog) naar aanleiding van Zeus Malware (ja ik weet het voor de Pc en niet voor Mac OS X maar het had toch mijn interesse) wat php functionaliteit en scripts kunnen doen bij bezoek aan een webpagina en hoe php functionaliteit te blocken.
Daar had ik overigens wel een maffe oplossing / workaround voor gevonden.
Kan praktisch zij als je niet bijvoorbaat een bepaalde website vertrouwt en deze toch wil bezoeken, blokkeer je php functionaliteit.
https://www.security.nl/posting/373906#posting373936

Anyway, tot zover de php (server) functionaliteit.

- - -


Ja dat idee heb ik ook, roep ik ook al jaren hier (firewall gebruiken, whitelisting gebruiken).
Desnoods twee firewalls gebruiken (?), één voor het blokkeren/toestaan van specifieke ip-adressen of web-adressen.
Eén voor whitelisting voor het geval dat de andere firewall ze per ongeluk doorlaat, je een foutje hebt gemaakt of omdat het een 'hels karwei' is preventief voor alle mogelijke programma's en processen een firewall rule aan te maken.
Werk iets niet omdat de verbinding is geblokkeerd kan je tijdelijk of definitief een whitelist rule aanmaken.

Nadeel? Zorg?
De inkomende Firewall functionaliteit onder Mac OS X.
Na Mac OS X Tiger heeft Apple de Firewall gerestyled en versimpeld. Je kan alleen nog kiezen voor het blokkeren van inkomend of uitgaand verkeer, in plaats van allebei te definiëren.
Ik kan niet alle OS X versies overzien maar meestal heb je de mogelijkheid om je Mac in Stealth mode te zetten (wat denk ik niet helpt als die ander je ip adres al heeft en met shell bezig gaat).

Daarnaast kan je (kon je?) alleen kiezen voor het blokkeren van alle inkomende connecties met uitzondering van door Apple bedachte noodzakelijke functionaliteit. Welke dat dan betreft is weer niet helemaal duidelijk, dus is die beveiliging relatief en heb je toch weer een ander programma nodig om dat te monitoren.

Inmiddels
Ik had het over het hoofd gezien maar zag vandaag een artikel over firewall's van dezelfde persoon die ook iets geschreven had wat onder meer aanleiding van dit topic.
Daarom 'durf' ik nu wel de links hier te plaatsen.

Eerst zijn oplossing, het is er maar één (!), dat stelt mij nog niet gerust, ik wil nog steeds dit veld verkennen
(hoe werkt het nu, welke programma functionaliteit wordt er nu aangeroepen, Command Line / Terminal?) :

"Stopping Backdoors"
http://patrickmosca.com/stopping-backdoors/

Dan nu alsnog één geïllustreerd voorbeeld dat onder meer aanleiding was voor mijn vraag hier :

"OSX Backdoor – Persistence"
http://patrickmosca.com/osx-persistent-backdoor/

Verder zul je op zijn site ook nog materiaal vinden aangaande iSight.
De sinds december onderliggende reden van mijn onderzoek om een aantal zaken uit de destijds gepubliceerde iSight 'Hack' deels te weerleggen, van commentaar te voorzien en er oplossingen voor te noemen. Inmiddels hier en daar al deels gegeven.


* Firewall is dus een goede mogelijkheid (niet waterdicht voor inkomend verkeer ?).

* Hoe ver kom ik in dit geval met het 'sandboxen' van command line applications, voor de Mac de Terminal.app?
Op zijn minst dan uitgeschakeld onder standaard accounts en eventueel ook nog in haar geheel (meerdere manieren voor, ik kan na twee maanden experiment nog niet de mogelijke nadelige consequenties daarvan overzien).

Hartelijk dank voor de reacties tot zover alvast,
gestelde vragen blijven wat mij betreft nog steeds van toepassing
ben benieuwd.
TS


P.s., o,ja, uit het archief, programmaatje nooit getest (oud, 2006)
Laat eerst om toestemming vragen voor uitvoer van code Terminal.app

"Safe Terminal Version 0.3"
http://nirs.freeshell.org/safe-terminal/

Inderdaad goed lezen is belangrijk! In dat geval had je gelezen begrepen dat de vragen van de topicstarter vooral omtrent shellcode gaan en niet over de verschillende wijzes waarop een shell verkregen kan worden (waarvan het plaatsen, op welke manier dan ook, van een PHP backdoor variant een mogelijkheid is)

Ik vind reactie een mooi voorbeeld van hoe je een shell verbinding kunt opzetten door functionaliteit uit o.a. PHP te misbruiken maar ik denk dat de vraag van de topicstart toch meer gaat over shellcode gezien de context waarin hij zijn vraag stelt.

Mogelijk kan de stopicstarter dit toelichten ?

2e reactie Ts


Op het moment dat ik mijn eerste reactie schreef waren de volgende reacties nog niet in beeld :
24-01-2014, 12:13 door Anoniem / 24-01-2014, 13:55 door Anoniem

12:13 raakt in principe de kern van de zaak,
ik haal niet alleen zaken doorelkaar, sterker nog ; ik zwengel een topic aan dat wellicht veel meer kennis vereist dan ik heb (dummie :-0 ).

Dat krijg je dan van 'domme vragen'. ;-)
Of toch niet?
Ik hoopte eerlijk gezegd een vraag te stellen die op zich interessant is maar waarbij ik voor de oplossing 'volkomen afhankelijk ben' van de diepe kennis van zaken van anderen. (1)

Om enigszins verantwoordelijk om te gaan met vermoede kwetsbaarheid (heden) wilde ik niet zomaar met links gaan strooien. In eerdere reactie heb ik alsnog een link gegeven, namelijk :
http://patrickmosca.com/osx-persistent-backdoor/

Ik kan alleen maar hopen dat dit mijn vragen illustreert zonder daarbij dat verder te onderbouwen met technische kennis van de command line (die ik niet heb) en het opzetten van een verbinding of het binnendringen van een computer van een ander.

Het beste wat ik daarbij kan hopen is als degenen die wel de kennis hebben inhoudelijk hierover van gedachten wisselen met als resultaat een werkbare oplossing, of de conclusie dat er minder aan de hand is dan lijkt (?).
Ik krijg de indruk dat dit wel lukt gezien de reacties tot nu toe.

Het voorbeeld uit de link doet niet vermoeden dat de getargete gebruiker zelf meewerkt door een sessie op te zetten als gesteld (?) door 12:13 (mits ik het goed begrijp, 13:15 reactie is me veel te cryptisch wat vast aan mij ligt, dus daarop moet ik nog eens verder studeren, naast andere reacties).

Om het ten overvloede nog eens samen te vatten in eigen dummie taal.

Wat ik denk dat iedereen zou willen voorkomen is :

* dat een ander extern een '… sessie' opzet
* binnendringt om vervolgens taken uit te voeren die de getargete gebruiker niet door heeft en waar hij/zij het vast niet eens is
* desgewenst nog stiekem een remote verbinding opzet waarlangs 'vrolijk & stilletjes' data van de Mac (Win/Lin pc) verdwijnen.

Hacked by a pro? (2)
Nee, liever niet!
(niet op Windows, niet op Linux, en ook niet op de Mac).

Dank voor de reacties wederom.
Ts


(1) een eerdere meer algemene vraag sloeg niet aan,
https://www.security.nl/posting/375890/Security+%3A+Praktisch+nut+versus+Veiligheid+en+Privacy+%3F
meer to the point concreet gemaakt met nieuwe inzichten en info middels dit topic nu wel.

(2) Websearch : Hack like a pro

Thx. Ik ben de anoniem 12:13


Ik heb (summier) aangegeven dat de gebruiker niet bewust hoeft mee te werken.
Ik schreef 'iets of iemand' , en aan het eind dat de ook shellcode via een bufferoverflow het zou kunnen doen.
Dat 'iets' kan een exploit zijn (evt dus bufferoverflow en 'shellcode' ), wat op de een of andere manier actief wordt op een intern systeem.
Email, 'drive by exploit' op een website.
Of social engineering van de gebruiker. Feitelijk is iemand telefonisch overhalen een teamviewer sessie op te zetten ook een reverse shell. (maar geen 'shellcode' ) .

En 'shellcode' is een onderdeel van een exploit (vaak dus een bufferoverflow) waarbij een stukje code van de aanvaller uitgevoerd wordt binnen de priveleges en met toegangsmogelijkheden van de applicatie die ge-exploit is.

"Echter als je de meeste poorten dicht hebt zou dit ook kunnen plaatsvinden met gebruik van poort 80 of 443, dat zijn immers de poorten die iedereen wel open heeft. "

Kan theoretisch, maar dan moet de aanvaller wel eerst het process killen dat van die poort gebruik maakt (anders zet je die poort natuurlijk niet open op de externe firewall). Het gaat over inkomend verkeer. Je kunt per poort ook alleen het protocol toestaan dat voor die poort toegestaan is. Een normale niet op HTTP gebaseerde shell op poort 80 kan dan niet werken.

Als je het zo aanpakt ben je slim bezig. Het is sowieso slim om er van uit te gaan dat je server gehackt wordt en vervolgens na te gaan hoe je het de aanvaller zo moeilijk mogelijk kan maken om data van waarde te verzenden.

Er zijn hele volksstammen die denken dat dit type van security, security by obscurity, slecht is en daarom niet toegepast mag worden. Maar dat is onzin. Het doel is niet het voldoen aan een onhaalbaar ideaal (het utopisch beveiligingparadigma van perfecte software en beveiliging), het doel is voorkomen van data lekkage. Ook in het geval dat de server wel gehackt is ondanks alle andere maatregelen om dat te voorkomen.

Shellcode op zich kun je voorkomen door programmatisch te hardenen. Er zijn libraries en (OS) instellingen die daarvoor te gebruiken zijn. Ze zorgen er idealiter voor dat de schellcode niet of niet effectief uitgevoerd kan worden.

De signature controle van de executable vind plaats tijdens het starten. Het signeren van executables kan shellcode niet tegenhouden. Shellcode draait (normaliter) als deel van een al toegestaan process op de server, na het succesvol uitvoeren van een exploit. Het overschijft een stukje geheugen. Als je middelen gebruikt die dat voorkomen, of die de juiste plaats van het invoegen van de code moeilijk te bepalen maken dan kun je mogelijk voorkomen dat de shellcode wordt uitgevoerd.

Dit is een startpunt voor meer informatie: http://en.wikipedia.org/wiki/Data_Execution_Prevention

Ik hoor bij die volksstammen die "security by obscurity" als principieel uitgangspunt en de werkwijze afwijzen.
De LOL is dat het gebruik van een wachtwoord of pin-code natuurlijk juist gebaseerd is op obscurity (van dat gegeven).

War het wringt:
Als PHP en andere tools nu eens niet neergezet zouden zijn op hoog access level (soms root) zou de hele kwetsbaarheid met bufferoverflows niet eens meer relevant zijn. Er kan niet meer gebeuren dat het level wat het PHP proces zelf toestaat op het OS en is dat als "niet risicovol" neer te zetten. ... no problem ... no worry...

Het zijn juist als die obscure achterdeurtjes en "krachtige mogelijkheden" die ons al die hack mogelijkheden geschonken hebben. Jammer want het was niet nodig. Nu hebben we dat monster losgelaten met de risico's van datalekken corruptie etc.. Nou goed er zijn er genoeg die zich er mee vermaken en ook werk aan hebben.

3e reactie Ts
(betrekking hebbend op een reguliere computer en niet op een server)


* Dus als je browser crasht heb je wel een indicatie omdat het een bekende truc is (bewust laten crashen).
Is het (alsnog) een goed idee om dan :

- direct te internet verbinding eraf te gooien?
- je browser (offline) in safe modus op te starten om het cache geheugen te legen?
- of zelfs je computer (offline) in safe modus op te starten om cache geheugens te legen, browser in safe modus op te starten, opstart items te controleren en desgewenst toegevoegde opstart items te verwijderen?
- hierna pas de computer normaal op te starten en daarna pas weer online te gaan?

* Wat betreft firewall beheer wordt er altijd gesproken over poortbeheer (welke blokkeer je voor welke programma's?) en of over white listing (welke programma's mogen überhaupt contact maken met het internet?).

- een combinatie lijkt me gewenst.
- ik mis nog een andere optie waarover volgens mij nooit gesproken wordt, namelijk ; apart en specifiek protocol beheer.

Een zoektochtje naar het aantal en soorten protocollen levert het volgende op
http://ftp.tw.freebsd.org/pub/branches/3.0-stable/src/etc/protocols
Dat zijn pakweg 255 protocol nummers waarvan een aantal nog niet toegewezen zijn.
Ik krijg de indruk dat de meeste protocollen daarvan voor standaard gebruikers niet relevant zijn er er pakweg een handvol overblijven, in ieder geval onderstaande 3 ?

* protocol nummer 6 , TCP
(voor een paar standaard poorten geopend, browsers, mail, enkele os-services)
* protocol nummer 17 , UDP
(in welke gevallen, voor welke services en over welke poorten toestaan is uitzoeken)
* protocol nummer 41 , IPV6
(wanneer je een ipv6 modem hebt of met ipv6 adressen wil communiceren, ideeën? Idem voor ipv4?)

- is het dan een logische/zinvolle gedachte om aan te nemen dat overige protocollen geblokkeerd kunnen worden (m.u.v. wat ipv6 extra's).

Protocollen opgesomd (alfabetische volgorde) :
3PC , A/N , AH , ARGUS , ARIS , AX.25 , BBN-RCC-MON , BNA , BR-SAT-MON , CBT , CFTP , CHAOS , Compaq-Peer , CPHB , CPNX , CRTP , CRUDP , DCN-MEAS , DDP , DDX , DGP , DIVERT , EGP , EIGRP , EMCON , ENCAP , ESP , ETHERIP , FC , FIRE , GGP , GMTP , GRE , HMP , HOPOPT , I-NLSP , IATP , ICMP , IDPR , IDPR-CMTP , IDRP , IFMP , IGMP , IGP , IL , IP-ENCAP , IPComp , IPCV , IPIP , IPLT , IPPC , IPV6-FRAG , IPV6-ICMP , IPV6-NONXT , IPV6-OPTS , IPV6-ROUTE , IPX-in-IP , IRTP , ISIS , ISO-IP , ISO-TP4 , KRYPTOLAN , L2TP , LARP , LEAF-1 , LEAF-2 , MERIT-INP , MFE-NSP , MHRP , MICP , MOBILE , MTP , MUX , NARP , NETBLT , NSFNET-IGP , NVP-II , OSPFIGP , PGM , PIM , PIPE , PNNI , PRM , PTP , PUP , PVP , QNX , RDP , RSVP , RVD , SAT-EXPAK , SAT-MON , SCC-SP , SCPS , SCTP , SDRP , SECURE-VMTP , SEP , SKIP , SM , SMP , SNP , Sprite-RPC , SPS , SRP , SSCOPMCE , ST , ST2 , SUN-ND , SWIPE , TCF , TLSP , TP++ , TRUNK-1 , TRUNK-2 , TTP , UTI , VINES , VISA , VMTP , VRRP , WB-EXPAK , WB-MON , WSN , XNET , XNS-IDP , XTP

- Welke uit deze lijst hebben dan het meeste prioriteit (of beter allemaal)?
- Uit te sluiten protocol nummers in ranges opgave mogelijk ?
0-5 , 7-16 , 18-40 , 42-252

- Hoe doe je dat dan concreet en effectief, als je geen extra firewall software hebt bijvoorbeeld? Ook via het host file?



Inderdaad

* Security by obscurity,
is geen vervanging voor standaard maatregelen die je tot je beschikking hebt.
Als je niet meer anders kan, door einde lifecycle van je Os kan het een noodzakelijke extra maatregel worden. Genoeg gebruikers te vinden die op oudere hardware en met een ouder Os werken volgens mij. (maar extra (obsucre?) maatregelen nemen, daar moet je zin in hebben of zelfs de lol van inzien ;-), koop anders toch maar een nieuw systeem, niets doen is in ieder geval geen goede optie lijkt mij

* Economisch aanpakken / denken,
behalve voor zeer specifiek gemotiveerde aanvallers zal het economisch argument (veel moeite doen) de doorslag geven.
Ik neem aan dat bij het pogen systemen te exploiten het een heel nuttige/economische aanpak is eerst alle bekende standaard (of eenvoudige) wegen te bewandelen.
Een script of file pad moet eerst gedefinieerd worden en is gebaseerd op de verwachting van de schrijver, obscurity zit in de weg bij standaard aannames en scripts.

* Homogeniteit versus Obscurity!
Je kan het zelfs omdraaien (dat argument hoor ik nooit)
Hoe groter de homogeniteit is hoe economisch aantrekkelijker het is als target (Niet voor niets dat nieuw geïntroduceerde Os-en en versies het zwaarst onder vuur liggen, kijk maar naar de Cve's in vergelijking tot de systeemversie release data).

Wanneer de grootste gemene deler up-to-date systemen betreft, heb je als aanvaller de zekerheid dat je simpele/gerichte methodiek voor die groep gaat werken vanwege de homogeniteit.
Hoe minder homogeen je target groep is (niet up-to-date, verschillende Os versies) hoe meer variabelen je moet inbouwen, des complexer het wordt en hoe minder economisch het daarmee is. ;-)

* "Expect the unexpected"
Obscure maatregelen op een systeem kunnen een aanvaller (hopelijk) voor de nodige complete raadselen stellen.
Echter ook voor gebruikers geldt een zekere economie (gemak, zucht,..) ; namelijk hoeveel moeite ben je bereid om te steken in een veilig systeem.
Dat is over het algemeen (te? / bar?) weinig : geen interesse en op basis daarvan,.. teken maar uit.
En als dat wel het geval is, dan zal het in een handig App'je verpakt moeten zitten.
Dat valt me ook hier keer op keer op. Op zich wel een economische zinvolle gedachte, App'jes en addons alleen zijn niet zaligmakend.
Maar goed.



* Ik kan alleen maar hopen dat je dat enigszins met de volgende maatregelen wat kan ondervangen in geval van vermoeden van een gecompromitteerd systeem.

- offline gaan
- safe boot / boot van een andere OS disk
- caches (en meer) schonen
- startup processen monitoren


???
Hoe zit het nu met het limiteren van permissies van command line functionaliteit / programma's ?
Zou dat helpen tegen een (nogmaals) benadering van buitenaf als beschreven in eerder opgegeven link
http://patrickmosca.com/osx-persistent-backdoor/

Of is deze vraag 'Not done' daar het een (veronderstelde) favoriete tool is van de meeste systeembeheerders?
Maar daar heb je met privé computers niet mee te maken.
Het lijkt me dat het onder standaard accounts overbodige functionaliteit is waarbij mogelijke root processen de functionaliteit nog steeds kunnen benutten .

Wie weet het en 'durft' (ook al is het je favoriete tool ;-) deze vraag (s.v.p.) wèl te beantwoorden?



* Buffer overflow is dus weinig tegen te doen (?), vertrouwen wordt het op de kwaliteit en support van het getargete programma zelf?
Dus met name de browsermakers die de kans op buffer overflows zo klein mogelijk maken?

* Limiteren van de permissies van je command line programma gaan zeker helpen tegen verborgen exploits / scripts in een file. Je hebt onder het standaard account waar je werkt de rechten niet om de applicatie te openen, dat heb ik inmiddels wel getest (niet met recente malware, die heb ik niet).

* Drive by downloads kan je zelf voorkomen op verschillende manieren .

De meest rigide (maar denk ik best werkbare) methode heb ik op deze site al meerdere malen aangekaart, het wil er niet in. Heb ik een verbod op / erecode voor gemist aangaande creatieve oplossingen?
Standaard Downloads folder op slot met permissies en definiëren in je standaard browser.
Tweede aparte browser erbij voor als je een keer iets wil downloaden met opgave van een andere voorkeur download folder.
Very simple (werkt in ieder geval in OS X).

Javascripts monitoren of tijdelijk uitschakelen helpt niet altijd. Geen maar toestemming met je No-Script en daar ga je weer.

* Exploits per email maatregelen zijn op zich bekend, maar wie past ze toe?

- weergave in plain text in plaats van html opmaak (jammer van de mooie nieuwsbrieven, zelden echt visuele kunstwerkjes)
- firewall blockingrules aanmaken voor emailclient connecties over poort 80 / 443 (en eigenlijk alle andere poorten die je niet nodig hebt) zodat een in html opgemaakte mail geen additionele files kan ophalen of connecties zoeken met foute servers op het moment dat jij de mail selecteert.
- links in een bericht niet aanklikken, eerst zorgvuldig controleren en je afvragen waarom je die link zou moeten aanklikken. Is het bericht echt wel afkomstig van een bekende?
- bijlagen, tja, dat weten we nu wel.
Blijft staan de methode van verstopte scripts in bestanden die je command line application openen, ...

- Social engineering is een veel gebruikte methode inderdaad.


Openstaand dus nog steeds

!* Kan de methode als beschreven in eerder opgegeven link?
http://patrickmosca.com/osx-persistent-backdoor/

!* Hoe plaatst de creatieveling in kwestie nu bestanden op de computer van de ander?
Of kan het 'gewoon' door te variëren op de ftp constructie (zoals met het plaatsen van een website op een server, gaat niet zonder wachtwoord trouwens) door bestanden te uploaden naar bepaalde directories op de computer van een ander?

Als het plaatsen van bestanden inderdaad 'zomaar kan' helpt denk ik alleen nog het op slot zetten van grote delen van je local user account libraries (waar er overigens inderdaad een heleboel van op slot kunnen, zonder merkbare nadelen, sommigen veranderen niet zoveel).
Daarbij ga ik er wel vanuit dat je niet onder je admin account werkt.


Mac tipje / ideetje dan nog :
I.g.v. van onzichtbaar geplaatste files en directories, kijk zelf hoe dat te doen voor je eigen Mac OS X versies.

In het Finder window (links) een extra snelkoppeling aanmaken.
Een snelkoppeling naar een zoekopdracht voor alleen invisible files binnen je local user library.
Wanneer geplaatst onder saved searches in je linker Finder window kan je af en toe eens kijken of er ineens rare verborgen files of directories zijn bijgekomen door even op de search te klikken en te sorteren op datum of soort. Diverse variaties op dit idee mogelijk.
Mocht je deze methode nog niet kennen.

Tja als men het over deze attacks heeft,dan praat men bijvoorbeeld niet over OSX maverics 10.9.1 wat nu de nieuwste versie van Het Mac operatingsysteem is.
Men kan hier niks over vertellen of deze attacks erop mogelijk zijn.
Ik denk dat Apple tegen deze attacks nu wel meer maatregelen heeft genomen,omdat er inde vorige versie van bijvoorbeeld Mountain Lion wel exploits makkelijker uitgevoerd konden worden.

Maar het begrip 'security through obscurity' als af te wijzen praktijk slaat helemaal niet op het geheimhouden van sleutels, wachtwoorden of pin-codes, het slaat op het geheim houden van ontwerp en/of implementatie van de beveiligingsmaatregelen. Het slaat bijvoorbeeld op een cryptografisch algoritme en de implementatie van dat algoritme in software, maar niet om de sleutels die je erbij gebruikt. Ik zie geen LOL, dus.
Je hebt het over aanvullende maatregelen, niet over het dwarszitten van een aanvaller als hij eenmaal op het systeem zit in plaats van robuuste beveiligingsmaatregelen. Daar is inderdaad helemaal niets mis mee, zolang je daarmee die robuuste beveiligingsmaatregelen niet uitschakelt of verzwakt. Het is mooi meegenomen als je een aanvaller op het verkeerde been weet te zetten met obscure aanvullende maatregelen, maar het zou tegelijkertijd heel dom zijn om te veel te vertrouwen op obscure maatregelen. Het is mooi meegenomen als ze effect hebben, maar de kans blijft aanwezig dat een aanvaller snel de weg weet te vinden op een manier die nooit bij jou was opgekomen, en dan betekenen ze opeens niets meer. Maar bij aanvallers die er wel intrappen is dat extra hobbeltje mooi meegenomen.

Ik heb ook wel eens meegemaakt dat verschillende mensen helemaal in een stuip schoten omdat een aanvullende maatregel als security through obscurity kon worden gezien. Het ging om het camoufleren van een SSH-poort via een mechanisme dat qua robuustheid lijkt op port-knocking. Ze reageerden alsof dat in de plaats kwam van de toegangsbeveiliging die onderdeel van SSH is. Alsof je opeens geen slot meer in je deur hebt zitten als je een klepje voor het sleutelgat hangt. Ik deed niets wat de beveiliging verzwakte, ik deed alleen iets dat massa's aanlogpogingen vanuit botnets uit mijn logfiles weerde (qua beveiliging kon het systeem het wel hebben, de aanvaller heeft niet zo veel aan het uitproberen van wachtwoorden als je alleen met een sleutel aan kan loggen). Dat is niet de kern van de beveiliging, het maakt wel de logbestanden overzichtelijker, waardoor onregelmatigheden beter opvallen.

Maar let wel: dat zijn aanvullingen op een basis waarvoor geldt dat 'security through obscurity' wel degelijk schadelijk is, het uitgangspunt dat het beveiligingsniveau niet afhankelijk mag zijn van onbekendheid met de details is essentieel voor een robuuste basis. Geheimen lekken namelijk nog wel eens uit, en terugkoppeling op denkfouten krijg je pas als anderen je denkfouten kunnen zien. Dat perfectie een utopie is mag dan wel zo wezen, maar de afkeer van `security through obscurity' is wel degelijk een van de drijvende krachten achter het zo goed mogelijk benaderen van die perfectie.