• Olá Visitante, se gosta do forum e pretende contribuir com um donativo para auxiliar nos encargos financeiros inerentes ao alojamento desta plataforma, pode encontrar mais informações sobre os várias formas disponíveis para o fazer no seguinte tópico: leia mais... O seu contributo é importante! Obrigado.

Hacking O iPhone, iPod e IPAD com uma página Web

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
por Alan Dang

Tom's Hardware leitores regulares sabem Charlie Miller como a primeira pessoa a hackear o iPhone da Apple e uma repetição do vencedor do concurso Pwn2Own CanSecWest. Desta vez, falamos com Charlie sobre jailbreaking eo que ela significa para smartphone segurança em geral.

A melhor parte de ser um escritor com Tom's Hardware não é que eu consigo jogar com os mais recentes CPUs e GPUs. Claro que a coisa é legal, mas o que é ainda mais especial é a oportunidade de conhecer e conversar com as pessoas que fazem a mágica acontecer. Cirque du Microsoft festa de lançamento Soleil empalidece em comparação com o encontro com o pai de Intel V8 para tomar um café na lanchonete do campus da Intel, sentar com os engenheiros da Nvidia PureVideo durante o almoço, ou simplesmente falar de carros com os caras da AMD.


Hoje, temos uma outra entrevista com Charlie Miller, da Independent Security Evaluators. Como os leitores regulares de Tom's Hardware sabe, Charlie foi a primeira pessoa a hackear o iPhone e com êxito invadiu uma totalmente atualizados Apple MacBook de cada ano, a CanSecWest Pwn2Own do Concurso.





A menos que você esteja vivendo em um posto remoto em Mar Sara, você provavelmente já ouviu falar sobre o recente jailbreakme site para o iPhone e IPAD, que lançou este mês, logo após a Biblioteca do Congresso explicitamente permitido telefone celular "jailbreaking", a ser isento do DMCA. Embora o jailbreak tem sido em torno desde o iPhone original, e os milhões de usuários de telefones baseados no Android aproveitar a oportunidade de rodar qualquer aplicação que eles querem fora da caixa, a incrível popularidade e controvérsia dos 4 iPhone fez um hot tema para a mídia, chegando até o New York Times e Wall Street Journal.


A história real não tem a ver com o jailbreaking, no entanto. É como o jailbreak realmente acontece, e as implicações para a segurança do smartphone. Assim, sem mais delongas, aqui está a nossa entrevista.


Tom's Hardware: Como sempre, nós realmente apreciamos o tempo que você levar para fora para as entrevistas.


Charlie: Não tem problema. Eu estou sempre feliz em compartilhar detalhes técnicos com as pessoas para dar dicas sobre as plantas daninhas de segurança.


TH: O que vulnerabilidades foram expostos para o iPhone e na semana passada IPAD?


Charlie: Existem duas vulnerabilidades. O primeiro é uma execução remota de código no MobileSafari. O erro está na forma como determinadas fontes são analisados. O real explorar usa um PDF para entregar a fonte, mas outros métodos são possíveis, eu suponho. A segunda vulnerabilidade é uma escalação de privilégios no âmbito local IOKit.


TH: Então como é que o site JailBreakMe explorar essas vulnerabilidades para permitir que o "jailbreaking" de ocorrer?


Charlie: Em primeiro lugar, fica jailbreakme código em execução dentro MobileSafari com o bug fonte. No entanto, devido à arquitetura de segurança do IOS, MobileSafari executado como usuário "móvel" e dentro de uma caixa de areia. Usuário "móvel" não pode fazer alterações na configuração do sistema, apenas o administrador "root" pode fazer isso. Além disso, o sandbox restringe as ações de exploração pode assumir. Por exemplo, o seguro não permite MobileSafari para enviar mensagens SMS.


Isto é onde a segunda façanha vem dentro É a segunda vulnerabilidade, em IOKit, que permite que o código seja executado como usuário root, em vez de usuário móvel. De dentro do contexto de MobileSafari, o segundo é lançada explorar o que aumenta o privilégio da execução do código para a de raiz. O seguro não é destinado a restringir a um processo que pertence ao root, e também é facilmente burlada neste momento. Então agora o código pode escrever para a memória do kernel e nada é sagrado. O exploit então desabilita a assinatura de código, e carrega algumas bibliotecas dinâmicas, que fazem o trabalho de jailbreaking o telefone.


TH: Então, a caixa de areia desmorona. E sobre a mesa sandbox do Google Chrome, e como MobileSafari comparar?


Charlie: Eles são semelhantes no que eles tentam restringir os tipos de ações que o código pode executar. Adobe Reader em breve também executar em um sandbox. Na prática, caixas de areia vigor atacantes para escrever duas explorações em vez de um, como foi feito aqui. Areeiros apenas fornecer uma camada adicional de defesa, mas não fazem a exploração impossível.


TH: Interessante. Uma das coisas que eu observei é que o processo de jailbreaking inteiro leva alguns minutos. Quanto disto é gasto com acesso root para o telefone para permitir a execução remota e quanto desse tempo é a própria instalação do software, como o Cydia?


Charlie: A exploração recebe o código em execução, eleva a raiz, e assinatura de código desativa quase instantaneamente. Todo o tempo adicional na execução do jailbreak real.
 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
O que Jailbreakme fazer?

TH: Então, se jailbreakme.com não fornecer uma barra de progresso, isso poderia ter sido feito sem a consciência do usuário?

Charlie: Certamente. O site Web jailbreakme não tentam esconder suas ações. Ele está prestando um serviço para o usuário. Um site malicioso poderia executar esse código em segundo plano e você não o saberia.

TH: E se a carga foi menor, digamos enviar senhas ou informações pessoais, que poderia ter acontecido quase que instantaneamente?

Charlie: Sim. Fazer alterações permanentes ao telefone, como jailbreak, é demorado. Mas roubar informações como contatos, mensagens SMS e e-mails que aconteceria em menos de um segundo.

TH: Deixe-me colocar um chapéu preto por um segundo. Como sabemos que esta vulnerabilidade, que existe em versões anteriores do IOS, não tem sido explorada de forma orientada em algum lugar? Em junho, tivemos a fuga de mais de 100 mil proprietários iPad "endereços de email, incluindo executivos e funcionários do governo. Alguém poderia ter enviado um deles um link para um site malicioso, que em seguida, instalou um spyware ou outro código malicioso?

Charlie: Não há nenhuma maneira de saber se essa vulnerabilidade tem sido explorada no passado.

TH: assustador. Como podemos ter certeza de que nenhuma aplicação existente disponível através da App Store não alguma forma de instalar um rootkit? Vimos proxies SOCKS sneak através da App Store oficial no passado, e há toda a história do papel de parede Android App roubar informação confidencial?

Charlie: Então ... um aplicativo da App Store poderia, teoricamente, usar a mesma escalação de privilégios explorar a sair da caixa de areia e instalar malware. Como um engenheiro e auditor reversa de código, posso dizer que seria impossível para a Apple a auditoria de todas as aplicações que passam através da App Store. Eles só podem fazer o seu melhor e tentar restringir o API é usado pelas aplicações, mas isso pode ser contornado. Recentemente, alguém incluiu um aplicativo no Android Marketplace, que incluiu um aumento de privilégios exploração local e enraizada no telefone.

TH: Então é possível que um aplicativo pode fazer isso?

Charlie: É possível que um aplicativo pode fazer isso, embora, tanto quanto sei, nenhum aplicativo na App Store já fez isso.

TH: Porque não a ARM XN bits, também conhecida como NX-bit ou bits XD, evitar excessos como este?

Charlie: Antes de Data Execution Prevention (DEP), buffer overflows que redirecionar a execução do processo em código de usuário injetado ou shell. No entanto, o DEP proíbe isso, como o processador sabe que o código injetado é de dados, que não é suposto ser executado. Como uma maneira de contornar isso, explora o uso que é conhecida como programação orientada a retornar (ROP). Aqui, em vez de saltar para o código do usuário com injeção, o ataque vai para o código do processo real. Neste caso, o código dentro MobileSafari e as bibliotecas que ele necessita. Ao reutilizar pequenos pedaços de código do processo, o exploit é capaz de executar as ações necessárias para realizar ações de uso geral.

TH: Então, para compreender isso corretamente, IOS tem alguma forma de DEP, e isso impede a injeção arbitrária de código do usuário. Mas o caminho é a utilização de pedaços de código legítimo - o equivalente a uma nota de resgate feita de cortar letras de jornal?

Charlie: Sim, a implementação da DEP IOS é muito bom. A analogia nota de resgate é uma analogia perfeita, originalmente atribuída a namorada do rapper @ drraid's. Você pega pedaços de código existente e colá-las de uma forma que lhe convier, mas não foi criado pelo designer.

TH: Que sobre tecnologias como ASLR e pilha randomização? Isso teria sido uma solução?

Charlie: Sim, em geral, ASLR derrotas de programação orientada a retornar por randomizing a localização do código de residente, que a exploração gostaria de reutilizar. Se a exploração não pode encontrar o código para a reutilização, ele não pode usar ROP. iPhone não tem qualquer ASLR, todos os endereços são completamente conhecidos por um invasor se você souber a versão do firmware do aparelho.
 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
O futuro da segurança Smartphone?

TH: O que isso significa para o futuro da segurança smartphone? Costumávamos dizer que o MacOS X é inseguro, mas enfrentou um número limitado de ameaças. Ele não era economicamente viável. Macs teve de chegar a 16,6% participação no mercado para que ela faça sentido. Dito isto, com a Casa Branca em execução em Macs e Google rodando no Mac, o Mac é uma prioridade maior.

Mas eu acho que é ainda pior no iPhone. Se eu puder ter mais de um iPhone, não só eu tenho informações pessoais como número de telefone da pessoa, mas eu também posso descobrir qual o proprietário utiliza banco, dependendo se o Bank of America e Wells Fargo aplicativo é instalado. Eu também estou disposto a apostar numa perspectiva de engenharia social que a maioria dos usuários do iPhone compartilhar o PIN de 4 dígitos iguais entre o iPhone eo cartão Multibanco ...

Charlie: Eu sou questionado sobre a segurança dos smartphones o tempo todo. Na história da segurança do iPhone, desde a versão dois foi lançado em 2008, havia apenas um público, exploração remota do root com o iPhone. Esse foi o SMS explorar eu apresentei o ano passado em BlackHat, ea exploração nunca foi lançado ou visto em estado selvagem. Assim, enquanto os iPhones foram teoricamente vulnerável a ataques, nós simplesmente não tinha visto isso na prática. Eu sentia que havia praticamente nenhum risco de ataque remoto contra a fábrica de iPhones, porque seria muito difícil encontrar um bug do Safari, faça ROP, executar uma escalada de privilégios locais, ou de assinatura de código desativar. Esta façanha mudou minha mente, e agora vejo iPhones tão vulneráveis a ataques, especialmente até que uma correção esteja disponível.

TH: O que é uma expectativa razoável para os usuários finais têm para a Apple para corrigir essas vulnerabilidades? Isto é algo que toma muito esforço ou é apenas uma questão de alteração de algumas linhas de código, agora que o problema é conhecido?

Charlie: Essas falhas devem ser corrigidas rapidamente, eu diria que dentro de duas semanas. Apple estará muito motivado para corrigi-lo, não tanto por causa das implicações de segurança, mas porque eles não gostam de pessoas jailbreaking seus telefones. A correção deve ser relativamente simples, e requerem pouco de teste desde que o programa é executado em apenas um punhado de configurações de hardware diferentes.

TH: Apple sempre fala sobre o risco de segurança, após o jailbreak. Mas para esclarecer, as vulnerabilidades que se permitiu código não assinado para ser executado em primeiro lugar estava sempre lá em cada iPhone ou IPAD, independentemente do status de jailbreak, certo?

Charlie: Sim, o jailbreak não enfraquecer a segurança do dispositivo, contornando a arquitetura de segurança tal como concebido pela Apple (assinatura de código, executando aplicações como usuário móvel em uma caixa de areia, etc.) No entanto, neste caso, a vulnerabilidade funciona contra iPhones fábrica totalmente remendado, que não tenham sido desbloqueados. Este é o primeiro exemplo dado IOS 2 saiu que tal um exploit remoto existe. Anteriormente, o worm ikea só funcionou contra telefones desbloqueados, mas este exploit trabalha contra os telefones para a direita fora da caixa.

TH: Antes disso, tivemos o TIFF exploit que permitia que o iPhone de primeira geração a ser cortado, certo? Era esse o mesmo tipo de problema?

Charlie: Então, o TIFF exploit foi também uma vulnerabilidade remota de código no MobileSafari. A diferença era que naquela época, no IOS de um dia (por volta de 2007), a arquitetura de segurança do iPhone era muito imaturo. MobileSafari funcionou como root sem uma caixa de proteção em telefones de fábrica. Assim, neste caso, não era necessário segundo explorar, qualquer vulnerabilidade de código remoto levou a todos os privilégios administrativos sobre o dispositivo. Você pode ver o quanto a melhoria da segurança quando a versão dois saíram.

TH: Apple tenta compartilhar o código subjacente entre iOS4 eo desktop Mac OSX. Embora existam diferenças de arquitetura, obviamente, entre os dois, podem estas vulnerabilidades do iPhone e do IPAD ser usado para desenvolver um exploit para o sistema operacional para desktop?

Charlie: Eu acho que sim, estou actualmente a estudar isso.

TH: Você já olhou para o Android, BlackBerry, Symbian, Windows 7 ou Telefone recentemente?

Charlie: Eu também olhou para a segurança do Android. Na verdade, eu escrevi um exploit para o navegador da Web para o celular G1, o dia em que saiu. Quanto a compará-lo com o iPhone, que é uma espécie de difícil comparar, porque fazem escolhas diferentes na forma como segura o telefone. Mas eu diria que eles são aproximadamente comparáveis.

TH: Que tipo de telefone que você está usando?

Charlie: eu normalmente uso um iPhone 3GS, mas tenho um pouco de água em um par de dias atrás, então eu estou usando um iPhone de primeira geração no momento em que eu normalmente uso para hackear, err testes. Eu normalmente não faço nada de especial, e eu levar o meu telefone em alguns ambientes muito hostis como Blackhat e DEFCON. Como eu disse, antes eu achava que estava bastante seguro contra ataques. Pelo menos até o patch sai para estas vulnerabilidades, eu estou sendo cuidadoso ao seguir links em e-mails e Twitter. By the way, você pode me seguir no Twitter 0xcharlie .

TH: Ainda correndo o MacBook?

Charlie: Sim, eu ainda estou usando o meu MacBook antigo, que já ganhou três vezes Pwn2Own. É realmente em sua última etapa, então muito em breve estarei mudando para um dos MacBook Pros que eu ganhei. Vai ser um dia triste, como eu tenho uma ligação sentimental com este computador. É o único que eu acho que eu já escrevi um Mac OS X em explorar, eu escrevi Mac Hacker's Handbook sobre ele. Eu realmente perder!

TH: Free Bugs? "Como o progresso" Não é com mais

Charlie: Muito bom. Desde que começamos a falar no Bugs mais livre, o Google começou a pagar para as vulnerabilidades, e no mês passado, aumentou o montante que pagam mais de US $ 3.000 por bug. Pouco tempo antes, Mozilla levantou o montante que pagam para vulnerabilidades de segurança de R $ 500 a $ 3000. Também tem havido um grande aumento no uso de terceiros "intermediários", como Zero Day Initiative da TippingPoint (ZDI). Eu não levar o crédito por todos estes eventos, mas estou feliz de vê-los acontecer. Qualquer coisa que ajude navio de software com menos bugs é bem comigo. By the way, a Microsoft ea Apple ainda não pagam por vulnerabilidades.

TH: Sua empresa é especializada na análise da arquitetura, testes de penetração, e revisão de código fonte. Reconhecendo a tendência inerente, como poderia cada um desses serviços ter mudado as coisas? Foi este exploit puramente o resultado de má sorte na parte de Apple? Ou foi algo evitável em retrospectiva?

Charlie: Empresas fazem sua própria sorte, boa ou má. Há muitas coisas que a Apple poderia ter feito para evitar que isso ocorra, embora seja sempre mais fácil ver em retrospecto. Primeiro, por uma auditoria e difusão de código, as vulnerabilidades poderiam ter sido encontradas e corrigidas antes de ser descoberto fora da Apple. Por exemplo, em março, dei uma palestra sobre a difusão onde eu mencionei que eu encontrei 40-60 vulnerabilidades exploráveis em Preview. Se eu encontrasse esse muitos bugs, provavelmente há muitas centenas de bugs críticos no código.

Em seguida, as regras sandbox poderia ter sido mais apertado. Eu duvido que houvesse qualquer razão para permitir que o navegador da Web para interagir com IOKit da maneira que aconteceu. Deve exibir páginas da Web, não mexa com os drivers do kernel.

O irônico é que, se a Apple ofereceria um aparelho mais aberto, este evento nunca teria acontecido. O cara que descobriu esses erros e escreveu as façanhas não era um pesquisador de segurança ou um hacker mal, ele era alguém que queria fazer o jailbreak seu telefone e utilizá-lo como ele queria. Se a Apple permitiu aplicações independentes de terceiros, ele nunca teria ido à procura de bugs.

TH: Bem, ele nos fez um grande serviço para todos nós. Não só tem tido tempo para nos mostrar os riscos de segurança dos nossos telefones inteligentes, mas ele nos deu uma fuga de presos iOS4 ao mesmo tempo. Muito obrigado pelo seu tempo.

Charlie: Você é muito bem-vindos.

UPDATE: O bug do PDF foi encerrado com o lançamento do firmware 4.02. Como resultado, Jailbreakme.com não funciona mais. Os proprietários de iPhones desbloqueados podem obter o partido fixar terceiros através do Cydia. Infelizmente, os proprietários do iPhone original e do iPod Touch não tem acesso a uma versão corrigida do IOS. do tempo de resposta da Apple para essa vulnerabilidade estava bom e dentro de uma semana de tempo-alvo dois.
 
Topo