Wipe-functionaliteit Exchange kan worden misbruikt

De mogelijkheid in Microsoft Exchange om gekoppelde apparaten op afstand te wipen, kan via een man in the middle-aanval worden misbruikt. Op Android en iOS blijkt er nauwelijks controle plaats te vinden; Windows Phone is wel veilig.

"Het was echt heel simpel", zegt de Australische onderzoeker Peter Hannay in een interview met Tweakers.net op de Black Hat-beveiligingsconferentie. "Ik had niet verwacht dat het zou werken, ik was echt verrast." Met behulp van een eenvoudig, niet door een certificaatautoriteit ondertekend certificaat wist hij iOS- en Android-apparaten op afstand te wipen.

Daarvoor was het wel nodig om een man in the middle-positie te hebben, waarbij een aanvaller de controle over de internetverbinding van een slachtoffer heeft. Daarvoor zou bijvoorbeeld een draadloos netwerk kunnen worden opgezet dat zichzelf voordoet als een legitiem netwerk.

Daarnaast moet een apparaat een Exchange-profiel hebben. "Exchange biedt de mogelijkheid om aangekoppelde telefoons op afstand te wissen", vertelt Hannay. Door verbindingen met de Exchange-server te onderscheppen, kon hij 'slachtoffers' via het Exchange-protocol een wipe-verzoek sturen.

Hannay nam telefoons met Android, iOS en Windows Phone onder de loep; alleen Windows Phone bleek niet kwetsbaar. Onder Android werkte de exploit als de geconfigureerde Exchange-server zelf ook geen certificaat van een certificaatautoriteit had - iets wat over het algemeen wordt afgeraden. Maar, zegt Hannay: "Veel Exchange-servers hebben zo'n self-signed-certificaat."

Onder iOS kunnen ook telefoons die verbinding maken met een Exchange-server met een door een certificaatautoriteit uitgereikt certificaat om de tuin worden geleid, maar gebruikers krijgen dan wel een waarschuwing te zien. Uit de waarschuwing valt echter niet op te maken dat de telefoon op het punt staat zichzelf te wissen; de melding geeft enkel aan dat het certificaat niet klopt. "Veel mensen drukken dan gewoon op 'akkoord'", stelt Hannay.

De onderzoeker benadrukt dat de kwetsbaarheid hem niet zit in de Exchange-server, hoewel de authentificatie met Exchange iets geavanceerder zou kunnen. Het grootste probleem zit echter in de Exchange-implementatie van Android en iOS. Hannay heeft contact opgenomen met Microsoft, die Google en Apple op de hoogte heeft gesteld. Een fix is echter nog niet voorhanden.

Reacties (71)

In het artikel wordt telkens Exchange geroepen, wat in de basis natuurlijk klopt, maar het gaat meer specifiek om het ActiveSync protocol.

Nog specifieker gaat het over de implementatie van ActiveSync binnen Android en iOS. Aangezien Windows Phone geen problemen lijkt te hebben, gaat het hier waarschijnlijk over fouten die door Google en Apple zijn gemaakt. Het is ook nog eens dat het hier om 2 verschillende fouten gaat: op Android is het wissen direct mogelijk, bij iOS wordt er onvoldoende gewaarschuwd. De eerste is echt een onderliggende fout, de tweede is meer een UI misstap.

Uit de ActiveSync protocol specificatie:

There are no special security considerations specific to this specification. It is recommended that communication between the client and server occur across an HTTP connection secured by the Secure Sockets Layer (SSL) protocol.
When connecting to a server using SSL, clients are required to support server certificates that use the Subject Alternative Name for domain names, as specified in [RFC4985], as well as wildcard certificate names, as specified in [RFC2818] and [RFC3280].

Met andere woorden: zorg er zelf voor dat de boel veilig is, iets wat ik an sich wel kan begrijpen. Het is aan de ontwikkelaar om er zeker van te zijn dat de server waarmee gecommuniceerd wordt echt de server is die ze denken dat het is.

[Reactie gewijzigd door the_shadow op 27 juli 2012 09:23]

Op Android en iOS blijkt er nauwelijks controle plaats te vinden; Windows Phone is wel veilig.

Dat is een opmerkelijk iets. Apple en Google hebben beiden actief samengewerkt met Microsoft voor die functionaliteit, en ik heb geen enkele aanleiding om aan te nemen dat ze iets anders hebben gedaan dan de officiele specificaties van Microsoft te volgen.

Blijkbaar is er een specificatie die Microsoft intern gebruikt, die beter/veiliger is.

Het zou niet de eerste keer zijn dat microsoft incomplete data aanlevert voor dergelijke zaken, namelijk.

[Reactie gewijzigd door arjankoole op 27 juli 2012 09:00]

Wow van een implementatiefout door Apple (en google) in 3 zinnen naar MS is de boze wolf en het is hun fout. Really?

Het kan ook gewoon zijn dat de mensen bij Apple de specificaties fout hebben geinterpreteerd en dat op het punt van wipen de specificaties onduidelijk zijn over het wel accepteren als er geen certificaat is ingesteld (op zich niet geheel vreemd namelijk). Om nou meteen aan te komen met dan MS intern een andere specificatie gebruikt vind ik wel heel erg ver gaan.

[Reactie gewijzigd door Caelorum op 27 juli 2012 09:04]

Het kan ook gewoon zijn dat de mensen bij Apple de specificaties fout hebben geinterpreteerd

als het alleen bij iOS het geval was geweest: ja. Maar bij zowel Apple als Google? Waarbij in elk geval in de iOS variant Microsoft actief een bijdrage heeft geleverd?

Als het alleen Apple was geweest had ik 't niet gezegt. Maar dezelfde fout bij 2 verschillende bedrijven? Dat is meer dan verdacht. Zeker aangezien die 2 tech-giganten zijn.

Wow van een implementatiefout door Apple (en google) in 3 zinnen naar MS is de boze wolf en het is hun fout. Really?

Ja, microsoft is voor dit soort fratsen meerdere malen wereldwijd veroordeeld. Ze hebben alles behalve een schone reputatie op dit gebied.

[Reactie gewijzigd door arjankoole op 27 juli 2012 09:20]

Mij is nog wat meer opgevallen, de AutoDiscover functie van ActiveSync in Android is ook niet goed geimplementeerd. Er zijn 4 manieren voor de client om de juiste URL te vinden.
1. Test potential Autodiscover URL https://domein.nl/AutoDiscover/AutoDiscover.xml
(de bovenste mogelijkheid valt vaak al af omdat admins hier een website op hebben staan)
In dat geval gaat een ActiveSync client verder naar manier 2
2. Test potential Autodiscover URL https://autodiscover.domein.nl/AutoDiscover/AutoDiscover.xml
(Dit zal de meest gebruikte manier zijn door admins, helaas is het zo als je meer domeinen host op je exchange servers dat je een choas aan certificaten krijgt.
Om dit probleem op te lossen is optie 3 en 4 door microsoft het leven in geroepen.
namelijk,
3. Attempting to contact the Autodiscover service using the HTTP redirect method.
en de laatste manier
4. Attempting to locate SRV record _autodiscover._tcp.domein.nl in DNS.

Die laatste manier gebruiken wij en op android toestellen werkt dit gewoon niet. Op Windows Phone toestellen en Symbian met speciale client werkt het wel. Meer mensen hebben last van deze "bug" en waar het op lijkt na wat onderzoek is dat google simpel weg niet goed active sync heeft geïmplementeerd. Wat overigens een workaround is is een andere Exchange client downloaden voor android die wel volledig/goed active sync heeft geimplementeerd en maar deze kosten aardig wat geld. We hebben een aantal android telefoons met een betaalde client en daar werkt alles probleemloos.

Ik denk dus wel dat het een fout van Google is en niet dat microsoft intern een veilige code gebruikt.

Bij Android wordt kennelijk niet gedetecteerd dat het self-signed certificaat van de aanvaller anders is dan het certificaat van de geconfigureerde server, en daarop worden commando's als WHIPE kennelijk gewoon uitgevoerd.

Bij iOS wordt er wel gedetecteerd dat het certificaat niet klopt ("de melding geeft enkel aan dat het certificaat niet klopt"), geeft daarop een melding, maar begint dan alsnog met wissen.

Dat laatste is in mijn ogen nog kwalijker: je weet dat er iets niet klopt, maar doet er kennelijk niets mee. De fout die in Android zit, wordt, wat ik zo kan zien, veroorzaakt door simpelweg niet goed controleren.

De fratsen waar MS voor veroordeeld is, is het niet openbaar willen maken van de protocol specificaties. Dat kan je niet zeggen van Exchange en ActiveSync, hier zijn de specificaties direct van te vinden. Daar staat ook in dat het protocol niet zorgt voor veiligheid, maar dat de applicatie daar zelf voor moet zorgen. Als je als developer niet controleert of alles in orde is, dan ben je in mijn ogen ook niet helemaal goed bezig.

[Reactie gewijzigd door the_shadow op 27 juli 2012 09:33]

Wipen is een beveiligingsmaatregel. Certificaten zijn eenvoudig ongeldig te maken door de datum op je telefoon te veranderen of de betreffende root certificate te verwijderen. Zouden Apple en Google de specificatie volgen dan kan ik dus verhinderen dat de telefoon (die ik bijvoorbeeld gestolen heb) gewiped wordt door de datum ver in de toekomst te zetten.

Ik ben er nog niet helemaal uit, maar ik neig toch de fout/keuze van Apple en Google te prefereren boven de specificatie.

[Reactie gewijzigd door xnpu op 27 juli 2012 10:09]

Welke specificatie. Heb jij die gelezen? Het kan best zijn dat Microsoft een nieuwere versie van de specificatie gebruikt heeft voor de Windows Phone implementatie of Apple en Google bepaalde optionele features niet gebruiken.

Dat betekent niet dat bij Windows Phone het wipen onmogelijk gemaakt kan worden. Het enige wat hier gezegd wordt is dat Wipen van Android en iOS devices door derden via Exchange mogelijk is. Dat kun je niet zomaar omdraaien.

Het probleem is dat de Apple en Google applicatie bepaalde commando's accepteren zonder dat het bericht geauthenticeerd is via een geldig certificaat (ok er kan een foutmelding verschijnen). In de specificaties (http://msdn.microsoft.com...cc307725(v=exchg.80).aspx) is hierin voorzien (er wordt een certificaat gebruikt) maar als de controle niet (goed) gedaan wordt in de client apps van Apple en Google kan MS daar helaas helemaal niets aan doen. Geen geheimzinnige extra functionaliteit had hier iets aan kunnen doen, het is gewoon een klein foutje die MS blijkbaar niet gemaakt heeft.

Overigens is het niet vreemd dat applicaties de mogelijkheid bieden om ongeldige en self-signed certificaten te accepteren en bij de Google versie van de applicatie moet je er zelfs voor kiezen om zo'n certificaat te gebruiken voordat deze hack werkt en zelfs de Apple versie geeft nog een (wat cyptische) foutmelding.

Als laatste wil ik zeggen dat de wipe ook niet zo vreselijk is, alle e-mails worden van het mobieltje gewist maar zijn normaliter nog gewoon beschikbaar op de Exchange server en kunnen dus opnieuw gedownload worden. De server is immers niet gekraakt.

Conclusie: kleine implementatie fout/onduidelijkheid van Apple en Google, MS kan er niets aan doen en de impact en feasibility van deze hack is klein.

Je hele toestel word gewiped. Niet alleen het email gedeelte.

Ik ga ervan uit dat Windows Phone de specificatie netjes volgt. Vervolgens is het een kwestie van even proberen

dan kan ik dus verhinderen dat de telefoon (die ik bijvoorbeeld gestolen heb) gewiped wordt door de datum ver in de toekomst te zetten.

Waarom zo ingewikkeld. Als je toegang hebt op de telefoon hebt op dat niveau kun je toch gewoon een backup of kopie maken van de data?

?eh? Dus jij prefereerd een fout die het in principe mogelijk maakt om je telefoon remote te whipen terwijl je alleen maar een een extern netwerk contracteerd boven een niet bestaande fout in de specificatie.

Om je een voorbeeld te geven van hoe gevaarlijk deze fout is. Ik kan nu midden in amsterdam een gratis hotspot opzetten. Iedere Iphone of Android telefoon die daar aan connect en exchange heeft geconfigureerd wordt dan gewiped!

Los nog even van het feit dat je met je security policy kan instellen dat een telefoon moet locken and dus dat de dader niet bij de tijd instellingen kan werkt het verlopen van de certificaten niet zoals jij zegt. De spec zegt namelijk dat je het laatst gebruikte certificaat voor die sessie vast moet houden zodat je in het geval van een tijd/datum mis match nog wel een aantal cruciale instructies (zoals wipe) kan uitvoeren.

Ik heb zelf een keer het 'plezier' gehad om het protocol te implementeren en hoewel er veel iritiante zaken (zoals wbXML) inzitten zitten dit soort dingen specificatie wise echt goed in elkaar

Punt is dat het niet dezelfde fout hoeft te zijn bij beide bedrijven. iOS accepteert elk verzoek voor wipen blijkbaar, waar Android dat alleen doet wanneer er een geldig certificaat wordt meegegeven of er een willekeurig certificaat wordt meegegeven en er op de exchange server geen certificaat afgegeven is. Dat is IMO een behoorlijk verschil.

Dat haal ik niet uit de tekst, iOS vereist volgens mij wel een certificaat maar negeert het feit dat het niet goed is door alleen maar een melding te tonen aan de gebuiker.

Wat gebeurt er dan precies op Android? helemaal geen melding maar het wordt gewoon uitgevoerd? Want dat lees ik niet terug.

Wat mij verder bevreemd is dat het mogelijk is om de Wipe functie via Exchange te laten lopen, Apple bied zelf faciliteiten voor dit doeleind, waarom dan ook nog via Exchange?

Nu heb je het niet in de hand omdat je deels afhankelijk bent van een derde partij.

[Reactie gewijzigd door ronaldmathies op 27 juli 2012 09:45]

Over Android: "Onder Android werkte de exploit als de geconfigureerde Exchange-server zelf ook geen certificaat van een certificaatautoriteit had - iets wat over het algemeen wordt afgeraden". Verder is het normaal dat je kan wipen als het certificaat wel geldig is.
Van iOS was ik iets te kort door de bocht, wat ik bedoelde was dat iOS alle verzoeken accepteert tot wipen zolang er maar een certificaat aan hangt. Ze zijn dan wel weer zo vriendelijk om melding te maken dat het certificaat mogelijk niet geldig is, maar ze blokkeren het wipen niet.

Misschien nog met de kanttekening erbij dat je wel een certificaat van een certificaatautoriteit nodig hebt en dat elke android telefoon kan worden gewiped ook al gebruikt de exchange server een self-signed certificaat.

[Reactie gewijzigd door Caelorum op 27 juli 2012 10:20]

Het is wel zo handig als je als bedrijf zowel iOS, Android als Windows Phone telefoons gebruikt dat je die allemaal centraal kan beheren. Dat er dus partijen zijn die cross platform systemen aanbieden is dan ook niet vreemd.

Wat mij verder bevreemd is dat het mogelijk is om de Wipe functie via Exchange te laten lopen, Apple bied zelf faciliteiten voor dit doeleind, waarom dan ook nog via Exchange?

Het is een officieele eis van Microsoft om gebruik te maken van native activesync/exchange connecties.

Daarnaast heeft 't als voordeel dat een bedrijf dat eigelijk alleen Windows doet, niet ook nog eens een OS X Server hoeft aan te schaffen. iCloud heeft de mogelijkheid ook wel, maar bedrijven houden 't liever binnenshuis. (via icloud is niet centraal geregeld - voor ieder device heb je een andere account nodig in weze, en dus bijzonder onpractisch)

[Reactie gewijzigd door arjankoole op 27 juli 2012 10:56]

iCloud heeft de mogelijkheid ook wel, maar bedrijven houden 't liever binnenshuis. (via icloud is niet centraal geregeld - voor ieder device heb je een andere account nodig in weze, en dus bijzonder onpractisch)

Het is misschien niet iCloud maar Exchange is ook niet Hotmail: http://www.apple.com/nl/osx/server/#communication
Kan dus prima..

Apple bied zelf faciliteiten voor dit doeleind, waarom dan ook nog via Exchange?

Klopt maar is inderdaad een Active Sync vereiste. Overigens zijn bijna alle platformen en ook Android (zéér beperkt, m.u.v. Samsungs eigen implementatie) samen weer onder te brengen in een veel uitgebreider "Device Management": http://www.sybase.nl/prod...tab=TRY+%26+BUY&hid=80542

Ik zou een setting op mijn iPhone die de Exchange wipe functie blokkeert wel waarderen..

Onzin, Windows Phone laat standaard geen self signed certificaten OF certificaten signed door een CA die niet in de trusted store van de telefoon staat toe. Er word door Microsoft ook geen prompt gepresenteerd, dus zul je de rootCA of het self signed certificaat zelf in de trusted store van de telefoon moeten zetten.

Apple heeft er (ongetwijfeld bewust) voor gekozen om in dat geval de user te vragen om het certificaat te vertrouwen.

Die keuze heeft Microsoft niet gemaakt, je beschuldiging is dan ook totaal onzinnig

Ik kan me natuurlijk vergissen maar het doet me ook een beetje denken aan het windows mobile 6.0 en 6.5 verhaal. Misschien is het daarom dat Windows Phone het hier dus ook gewoon goed doet.
Zover ik weet, Windows Mobile weigerde self-signed certificaten, en ook certificaten van onvertrouwde CA's. Als Windows Phone enigsinds hetzelfde werkt(waar ik eerlijk gezegd 0,0 vanaf weet), kan ik me wel voorstellen dat een niet erkend certificaat geweigerd zal worden.

Ik weet dat Android en iOS inderdaad de mogelijkheid hebben om self-signed, en dus onverifieerbare certificaten kunnen vertrouwen.

Dan nog, knullig dat je met een ander certificaat als het certificaat van de exchange server een wipe commando kunt laten geven.

Ja Google en Apple controleren een met het bericht meegestuurd certificaat niet dus het is de schuld van MS want die heeft zogenaamd een geheime API die dat wel doet. Ben wel benieuwd hoe deze server-side API hier tegen had moeten beschermen .

Tja, het ongeloof slaat toe .. iOS en Android nemen het niet zo nauw met certificaten en slikken alles; vooral Android, want gebruikers vinden die certificaatmeldingen maar lastig. Overigens, *elke* Exchange implementatie die ik ken gebruikt *geen* self-signed certificaten.

Overigens, *elke* Exchange implementatie die ik ken gebruikt *geen* self-signed certificaten.

Ik ken er wel een paar. Vooral in kleinere omgevingen worden kosten en complexiteit van een 'echt' certificaat overschat. Dit is ook geen probleem, als 'gebruiker' van het certificaat geef je immers zelf aan of je de uitgever van het certificaat vertrouwd.
Het probleem kan/mag dan ook niet hier neergelegd worden; een ander certificaat dan het oorspronkelijke is simpelweg geen juist certificaat en zou dus niet als zodanig geaccepteerd moeten worden.

Uit persoonlijk ervaring kan ik melden dat WP veels tricter is met certificaten. Mijn collega's met android en iOS konden gewoon met onze exchange server met verlopen certificaat blijven syncen, maar mijn WP vertikte het, totdat het certificaat weer up to date was. Dus ik denk dat deel van deze implementatie gewoon 'gemakzucht'van de geburiker is waar apple en google op in spelen.

Overigens, *elke* Exchange implementatie die ik ken gebruikt *geen* self-signed certificaten.

Dan ken je blijkbaar alleen maar verouderde exchange implementaties.

Exchange 2010 servers hebben standaard allemaal self-signed certificaten, om onderling de boel secure af te handelen. Uiteraard zorgt Exchange er wel voor dat willekeurige self-signed certificaten niet worden vertrouwd. Zodoende hoef je als bedrijf niet een volledige PKI infrastructuur op te bouwen om Exchange te draaien.
Voor secure email met derde partijen gebruik je uiteraard geen self-signed certificaten en ga je naar verisign of zo.

want gebruikers vinden die certificaatmeldingen maar lastig

Verklaar je nader? Of gewoon uit de lucht gegrepen?

Opvallende reactie. In het geval van werken met SSL certificaten ligt de verplichting van controle altijd bij het end device, ik snap dus niet hoe je er hier MS met de haren bij kunt slepen

OT: Wat een fudge up van Google, al doet Apple het niet beter. Lijkt me best zuur als je bijv. je foto's/filmpjes kwijtraakt door dit soort grappen.

De exchange server heeft nog alle data toch? Of delete deze wipe functionalteit nog meer dan alleen e-mails, contacts, e.d. van de telefoon?

Alles gaat eraan, inclusief externe storage op Android

Dus als iPhone of Android zijn certificaten niet checkt, is dat de schuld van MS?

Bizarre logica die jij volgt...

En wat is het probleem van een telefoon die gewyped is?
Je synct hem weer met exchange en je hebt alle belangrijke gegevens weer terug!

Je mist wat smsjes en wat foto's, maar dat is een probleem? Meestal zijn exchange implementaties als deze zakelijk.

En wat is het probleem van een telefoon die gewyped is?

Nog een leuke: Wat is het probleem met een DDOS aanval. Een paar uur later is de website toch weer in de lucht.
Elke verstoring van het normale arbeidsproces kost geld en is dus ongewenst.

Mee eens.

Maar we hebben het hier over 'marge werk'. De impact is qua tijd en resources relatief laag.
Je kunt beter je tijd steken in het oplossen van grotere problemen en deze 'kleine' problemen laten voor wat het is.

Om in je DDOS vergelijking te spreken: Als je ergens een lading requests vandaan komt met 1mb/sec en je hebt een 1gb/sec verbinding, dan kan je het probleem negeren ook al is het DDOS. Je schaalt pas op als de (verwachtte) impact groot is.

En wat is het probleem van een telefoon die gewyped is?
Je synct hem weer met exchange en je hebt alle belangrijke gegevens weer terug!

Het kost manuren, en is dus geld wat verloren wordt.

De gebruiker moet namelijk ook vast weer langs hun IT club, die er tijd en energie in moeten stoppen, etc, etc, etc. Zulke grappen lopen snel in de papieren.

Je mist wat smsjes en wat foto's, maar dat is een probleem? Meestal zijn exchange implementaties als deze zakelijk.

Juist voor zakelijk gebruik is dit een risico...om eens wat te noemen: ben je net op locatie geweest voor een inspectie van het een of ander (bijvoorbeeld voor een huisuitzetting), wat fotootjes gemaakt als bewijs...blijken die vrolijk gewist te zijn.

Dat is toch net wat vervelender dan wat crappy foto's in de kroeg die je kwijt raakt...

Om hem te syncen met exchange moet je eerst alles weer instellen. De meeste gebruikers hebben niet alle paswoorden en vooral instellingen van hun Exchange Server en andere applicaties bij de hand. Ook de hoeveelheid MB's die over de lucht moeten zijn een issue, de data bundel is helaas beperkt.

Dan zit je dus al snel een dag zonder werkende telefoon en dat is zeker als je aan het werk bent ontzettend lastig (ook prive trouwens).

Gelukkig kan met deze functionaliteit alleen de data op de telefoon gewist worden. De e-mails, contactpersonen, taken en agenda ( en meer ) blijven gewoon op de Exchange server staan. Wanneer dus iemand het slachtoffer hiervan is geworden, is opnieuw verbinding maken voldoende om dit probleem te verhelpen. Geen groot probleem dus, wel lastig als dit vaak voor komt.

Dat is wel een heel typische admin-reactie... Als jouw carefully crafted and tweaked Android-phone weer terugezet wordt naar zijn standaard waarden, dan zou ik jou reactie wel eens willen horen ...

Je hebt het goed gezien dat mijn reactie vanuit een administrator / beheerders oogpunt komt. Wanneer ik verantwoordelijk ben voor de mobiele telefoons binnen het bedrijf ( wat niet het geval is ) zal daar een standaard in gelden. Deze standaard zal op een manier gemakkelijk uit te rollen zijn, waardoor er dus weinig werk aan is. De gebruiker kan dan niet eens meer tweaken.

Verder blijf ik wel aankaarten dat het zeker niet prettig is als iets dergelijks voorkomt, maar dat het relatief gemakkelijk op te lossen is. Wat ik wilde aangeven, is dat er geen groot dataverlies ontstaat wat niet meer terug te draaien is.

Een beetje tweakers zorgt dat hij een recente backup heeft en geautomatiseerde installer waarmee hij snel bijna alles kan recoveren.

Ik maak pas een backup voordat ik weer ga sleutelen dus als ik een week geen zin heb aan me telefoon te tweaken heb ik dus een week oude backup, daarbij heb jij het over tweaker, die hebben er minder last van inderdaad... De gewone gebruiker uiteraard wel...

En neem jij die back-up ook mee op vakantie of op zakenreis? Ja, het is allemaal niet zo'n probleem als de exchange server via het wifi netwerk op kantoor te bereiken is. Het wordt erg lastig als je gezellig op vakantie bent.

Vervelende exploit, maar gelukkig kan er op deze manier geen data worden gestolen, alleen worden verwijderd. Zolang de telefoons regelmatig een back-up krijgen, maakt dit niet heel erg uit. Zeker niet nu je tegenwoordig steeds meer in de cloud opslaat.
Ik heb wel eens een aantal telefoons per ongeluk gewiped en dan ben je weer een half uur per telefoon bezig om het te fixen. Dit is dus een risico wat overkomelijk is en hoogstens een boel tijd van de ICT afdeling kosten.

Natuurlijk als dit voor een enterprise niveau bedrijf niet leuk aangezien je dan best wel eens een heleboel telefoons moet terugzetten en je bent alle data kwijt die nog op de telefoon stond.

Veel bedrijven zijn aan het wachten op windows 8 tablets en windows 8 phone, om het volledige "pc, notebook, tablet, telefoon" park optimaal te laten samenwerken met het netwerk.
Zal zalig zijn dat je met uw Dc via group policy alles (pc, notebook, servers, tablets, phones) kan configureren aangepast aan de persoon, dienst, vestiging....
Android, ios....hun beleid is dat de gebruikers experience boven de veiligheid gaat. Terwijl ik vind, dat de veiligheid boven alles gaat. Ik werk nu op een volledig encrypted ssd hard disk, daardoor moet ik bij het opstarten een extra paswoord ingeven. (dus iets lastiger voor een gebruiker).
.

Maar Android is potentieel wel veiliger vanwege het open systeem.

iPhone is dus totaal niet encrypted. Het password op de lockscreen kun je gewoon omzeilen via de camera app. Dus geen password nodig om te decrypten, maar is het password ergens opgeslagen. Dat kun je dus gewoon uitlezen.

Bovendien duurt een wipe maar een paar seconden, de gehele telefoon kan dus niet worden gewiped en de meest simpele hacker kan dus al de chips eruit solderen om gegevens te lezen.

Bovendien is een 4 cijferig password binnen een seconde ofzo te bruteforcen.

Ik werk nu op een volledig encrypted ssd hard disk, daardoor moet ik bij het opstarten een extra paswoord ingeven. (dus iets lastiger voor een gebruiker).

En daarom zit er dus een TPM chip in moderne hardware. Deze kan de benodigde sleutel opslaan zodat jij (indien gewenst, natuurlijk) alleen jouw eigen credentials nodig hebt. De data op de disk (of eigenlijk: de versleutelde volumes) blijft op dezelfde manier beveiligd en is zonder een valide user-account nog steeds niet toegankelijk.

Maar in zekere zin ligt er ook wel een fundamenteler probleem aan ten grondslag. Kennelijk zetten veel beheerders toch nog self-signed servers op. Dat maakt ook dat er een zekere flexibiliteit in de clients wordt ingebouwd om gebruikers niet teveel lastig te vallen. Daarmee wil ik niet zeggen dat het goed is dat de clients onvoldoende controleren, geenszins zelfs. Maar met de huidige mate waarin we afhankelijk zijn geworden van mobiele apparatuur die moet communiceren met hoofdservers zouden we er goed aan doen om veel strikter te gaan werken met certificaten.

Dan blijft een probleem of je dan begint met strikte clients, wat beheerders dwingt of dat je begint aan de serverkant. In ieder geval lijkt het me dat met productieservers het nooit wenselijk is dat gewerkt wordt met self-signed certificaten. Daarmee bedoel ik te zeggen dat je eigenlijk clients en servers minder flexibel zou moeten maken om om te gaan met 'testomgevingen'. Uiteindelijk ontwikkel je dergelijke applicaties om veilig te werken binnen een open productieomgeving en niet voor testomgevingen of gesloten intranetstructuren.

[Reactie gewijzigd door Infor40 op 27 juli 2012 10:04]

Ik ben even benieuwd met welke client-settings onder Android getest is. Er is nl. een vinkje te configureren "Allow all SSL Certificates" die aangevinkt moet worden bij gebruik van een self signed certificate. Ik benieuwd of de exploit ook werkt als dit vinkje uit staat...

Dus als ik het goed begreip zit de fout niet in Exchange maar in de implementatie van het ActiveSync protocol? Dat zou dus betekenen, dat gebruikers van Z-push van zarafa en Datasync icm met GroupWise op iOS en Android o.a. ook vatbaar zijn?

Niet zozeer het ActiveSync protocol, maar meer hoe het device én de user omgaat met untrusted certificates (door verkeerde URL, MITM, Self-signed, Expired etc. etc.).
Dus ja, het is mogelijk.

Mag ik trouwens vragen wat het nut is van het wipen van je HELE telefoon? Ik neem aan dat exchange verwijderen meer dan afdoende is?

Nou...als je telefoon kwijt/gestolen is, lijkt het me ook wel fijn dat naast exchange gegevens ook alle SMS-jes, foto's, video's, documenten, POP3 email etc. niet in handen komen van de (al dan niet eerlijke) "vinder" van je telefoon...

Lijkt me niet dat dat het doel is van die functie? Daar installeer ik zelf wel wat voor, áls ik dat wil.

Wordt dit enkel gebruikt als ik zelf mijn sys admin vraag om de wipe uit te voeren, of doen ze dit ook ongevraagd, als ze verdachte activiteit oid zien?

Dit is juist wel de bedoeling van deze functie.

En dit is inderdaad iets wat je sysadmin moet uitvoeren. Met name als er een mobieltje kwijt /gestolen is.
Maar het zou in principe ook kunnen indien de sysadmin (op een of andere manier?) ziet dat er verdachte activiteit plaatsvind met het mobieltje (in dat geval mag ik overigens hopen dat de sysadmin dit eerst bespreekt met manager/P&O, die de medewerker er op aanspreken...).
Verder zou de sysadmin het (als het goed is alleen in opdracht van manager/P&O) kunnen uitvoeren in geval van bijvoorbeeld ontslag op staande voet.

Onze sysadmin heeft het naar mijn weten alleen 1x gedaan toen iemand op vakantie zijn bedrijfsmobiel was kwijtgeraakt, en daar netjes over belde.

En dit is inderdaad iets wat je sysadmin moet uitvoeren

Niet alleen de sysadmin, een gebruiker kan het ook zelf uitvoeren via outlook webaccess.
Maar als je telefoon net gestolen is heb je vaak geen internet bij de hand...

voor het geval dat je een keer een smsje met een wachtwoord hebt ontvangen, of dat de Vasco Authenticatie app op je telefoon staat, klantgegevens in je adresboek.