Ir para o conteúdo
  • Revista PROGRAMAR: Já está disponível a edição #60 da revista programar. Faz já o download aqui!

herakty

Apache.org hacked, Importante ver a técnica usada

Mensagens Recomendadas

herakty

vejam este artigo que fala de técnicas muito usadas hoje que são o XSS e CSRF e o facto de nem sempre se dar atenção aos alertas de segurança que permitiram que o site da Apache.org fosse crackado... farto-me de ouvir programadores desvalorizarem estas questões, pois dão mt trabalho pensar nelas... mas espero que estes acontecimentos levantem a consciência para programar em segurança

An attacker found an XSS hole in JIRA, a bug tracking application sold by Atlassian. He sent the malicious link to several administrators via the application itself, and they clicked it. (Kind of sloppy, if you ask me- embed the malicious link in an innocent looking page, and the admins may never realize they got compromised). At that point, the attacker modified a file upload directory and placed a few JSP scripts on the server, giving him a web shell and eventually, root access via sudo.
Let’s look at another example; a combination of several seemingly unimportant bugs. I used this exact exploit in a penetration test 6 months ago, and while it uses none of the same issues as the Apache.org attack, you’ll notice that the methods and results are eerily similar.

1) Administrator and user functionality throughout JIRA is vulnerable to CSRF. If you still don’t think CSRF is a critical bug, keep reading.

2) One administrator function is the ability to create XML-formatted backups of the database. Those backups can be stored in an arbitrary location, including the web root, and with an arbitrary filename, including JSP. (Atlassian’s response: “You’d have to be a JIRA administrator to do this”).

3) Other poorly-validated form fields exist throughout the application.

Whether it’s because they don’t understand the issues, don’t appreciate them, or don’t care about them, Atlassian’s support people have been generally dismissive of my bug reports. The issues I sent in (JSP-47415, JSP-55831, JSP-55834, and JSP-55835, though nobody but me and JIRA support can see them) have been closed, marked as “duplicate” to unrelated issues, or disregarded saying that an upgrade to the current version will fix them (it does not). To demonstrate a working 0-day (okay, not exactly, these were all first reported months ago), let’s embed a bit of JSP code in one of those poorly-validated form fields, setting our profile’s email preferences to:

It stores that code in the database. Harmless, right? Now, what happens when an administrator is tricked into visiting the following link?

https://jiraapp/secure/admin/XmlBackup.jspa?filename=..%2Fatlassian-jira%2Fshell.jsp&useZip=false&saxParser=&confirm=true&Replace+File=Replace+File

You’re welcome to stand up a demo copy of the application and try it yourself, but here’s the spoiler: It’ll create a backup of your database, saved with a .jsp extension, and executable by the webserver. If stealing your password hashes and other data wasn’t bad enough (it is a publicly accessible backup of the database, after all), the embedded JSP code also gives the attacker the ability to run arbitrary shell commands. Awesome.

este tipo de ataques são mt usados na tal web2 onde as pessoas podem criar conteúdos complexos e é possível injectar código no servidor (se houver uma falha) que depois todos os que acedem a esse conteúdo são afectados.. .neste caso era preciso um administrador clickar num certo link, o que é mais fácil do que parece pois pode ser disfarçado numa funcionalidade usada pelo Administrador do site... e quem trabalha diariamente não está sempre a ver se há links disfarçados

ISTO ACONTECEU, pois isso não digam... ahhh, isso é tudo treta porque é preciso isto e aquilo... ACONTECEU porque somos todos humanos e nem sempre reparamos em pequenos pormenores

oiçam sempre alguem que diz que podem ter um bug de segurança... não quer dizer que tenham... mas podem ter e deverão analisar a situação... ou acontece o que aconteceu à JIRA e a todos os seus clientes  :thumbdown:

este artigo mostra o que aconteceu a uma das organizações que mais admiro... a Apache que como sabem é muito mais do que uma organização que faz o HTTP server apache, mas uma organização que desenvolve vários excelentes projectos e são de louvar

mas porque a JIRA não ouvi um "bug report" e achou-se grande demais para dar ouvidos a alguém que descobriu um bug no seu software de bug tracking (curioso não? um bug letal num software de gestão de bugs  :thumbdown:) e porque a Apache usa esse programa da JIRA para gestão de bugs, foi vitima sem poder fazer nada, pois o problema está no programa da JIRA que usam e não no seu site em si

resultado que é BASTANTE LAMENTÁVEL DEVIDO À IMPORTÂNCIA DA APACHE.ORG... como a JIRA não deu ouvidos não corrigiram e À conta disso o site apache.org foi altamente crackado... o que mais uma vez digo, é lamentável E DESPREZÍVEL PARA QUEM FEZ ALGO ASSIM... SÃO ESSES PSEUDO CRACKERS (não foi o autor da descoberta do bug... esse foi quem avisou várias vezes a JIRA antes de o tornar público e fe-lo porque a JIRA não queria corrigir... pena ter a Apache sido a vitima, pois isso acho que quem fez esse ataque a uma organização que tanto fez por todos nós, é um ser desprezível

vejam tudo em:

http://www.thehackeracademy.com/apache-org-hacked-atlassian-fail/

teckV

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!

Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.

Entrar Agora

×

Aviso Sobre Cookies

Ao usar este site você aceita os nossos Termos de Uso e Política de Privacidade. Este site usa cookies para disponibilizar funcionalidades personalizadas. Para mais informações visite esta página.