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 -Misconfiguration / Default File" with evasion type 1 -> Random URI encoding (non-UTF8)
Running Nikto with evasion type 1 - Random URI encoding. This time, the attack is "Misconfiguration / Default File". This builds on the previous post.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ nikto -host http://10.0.0.106 -ipv4 -Display 1 --ask no -Format json -o /tmp/nikto.json -nossl -no404 -Tuning 1 -evasion 1 - Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 10.0.0.106 + Target Hostname: 10.0.0.106 + Target Port: 80 + Using Encoding: Random URI encoding (non-UTF8) + Start Time: 2023-05-31 09:17:47 (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/ + 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. + /: Retrieved x-powered-by header: PHP/8.0.28. + /: HTTP TRACE method is active which suggests the host is vulnerable to XST. See: https://owasp.org/www-community/attacks/Cross_Site_Tracing + // - Redirects (302) to http://10.0.0.106/dashboard/ , Apache on Red Hat Linux release 9 reveals the root directory listing by default if there is no index page. + / - Redirects (302) to http://10.0.0.106/dashboard/ , Default IBM TotalStorage server found. + / - Redirects (302) to http://10.0.0.106/dashboard/ , Default EMC Cellera manager server is running. + / - Redirects (302) to http://10.0.0.106/dashboard/ , Default EMC ControlCenter manager server is running. + / - Redirects (302) to http://10.0.0.106/dashboard/ , Default Sun Answerbook server running. + / - Redirects (302) to http://10.0.0.106/dashboard/ , Default JRun 2 server running. + / - Redirects (302) to http://10.0.0.106/dashboard/ , Cisco VoIP Phone default web server found. + / - Redirects (302) to http://10.0.0.106/dashboard/ , Default Sybase Jaguar CTS server running. + / - Redirects (302) to http://10.0.0.106/dashboard/ , Default Lantronix printer found. + / - Redirects (302) to http://10.0.0.106/dashboard/ , Default IBM Tivoli Server Administration server is running. + / - Redirects (302) to http://10.0.0.106/dashboard/ , Default JRun 4 server running. + / - Redirects (302) to http://10.0.0.106/dashboard/ , Default Lotus Domino server running. + / - Redirects (302) to http://10.0.0.106/dashboard/ , Appears to be a default Sambar install. + / - Redirects (302) to http://10.0.0.106/dashboard/ , Appears to be a default IIS 4.0 install. + / - Redirects (302) to http://10.0.0.106/dashboard/ , Appears to be a default Netscape/iPlanet 6 install. + /?sc_mode=edit - Redirects (302) to http://10.0.0.106/dashboard/ , Sitecore CMS is installed. This url redirects to the login page. + 1466 requests: 0 error(s) and 6 item(s) reported on remote host + End Time: 2023-05-31 09:17:54 (GMT-4) (7 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
At first glance, above seems interesting to me. I'm targeting Dam Vulnerable Web Application (DVWA) platform, so I was surprised to see all this guidance about Cisco, EMC, IBM, etc.
Let's see what we can find via our first step of network forensics.
Detect - Log Analysis
Looking at the first five lines of the access.log file
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ head access.log --lines=5 10.0.0.108 - - [31/May/2023:09:17:21 -0400] "GET / HTTP/1.1" 302 - "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36" 10.0.0.108 - - [31/May/2023:09:17:21 -0400] "GET %2f HTTP/1.1" 400 326 "-" "-" 10.0.0.108 - - [31/May/2023:09:17:21 -0400] "GET /%63g%69%2e%63%67%69%2f HTTP/1.1" 404 297 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36" 10.0.0.108 - - [31/May/2023:09:17:21 -0400] "GET /%77%65bcg%69%2f HTTP/1.1" 404 297 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36" 10.0.0.108 - - [31/May/2023:09:17:21 -0400] "GET %2f%63%67i%2d%39%314/ HTTP/1.1" 400 326 "-" "-" ...
Immediately, we see entries such as "/%63g%69%2e%63%67%69%2f". This will need to be decoded. If we copy this into one of our decoding tools, we see this converts to "/cgi.cgi/". With this in mind, do we really wish to copy every entry inside of a tool and decode it?
Let's try to find an easy path to solve this problem. Let's cheat by installing gridsite-clients.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ sudo apt-get install gridsite-clients
With gridsite-clients installed, let's decode.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ urlencode -d "/%63g%69%2e%63%67%69%2f" /cgi.cgi/
Rather than going through all the entries, like we did above, let's just take a look at the HTTP status codes.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ cat access.log | awk --field-separator='1.1' '{ print $2 }' | \
cut --fields 2 --delimiter ' ' | sort | uniq --count | sort --numeric-sort --reverse 738 400 677 404 22 302 22 2 503 2 403 2 200 1 405
With a summary of the status codes, we see 400 and 404 representing the largest amounts. 4xx represents client side errors such as bad request (400) or resource not found (404). There is also 405. This represents the method was not allowed. 5xx represent server side errors. Here see 503. 503 is means the server cannot handle the request. We will focus on the 2 successful (200).
What is that 405 message about method not allowed?! Peeking ...
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ cat access.log | grep "405" 10.0.0.108 - - [31/May/2023:09:17:21 -0400] "PUT /n%69kt%6f%2d%74e%73%74-%73Naj%52%56%44%64%2eh%74%6dl HTTP/1.1" 405 321 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36"
So we see the attempt to use the put method. Let's decode what is was trying to put.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ urlencode -d "PUT /n%69kt%6f%2d%74e%73%74-%73Naj%52%56%44%64%2eh%74%6dl" PUT /nikto-test-sNajRVDd.html
Interesting, so Nikto tried to put a file on the server. We assume this failed because we got the message method not allowed.
Looking at the two 200 messages.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ cat access.log | grep --perl-regexp "\s+200\s+" 10.0.0.108 - - [31/May/2023:09:17:22 -0400] "OPTIONS * HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36" 10.0.0.108 - - [31/May/2023:09:17:22 -0400] "TRACE / HTTP/1.1" 200 210 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36"
Above, the two successes were for OPTIONS method and TRACE methods. It seems there is no further need for us to dig deeper into this log.
Let's peek into the error.log file.
There's a lot in here, I'm going to extract only the items which are core:error
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ cat error.log | grep --perl-regexp '10.0.0.108' | grep "core:error" | grep --perl-regexp '\s+\(.*?\)' --only-matching | cut --fields 2 --delimiter "(" | cut --fields=1 --delimiter=')' /%2e%2e/..%2f%2e%2e%2f.%2e%2f.%2e/../%2e.%2f%2e.%2f%2e.%2f../%2e.%2f%2e./%65t%63/%73ha%64o%77 /%64a%6ea%2d%6e%61%2f../d%61n%61%2f%68%74%6dl%35a%63%63%2fg%75%61%63a%6d%6fle/%2e%2e/%2e%2e/%2e./.%2e%2f%2e%2e%2f%2e%2e%2fe%74c/%70%61s%73w%64?/d%61na/ht%6dl%35acc/gua%63amo%6ce/
As before, this has to be decoded. Let's build on that output, by leveraging awk.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ cat error.log | grep --perl-regexp '10.0.0.108' | grep "core:error" | \
grep --perl-regexp '\s+\(.*?\)' --only-matching | cut --fields 2 --delimiter "(" | cut --fields=1 --delimiter=')' | \awk --field-separator='$' '{ system("urlencode -d " $1) }' /../../../../../../../../../../../../etc/shadow /dana-na/../dana/html5acc/guacamole/../../../../../../etc/passwd?/dana/html5acc/guacamole/
Awesome, we were able to decode via a one-liner. Above shows directory traversal attack looking for /etc/shadow and /etc/passwd. We know these are false positives because the web server is running on Windows. Hence nothing for us to analyze here.
Transitioning to packet analysis.
Detect - Packet Analysis
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ tshark -n -w tuning_2.pcap -f 'tcp port(80 or 443)' --interface eth0
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ tshark -n -r tuning_2.pcap -Y 'http.response.code == 405' -T fields -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport -e tcp.stream -E header=y ip.src ip.dst tcp.srcport tcp.dstport tcp.stream 10.0.0.106 10.0.0.108 80 43566 11
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ tshark -n -r tuning_2.pcap -q -z follow,tcp,ascii,10.0.0.106:80,10.0.0.108:43566 | grep 405 --before-context=10 --after-context=7 332 PUT /n%69kt%6f%2d%74e%73%74-%73Naj%52%56%44%64%2eh%74%6dl HTTP/1.1 Content-Type: application/x-www-form-urlencoded Connection: Keep-Alive Host: 10.0.0.106 Content-Length: 22 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36 This was a Nikto test. 608 HTTP/1.1 405 Method Not Allowed Date: Wed, 31 May 2023 13:17:21 GMT Server: Apache/2.4.56 (Win64) OpenSSL/1.1.1t PHP/8.0.28 Allow: POST,OPTIONS,HEAD,GET,TRACE Content-Length: 321 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>405 Method Not Allowed</title> </head><body> <h1>Method Not Allowed</h1> <p>The requested method PUT is not allowed for this URL.</p> <hr> <address>Apache/2.4.56 (Win64) OpenSSL/1.1.1t PHP/8.0.28 Server at 10.0.0.106 Port 80</address> </body></html>
Interestingly, though from above while the PUT method was not allowed, we see the server allows "POST,OPTIONS,HEAD,GET,TRACE". Moving on, nothing else to see with this method.
Looking at the two records where the response code is 200.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ tshark -n -r tuning_2.pcap -Y 'http.response.code == 200' -T fields -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport -e tcp.stream -E header=y ip.src ip.dst tcp.srcport tcp.dstport tcp.stream 10.0.0.106 10.0.0.108 80 46274 312 10.0.0.106 10.0.0.108 80 46314 315
Looking at stream 312.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ tshark -n -r tuning_2.pcap -q -z follow,tcp,ascii,10.0.0.106:80,10.0.0.108:46274 | grep 200 --before-context=8 --after-context=7 193 OPTIONS * HTTP/1.1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36 Connection: Keep-Alive Host: 10.0.0.106 187 HTTP/1.1 200 OK Date: Wed, 31 May 2023 13:17:22 GMT Server: Apache/2.4.56 (Win64) OpenSSL/1.1.1t PHP/8.0.28 Content-Length: 0 Keep-Alive: timeout=5, max=99 Connection: Keep-Alive
Nothing exciting there. Nothing exciting for the TRACE either.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2]
└─$ tshark -n -r tuning_2.pcap -q -z follow,tcp,ascii,10.0.0.106:80,10.0.0.108:46314 | grep 200 --before-context=8 --after-context=7
TRACE / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36
Connection: Keep-Alive
Host: 10.0.0.106
Trace-Test: Nikto
446
HTTP/1.1 200 OK
Date: Wed, 31 May 2023 13:17:22 GMT
Server: Apache/2.4.56 (Win64) OpenSSL/1.1.1t PHP/8.0.28
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: message/http
Nothing much more to do here via packet analysis. There is a lot in the packets but in this scenario, what is the real benefit of looking at 4xx and 5xx errors. If you have a different opinion on the 4xx codes, feel free to share your opinion in the chat.
┌──(kali㉿securitynik)-[~/nikto_stuff/zeek_stuff] └─$ sudo zeek --iface any --no-checksums
Let's see what can Zeek can tell us. Focusing primarily on the tasks which were successful:
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ cat http.log | grep --perl-regexp '\s+200\s+' | cut --fields 1 --delimiter='-' 1685539068.778266 CfTqVex3giFVuZHr1 10.0.0.108 46274 10.0.0.106 80 2 OPTIONS 10.0.0.106 * 1685539068.802076 CeV6D319VtYt5qKZHf 10.0.0.108 46314 10.0.0.106 80 1 TRACE 10.0.0.106 /
Let's take the UID "CfTqVex3giFVuZHr1" to see where else there is associated activity.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ grep "CfTqVex3giFVuZHr1" *.log | cut --fields=1 --delimiter=':' | sort --unique conn.log files.log http.log
So far, we've worked with the http.log, so there is no surprise that the conn.log file also shows up there. What's in the files.log. Let's go hunting there.
The files.log did not return anything meaningful.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ grep "CfTqVex3giFVuZHr1" files.log 1685539068.776983 F4eJjh2lgpWOQmofe CfTqVex3giFVuZHr1 10.0.0.108 46274 10.0.0.106 80 HTTP 0 (empty) text/html - 0.000000 - F 297 297 0 0 F - - - - - - - 1685539068.790150 Fx2Mtn4wvdujHy9u29 CfTqVex3giFVuZHr1 10.0.0.108 46274 10.0.0.106 80 HTTP 0 (empty) text/html - 0.000000 - F 326 326 0 0 F - - - - - - -
Moving on to IDS analysis
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 . --simulate-ips -k all
Taking a look at the alerts triggered for this activity. We see there were 37 alerts triggered.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ cat fast.log | cut --fields=3 --delimiter='[' | sort | uniq --count | sort --numeric-sort --reverse | wc --lines 37
Peeking into the top 5 alerts that triggered the most.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_2] └─$ cat fast.log | cut --fields=3 --delimiter='[' | sort | uniq --count | sort --numeric-sort --reverse | head --lines=5 122 1:2022028:2] ET WEB_SERVER Possible CVE-2014-6271 Attempt 8 1:2101402:9] GPL EXPLOIT iissamples access 7 1:2100977:15] GPL EXPLOIT .cnf access 5 1:2101245:13] GPL EXPLOIT ISAPI .idq access 4 1:2101129:9] GPL WEB_SERVER .htaccess acces
Nothing more to do here.
References:
https://www.urldecoder.net/linux-urldecode
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/PUT
https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS
https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/TRACE
No comments:
Post a Comment