Questions[nessus](server)

I have nessus professional 8.14.0 installed on a server, which is attached to the network, 3 esxi 6.7 hosts and 1 vcenter servers.

Nessus Server (192.168.1.21)

vCenter Server (192.168.1.9)

ESXi Host 1 (192.168.1.10)

ESXi Host 2 (192.168.1.11)

ESXi Host 3 (192.168.1.12)

If I run a scan with just host 1 (192.168.1.10) in the targets.

Warning

Possible Reasons :

• VMware vSphere Username/Password were not supplied.
• Unable to authenticate with the VMware vCenter server on port 443.

If I run a scan with just host 1 (192.168.1.10) and vCenter (192.168.1.9) in the targets.

On host vCenter server I get about 68 warnings.

On host 1 I get:

Possible Reasons :

• VMware vSphere Username/Password were not supplied.
• Unable to authenticate with the VMware vCenter server on port 443.

The complicanse file I am using is "cis vmware esxi 6.7 v1.1.0 level 2" or "cis vmware esxi 6.7 v1.1.0 level 1"

Settings:

Target: 192.168.1.9, 192.168.1.10 or just 192.168.1.10

VMWare vCenter SOAP API:

I have also tried the bare metal scans, which ask for ssh creds, however the Credentials scans = No, which will not do.

Any suggestions on what I am missing?

I have double checked and tripple check the password,

From the nessus host I can telnet to vCenter and Host 1 on port 443.

How do I test the SOAP API access? I have googled to the end of google and cannot find out how this is done.

A Nessus plugin 44676 audit scan revealed this issue: "SMB Insecurely Configured Service" Description At least one insecurely configured Windows service was detected on the remote host. Unprivileged users can modify the properties of these affected services.

An unprivileged, local attacker could exploit this to execute arbitrary commands as SYSTEM. Solution Ensure the 'Everyone' group does not have ChangeConf, WDac, or WOwn permissions. Refer to the Microsoft documentation for more information. See Also http://support.microsoft.com/kb/914392 http://msdn.microsoft.com/en-us/library/ms685981(VS.85).aspx Output • The following service has insecure permissions for Everyone: •
• Task Scheduler (Schedule) : DC, WD, WO

I copied the security descriptor from another machine that doesn't have this issue, with sc sdshow schedule. Then I tried to set it on the affected machine with sc sdset schedule *SDDL_security_descriptor*. But when I rebooted the machine and then checked again with the sdshow, it was back to what it was before. Does anyone know how to make this work or another remediation for this finding?

I have Nessus 5 installed under KaLi. Whenever I start Nessus (i.e. nessusd), then it takes like half an hour to initialize. Is there anything one can do to speed up this process?

I have openVAS installed from the atomic corp YUM repo, and it all seems to be functioning wonderfully, however I am seeing a single "Security Hole" which is that OpenVAS detects that "arora" is installed on the system, (which it is not)

I am getting a positive result for "Arora Common Name SSL Certificate Spoofing Vulnerability (Linux)" which is documented here;

I pulled up the script, and it seems to be searching the binary with file name "arora"; (

modName = find_file(file_name:"arora", file_path:"/usr/bin/",
                      useregex:TRUE, regexpar:"$", sock:sock);

However the target in question does not have any binaries installed called arora, nor even any documents with files, or even sub strings "arora" in a case insensitive search;

[root@52-56-149-11 ~]# locate Arora
[root@52-56-149-11 ~]# locate rora
[root@52-56-149-11 ~]# locate arora
[root@52-56-149-11 ~]# find / | grep -i arora

all return nothing.

Can I run this test by hand, and inspect the values or something?

(I am new to openvas nasl scripts, so any points to documentation would be helpful, I did look at the troubleshooting guide in the 1.0.1 compendium, but I could not work out how to send the SSH Credentials as parameters to the nasl script)

Full source of my installed copy of the test is as follows;

###############################################################################
# Openvas Vulnerability Test
# $id: secpod_arora_cn_ssl_cert_spoofing_vuln_lin.nasl 2011-12-15 14:01:47z dec $
#
# Arora Common Name SSL Certificate Spoofing Vulnerability (Linux)
#
# Authors:
# Madhuri D<[email protected]  <mailto:[email protected]>>
#
# Copyright:
# Copyright (c) 2011 SecPod,http://www.secpod.com  <http://www.secpod.com/>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the gnu general public license version 2
# (or any later version), as published by the free software foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
###############################################################################

if(description)
{
  script_id(902764);
  script_version("$Revision$");
  script_cve_id("CVE-2011-3367");
  script_bugtraq_id(49925);
  script_tag(name:"cvss_base", value:"5.0");
  script_tag(name:"cvss_base_vector", value:"AV:N/AC:L/Au:N/C:N/I:P/A:N");
  script_tag(name:"risk_factor", value:"Medium");
  script_tag(name:"last_modification", value:"$Date$");
  script_tag(name:"creation_date", value:"2011-12-15 14:01:47 +0530 (Thu, 15 Dec 2011)");
  script_name("Arora Common Name SSL Certificate Spoofing Vulnerability (Linux)");
  desc = "
  Overview: This host is installed with Arora and is prone common name SSL
  certificate spoofing vulnerability.

  Vulnerability Insight:
  The flaw is caused due to not using a certain font when rendering certificate
  fields in a security dialog.

  Impact:
  Successful exploitation will allow remote attackers to spoof the common name
  (CN) of a certificate via rich text.

  Impact Level: Application.

  Affected Software :
  Arora version 0.11 and prior

  Fix: No solution or patch is available as on 15th December 2011. Information
  regarding this issue will be updated once the solution details are available
  For updates refer,http://code.google.com/p/arora/downloads/list

  References:
  http://secunia.com/advisories/46269
  http://www.securityfocus.com/archive/1/520041
  https://bugzilla.redhat.com/show_bug.cgi?id=746875
  http://archives.neohapsis.com/archives/fulldisclosure/2011-10/att-0353/NDSA20111003.txt.asc  ";

  script_description(desc);
  script_summary("Check for the version of Arora");
  script_category(ACT_GATHER_INFO);
  script_copyright("Copyright (C) 2011 SecPod");
  script_family("General");
  script_dependencies("find_service.nes");
  script_mandatory_keys("login/SSH/success");
  exit(0);
}


include("ssh_func.inc");
include("version_func.inc");

## Open SSH Login connection
sock = ssh_login_or_reuse_connection();
if(!sock){
  exit(0);
}

## Confirm Linux, as SSH can be instslled on Windows as well
result = ssh_cmd(socket:sock, cmd:"uname");
if("Linux">!<  result){
  exit(0);
}

grep = find_bin(prog_name:"grep", sock:sock);
grep = chomp(grep[0]);

garg[0] = "-o";
garg[1] = "-m1";
garg[2] = "-a";
garg[3] = string("[0]\\.[0-9][0-9]\\.[0-9]");

## Getting arora file path
modName = find_file(file_name:"arora", file_path:"/usr/bin/",
                      useregex:TRUE, regexpar:"$", sock:sock);
foreach binaryName (modName)
{
  binaryName = chomp(binaryName);
  arg = garg[0] + " " + garg[1] + " " + garg[2] + " " + raw_string(0x22) +
          garg[3] + raw_string(0x22) + " " + binaryName;
}

## Grep the version
arrVer = get_bin_version(full_prog_name:grep, version_argv:arg,
                              ver_pattern:"([0-9.]+)", sock:sock);
if(arrVer)
{
  ## Check the arora version
  if(version_is_less_equal(version:arrVer[0], test_version:"0.11.0")){
      security_warning(0);
  }
}

ssh_close_connection();


  [1]: http://wald.intevation.org/scm/viewvc.php/trunk/openvas-plugins/scripts/secpod_arora_cn_ssl_cert_spoofing_vuln_lin.nasl?root=openvas&view=markup

I'm testing out both Tenable's Nessus scanner as well as eEye's Retina for scanning network devices. I am trying to supply credentials to get deeper, more accurate results, however there seems to be no difference in the results whether I supply the credentials or not. I've read the documentation and it seems like I've tried all the logical settings in the Credential options. I've submit along with usernames and passwords for many different accounts and types of accounts (both SSH Credentials and Web Application Credentials) on the devices as well as their respective domain names (when applicable).

Is there possibly a good test for either (or both) scanners to tell where these credentials are being provided (if at all) and if any of them are successfully getting authentication?