aparelhos • Exemplos de APIs, frameworks e técnicas para desenvolvimento seguro, segurança de usuários (privacidade), etc. • Situação prática de exemplo: dados de um aplicativo real (de banco) sendo retirado de um aparelho bloqueado e com senha
• Versões do Sistema • Aparelhos e Hardware • Características de Aplicativos Nativos • Mecanismos Gerais * de Segurança • Identificação “Universal” De Aparelhos * Criptografia? Push? IAP? IPC? ...
Como Aplicativos são Desenvolvidos • Publicação e Assinatura de Aplicativos • Gerenciamento (ADC e iTC) • Ferramentas de Depuração e Análise • Exemplo sobre Ambiente iOS / Xcode
• Sobre Engenharia Reversa • Proteção de Dados de Usuários • Sobre Privacidade no Aparelho • Proteção de Dados de Comunicação • Sobre Privacidade em Protocolos
OS X (para Macs da Apple) • OS X é um sistema baseado em UNIX tendo um kernel XNU* (Mach / FreeBSD) • Mesmo Sistema Operacional para vários aparelhos: iPhone, iPad, iPod touch e até Apple TV (ainda sem SDK) * Open source: http://opensource.apple.com
X pra iPhone", e depois iOS • Consiste de um Kernel (BSD), Frameworks/ Serviços e Aplicativos (Phone, Mail, outros) • Originalmente lançado (2007) sem um possuir um SDK, apenas com "Web Apps"
ganhou um SDK / IDE (baseada no Xcode, já existia) • Xcode foi adaptado para suportar “iPhone” • Embora seja um sistema fechado, há muitas partes abertas (Open Source / BSD) • Desenvolvimento iOS iniciou muito antes do próprio SDK (sobre Jailbreak depois)
iPhone, só Web apps 2.0, 2008 Suporte ao SDK, nome iPhone OS, App Store 3.0, 2009 Suporte a Push Notifications, diversas novas APIs 3.2, 2010 Lançamento do iPad, suporte ao iPad, nome iOS 4.0, 2010 Suporte a multi-tasking, muitas novas APIs 5.0, 2011 Barra de notif. iCloud, ARC, Storyboards, ... 6.0, 2012 APIs novas: p.ex. AutoLayout, CollectionView, ... 7.0, 2013 O recomeço
Core Services, Core OS (System) • O desenvolvimento geralmente está focado na Cocoa Touch e Media • As camadas Core Services e Core OS são de sistema e apoio, comuns entre iOS e OS X
e threads e outros • Quando necessário, camadas inferiores suportam usos avançados, low-level • Exemplo: Uma conexão de rede com NSURLConnection (Objective-C) ou sockets UNIX / C, ou... assembly (ARM)
hardware sem qualquer VM/CLR/etc., uso de assembly é “normal” • Compilados em arquitetura ARM no aparelho, x86 no simulador • Existem atualmente “abstrações” para camadas superiores como Xamarin (.NET)
frameworks e seus arquivos relacionados • Aplicativos são isolados em um sandbox como os chroots de UNIX • Existe suporte limitado a multitasking • Existe suporte limitado a comunicação entre aplicativos/processos* * Será visto com detalhe mais adiante (as “IPCs”)
para usuário (aplicativos e dados) e sistema (SO) • Na instalação de um aplicativo, é escolhido um caminho totalmente aleatório • Cada aplicativo vive “isolado” com comunicação limitada e bem simples • Dados do usuário e externos são via APIs* * Tópico de polêmica ao longo dos anos / versões
carrega bootloader assinado • Bootloader só carrega firmware assinado • Firmware só carrega apps assinados* • Validação de versões/aparelhos online • Downgrade não é possível • Não é possível “desatualizar” um aparelho * Parte importante e tema posterior (publicação)
UDID (nos apps) • Do iOS 5 até o iOS 6: MAC address • aka “gambiarra” • Quebra no iOS 7+ com retorno inválido • Do iOS 6 e 7 em diante: • identificador para ads (opcional) • identificador por desenvolvedor* * Sobre desenvolvedor (assinatura) em breve
iOS 5 algumas poucas coisas eram “liberadas” (p.ex., contatos), outras eram “perguntadas” (p.ex., localização) • Não existe um esquema de pergunta antes da instalação (como o Manifest do Android) • No iOS 6 ficou mais restrito • No iOS 7 ficou muito mais restrito* ainda * Qualquer coisa é “questionada”, p.ex., contatos
• Existem as seguintes formas de “passagem de dados” entre aplicativos ou externo: • URL schemes - API trivial openURL • Clipboard/Pasteboard - iOS 3 ou superior • Documentos - área de arquivos • iTunes • Keychain (apps do mesmo desenvolvedor)
• Exemplo: aplicativo://whatever * • Não existe nenhum controle sobre este tipo de registro, nem mesmo na submissão • Aplicativos “do sistema” (Apple) têm prioridade para os nomes, no caso de terceiros resultado é indefinido em conflitos • API: openURL da classe UIApplication * Criatividade: http://x-callback-url.com
Classe UIPasteBoard (generalPasteboard) • Pode ser escrito por qualquer aplicativo • Pode ser lido por qualquer aplicativo • É possível ligar/desligar para campos (texto)
Exemplo: aplicativo Mail pode abrir PDFs em outros aplicativos (p.ex., Dropbox) • Surgiu com o iPad (3.2+) • Classe UIDocumentInteractionController • Aplicativos “registram” UTIs (Uniform Type Identifier) para serem exibidos nos apps • Aplicativo “destino” é aberto normalmente com o contexto nos argumentos* * Exemplo de argumentos (similar ao push)
arquivos através do iTunes • Passa a aparecer nos Aplicativos do aplicativo iTunes em Documentos • A transferência ocorre através do cabo • Um novo arquivo é criado no sandbox • Não existe nenhuma API / comunicação
Área segura (por padrão) no iOS. É o mesmo esquema de keychain do OS X • Aplicativos do mesmo desenvolvedor compartilham área de Keychain e podem usar valores compartilhados (secure store) • APIs em C do Security.framework • SecItemAdd, SecItemUpdate, ... * Google tem usado isso recentemente
• Comunicação externa com aplicativos • (In)felizmente, esta comunicação é segura apenas entre aparelhos e a Apple (APNS) • Nenhum servidor conecta-se diretamente aos aparelhos para envio de notificações • Servidores->Apple->Aparelhos (e o inverso)
Já foi alvo de ataques (iOS 5.1) • Quem foi o “atacado” foi o próprio desenvolvedor, e não o usuário • Nenhuma informação de usuário sobre pagamento foi (abertamente) comprometida até hoje
a comunicação ocorre de forma segura entre iOS e Apple • Aplicativo é apenas informado sobre o resultado (sucesso, erro, etc.) e recebe, opcionalmente, um recibo (receipt) • Existiu uma falha recente (iOS 5.1) sobre isso: validação de recibos no aplicativo * https://developer.apple.com/library/ios/releasenotes/StoreKit/IAP_ReceiptValidation/
um ambiente fechado, sandbox • Não é conhecida nenhuma falha desde o surgimento do iOS onde aplicativos tenham conseguido “sair” desse sandbox • Aplicativos rodam com um usuário não privilegiado chamado mobile (e não root)
um equivalente Objective-C (NSLog) para enviar conteúdo pro console • Embora alguns desenvolvedores não saibam, realmente existe um console • O console é facilmente acessível (Organizer) • Evite logs com informações restritas (ou até embaraçosas ou que facilitem ataques)
permite um acesso quase irrestrito ao aparelho (como será demonstrado), e mesmo com senha • Na versão 7+, o sistema precisa “aceitar” o aparelho através de um “OK” do usuário • Nem mesmo a restauração do aparelho é mais possível sem a confirmação iCloud • Ainda é possível desligar (soft / hard)
um arquivo no computador ou então remotos (no iCloud) • Os backups locais podem ter criptografia, de modo que todos os dados são preservados. Sem criptografia, nenhuma informação sensível (keychain) é mantida • Os backups iCloud são sempre seguros
é acessado diretamente • Existem APIs de abstração (Data Protection) • Começou no iPhone 3GS (2009) e iOS 4 • Suporte a ASLR (Address Space Layout Randomization) e XN-bit ARM
e testar aplicativos - Xcode • Aplicativos nativos são desenvolvidos em linguagem Objective-C e rodam no iOS • Aplicativos nativos são parecidos com os do sistema (p.ex., Mail) que também têm as suas mesmas restrições * • Existem frameworks (não oficiais) e produtos para abstrair o uso de ObjC * Já foram encontradas falhas envolvendo MobileSafari
Web (Webviews) • Exemplo de híbridos mais avançados são por exemplo feitos por PhoneGap • Aplicativos híbridos / Web têm as mesmas restrições dos “100% nativos”
aos aplicativos • São diretórios com a biblioteca em si e seus arquivos/conteúdos de apoio • Existem muitos frameworks compartilhados entre iOS e OS X • Um aplicativo iOS padrão inicia com Foundation e UIKit (e AppKit no OS X)
Objective-C e compilados em linguagem de máquina (ARM ou x86) • O desenvolvimento é feito com o Xcode que engloba diversas ferramentas (IDE, compiladores, analisadores, documentação, entre outros) • Compilador é “próprio” - Clang / LLVM* * É tudo Open Source - http://llvm.org
(deste a NeXT) • É um super-conjunto estrito de C • Até pouco tempo atrás era gerenciamento manual de memória, hoje tem ARC (que não é bem um Garbage Collector, ocorre em tempo de compilação)
de C, fora detalhes de OO • Baseada em Smalltalk e tem algumas características interessante como as noções de “mensagens” • A “relação” com C é direta, pode-se programar em C, C++ e Objective-C* * Na prática, Objective-C é um grande “wrapper” de C, abstraindo estruturas, pfunctions, etc.
que são apenas em C ainda, ao passo que outras já são em Objective-C (seja por foco, por otimização, etc.) - Security framework é C • Não é raro desenvolvedores preferirem fazer critical paths em assembly __asm__ • Não é raro pegar coisas prontas em C * e simplesmente “plugar” nos projetos/Xcode * Exemplo de código C misturado com ObjC
Existem duas formas de distribuição (ou publicação) de aplicativos atualmente: • Ad Hoc: conjunto restrito de aparelhos • App Store: todos * com acesso à loja • Desenvolvimento: cabo ligado no Mac/iOS * Existe uma variação recente de distribuição B2B diretamente pela App Store. Brasil fora ainda
existe a opção de executar aplicativos de “fontes não conhecidas” no iOS (ou seja, aplicativos não assinados) • Hoje o Mac OS X tem essa opção disponível em Preferências do Sistema, Geral, Permitir aplicativos transferidos de.
aplicativos não assinados, e por isso também permite a pirataria* • Consiste de: exploit no bootloader para executar versão não assinada do iOS, que é alterada para permitir a execução de aplicativos não assinados (via lockdownd) • Exemplo em um aparelho com jailbreak * As coisas não estão relacionadas, no entanto. Pirataria em iOS é praticamente insignificante.
encontrados no bootloader • Jogo de “gato e rato” com a Apple • Cada novo aparelho e cada novo iOS tornou as coisas mais difíceis • Não confundir jailbreak e unlock (baseband) • Atual versão (6.1.3) ainda é sem jailbreak * * Pelo menos não existe divulgado. Talvez estejam aguardando pelo iOS 7 (Setembro/13)
um aparelho (ARM), um desenvolvedor (pessoa ou empresa) precisa participar do Apple Developer Program • Não é necessário assinar ou participar deste programa para usar o Simulador • A participação no “programa” é validada pela Apple (comprovação pessoal/empresa)
pessoal física que publica em seu próprio nome - $99 por ano • Company: empresa que possui um time de pessoas e publica no nome da própria empresa - $99 por ano • Enterprise: direto com a Apple * * Talvez tenha sido deixado de lado com os novos B2B apps na App Store
• Acesso a versões beta (em NDA) • Tickets (restritos) de suporte • Assinatura de desenvolvimento (cabo) • Assinatura para Ad Hoc (betas) • Assinatura para App Store
que agrega alguns outros sistemas da Apple para desenvolvimento Mac, iOS e Safari • Provisioning Portal: Ambiente para fazer configurações de provisionamento • iTunes Connect: Gerenciamento de aplicativos (e outros) no iTunes, envolve contratos, downloads, versões, etc
através dos portais Web, muita coisa agora já pode ser feita direto no Xcode 4 / Organizer • Muita coisa muda com Xcode 5, sendo praticamente tudo suportado diretamente pelo próprio Xcode 5 / Organizer • Atenha-se principalmente aos conceitos, não aos sistemas e interfaces
e Perfis (do ADC) • Certificado é um certificado normal ligado a um desenvolvedor (em seu Mac) • Identificador é ligado a um ou mais apps • Perfil relaciona certificado, identificador, e opcionalmente aparelhos para provisioning
define quais “serviços do sistema” são usados (p.ex., Push Notifications) • Válido principalmente para OS X (sandbox) • Um aplicativo é assinado com entitlements
das seguintes formas: • Development: cabo ligando direto aparelho e Mac (Xcode) • Ad Hoc: distribuição de IPA (iPhone/ iOS Package Archive) via iTunes/Web/etc* • App Store: distribuição em massa * Poucos sabem, um IPA pode ser distribuído via Web. Além disso, existem serviços como TestFlight
um iPhone se estiver assinado, em 3 situações: • Assinado em Development (cabo) com o ID do aparelho associado • Assinado em Ad Hoc (beta) com o ID do aparelho associado • App Store com assinatura da Apple
100 aparelhos (acabou de subir para 200 aparelhos) por ano para quem possa fazer a distribuição de testes* • Um aplicativo assinado em development ou ad hoc só executa no aparelho se nele estiver associado um provisioning que tenha o ID (UDID) do próprio aparelho * Não apenas testes, é comum empresas usarem isso como “Enterprise Deployment”
diversas funções (roles) no ADC: • Agent: coordena o time • Admin: tem funções administrativas • Member: apenas acessa/utiliza • A conta Individual não tem nenhum tipo de organização, é só um acesso/perfil
funções no portal ADC / Provisioning Portal, existe ainda toda a parte de iTunes Connect onde aplicativos/conteúdos são criados • É um outro time, outros convites, e outro conjunto de responsabilidades. O gerenciamento de usuários é feito através do próprio iTunes Connect
Portal criam e gerenciam certificados, identificadores e perfis, seguindo as suas funções permitidas • Usuários (convidados) no iTunes Connect criam e gerenciam conteúdos e questões relacionadas (vendas, versões, etc.) também seguindo as suas funções permitidas
o código fosse aberto e evite “segurança por obscuridade” do tipo “se chegarem a pegar o meu código eu estou com sérios problemas”* • Exemplo: use mecanismos (e criptografia) que dependa de outros fatores externos à base de código, como a senha do usuário ao criptografar dados do usuário * Não apenas por engenharia reversa, também por acesso “não autorizado” à base de código
que contém: • Executável (que pode ser analisado) • Arquivos (todos abertos) • Assinatura e plist • É um ZIP normal, pode ser aberto e analisado inteiramente, sem restrições
• Copie um IPA (iPhone Package Archive) • Troque para ZIP (rename) • Faça unzip normal • Diretório Payload / <Aplicativo.app> • No Finder Show Package Contents
pois os aplicativos são organizados assim, mesmo que no Xcode seja diferente • O _CodeSignature contém a assinatura • Diretórios de localização (lang.lproj) • Executável Aplicativo (p.ex. Dropbox) • Arquivo Mach-O executable arm
e ajustes de um aplicativo está aberto e livre para leitura • É comum o Info.plist ser usado para ajustes do próprio desenvolvedor (eu faço muito esse tipo de “ajuste dinâmico” pra facilitar múltiplos targets e configurações • Alguns resources são “otimizados”
em “binários Mach-o” • Não apenas em aplicativos, mas também no próprio sistema operacional (através da imagem do firmware). Daí saem os tweaks • Pode ser feito com ferramentas do próprio SDK como otool (man otool / man nm) • Pode ser facilitado: Hopper
diretórios “especiais” em seu sistema de arquivos isolado: • Documents: arquivos normais (backup) • Cache: caching (removidos às vezes) * • Temporary: tmp (removidos sempre) • Bundle: o caminho do aplicativo read-only * Na prática acaba ficando em Library/Caches ao lado de outras coisas internas em Library
são acessíveis de fora... mesmo com o aparelho bloqueado e com senha • Exemplo: iExplorer • Mostra Media (fotos, músicas, etc.) do aparelho e Apps (todos os aplicativos, seus dados estáticos, seus dados dinâmicos dentro do sandbox) • Solução: Data Protection (DP)
e 100% transparente entre aplicativo (in-memory) e dados (storage) • Sem impacto de desempenho (ou não chega a ser mensurável) • Precisa ser ligado pelo desenvolvedor (está para se tornar um padrão no iOS 7) • Depende de senha no aparelho, pois a senha é usada na criptografia (que é transparente)
engine) para a memória flash • IV é o resultado de um LFSR calculado com o offset do bloco no arquivo, criptografado com hash SHA-1 de uma chave por arquivo • Cada arquivo tem uma classe diferente de criptografia dependendo da forma com que o conteúdo é acessado (tabela a seguir) • O wrapping é via NIST AES (RFC 3394)
acesso de um conteúdo: • Complete Protection: criptografado logo que o usuário bloqueia o aparelho e o acesso é liberado ao desbloquear • Protected Unless Open: acessível parcialmente enquanto aberto, mesmo com aparelho bloqueado (p.ex., anexos de email) • No Protection: sem nenhuma proteção
também é importante garantir que a comunicação seja segura com comunicações externas (p.ex, um aplicativo com Webservices) • Em iOS não existe o conceito de Webservices e sim uma combinação de coisas: REST/JSON com requisições HTTP, por exemplo • Da mesma forma genérica, TLS/SSL suporta protocolos, inclusive HTTP (aka HTTPS)
contempla de forma transparente (automática) todas as questões envolvendo TLS/SSL (validações) • Por padrão, comunicação HTTPS com certificados inválidos são inclusive não aceitos, sendo necessário “liberar” • Certificados auto-assinados também são considerados certificados inválidos • Há uma lista de CAs roots válidos: https://support.apple.com/kb/ht5012
do aparelho (mais sobre perfis e configurações em breve) • É possível um aplicativo adicionar um CA para sua própria validação (isolado) • É possível fazer validação de duas vias para garantir integridade de comunicação • Lembrando: criptografia TLS/SSL pode ser “quebrada” facilmente com MITM * * SSL/TLS resolve privacidade, integridade, outros
erro se uma conexão SSL/TLS detectar problemas de certificados, por exemplo (inválido), já prevenindo MITM • Mesmo assim, é possível: • Desligar o suporte a verificação (inseguro) • Ligar veficicação para duas vias
• Exige implementação (suporte) no servidor • Se instalado no sistema já é usado por aplicativos do sistema (Apple) • Aplicativos 3rd-party precisam carregar certificado (p12) e enviar explicitamente • Apple provê um exemplo excelente na documentação oficial (exemplifica o Apache)
techniques with NSURLConnection. Specifically, it demonstrates how to respond to authentication challenges, how to modify the default server trust evaluation (for example, to support a server with a self-signed certificate), and how to provide client identities • Um pouco confuso mas completo em funções mais elaboradas da NSURLConnection
Trust Services • Keychain Services • Randomization Services • Secure Transport (SSL “raw”) • Sempre são interfaces (APIs) em C mas em geral bem simples (p.ex SecRandomCopyBytes)
• Codesigned • Limitação de APIs e recursos • Uso de Data Protection • Uso de Keychain • Cuidados com caching (novo) • Uso de CommonCrypto (hash) • Uso de SSL (padrão) lendo cer
felipek
mochizuki875
hanhan1978
qt_luigi
rssytems
oomatomo
bengo4com
excdinc
aiandrox
righttouch
loglass2019
rayuron
zigorou
philnash
kastner
jakevdp
keathley
thekraken
vanstee
csswizardry
eileencodes
morganepeng
tammyeverts
speakerdeck
bryan
![Segurança iOS Felipe Kellermann - @felipek http://felipek.com - [email protected] http://nyvra.net](https://files.speakerdeck.com/presentations/d1af05600176013178384228df31dccf/slide_0.jpg){kind=link}
