To understand what can be attacked, emulate the attacker
Savid uses a range of manual and automated tools and techniques within our penetration testing.
Savid performs penetration testing as the primary means to evaluate overall system and network security from an outsider’s perspective. The tools, methods, and techniques employed by Savid to perform these tests are generally well known throughout both the computer security and “hacker” communities. Hence, vulnerabilities or configuration liabilities discovered as a result of these tests can be viewed as those that any intruder may find while testing the network and connected systems.
This standard battery of tests and exploits that are publicly available tend to discover 90 – 95 percent of the vulnerabilities in a network. Savid differentiates their service from that of other security firms by having the technical ability to discover and fix that last 5 to 10 percent. Savid’s security engineers utilize extensive backgrounds in security, vulnerability research, and programming to develop custom tools, discover new vulnerabilities, and write exploits to find and fix that last 5 to 10 percent that other firms miss. Our world renowned pen test team has performed work for Fortune level companies and select government and military organizations.
All tests are conducted over the Internet, or locally if it is an internal network, to determine if network security controls (firewalls, server hardening, routers, etc.) are effective in preventing unwanted external intrusion and unauthorized access to resources on the internal network. All Internet tests are accomplished from the perspective of an outsider trying to gain unauthorized access. Below is a list of the steps that were taken while performing this penetration test:
Once an initial set of vulnerabilities are discovered Savid Engineers use the network information to craft customized attack vectors such as utilizing insecure Web Applications to perform SQL injections that lead to a compromised web server. Savid engineers are unique in that they have both network and application security auditing experience, giving them the opportunity to combine methodologies when auditing a customer network.
Pure black box testing is performed outside the network without valid login accounts and without any network knowledge. If white box testing is performed, testing is accomplished using an authorized, non-administrative user account, to determine any unauthorized access that can be performed. Client side exploitation is a more complex form of combined external then internal testing. It begins with a phishing exercise. Users who are socially engineered by the phishing emails will then have test software installed on their workstations. From the exploited client, Savid then tests to determine the degree of network and system exploitation possible, leveraging the exploited client workstation. By performing black box testing on the client’s external facing network, white box testing from inside the network and client side exploitation, Savid can paint a holistic picture of the client’s network vulnerabilities and risk.
Savid also has the ability to perform penetration test to analyze and find web application vulnerabilities. Our focus is on the Top Ten Web Application vulnerabilities as created by the Open Web Application Security Project (OWASP).
The following is a short summary of the most significant web application security vulnerabilities we look for:
| Top Vulnerabilities in Web Applications | |
| Unvalidated Input | Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backend components through a web application. |
| Broken Access Control | Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users’ accounts, view sensitive files, or use unauthorized functions. |
| Broken Authentication and Session Management | Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users’ identities. |
| Cross Site Scripting (XSS) Flaws | The web application can be used as a mechanism to transport an attack to an end user’s browser. A successful attack can disclose the end user’s session token, attack the local machine, or spoof content to fool the user. |
| Buffer Overflows | Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers, and web application server components. |
| Injection Flaws | Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application. |
| Improper Error Handling | Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server. |
| Insecure Storage | Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection. |
| Denial of Service | Attackers can consume web application resources to a point where other legitimate users can no longer access or use the application. Attackers can also lock users out of their accounts or even cause the entire application to fail. |
| Insecure Configuration Management | Having a strong server configuration standard is critical to a secure web application. These servers have many configuration options that affect security and are not secure out of the box. |
Depending on the application and our initial analysis of the application, Savid may or may not use automated tools to identify vulnerabilities or improper implementation of design patterns.
Our focus is on whether the software contains effective safeguards against error and abuse aimed at altering privileges, denying service, and compromising control of additional components. We place a special emphasis on systemic issues that might go beyond individual vulnerabilities. In general, our review attempts to explore questions such as:
