Início » Antivírus e Segurança » Uma simples troca de data pode inutilizar um iPhone

Uma simples troca de data pode inutilizar um iPhone

Basta voltar o calendário para 1º de janeiro de 1970 para transformar um iPhone num peso de papel

Paulo Higa Por

A Apple tem um sério problema com calendários. Quando um ano bissexto começa, um horário de verão termina ou você muda de fuso horário, a gente sabe que algum produto da maçã vai dar pau. Uma falha recém-descoberta é bem grave: nos iPhones mais novos, se você alterar a data do aparelho para 1º de janeiro de 1970 e reiniciá-lo, ele simplesmente para de funcionar.

ios-falha-1970

O problema foi divulgado por um usuário do Reddit e, até onde se sabe, afeta qualquer dispositivo que rode iOS e tenha um processador de 64 bits, o que significa que os iPhones 5s ou mais recentes estão sujeitos à falha. Depois de voltar a data para 1970 e desligar o aparelho, o iPhone não ligará novamente. A tela de boot, com a marca da Apple, chega a aparecer, mas não é possível fazer mais nada.

Este vídeo mostra o que acontece:

Não pergunte como (e por que) alguém conseguiu descobrir o problema — é necessário uma bela dose de paciência para conseguir voltar o calendário do iPhone para 1970. Mas a falha certamente está relacionada ao fato de que 1º de janeiro de 1970 é o marco zero no calendário dos sistemas operacionais baseados em Unix. O horário Unix é o número de segundos que se passou desde esse dia (no momento em que escrevo este parágrafo, o relógio marca 1455292939).

Esse é um problema sério porque o smartphone precisa ser reparado fisicamente se algum engraçadinho mudar a data do aparelho de propósito. Por enquanto, não há nada que você possa fazer por software para reviver um iPhone que pensa estar em 1970, nem mesmo colocando o dispositivo em modo de recuperação.

Além disso, teoricamente é possível inutilizar um iPhone mesmo sem acesso físico, logo, não basta impedir que alguém tente voltar a data do seu celular. Como os computadores costumam sincronizar o horário com um servidor NTP, um hacker poderia, por exemplo, enviar um comando remoto para voltar a data de todos os iPhones conectados a uma rede para 1º de janeiro de 1970, em um ataque hipotético.

Mais um ano, mais uma falha de calendário na Apple.

Comentários

Envie uma pergunta

Os mais notáveis

Comentários com a maior pontuação

César de Tassis Filho
Acabou de sair notícia de que pesquisadores conseguiram brickar remotamente iDevices usando a técnica que eu citei acima, rodando um servidor NTP malicioso com data errada e "redirecionando" o tráfego de time.apple.com para esse servidor. Vejam: http://9to5mac.com/2016/04/13/brick-iphone-via-wifi/
Luizzz
E o pessoal ficava zoando a Microsoft com os seus trocentos updates de ajuste do horário de verão
Paulo Freitas
Lendo o artigo no Ars Technica (http://arstechnica.com/apple/2016/02/64-bit-iphones-and-ipads-get-stuck-in-a-loop-when-set-to-january-1-1970/) parece que realmente apesar de ser possível na teoria na prática a conversa é outra. :P Seguem comentários relevantes de lá: @Rosyna: "That was speculation. NTP is supposed to use multiple sources (per the RFC) to weed out bogus values. For a single source, it's supposed to use multiple timing values (including one based on the packets in the NTP response) to weed out a bogus server." @Peter Bright (Editor) "By default, the typical Unix ntpd won't change the system time if the network time is more than 1,000 seconds away from the server time, because it assumes that the local clock (which on computers is battery backed) is never going to be too far wrong. I think the Windows service has similar rules." @Chuckstar "Some configurations run ntpdate first, then start the ntpd daemon. IIRC, unlike the ntpd daemon, ntpdate does not have that kind of error checking. I guess one might set up a system that way if for some reason it was expected to have bad time data on startup. Maybe a router with no battery backup for the clock (speculating only)." O ntpdate que eu usei pra atacar o OS X não possui verificação de erros, o daemon ntpd por sua vez tem e parece ignorar grandes mudanças de data. Existe ainda a possibilidade do telefone obter a data através da operadora e neste caso a data obtida pelo servidor NTP seria claramente ignorada por estar muito distante da outra. Ao que me parece, um ataque não-físico não parece ser possível, o que já reduziria bastante a gravidade do problema. Espera-se que seja isso mesmo. :P
Paulo Freitas
Éééé, sei não se é possível de rolar... No log do .pcap achei o domínio time-ios.g.aaplimg.com, que é consultado através de uma query de DNS AAAA. Apaguei o cache de DNS do iPhone ativando o modo avião e desativando, mas mesmo aplicando spoofing no A e AAAA do time-ios.g.aaplimg.com o Ettercap até agiu mas o iPhone em si não alterou o relógio. :/
César de Tassis Filho
Ah, provavelmente eles usam IP literal (em vez de usar DNS pra resolver nome -> IP) para direcionar "com segurança" (aplique MUITAS aspas à frase anterior) as requisições NTP pros lugares certos. Pra testar isso você pode colocar esse IP aí em alguma máquina da sua rede e mexer nas rotas do roteador e dessa tal máquina que você mexeu para que os pacotes NTP sejam encaminhados para ela (e para que ela saiba por onde devolver esses pacotes), mas isso dá um pouco de trabalho.
Paulo Freitas
Errr, acho que fui trollado pelo Ettercap. :P Mesmo tendo apontado diretamente pro IP do iPhone acho que ele acabou pegando algo de alguma aba aberta no meu Firefox. Inspecionando os .pcap gerado pelo Ettercap dá pra ver que ele se conecta ao IP 17.253.12.253 via UDP. Configurei tanto o time.apple.com quanto o time.*.apple.com para redirecionar para o IP do meu servidor - coisa que funcionou no OS X. Ou ele usa um outro domínio para resolver o DNS ou tá se conectando diretamente aos IPs do pool de servidores NTP da Apple - o DNS spoofing não está funcionando no caso do iPhone. Ainda não saquei como continuar. :P Editado: Opa, achei esse carinha aqui: time-ios.g.aaplimg.com Já já eu digo o que rolou... ;D
César de Tassis Filho
HTTP no NTP.br? Isso é BEM bizarro. Consegue dar mais detalhes sobre isso? Ou compartilhar a captura que você fez? Talvez eles utilizem o pool.ntp.org, projeto que agrupa servidores NTP do mundo todo e utiliza geolocation e DNS para apontar as requisições NTP pro servidor mais "próximo". Temos 10 servidores NTP brasileiros no pool.ntp.org, vide http://www.pool.ntp.org/zone/br, sendo boa parte desses servidores mantidos pelo projeto NTP.br. Isso explicaria requisições NTP para servidores brasileiros, mas não usando protocolo HTTP.
Paulo Freitas
Consegui fazer isso no OS X El Capitan com ARP poisoning + DNS spoofing. Ainda não consegui fazer funcionar num iPhone. :/ Pelo ettercap eu notei que o iPhone usa mais de uma maneira pra atualizar o relógio, via UDP no servidor da Apple e via HTTP no ntp.br. Ainda não saquei por qual razão não deu certo ainda.
Leonardo Caldas
Não, mas todo celular que você compra é para ter a flexibilidade de fazer as alterações que o próprio SO possibilite. O iOS permite voltar a data até onde - pelo menos na teoria - o usuário queira. O porque de a pessoa querer fazer não faz diferença...
abraaocaldas
O iOS não usa sincronização de data pela rede da operadora?
abraaocaldas
Tipo aquele padrão de segurança que permitia brute force na API do ICloud?
Keaton
isso no caso do usuário ter feito, né... E no caso de um DNS apontando para o NTP errado cujo qual tenha tal fatidica hora? :D Acredito que em ambos os casos, mesmo sendo culpa do usuário, eles devem ser obrigados a reparar. Pois o problema está no programa deles.
gprujansky
Como seria o "reparado fisicamente"?
Igor
Palmeiras 1 x 2 Linense
Anayran Pinheiro
Qual o resultado?
Exibir mais comentários