Jump to content
  • 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

Recommended Posts

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  👎

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  👎) 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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.