During the conception phase of my script, I discovered several risk:

  • Receiving of files
  • Ensuring the integrity of files
  • Securing the analyzing script against malicious attacks

Beside of these risks, there are many more, which I will point out in later blog posts. In the next chapters I will try to explain why they are a risk, what may happen and how I try to mitigate them.

Risk: Receiving of files Risk: Ensuring the integrity of files

Even if we switch from insecure file transport options like FTP to SFTP, FTPS or much better SCP, the service itself may be malicious.

Example:

After a successful login, the attacker installs a malicious version of the SCP server, which sends out the original file, but the web server itself is serving modified versions of them, containing malicious code.

The question is, how we detect something like that. One possible solution is to use multiple transport options and even requesting single files from the web server itself. But keep in mind, something like “the correct solution” or a “full solution” will never exists. If the attacker gains access to deeper operating system layers and detects your check-runs in some logs… it is a fight of knowledge, speed and luck.

Risk: Securing the analyzing script against malicious attacks

Exception handlers, running with less privileges, using SELinux and do not store the received files on the analysis machine. Most of these mitigation steps are easy to implement, but file transport options like ftp and even scp need to store the files somewhere on the machine. At the moment this risk will have to stay without a mitigation.