Expose the software version publicly implementing a platform security transparency

globaleaks / globaleaks-whistleblowing-software

GlobaLeaks is a free and open-source whistleblowing software enabling anyone to easily set up and maintain a secure reporting platform.

https://www.globaleaks.org

Other

1.26k stars 275 forks source link

Expose the software version publicly implementing a platform security transparency #1761

Closed evilaliv3 closed 7 years ago

evilaliv3 commented 8 years ago

Given that:

the aim of GlobaLeaks to support a responsible and secure whistleblowing;
GlobaLeaks relies on public reviews instead of security through obscurity concepts
it will be always that easy for a web software to be fingerprinted

I propose to make the software version public by design through the public API.

The added value in the change is:

Allow more easily to track that need to be updated
Enforce professionals providing globaleaks, to really maintain the platforms installed for a customer
Enable a security transparency to the stakeholders community in order to protect more the whistleblower.

evilaliv3 commented 8 years ago

\cc @vecna @NSkelsey @fpietrosanti

could you express what you think about this?

NSkelsey commented 8 years ago

A nice side project is a tool and a website that consumes this API.

It could be version 2 of http://leakdirectory.org

evilaliv3 commented 8 years ago

Excactly @NSkelsey, this is a component of what i would like to be implemented with https://github.com/globaleaks/GlobaLeaks/issues/1762

fpietrosanti commented 8 years ago

I remember we moved the software version as hardening outcome of a penetration test, maybe an OWASP recommendation, it should be checked but anyhow exposing publicly the precise software version is against good security practices (in fact all webserver hardening procedures require to hide any software version publicly exposed)

vodkina commented 8 years ago

About publicly exposing software version I recall more or less what already mentioned by @fpietrosanti in his comment

fpietrosanti commented 8 years ago

(btw to facilitate upgrades it would be better to first implement #1493)

evilaliv3 commented 8 years ago

i know @vodkina and @fpietrosanti thanks, i recall the same.

what i wonder is: that is security through obscurity that i hope none of us endorse and on the other hand any paranoid will anyhow reject globaleaks, so why do not enforce security through transparency? in the sense why not force adopters that want a minimum trust to maintain updated their nodes to not get shame on them?

if you do not agree with this, think a moment to how it easy to implement a fingerprinting tool for the css of globaleaks in order to know the exact version;

if not a different user i will do probably myself a fingerprint tool like that for managing my instance and to be able to implement #1762; when done, we will all happy, me, the fingerprinters and the security through obscurity owaspers because the version wil be super easy fingerprintable as demonstrated but the version not exposed!

evilaliv3 commented 8 years ago

@fpietrosanti, the security audit you rememeber was on the wonderful Tor2web report: https://github.com/globaleaks/Tor2web/issues/139

shall we have also to blame SSHd for exposing the exact version down to the compiled libraries and operating system? :)

fpietrosanti commented 8 years ago

The fact that it's required to develop a fingerprinting tool, means that's a security barrier not displaying the version number, requiring additional knowledge and tools in the security discovery phase of an attack.

So, the exposure of the exact software version will always be considered a security issue by a penetration tester in it's report, that's a fact.

Said that, without entering into the security philosophical opinions whenever it's a good practice to enable it or not, it could be just implemented as a configurable behaviour of the application with:

Display exact software version
Display major software version
Does not display software version
Display fake software version: "String to be configured"

Implemented that way would enable that aspects to be adjusted depending on the context of uses and the kind of features of application transparency vs. technical hardening that the admin may wish to follow.

vecna commented 8 years ago

maybe, instead of displaying a "version", can be display the features supported. so a client and a directory can know better which are the capability, and the "version" itself don't get released.

but I would take otherwise the simple path: put the version and goodbye.

evilaliv3 commented 8 years ago

p.s. even SecureDrop is exposing the version;

i really do not see the value of complicating our life for hiding a version that in the context of web applications will be always discovered easely.

fpietrosanti commented 7 years ago

This is a well known and documented OWASP vulnerability that has been already reported and fixed: https://www.owasp.org/index.php/Testing_for_Web_Application_Fingerprint_(OWASP-IG-004)

Exposing the software version represent a security weakness and is against, if you want to read further documented conversation on why it's a security problem: https://security.stackexchange.com/questions/14709/hiding-version-valuable-or-just-security-by-obscurity