English | Deutsch
Home »

OpenVAS Change Request #25: OpenVAS-libnasl: Introducing support for WMI

Status: Voted #4. Done, released with openvas-libraries 3.0.0.

Purpose

To simplify connectivity to Windows systems, to allow for broader testing of currently supported Windows releases and to allow for testing newer Windows releases beyond Windows 2003 and Windows XP

Rationale

Most Windows-related NVT's depend on smb_nt.inc which offers SMB based connectivity to Windows systems. The implementation is limited in terms of its ability to perform newest authentication methods such as NTLMv1 and NTLMv2. Also limited by cryptographic functionality to perform SMB signing. The Windows Operating Systems, especially Windows 2003, Windows Vista and Windows 2008, by default are configured to negotiate the latest authentication method and perform SMB signing. Hence smb_nt.inc doesn't work with the above Operating Systems.

Also smb_nt.inc is limited in its features to provide all the functionality NVT's need in order to get a better posture of the Windows target system. The DCE/RPC connectivity to various RPC services for Windows is non-existent. Also the file and registry functions are limited.

Extensibility is also an issue with the current approach as smb_nt.inc relies on replaying the hardcoded packet structure. As the protocol gets extended or any new features added to the Windows, it is a challenge to update smb_nt.inc.

This change request proposes to incorporate support for WMI into OpenVAS-libnasl through interacting with wmi-client library.

Effects

This would, 

- Provide support to scan Windows 2003 (in its default configuration),
  Windows Vista and Windows 2008.
- Security policy changes to configure Windows system for local security
  checks is not required. Policies such as SMB signing, encryption, NTLM
  authentication levels are to be disabled currently.
- Ease the writing of Windows based NVT's through simplified calls and
  newly added functions.
- Number of new functions to interact with Windows based systems.
- This introduces to a further dependency, wmi-client library. It might
  be necessary to run this low privileges.

Design and Implementation

There were two approaches proposed initially,

  1. Integrate to SAMBA libraries to have support for SMB/CIFS protocol
  2. Implement WMI client: Windows Management Instrument(WMI) allows SQL like (WQL) queries through DCOM communication model to interact with Windows. SQL queries can be sent to the WMI service on the Windows systems, which exposes all Win32 API's, allowing access to every information from the Windows system including hardware, OS, Process, Service, Registry and File System.

After investigating SAMBA vs. WMI approach, it was decided to implement WMI because of the following advantages: 

- wmi-client is maintained tool based on SAMBA which is readily available
  for most current GNU/Linux distributions. It thus does not indroduce
  more complex dependencies than samba would.
- Integrating wmi-client is easier as it can be used via a leaner
  interface than would be needed for samba.
- Implementing WMI means that we can provide more functionalities to
  NASL than would have been possible through SAMBA as WMI allows us
  to have access to all win32 API's

Implementation Approach

There is a wmi-client package available for several GNU/Linux distributions available which depends on SAMBA for DCOM support. The wmi-client can be built as .so. wmi-client daemon would act as a proxy to OpenVAS serving WMI requests. The following interfaces would be implemented,

1. WQL queries

WMI allows to query Windows system information through SQL like queries called WQL. An example WQL query is, "Select Caption from Win32_Process". These WQL queries will be embedded in NASL library (inc) files so that NASL developers call these functions instead of having to build WQL queries for each specific task. Also, for backward compatiability, it is suggested to have both smb_nt.inc approach and the WMI client approach to work seamlessly. Hence implementing generic WMI queries in include files will help address backward comptiability issues.

2. WMI RSOP (Resultant Set Policies) Implementation

Windows system policies can be accessed through Win32 RSOP classes. WMI RSOP provider allows to have access to all the policy items through this provider. WMI queries in the form of WQL can be sent to this provider.

3. WMI Registry provider

To access the Windows System Registry, we need to make use of StdRegProv provider. Through WMI, it is possible to interact with this provider to access Windows Registry.

Example Code

Functions to list all the Windows Process and Service 

 1. wmi_get(query:"Select Caption from Win32_Process");

 Response:
  CLASS: Win32_Process
  Caption|Handle
  System Idle Process|0
  System|4
  smss.exe|384
  csrss.exe|724
  winlogon.exe|748 
  services.exe|792
  lsass.exe|804
  svchost.exe|956
  svchost.exe|1056
  svchost.exe|1140
  svchost.exe|1192 
  svchost.exe|1240
  spoolsv.exe|1528
  FrameworkService.exe|1748
  Mcshield.exe|1776
  VsTskMgr.exe|1828
  naPrdMgr.exe|1876
  VMwareService.exe|208
  explorer.exe|1204
  VMwareUser.exe|1360
  shstat.exe|1372
  UdaterUI.exe|1380 
  Mctray.exe|1420
  wscntfy.exe|920
  alg.exe|1040
  IEXPLORE.EXE|1684
  wmiprvse.exe|2560

 2. wmi_get(query:"Select * from Win32_Service");

 Response:
  AcceptPause|AcceptStop|Caption|CheckPoint|CreationClassName|Description|DesktopInteract|DisplayName|ErrorControl|ExitCode|InstallDate|Name|PathName|ProcessId|ServiceSpecificExitCode|ServiceType|Started|StartMode|StartName|State|Status|SystemCreationClassName|SystemName|TagId|WaitHint
 
  False|True|IPv6 Helper Service|0|Win32_Service|Provides DDNS name registration and automatic IPv6 connectivity over an IPv4 network.  If this service is stopped, other computers may not be able to reach it by name and the machine will only have IPv6 connectivity if it is connected to a native IPv6 network.  If this service is disabled, any other services that explicitly depend on this service will fail to start.|False|IPv6 Helper Service|Normal|0|(null)|6to4|C:\WINDOWS\system32\svchost.exe -k netsvcs|1140|0|Share Process|True|Auto|LocalSystem|Running|OK|Win32_ComputerSystem|FRESHXPSP2|0|0
  False|False|Alerter|0|Win32_Service|Notifies selected users and computers of administrative alerts. If the service is stopped, programs that use administrative alerts will not receive them. If this service is disabled, any services that explicitly depend on it will fail to start.|False|Alerter|Normal|1077|(null)|Alerter|C:\WINDOWS\system32\svchost.exe -k LocalService|0|0|Share Process|False|Disabled|NT AUTHORITY\LocalService|Stopped|OK|Win32_ComputerSystem|FRESHXPSP2|0|0
  False|True|Application Layer Gateway Service|0|Win32_Service|Provides support for 3rd party protocol plug-ins for Internet Connection Sharing and the Windows Firewall.|False|Application Layer Gateway Service|Normal|0|(null)|ALG|C:\WINDOWS\System32\alg.exe|1040|0|Own Process|True|Manual|NT AUTHORITY\LocalService|Running|OK|Win32_ComputerSystem|FRESHXPSP2|0|0
  False|False|Application Management|0|Win32_Service|Provides software installation services such as Assign, Publish, and Remove.|False|Application Management|Normal|1077|(null)|AppMgmt|C:\WINDOWS\system32\svchost.exe -k netsvcs|0|0|Share Process|False|Manual|LocalSystem|Stopped|OK|Win32_ComputerSystem|FRESHXPSP2|0|0
  False|True|Windows Audio|0|Win32_Service|Manages audio devices for Windows-based programs. If this service is stopped, audio devices and effects will not function properly. If this service is disabled, any services that explicitly depend on it will fail to start.|False|Windows Audio|Normal|0|(null)|AudioSrv|C:\WINDOWS\System32\svchost.exe -k netsvcs|1140|0|Share Process|True|Auto|LocalSystem|Running|OK|Win32_ComputerSystem|FRESHXPSP2|0|0
  False|True|Background Intelligent Transfer Service|0|Win32_Service|Transfers data between clients and servers in the background. If BITS is disabled, features such as Windows Update will not work correctly.|False|Background Intelligent Transfer Service|Normal|0|(null)|BITS|C:\WINDOWS\system32\svchost.exe -k netsvcs|1140|0|Share Process|True|Auto|LocalSystem|Running|OK|Win32_ComputerSystem|FRESHXPSP2|0|0

Implementation Phases

  1. Phase I: 
    a. Create wmi-client library 
    
b. openvas-libasl interaction with wmi-client
    
   - WQL query execution
  2. Phase II: 
    a. WMI Client enhancement for RSOP 
    
b. NASL Library functions based on generic WQL queries 
    
- Registry
- File system
- Services
- Process
- System
- Policy
- User accounts

  3. Phase III:
a. WMI Client enhancements for Windows Registry and File Effective Rights. The
following functions will be implemented,
- wmi_connect_reg
- wmi_close
- CheckAccess
- EnumKey
- EnumValues
- GetBinaryValue
- GetDWORDValue
- GetExpandedStringValue
- GetMultiStringValue
- GetQWORDValue
- GetSecurityDescriptor
- GetStringValue
- CreateKey
- DeleteKey
- DeleteValue
- GetFileEffectiveRights
  4. Phase IV: 
    - Wrapper NASL inc's to support earlier methods (smb_nt.inc) and new WMI methods
    Backward compatibility:

    With the introduction of WMI client interface,
    1. All old Windows Plugins will continue to work with smb_nt.inc approach which require policy changes etc at each Windows box, to not have signing/encryption enabled, to not have NTLM authentication etc.,

    2. All new Plugins will start using WMI, it'll make it mandatory to have WMI support with OpenVAS, otherwise Windows Plugins will not work. People using the older version of OpenVAS will not be able to run newer Plugins that use WMI.

    To handle the above issue, we can introduce a NASL inc layer that'll call either method (smb_nt.inc or WMI) according to the availability of WMI client library. If client library is available, it'll invoke the corresponding function or else it'll try the old function.

  5. Phase V: 
    - Update OpenVAS compendium documenting all the newly added functions.

History