CSESoc Website Vulnerable to OpenSSL Heartbleed Vulnerability

[csesoc]

CSESoc Website Vulnerable to OpenSSL Heartbleed Vulnerability

[johnwiseheart]

The update depends on being able to update linux-headers-server, which according to evgeny could break the server (its very fragile). What is the vulnerability to CSESoc by not patching the issue until we deploy the new site?

[infosec-au]

The heartbleed bug is pretty severe. It requires no man in the middle attacks for an attacker to gain sensitive information. The server is returning up to 64kb of arbitrary memory, which could potentially contain SSL private keys.

Any/all session IDs which go through the site can be gathered by any attacker, remotely. Not only that, any/all post data going to cse soc's website can be obtained by the attacker.

For example, in this image, I am sniffing for "sessionid" in the data returned - remotely.

If you logged in right now, I would obtain your sessionid.

I can also obtain other users CSRF tokens and more, but that isn't as severe.

[johnwiseheart]

Is there any fix other than upgrading openssl?
On 09/04/2014 3:18 pm, "Shubham Shah" [email protected] wrote:

Closed #19 #19.

Reply to this email directly or view it on GitHubhttps://github.com//issues/19
.

[infosec-au]

Upgrading OpenSSL will definitely fix the bug, but at the same time, will require a restart of the server and may lead to server breakage as you said.

There may be OpenSSL alternatives for our case, but all of them will most likely require a server restart also, and they also may break the server.

If you're absolutely certain that you can't upgrade the packages, then you can potentially try and get Cloudflare with SSL (paid), which means that the CSESoc servers will use Cloudflares SSL proxy instead (which have been patched). That is one way we can mitigate without restart or server modification - however it would be costly.

[johnwiseheart]

Given we store very little sensitive data, its probably not worth it. We
can wait 2 or 3 weeks and do it when we deploy the new site.
On 09/04/2014 3:27 pm, "Shubham Shah" [email protected] wrote:

Upgrading OpenSSL will definitely fix the bug, but at the same time, will
require a restart of the server and may lead to server breakage as you said.

There may be OpenSSL alternatives for our case, but all of them will most
likely require a server restart also, and they also may break the server.

If you're absolutely certain that you can't upgrade the packages, then you
can potentially try and get Cloudflare with SSL (paid), which means that
the CSESoc servers will use Cloudflares SSL proxy instead (which have been
patched). That is one way we can mitigate without restart or server
modification - however it would be costly.

Reply to this email directly or view it on GitHubhttps://github.com//issues/19#issuecomment-39929847
.

[infosec-au]

That's fine, the only thing I'd recommend is making sure that there are no payment forms/any other forms which could contain really sensitive data. Since I can sniff post data remotely, anything you enter on csesoc's site is open to the world.

Anyways, looking forward to the new site! 😄

[johnwiseheart]

We shouldn't be using any of the payment until the new site is open - I
think its all disabled. The issue should be closed.
On 09/04/2014 3:32 pm, "Shubham Shah" [email protected] wrote:

That's fine, the only thing I'd recommend is making sure that there are no
payment forms/any other forms which could contain really sensitive
data. Since I can sniff post data remotely, anything you enter on csesoc's
site is open to the world.

Anyways, looking forward to the new site! [image: 😄]

Reply to this email directly or view it on GitHubhttps://github.com//issues/19#issuecomment-39930034
.

[infosec-au]

No worries - thanks for helping co-ordinate this 😃