Alert Logic scanning technical description

Technical Description

Port scan

The port scanning segment of the scanning process is split into two parts: the TCP port scan and the UDP port scan. Alert Logic uses full connect scans on both types of ports.

TCP port scan

1. The scanner makes a connection to the target server through each port in the scan policy.
2. The scanner executes a full RFC compliant TCP/IP handshake
3. Each port gives one of three responses:
   • Port open: These ports get examined further in the next step of the scanning process.
   • Port closed: These ports are ignored for the remainder of the scan.
   • No answer or dropped package: These ports are filtered out because the Alert Logic request can not get through. The time out period on these ports is ten seconds.

UDP port scan

1. The scanner attempts to make a connection to the target server through each port in the scan policy.
2. The scanner waits the maximum amount of time for each port.

3. The scanner labels each port as open or filtered.

   UDP ports do not always send responses even if they are open, so the scanner sometimes labels open ports as filtered.

Service detection

After the port scan finds open ports, the service detection segment of the scan identifies which services are running on the port. The scanner searches all open ports for all known services, in case services are running on non-standard ports.

1. The scanner sends traffic to ports using various protocols and records those that get responses.
   • TCP ports: The scanner sends specific queries to the port until it receives a recognizable response.
   • UDP ports: Because UDP ports without connection errors are inferred to be open, UDP service detection is both slow and unreliable. Many systems filter out ICMP error messages, or only send a certain number of error messages per second.
2. The scanner analyzes each response received and determines which type of service sent the response.

Version detection

The version detection segment of the scan attempts to identify the following items for the port:

• Version numbers for each service on the port
• Applications running on the service
• Third-party plug-ins
• Security patches

This phase of the scan is done in two steps:

1. The scanner runs the Nmap service and version detection.
2. The scanner runs proprietary Alert Logic service and version detection.

Results from the two steps are then combined together into a comprehensive list of software, versions, and patches.

Vulnerability evaluation

In the vulnerability evaluation phase, Alert Logic compares the software/version/patch list to its vulnerability database. The database includes over 70,000 vulnerable versions and their associated vulnerabilities. The scanner matches the software list with the vulnerability database and provides clients with a list of vulnerabilities that may be present in their environments.

Assessment scope

Following is a sample list of services, devices, and operating systems that Alert Logic tests:

Operating systems

• Linux
• Microsoft® Windows®

Web servers

• Apache
• Microsoft® IIS

Web application servers

• Apache Jakarta Tomcat
• JBOSS

Common web script

• Commonly found scripts (typically, common gateway interface [CGI] scripts) written in various languages
• Ecommerce-related scripts, such as shopping carts and CRM scripts
• ASP
• PHP

Database servers

• Microsoft SQL Server™
• MySQL®
• Oracle®
• PostreSQL

Mail servers

• Microsoft® Exchange
• SendMail™

Firewalls

• Cisco PIX®
• NetScreen

Routers

• Cisco

Common services

• Domain name system (DNS)
• file transfer protocol (FTP)
• simple mail transfer protocol (SMTP)

Router check

The scanning solution tests the router for known vulnerabilities and configuration issues in the firmware.

Firewall check

• Check for up-to-date patches on known vulnerabilities
• Check for open ports indicating inadequate configuration

Operating system check

Vendors release patches to address new exploits and flaws. The scanning solution verifies that the operating system has the latest patches installed.

Database check

New exploits are found regularly for database products. The scanning solution detects exploits and open access to databases.

Web server check

The scanning solution tests for all known vulnerabilities, exploits, and configuration issues on web servers. New exploits are routinely discovered in web server products. The scanning solution detects and reports known exploits. The scanning solution checks for other best practices, for example, making sure that directory browsing is not possible on the server.

Complex passwords

Alert Logic supports complex passwords; however, some special characters give command line interfaces difficulty, as they have special meanings. Keep your password special characters limited to numbers (0-9), periods (.), colons (:), semi-colons (;), quotes (',',","), percentages (%), and spaces ( ).

Scanning depth

Alert Logic scanning enables safe and accurate assessments without affecting network operations. If the system finds an open SNMP service, it will poll it for as much information as possible (true operating system, real hostname, patch level), but it will not attempt to exploit holes to demonstrate what an attacker can do.

Backporting

Backporting involves taking a software patch and applying it to an older version of the software than the version it was designed to modify. Backporting is specific to some UNIX/Linux and open source vendors. See also Red Hat about backporting security fixes.

If you are using zero privileged level of network scanning, then Alert Logic scanning provides the option to ignore a vulnerability, which documents the presence of your vendor-supplied patch and suppresses further reporting of this issue on those IP addresses. You can export the list of ignored vulnerabilities as a report to give to other auditors showing the documented fixes for supposed network vulnerabilities. Network scanners report based on the found version, and auditors expect all vulnerabilities to be enumerated and exceptions to be documented.

The best way to handle backported patches is to do credentialed scans. The preferred method for handling this is using the OVAL algorithm and data feeds Alert Logic gets directly from RedHat and other Linux vendors. When you run scans with credentials, the system automatically enumerates the list of installed patches and auto-suppresses vulnerabilities that have been addressed by backported patches. Alert Logic scanning can do this internally and externally from the internet, but it requires standard user access to a Secure Shell (SSH) service on that computer.

When a network vulnerability scanner assesses a computer, it bases some of its findings on found versions of software. If these versions are known to be vulnerable to certain issues, they are enumerated as vulnerable to their respective CVEs. If your vendor backports security fixes and does not update the software version number, you may not be vulnerable despite what the Alert Logic vulnerability report states.

Scanning system details

SSL certificate host name discrepancy

This vulnerability appears in a report when the name listed in the SSL certificate configuration does not match the name used to access the host. This is an automatic failure for external PCI assessment scans due to the inability to verify the legitimacy of the host.

This vulnerability commonly appears when an administrator reuses an SSL certificate from one web application for another. For example, an SSL certificate created for www.mydomain.com cannot be used for mypage.mydomain.com.

Mitigation

Use the mitigation methods listed below to address this vulnerability.

• External sites
  • Purchase a new SSL certificate created specifically for your web application.
  • Use a wildcard SSL certificate for any page on the domain.
• Internal methods
  • Update the reverse DNS record of the IP address to be the same as the subject of the SSL certificate. The scan will automatically detect the reverse DNS name and if it matches the subject of the SSL certificate, the issue will not be flagged.
  • Update the SSL Certificate subject line to match the host name of the device.
• Other methods
  • If the scanner was unable to resolve a host name for the host, it is typically related to the configured DNS servers not having a record of the host.
  • If the certificate is not valid because it is a generic or default self-signed certificate, you can choose to filter the vulnerability at the IP or job level. If the host name (or lack thereof) provided by the certificate does not match the host name discovered during scanning, this is a valid finding. Filtering this vulnerability is at the discretion of the client only.

False positives

False positive in external or internal scan

If the scan result is a false positive, you can make the exposure inactive to remove the results from reports.

False positive in PCI scan

In many cases, the SSL certificate host name discrepancy appears because the host was scanned via IP address instead of via fully qualified domain names (FQDN). PCI-DSS requires customers to supply FQDNs in addition to providing all external-facing IP addresses and all other unique entryways into applications for the entire in-scope infrastructure. You must include this information when you schedule a scan.

If you deploy load balancers, the scan may only see part of the configuration behind the load balancer. In these cases, the following applies:

• Localized load balancers: You must supply documentation showing that the infrastructure behind the load balancer(s) is synchronized in terms of configuration.
• External load balancing services: Implement a configuration to ensure that all IP addresses and ranges provided are successfully scanned.

If you believe that a PCI assessment failure was in error, first verify that the FQDN resolves to the host using an outside source such as www.sslshopper.com or www.digicert.com/help. These sources may also identify other certificate problems.

PCI scan disputes

If the FQDN resolves to the host, you may submit a dispute. Provide the FQDN in the dispute comment so that Alert Logic can validate the certificate. Enter only one FQDN per host. A single dispute comment containing a blanket statement for all hosts found in the scan is not acceptable. In the case of a load balancer, provide all expected IP resolutions of the FQDN and confirm that hosts behind the load balancer are in sync.

In general, using the FQDN in the scan configuration prevents this vulnerability from appearing.

Brute force user name and password guessing

Alert Logic scanning performs some user name and password guessing; however, it does not perform an all-out brute force attempt against accounts. Many devices come with default administrative account names, and the system checks for standard user name/password combinations, such as:

• 3Com hubs/switches default logon—manager:manager
• Windows Network—administrator:administrator or administrator:blank
• MS-SQL—sa:blank

Denial-of-service attacks and buffer overflows

Alert Logic does not run any test that can cause significant or fatal damage to a system or application. Alert Logic can test some buffer overflow and denial-of-service (DoS) vulnerabilities without harming your server or service. Strict quality assurance measures ensure tests are safe before release. It is impossible to test for all configuration possibilities and it is difficult to completely rule out any disruptions.

For vulnerabilities that require a non-active testing method, the Alert Logic scanning system deploys a passive scan operation utilizing versioning, configuration testing, and inference to determine the likelihood of the existence of a given vulnerability. Vulnerabilities that cannot be completely verified are stated as warnings, with associated detail to evaluate mitigation strategies for that issue.

Denial-of-service situations

Alert Logic has identified two scenarios in which active testing could cause a DoS situation on a network.

• Consumption of firewall connections/exhaustion of firewall resources
  If an internal Threat Manager appliance is placed behind a firewall and instructed to scan computers on the other side of the firewall, the appliance could exhaust the available outbound connections/resources of the firewall. This has happened on Cisco PIX firewalls where port address translation (PAT) was used to PAT private, internal addresses to the outside interface. During the port scanning phase of the scan, a large number of connections are initiated to identify all open ports on a target device.
  To avoid this scenario:
  1. Place the appliance on a segment of the network where it does not have to go through the firewall to reach the target.
  2. Provide a static IP translation for the IP address of the testing unit. This reduces the number of connections the firewall must "remember" during testing.
• Debug level logging/religious logging
  An appliance performing a high level of logging can cause a DoS situation. This has happened in both internal and external testing. This scenario is a classic security vulnerability. If a firewall logs every connection attempt to a remote system, it could generate gigabytes of log file traffic, which causes a strain on network infrastructure and exhausts file system resources of the remote logging console. This is a known problem with debug-level logging (i.e., logging everything). When a port scan is performed, the number of connections to a device can range from 1,500/3,000 ports connection attempts up to 65,535/131,070 ports connection attempts. To prevent a DoS situation, use a lower level of logging.

Scans and network performance

The Alert Logic scan engine includes the following features designed to protect network performance:

• Active scan tools designed and tested to be sensitive to network operations
• Passive asset profiling that does not require an active test
• Scan job configuration options
• Schedule configuration options
• Bandwidth limits on scan jobs
• Custom parameters for more light or heavy port scanning
• Option to exclude IP addresses for devices that may not respond well to scanning
• Flexible scheduling to ensure scan activity occurs only during approved times

Load-balancing devices

If your environment has a web farm behind a load-balancing device, there is no way to asses all devices, because the load-balancing device creates the algorithm that determines load distribution. The Alert Logic software would find issues in your code base, but computer-specific issues might be missed due to the decisions made by the load-balancing device.

To ensure that Alert Logic scans each device, place a Threat Manager appliance where it reaches the individual computers in the web farm.

Operating systems

Alert Logic scanning generally tests for any operating system that supports a TCP/IP stack; however, results vary among operating systems. DOS and Windows 3.1 WFWG support TCP/IP, but few known vulnerabilities exist for these systems.

Alert Logic does not rely on operating system guessing as a part of vulnerability assessments. For instance, a network that uses an F5 BIG-IP load balancer on its perimeter would skew the results of a test that relied on operating system guessing. While the web site being hosted could reside on a Microsoft IIS server, the BIG-IP itself fingerprints as a BSD UNIX operating system. In this case, a more comprehensive test prevents inaccurate and possibly dangerous results.

Operating system and host name reporting

Operating system guessing and host name determination in Alert Logic scanning is based off of a weighted system. The report shows the item with the highest weight (confidence factor).

Examples of the host name weighted system are as follows:

Method	Weight
DNS forward lookup	1
FTP/SMTP/Telnet/IMAP/POP3 Banners	4
SSL Certificate Subject Names	5
MS RPC	5
SNMP	6
MSSQL	8
NetBIOS – nbtstat	12
Authenticated SSH	13
Authenticated NetBIOS	15

Examples of the host weighted system are as follows:

Operating system guessing method	Weight
IP Fingerprinting (nmap)	2
HTTP Server Headers	5
FTP/SMTP/Telnet/IMAP/POP3 Banners	6
NetBIOS – nbtstat	8
Authenticated – SNMP	10
Authenticated – SSH	11
Authenticated – NetBIOS	15

Authenticated scanning

Alert Logic allows you to use credentials to perform host-level authenticated scanning. Using Windows or SSH credentials as part of your scans allows for more accurate vulnerability scans and lowers the number of false positive results.

This section provides information on:

• Windows authenticated scanning
• UNIX/Linux authenticated scanning
• Amazon Web Services authenticated scanning
• Credential storage

Windows authenticated scanning

Windows authenticated scanning is an authenticated network-based method for interrogating the target machine for missing security-related patches and updates.

To run Windows authenticated scanning, you must set up the following parameters:

• Credentials— Alert Logic scanning needs a local or domain administrator account to accurately assess the patch level of your computers.
• Network access to RPC, NetBIOS or SMB/CIFS ports— Alert Logic scanning requires access to RPC (135/tcp), NetBIOS (139/tcp, 137/udp, 138/udp) or SMB/CIFS (445/tcp adn445/udp). Network or personal firewalls blocking access to any of these protocols will prevent access to Windows patch scanning.
• Enable Remote Registry servicesThe Remote Registry service must be enabled and started. Verify this from the Administrative Control Panel under Services.

If the authentication failed, the scan report will list Exposure ID: 16205 - Local Checks Error.

To set up a dedicated user for scanning:

Use the following procedure to set up a dedicated user that Alert Logic can use for authenticated scanning.

1. Click Start, type lusrmgr.msc, and press Enter.
2. Right-click the Users folder, and then click New User.
   
3. On the New User window:
   1. In User Name, type a new user name (for example, Alert Logic Dedicated Scanning User).
   2. In Password, type a password.
   3. In Confirm Password, type the password again.
   4. Click Create.
      
4. After the window refreshes, indicating successful user creation, click Close.
5. Click the Groups folder, then right-click Administrators and click Add to Group.
   
6. On the Administrators Properties window, click Add.
   
7. On the Select Users window, in Enter the object names to select, type the newly created user (for example, Alert Logic), and click Check Names.
   
8. After the window refreshes, reflecting any changes and user confirmation, click OK.
   
9. On the Administrators Properties window, confirm that the user appears under Members, and click OK.
   
10. Close lusrmgr.

To set up WMI:

The Alert Logic scanner needs to connect to Windows Management Instrumentation (WMI) on the machine, in addition to remote registry, to pull version information from .dll and .exe files, as well as information stored within Windows Management services and settings. Unlike Unix and Linux, which come with SSH secure remote access where the system can log on and interrogate things as a user, Alert Logic scanning requires the administrative privileges due to the limitations of methods available to remotely access Windows machines. Alert Logic scanning does not make registry changes and does not write to the machine. To learn more about registry keys, refer to the Microsoft documentation here.

The Open Vulnerability and Assessment Language (OVAL®) method is the preferred method of network-based patch scanning. The scanner uses the OVAL method for assessing Windows-based machines for a variety of Microsoft-specific and third-party application security patches.

WMI comes installed on all Microsoft operating systems. The following procedure describes how to enable remote access to WMI.

To enable remote WMI requests:

1. On the target server, go to Administrative Tools, Computer Management.
2. Expand Services and Applications.
3. Right click on WMI Control, then select Properties.
   
4. Select the Security tab.
5. Click Security.
   
6. Add the scan user (if needed), and then be sure to check Remote Enable for the user/group that will be requesting WMI data.
   

Further Investigation

If the above steps didn’t help, Alert Logic recommends installing the WMI Administrative Tools from Microsoft. This includes a WMI browser that will let you connect to a remote machine and browse through the WMI information. That will help to isolate any issues in a more direct and simple environment. Once the WMI browser can access a remote machine, Alert Logic should have access as well.

UNIX/Linux authenticated scanning

All UNIX and Linux authenticated scanning (security patch scanning) is performed with Secure Shell (SSH) access using a standard user account.

UNIX/Linux operating system types

Alert Logic scanning supports the following operating systems for authenticated scanning:

• Amazon Linux AMI
• CentOS
• Debian
• Fedora
• RedHat
• SuSe
• Ubuntu

If the authentication failed, the scan report will list Exposure ID: 12152 - SSH Patch Scanning - Failed Logon.

Authenticated scanning in an Amazon Web Services environment

For authenticated scans to work properly in your environment, you must have your AWS security groups set to allow full access by the scanning appliance. Doing so allows a Cloud Insight appliance to communicate with client instances, so the authenticated scan can detect all possible vulnerabilities and configuration issues. Alert Logic installs appliances alongside the instances inside each Amazon VPC.

By default, security groups are set up to allow full communication among group members. If you modify the default settings, authenticated scans may not reflect a full picture of your instance.

Credential storage

Type	Encryption type	Notes
Front end web traffic	TLS 1.2 and AES 256 bit encryption, via HTTPS	User credentials are encrypted using the public key from the FusionVM server, and only the FusionVM server can decrypt the information.
FusionVM back end	RSA and Api call EncryptByAsymKey, 2048 bit key length	Encryption of user passwords and authentication credentials for scanned systems is handled by MS-SQL server.
Scanning appliances	RSA and DSA, 2048 bit key length	Encryption by OpenSSH in SSH connections between the Appliance and the FusionVM server. Scanning appliances do not have anything encrypted on the appliances except the password file for appliance login authentication.

Web application testing

Alert Logic scanning looks for sample/default web pages left from an installation and commonly named files and folders that draw attention from malicious users. Some additional tools check web applications for rudimentary validation errors.

PCI scanning for web applications

Comprehensive web application scanning is a standard part of Alert Logic PCI scans. Web application scanning enhancements offer hierarchically deep, page-level scanning of common attack vectors including SQL injection and cross-site scripting. The scanning system indexes web servers and builds a list of hierarchical URL links in the website. Web application checks are performed separately for each URL to provide sitewide coverage.

Other web application scanning features

• SQL injection: Check if SQL parameter injection is allowed on the query parameters
• Cross−site scripting: Check if cross−site scripting (XSS) is allowed on the query parameters
• HTTP PUT allowed: Check if the PUT option is enabled at server directories
• Directory index-able: Check if the server directories can be browsed
• Obsolete files exist: Check if obsolete files exist
• CGI scanning: Test for common check web pages

Spider capabilities

A spider crawls websites and gathers as many URL links as possible. These links provide the list of URLs the scanner targets for testing. Spider functions include:

• Crawling HTTP and HTTPS websites based on given URL
• Cookie support

The spider has the following limitations:

• SSL websites with invalid certificate cannot be crawled
• Some ‘malformed’ URLs in HTML pages cannot be recognized
• URLs generated by Javascript cannot be found using this spider

Wireless networks

Wireless environments are transparent to the Alert Logic scanning system. Wireless devices have IP addresses and run applications just like other network systems. In that sense, wireless devices are assessed for security by Alert Logic. However, Alert Logic scanning is based on the Network layer (specifically IP only) and above; lower levels such as Data Link (PPP, SLIP, Ethernet, 802.11b, ATM, Frame-relay) and physical (Fiber, Cat-5, Cat-3, phone line, serial cable) are not within the scope of a network-based assessment.

Vulnerability and exposure library

Vulnerability sources

Alert Logic uses a variety of vulnerability suppliers: public, commercial, third-party, and vendor-driven.

• Security Focus (bugtraq, pentest, incidents, vulndev)
• Cert
• Vulnwatch
• OSVDB
• CVE
• NVD
• I-Cat
• Other vendors

Severity ratings

Alert Logic severity ratings come from the method used by the National Institute of Standards and Technology National Vulnerability Database, and are based on the CVSS Base Score.

Alert Logic assigns each vulnerability one of the following severities based on the CVSS score:

Severity	CVSS base score
Info	0.0
Low	0.1 - 3.9
Medium	4.0 - 6.9
High	7.0 - 10.0

CVE numbers

The Common Vulnerabilities and Exposures (CVE®) enumeration system was developed by the MITRE Corporation. The CVE website provides more information.

Use the CVE number to find vulnerability text that other vendors/researchers have made available or correlate vulnerability assessments with IDS data.

Types of vulnerabilities

Dangerous default settings

Dangerous default settings can come in various forms, including:

• Leaving sample pages/scripts on an IIS installation
• Not changing the manager password from "manager" on a 3Com hub/switch
• Leaving public/private as SNMP community names on a SNMP enabled device
• Failing to set the sa password on a MS-SQL server

Software features and best practices

Attackers can take advantage of usability features for a system or application and use them to access your network. For example:

• ICMP timestamp/netmask requests
• Microsoft netBIOS protocol
• Expand/Verify commands of Sendmail
• Ident services displaying the owner of running processes

Misconfigurations

Alert Logic designed the scanning system to separate true misconfigurations from default out-of-the-box settings. Common misconfigurations that are identified and reported include:

• SMTP relay
• Unrestricted netbios file sharing
• DNS zone transfers
• FTP world writeable directories
• Default administration accounts without passwords
• Open FrontPage websites
• NFS world exportable directories

Vendor flaws

Vendor flaws is the largest category. It includes buffer overflows, string format issues, directory transversals, and cross-site scripting. This category includes any vulnerability that requires a patch or an upgrade to fix.

Related topics