GRP1 TASK NMAP AND WIRESHARK

downloaded from

Scholarfriends

https://scholarfriends.com

Downloaded by: browsegrades@gmail.com | https://scholarfriends.com/singlePaper/206498/grp1-task-nmap-and-wireshark Distribution of this document is illegal.

GRP1 — GRP1 TASK 1: NMAP AND WIRESHARK C844 Submitted by: Jeremy Cummings (000683884)

A. NMAP Network Topology In my initial scan of the 192.168.27.0/24 network with Zenmap, there were nine hosts found within this network. With this network scan, three of the systems were Microsoft Window servers (one Windows Server 2012 R2 device and two Windows Server 2016 Standard devices), three Linux systems (two of which were at OS version 3.10-4.11 and one that was at version 2.62-3.10), one Juniper SA2500 SSL VPN gateway, one machine at Windows 8.1, and one system at Windows 10 (build 1507-1607).



Hosts scanned:

Win Server 2012 R2

Win Server 2016 build 10586-14393

Win Server 2016 build 10586-14393

Juniper SA2500 SSL VPN gateway

Linux 3.10-4.11

Windows 8.1

Linux 2.6.32-3.10

Windows 10 build 1507-1607

Linux 3.10-4.11

B. Network Vulnerabilities  After completing the scan with Nmap, I was able to identify some vulnerabilities with several ports open that were being used consistently across the Windows devices on the network.

1. TCP Ports 445 and 139 (Server Message Block) on hosts 192.168.27.10, 192.168.27.11, 192.168.27.15, and 192.168.27.18. SMB is the transport protocol used by Windows for things such as file sharing, printer sharing, and access to remote Windows services. The WannaCry ransomware does take advantage of SMB vulnerability to compromise Windows devices to load malware and propagate that malware to other machines in a network (FIREEYE, 2017). US-CERT recommends disabling SMBv1 at the boundary of your network by blocking TCP port 445 and UDP ports 137-139 (US-CERT, 2017).

2. Remote Administration Protocols – SSH (port 22) on hosts 192.168.27.14 and 192.168.27.20; Telnet running on host 192.168.27.15; and VNC running on host 192.168.27.18. VNC is much like remote desktop protocol on a Windows device, it is used to connect remotely from one machine to another. Telnet, SSH, and VNC are all utilized fore remote administration. These protocols do pose a risk in unauthorized

access to another machine within the network, but they do serve as a legitimate resource if another more secure option is not available. If not properly secured, a potential attacker could brute force login credentials until they successfully gain access.

3. HTTP/FTP: hosts 192.168.27.12 and 192.168.27.18. Port 80 (common for HTTP) and port 21 (for the File Transfer Protocol). While either of these ports are not inherently bad to utilize within a network, they do transmit data/information in cleartext. This can introduce within Telnet, wherein attackers can eavesdrop on communications between hosts on a network.

4. OpenSSH on hosts 192.168.27.14 and 192.168.27.20. I did a quick internet search on OpenSSH and several common vulnerabilities that relate to version 6.6.1. One CVE with a critical score (CVE-2016-1908) states that a client “mishandles failed cookie generation for untrusted X11 forwarding and relies on the local X11 server for access-control decisions, which allows remote X11 clients to trigger a fallback and obtain trusted X11 forwarding privileges by leveraging configuration issues on this X11 server, as demonstrated by lack of the SECURITY extension on this X11 server” (National Institute of Standards and Technology, n.d.).

C. Anomalies from Wireshark

DNS: After analyzing the network capture within Wireshark, I observed many ICMP destination unreachable attempts from the host on 192.168.27.1 to host 192.168.27.17 as a result of DNS queries. It would almost appear that 192.168.27.17 has been configured to utilize 192.168.27.1 as a DNS server on the network, though the host on 192.168.27.1 is unreachable at this time (either PING has been disabled on a firewall or the server is down). This can open the possibility of an attacker configuring a fake host on the network that acts as 192.168.27.1. This fake host could then accept DNS queries, which could then provide any host (even host on 192.168.27.17) with harmful DNS resolutions. This fake DNS entries could then be set up to resolve to a legitimate looking site but could be harvesting domain credentials without the domain user knowing any better.

TELNET: In looking at the numerous entries on Telnet, one thing that caught my attention was the host on 192.168.27.15 making attempts to reach the host on 172.16.80.243. The last entry in there shows that the host on 27.15 attempts to make a connection to 80.243, which in my mind is a server or other entity and is trying to gain access to it. In the screenshot above, the length of packet is largest and the host on 27.15 is denied access to 80.243, due the source host not having permissions to access host on 80.243. The repeated attempt at accessing host on 80.243 is also seen as denied in the second screenshot. I get the feeling that the source host is trying to brute force its way in 80.243 and gets an access denied. I would have to say that disabling Telnet may be the safest option but seeing as host 27.15 is getting access denied, so my thought is that the username and password are secure as well as group membership to utilize it on host 80.243.

D. Summarization / Recommendations

o During the NMAP scan, it would be important to consider shutting down any unused ports within the network (where possible). If there is a host that doesn’t need to have port 21 (Telnet), that port should not be in an open/listening status.

If a port like Telnet needs to used, access to it should be limited to only those hosts that have a work-related requirement to use it. Limiting access can help mitigate any potential risks of an attacker exploiting any weaknesses that may be tied to the port(s). Vulnerability management comes to mind when locking things down and the Center for Internet Security’s Control 3 revolves around continuous vulnerability management. Its purpose is to “continuously acquire, assess, and take action on new information in order to identify vulnerabilities, remediate, and minimize the window of opportunity for attackers” (Center for Internet Security, Control 3).

o It would be worth considering that for the Linux hosts that were running OpenSSH version 6.6.1 should have that software patched to the latest version.

Older software/applications do pose a risk of attackers being able to exploit any vulnerabilities that may be present. I found several CVEs when searching for OpenSSH 6.6.1 and CVE-2016-10708 does mention that versions of OpenSSH prior to 7.4 “allows remote attackers to cause a denial of service” (CVE Details, 2016). o There were a few clear-text protocols being used on the network, Telnet, FTP, and HTTP. These protocols are set to transmit information in an unencrypted fashion, leaving valuable information in the open for a potential attacker to sniff out and capture. Switching over to more secure means that encrypt the data, like SFTP, HTTP, and SSH will at least encrypt the information as it traverses a network. o The scan of the network and its hosts presented some remote administration tools like Telnet and SSH. Not everyone host or user should be granted access to use such tools, thus they should only be allowed by authorized users and/computers that are mission critical. There are many ways that lock these down so to speak and one could make the adjustments on a host firewall (or network) or one could even configure these settings within the tools. o The Wireshark scan that was conducted also found an issue with DNS in which the host on 192.168.27.17 was using host 192.168.27.1 as a DNS server but there were ICMP host unreachable errors. To resolve this, one could edit the settings host 192.168.27.17 to not use 27.1 as its DNS server (Configure a New DNS Server, 2020).

E. References Configure a New DNS Server. (2020). Retrieved April 8, 2020 from https://technet.microsoft.com/en-us/library/cc771031(v=ws.11).aspx#BKMK_winui

Center for Information Security. (2020). Retrieved April 8, 2020 from https://www.cisecurity.org/controls/

SMB Exploited: Wannacry Use of “EternalBlue.” (2020). Retrieved April 8, 2020 from https://www.fireeye.com/blog/threat-research/2017/05/smb-exploited-wannacry-use-ofeternalblue.html

SMB Security Best Practices. (2017). Retrieved April 8, 2020 from https://www.uscert.gov/ncas/current-activity/2017/01/16/SMB-Security-Best-Practices

CVE Details: CVE-2016-10708. (n.d.). Retrieved April 8, 2020 from https://www.cvedetails.com/cve/CVE-2016-10708/