Posts tagged ‘security’

Jira at apache.org was hacked

The Apache Infrastructure Team Incident Report 04/09/2010 released today 13. April 2010 about the hack of jira.apache.org.

Thank you guys for this helpful disclosure.

There is no clear information available today what was the root cause of the Atlassian security breach (published yesterday).

Today we got detailed information from Apache Infrastructure Team about the breakin at jira.apache.org:

1. 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.
2. 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.
3. Service isolation worked with mixed results. The attackers must be presumed to have copies of our Confluence and Bugzilla databases, as well as our JIRA database, at this point.

UNBELIEVABLE!

What todo now:

  1. Checkout all background information about this vulnerability of JIRA.
  2. Check and Upgrade all non-internal JIRA and other Atlassian systems world-wide to prevent these attacks.

And we all should never forget:
Install 3rd party applications as root and run them as user with limited privileges.

[1] Apache Infrastructure Team Incident Report (13 Apr 2010) related to jira.apache.org
[2] Max on Improving Web Security: Six Ways the Apache.org JIRA Attack Could Have Been Prevented by Better Cod (13 Apr 2010)

Tuesday, 13 April 2010 at 14:21 UTC Leave a comment

Atlassian security breach and customer support in real-time

About an hour ago customers of Atlassian (the company behind great tools like Jira and Confluence) got an email about a security breach and to change their password.

Be aware that this security issue only affects Atlassian customers who created an Atlassian account and purchased one of our products before June 2008. Since then, we have been using a more secure user management system based on Atlassian’s Crowd product. When you change your Atlassian account password using the procedure below, your Atlassian customer account details will be stored in our updated Crowd user management system, which will further minimise the chance of a security breach occurring in future.

[1] Source: Jason Winder Webnet IT Blog: Atlassian Stored Passwords in Cleartext?

Just after this email it seems that most people were not able to retrieve Atlassian’s service to react.

Now after one hour there was no official statement of Atlassian!

Guys @Atlassian ! Please use Twitter or Uservoice to react in our real-time live and give us some background information!

Twitter User Feedback

Update 1:

[2] @atlassian on Twitter at 7 00 PM GMT replied:

Atlassian had a security breach. Apologies for the confusion. Our site is experiencing heavy loads. We are working on getting back up ASAP.

[3] Zoli Erdos at Cloudave: Atlassian Security Breach and Warning

Update 2:
[4] Atlassian’s Mike Cannon-Brookes initial customer feedback today morning

The legacy customer database, with passwords stored in plain text, was a liability. Even though it wasn’t active, it should have been deleted. There’s no logical explanation for why it wasn’t, other than as we moved off one project, and on to the next one, we dropped the ball and screwed up.
Disclosure: in terms of the security breach itself, we will disclose the various attack vectors and what happened once we have a full picture. Expect this in the coming week.

Looking forward to it, so everybody can learn from such IT security mistakes.

Monday, 12 April 2010 at 19:56 UTC 3 comments

Securing php with mod_security

Learning from Facebook: Preventing PHP Leakage

There was in 2007 the Facebook code leak. PHP has always been notorious for sometimes not processing requests poorly and sending back the source code for pages to the client. Because of the way mod_php works with apache, if mod_php fails in intercepting and processing the request, then apache will just serve it back to the client as an ordinary text file. Lets touch on a few solutions to preventing PHP code from leaking:

Use mod_security to filter output and prevent leakage


mod_security
is so damn good that it should be included in apache by default (and there should be some default rules in the default conf files). You can write mod_security rules that will detect if the output is PHP source code, and then prevent it from hitting the wire, instead giving the user an error page. You can also detect other information leakage, and prevent it from escaping. When writing a rule to detect if there is PHP in the output, you can do a regexp against the PHP header tags (eg. ‘< ?php’ and ‘?>‘) or include a special token in your PHP that identifies it as source code (eg. have the comment /* THIS_IS_PHP_SOURCE */ at the top of each PHP page, and if mod_security sees that in the output, kill the response). Here is a simple sample mod_security rule that will filter output:


SecFilterOutput On
SecFilterSelective OUTPUT "<?php" log,deny

For more on mod_security (essential!), see this onlamp article (old but a good intro)

Code should live outside of the web root

You should keep all logic and sensitive code outside of the web root. You can then include the logic files using the include() function. You should already be doing this with any files that store database information or passwords, but you could take this to an extreme and have only a single index.php inside your webroot, which will include a fileoutside of the webroot where everything actually happens, eg:


index.php:

<?php
include(‘../realroot/index.php’);
?>

Change the default file type

By default, Apache will treat files as text/plain – meaning that if the extension of a file doesn’t match a handler (eg. .php files processed by mod_php), then it will send it back as plain text. If you accidently change the extension of a file type, or if an attacker somehow forces an alternate extension, they can retrieve the plain text content. To prevent this, with PHP apps you may want all files to be treated as PHP (and then have certain types handled as plain text). Modify the following directive in http.conf:


httpd.conf:

DefaultType application/x-httpd-php

Deny all outside of the webroot

Assuming your webroot is ‘www’, you want every other directory and file to note be served. Common sense:

http.conf: (or .htaccess)

<directory />
Order Deny,Allow
Deny from all
Options None
AllowOverride None

<directory /www>
Order Allow,Deny
Allow from all
</directory>

Wednesday, 6 August 2008 at 11:06 UTC Leave a comment


Categories