« Older Entries Subscribe to Últimos Posts

14 Feb 2012

Crimes Eletrônicos — Implicações Legais

Postado por Elzo Brito. Nenhum Comentário

14 Feb 2012

Crimes Eletrônicos — Implicações Legais

Postado por Elzo Brito. Nenhum Comentário

14 Feb 2012

Pedofilia e Internet: Gisele Truzzi no programa "Fala Sério"

Postado por Elzo Brito. Nenhum Comentário

14 Feb 2012

VideoCast com a Dra. Gisele Truzzi – Direito Digital e a Operação AntiSegurança

Postado por Elzo Brito. Nenhum Comentário

Espero que gostem…

14 Feb 2012

Falha em bilhete único em SP

Postado por Elzo Brito. Nenhum Comentário

Hoje resolvi postar uma coisa diferente, foi descoberto que o bilhete único de SP contém uma falha de segurança meio grotesca, segue abaixo o texto postado no http://pastie.org/3375325 divirtam-se com com cautela =]

—————————————————————————————————

Engenharia reversa Bilhete Único (Full Disclosure)

Decidi fazer full disclosure, por não achar que o problema não é uma vulnerabilidade e sim uma escolha deliberada de usar chaves padrão para proteção do bilhete unico.

O Cartão é o MIFARE CLASSIC 4K. Os dados são organizados em setores, cada setor com 4 blocos de 16 bytes.
O primeiro bloco eh read-only e tem o UID do cartão + dados do fabricante do cartao
O ultimo bloco de cada sector sempre tem as chaves a e b e o direito de acesso. O ultimo sector estar organizado mais ou menos assim (olhar um hexdump qualquer):

chave A direitos chave b
—————– ———- —————-
a0 a1 a2 a3 a4 a5 08 77 8f 69 b0 b1 b2 b3 b4 b5

exemplo de como os dados são organizados no cartão

0000000 9a 49 37 b1 50 08 04 00 62 63 64 65 66 67 68 69 bloco 0, sector 0: uid do cartão 9a4937b1, dados do fabricante 0804006263646566676869
0000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bloco 1, sector 0
0000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..
0000030 ff ff ff ff ff ff ff 07 80 69 ff ff ff ff ff ff bloco 3, sector 0: chave a, direitos de acesso e chave b
0000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bloco 0, sector 1
0000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..
0000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..
0000070 a0 a1 a2 a3 a4 a5 08 77 8f 69 b0 b1 b2 b3 b4 b5 bloco 3, sector 1: chave a, direitos de acesso e chave b

ferramentas usadas para ler e escrever dados no cartão:

* Um leitor de cartão (para mim as melhores são baseadas no chip PN532) um exemplo: http://www.adafruit.com/products/364
* mfoc (nfc-utils)
* nfc-mfclassic (nfc-utils)
* hexedit e vimdiff

O grande problema é que foram utilizada as chaves padrões e por isso em menos de 30 minutos o MFOC conseguiu recuperar todas as chaves para criptografar todos os setores. Por conta disso é possivel, se recarregar o cartão, fazer um backup dos dados, usar todo o cartão e gravar novamente o backup salvo no cartão. grau de dificuldade: 0.

testes que foram realizados:

p.s: vale salientar que nenhuma vez o cartão foi utilizado depois de carregar o backup no cartão. Só validamos o cartão nos pontos de verificação de saldo.

* Carregar novamente backup no mesmo cartão
* compramos o cartão novo, fizemos um backup, usamos o cartão até o fim, carregamos o backup novamente no cartão e o saldo estava lá novamente.

* Clonar o cartão em outro cartão virgem
* o backup pode ser copiado em outro cartão. É preciso no backup somente alterar o ID do cartão para o ID do cartão virgem, uma vez que essa área do cartão é read-only.

Porque até hoje eu não liberei estas informações?

Pois para mim, esse erro era esperado uma vez que, não é nenhuma surpresa, as empresas brasileiras, não ligarem a mínima para segurança. Outro ponto é que foi publicado na mídia que alguém "descobriu" isso, mas não foi revelado como. Para mim mais importante do que o disclosure conciente é o full disclosure, principalmente nos sistemas que afetam o dia-dia dos cidadãos. Outro ponto importante é que pessoas de outros estados e cidades, possam testar os próprios sistemas.

Tentei por meses, sem sucesso, entender o layout dos dados, ou como os dados são organizados no cartão. Infelizmente sem sucesso tb. O melhor teste aqui é, comprar um cartão carregado, gerar um dump, usar o cartão, gerar um novo dump e comparar quais campos mudaram. Algumas coisas que descobri:

Sector 0, Sector 1, Sector 2 não há mudança
Sector 3 e Sector 4 são repetidos

o sector 3, block 3 guarda ou valor ou timestamp. isso porque ao usar 2 x ônibus no mesmo dia e sem cobrar de novo (dentro de período de 1 hora) os primeiros 7 bytes não mudaram. somente o ultimo (que pode ser a casa dos minutos em um timestamp ou um CRC para validar campo)

solução sugerida:

bom primeiro ponto sem duvida nenhuma é alterar as chaves default de criptografia dos cartões. Muito interessante é como fazer isso, sem impactar os clientes.

Outro ponto que evita a clonagem de cartão é manter uma base de cartão autorizados e fazer essa validação na hora em que o usuário tentar usar o cartão. O desafio aqui é como diariamente (via batch) ou online (duvido que os ônibus estão conectados a alguma rede, acredito que toda a operação é off-line).

de qualquer forma, pesquisadores Brasileiros, mãos a obra, não é possível que um sistema tão falho, ficou tanto tempo no ar. Precisamos olhar os sistemas ao nosso redor e procurarmos entender como eles funcionam e como pode ser burlados e melhorados. (hint: Urna Eletrônica)

Abraços

Alguém

7 Nov 2011