{"id":403,"date":"2010-04-13T21:39:44","date_gmt":"2010-04-14T00:39:44","guid":{"rendered":"http:\/\/www.subterfugios.net\/blog\/?p=403"},"modified":"2010-04-13T21:39:44","modified_gmt":"2010-04-14T00:39:44","slug":"ataque-hacker-ao-issuesapacheorg","status":"publish","type":"post","link":"http:\/\/www.subterfugios.net\/blog\/ataque-hacker-ao-issuesapacheorg\/","title":{"rendered":"Ataque hacker ao issues.apache.org"},"content":{"rendered":"

\"noplace\"<\/p>\n

H\u00e1 alguns meses, comentamos sobre a senha de seu email e porque mant\u00ea-la segura<\/a>, muito segura. Ocorrido durante a semana passada, um ataque ao site de bugs da mais famosa organiza\u00e7\u00e3o open-source refor\u00e7a este apelo.<\/p>\n

Sup\u00f5e-se que um site como o issues.apache.org seja um exemplo de seguran\u00e7a da informa\u00e7\u00e3o. E \u00e9 de fato. Os sistemas est\u00e3o sempre atualizados e as pol\u00edticas de seguran\u00e7a s\u00e3o bem seguidas. Mesmo assim, isso n\u00e3o evitou que um grupo de hackers tivesse acesso de root ao servidor. Tudo come\u00e7ou com um XSS (cross-site scripting) no Jira usando uma tinyurl e acabou com indisponibilidade dos servi\u00e7os e comprometimento dos dados dos usu\u00e1rios.<\/p>\n

O resultado \u00e9 que os meliantes hoje t\u00eam posse da base de usu\u00e1rios do Jira, contendo email e hash da senha de milhares de usu\u00e1rios. Se voc\u00ea tinha um usu\u00e1rio no Jira da Apache, usava uma senha boba (ex.: shelovesyou, baseada em palavras de dicion\u00e1rio ou n\u00fameros simples) e tem a mesma senha em seu email, \u00e9 poss\u00edvel que sua conta j\u00e1 esteja em outras m\u00e3os.<\/p>\n

A diferen\u00e7a aqui \u00e9 que ficamos sabendo. Por ser uma funda\u00e7\u00e3o totalmente aberta e transparente, a Apache divulgou o passo-a-passo do que foi feito em seus servidores, como forma de explica\u00e7\u00e3o e de evitar novas ocorr\u00eancias. Aquele sitezinho Web 2.0 que voc\u00ea faz coisas Web 2.0 provavelmente n\u00e3o ser\u00e1 t\u00e3o nobre e voc\u00ea n\u00e3o ficar\u00e1 sabendo que sua senha (porque aquele sitezinho provavelmente n\u00e3o usa nem MD5) est\u00e1 \u00e0 solta por a\u00ed.<\/p>\n

Bem, o objetivo n\u00e3o \u00e9 dar li\u00e7\u00e3o de moral, nem me \u00e9 permitido pela coer\u00eancia. Comecei a escrever mesmo para compartilhar o relato do incidente. A Funda\u00e7\u00e3o Apache fez um resumo claro e did\u00e1tico da invas\u00e3o, que pode ser lido neste link<\/a>. \u00c9 interessante porque n\u00e3o \u00e9 comum encontrar uma descri\u00e7\u00e3o assim. Cito um trecho aqui, grifado por mim:<\/p>\n

\"feather-small\"<\/p>\n

\nOn April 5th, the attackers via a compromised Slicehost server opened a new issue, INFRA-2591. This issue contained the following text:<\/p>\n

ive got this error while browsing some projects in jira http:\/\/tinyurl.com\/XXXXXXXXX [obscured] <\/p>\n

Tinyurl is a URL redirection and shortening tool. This specific URL redirected back to the Apache instance of JIRA, at a special URL containing a cross site scripting (XSS) attack. The attack was crafted to steal the session cookie from the user logged-in to JIRA. When this issue was opened against the Infrastructure team, several of our administators clicked on the link. This compromised their sessions, including their JIRA administrator rights.<\/p>\n

At the same time as the XSS attack<\/strong>, the attackers started a brute force attack <\/strong>against the JIRA login.jsp, attempting hundreds of thousands of password combinations.<\/p>\n

On April 6th, one of these methods was successful. Having gained administrator privileges on a JIRA account, the attackers used this account to disable notifications for a project, and to change the path used to upload attachments. The path they chose was configured to run JSP files, and was writable by the JIRA user. They then created several new issues and uploaded attachments to them. One of these attachments was a JSP file that was used to browse and copy the filesystem. <\/strong>The attackers used this access to create copies of many users’ home directories and various files. They also uploaded other JSP files that gave them backdoor access to the system using the account that JIRA runs under.<\/p>\n

By the morning of April 9th, the attackers had installed a JAR file that would collect all passwords on login and save them. They then sent password reset mails from JIRA to members of the Apache Infrastructure team. These team members, thinking that JIRA had encountered an innocent bug, logged in using the temporary password sent in the mail, then changed the passwords on their accounts back to their usual passwords.<\/p>\n

One of these passwords happened to be the same as the password to a local user account on brutus.apache.org, and this local user account had full sudo access.<\/strong> The attackers were thereby able to login to brutus.apache.org, and gain full root access to the machine. This machine hosted the Apache installs of JIRA, Confluence, and Bugzilla.<\/p>\n

Once they had root on brutus.apache.org, the attackers found that several users had cached Subversion authentication credentials<\/strong>, and used these passwords to log in to minotaur.apache.org (aka people.apache.org), our main shell server. On minotaur, they were unable to escalate privileges with the compromised accounts.<\/p>\n

About 6 hours after they started resetting passwords, we noticed the attackers and began shutting down services. We notified Atlassian of the previously unreported XSS attack in JIRA and contacted SliceHost. Atlassian was responsive. Unfortunately, SliceHost did nothing and 2 days later, the very same virtual host (slice) attacked Atlassian directly.<\/p>\n

We started moving services to a different machine, thor.apache.org. The attackers had root access on brutus.apache.org for several hours, and we could no longer trust the operating system on the original machine.<\/p>\n

By April 10th, JIRA and Bugzilla were back online.<\/p>\n

On April 13th, Atlassian provided a patch for JIRA to prevent the XSS attack. See JRA-20994 and JRA-20995 for details.<\/p>\n

Our Confluence wiki remains offline at this time. We are working to restore it.\n<\/p><\/blockquote>\n

Fiquei sabendo disso atrav\u00e9s de um email que come\u00e7ava assim:<\/p>\n

De:\t<root@apache.org>
\nDear Joao Del Valle,
\nYou are receiving this email because you have a login, [suprimido], on the Apache JIRA installation, https:\/\/issues.apache.org\/jira\/…<\/p><\/blockquote>\n

Mas sem problemas, minha senha era bem boba, s\u00f3 para consultar e comentar issues. E a sua?<\/p>\n