Questão de segurança?

A opção de alguns sites permitirem o reset da password somente respondendo a uma pergunta predefinida, poderá facilitar o abuso desta funcionalidade por quem conheça a pessoa em causa ou tenha simplesmente acesso ao seu perfil no facebook.

Senão vejamos alguns exemplos dessas perguntas que permitem o reset imediato da password da conta:

  • Qual a tua data de nascimento?
  • Qual a tua cor favorita?
  • O nome da tua mãe?
  • O nome da tua professora primária?
  • O nome do teu animal de estimação?

Quantas destas questões não estarão respondidas nos vossos perfis do facebook ou linkedin? Certamente muitos terão lá a sua data de nascimento, a sua filiação, o seu percurso educativo e muitas outras informações pessoais que poderão servir para responder às questões standard que permitirão o reset da password.
Um caso mediático deste tipo de situações deu-se com as famosas fotos da Scarlett Johansson que circularam na Net, onde tudo começou com a resposta a uma dessas “security questions”.

Por isso é que aconselho para nunca darem respostas corretas quando se depararem com estas opções, sugerindo que essa resposta sirva como outra password forte. Porque não poderemos responder que a nossa cor favorita é ‘psi~cLoDs*mew37fiD’?

Fica aqui a ideia.

Panopticlick


Será que mesmo sem cookies os sites nos conseguem rastrear?

O projeto Panopticlick da EFF (Electronic Frontier Foundation) vem provar que somente utilizando a informação disponibilizada pelo nosso browser eles conseguem obter um somatório bastante distinto e único que poderá servir de identificador de um utilizador (ou pelo menos de um PC). Esta fingerprint de cada browser poderá rondar nos 21 bits de informação e para já deu para identificar mais de 2 milhões de cenários singulares.

Visitem e confiram em https://panopticlick.eff.org/

Funcionamento das fechaduras cilíndricas

Um tema que me suscitou interesse há uns meses foi o funcionamento das fechaduras e também a “arte” de abrir portas sem utilização das chaves e sem deixar vestígios de arrombamento – que em inglês se costuma designar por lockpicking.

O funcionamento da maioria das fechaduras cilíndricas mais comuns (Yale locks) são baseadas num mecanismo muito simples! Normalmente são compostas por um conjunto de 3 a 6 pares de pinos de comprimentos variáveis, assentes em canais que atravessam o cilindro central, empurrados na parte superior desses canais por pequenas molas e somente com a correta posição das ranhuras da chave nesses pinos é que o cilindro central consegue rodar e abrir/fechar a fechadura.

Mais do que tentar explicar por palavras julgo que as seguintes desenhos permitem ter uma perceção mais eficiente do funcionamento dessas fechaduras:


Exemplo de fechadura com 5 canais.


A impossibilidade de abrir a fechadura com a chave incorreta deriva de todos os pares de pinos não estarem na posição correta.


Ao inserir a chave certa, os pares de pinos alinham com o cilindro central.


Esse alinhamento permite rodar o cilindro, abrindo a fechadura.

Existem diversas técnicas para abrir este tipo de fechaduras, como a bump key, a lock pick gun ou a utilização de ferramentas (vulgarmente chamadas em Portugal como gazuas) que permitem com alguma perícia alinhar todos pinos e rodar o cilindro.

Em artigos futuros explicarei algumas destas técnicas e tentarei também informar alguns dos métodos que permitem dificultar ou resolver estas falhas.

Entretanto podem sempre pesquisar no Youtube por lockpicking e confirmar com que rapidez algumas das fechaduras conseguem ser abertas!

CommandKungFoo: ‘lscpu’ ou ‘cat /proc/cpuinfo’

Uma forma rápida de obter mais informações sobre o(s) CPU(s) da máquina:
lscpuou
cat /proc/cpuinfo

Exemplos de outputs desses comandos:

# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 37
Stepping: 5
CPU MHz: 1199.000
BogoMIPS: 4787.92
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 3072K
NUMA node0 CPU(s): 0-3

# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model : 9
model name : AMD Opteron(tm) Processor 6136
stepping : 1
cpu MHz : 2400.000
cache size : 512 KB
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch
bogomips : 4800.00
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:

Hashes


A notícia já não é nova, mas a divulgação de quase 6,5 milhões de hashes das passwords de contas do Linkedin veio trazer novamente para as conversas técnicas a necessidade de implementação das melhores soluções no que diz respeito à salvaguardar das passwords dos utilizadores.

Mas o que é uma hash?
Uma hash pode ser caracterizada como uma impressão digital de um pedaço de dados. É uma função matemática unidirecional, não revertível, que pega num conjunto de dados e converte-o numa string de tamanho fixo. É impossível recuperar o texto/dados originais depois de convertidos, mas existem inúmeros sites com extensas base de dados de hashes e o texto que o deu origem:

Salted hashes?
Se a hash de um texto dará sempre o mesmo resultado, a solução para tornar essa hash sempre única poderá passar por adicionar-lhes um texto aleatório – o chamado salt. Este deverá ser guardado conjuntamente com a hash para se conseguir futuramente comparar o resultado da hash da password com o salt.

Um exemplo rápido:
A hash SHA-1 da string ‘changeme’ é fa9beb99e4029ad5a6615399e7bbae21356086b3 e será sempre esta.
Se adicionarmos o texto/salt ‘random’ à string ‘changeme’ (ficando ‘randomchangeme’) a hash será 7df51186f50d1bcd11df64a7db86cafc19ddddff.
Se em vez de ‘random’, o texto adicionado for ‘qqcoisa’ (ficando ‘qqcoisachangeme’) a hash já será 0e84f7268b565d884d48af9f3b38b53415c3330e.

E o que podemos aprender com a divulgação das hashes do Linkedin?
A utilização de sha1 já à muito que não é suficiente para garantir a segurança das passwords armazenadas. E mesmo que um site ainda utilize sha1 ou md5, não há razões para que essa alteração não se consiga efetuar sem interrupção no serviço e sem constrangimentos para os utilizadores. Aqui fica o meu fast and darty hack para essa migração: quando o user se validar, guardar a sua password temporariamente, passá-la pela nova solução (sha2 + salt, bcrypt, scrypt, PBKDF2, …), apagar a velha hash e somente utilizar a nova solução para autenticações futuras.
Esperemos que o Linkedin tenha aprendido a lição e que isto tenha também servido de alerta para outras empresas que ainda utilizam unsalted sha1.

Podcast PaulDotCom Security Weekly

Tentarei que este seja o primeiro de uma série de artigos sobre alguns dos podcasts que estão na minha playlist.

Para mim foi fácil decidir quem deveria ser o primeiro podcast a divulgar. É claro que teria que ser o PaulDotCom Security Weekly, porque é atualmente o meu podcast favorito.

Este podcast, que se iniciou em 2005 e conta já com quase 300 episódios, foca muitos temas de segurança em IT, contando com entrevistas, notícias e segmentos técnicos. As entrevistas são muito bem conduzidas e já passaram por lá grandes personalidades do meio como o Fyodor (nmap), HD Moore (metasploit), Kevin Mitnick e Bruce Schneier, entre muitos, muitos outros. O Paul Asadoorian e a sua “crew” conseguem tornar as quase 2 horas que alguns episódios têm de duração numa divertida mas muito informativa conversa entre amigos, cativando o ouvinte até ao último segundo com os seus conteúdos sempre atuais e com algum humor “apurado” (nota: às vezes esse humor não é aconselhável a ouvintes mais sensíveis).

O podcast tem uma dinâmica muito própria que advém do à-vontade mas também know-how de todos os intervenientes e de cuidada pré-produção e pós-produção que não costuma falhar.

Os links para Podcast e algumas informações sobre o mesmo:
PaulDotCom – www.pauldotcom.com
Podcast – itunes.apple.com/podcast/pauldotcom-security-weekly
Show notes – pauldotcom.com/wiki/index.php/Show_Notes

Outros podcasts da minha atual playlist seguirão em posts futuros, porém gostaria de descobrir novos podcasts e para isso vocês podem deixar aqui comentários sobre os podcasts que seguem e recomendam.

Itanium: HP vs Oracle


A história é simples de contar: A Oracle decide acabar com o desenvolvimento de novas versões da sua base de dados para os processadores Itanium da Intel e a HP contra-ataca em tribunal.

É certo que a equação “Oracle + HP-UX + Itanium” é um nicho de mercado, mas esta decisão da Oracle é uma machadada muito grande para os servidores Mission Critical da HP que correm sobre HP-UX.

A Oracle alega que o processador está a ser descontinuado (algo que a HP e a Intel negam) e por isso achou-se no direito de acabar com o desenvolvimento para Itanium. A HP alega que a Intel desenvolverá novos processadores Itanium até 2022 e que a Oracle deveria continuar a portar as novas versões para esta plataforma.
A HP está neste momento atacar em duas frentes: Nos EUA (California) a HP está a alegar a violação de contrato e na Europa a HP requereu a abertura de dois processos anti concorrenciais, alegando que a medida tomada pela Oracle tem como objetivo condicionar o seu negócio de hardware, levando a que os clientes optem por hardware da Sun.

É certo que o mercado dos Itanium é cada vez mais diminuto, e ainda mais depois dos anunciados planos da Microsoft e da Redhat em abandonar o suporte para estes processadores, mas a HP não vai abdicar deste nicho de mercado e fica visível que quer tentar demover a Oracle desta decisão. É obvio que acabando o suporte das base de dados Oracle sobre Itanium/HP-UX os clientes vão ser obrigadas em migrar e nada invalida que aproveitem também para alterar também de plataforma de hardware/SO, passando de Itanium/HP-UX para, por exemplo, Xeon/Linux ou até Sparc/Solaris.

Os próximos meses certamente terão novidades sobre este tema.

CommandKungFoo: ‘xargs kill’ com ‘egrep’

Na continuação dos meus anteriores posts “QLC – Quick Linux Commands” decidi (e inspirado também no site commandlinefu.com) decidi continuar com estes tipo de posts onde apresentarei pequenos hacks e comandos úteis em Linux. Desta vez vou-lhes começar a intitular ‘Command Kung Foo’.

O primeiro desta serie será um Kung Foo útil quando necessitamos “matar” todos os processos com um determinado padrão e o killall não nos ajuda:

ps -ef | egrep ‘<regular expression>’ | awk ‘{print $1}’ | xargs kill

Desmembrando esta solução:

  • ps -ef: lista todos os processos;
  • egrep: filtra pela expressão regular desejada;
  • awk ‘{print $1}’ : obtém os PIDs dos processo filtrados;
  • xargs kill : executa o kill para cada um do PIDs.

De volta!!

Mais de 2 anos desde o último post neste blog e decidi agora voltar a escrever neste cantinho cibernético!

Muitos podem argumentar que o declínio dos blogs foi generalizado e que se deveu principalmente ao crescimento exponencial do Facebook, twitter e de outras redes sociais e de partilha de informação/conteúdos (como o youtube, intagram, google+), mas no meu caso o afastamento deveu-se também à falta de tempo e também à perda de motivação e de objetivos concretos que tinha inicialmente definidos para este blog.

Continuo a achar que existe uma falta de blogs verdadeiramente tecnológicos em português que foquem alguns temas que são muito pouco visíveis por estas bandas. Por isso decidi recentrar os temas principais deste espaço em torno de assuntos que me são fáceis de explorar e que me deem algum prazer em escrever. Poderão, por isso, voltar a encontrar posts sobre Linux, Unix, gadgets, Internet e segurança. Um tema que tentarei explorar mais será o da segurança… em diversas amplitudes: seja segurança informática ou física, bugs, vulnerabilidades e vírus, mas também ‘social engenering’ e privacidade (ou a falta dela).

Nota Final: Outra alteração neste blog será a adoção do novo acordo ortográfico nos novos posts. Pessoalmente posso não gostar das alterações implementadas neste AO, mas uma vez que o processo está em andamento e não vai parar, mais vale começar a habituar-me aos novos tempos.