Vulnerabilidade no Mysql e no MariaDB

Vulnerabilidade

 

No dia 09/06, Sergei Golubchik  postou na lista de segurança oss-sec sobre uma nova vulnerabilidade encontrada no MariaDB e no Mysql, que recebeu o nome de CVE-2012-2122.

 

VULNERABILIDADE

 

Quando um usuário tenta se conectar a um banco MySQL ou MariaDB, à senha aplica-se um algoritmo SHA  e “soma-se” uma string randômica qualquer e, então, compara-se o valor obtido com o valor esperado.

O protocolo utilizado assume que a  função memcmp, utilizada na comparação, deve retornar um valor entre -128 e 127. Em algumas configurações, tal função pode retornar um valor diferente de zero, fora deste intervalo.

Ou seja: a comparação é considerada válida mesmo que uma senha qualquer, diferente da real, seja fornecida.  Como o protocolo utiliza strings randômicas a cada tentativa, a probabilidade de que este erro ocorra é de 1/256.

Isso significa que, se soubermos previamente um usuário do sistema (muitos bancos possuem o usuário root) e fizermos diversas tentativas de senhas  quaisquer, podemos conseguir acesso privilegiado ao sistema muito rapidamente (levando-se em consideração que podemos fazer centenas de tentativas por segundo, o acesso é conquistado com muito pouco esforço).

 

QUEM ESTÁ VULNERÁVEL?

 

A vulnerabilidade resume-se a sistemas que possuem a rotina memcmp()  retornando valores fora do intervalo citado anteriormente e isto não ocorre com tanta frequência. O caso mais comum é quando o GCC utiliza a otimização SSE, mas, de acordo com Sergei, na maioria dos casos esta rotina é compilada como uma função inline. 

Alguns sistemas foram considerados vulneráveis, geralmente com as versões 5.1.61, 5.2.11, 5.3.5 e 5.5.22 do MySQL e MariaDB. Mas, para se ter certeza, um simples teste pode ser feito.

Joshua Drake criou um simples programinha em C++ capaz de verificar se o sistema está ou não vulnerável.

Quem souber inglês e quiser ler e obter mais informações, acesse o post original e o post do HD Moore, criador do Metasploit, na comunidade do mesmo.

Um abraço a todos e até a próxima!

 

 

Olá pessoal,

eu estou disponibilizando pra vocês um trabalho em formato de artigo da SBC e uma apresentação sobre segurança em cloud computing. Quem quiser dar uma olhada, fique a vontade. Se quiser usar a apresentação pode ficar a vontade também, mas de os devidos créditos.

 

Até a próxima,

 

Igor.

Artigo

Apresentação

Introdução as Redes de Computadores – Modelo OSI

Bom, eu vou pular a estorinha da evolução do computador, primeiro porque já li isso mais de 1000 vezes e acho que vocês também e segundo porque gosto de ir direto ao ponto. O fato é que quando se começou a pensar em redes de computadores, muitas empresas, como a IBM, apareceram com soluções proprietárias, que incluíam software e hardware. Uma vez escolhida a arquitetura de uma empresa, apenas computadores que estivessem operando sobre essa arquitetura poderiam se comunicar. Esse tipo de restrição era inaceitável por uma série de razões, como no exemplo a seguir:

Suponha que a empresa A use a arquitetura de rede fornecida pela empresa E1 e a empresa B use a arquitetura de rede da empresa E2. Suponha agora que a empresa A compre a empresa B. Uma vez que as redes das empresas A e B utilizam diferentes arquiteturas, elas não poderiam se comunicar, levando a empresa A a decisão de ou mudar para a arquitetura da empresa E2 ou mudar a rede da empresa B para a arquitetura da empresa E1.

Com o objetivo de sanar este tipo de problema, a ISO criou o modelo de referência OSI. O modelo OSI adota a ideia da divisão e conquista para resolver o problema extremamente complexo que é o transporte de dados de um host origem até um host destino. Para tanto, tal modelo estabelece 7 camadas, cada uma só podendo se comunicar com a camada imediatamente acima ou abaixo. A imagem abaixo ilustra as 7 camadas do modelo OSI.

As 7 camadas do modelo OSI

As 7 camadas do modelo OSI.

  •  Camada de aplicação (camada 7): a maioria das aplicações que necessitam trocar informações entre sistemas finais remotos precisam faze-lo transmitindo a informação de uma maneira estruturada. O que eu quero dizer com isso é que a informação precisa ser montada em uma estrutura bem conhecida pela aplicação, de modo que quando a informação chegar na aplicação do sistema final destinatário, esta saiba como interpreta-la. A maneira como essas informações são estruturadas, transmitidas e interpretadas, constitui um protocolo. Uma vez que a aplicação interage diretamente com este protocolo, este é dito pertencente à camada de aplicação. É importante notar que a aplicação em si não faz parte da camada de aplicação, mas sim os protocolos que fazem a interface estre a aplicação e as camadas mais baixas. Podemos citar como exemplo os navegadores web. Se você já criou uma página web ou baixou uma da internet, você sabe que o navegador é capaz de exibir páginas web independentemente de você estar conectado a alguma rede ou não ou mesmo de você ter ou não qualquer protocolo ou interface de rede na sua máquina. Isso ocorre pois o navegador possui um módulo de renderização de páginas html, onde as tags são interpretadas e o resultado é a exibição da página. Por outro lado, quando você requisita uma página que está num servidor web remoto, o navegador passa a fazer uso do protocolo HTTP (sem contar a resolução de nomes DNS) para enviar uma requisição ao servidor web remoto, que por sua vez conhece o protocolo HTTP e sabe interpreta-lo. Exemplos de protocolos pertencentes a camada de aplicação são: HTTP, DNS, FTP, SMTP, etc.
  • Camada de Apresentação (Camada 6): a camada de apresentação, como seu nome sugere, é responsável por apresentar os dados à camada de aplicação e traduzir dados oriundos da camada de aplicação com destino a aplicação em um sistema remoto. Uma vez que as aplicações podem ser executadas em sistemas diferentes, é importante que os dados sejam formatados de uma maneira que o sistema em questão possa interpretar ou exibir corretamente. Assim, os dados oriundos da camada de aplicação podem ser traduzidos para um formato padrão da rede e então quando chega na camada de apresentação do sistema destinatário, os dados são então traduzidos para o formato correto para aquela aplicação. Além disso essa camada pode também fornecer serviços de compressão e descompressão e criptografia dos dados.
  • Camada de Sessão (Camada 5): a camada de sessão é responsável por criar, gerenciar e terminar sessões entre as aplicações. No momento em que as sessões são criadas, entra em cena mais um serviço dessa camada que é o gerenciamento do diálogo entre as aplicações. É definido o modo de comunicação, que pode ser :simplex, full-duplex ou half-duplex. Basicamente, esta camada é responsável por manter os dados das diferentes aplicações separados. Exemplos de protocolos desta camada são: Network File System (NFS), Structured Query Language (SQL), Remote Procedure Call (RPC), etc.
  • Camada de Transporte (Camada 4): para que uma aplicação possa enviar informações para outra, a primeira precisa utilizar uma porta lógica de origem e a aplicação de destino precisa escutar em uma outra porta lógica de destino. A camada de transporte é responsável por transmitir os dados da porta de origem até a porta de destido. Os dados oriundos da camada de sessão são segmentados e remontados, reunindo esses dados e um mesmo fluxo de dados. Fatores como alto congestionamento, inteferência eletromagnética e diferenças nas velocidades de transmissão e processamento dos diversos dispositivos dispostos entre a origem e o destino podem causar erros nos bits dos dados enviados e até mesmo a perda dos mesmos. Visando contornar esse problema, a camada de transporte pode fornecer o serviço de transporte confiável de dados, utilizando para tanto uma conexão lógica entre as aplicações de origem e destino (serviço orientado a conexão) juntamente com o sequenciamento dos segmentos enviados e a confirmação dos recebidos. Ainda fazem parte dos serviços que podem ser oferecidos por essa camada o controle de fluxo e congestionamento e a detecção e correção de erros. O protocolo TCP implementa todos esses serviços e por isso é mais indicado para aplicações sensíveis a perdas e que podem tolerar um atraso maior na trasmissão. Já aplicações multimídia e de tempo real são sensíveis a atrasos, mas podem sofrer uma taxa razoável de perda sem que isso comprometa o serviço. Para essas aplicações, indica-se o uso do protocolo UDP, que é simples e só implementa os serviços básicos de segmentação dos dados e transporte fim-a-fim.
  • Camada de Rede (Camada 3): a camada de rede é responsável pelo endereçamento lógico das redes. Esse endereçamento é utilizado quando o sistema final de origem que transmitir dados para um sistema final destinatário que está fora de sua rede. Dessa forma, dizemos que o pacote deve encontrar um caminho da rede origem até a rede destino, o que significa dizer que o pacote deve ser roteado de sua origem até o seu destino. O dispositivo principal da camada 3 é o roteador. As diferentes interfaces de um roteador formam diferentes domínios de colisão e diferentes domínios de broadcast, o que significa que cada interface do roteador pode ser dita uma rede distinta. Uma vez que um pacote chega em um roteador, este deve verificar se o mesmo é endereçado a ele, caso não, o roteador precisará decidir pra qual interface de saída ele repassará o pacote. Essa decisão é tomada com base na tabela de roteamento do roteador, que define mapeamentos de prefixos de endereços lógicos (Ip por exemplo), para interfaces de saida. Tais tabelas são geradas e atualizadas através da execução de algoritmos de roteamento. Além das funções de repasse e roteamento, um roteador pode desempenhar a função de filtragem de pacotes, permitindo assim que somente pacotes com determinadas propriedades sejam repassados.
  • Camada de Enlace (Camada 2): a camada de enlace tem a função de converter os dados oriundos da camada de rede em bits, com o objetivo de facilitar a transmissão dos mesmos pelo meio físico. Nesta camada os dados são formatados como quadros (frames) e possuem um cebeçalho específico. Uma vez que muitos sistemas finais podem transmitir dados no mesmo segmento, é possível que duas transmissões simultâneas ocorram, o que gerará interferência entre os sinais, conhecida como colisão. Para evitar as colisões, os dados não podem ser repassados para o meio físico sem gerenciamento, ficando esta função, portanto, com a camada de elance. Protocolos são executados para abitrar quem pode transmitir em um determinado momento. Além do endereçamento lógico desempenhado pela camada de rede, existe também o endereçamento físico desempenhado pela camada de enlace. Equanto o endereçamento lógico é utilizado para transmitir dados através de redes, o endereçamento físico é utilizado para transmitir dados a dispositivos dentro da mesma rede. Cada interface de rede possúi um número único que o identifica. Esse número é conhecido como endereço MAC.
  • Camada Física (Camada 1): esta é a camada que transporta realmente os bits em um link físico. Esse transporte pode ocorrer através de voltagem elétrica através de um fio, espectro de luz (fivras óticas) ou através de modulações de rádio.

Uma vez que a informação a ser transportada pela rede começa o seu caminho de cima para baixo pela pilha de camadas, os dados são montados no que o modelo OSI chamou de PDU (Protocol Data Unit). Por exemplo, a camada de aplicação gera os dados a serem transferidos -> a camada de apresentação faz a função de tradução -> a camada de sessão estabelesse o diálogo entre as aplicações -> a camada de transporte encapsula os dados em segmentos -> a camada de rede recebe os segmentos e monta pacotes/datagramas tendo na sua parte de dados o segmento -> a camada de enlace encapsula os pacotes em quadros que são então trasmitidos para a camada física. Após chegar no seu destino, cada camada analisa o cabeçalho do seu pdu e passa a parte de dados para a camada de cima. Ou seja, o pdu é a estrutura mínima que a a camada é capaz de analisar:

Camada —- PDU

4                 Segmento

3                 Pacote / Datagrama

2                 Quadro

1                  Bit

 

Bom pessoal, é isso ai, espero que tenha sido esclarecedor. Até o próximo post.

 

<<< Parte Anterior

Dica – Comparando registros no Windows

Boa noite, pessoal! Esse post é somente uma dica básica de como comparar dois arquivos .reg no Windows.

Digamos que você tenha instalado um programa e queira saber quais modificações foram feitas no registro. Para fazermos essa verificação utilizaremos o comando fc.exe (file compare), do Windows. Para tal, basta seguirmos os seguintes passos:

  1. Antes de instalar o programa, abra o regedit.exe, vá em Arquivo > Exportar, exportando, digamos, para um arquivo de nome regAntes.reg.
  2. Instale o programa;
  3. Exporte novamente o registro para um segundo arquivo (regDepois.reg , por exemplo).
  4. Abra o command (cmd) e digite o seguinte comando, estando no mesmo diretório onde foi exportado o registro (caso tenha exportado para o diretório C:\, basta digitar o comando cd C:\ ):

fc /u regAntes.reg regDepois.reg > comparacao.txt

O /u indica que a comparação deve ser feita em Unicode.

Segue abaixo um printscreen demonstrativo.

Um grande abraço e até a próxima!

Introdução as Redes de Computadores – Visão Geral (Parte 2)

Olá pessoal, depois de um longo tempo sem postar no blog consegui um tempinho para finalmente escrever a segunda parte dessa introdução às redes de computadores. Neste post vou falar basicamente sobre a diferença entre comutação de pacotes e de circuitos, explicando cada um dos dois.

  1. Comutação de circuitos x comutação de pacotes.

Sabemos que o computador é uma tecnologia relativamente recente e que a interconexão dos mesmo através de arquiteturas de redes é ainda mais recente. Porém, antes mesmo de se pensar em redes de computadores e consequentemente em internet, as redes de telefonia fixa já existiam a um bom tempo. Essas redes utilizavam o processo chamado de comutação de circuitos, que era responsável por enviar dados de voz através de um aparelho telefônico a outro. Tempos mais tarde, com o surgimento da internet, foi adotado o processo de comutação de pacotes, que tem objetivo semelhando ao da comutação de circuitos, mas a forma pela qual esse objetivo é alcançado é bastante diferente.

Comutação de Circúitos: a idéia básica da comutação de circuitos é que quando um sistema final precisa transmitir dados, este deve criar um circuito entre ele e o sistema final destinatário. Este circuito nada mais é do que uma conexão entre os dois sistemas finais, onde os recursos da rede(buffers, banda, etc.) são reservados para a conexão. Dessa maneira, uma vez que a largura de banda de cada enlace no caminho do circuito é reservada, é possível transmitir dados a uma largura de banda fixa. Como veremos mais tarde em outro post, o TCP é um protocolo que exige o estabelecimento de uma conexão (three-way-handshake) andes de transmitir dados. Entretanto, o TCP exige que apenas os sistemas finais estejam cientes dessa conexão, deixando o núcleo da rede completamente alheia a esta. No caso da comutação de circuitos, não só os sistemas finais precisam estar cientes da conexão, como também os comutadores precisam estar.

Uma vez que aplicações de tempo real como a telefonia são sensíveis ao atraso(mas não a perda de dados), seria mais interessante utilizar comutação de circuitos nesses casos, já que como a largura de banda é reservada, o atraso no recebimento dos dados é fixo fazendo com que o jitter(como veremos em um post futuro, o jitter é a variação estatística do atraso) seja 0. Entretanto, hoje em dia existem inúmeras aplicações multimídia que rodam em cima da internet. A grande sacada foi desenvolver protocolos de camada de aplicação(veremos o modelo em camadas no próximo post) mais inteligentes a ponto de conseguir amenizar os problemas causados pelo atraso variável oriundos da comutação de pacotes.

Comutação de pacotes: é o modelo utilizado pela internet. Com a comutação de pacotes, nenhuma conexão precisa ser estabelecida entretanto, como não há reserva de banda, um pacote que precise ser repassado para um enlace que está ocupado transmitindo outro pacote, deverá entrar na fila de espera pelo acesso ao enlace, o que pode gerar  atrasos. Além dos atrasos, sabemos que a memória onde a fila de espera é implementada é finita, se esta crescer de mais pode chegar ao esgotamento, o que irá causar perdas de pacotes.

Já que não há reserva de banda, se o enlace está livre, um sistema final pode transmitir seus pacotes na taxa total do enlace. Já sabemos que dois sistemas finais não estão conectados diretamente através de um único enlace. No lugar disso, são interconectados através de roteadores, que tem a função de receber um pacote por uma de suas interfaces e repassa-lo para outra de suas interfaces. Tantos nas interfaces dos sistemas finais, quanto nas interfaces de saída dos roteadores, se um pacote a ser transmitido para o enlace encontra o mesmo ocupado pela transmissão do outro pacote, este deve esperar o fim desta para iniciar aquela. Um pacote espera pela sua vez de ser transmitido em um buffer conhecido como fila de saída. Se a taxa de repasse do roteador for muito maior que a taxa do enlace, a fila pode aumentar indefinidamente. Uma vez que a fila é implementada em uma memória no hardware, está não é infinita e se a fila aumentar demais, cedo ou tarde a memória se esgotará. Se um pacote a ser repassado encontrar a fila cheia, um dos pacotes da fila, ou o pacote recém chegado precisará ser descartado.

Multiplexação na comutação de circuitos.

Sabemos que um enlace de comunicação é feito de materiais cujas propriedades físicas interferem diretamente na taxa de bits que podem ser transmitidos pelo mesmo. Visto isso, podemos concluir que a largura de banda total de um enlace é fixa e um hospedeiro pode transmitir seus dados na largura de banda total do enlace, ou dividi-la com outros hospedeiros. No caso da comutação de circuitos, a largura de banda total do enlace é compartilhada entre os diversos circuitos que por ele passam. Cada enlace na comutação de circuitos tem n circuitos, ou seja, pode suportar até n conexões simultâneas. Assim, cada circuito terá uma fração 1/n da largura de banda total do enlace.

Existem 2 maneiras de dividir(multiplexar) o enlace em circuitos: FDM e TDM

FDM(frequency-division multiplexing): nesse modelo, cada circuito no enlace transmite dados em uma determinada frequência. Assim, quando o circuito é estabelecido, a frequência correspondente ao mesmo é estabelecida e toda a rede(sistemas finais e comutadores) precisam estar cientes disso. Assim, a frequência total de transmissão de um enlace é dividida em um spectro de frequências, cada uma utilizada por um circuito.

TDM(time-division multiplexing): esse modelo pode ser visto como uma fila de pessoas esperando para descer num escorregador. Supondo que nós passemos a observar a fila no tempo 0 então, se numerarmos as pessoas na fila, teremos que a pessoa 1 escorregará no escorregador no tempo 1, a pessoa 2 escorregará no tempo 2 e assim sucessivamente até a pessoa n. Depois que todas as pessoas escorregarem, zeramos o tempo de modo que na próxima vez que a pessoa 1 escorregar, ela p fará também no tempo 1. Dessa maneira, a pessoa 1 sempre escorrega no tempo 1, a pessoa 2 no tempo dois e a pessoa n no tempo n. Fazendo uma comparação entre a atividade de escorregar no escorregador e a de transmitir dados, temos que cada circuito(pessoa) transmite dados(escorrega) no seu determinado tempo. Assim, o enlace(escorregador) é multiplexado, fazendo com que cada circuito(pessoa) transmita dados(escorregue) em seu determinado tempo. Esses tempos são chamados de compartimentos(slots) e o conjunto de todos os compartimentos, que representa uma quantidade de tempo fixa, é conhecido como quadro(frame). Isso significa que após as conexões terem sido estabelecidas, se o circuito pode transmitir 8000 quadros por segundo e cada compartimento tem 8 bits, então a taxa de transmissão do circuito será de 64Kb/s.

TDM

Figura 1 - Exemplo de TDM com 3 slots e 3 frames

Um problema simples de se perceber tanto com o FDM quanto com o TDM são os chamados períodos de silêncio. Períodos de silêncio são períodos onde por alguma razão não se está transmitindo dados através de um circuito(selêncio). A pesar da inatividade da conexão, todos os recursos reservados para ela continuam sem poder serem utilizados por outros hospedeiros, o que gera disperdício de recursos da rede.

<<< Parte anterior    Próxima Parte >>>

ara qualquer dúvida ou sugestão podem enviar um email para igorcompuff@gmail.com.

Obrigado a todos e até o próximo post.

Forense no Firefox – parte 1

Boa noite, pessoal! Neste post eu pretendo falar um pouco sobre forense no Firefox, o famoso navegador da Mozilla.

Nesta primeira parte falarei sobre o arquivo places.sqlite, mais especificamente sobre as tabelas moz_inputhistory , moz_places e moz_historyvisits. Delas podemos obter algumas informações bastante interessantes e, portanto, acredito que este seja um bom ponto de partida. Espero que gostem!

FERRAMENTAS UTILIZADAS


SQLite3 -> Essa ferramenta pode ser baixada para os sistemas operacionais GNU/LINUX, MAC OS e Windows, no site: http://www.sqlite.org/download.html

 Para quem não conhece, esta é uma ferramenta de linha de comando muito simples e que utilizaremos para fazer nossas consultas às tabelas dos bancos de dados citados neste post.

Para este post eu utilizo o Firefox 4 –  que pode ser baixado no próprio site da Mozilla http://br.mozdev.org/ – rodando sobre o Windows 7.


DIRETÓRIOS


Segue abaixo uma lista dos diretórios utilizados:

Windows 7 (e Vista):

  • C:\Users\<Usuário>\AppData\Roaming\Mozilla\Firefox\Profiles\*********.default
  • C:\Users\<Usuário>\AppData\Local\Mozilla\Firefox\Profiles\*********.default\Cache
Linux
  • ~/.mozilla/firefox/*********.default/
Em caso de não encontrar o diretório, basta abrir o Firefox, ir em Ajuda -> Dados para Suporte -> Abrir Pasta (Pasta do Perfil).
 

                                                                                                                                                                                                                                                                                                       MÃO NA MASSA


Para começarmos nossa análise, utilizaremos o arquivo places.sqlite que o firefox utiliza para guardar todo o histórico de navegação do usuário. Abrindo o arquivo com o sqlite3 e utilizando o comando “.tables“, nós podemos ver o nome das tabelas desse banco de dados. Neste artigo falaremos um pouco sobre algumas delas.

No site FirefoxForensics há um diagrama representando a relação entre as tabelas.

                                                                                                                                                                                                                                                                                                          A TABELA moz_inputhistory


Sempre que visitamos um site, um registro é inserido na tabela moz_places. Ao digitarmos alguma coisa na barra de endereços do navegador, o Firefox procura nesta tabela algum site que esteja relacionado com o que estamos digitando, exibindo – logo abaixo da barra de endereços – a URL, um título e um ícone para o site referente. Se clicarmos nesta sugestão, um registo é inserido na tabela moz_inputhistory. 

Nesta tabela há somente três campos.

  • places_id: uma chave estrangeira que referencia uma entrada na tabela moz_places;
  • input: é a “string” que foi digitada pelo usuário e que foi utilizada – ou seja, o usuário digitou tal string e depois clicou na sugestão fornecida pelo firefox;
  • use_count: a quantidade de vezes que o usuário utilizou esse input.

Para exemplificar farei duas visitas ao blog UFForense digitando as string “uff” e “foren”. Logo depois, farei uma consulta à tabela moz_inputhistoruy utilizando o sqlite3.

 

                                                                                                                                                                                                                                                                                                 Gostaria de fazer três observações importantes. Primeiramente vale ressaltar que todas estas informações são referentes a um determinado usuário. Cada usuário do sistema terá um diretório referente ao seu perfil em Profiles. Em segundo lugar, esta tabela é importante pois nos mostra que o usuário visitou o site digitando alguma coisa na barra de endereços (ou seja, voluntariamente). E por último, se o endereço for digitado completamente, não será adicionada uma entrada nesta tabela.                                                                                                                            

                                                                                                                                                                                                                                                                                                          A TABELA moz_places

                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

                                                                                                                                                                                                                                                                                                    Como mencionado anteriormente, a tabela moz_places contém informações sobre o histórico de sites visitados pelo usuário.

Alguns campos são auto-explicativos. O id é a chave-primária da tabela, que é referenciada em muitas outras tabelas (inclusive na moz_inputhistory), url é o endereço propriamente dito e title é o título exibido pelo firefox. Abaixo segue uma descrição dos outros campos:

  • rev_host:   Este campo contém o “host name” ao contrário, terminado em “.” (ponto final). Portanto, em nosso exemplo, o site “ufforense.wordpress.com” ficaria “moc.sserpdrow.esneroffu.”. A explicação da importância deste campo está no código fonte. Lá podemos perceber que esta coluna é mantida para que se possa fazer uma busca de endereços mais “parecidos”, similares ou que contenham o domínio.
  • hidden:   indica se a URL foi realmente acessada pelo usuário ou se a mesma foi acessada indiretamente. Ou seja, ela pode estar presente em imagens ou por alguma referência.
  • typed:   lembra que quando o usuário começa a digitar na barra de endereços, ele pode digitar o endereço completo ou simplesmente clicar na sugestão? No segundo caso a tabela moz_inputhistory é atualizada. Já no primeiro é a tabela moz_places que recebe a atualização.
  • favicon_id:   referencia um ícone que está armazenado como BLOB na tabela moz_favicons.
  • frecency:  é a combinação das palavras em inglês “frequency” e “recency” que indica o quão frequente e o quão recentemente o site foi acessado. Para quem tiver curiosidade em olhar o algoritmo, basta acessar este site.
  • last_visit_date: contém o último tempo de acesso.
  • visit_count: indica quantas vezes o site foi visitado. Seu valor não será incrementado quando o firefox estiver configurado para Restaurar janelas e abas da sessão anterior e o usuário estiver abrindo o firefox. Ele também não será incrementado com “refresh” da página.
Repare que o campo last_visit_date contém a última vez que o usuário visitou o site. Mas o campo visit_count pode indicar que tal site pode ter sido visitado mais de uma vez. Sendo assim, como podemos obter um “log” completo de todas as visitas do usuário ao longo do tempo? Para conseguirmos isso, faremos uma consulta à tabela moz_historyvisits.
                                                                                                                                                                                                                                                                                                         A TABELA moz_historyvisits
                                                                                                                                                                                                                                                                                                            
                                                                                                                                            
A coluna from_visit indica o site (id da própria moz_historyvisits) que foi utilizado para acessar o site atual. Como exemplo, digamos que eu faça uma busca no google pelo nosso blog e o acesse por lá. A figura abaixo demonstra os resultados… 
 
                                                                                                                                                                                                                                                                                                     Repare que o site 2211 (UFForense) foi acessado através do site de id 2251 (google).
O Firefox armazena informações referentes a tempo em variáveis do tipo PRTime. Ela possui 64 bits, ao contrário do formato padrão do Unix e seus cálculos são baseados em microsegundos, ao contrário do UNIX que é em segundos. Reparem na figura acima que o tempo vem como um valor inteiro muito grande. Para transformar este número em algo legível para nós, devemos utilizar o comando “datetime” do próprio sqlite. (Acesse este site para mais informações). Como o incremento está em microsegundos, quando fizermos alguma consulta utilizando datetime, os dados do tipo PRTime devem ser divididos por 1.000.000.
Agora já possuímos informações suficientes para conseguir um log completo das visitas do usuário. Basta fazermos a seguinte consulta.
                                                                                                                                                                                                                                                                                                       select moz_places.url, datetime((moz_historyvisits.visit_date/1000000), ‘unixepoch’, ‘localtime’) from moz_places, moz_historyvisits where moz_historyvisits.place_id = moz_places.id order by moz_historyvisits.visit_date desc;

Exemplo de consulta a moz_places e moz_historyvisits

                                                                                                                                                                                                                                                                                                           
Por fim, a coluna visit_type nos fornece uma informação muito importante. Ela indica como o usuário chegou a este endereço. As opções são:
  1. O usuário utilizou algum link;
  2. O usuário digitou todo o endereço ou utilizou o auto-completar;
  3. utilizou o favoritos;
  4. utilizou uma “embedded url”;
  5. usuário redirecionado permanentemente;
  6. redirecionado temporariamente.
  7. Download.
No exemplo onde fazemos a busca do blog pelo google, o visit_type para o google aparece como 6 e para o UFForense aparece com o valor 1.
Bem, por hoje é só. Até o próximo post. ^^

Resultado da Primeira apresentação

Boa noite, pessoal! ^^

Gostaria de fazer alguns comentários sobre a apresentação de hoje.

Eu, particularmente, gostei muito do resultado. Tivemos um feedback muito bom de cada um dos participantes e todos demonstraram interesse pela proposta do grupo. Todo mundo expôs suas ideias e sugestões para que o grupo possa crescer e melhorar.

Nesta nossa primeira reunião, contamos com a presença de 11 (onze) pessoas, além de mim e da Carol.  Algumas pessoas não puderam comparecer, mas todas elas confirmaram presença nos próximos encontros.

Foto tirada no final da apresentação

Começamos contando um pouco da história do grupo, claro, explicando nossas ideias e objetivos. Logo depois a Carol falou sobre a área de Segurança e eu sobre a parte de Computação Forense. Apresentamos alguns temas que serão abordados, como SnortMetasploit Framework, testes de penetração, nmap, hardening  e muitos outros assuntos. Batemos um papo sobre a organização do grupo e chegamos a conclusão que, a priori, faremos reuniões quinzenais e, cada um que estiver interessado, poderá criar sua apresentação para que possamos debater sobre o tema abordado. No final da apresentação, cada um se apresentou e falou um pouco sobre o que espera das reuniões.

O encontro teve uma duração aproximada de duas horas e ainda, logo depois, tivemos uma conversa animada movida a pastéis, refrigerantes e ideias sobre parcerias e encontros paralelos com o pessoal do Dojo UFF – só para citar um exemplo.

Espero que todos tenham gostado e que este seja apenas o primeiro de muitos e muitos encontros.

Abraço a todos!