-2

Recently I devised a way to avoid obfuscation of a jar file, here is how it works:

  1. Renamed the abc.jar file to xyz.so
  2. Placed it in system folder something like /lib/bdevid/ where other .so files were also present
  3. Modified the Operations And Management script (which used to restart the jar in case of any crash, both manually and automatically) to copy it from /lib/bdevid/xyz.so and place it where it was supposed to be, restart it and then delete the jar file, after a delay of 1 to 2 seconds.

The operations and management script is on a remote machine so access to this script is restricted, only web access is permitted.

What are possible loopholes in this process?

Please note that this process is currently running successfully, I just want to know how secure is this.

techraf
  • 9,159
  • 11
  • 45
  • 63
shabby
  • 97
  • 1
  • 8
    This is security through obscurity. Like hiding your spare house key under your backdoor mat instead of the front. – Alexander O'Mara May 20 '16 at 05:33
  • 3
    it is as secure as how secret you can keep your scheme – schroeder May 20 '16 at 05:36
  • Your scheme isn't secure. Any attacker easily running say file (which looks at file headers) on xyz.so would quickly see it is a jar file and not a shared library (.so); e.g., file xyz.so would give xyz.so: Java Jar file data (zip). – dr jimbob May 20 '16 at 06:09
  • 1
    Secure against what? – user253751 May 20 '16 at 08:47
  • "I just want to know how secure is this.".... go take a pen and the biggest piece of paper you can find, and write the following line, repeating until you run out of space on the paper ... "SECURITY BY OBSCURITY IS NOT SECURITY". – Little Code May 20 '16 at 17:14
  • 1
    Security by obscurity is not secure, and obscurity posted on the Internet isn't even obscure. – Jens Erat May 22 '16 at 19:21
  • Also, note that your script will have the name, location, and type of the file in cleartext, and this is one of the earlier places the attacker will look. Plus, checking for files where the actual type doesn't match the extension is a really common technique, and will make these stick out like they're on fire. – SomeoneSomewhereSupportsMonica May 22 '16 at 20:52

1 Answers1

4

This is not secure at all, against any Form of possible attack. Regardless of what you are trying to achieve, this will not solve your problem. As the commenters already proposed, this is not only "security by obscurity" this might already be "obscurity" only.

Jonas Köritz
  • 320
  • 1
  • 10
  • my question was to let me know the loopholes, like one of it is that parsing the headers will breach this security. What else? The script that does all this is already on a remote secured machine, there is no access to it. – shabby May 23 '16 at 05:10
  • 3
    shabby - there are so many problems with the scheme it's pointless to go through, find and fix all the loopholes - you need to start from scratch with an architecture that can be secured. – Rory Alsop May 23 '16 at 08:13