Hunting Security Bugs

Following are several tips to help you test sending malicious server responses to a client application.

• The same concepts that are important in making malicious client requests are important when sending malicious server responses. The same tools work in both scenarios, including Web Proxy Editor, Jiri Richters MITM tool, and Netcat.

• Malicious responses are an entry point into the client. This entry point can allow for finding bugs in many categories. For example, buffer overruns, information disclosure, spoofing, and so forth. It is important to understand how the client interprets data it receives.

• If you have access to the source code of the client, it is useful to set breakpoints on common functions used to retrieve data from the network. These include recv , WSARecv , WSARecvEx , and WSARecvFrom . This enables you to see exactly which data is received by the application and to follow its use through the code.

• It is interesting to replace URLs sent by the server with URLs of other servers. Web browsers have a well-defined security model that does not allow them to access data from another domain. Sometimes because the legitimate server sends only relative URLs, the client wont perform any validation and will blindly follow full URLs to other servers. This allows malicious responses to cause data from other servers to enter the client while the user and client code think only the server to which the client is directly connected is being used. This issue, known as domain/zone elevation, is discussed further in Chapter 10.

• SSL provides no protection if the client can connect to arbitrary servers. Attackers can legitimately set up their own servers that use SSL.

• If the client connects to only specific servers over SSL, test to ensure the client verifies the SSL certificate is from a trusted certificate authority, that it is not expired , that the server name matches the name on the certificate, that the certificate has not been revoked , and so forth.

  Many system application programming interfaces (APIs) automatically perform certificate checks. However, parts of these checks can be disabled. It is easy to find bugs where the checks have been disabled through white box testing. Look for the following ways to disable certificate checks:

  • The SCHANNEL (Secur32.dll) ISC_REQ_MANUAL_CRED_VALIDATION flag can be passed to the InitializeSecurityContext function to bypass certificate validation that the system normally performs .

  • The WinInet (Wininet.dll) INTERNET_FLAG_IGNORE_CERT_CN_INVALID (which bypasses server name/certificate name match checks) and INTERNET_ FLAG_IGNORE_CERT_DATE_INVALID (which bypasses date checks) could be used when calling HttpOpenRequest and InternetOpenUrl .

  • The WinHTTP ( Winhttp .dll) WinHttpRequestOption enumeration type contains the WinHttpRequestOption_SslErrorIgnoreFlagsWinHttpRequestOption_SslErrorIgnore- FlagsSets , which can be configured to ignore various certificate problems. More information about this is available on MSDN ( http://msdn.microsoft.com/library/en-us/winhttp/http/winhttprequestoption.asp ).

• Be mindful of the downgrade attack. If the client supports legacy versions of the server and there are security concerns around legacy support, it is helpful to have a client option to communicate only with specific versions of the server.

• Even when other components are compromised, connecting clients should not be compromised. For example, if an attacker poisons the DNS and sends malicious responses from an imposter server, the client application shouldnt allow the attacker to take over connecting clients .

• Fuzz responses. Fuzzing server responses is often overlooked, but is a useful way to find malicious response bugs.