1

I'm facing an issue which i need to upload files to a centralized server, then relay it to other malware analysis providers (Palo Alto / etc...)

As from security perspective - it's forbidden for the file to reside in the server's file system and memory.

The server is ASP.NET based, and the client is C++ and i thought about streaming (currently we stream those files through IIS) - but i have some major drawbacks:

  1. I think that IIS can cache data it receives, meaning - i have no control on the data flow (malware can suddenly reside in IIS memory).
  2. Even if i use TCP components - who said that there's no caching in the server side? I would hate to write the entire TCP handling myself (which never will be efficient like the already written ones)
  3. Other option i was thinking is to XOR the files, but if i do it on agent - compromised machine can manipulate it and send the original malware, and in server again, it could be that the malware is already cached in memory.

In addition to #3, XOR, or any password protected zip files methods (that client can send) are no acceptable aswell, as exploits might be used to decrypt this file in the server and run it (though those are slim chances).

The 3rd parties we use also expect the original file's data.

The only "acceptable" solution is to sandbox the receiving process with its files, either by a 2nd server (which is not acceptable by our on-premise customers) or in our "real" server (some kind of container - which seems like a super overkill)

Would love to hear your comments about this?

  • Just don't host the server yourself, then you don't have to care. – eckes Jun 25 '17 at 15:00
  • Sandboxing is just too risky (and really not needed if you encrypt the data) – eckes Jun 25 '17 at 15:14
  • we cannot encrypt the data, as we'll need to decrypt it in memory and relay it to the 3rd parties. why Sandboxing is too risky? are you talking about a security hole that might make the machine leak to the host? – ArielB Jun 26 '17 at 7:12
1

Just ZIP the file with a strong AES password or use OpenPGP or Minlock file encryption (on the client before upload).

This protects your server from accidental execution, it hides the content from scanners, it will also protect integrity and will protect the analysts from accidental exposure on/after download. In fact it's the only reliable method to avoid accidental corruption by intermediates anyway. I don't think any forensic company accepts files without packing them in containers.

Yes you stated you don't want to ZiP, but you have not mentioned convincing reason why not: The threat model 'might be decrypted and run on server' is not valid, if an attacker can generate files and execute them they don't need your encrypted content to start with.

Using streaming adds very much distribution logistic as all receivers have to know and be online at the same time. And even with streaming you want to package, encrypt and integrity protect your network transfers.

  • "any password protected zip files methods (that client can send) are no acceptable aswell" - as stated in the original post – julian Jun 25 '17 at 15:11
  • @SYS_V sure but if you state impossible requirements somebody has to tell you that, right? – eckes Jun 25 '17 at 15:12
  • Given the contraints he imposes, I guess he is SOL – julian Jun 25 '17 at 15:15
  • OpenPGP can encrypt using a destination certificate, which avoids 'passwords'. – Andrew Russell Jun 26 '17 at 2:40
  • 1
    @ArielB My sympathies. – eckes Jun 26 '17 at 10:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.