Heartbleed and IPB

[GreenLinks]

Can you please let us know detailed about how IPB is protected agains heartbleed ?

[Charles]

I do not understand your question.

Heartbleed is an OpenSSL vulnerability that is a server-level problem. IPB is not OpenSSL ...

[GreenLinks]

It is OpenSSL vulnerability though IPB uses sessions inside backend url which kind of makes this security more in the face of the user. So i want to know if you are planning to change or add more improvements for future.

[Ryan H.]

As Charles said, the OpenSSL vulnerability is a server issue, nothing IPB has any sort of control over. You need to contact your host to make sure they've patched or will be patching your server(s).

[GreenLinks]

If Charles or other team will approve the posts in timely , you can all see the issue.

Heartbleed is a OpenSSl vulnerability however according to how systems is designed , it is extremely easy to attack vulnerable websites.

Unfortunately IPB is one of this easy attacked candidates atm.

My question is if IPB is thinking about changing this for future to increase security or not.

[bfarber]

Can you please explain what you are referring to?

The solution for the vulnerability in question is to upgrade OpenSSL. There is no application-level solution. I don't understand what it is you think we as a company can do at the application level to resolve or mitigate this issue.

[Guest]

I think Greenlinks is referring to the idea that if you can steal someone's session ID by exploiting the Heartbleed vulnerability, you can gain access to other people's accounts within IP.Board by hijacking their session, and is looking for mitigations for that.

I guess this is where session IP validation would come in, if you're particularly paranoid about man-in-the-middle attacks, but there's very little else IP.Board could do.

[bfarber]

I think Greenlinks is referring to the idea that if you can steal someone's session ID by exploiting the Heartbleed vulnerability, you can gain access to other people's accounts within IP.Board by hijacking their session, and is looking for mitigations for that.

I guess this is where session IP validation would come in, if you're particularly paranoid about man-in-the-middle attacks, but there's very little else IP.Board could do.

The ability to validate a session against an IP address is already included in IP.Board as an ACP setting.

[GreenLinks]

I think Greenlinks is referring to the idea that if you can steal someone's session ID by exploiting the Heartbleed vulnerability, you can gain access to other people's accounts within IP.Board by hijacking their session, and is looking for mitigations for that.

I guess this is where session IP validation would come in, if you're particularly paranoid about man-in-the-middle attacks, but there's very little else IP.Board could do.

Exactly

thanks for notifying about that setting :)

[media]

Well, thank you for bringing this issue to our attention GreenLinks...

I fixed my server right away and if anyone needs more info, here you go...

http://heartbleed.com/

http://filippo.io/Heartbleed/

Second link you can check if your server is vulnerable....

[Aiwa]

http://community.invisionpower.com/topic/399417-important-notice-regarding-openssl-101-to-openssl-101f/

More info here

[ZakRhyno]

http://money.cnn.com/2014/04/09/technology/security/heartbleed-bug/index.html?hpt=hp_t2 If you want to understand what there all talking about check this vid out!

[Neil2]

Thanks for the Topic GreenLinks, I sent the info to my hosting company and they got on it immediately to correct this issue.

[Ichirō]

Exactly

thanks for notifying about that setting :smile:

Just to clarify for anyone unsure, to check the setting you will find it here:

Admin cp > System Settings > System > Security and Privacy > Security [General - High]

[Hexsplosions]

I have that setting disabled as it causes problems when multiple users browse from the same IP address (university campuses, partners in the same households, etc).

I'm not particularly worried about this myself... since the exploit is now effectively closed through a patch.