Pentesting Script – Guidelines

In this post I’ll be covering mostly the basics of any pentest assessment, which is basically a generic checklist of what to test and the tools you should be using. Obviously, as my recommendation, they sure aren’t the only way to do things, this is a compilation of best practices and experiences that I’ve gathered over my years working as a security analyst. The best way will always be the way you get along with mixed with the one that suit your needs.

To start off, this post covers 5 major phases that I generally run on every pentest assessment, this list doesn’t need to be run extensively in every test, since each assessment has its own particularities. This works great as a guide during a test, by looking at the phases and its tasks as testing recommendations, and as you may think, I’m not listing every single step and tasks since my testing script is very extensive. Start off, as for the first phase:

  • Phase 1 – Automated Testing

This phase is responsible for the hard and extensive work during an assessment. Automated scanning tools should be used first, as they can setup the initial path you should take for more detailed testing and save precious time. These tools can be slipt mostly in two categories, the first one that focus in web application testing and the second for infrastructure testing. As for the tasks in this phase, here’s the most important:

  • Run infrastructure automated scan. (Nmap, Nexpose, Nessus);
  • Run application automated scan. (Acunetix, Burp Suite, ZED);
  • Run Nmap or similar tool to scan all TCP ports;
  • If any vulnerabilities be identified, verify whether public exploits exist (Metasploit, Exploit-DB.com.

Acunetix, Nexpose and Nessus are excellent paid commercial tools but they all can be replaced by manual testing, open source tools and a lot of patience if you can’t afford paying for these licenses.

  • Phase 2 – Manual Testing – Information Gathering

In this phase, if it applies, we will be looking for relevant public information about the target of the assessment, such as e-mails addresses that may be used on the application, manuals and any sensitive information indexed by the major search providers (Google and Shodan for example). Any information found on this phase may help the further testing at some point and mostly, at the manual testing. The tasks of this phase are:

  • Provoke application errors and analyze responses for possible information leakage;
  • Identify potentially dangerous functionalities such as file uploads;
  • Attempt to identify possible hidden features of the application (e.g. Hidden debug / admin parameters or links);
  • Verify whether error pages can be influenced by user input parameters.

Any information that may seem useless at first should be stored for later analysis. I had countless assessments that I got myself using something that at first I thought I you’d never use.

  • Phase 3 – Manual Testing – Authentication Testing

This phase main objective is to test how the application works with authentication. Whether by using manual credentials input, SSO (Single Sign On) feature or none at all, we will focus our efforts in finding vulnerabilities regarding the authentication process.

  • Verify whether HTTPS is used to encrypt credentials and / or sensitive data;
  • Test for user enumeration vulnerabilities;
  • Test for bypassing authentication by forced browsing;
  • Test for bypassing authentication by SQL Injection on the login page;
  • Test if password reset/reminder can be guessed or bypassed;
  • If possible, verify that all users have a unique user id;

The idea is trying to bypass the regular authentication of the application, accessing it without any authentication at all or even by using a profile you don’t have access.

  • Phase 4 – Manual Testing – Session Management Testing

Session management is how the application handles user sessions by the time you get first authenticated, for example, after you provide the login credentials. The main idea in this phase is to check whether the application can maintain good track of your privileges as an authorized user and which actions you can take “inside” of the application. Tasks in this phase can be summarized as:

  • Verify session timeout enforced in a reasonable amount of time;
  • Check for session fixation (not invalidating/re-issuing current session token after authenticating or forcing a known session ID on a user);
  • If the site is secure (HTTPS), check if the session ID passed over an unencrypted connection at any stage (HTTP);
  • Check is the session ID is sent in a GET request at any stage. Verify if it is possible to force it into the GET request;
  • Verify that all pages that require authentication also contain a clear Logout button;
  • Check for weak obfuscation or encryption of cookie data;
  • Test if concurrent logins are possible.

Common exploits regarding session management are privileges elevation, user personification and session theft, these can be done by manipulating sessions cookies and by modifying users ID’s.

  • Phase 5 – Manual Testing – Data Validation & Business Logic Testing

This final phase aims for tests of vulnerabilities that your automated tool of choice may already had pointed out, such as SQL Injection, XSS (cross-site scripting), HTML injection and many others. If none of these were pointed out, manual testing should take place in areas where the current type of vulnerability you are testing normally appear, places like forms, fields and any place that data can be inputted by the user. This phase is also the time for specific business logic testing, functionality that are critical to the business.

  • Attempt to subvert critical business logic. (Change transfes limits, access data from client a with client B, change users preferences, etc.);
  • All suspicious parameters (POST & GET parameters, SOAP Headers, etc) manually tested for (Blind) SQL Injection;
  • Generic user input validation testing;
  • Command injection;
  • All suspicious parameters (POST & GET parameters, SOAP Headers, etc) manually tested for Cross-Site Scripting.

Remember that the best way to do any pentesting is by following good practices and most importantly doing what works for you, focus on your best field like programming, thinking out of the box or if everything else fails, reading a lot from Google. Check out OWASP Testing Guide that I’ve posted on my previous post, it should serve you just right to start off.

Advertisements