root@devnull # prtdiag
System Configuration: Sun Microsystems sun4u Sun Fire V490
System clock frequency: 150 MHz
Memory size: 16384 Megabytes

================ CPUs ================

Run E$ CPU CPU
Brd CPU MHz MB Impl. Mask
--- ----- ---- ---- ------- ----
A 0, 16 1500 32.0 US-IV+ 2.2
A 2, 18 1500 32.0 US-IV+ 2.2

No passado dia 2 deste mês, o confronto entre spammers e um serviço anti-spam tomou proporções gigantescas levando a diversos danos colaterais dentro da estrutura da internet.

Ao que parece um spammer profissional achou que o serviço da bluesecurity que combate o SPAM está a ter bastante sucesso tendo como consequência imediata uma menor receita económica da sua actividade como spammer, com tal decidiu fazer um ataque cerrado á empresa.

A solução que a bluesecurity apresenta para o SPAM passa por combater a sua origem, ou seja, quem paga para que haja SPAM, o mesmo será dizer, as empresas que vêm referidas nos ditos mails. Sendo assim, quando é detectado um mail de SPAM, transparentemente e automaticamente o serviço envia um mail a essa empresa avisando que não pretende receber mais emails seus (o direito aos opt-outs)
Este processo faz com que as empresas mencionadas nos mails de SPAM sejam elas próprias inundadas por mails.

O ataque protagonizado pelo "PharmaMaster" teve basicamente 3 fases, a primeira passou por enviar mails á comunidade onde se afirmava que o serviço não cumpria os seus objectivos pois o próprio mail era exemplo disso mesmo. Provavelmente este método não teve grande sucesso o que fez o spammer passar á segunda fase.

Foi esta fase que me despertou a atenção para o assunto, pois o atacante conseguiu isolar a Bluesecurity ao seu país de origem, Israel, ou seja, o site apenas conseguia ter acessos de ligações vindas do próprio país. Na altura toda a informação que tinha disponível sobre o assunto era que o atacante tinha conseguido fazer um blackhole filtering algures nos routers da linha internacional do ISP nacional da Bluesecurity.

Um blackhole filtering em termos práticos não passa da colocação de uma routa que envia todo o tráfego de determinado host/network para um device dummy. Comecei a pensar como é que o spammer tinha conseguido tal feito e vinha-me três situações á cabeça:

1) O atacante tinha de certa forma hackados os routers

2) O atacante tinha realizado um ataque DDoS aos routers em que spoofou a source dos packets com o IP do site da Bluesecurity, e os administradores do backbone acharam por bem defenderem-se do ataque colocando uma backhole, o que me parecia uma decisão irresponsável pois é sabido que em protocols UDP e ICMPS este spoof é trivial.

3)O atacante tinha realizado um ataque DDoS ao próprio site da BlueSecurity e os administradores do backbone de modo a se preservarem a largura de banda da sua rede e o bom funcionamento dos seus outros clientes, abdicaram de servir o IP da Bluesecurity colocando o blackhole filtering. Esta teoria foi posta logo de parte quando os administardores da Bluesecurity afirmaram que não tinham sido vitimas de nenhum ataque DDoS.

Afinal o "PharmaMaster" não fez nada disto, usou os seus contactos sociais e convenceu um "amigo" que possui poderes de administração nesses router para introduzir o blackhole.

# [tier-1 ISP name withheld] says: Yes wont be a problem, i'll make sure to block all traffic to this domain very soon just get me reports mate"
# [tier-1 ISP name withheld] will block traffic to your websites god i love this war :)"

Se isto realmente aconteceu, que tipo de "profissionais" temos nós a administrar importantes backbones da internet, e ninguém realizou um traceroute de modo a identificar qual dos ISP's tava a fazer drop da rota e posteriormente responsabilizar a empresa? weird...


Depois de isolados do resto do Mundo, a Bluesecurity decidiu colocar um CNAME no nameserver de modo a apontar para um blog (http://bluesecurity.blogs.com) seu alojado na Six Apart, e aqui começou a terceira fase do ataque. O spammer decidiu lançar um DDoS baseado em syn flood para os servidores da Six ApArt e aos nameservers da Tucows de modo a que a BlueSecurity ficasse sem qualquer "expressão" online, isto levou a que vários milhares de máquinas tivessem os seus serviços inacessíveis durantes várias horas.

UPDATE(2006/05/17): And the winner is .. THE SPAMMERS.
Blue Security close it's doors.

Apesar da actual falta de tempo para seguir mais atentamente assuntos relacionados com segurança informática, esta última vulnerabilidade encontrada no servidor de X não poderia deixar de a referir, mesmo passadas cinco semanas.
O interessante desta vulnerabilidade é o contexto a que lhe deu origem, ou seja uma distracção do programador que levou a que utilizadores locais possam ganhar acesso root. O patch é tão rídiculo quanto isto:

/* First the options that are only allowed for root */
- if (getuid() == 0 || geteuid != 0)
+ if (getuid() == 0 || geteuid() != 0)
{
if (!strcmp(argv[i], "-modulepath"))
{
@@ -1677,7 +1677,7 @@
}
if (!strcmp(argv[i], "-configure"))
{
- if (getuid() != 0 && geteuid == 0) {
+ if (getuid() != 0 && geteuid() == 0) {
ErrorF("The '-configure' option can only be used by root.\n");
exit(1);
}

Ora, o programador esqueceu-se dos "()" na função geteuid, e como tal em vez comparar o valor que a função retorna está a comparar com o valor da zona de memória da função, como é impossível esta ser zero a proposição lógica do "if" será sempre verdadeira. Estranho é que o programador faz este erro duas vezes.
Apesar de ambos os statements serem válidos em C, parece-me que o compilador deveria dar um warning quando se compara o valor da memória da função com zero pois isso é impossível, já que este nem sequer é um ponteiro para função.

Depois existe aqui aquele strcmp que muito provavelmente não terá consequências a nivel da exploração do overflow do mesmo, mas custa assim tanto usar um strncmp?

Um assunto que tem vindo a ser frequentemente abordado nas conversa mundanas é certamente a Blogosphere. Um estudo recente apontava que cerca de 60% dos portugueses que utilizam a Internet regularmente têm por hábito vistar blogs, o que me leva a afirmar, que os blogs já fazem parte do quotidiano de muitas pessoas.

O mediatismo nem sempre é um sinal positivo, e a comprová-lo está o ataque dos spammers a estes serviços, e os métodos usados têm vindo a ser cada vez mais sofisticados.

Existem algumas razões para o My little place não possuir SPAM:

1- O site não possuí muitos referers.

2- O site não usufruí dos conhecidos serviços que fornecem a possíbilidade de alojar um blog.

3- O site utiliza software próprio para publicar os conteúdos, o que dificulta o processo automático de publicação do Posts por parte dos Bots.

Apesar disto, e influenciado pelo post do João Bordalo, decidi implementar o sistema CAPTCHA no site. Optei por uma implementação simples de PHP+GD e posteriormente fui testar ao projecto PWNtcha a ver se este conseguia "descodificar" a imagem o que não veio a acontecer, para minha surpresa, visto que a imagem é bastante simples comparada com algumas que o site possuí como exemplos de sucesso:

./pwntcha: image size 110x35, 2 colours
./pwntcha: probably a scode/trencaspammers captcha
./pwntcha: don't know about checksum 511
./pwntcha: don't know about checksum 1085
./pwntcha: don't know about checksum 1085
./pwntcha: don't know about checksum 665
./pwntcha: don't know about checksum 909
9?????

E aproveitando que tinha a mão no código, alterei a sequência das páginas de modo a que a indexação dos motores de busca não fica-se obsoleto com o tempo.