Verifying the integrity of XNAT releases to avoid supply chain attacks

[James]

Hey everyone,

So we run multiple instances of XNAT at our institution. We have automated deployment scripts to spin up new instances for any team that wants one. Mostly all instances so far have been for per-anonymized research data on an internal network. But we would like to expand into multi-center clinical studies, which means exposing XNAT outside our LAN, and ingesting real patient data from clinics.

To the end we have been in discussing the security aspects of our deployments with the data and IT security teams, and one of the issues that was raised is that there is no way to verify the integrity of xnat-web.war, or any of the plugins, leaving us open to a supply chain attack if the released package is modified upstream. Unless I am missing something, these are the options I have looked for and could not find implemented for xnat-web

Option 1: Checksum validation of the WAR. This is probably the easiest one to implement. Just publish a list of sha256 sums for each release so it can be checked at download time. I could not find any such list for XNAT releases

Option 2: Sign the WAR file. I tried `jarsigner -verify xnat-web-1.8.10.1.war` and it came back as unsigned. You'd have to publish a GPG pub key to verify against for this

Options 3: Signed your git commits. Git has the option for developers to sign their work: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work. As far as I can tell none of your devs do this. At least if each commit was signed, We could build xnat-web from source on each deployment and be fairly sure no malicious code had been added. This is obviously the most work as all devs would have the share a pub key.

Anyway sorry for the long winded message. I believe Option 1 would be easy enough to implement and would convince our security team to let us move forward.

Please let me know if i've missed something and you already have a solution to this.

[Battiston, Christopher]

As with James' previous email I fully support this - but I would actually like to go bigger and have some sort of documentation outlining the security precautions taken in XNAT.  From using current versions of TPAs, to built-in encryption methods and hashes, the more we can guarantee that the data is secured, the more likely more studies will be willing to use it.  

Thanks, 

Chris 

Pronouns: He / Him  

REDCap Administrator / Research Data Analyst, Research Operations 

The Center for Health Research Information Systems 

Please know that I honour and respect boundaries around personal time, well-being, caretaking, and rest. Should you receive correspondence from me during a time that you're engaging in any of the above, please protect your time and wait to respond until you're next working or in front of a computer. Prioritize joy, not email, when and where you can. 

  

Women’s College Hospital is located on the traditional lands of the Anishinaabe, Mississauga, Haudenosaunee, Ojibway/Chippewa and Huron-Wendat nations. 

---

From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of James <james....@med.uni-goettingen.de>
Sent: Thursday, May 9, 2024 13:47
To: xnat_discussion <xnat_di...@googlegroups.com>
Subject: [External]:[XNAT Discussion] Verifying the integrity of XNAT releases to avoid supply chain attacks

 

You don't often get email from james....@med.uni-goettingen.de. Learn why this is important

CAUTION: This email originated from outside of Women's College Hospital. Do not click links, open attachments or respond to requests for information unless you recognize the sender and know the content is safe.

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/90603959-d651-4168-bf29-5ba7be8cfc10n%40googlegroups.com.

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

AVIS DE CONFIDENTIALITÉ : Ce message électronique, ainsi que tout fichier qui y est joint, est réservé à l’usage exclusif du destinataire visé et peut contenir des renseignements confidentiels et privilégiés. Toute lecture, utilisation, divulgation ou distribution non autorisée est interdite. Si vous n’êtes pas le destinataire visé, veuillez en aviser l’expéditeur par retour de courriel et détruire toutes les copies du message original.

[James]

+1 to Chris's suggestion as well. I am in Germany and the amount of paper work surrounding "Datenschutz" is astounding. It would be amazing to have a document like this to reference.

However, for now, just some sort of mechanism to ensure that when I "wget https://api.bitbucket.org/2.0/repositories/xnatdev/xnat-web/downloads/xnat-web-${XNAT_VERSION}.war" I am indeed receiving an unmodified binary, would go a long way. And frankly would make XNAT look far more professional.

[james...@gmail.com]

Bumping this thread to see if there has been any improvements in validating the integrity and authenticity of the war/jar release 

[Rick Herrick]

Hey James,

We've had discussions about this topic (these topics?), but have been dealing with transitioning our build and deployment infrastructure so it's just been talk so far. We intend to start including SHA256 and SHA512 checksums along with our application and plugin downloads sometime soon, hopefully within the timeframe of our 1.9.3 release, but don't currently have that. The other options–involving signing artifacts and commits–is something I'm hoping to get worked out and integrated into our standard development and build workflow soon as well, but that will have to wait until we've stabilized our build and release processes.

All that said, there is a way to validate many artifacts, especially XNAT application wars. It's not super straightforward but provides some assurance about the integrity of the artifact. You can find a SHA256 checksum in our Maven repository where all of our artifacts are published. The path depends on what it is you're trying to validate, but is based on the group and artifact IDs plus the version for a particular artifact. For example, the XNAT war is published with group ID org.nrg.xnat.web, artifact ID xnat-web, and then its version. The URL to view that artifact for XNAT 1.9.2 would be:

https://nrgxnat.jfrog.io/ui/repos/tree/General/libs-release-local/org/nrg/xnat/web/xnat-web/1.9.2/xnat-web-1.9.2.war

At the bottom of that page, you'll find the various available checksums:

This applies to the constituent dependencies in XNAT as well. For example, if you extract one of our libraries like org.nrg:framework:1.9.2 and run sha256sum on it:

# jar xf xnat-web-1.9.2.war WEB-INF/lib/framework-1.9.2.jar

# sha256sum WEB-INF/lib/framework-1.9.2.jar
6c983dc90890737395a2943ab424988a3bbd688815af44ceca2d3b52c89740b6  WEB-INF/lib/framework-1.9.2.jar

Then compare that to https://nrgxnat.jfrog.io/ui/repos/tree/General/libs-release-local/org/nrg/framework/1.9.2/framework-1.9.2.jar:

As you can see, the sha256 checksums match.

Hope this helps for now, but like I said we will be adding more security and validation for verifying artifacts very soon!

Rick Herrick 

Senior Software Developer

ri...@xnatworks.io

https://xnatworks.io | Find us on LinkedIn! 

--

You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/xnat_discussion/9c9fe57a-7628-4fd2-9389-8613ef9fba7dn%40googlegroups.com.

[james...@gmail.com]

Hey Rick,

Thanks for the update. I'm glad to hear you are discussing this issue internally. And thanks for the tip about using the Maven repo to get checksums, this is a good workaround for the time being.

All the best,

James