Apple verbant hacker wegens beveiligingslek
Apple heeft de bekende beveiligingsonderzoeker Charlie Miller uit het programma voor ontwikkelaars verbannen, omdat hij een beveiligingslek had ontdekt. Dat laat Miller zelf op Twitter weten. De Mac-hacker had een kwetsbaarheid in iOS ontdekt, het besturingssysteem voor de iPhone en iPad. Via het lek was het mogelijk om kwaadaardige apps in de Apple App Store te plaatsen, zonder dat Apple dit door had.
Om te bewijzen dat het uitvoeren van ongesigneerde code mogelijk was, plaatste Miller zijn demo app in de App Store. De applicatie toont real-time beursinformatie, maar staat ook in verbinding met een server waardoor Miller het programma opdrachten kan geven, waaronder het bekijken van het adresboek. De controles die Apple uitvoert voorkomen het uitvoeren van ongesigneerde code op de iPhone, maar Miller weet dit via het lek te omzeilen.
Miller is van plan om zijn ontdekking volgende week tijdens de SysCan conferentie in Taiwan te presenteren. "Nu heb je een programma in de App Store zoals Angry Birds dat nieuwe code op je telefoon kan uitvoeren die Apple nooit heeft kunnen controleren", aldus Miller. "Met deze bug kun je er niet meer zeker van zijn dat wat je van de App Store downloadt, zich ook netjes gedraagt."
Verbannen
Inmiddels heeft Apple de app uit de App Store verwijderd. Daarnaast werd Miller uit het iOS Developer programma gezet. Volgens 'Cupertino' was de kwaadaardige app in strijd met de licentievoorwaarden. De Mac-hacker kwam op het spoor van het lek toen Apple iOS 4.3 uitbracht.
Om de werking van de browser te versnellen, stond Apple het toe om JavaScript van het web veel dieper in het geheugen te draaien dan bij vorige versies van het besturingssysteem het geval was. Apple had een uitzondering voor de browser gemaakt om niet goedgekeurde code in een gebied van het geheugen uit te voeren, wat tot dat moment onmogelijk was. Uiteindelijk vond hij een lek waardoor hij die uitzondering voor elke applicatie kon laten gelden. Miller maakte onderstaande demonstratie.
Natuurlijk niet eerst Apple op de hoogte brengen, volledig voor eigen glorie gegaan.
=_="
Echter, je kan er zeker van zijn dat iOS 5.0.1 volgende week uit komt, met een bug fix.
Ik gok eerder op de standaard knee jerk reactie van Apple. Eerst doen, dan denken.
Natuurlijk niet eerst Apple op de hoogte brengen, volledig voor eigen glorie gegaan.
Een deel van het succes van de hack was juist het plaatsen van de app in de store zonder opgemerkt te worden door de controle software.
Onjuist. Hij werd niet verbannen vanwege het ontdekken van een lek, maar vanwege het plaatsen van een programma dat dit lek misbruikte op de Apple store. Het plaatsen van kwaadaardige apps is vanzelfsprekend niet toegestaan. Apple verwijderde eerst alleen de app, en toen Charlie daar ook nog eens over ging klagen werd ook zijn toegang verwijderd.
"Normaal is het wel zo netjes om een bedrijf op de hoogte te stellen. Ik vind het geen nette actie."
Daar gaat het dus helemaal niet om.
Volgens C\net was het lek dus netjes gemeld. Iemand op deze manier aanpakken op een POC, dat alleen op deze manier is aan te tonen, vind ik niet de manier.
Ik hoop dat Apple op deze 'domme' beslissing terug komt, want Miller is eerder een kans dan een bedreiging. Beter dat hij een lek vindt dan scriptkiddie l0l-l33t-h4x0r. Je kan je wel verschuilen achter de regels, maar niet alles is zwart-wit.
Aan het eind van het filmpje zegt Miller, "Apple is going to fix this". Dus ja, er is duidelijk contact geweest.
Apps kunnen ALTIJD extra code in de app verbergen en de mogelijk inbouwen om meer code te downloaden en uit te voeren at runtime is ook simpel. De grootste impact komt voor exploits die iets anders targetten dan Safari aangezien hun ROP payload kleiner kan zijn.
Als voorbeelden voor extra code:
voeg code in die nooit aangeroepen wordt en zorg dat er een bufferoverflow in je programma zit, overflow en je code die er al was wordt uitgevoerd.
Nieuwe code:
zorg dat alle nuttige ROP gadgets in het programma zitten en bouw een bufferoverflow (en eventueel info leak) in.
Of voeg een simpele stack cpu emulator toe die ook system calls kan uitvoeren, triggeren door middel van buffer overflow en je kan weer extra code uitvoeren.
Charlies lek maakt dit alles ietwat makkelijker, maar er is geen manier voor Apple om te voorkomen dat mensen functionaliteit aan hun programma's toevoegen at runtime.
Hiermee word wederom aangetoond dat privacy niet meer bestaant op je Apple (en andere) mobile devices.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?