Will FusionVM perform buffer overflows/denial of service attacks against my network application?
Can denial of service situations occur through the FusionVM active testing?
General categories for “types” of vulnerabilities can be broadly categorized as the following:
Dangerous Default Settings - These can come in various forms. Examples would include:
- Leaving sample pages/scripts on a 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 serve
Software Features - This is a category that can also be thought of as "Best Practices". Often there are "feature" settings for a system or application that, while they are designed for better usability, can be used by attackers to gain access to your network. A good example is Microsoft's netbios protocol. For internal usage, this is very useful; however, if exposed to the Internet or another un-trusted network segment, it becomes a dangerous source of information. Other examples include:
- ICMP timestamp/netmask requests
- Expand/Verify commands of Sendmail
- Ident services displaying the “owner” of running processes.
Misconfigurations - This category includes many different vulnerabilities. The FusionVM system is built to separate true misconfigurations from default out-of-the-box settings. Common misconfigurations that are identified and reported on include:
- SMTP Relay
- Unrestricted netbios file sharing
- DNS Zone Transfers
- FTP world write-able directories
- Default administration accounts without passwords
- Open FrontPage webs
- NFS world exportable directories
Vendor Flaws - This is the largest category. This would include buffer overflows, string format issues, directory transversals, cross-site scripting and many others. This grouping includes any vulnerability that requires a patch or an upgrade to fix.
ANY test that can cause significant/fatal damage to a system or application is not run. Some buffer overflow and "dos" vulnerabilities can be safely tested for without causing harm to your server/service. Quality assurance measures on the tool creation process insure tests are safe before they are put into "general release" in the system. Even so, it is impossible to test for 100% of all configuration possibilities and its difficult to completely rule out any disruptions. The above can illustrated by some examples.
Example 1: dos Vulnerability in Web Server X: "By making repeated requests for http://web/badfile.htm it is possible to cause a web server to consume 100% of all processor speed, effectively creating a dos condition". In this case, checking for the existence of the file or making a single request would not create a dos scenario, however repeating 100,000 times would."
Example 2: Buffer Overflow in Web Server X: "By sending a large packet it is possible to overflow a buffer and possible run code". If this web server were known to automatically restart itself when it senses an outage, it would be safe to test. A good example is IIS 5 vs. IIS 4. IIS 4.0 will crash and require an administrator to reboot or restart the application, while IIS 5.0 will automatically restart itself with only milliseconds of downtime.
Example 3: Symantec's PC Anywhere Version 9.2 will crash when it is port scanned using a TCP Connect method. The TCP Connect method is the most application friendly port scanning method available, as it follows the RFC TCP handshaking protocol. The crash is due to faulty programming in the application and cannot be prevented by Critical Watch. By the time we would have discovered that the application exists on the target network, the service would have already halted.
For vulnerabilities that require a non-active testing method, the FusionVM 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.
Critical Watch has identified two different scenarios upon which active testing could cause a denial of service situation on a network.
1. Consumption of Firewall Connections/Exhaustion of Firewall Resources If an internal VM Server is placed "behind" a firewall and instructed to scan machines on the other side of the firewall, there is the possibility that the VM Server could exhaust the available out-bound connections/resources of the firewall. This has been seen in particular on Cisco PIX firewalls where Port Address Translation was being used to PAT private, internal addresses to the outside interface. Specifically, when the port scanning phase of the scan is performed there are a large number of connections initiated to identify all open ports on a target device.
Solution:
A) Place the VM Server on a different segment of the network where it does not have to traverse through the firewall to reach the target.
B) Provide a static IP translation for the IP address of the testing unit. This should help reduce the number of connections the firewall would need to "remember" during the testing.
2. Debug Level Logging/Religious Logging" If an appliance is performing a high level of logging, it is possible to cause a denial of service situation. This has been seen in both internal and external testing; however, this is not a Critical Watch specific issue, but rather a classic security vulnerability. If a firewall is logging every connection attempt to a remote system, this could potentially generate Gigabytes of log file traffic. This has been seen to both cause a strain on network infrastructure as well as exhaust 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 amount of connections to a device can range anywhere from 1,500/3,000 ports connection attempts up to 65,535/131,070 ports connection attempts (if all TCP & UDP ports are investigated). Now, take the upper limit (131,070) and multiply this across a full Class C address space (256). This quickly grows to a large amount of log traffic.
Solution: To prevent a denial of service situation use a lower level of logging.
FusionVM generally tests for any operating system that supports a TCP/IP stack; however, results will vary from OS to OS. While DOS and Windows 3.1 WFWG supports TCP/IP, known vulnerabilities for these systems are few. FusionVM covers a wide variety of operating systems, applications and devices. The complete exposure library is searchable in the FusionVM portal under the “Research” tab.
As a rule, the system does not rely on OS guessing as a part of vulnerability assessments. For instance, a network that uses an F5 BIG-IP load balancer on their perimeter would skew the results of a test that relied on OS 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. Using OS guessing, solely, can result in inaccurate results.
FusionVM uses several methods for determining that an IP address is “active”. Initially, a “Ping Sweep” using ICMP messages is sent to each address. Then a “TCP Ping” is sent to commonly used ports (21, 22, 23, 25, 80, 443, etc.). TCP “Pings” use a deviation of the TCP standard three-way handshake to determine if a machine responds. This method sends an unsolicited TCP “Acknowledge” (TCP ACK) to the specified port. If an active machine is listening on this port, it should send back a reset to the unsolicited request. Another method involves sending a TCP “Synchronize” (TCP SYN) message (similar to the TCP ACK) to the commonly used ports and looking for a response.
Also, while this allows for a high success in detecting active hosts, only machines with open ports apply to licensing for billing. This prevents blank network address space, such as NAT pools, from inflating IP usage numbers.
FusionVM leverages a variety of vulnerability information suppliers: public, commercial, 3rd party & vendor-driven. Examples include:
- Security Focus (bugtraq, pentest, incidents, vulndev)
- Cert
- Ntbugtraq
- Vulnwatch
- OSVDB
- CVE
- I-Cat
- FBI Infragard
- A host of vendors
- USENET newsgroups
- "Underground" hacker sites
The complete and daily updated exposure library is searchable within the FusionVM portal using the “Research” tab.
Upon boot, the appliance makes an out-bound request to a high numbered port from your location to our network across the Internet. It establishes a secure connection to our system and creates a VPN Tunnel back to the local loop-back device of the appliance. When testing or updating, the system will use the Tunnel of this "call-back VPN" to connect to the appliance. This connection is encrypted with a unique public/private key set and it is not open to anyone else from the outside. A route to the Internet and a local DNS resolver is required for this to function correctly
The outbound VPN is actually a secure shell (ssh) back to our system. Once connected, it creates a number of 'tunnels' through the established connection. The first tunnel that is opened creates a TCP port 3383 (mysql) on the local loopback device. The local port is then 'forwarded' over the ssh connection back to the main controller where a lightweight mysql database is listening. A separate process is responsible for periodically polling the database for any instruction sets to run. The terms tunneling and forwarding are part of the ssh protocol collection.
Yes HTTP & HTTP(s) proxy server are supported.
Yes and No. In general, many of the http checks that are performed do overlap into the ‘custom’ application testing; however, this should not be taken as a complete Web Application test or source code audit. FusionVM looks for sample/default web pages that get left from an install, it also checks for common named files/folders that draw unwanted attention from outsiders. In addition, there are some tools that will check web application for rudimentary validation errors. Again this shouldn’t be a substitute for a complete application audit. For discovered self-created code vulnerabilities, there really is no good substitute for a third party (person or software) to manually review the source code.
It does perform some username and password guessing; however, FusionVM does not perform an all-out brute force attempt against accounts. Many devices come with default administrative account names, and there are quite a few standard username/password combinations the system checks for. For example: 3Com’s hubs/switches default logon of manager:manager: Windows Network administrator:administrator or adminstrator:blank: MS-SQL sa:blank. While it is checking for the basics and the defaults, FusionVM will not perform straight brute force attempts against logins, as there is too great a risk of causing a Denial of Service situation by locking out accounts.
FusionVM is built to enable safe and accurate assessments without affecting network operations. Part of this addresses the aspect of how" deep" the scans attempt to go. FusionVM is geared toward identifying vulnerabilities, not exploiting them. 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, etc) but there is no active attempt to exploit holes to demonstrate what an attacker can do. FusionVM is an automated system built to enable an operational process around assessing vulnerabilities not penetrating holes and creating security breaches. If you are interested in seeing how your network could be penetrated, that is best handled through a manual consulting engagement.
Wireless environments are completely transparent to the FusionVM system. Wireless devices have IP addresses and run applications just like other network systems. In that sense, wireless devices are assessed for security using FusionVM. However, FusionVM 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.
IP ranges are specified by you in the FusionVM portal (Jobs Manager tab), so if you specify a range that is home to a call-in modem bank, then yes they will be seen. Of course, connection speed in a typical modem environment will affect the scan performance. However, as high speed Internet is in greater use both in homes, hotels, etc..many people are using VPN software over their existing broadband connections. This would enable a normal scanning scenario. Whatever IP a user received when they connected to your network would be the IP address assessed by the FusionVM System (*Note: not the originating IP from the home/hotel/remote network).
Yes, but there is no way to assure that all devices will be assessed. This is due to the fact that the algorithm that determines load distribution is not in the VM Server's control, but rather determined by the load balancing device. Issues that are commonly found across your code base would be found, but machine specific issues might be missed due to the decisions made by the load balancing device. The correct method to ensure that each device is tested would be to place a VM Server that could reach the individual machines in the farm. FusionVM supports the use of Virtual Host Headers so that each machine's web applications could be tested for known CGI abuses.
The FusionVM scan engine is built to achieve accuracy in a non-intrusive manner. The system utilizes both active scan tools that are designed and tested to be sensitive to network operations, as well as passive asset profiling that do not require an active test. In addition, there are multiple scan job and schedule configuration options to insure non-disruptive scanning. Each job can have bandwidth limits applied to it. There is also the ability to set custom parameters for more “light” or “heavy” port scanning, as well as the option to denote IP exceptions for problem devices that may not respond well to scanning. FusionVM also offers flexible scheduling as well as Operational Windows that create hard start and stop windows for active scanning. This feature can be deployed to insure scan activity is occurring only during approved times.
No, FusionVM is a completely agent less technology that uses secure, hardened appliances to perform scans network based scans using protocol based communication.