5

If one has to describe fundamental difference in between these three terms (i.e. Code Injection, Command Injection and Remote Code Execution) what will that be?

How they are different from each other in terms approach to perform the attack and it's behavior on the target machine?

6

Hmm let me try:

  • Code injection consists of modifying an executable / compilation unit / script so that it contains malicious code on top of it´s intended functions. Code can be injected locally into it and then it could be uploaded into the internet, forums, news servers etc. It is a rather easy form of exploit and similar to a trojan horse. Early viruses were made like this, and spread via users sharing executables. You probably find this still today in "key generators" and other illegal software, as well as in data files like the notorious windows sreensavers ".scr" and other formats that aren´t executables per se but can be loaded with code that gets executed.

  • Command injection is IMHO using the weakness of an unprotected system to allow execution of arbitrary commands to modify or damage the target system. This could be for example to inject instructions via web URLs and make the remote server execute them. Unguarded SQL strings became famous for this. Either they can corrupt the database or even execute code on the underlying OS.

  • Remote code execution is to actually again craft malicious code but this time it is not attached to the binary unit, but send via the network. The difference to command injection could be seen in that additionally to the malicious code / script it also needs a weakness or fault of the receiving process, like you would send over a wrong instruction, make the process crash, and then make use of the crash handler to execute code that has been delivered together with your "crash packet". Most modern "zero day" exploits work like this.

I think the terminology is used in a fuzzy way though, so other people might see this different.

  • underguarded sql strings can be used to execute code on the underlying OS. That only happens when the user is the DBA in the sql server, am I right? @flohack – turmuka Sep 9 '17 at 23:31
  • wow, very nice explanation on remote code execution. Could it be done with messing with the http headers? or adding some strange stuff to the body of a request? @flohack – turmuka Sep 9 '17 at 23:36
  • Well the user might not be necessarily dba, because some weird database setup could escalate priviledges to a normal user, and with that user in turn you could get access to or command over a server. – flohack Sep 10 '17 at 13:10
  • I see, normal users can also run commands under some circumstances then, @flohack – turmuka Sep 10 '17 at 13:12
  • remote code execution can be very easy, here is a report of cloudflare about the shellshock attack: blog.cloudflare.com/inside-shellshock – flohack Sep 10 '17 at 13:17
1

Code Injection: When a malicious application uses a vulnerability to exploit an already running application to insert malicious code into the exploited application; changing the path of execution.

Command Injection: When you use some type of input to a system to run a system command. This can occur when input is not properly sanitized or checked. Wikipedia has a nice example

Remote Code Execution: When a code can execute any instruction that it wants on a system. There are lots of vulnerabilities out there, but not all of them will allow an attacker to execute arbitrary code on a system. Gaining Remote Code Execution is the last step exploiting a system.

To put them all together. A vulnerability is used to exploit a system to perform code or command injection to gain remote code execution. It should be noted that you don't need code/command injection to gain remote code execution. They are simply examples of how malicious code might be used.

  • with code injection, we can get to the paths that are not allowed by a normal user on the url, right? if that input system or application has a right to do it? – turmuka Sep 9 '17 at 23:33
  • With code injection you change the path of execution to code that you've written. It has nothing to do with a URL, and any system that you have exploited will still have the permissions of whichever user you're running as. – RoraΖ Sep 11 '17 at 11:13

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.