Porque servidores de universidades são tão falhos?

removido
(usa Nenhuma)

Enviado em 07/06/2016 - 20:45h

NOTA À (OMITIDO): Eu quero deixar bem claro que absolutamente NENHUM DANO foi causado da minha parte e que eu não tive nenhuma intenção de incentivar o cracking e qualquer tipo de ataque, ah não ser informa-los e apresentar possíveis melhorias e também usar este material produzido por mim como tema de debate à assuntos relacionados a Segurança da informação exclusivamente aqui neste tópico e em nenhum outro site, também não foi feito o download de nenhuma informação do sistema.
O e-mail contendo as respectivas informações sobre as vulnerabilidades foi extremamente detalhado e se for entendido que o ocorrido mereça alguma medida judicial sendo tratado como crime (o que ao meu ver é extremamente desnecessário, visto que minha intenção claramente foi ajudar e em nenhum momento prejudicar), foi enviado outro e-mail para o setor de informática com nota especial pela minha advogada explicando minuciosamente o que foi dito por mim acima entre parênteses, para que qualquer mal entendido seja resolvido sem a necessidade de intervenções judiciais se solicitada por parte da empresa em questão não citada ou insinuada por mim em nenhum momento neste tópico, sendo este tópico não referente a nenhuma instituição e, ou empresa atualmente existente. :)

Tópico anteriormente removido por questões de uso de imagem/informação privada não autorizada, famoso "Exp0sed information".

Obrigado Fábio Berbert de Paula pela consideração, que contatou-me via e-mail, comentando um trecho de texto em que os responsáveis relatavam que algumas informações em meu tópico (como endereços e nomes) denegria a imagem e incentivava crimes cibernéticos, e também facilitaria ataques (facilitaria ainda mais ataques) ao servidor em questão. Pois bem, omitido informações de imagem privada; repostarei o tal tópico.

Originalmente postado domingo, no dia: 05/06/2016
Então pessoal, venho com um assunto polêmico aqui.
Antes de tudo, pelo titulo pode parecer que estou generalizando, mas esse não é o caso.
Conversando com uns colegas no irc que manjam dos paranauê, trocando infos e etc. Começamos a discutir o porquê de servidores de universidades serem frequentemente invadidos por hackers. Nessas conversas cheguei a uma conclusão que faz parte da minha opinião pessoal.

Comumente servidores de faculdade hospedam muitos sites, sendo eles de professores, projetos pessoais de funcionários, projetos de terceiros, sites informativos, sites de outras áreas da universidade e inclusive sites feitos pelos próprios acadêmicos.
Em um dos meus pentests de rotina, eu encontrei um servidor da (OMITIDO) vulnerável permitindo rodar comandos por local file inclusion, na plataforma web.
Tendo em mente o fato de servidores de universidades (nem todas) hospedarem todo tipo de porcaria de seus alunos/funcionários eu pensei comigo: "Essa não pode ser a única falha, vou perder um tempo checando outros sites do servidor"
E BOOM, cada site checado usando linguagem web, havia no mínimo um script vulnerável (não vou entrar em detalhes da vulnerabilidade porque acho que seria um desrespeito mais com os moderadores do VoL que perderiam um tempo apagando meus posts) então eu tive certeza da minha conclusão.
Na shell do bixinho fui checar a versão do kernel, 3.16.*; não tenho nada pra esse kernel, legal... for now, dei um exit na shell.
Fui checar no zone-h o histórico do IP e para minha surpresa, veja só:

Mais de 4 hackers já vinham fazendo uma zoeirinha no servidor.
Checando a segunda página do zone-h vi que o servidor já era um velho alvo, e os administradores fodões, técnicos especialistas com superior e a po.rra toda, não haviam obtido sucesso no securing do servidor em 4 (QUATRO!) anos, então eu percebi a minha facilidade em cair em uma shell.
Dando uma olhada nas index dos caras (dos defacers) percebi que continua rodando o mesmo sistema, com o mesmo kernel... beleza, nem me aprofundei em procurar as falhas do Debian Jessie por ora.
Conectei na minha porta mágica (hehe), e por curiosidade rodei um:



Vamos tentar descobrir a intenção do administrador com esse raio de permissão...
Chutando um cálculo rápido aquii, acho que essa é uma permissão 774, como você pode observar: owner e grupo tem permissão total e outros tem permissão apenas de leitura, até ai... ta tudo certo, é uma permissão relativamente segura.
MAS veja o mistake; o grupo é "users" e a permissão do grupo é total! e o premio é a permissão especial suid! PQP admin, onde que tu aprendeu a fazer uma coisa tão legal dessas HAHA.
Por algum motivo o user root setou a permissão errada no grupo. Como o grupo é users, a permissão deveria ser apenas r ou 4 de leitura (ou o grupo não deveria ser users!), e não rwx ou 7, sacou? pulta mistake que pode valer a vaga de administrador do especialista responsável.

Fui checar o grupo do usuário local, e veja só:


Não me pergunte o porquê do usuário www-data estar nesses grupos (como um usuário de desktop comum), sem comentar que eu poderia tranquilamente rodar um "shutdown -h now".

Bom, você deve estar se perguntando: "Mas que tanso! porque não spawna logo uma shell root nesse tal "sqlrevise.sh"?"
Porque shell script por security reasons infelizmente não permite o uso de suid (também não sei porque esse arquivo estava com permissão suid).

De qualquer maneira, decidi tentar um "hard link attack" me baseando em uma possível vuln na GNU C library, usando as permissões desse tal "sqlrevise.sh", ficando assim:

poderia ter usado um outro binário qualquer com permissão suid? poderia, mas se o admin começou a fazer o securing do servidor foi removendo as permissões suid default do Debian. HAHA


Shell crashed.
É, definitivamente a glibc versão 2.19-18 não é vulnerável a code execution.
Tentativa inspirada no paper: https://www.exploit-db.com/exploits/15274/

Minha conclusão final:
Sim, servidores de faculdade são extremamente falhos sem um especialista que realmente sabe o que faz no terminal como administrador.
Não foi difícil conseguir um acesso, visto que a plataforma web estava vulnerável a SQLi e LFI, permitindo code execution pelo usuário local do servidor, foi fácil instalar meu backdoor.

Não sei como funciona esse sistema de virtual hosts em servidores de grande porte como de universidades, se é feito algum tipo de revisão no conteúdo dos arquivos que serão hospedados no servidor, se existe uma equipe responsável pelo securing e reestruturação do servidor... talvez os amigos que fazem superior aqui do VoL saibam como funciona as coisas em relação a este contexto, na universidade.
Neste caso, o servidor claramente estava sob a administração de uma pessoa realmente despreparada ao ponto de configurações importantes do estarem readable para todos usuários, arquivos como httpd.conf, vhosts.conf, meminfo, cpuinfo, binários do servidor com permissão e como se não bastasse o despreparo, o nmap estava instalado e com permissão de execução por qualquer usuário!
Ai já viu né, muitos outros mistakes pessoal, que nem vou comentar.

Observação
Antes que alguém me julgue, eu mesmo digo. Não quero "um minuto de fama" e não estou querendo desmerecer nenhum administrador e nem me gabar.
Apenas me senti na necessidade de comentar sobre isso, visando o fato de que pessoas despreparadas realmente ocupam cargos importantes.
Me senti na necessidade de comentar sobre isso porque vejo domínios gov.br, .edu.br e etc serem pichados muitas vezes por crianças que incrivelmente parecem saber mais que "especialistas".
Claramente é possível rootar este servidor, eu não cheguei a checar as falhas do Debian Jessie mas com certeza este era o caminho.

Já comuniquei os responsáveis pelo servidor (OMITIDO) sobre os scripts que encontrei vulneráveis, mas não comentei sobre as permissões erradas, sobre o nmap e sobre outras coisas que ao meu ver não eram pra estar em um servidor, não comentei justamente pelo securing e reestruturação ser um trabalho do responsável e não meu.
De quebra apresentei um patch para algumas libs que estavam vulneráveis (que já estava disponível pela equipe do Debian desde o inicio do ano), apresentei os códigos corrigidos dos scripts web (ao menos, os que eu chequei) e removi meu backdoor mágico (hehe).
Comentei sobre a importância de um audit framework apenas para monitorar o acesso a syscall importantes como a bind (#define __NR_bind 361) muito usada em sockets de backdoor, entre outros detalhes.
Espero que os administradores leiam atentamente ao meu e-mail e que já esteja tudo corrigido.

É isso pessoal, não tive nenhuma intenção de causar danos, apenas de mostrar como os profissionais da área no Brasil continuam um tanto despreparados.
--
Just bring us some beers, and then we can talk about our systems. :)

luiztux
(usa Gentoo)

Enviado em 07/06/2016 - 21:15h

Eu li teu post anterior. Para um post estava bem detalhado as (algumas) falhas. Este também. É um assunto, no mínimo, interessante. Deixo meus parabéns.

Embora eu tenha superior(es), sinceramente não sei te responder porque cargas d'água os servidores são tão mal configurados. E não é só de universidade. É espantoso o número de empresas, grandes empresas aliás, que parece que uma criança configurou a bagaça. Não vou citar nomes pois não convém. Entre estes, agências governamentais, que disputam um páreo duro com as universidades.

Mas este problema não é só no Brasil e engana-se quem pensa que é. Já fiz experimentos por aí e o negócio é complicado. Alguns dá pra perceber que a falha é risória. Outros são mais por combinações de pequenas brechinhas que juntas formam o efeito dominó. Mas é aquela história: não existe nada 100% seguro.

A gente comenta estas coisas mas é bom sempre ter em mente que estamos fadados ao mesmo problema. Uma hora acontece com teu software, com teu sistema, etc., etc. Por isto é sempre recomendável testar teu sistema ao máximo. Lembra-se do bug do gato no Ubuntu? Taca um gato lá pra fuçar teu software e você vai ver o melhor caça bugs em ação. ;)

-----------------------------------''----------------------------------

"If it moves, compile it."

removido
(usa Nenhuma)

Enviado em 08/06/2016 - 01:26h

Na outra postagem eu havia comentado que esses servidores devem ter essas brechas deixadas por gente de dentro.
Mas poderiam ser apenas plantadas lá e nunca terem feito uma auditoria para saber se há algum perigo.

E que eu li numa newsletter sobre o mercado negro de exploits 0-day na Rússia.
Esse pessoal das falhas deve trocar figurinha sabendo o que há e onde há.

----------------------------------------------------------------------------------------------------------------
Nem direita, nem esquerda. Quando se trata de corrupção o Brasil é ambidestro.
(anônimo)

Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. — Edward Snowden[/quote]

removido
(usa Nenhuma)

Enviado em 08/06/2016 - 18:30h

Esse lance do gato repercutiu mesmo viu, HAHA.

Aparentemente quem acessa um servidor governamental ou mesmo de uma instituição privada como de universidades (entre outros), "por fora" aparenta ser um servidor seguro e de fato não é tão falho assim, mas eu percebi que um dos problemas é que a atenção é quase toda direcionada para o que fica no WEB path e serviços externos do servidor ao invés da segurança ser pensada como um todo, ou seja; também localmente e não só com o que é acessível pelo usuário cliente/atacante.
Digo isso porque percebe-se que a coisa ta feia quando tu vê como o bixinho é mal configurado "por dentro".

Realmente luiztux não são apenas esses, eu apenas me referi a universidades porque era para ter uma atenção melhor dedicada à servidores do tipo, sendo que pode acabar expondo dados de professores, alunos, configurações de todo tipo como senhas de acesso e outras infos de caráter confidencial, imagine só se uma pessoa mal intencionada consegue acesso a um servidor deste, ou na pior das hipóteses consegue acesso root. Os danos não seriam comparáveis à uma simples index pichada por defacers, os problemas poderiam envolver desde dados roubados/espionagem, à extorsão ou seja; os danos poderiam ser muito mais graves.

Em relação ah não ser só o Brasil, realmente é verdade.
Muitas empresas grandes mundo a fora são falhas também, teve uma empresa que oferecia/oferece serviços de hospedagem (frxx.fr) que teve grande parte de seus virtual hosts (inclusive o principal) pichados a uns anos atrás.
Uma outra empresa mundialmente conhecida por ser a rede social mais famosa do mundo atualmente, também já teve suas vulnerabilidades expostas a uns 10 anos atrás em um paper no extinto milw0rm, o que repercutiu muito no underground antes de ser uma empresa conhecida, uma outra empresa muito conhecida pelos norte americanos, com cara de blog teve todos seus logins de usuários exp0sed no seu "auge" em uma página do atacante.
Até mesmo aquela empresa do nosso buscador mais famoso já foi alvo de cracking (especificamente defacement), incluindo uma outra empresa roxinha que era a rede social do momento dominada pelos Brasileiros, famosa no underground pelos seus evil javascripts. Realmente a coisa estava feia a uns 10 anos atrás, e continua feia mas em um nível menor porque os profissionais vem buscando se especializar mais e consequentemente isso dificulta os objetivos de kiddies seguidores de receitas, ficando só a galera que entende a gravidade, que quer ajudar a melhorar a segurança virtual no cenário global e não piorar.

Acho que o grande problema de servidores grandes, seja de instituições privadas ou governamentais, seja de servidores de hospedagem, seja de qualquer empresa do Brasil (ou de qualquer país) que tenha mais de um virtual host, o grande problema é a falta de pessoal ou a falta de conhecimento do pessoal responsável já existente, em manter um servidor com muitos arquivos e serviços, minimamente seguro.
O ponto é que; se não falta pessoal... falta conhecimento, e não adianta nada ter um pessoal pra ligar o servidor quando ele desligar.
Antes de os responsáveis por uma empresa pensar em configurar um servidor gigantesco com centenas de virtual hosts, tem que: em reunião discutir as possibilidades de falhas que cada site hospedado possivelmente poderá conter, que poderá existir um backdoor em algum dos serviços rodando, que cada arquivo escrito/enviado poderá estar vulnerável, que permissões erradas e programas desnecessários em um servidor fazem diferença sim, erros básicos que qualquer administrador de servidor leigo ou não pode acabar cometendo por um discuido mínimo e mesmo tendo todo cuidado posteriormente já não fará mais diferença, sem alguma manutenção regular.
E olha que fazer o securing não é uma coisa tão difícil, mas se não for feito a manutenção com regularidade desde o ínicio isso vira um problema que pode acabar denegrindo muito a imagem de uma empresa, como sofrer invasões durante anos consecutivos e aparentemente ninguém estar nem ai para o problema.
Uma instituição em que os responsáveis pela administração do servidor não dão a devida importância aos milhares de arquivos hospedados no servidor, largou o servidor lá e quando der alguma mer.da grave "tira o roteador da tomada e chama o sobrinho" pra ver o que é.

E é justamente esta questão que me intriga, será que instituições deste porte não tem verba pra treinar um pessoal ou contratar um pessoal especializado? o que acontece pra isso deixar de ser uma prioridade? ta certo que uma universade tem dezanas de outros assuntos pra tratar e priorizar mas um servidor contendo informações importantes, gerenciando e movimentando parte da instituição deveria ser melhor escalado na escala de prioridades. E isso que estou falando apenas de um servidor, imagine só uma rede de servidores mal configurados por profissionais assim, o caos que deve ser.

E mais uma vez sou obrigado a concordar com você luiztux, estúpido é aquele que pensa que um sistema é 100% seguro.
--
Just bring us some beers, and then we can talk about our systems. :)

removido
(usa Nenhuma)

Enviado em 08/06/2016 - 19:25h

Eu também havia respondido sua resposta anterior mano listeiro_037
Realmente pode ter sido alguém de dentro, e como aparentemente não é feito alguma manutenção regular alguém deve ter encontrado estas primeiras brechas e dado início a essas invasões.
Mas eu acredito que a falta de conhecimento dos profissionais somada a negligência tornou a instituição um alvo fácil sendo que os problemas de resolução simples são vários, e talvez a negligência tenha tornado isso uma densa "bola de neve", tanto que isso vem comprometendo a segurança de um dos servidores a anos.
Como eu havia dito antes, uma rápida lida nos logs já apresentaria uma noção da segurança no servidor atual, sendo que o ideal seria oferecer um treinamento especializado para a equipe que administra o servidor, que ao meu ver a segurança anda um tanto comprometida e deve ser tomada como uma prioridade, do tipo principal.

Também havia comentado sobre o assunto dos exploits, o tal mercado cinza não é mesmo? eu li bem superficialmente sobre o assunto, mas na resposta anterior acabei deixando deixando uma pergunta no ar, vou faze-la de novo:
será que esse mercado vem movimentando alguma grana? realmente o pessoal do underground troca muitas figurinhas HAHA, mas um palpite; acredito que isso deve vir movimentando alguma grana mais por parte das empresas que talvez estejam contratando este mesmo pessoal para prejudicar de alguma maneira a concorrência (supondo essas empresas sejam antiéticas, lógico)... mas acho que a venda de exploits vem sim movimentando uma grana, não imagino quem sejam os "compradores", mas talvez sejam essas mesmas empresas antiéticas que exploram sua concorrência.
A propósito, falando em mercado de exploits, lembrei-me do 1337day Team, que vem cobrando pelos exploits há um tempo.
--
Just bring us some beers, and then we can talk about our systems. :)

luiztux
(usa Gentoo)

Enviado em 08/06/2016 - 20:31h

O mercado de exploits está em alta. É venda de um produto como outro qualquer: tem oferta e tem demanda. O negócio mesmo rola sem que se conheça quem são os vendedores e compradores. Mas uma coisa é certa: quem compra são os peixes grandes. Ninguém desce ao submundo à toa. E se você desce, tem que ter fibra pra aguentar.

Na minha opinião você deveria preparar um belo de um artigo, um daqueles que chame a atenção, e publicar aqui no VOL. Sem citar nomes nem nada muito comprometedor, para que ninguém saia prejudicado. Este é um problema velho que infelizmente ainda persiste, então é preciso dar uns tapas na cara das pessoas para que saiam da zona de conforto. Escreva algo que crie um impacto.

Sabemos que o VOL é referência, se não fosse não teriam alertado o Fabio. Ou seja, "os caras" perambulam por aqui ou até tem conta, que seja. Mas é visto por milhares. Então eu acho que você tem o dever de contribuir com isto...já que começou, termine! rsrsrsr

Brincadeiras à parte, acredito que daria um ótimo artigo e pode ser referência aí para muitas pessoas.

-----------------------------------''----------------------------------

"If it moves, compile it."

removido
(usa Nenhuma)

Enviado em 09/06/2016 - 04:28h

Bela sugestão luiztux;
vou pensar em algo envolvendo os temas aqui apresentados e discutidos como tema principal de um artigo, talvez abordando outros temas também envolvendo Tecnologia e Segurança da informação, claro.
Pensei também em contata-lo para a pesquisa, edição, revisão e por fim redigir o artigo; deste modo teríamos mais de uma opinião em um artigo completo (se você estiver disposto, é claro).
Mais uma vez devo ressaltar que foi uma bela sugestão, seria muito bom ter um artigo completo sobre S.I aqui no VoL, realmente poderia servir como referência para muitas pessoas, e inclusive servir de referência para um bom fórum como o VoL.
Assim que eu tiver algum material pronto para dar inicio ao resto do conteúdo, eu te aviso :)

Quem mais se interessar, basta fazer contato via e-mail ou aqui mesmo no tópico.
A favor da liberdade de conhecimento, para que "kiddies" em Segurança da informação possam se tornar profissionais.
--
Just bring us some beers, and then we can talk about our systems. :)

luiztux
(usa Gentoo)

Enviado em 09/06/2016 - 07:18h

Bom..."tamo" por aí.

Caso queira compartilhar teu artigo ficarei contente em ajudar.

-----------------------------------''----------------------------------

"If it moves, compile it."