QuestionQuestion

Transcribed TextTranscribed Text

Project Final Report Foundations of Information Assurance The project for this course is to perform a security assessment on a network of virtual machines. At this point you have created and configured this network. You have begun the first phase of discovering and documenting the vulnerabilities in the network using a variety of scanning tools and techniques. In the second phase you will write a paper that documents the vulnerabilities you found and suggests mitigations. To complete the first phase you may continue to run similar scans to what you've already done for the assignments from different locations in the network or with different scanner settings. You may also consider using other scanning/assessment tools. The report should be about 10-15 pages. Consider known vulnerabilities, network snooping, viruses, password usage, Trojan horses, etc. For vulnerabilities discovered analyze the suggested mitigations or patches. Explain how an attacker might exploit the vulnerability and how the recommended patch would mitigate it. In some cases consider explaining how the vulnerability was discovered or whether it is known to have been exploited by attackers. Foundations of IA Lab layout Adtresz: chOIP - 12.168.0.12 Inside VLAN Firewall Outside Scanning Outside VI AN IP Address 1020002/29 vSwitch Public" Computer Hostname: pc1.seclab.nct DM7 VI AN II³ Address. 102.168.0.101/21 vSwildh Inside Scanning Web Server IP Address. 102. 169.0.2/24 Hostname. www.sedab.net IP Address 10 2000 12/29 DNS Server Hostname nst seclab net II' Address 10.200.0.11/29 DMZ Scanning IP Address 10.200.0.10/29

Solution PreviewSolution Preview

These solutions may offer step-by-step problem-solving explanations or good writing examples that include modern styles of formatting and construction of bibliographies out of text citations and references. Students may use these solutions for personal skill-building and practice. Unethical use is strictly forbidden.

Project Final Report

A. Executive Summary/Introduction

1. Motivation

• Web applications are becoming primary target of cyber-attack.
New vulnerabilities are found every day in the system, networking and software

• Web application security is a hard task because these applications are exposed to the people.
Processing requests that comes through HTTP request is difficult. Firewall , network scanner cannot make sure of the secure of the web site

2. Analyzed network

• Webserver www.seclab.net/ Ubuntu server

• DNS server ns1.seclab.net / Centos

3. Tools and techniques

• Openvas

• CVE

4. High-level results and analysis

• Most vulnerabilities could be fixed by upgrading the software

• We could eliminate the number of vulnerabilities by restricting the public access to the system

• Attackers could gain more chances to figure out vulnerabilities of our network when they know the version of our software

B. Vulnerabilities Found

1. DNS server

• SSH Brute Force Logins With Default Credentials Reporting

1. It was possible to login into the remote SSH server using default credentials.

2. It was possible to login with the following credentials <User>:<Password> root:password

• SSH Weak Encryption Algorithms Supported

1. The remote SSH server is configured to allow weak encryption algorithms.

2. These weak client-to-server ans server–to-client encryption algorithms are supported by the remote service

a. 3des-cbc

b. aes128-cbc

c. aes192-cbc

d. aes256-cbc

e. arcfour

f. arcfour128

g. arcfour256

h. blowfish-cbc

i. cast128-cbc

j. rijndael-cbc@lysator.liu.se

3. Insight

a. The `arcfour` cipher is the Arcfour stream cipher with 128-bit keys. The Arcfour cipher is believed to be compatible with the RC4 cipher [SCHNEIER]. Arcfour (and RC4) has problems with weak keys, and should not be used.

b. A vulnerability exists in SSH messages that employ CBC mode that may allow an attacker to recover plaintext from a block of ciphertext.

• TCP timestamps

1. The remote host implements TCP timestamps and therefore allows to compute the uptime.

2. Vulnerability detection result

a. It was detected that the host implements RFC1323.

b. The following timestamps were retrieved with a delay of 1 seconds in-between:

i. Packet 1: 16305722

ii. Packet 2: 16306853

3. Impact: A side effect of this feature is that the uptime of the remote host can sometimes be computed.

• SSH Weak MAC Algorithms Supported

1. The remote SSH server is configured to allow weak MD5 and/or 96-bit MAC algorithms.

2. Vulnerability Detection Result : The following weak client-to-server and server-to-client MAC algorithms are supported by the remote service:

a. hmac-md5

b. hmac-md5-96

c. hmac-sha1-96

2. Web server

• X Server

1. Attacker may send garbage data and slow down our X session or even kill the server.

• Check for rexecd Service

1. rexecd authenticate by reading the username and password *unencrypted* from the socket.

• TWiki XSS and Command Execution Vulnerabilities

1. The host is running TWiki and is prone to Cross-Site Scripting (XSS) and Command Execution Vulnerabilities.

2. Successful exploitation could allow execution of arbitrary script code or commands. This could let attackers steal cookie-based authentication credentials or compromise the affected application.

• Distributed Ruby (dRuby/DRb) Multiple Remote Code Execution Vulnerabilities

1. Systems using Distributed Ruby (dRuby/DRb), which is available in Ruby versions 1.6 and later, may permit unauthorized systems to execute distributed commands.

2. The service is running in $SAFE >= 1 mode. However it is still possible to run arbitrary syscall commands on the remote host

3. Impact:

a. By default, Distributed Ruby does not impose restrictions on allowed hosts or set the $SAFE environment variable to prevent privileged activities.

b. If other controls are not in place, especially if the Distributed Ruby process runs with elevated privileges, an attacker could execute arbitrary system commands or Ruby scripts on the Distributed Ruby server.

c. An attacker may need to know only the URI of the listening Distributed Ruby server to submit Ruby commands.

• Possible Backdoor: Ingreslock

1. A backdoor is installed on the remote host

2. Ingreslock is a legitimate service that uses 1524 port. TCP 1524 is often used by Trojans as a backdoor.

3. The Ingreslock backdoor may be used as an intentional backdoor by malicious actors to obtain access to a system. Malicious actors only need to connect to the port, and they will be logged in, having the same
privileges as the user running the service

• OS End Of Life Detection

1. The Operating System (cpe:/o:canonical:ubuntu_linux:8.04) on the remote host has reached the end of life at 09 May 2013 and should not be used anymore.

• DistCC Remote Code Execution Vulnerability

1. DistCC 2.x, as used in XCode 1.5 and others, when not configured to restrict access to the server port, allows remote attackers to execute arbitrary commands via compilation jobs, which are executed by the server without authorization checks.

2. It was possible to execute the "id" command. Result: uid=1(daemon) gid=1(daemon)

• VNC Brute Force Login

1. It was possible to connect to the VNC...

By purchasing this solution you'll be able to access the following files:
Solution.docx.

$128.00
for this solution

or FREE if you
register a new account!

PayPal, G Pay, ApplePay, Amazon Pay, and all major credit cards accepted.

Find A Tutor

View available Network Management and Data Communication Tutors

Get College Homework Help.

Are you sure you don't want to upload any files?

Fast tutor response requires as much info as possible.

Decision:
Upload a file
Continue without uploading

SUBMIT YOUR HOMEWORK
We couldn't find that subject.
Please select the best match from the list below.

We'll send you an email right away. If it's not in your inbox, check your spam folder.

  • 1
  • 2
  • 3
Live Chats