Save 37% off PRO during our Black Friday Sale! »

Segurança - iOS

Segurança - iOS

Slides de um mini curso sobre Segurança iOS.

D42a279f980e29b74fa467b6c3d86f29?s=128

Felipe Kellermann

September 17, 2013
Tweet

Transcript

  1. Segurança iOS Felipe Kellermann - @felipek http://felipek.com - felipek@me.com http://nyvra.net

    / http://negotti.com
  2. Tópicos • iOS e Arquitetura Geral • Overview Desenvolvimento e

    Publicação • Segurança de Informações (Exemplos) • Mecanismos de Segurança (APIs) • Gerenciamento de Aparelhos • Exemplos Práticos (Aplicativos Seguros)
  3. Instrutor • Felipe Kellermann - FK - @felipek • http://felipek.com

    (pessoal) • http://nyvra.net (empresa) • http://negotti.com (produto) • http://horadomac.com (podcast) • felipek@me.com (email) • Passado: Linux/segurança (netfilter, busybox, relacionados). Hoje: iOS
  4. Material • Estas anotações (slides) • Tutorial Objective-C Moderno •

    Tutorial MDM (Profile Manager) • Principais referências Apple • Alguns papers e apresentações
  5. Curso • Discussão geral sobre segurança envolvendo iOS e seus

    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
  6. Segurança iOS

  7. iOS e Arquitetura Geral • Sobre o Sistema Operacional “iOS”

    • 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? ...
  8. Overview Desenvolvimento e Publicação • Funcionamento de Aplicativos Nativos •

    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
  9. Segurança de Informações (Exemplos) • Proteção de Dados de Aplicativos

    • 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
  10. Mecanismos de Segurança (APIs) • Mecanismos Data Protection (DP) •

    Chaves: Keychain • Comunicação segura (TLS/SSL) • Security.framework • Certificate, Key, and Trust Services, Keychain, Randomization Services, Secure Transport • CommonCrypto
  11. Gerenciamento de Aparelhos iOS • Segurança Corporativa • Perfis de

    Configuração (Profiles) • Sobre o Mac OS X Server • Sobre o Server Profile Manager • O Que Pode Ser Gerenciado • Explorando o Ambiente
  12. Exemplo Prático (Aplicativo Seguro) • Projeto para Exemplo • Privacidade

    dos Dados do Usuário • Acesso a Informações do Usuário • Engenharia Reversa e Informações • Comunicação Segura (Webservices)
  13. iOS e Arquitetura Geral

  14. Sobre iOS • Sistema Operacional móvel e proprietário baseado no

    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
  15. Sobre iOS • Originalmente chamado "iPhone OS" ou apenas "OS

    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"
  16. Sobre iOS • Em 2008 na versão 2.0 o iOS

    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)
  17. Versões iOS Versão Características 1.0, 2007 Versão de lançamento do

    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
  18. Aparelhos e Hardware • Todos os hardwares rodam o mesmo

    iOS: • iPhone • iPod • iPad • Apple TV (fechado) • Criptografia por hardware: iPhone 3GS+ acompanhado do iOS 4+
  19. Arquitetura e Aplicativos • Divisão entre camadas: Cocoa Touch, Media,

    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
  20. Arquitetura e Aplicativos Camadas iOS - Fonte: iOS Technology Overview

  21. Arquitetura e Aplicativos • Camadas superiores abstraem questões como sockets

    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)
  22. Arquitetura e Aplicativos • Aplicativos Nativos são executados diretamente no

    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)
  23. Arquitetura e Aplicativos Desenvolvimento iOS - Fonte: iOS Technology Overview

  24. Aplicativos iOS • Um aplicativo é um executável ligado a

    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”)
  25. Segurança Geral Layout - Fonte: iOS Security

  26. Segurança Geral • O sistema é dividido em 2 partições

    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
  27. Segurança Geral • Esquema chain of trust • Hardware só

    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)
  28. Identificação Universal • Do iOS 1 até o iOS 5:

    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
  29. Acesso a Informações Pessoais (privacidade) • Do iOS 1 até

    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
  30. Comunicação (IPC?) • Em resumo: não existe IPC na realidade

    • 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)
  31. IPC: URL Schemes • Aplicativos registram URL Schemes (iOS 3+)

    • 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
  32. IPC: Clipboard • Área de transferência simples (iOS 3+) •

    Classe UIPasteBoard (generalPasteboard) • Pode ser escrito por qualquer aplicativo • Pode ser lido por qualquer aplicativo • É possível ligar/desligar para campos (texto)
  33. IPC: Documentos • Um aplicativo passar arquivos para outros •

    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)
  34. IPC: iTunes • Aplicativo “registra” (no plist) que aceita receber

    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
  35. IPC: Keychain • Pouco conhecido e pouco usado * •

    Á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
  36. Push (Remoto) • Push seria um ótimo “vetor de ataque”

    • 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)
  37. Push (Remoto) APNS - Fonte: Local and Push Notification Programming

    Guide
  38. Push (Remoto) Tokens - Fonte: Local and Push Notification Programming

    Guide
  39. Push (Remoto) Trust - Fonte: Local and Push Notification Programming

    Guide
  40. Pagamentos (IAP) • Onde há pagamentos, há fogo :-) •

    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
  41. Pagamentos (IAP) Comunicação - In-App Purchase Programming Guide

  42. Pagamentos (IAP) • Arquitetura similar APNS (Push): StoreKit • Toda

    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/
  43. Pagamentos (IAP)

  44. Pagamentos (IAP)

  45. Sandbox • Todos os aplicativos do iOS são enjaulados em

    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)
  46. Logs (Console) • Os aplicativos podem fazer um “printf” ou

    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)
  47. Acesso Físico • Até a versão 7, o acesso físico

    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)
  48. Backups • Os backups podem ser locais (no iTunes) gerando

    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
  49. Hardware • Existe um hardware engine de criptografia • Não

    é 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
  50. Demonstração (Pythonista)

  51. Demonstração (Terminal / Jailbreak)

  52. Overview Desenvolvimento e Publicação

  53. Desenvolvimento iOS • iOS SDK: Ferramentas pra desenvolver, instalar, rodar

    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
  54. Desenvolvimento iOS • Existem aplicativos híbridos tendo parte nativa, parte

    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”
  55. Desenvolvimento iOS • Frameworks são bibliotecas compartilhadas e relacionados (ligadas)

    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)
  56. Xcode Instruments - Fonte: iOS Technology Overview

  57. Aplicativos Nativos • Os Aplicativos Nativos são desenvolvidos em linguagem

    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
  58. Linguagem Objective-C • Linguagem predominantemente usada e mantida pela Apple

    (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)
  59. Linguagem Objective-C • A linguagem Objective-C não é muito distante

    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.
  60. Linguagem Objective-C • Não é raro ter partes do SDK/APIs

    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
  61. Linguagem Objective-C Referências • Objective-C Moderno • Tutorial do Felipe

    (eu) • Programming With Objective-C • Apple • The C Programming Language • K & R (aka Os Profetas)
  62. Publicação Distribuição - Fonte: App Distribution Guide

  63. Publicação • Aparelhos com iOS executam apenas aplicativos assinados •

    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
  64. Publicação • Diferente de outros sistemas operacionais no mercado, não

    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.
  65. Jailbreak • O jailbreak tem justamente o objetivo de rodar

    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.
  66. Jailbreak • Cada “geração” de jailbreak se valia de problemas

    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)
  67. Developer Program • Para assinar um aplicativo e rodar em

    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)
  68. Developer Program

  69. Developer Program • Existem três variações do programa: • Individual:

    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
  70. Benefícios do Programa • Acesso completo a material de apoio

    • Acesso a versões beta (em NDA) • Tickets (restritos) de suporte • Assinatura de desenvolvimento (cabo) • Assinatura para Ad Hoc (betas) • Assinatura para App Store
  71. ADC e iTC • ADC é o Apple Developer Center,

    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
  72. ADC e iTC

  73. ADC e iTC • Boa parte das coisas era feita

    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
  74. Certificados, Identificadores e Perfis • Conceitos importantes são: Certificados, Identificadores

    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
  75. Certificados, Identificadores e Perfis Certificados - Fonte: App Distribution Guide

  76. Certificados, Identificadores e Perfis Provisionamento - Fonte: App Distribution Guide

  77. Bundles Bundles - Fonte: App Distribution Guide

  78. Entitlements • Conjunto de “permissões” para serviços • Um aplicativo

    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
  79. Deploy • O deploy de um aplicativo pode ser feito

    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
  80. Deploy • Como mencionado anteriormente, um aplicativo só roda em

    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
  81. Deploy • Cada conta de desenvolvedor tem direito a até

    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”
  82. Deploy Deploy - Fonte: App Distribution Guide

  83. Segregação de Funções • O “time” de desenvolvedores pode ter

    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
  84. Segregação de Funções Roles - Fonte: App Distribution Guide

  85. Segregação de Funções • Além de usuários e divisões de

    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
  86. Segregação de Funções Usuários - Site: iTunes Connect

  87. Segregação de Funções • Usuários (membros) no ADC / Provisioning

    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
  88. Xcode / Organizer

  89. Segurança de Informações (Exemplos)

  90. Proteção de Dados de Aplicativos • Sugestão: programe como se

    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
  91. Engenharia Reversa • Um aplicativo (IPA) é apenas um ZIP

    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
  92. Engenharia Reversa • Um IPA como um ZIP (no Mac):

    • Copie um IPA (iPhone Package Archive) • Troque para ZIP (rename) • Faça unzip normal • Diretório Payload / <Aplicativo.app> • No Finder Show Package Contents
  93. Engenharia Reversa • Todos os resources (assets) ficam na raiz

    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
  94. Engenharia Reversa • O arquivo Info.plist que define o “start”

    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”
  95. Engenharia Reversa • Surpresa: Engenharia reversa é possível e comum

    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
  96. Engenharia Reversa • Hopper: The Multi Platform Disassembler, Decompiler and

    Debugger
  97. Debugging / FairPlay • É possível “simbolicar” crash logs •

    dSYM • symbolicate / atos • Aplicativos App Store são criptografados • FairPlay - exceto debugger (gdb) com JB • class-dump http://stevenygard.com/projects/class-dump/
  98. Jailbreak • Além de debugger (gdb), jailbreak permite outras coisas

    • Exemplo: ios-ssl-kill-switch https://github.com/iSECPartners/ios-ssl-kill-switch http://nabla-c0d3.github.io/blog/2013/08/20/ intercepting-the-app-stores-traffic-on-ios/ • dumpdecrypted https://github.com/stefanesser/dumpdecrypted http://www.sensepost.com/blog/6254.html
  99. Dados do Usuário • Os aplicativos iOS no sandbox têm

    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
  100. Dados do Usuário • Todos os conteúdos/arquivos gravados pelos aplicativos

    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)
  101. Dados do Usuário

  102. Dados do Usuário

  103. Data Protection • Criado como um mecanismo para criptografia “on-the-fly”

    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)
  104. Data Protection • Criptografia 100% transparente direto via hardware (AES

    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)
  105. Data Protection Data Protection - Fonte: iOS Security

  106. Data Protection • As classes definem as diferentes necessidades de

    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
  107. Data Protection Classes - Fonte: iOS Security

  108. Proteção de Dados de Comunicação • Além dos dados armazenados,

    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)
  109. Comunicação SSL/TLS • Todo o suporte HTTP do iOS já

    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
  110. Comunicação SSL/TLS • É possível adicionar novos CAs nas configurações

    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
  111. Mecanismos de Segurança (APIs)

  112. Data Protection • Suportado no iOS 4 ou superior •

    Atributos de arquivo (filesystem) NSDictionary *attrs = @{ NSFileProtectionKey : NSFileProtectionComplete }; [[NSFileManager defaultManager] setAttributes:attrs ofItemAtPath:path error:&error];
  113. Keychain • Keychain: Keychain Services Reference • API em C:

    SecItemAdd, SecItemUpdate, ... • Apple: Keychain Services Tasks for iOS • Apple: GenericKeychain • Recomendação de “wrapper”: SSKeychain ... [SSKeychain setPassword:pwd forService:srv account:acc error:&error]; ... ... NSString *pwd = [SSKeychain passwordForService:srv account:acc error:&error]; ...
  114. Comunicação TLS/SSL • Por padrão NSURL* já faz validações retornando

    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
  115. SSL/TLS inseguro • É uma busca comum na Internet •

    Certificados auto-assinados são inválidos • Não deixa de ser uma necessidade válida para testes/validação (#if DEBUG) • - (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace { return [protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]; } - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge { if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) { [challenge.sender useCredential:[NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust] forAuthenticationChallenge:challenge]; } [challenge.sender continueWithoutCredentialForAuthenticationChallenge:challenge]; }
  116. SSL/TLS Super Seguro • Verificação de duas vias (client-side certificate)

    • 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)
  117. SSL/TLS Super Seguro • AdvancedURLConnections • Demonstrates various advanced networking

    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
  118. Security.framework • Engloba funções vistas anteriormente: • Certificate, Key, and

    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)
  119. CommonCrypto • API (CC) em C para funções “comuns” de

    criptografia simétrica, hash, outros • Open Source: http://opensource.apple.com/source/CommonCrypto/ • Exemplo: CCCryptor • Exemplo de wrapper ObjC: RNCryptor
  120. Gerenciamento de Aparelhos iOS Material complementar (sobre MDM)

  121. Exemplo Aplicativo • Lembrando Arquitetura iOS: • Sandbox (kernel enforced)

    • 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